(57)【要約】【課題】暗号鍵の共有速度、および、暗号鍵の蓄積量などに応じて、アプリケーションに提供する暗号鍵の量を制限する通信装置を提供する。【解決手段】通信装置は、他の通信装置との間で共有した暗号鍵をアプリケーションに提供する通信装置である。通信装置は、算出部と、通信制御部と、を備える。算出部は、暗号鍵の共有速度、および、暗号鍵の蓄積量の少なくとも１つに基づいて、アプリケーションが暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する。通信制御部は、要求メッセージに対する応答として暗号鍵を返すメッセージであって、制限情報を付加した応答メッセージをアプリケーションに送信する。【選択図】図５
2019050453.tif 000002
【特許請求の範囲】
【請求項１】
他の通信装置との間で共有した暗号鍵をアプリケーションに提供する通信装置であって、
前記暗号鍵の共有速度、および、前記暗号鍵の蓄積量の少なくとも１つに基づいて、前記アプリケーションが前記暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する算出部と、
前記要求メッセージに対する応答として前記暗号鍵を返すメッセージであって、前記制限情報を付加した応答メッセージを前記アプリケーションに送信する通信制御部と、
を備える通信装置。
【請求項２】
前記制限情報は、単位時間あたりに前記要求メッセージを呼び出し可能な回数の最大値、および、単位時間あたりに前記要求メッセージを呼び出し可能な残りの回数のうち少なくとも一方を含む、
請求項１に記載の通信装置。
【請求項３】
前記制限情報は、単位時間あたりに前記要求メッセージに応じて提供可能な暗号鍵の最大値、および、単位時間あたりに前記要求メッセージに応じて提供可能な残りの暗号鍵の量のうち少なくとも一方を含む、
請求項１に記載の通信装置。
【請求項４】
前記要求メッセージが受信されたときに、前記要求メッセージの呼び出しの制限を超えたか否かを判定する判定部をさらに備え、
前記通信制御部は、さらに、前記要求メッセージの呼び出しの制限を超えたと判定された場合に、制限を超えたことを示すエラーメッセージを前記アプリケーションに送信する、
請求項１に記載の通信装置。
【請求項５】
前記通信制御部は、前記要求メッセージを呼び出し可能となるタイミングを示す情報を含む前記エラーメッセージを前記アプリケーションに送信する、
請求項４に記載の通信装置。
【請求項６】
前記算出部は、さらに、前記アプリケーションの数、前記アプリケーションの優先度、要求された前記暗号鍵のサイズ、前記アプリケーションに過去に提供された前記暗号鍵の量、および、前記アプリケーションの認証結果、のうち少なくとも１つに基づいて、前記制限情報を算出する、
請求項１に記載の通信装置。
【請求項７】
前記要求メッセージおよび前記応答メッセージは、ＨＴＴＰ（Hypertext  Transfer  Protocol）およびＪＳＯＮ（JavaScript  Object  Notation）に基づくウェブＡＰＩ（Application  Programming  Interface）であり、
前記応答メッセージは、ＨＴＴＰヘッダに前記制限情報が付加される、
請求項１に記載の通信装置。
【請求項８】
他の通信装置との間で共有した暗号鍵をアプリケーションに提供する通信装置で実行される通信方法であって、
前記暗号鍵の共有速度、および、前記暗号鍵の蓄積量の少なくとも１つに基づいて、前記アプリケーションが前記暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する算出ステップと、
前記要求メッセージに対する応答として前記暗号鍵を返すメッセージであって、前記制限情報を付加した応答メッセージを前記アプリケーションに送信する通信制御ステップと、
を含む通信方法。
【請求項９】
他の通信装置との間で共有した暗号鍵をアプリケーションに提供する通信装置が備えるコンピュータを、
前記暗号鍵の共有速度、および、前記暗号鍵の蓄積量の少なくとも１つに基づいて、前記アプリケーションが前記暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する算出部と、
前記要求メッセージに対する応答として前記暗号鍵を返すメッセージであって、前記制限情報を付加した応答メッセージを前記アプリケーションに送信する通信制御部と、
として機能させるためのプログラム。
【請求項１０】
アプリケーションを実行する情報処理装置と、他の通信装置との間で共有した暗号鍵を前記アプリケーションに提供する通信装置と、を含む通信システムであって、
前記通信装置は、
前記暗号鍵の共有速度、および、前記暗号鍵の蓄積量の少なくとも１つに基づいて、前記アプリケーションが前記暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する算出部と、
前記要求メッセージに対する応答として前記暗号鍵を返すメッセージであって、前記制限情報を付加した応答メッセージを前記アプリケーションに送信する通信制御部と、を備え、
前記アプリケーションは、
前記応答メッセージに含まれる前記制限情報に基づいて通信を制御する、
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、通信方法、プログラムおよび通信システムに関する。
【背景技術】
【０００２】
通信装置間で共有された暗号鍵を用いて通信を行うアプリケーションが知られている。例えば定期的に暗号鍵を更新する場合は、通信装置は新たな暗号鍵を生成し、生成した暗号鍵を他の通信装置と共有する。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】GitHub  Developer、[online]、August  2017、retrieved  from  the  Internet：<URL:https://developer.github.com/v3/#rate-limiting>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
暗号鍵の共有速度には上限があるとともに、暗号鍵の共有速度は外的な要因によって変動しうる。また、同じ通信装置に複数のアプリケーションが接続して暗号鍵を利用する場合には、アプリケーションの接続数に応じて、各アプリケーションが使用可能な暗号鍵の量が変動しうる。従って、暗号鍵の共有速度、および、暗号鍵の蓄積量などに応じて、アプリケーションに提供する暗号鍵の量を制限できることが望ましい。
【課題を解決するための手段】
【０００５】
実施形態の通信装置は、他の通信装置との間で共有した暗号鍵をアプリケーションに提供する通信装置である。通信装置は、算出部と、通信制御部と、を備える。算出部は、暗号鍵の共有速度、および、暗号鍵の蓄積量の少なくとも１つに基づいて、アプリケーションが暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する。通信制御部は、要求メッセージに対する応答として暗号鍵を返すメッセージであって、制限情報を付加した応答メッセージをアプリケーションに送信する。
【図面の簡単な説明】
【０００６】
【図１】通信システムの基本構成の例を説明するための図。
【図２】量子鍵配送ネットワークの例を示す図。
【図３】量子鍵配送ネットワークによりグローバルキーを共有する方法のシーケンス図。
【図４】接続ノード情報の例を示す図。
【図５】第１の実施形態にかかるノードのブロック図。
【図６】ウェブＡＰＩの一例を示す図。
【図７】暗号鍵および鍵ＩＤのフォーマットの例を示す図。
【図８】ＨＴＴＰレスポンスのヘッダ例を示す図。
【図９】ＨＴＴＰレスポンスのヘッダ例を示す図。
【図１０】ＨＴＴＰレスポンスのヘッダ例を示す図。
【図１１】ＨＴＴＰレスポンスのヘッダ例を示す図。
【図１２】第１の実施形態による通信処理のシーケンス図。
【図１３】第１の実施形態による通信処理のシーケンス図。
【図１４】第２の実施形態にかかるノードのブロック図。
【図１５】第２の実施形態による通信処理のシーケンス図。
【図１６】第２の実施形態による通信処理のシーケンス図。
【図１７】変形例１による通信処理のシーケンス図。
【図１８】第１および第２の実施形態にかかる通信装置のハードウェア構成図。
【発明を実施するための形態】
【０００７】
以下に添付図面を参照して、この発明にかかる通信装置の好適な実施形態を詳細に説明する。
【０００８】
上述のように、暗号鍵の共有速度の上限および変動、並びに、接続するアプリケーション数などに応じて、各アプリケーションが使用可能な暗号鍵の量が変動しうる。
【０００９】
アプリケーションは、通信のタイミングに応じて、または、定期的に暗号鍵の更新および取得を行うのが一般的な挙動となる。アプリケーションとしては、暗号鍵が必要なときに常に十分な暗号鍵が得られることが望ましい。しかし上記制約から、この要求が満たされない場合が生じうる。一方、少なくとも、ある時点までは十分に取得できていた暗号鍵が、急に取得できなくなるといった事態が発生することは避けることが望ましい。送信（または受信）するデータがあるのに、暗号鍵が取得できないために送信（または受信）ができなくなるためである。
【００１０】
このように、アプリケーションは、暗号鍵の共有速度（蓄積量）およびその変動、並びに、接続しているアプリケーションの状況等を踏まえ、自身において可能な、適切な暗号鍵の取得頻度または取得量を把握したい。
【００１１】
一方、通信装置は、暗号鍵の共有速度および蓄積量の変動、接続するアプリケーションおよび複数のアプリケーションからの暗号鍵の要求の変動、並びに、通信装置自身の処理負荷をも考慮して、各アプリケーションに対して提供できる鍵のレート制限を行いたい。
【００１２】
特に、量子鍵配送（ＱＫＤ：Quantum  Key  Distribution）など、変動しうる速度で鍵を共有する技術を用いる場合、システム全体で暗号鍵が不足しないように、アプリケーションに提供する暗号鍵の量を適切に制限できることが望ましい。
【００１３】
量子鍵配送は、光ファイバーにより接続された送信装置と、受信装置と、の間で連続的に送信された単一光子を利用して、安全に暗号鍵を共有する技術である。量子鍵配送により共有された暗号鍵は、量子力学の原理に基づいて、盗聴されていないことが保証されている。共有された暗号鍵は、例えばワンタイムパッド等の暗号データ通信に利用される。ワンタイムパッドにより送受信された暗号データは、如何なる知識を有する盗聴者によっても解読できないことが情報理論によって保証されている。
【００１４】
以下では、暗号鍵の共有方式として量子鍵配送を適用した場合を例に説明する。適用可能な方式は量子鍵配送に限られず、他の任意の暗号鍵の共有方式を適用できる。
【００１５】
（第１の実施形態）
第１の実施形態にかかる通信装置は、アプリケーションへ鍵を提供するＡＰＩ（Application  Programming  Interface）を用いて、提供する暗号鍵を制限するレート制限（rate  limit）の機能を実現する。この制限は、アプリケーションが要求している暗号鍵の共有速度（単位時間あたりの増加量または変動）、および、蓄積量（残量）の少なくとも一方によって決定される。
【００１６】
［基本構成］
図１は通信システムの基本構成の例を説明するための図である。図１の通信システムは、ノード１０ａおよび１０ｂを含む量子鍵配送システム、並びに、アプリケーション２０ａおよび２０ｂを含む暗号データ通信システムを備える。アプリケーション２０ａおよび２０ｂは、暗号データ通信ネットワーク３０を介して暗号データ通信を行う。
【００１７】
ノード１０ａおよび１０ｂは、量子鍵配送を行うノード（Trusted  Node）である。図１の説明では、ノード１０ａを送信側の通信装置とし、ノード１０ｂを受信側の通信装置とする。以下、ノード１０ａおよび１０ｂを区別しない場合、単にノード１０という。
【００１８】
アプリケーション２０ａおよび２０ｂは、ノード１０ａおよび１０ｂにより共有された暗号鍵を使用して、暗号データ通信を行う。アプリケーション２０ａにより使用される暗号鍵は、ノード１０ａにより提供される。アプリケーション２０ｂにより使用される暗号鍵は、ノード１０ｂにより提供される。アプリケーション２０ａおよび２０ｂは、サーバ装置、パーソナルコンピュータおよびスマートデバイス等の情報処理装置により実行される。以下、アプリケーション２０ａおよび２０ｂを区別しない場合、単にアプリケーション２０という。なおアプリケーション２０を実行する情報処理装置は、ノード１０でもよい。
【００１９】
量子鍵配送技術により暗号鍵を共有する方式では、単一光子をメディアとして利用するので、暗号鍵を共有可能な距離の制約がある。そのため、図２に示すような量子鍵配送ネットワーク（ＱＫＤネットワーク）が利用される。
【００２０】
図２は量子鍵配送ネットワークの例を示す図である。図２の量子鍵配送ネットワークは、光ファイバーリンクにより接続されたノード１０ａ〜１０ｃを備える。アプリケーション２０ａを実行する情報処理装置は、ノード１０ａと接続される。また、アプリケーション２０ｃを実行する情報処理装置は、ノード１０ｃと接続される。アプリケーション２０ａおよび２０ｃは、暗号データ通信ネットワーク３０を介して暗号データ通信を行う。
【００２１】
各ノード１０は、光ファイバーリンクによって接続された隣接するノード１０との間で量子鍵配送を行うことにより、暗号鍵を共有する。ここで、第１の実施形態の説明では、光ファイバーリンクによって接続された隣接するノード間で量子鍵配送により共有される暗号鍵をローカルキーという。すなわちローカルキーは、リンク間で使用されるリンク鍵である。
【００２２】
さらにノード１０は、量子鍵配送とは無関係に、別途、乱数情報等から暗号鍵を生成する。第１の実施形態の説明では、この暗号鍵をグローバルキーという。すなわちグローバルキーは、アプリケーション２０の暗号データ通信に使用されるアプリ暗号鍵である。
【００２３】
ノード１０は、グローバルキーをローカルキーにより暗号化し、暗号化されたグローバルキーを隣接するノード１０に転送する。各ノード１０は、隣接するノード１０との間で、ローカルキーにより暗号化されたグローバルキーを転送する処理を繰り返す。これにより各ノード１０は、任意のノード１０との間でグローバルキーを共有することができる。
【００２４】
上述のようにグローバルキーは、量子鍵配送によって共有されるローカルキーによって暗号化された状態でリンク上を転送される。したがって、ノード１０自体の安全性を仮定すると、グローバルキーの安全性は、ローカルキーと同様に保証されると言える。
【００２５】
図３は、図２の量子鍵配送ネットワークによりグローバルキー（アプリ暗号鍵）を共有する方法の例を示すシーケンス図である。図３の説明では、アプリケーション２０ａが、アプリケーション２０ｃと暗号データ通信を行う場合について説明する。
【００２６】
はじめに、ノード１０ａおよび１０ｂが、量子鍵配送によりローカルキーを共有する（ステップＳ１）。次に、ノード１０ｂおよび１０ｃが、量子鍵配送によりローカルキーを共有する（ステップＳ２）。
【００２７】
次に、アプリケーション２０ａが、アプリケーション２０ａの通信先との暗号データ通信に使用されるグローバルキーの取得要求を、ノード１０ａに送信する（ステップＳ３）。取得要求は、例えば通信先を特定する通信先特定情報を含む。通信先特定情報は、例えば、通信先のアプリケーション名、および、通信先のアドレス等である。
【００２８】
次に、ノード１０ａが、ステップＳ３の処理により送信された取得要求に含まれる通信先と接続されるノード１０ｃを、グローバルキーを共有するノード１０として特定する（ステップＳ４）。具体的には、ノード１０ａは、例えば接続ノード情報を参照することにより、グローバルキーを共有するノード１０を特定する。接続ノード情報は、例えばアプリケーション２０とノード１０との接続関係が記述されたディレクトリデータである。
【００２９】
図４は接続ノード情報の例を示す図である。図４の接続ノード情報は、エントリＮｏ．、アプリＩＤおよびノードＩＤを含む。エントリＮｏ．は、接続ノード情報に含まれる各データを識別する番号である。アプリＩＤは、アプリケーション２０を識別する識別情報である。例えばＡは、アプリケーション２０ａのアプリＩＤを示す。ノードＩＤは、ノード１０を識別する識別情報である。図４の例では、ノード１０の識別情報としてＩＰアドレスが使用されている。
【００３０】
図３に戻り、次に、ノード１０ａは、グローバルキーを生成する（ステップＳ５）。生成されたグローバルキーは、当該グローバルキーを識別する鍵ＩＤ等の識別情報により識別される。次に、ノード１０ａは、ステップＳ１の処理により共有されたローカルキーにより、ステップＳ５の処理により生成されたグローバルキーを、当該グローバルキーの鍵ＩＤとともに暗号化する（ステップＳ６）。次に、ノード１０ａは、ステップＳ６の処理により暗号化されたグローバルキーをノード１０ｂに送信する（ステップＳ７）。
【００３１】
次に、ノード１０ｂは、ノード１０ａから暗号化されたグローバルキーを受信すると、当該暗号化されたグローバルキーの復号、および、暗号化を行う（ステップＳ８）。具体的には、ノード１０ｂは、暗号化されたグローバルキーを、ステップＳ１の処理により共有されたローカルキーにより復号し、復号されたグローバルキーを、ステップＳ２の処理により共有されたローカルキーにより暗号化する。
【００３２】
次に、ノード１０ｂは、ステップＳ８の処理により暗号化されたグローバルキーを、ノード１０ｃに送信する（ステップＳ９）。
【００３３】
次に、ノード１０ｃが、ノード１０ｂから暗号化されたグローバルキーを受信すると、ステップＳ２の処理により共有されたローカルキーにより復号する（ステップＳ１０）。次に、ノード１０ｃは、ステップＳ１０の処理により復号されたグローバルキーを格納する（ステップＳ１１）。
【００３４】
次に、ノード１０ａが、ステップＳ５の処理により生成されたグローバルキーを、当該グローバルキーの鍵ＩＤとともにアプリケーション２０ａに提供する（ステップＳ１２）。
【００３５】
次に、アプリケーション２０ａが、ステップＳ１２の処理により提供されたグローバルキーの鍵ＩＤをアプリケーション２０ｃに通知する（ステップＳ１３）。
【００３６】
次に、アプリケーション２０ｃが、ステップＳ１３の処理により通知された鍵ＩＤを含むグローバルキーの取得要求を、ノード１０ｃに送信する（ステップＳ１４）。次に、アプリケーション２０ｃは、ステップＳ１４の処理により送信された鍵ＩＤにより識別されるグローバルキーを、ノード１０ｃから受信する（ステップＳ１５）。
【００３７】
次に、アプリケーション２０ａおよび２０ｂは、ステップＳ１〜ステップＳ１５の処理により共有されたグローバルキーにより、暗号データ通信を行う（ステップＳ１６）。
【００３８】
なお、上述の説明では、ステップＳ３の処理によりグローバルキーの取得要求がノード１０ａにより受信された後に、ステップＳ５〜ステップＳ１１の処理により、グローバルキーの共有処理が行われる場合について説明した。しかしながら、グローバルキーの共有処理を行われるタイミングは任意でよい。例えば、ノード１０ａは、ノード１０ａおよび１０ｃの間で予め共有されていたグローバルキーを、ステップＳ３の処理によりグローバルキーの取得要求を受信した後に使用してもよい。
【００３９】
また、上述の説明では、アプリケーション２０ａとアプリケーション２０ｃとの間の暗号データ通信に先立って、ステップＳ１３の処理により鍵ＩＤが通知される場合について説明した。しかしながら、鍵ＩＤの通知処理が行われるタイミングは任意でよい。例えば、アプリケーション２０ａは、ステップＳ１２の処理により提供されたグローバルキーにより暗号化された暗号データとともに、当該グローバルキーを識別する鍵ＩＤを、アプリケーション２０ｃに送信してもよい。
【００４０】
一般に、上述の各ノード１０は、それぞれ地理的に離れた場所に設置され、各アプリケーション２０は、各ノード１０上、または、ノード１０と同一のサーバールーム等で動作する情報処理装置上で実行される。
【００４１】
図５は、第１の実施形態にかかるノード１０の構成の一例を示すブロック図である。図１に示すように、ノード１０は、通信Ｉ／Ｆ（インタフェース）１１１、１１２と、状態記憶部１２１と、鍵記憶部１２２と、通信制御部１０１と、判定部１０２と、算出部１０３と、鍵共有部１０４と、を備えている。
【００４２】
通信Ｉ／Ｆ１１１は、ノード１０がアプリケーション２０と通信するためのネットワークインタフェースである。通信Ｉ／Ｆ１１２は、ノード１０が他のノード１０との間でグローバルキーを共有するなどの目的で通信するためのネットワークインタフェースである。
【００４３】
状態記憶部１２１は、ノード１０と接続しているアプリケーション２０の状態などを記憶する。例えば状態記憶部１２１は、接続しているアプリケーション２０の数、接続しているアプリケーション２０を識別する情報などを記憶する。
【００４４】
鍵記憶部１２２は、鍵共有部１０４により他のノード１０との間で共有された鍵（ローカルキーおよびグローバルキー）を記憶する。
【００４５】
通信制御部１０１は、アプリケーション２０などの外部装置との間の通信を制御する。例えば通信制御部１０１は、暗号鍵を要求する要求メッセージの解釈、および、要求メッセージに応じてアプリケーション２０に暗号鍵を提供するための応答メッセージ（鍵提供メッセージともいう）の組み立てなどを行う。
【００４６】
鍵共有部１０４は、他のノード１０との間で暗号鍵を共有する処理を制御する。例えば鍵共有部１０４は、暗号鍵を生成し、生成した暗号鍵を他のノード１０との間で共有する。上述したとおり、本実施形態では暗号鍵の共有方式として量子鍵配送技術を用いる。従って、隣接するノード１０との間で、ローカルキーが共有される。また、ローカルキーを用いて他の任意のノード１０との間でグローバルキーが共有される。
【００４７】
算出部１０３は、提供する暗号鍵を制限するための制限情報を算出する。例えば算出部１０３は、暗号鍵の共有速度、および、暗号鍵の蓄積量の少なくとも１つに基づいて、アプリケーション２０が暗号鍵を要求する要求メッセージの呼び出しを制限する制限情報を算出する。制限情報は、例えば、単位時間あたりに要求メッセージを呼び出し可能な回数の最大値、および、単位時間あたりに要求メッセージを呼び出し可能な残りの回数のうち少なくとも一方を含む。
【００４８】
本実施形態では、通信制御部１０１は、算出された制限情報を付加した応答メッセージをアプリケーション２０に送信する。
【００４９】
判定部１０２は、制限情報が示す制限が満たされているかを判定する。例えば判定部１０２は、要求メッセージが受信されたときに、要求メッセージの呼び出しの制限を超えたか否かを判定する。
【００５０】
本実施形態では、通信制御部１０１は、さらに、要求メッセージの呼び出しの制限を超えたと判定された場合に、制限を超えたことを示すエラーメッセージをアプリケーション２０に送信する。エラーメッセージは、要求メッセージを次に呼び出し可能となるタイミングを示す情報を含んでもよい。
【００５１】
上記各部（通信制御部、判定部、算出部、および、鍵共有部）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵ（Central  Processing  Unit）などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣ（Integrated  Circuit）などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。
【００５２】
上記記憶部（状態記憶部１２１および鍵記憶部１２２）は、ＨＤＤ（Hard  Disk  Drive）、光ディスク、メモリカード、ＲＡＭ（Random  Access  Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。記憶部は、物理的に異なる記憶媒体としてもよいし、物理的に同一の記憶媒体の異なる記憶領域として実現してもよい。さらに記憶部のそれぞれは、物理的に異なる複数の記憶媒体により実現してもよい。
【００５３】
以下、本実施形態による通信処理の詳細についてさらに説明する。暗号データ通信セッションを開始する側のアプリケーション２０をマスターと呼び、暗号データ通信セッションを受け付ける側のアプリケーション２０をスレーブと呼ぶこととする。グローバルキーの取得要求を、ウェブＡＰＩによって実現する場合、当該ウェブＡＰＩは、例えば図６のように定義される。図６は、ウェブＡＰＩの一例を示す図である。なお、図６に示すＡＰＩは一例であり、その他のどのような形式のメッセージを用いてもよい。
【００５４】
１番目のＡＰＩは、アプリケーション２０が暗号鍵を取得するためではなく、アプリケーション２０がノード１０または通信システムの状態を問い合わせるために用いられる。“｛hostname｝”は、状態を問い合わせる宛先となるノード１０を指定する情報である。
【００５５】
２番目のＡＰＩは、マスターとなるアプリケーション２０がノード１０から鍵を取得するためのＡＰＩ（暗号鍵を要求する要求メッセージの一例）である。“｛アプリＩＤ｝”は、ＡＰＩを呼び出すアプリケーション（マスター）の通信相手となるアプリケーション２０（スレーブ）のアプリＩＤである。マスターとなるアプリケーション２０は、ＡＰＩでノード１０に対して暗号鍵の個数を指定する。ノード１０は、暗号鍵および鍵ＩＤをマスターとなるアプリケーション２０に応答する。
【００５６】
３番目のＡＰＩは、スレーブとなるアプリケーション２０がノード１０から鍵を取得するためのＡＰＩである。“｛アプリＩＤ｝”は、ＡＰＩを呼び出すアプリケーション（スレーブ）の通信相手となるアプリケーション２０（マスター）のアプリＩＤである。スレーブとなるアプリケーション２０は、ＡＰＩ呼び出しにより、ノード１０に対して取得する暗号鍵の鍵ＩＤを指定する。ノード１０は、指定された暗号鍵および鍵ＩＤをスレーブとなるアプリケーション２０に応答する。
【００５７】
２番目および３番目のＡＰＩの応答で提供する暗号鍵は、どのようなデータフォーマットであってもよい。暗号鍵は、例えばＪＳＯＮ（JavaScript（登録商標）  Object  Notation）フォーマットで定義することができる。図７は、暗号鍵および鍵ＩＤをＪＳＯＮ（JavaScript  Object  Notation）フォーマットで定義する場合の例を示す図である。図７では、鍵ＩＤ（key  ID）と、Ｂａｓｅ６４エンコードされた鍵データである“key”と、の組み合わせのリストとして、表現されている。
【００５８】
アプリケーション２０は、図６に示すようなＡＰＩを用いて暗号鍵を取得し、取得した暗号鍵を用いて任意の他のアプリケーション２０との間で、任意の暗号通信を行うことができる。
【００５９】
続いて、ウェブＡＰＩにおけるレート制限について説明する。ここでは２つの例を挙げる。
【００６０】
第１の例は、ＲＦＣ６５８５で規定されているステータスコードである“HTTP  status  code  429:  Too  Many  Requests”を利用する方法である。ＡＰＩの呼び出し要求を受けたサーバは、呼び出し元であるクライアントに対してＡＰＩ呼び出しを制限する場合、“HTTP  status  code  429:  Too  Many  Requests”をステータスコードとして示すＨＴＴＰ（Hypertext  Transfer  Protocol）レスポンスを返す。
【００６１】
サーバは、このＨＴＴＰレスポンスの中で、“Retry-Afterヘッダ”によって、クライアントが待つべき時間の長さ（秒）、または、再試行までに待つべき絶対時間を指定する。
【００６２】
図８および図９は、第１の例におけるＨＴＴＰレスポンスのヘッダ例を示す図である。図８は、サーバがクライアントに対し、３６００秒後以降に再試行すべきであることを通知する場合の例である。図９は、サーバがクライアントに対し、“Fri,  31  Dec  1999  23:59:59  GMT”以降に再試行すべきであることを通知する場合の例である。
【００６３】
第２の例は、非特許文献１に記載されているウェブＡＰＩ等を利用する方法である。ＡＰＩの呼び出し要求を受けたサーバは、呼び出し元であるクライアントに対して応答（ＨＴＴＰレスポンス）を返すときに、“X-RateLimit-Limit”、および、“X-RateLimit-Remaining”等のＨＴＴＰヘッダを用いて、単位時間あたりのＡＰＩ呼び出し可能回数を通知する。このときのＨＴＴＰレスポンスは、“200  OK”等の正常応答でよい。
【００６４】
図１０および図１１は、第２の例におけるＨＴＴＰレスポンスのヘッダ例を示す図である。図１０は、単位時間あたり最大６０回のＡＰＩ呼び出しが許可され、ＡＰＩ呼び出し可能な残りの回数が５６回であり、“1372700873  UTC  epoch  second”の時間が経過するとＡＰＩ呼び出し回数がリセットされることを示す例である。図１１は、ＡＰＩ呼び出しが、設定されたレート制限を超過した場合に返されるＨＴＴＰレスポンス（エラー応答）を示す例である。
【００６５】
このように、アプリケーション２０とノード１０との間で送受信する要求メッセージおよび応答メッセージ（鍵提供メッセージ）は、ＨＴＴＰに基づくウェブＡＰＩで実現できる。
【００６６】
次に、本実施形態によるＡＰＩのレート制限について詳細に説明する。本実施形態では、量子鍵配送技術を用いて共有された暗号鍵をノード１０からアプリケーション２０へと提供する鍵提供ＡＰＩにおいて、ＡＰＩ呼び出し元のアプリケーション２０に対して提供可能な暗号鍵の量を、上記のようなＡＰＩのレート制限の手法を用いて提供し、かつ、ＡＰＩの呼び出しを制限する。
【００６７】
ＡＰＩの呼び出しを制限するために利用するパラメータとしては、以下のようなパラメータを用いることができる。すなわち算出部１０３は、以下のようなパラメータを参照して、要求メッセージの呼び出しを制限する制限情報を算出する。
・アプリケーション２０が要求している暗号鍵の共有速度、および、暗号鍵の蓄積量（共有速度および蓄積量の変動）
・接続されているアプリケーション２０の数
・接続されているアプリケーション２０、および、接続されているアプリケーション２０と通信する他のアプリケーション２０の優先度
・接続されているアプリケーション２０、および、接続されているアプリケーション２０と通信する他のアプリケーション２０が要求する暗号鍵のサイズ
・接続されているアプリケーション２０に過去に提供された暗号鍵の量
・接続されているアプリケーション２０、および、接続されているアプリケーション２０と通信する他のアプリケーション２０の認証結果
・ノード１０の処理負荷
【００６８】
過去に提供された暗号鍵の量は、暗号鍵の要求履歴などから算出してもよい。認証結果は、認証されたか否かであってもよいし、認証のレベルを表す情報（認証レベル）であってもよい。
【００６９】
算出部１０３は、例えば、状態記憶部１２１、鍵記憶部１２２、および、鍵共有部１０４から、暗号鍵の共有状況、暗号鍵の蓄積状況、および、アプリケーション２０の状態などの上記パラメータの値を収集し、レート制限を行うための制限情報を算出する。
【００７０】
制限情報は、例えば、単位時間あたりに要求メッセージを呼び出し可能な回数の最大値、および、単位時間あたりに要求メッセージを呼び出し可能な残りの回数のうち少なくとも一方を含む。非特許文献１の方法を適用する場合、算出部１０３は、ＨＴＴＰヘッダに付加する情報である、“X-RateLimit-Limit”、“X-RateLimit-Remaining”、および、“X-RateLimit-Reset”等の値を制限情報として算出してもよい。算出部１０３は、例えば通信制御部１０１にアクセスして、算出した制限情報をＨＴＴＰヘッダに付加する。
【００７１】
判定部１０２は、例えば“X-RateLimit-Limit”および“X-RateLimit-Remaining”などを参照して、要求メッセージを呼び出す頻度の制限を超えたか否かを判定する。判定部１０２は、判定結果を通信制御部１０１に通知して、要求メッセージの送信元のアプリケーション２０に判定結果を送信させる。
【００７２】
次に、ウェブＡＰＩを呼び出すアプリケーション２０と、ウェブＡＰＩにより応答するノード１０との間のメッセージシーケンスを説明する。図１２は、第１の実施形態による通信処理の一例を示すシーケンス図である。図１２は、アプリケーション２０からの暗号鍵の要求メッセージに対し、ノード１０が鍵提供メッセージ（鍵あり）を送信する例である。図１２は、要求メッセージのＨＴＴＰヘッダと鍵提供メッセージのＨＴＴＰヘッダの例も示している。
【００７３】
まずアプリケーション２０は、暗号鍵の要求メッセージをノード１０に対して送信する（ステップＳ１０１）。この要求メッセージは、例えば図６の２番目のＡＰＩの形式とすることができる。ノード１０の算出部１０３は、アプリケーション２０からの要求メッセージを受け取ると、要求されている暗号鍵の蓄積量、要求されている暗号鍵の数、および、接続している他のアプリケーション２０の数などの上述のパラメータの値を参照して、制限情報を算出する（ステップＳ１０２）。算出部１０３は、通信制御部１０１に対して、鍵提供メッセージのＨＴＴＰヘッダに制限情報の付加を指示する（ステップＳ１０３）。通信制御部１０１は、制限情報を付加した鍵提供メッセージを、暗号鍵を要求したアプリケーション２０に送信する（ステップＳ１０４）。
【００７４】
制限情報は、例えば“X-RateLimit-Limit”、“X-RateLimit-Remaining”、および、“X-RateLimit-Reset”である。ノード１０の算出部１０３は、上述のパラメータを参照することによってこれらの制限情報を算出し、鍵提供メッセージに付加する。
【００７５】
“X-RateLimit-Limit”は、例えば以下のように算出できる。まず算出部１０３は、要求された暗号鍵の共有速度を、暗号鍵を必要としている、現在接続しているアプリケーション２０の数で割った値を算出する。算出部１０３は、得られた値を、暗号鍵を要求したアプリケーション２０が過去のＡＰＩ呼び出しで一度に取得した暗号鍵の数でさらに割ることにより、“X-RateLimit-Limit”を算出する。
【００７６】
なお、“X-RateLimit-Limit”の算出方法はこれに限られるものではない。算出部１０３は、例えば、アプリケーション２０の優先度または認証レベルで重みをつけて制限情報を算出する方法、および、暗号鍵の蓄積量をさらに考慮する方法などを用いてもよい。
【００７７】
算出部１０３は、例えば優先度が高いアプリケーション２０ほど、“X-RateLimit-Limit”の値を大きくする。また算出部１０３は、例えば暗号鍵のサイズが大きいほど“X-RateLimit-Limit”の値を大きくする。また算出部１０３は、例えば暗号鍵を要求したアプリケーション２０に対して過去に提供された暗号鍵の量が大きいほど“X-RateLimit-Limit”の値を大きくする。また算出部１０３は、例えば認証レベルが高いほど“X-RateLimit-Limit”の値を大きくする。また算出部１０３は、例えばノード１０の処理負荷が小さいほど“X-RateLimit-Limit”の値を大きくする。
【００７８】
図１３は、第１の実施形態による通信処理の他の例を示すシーケンス図である。図１３は、アプリケーション２０からの要求メッセージに対して、該当アプリケーション２０がレート制限を越えたとノード１０が判定し、鍵提供メッセージ（エラー応答、鍵なし）を応答する例を示す。
【００７９】
まずアプリケーション２０は、暗号鍵の要求メッセージをノード１０に対して送信する（ステップＳ２０１）。ノード１０の判定部１０２は、アプリケーション２０からの要求メッセージを受け取ると、要求メッセージを呼び出す頻度の制限を超えたか否かを判定する（ステップＳ２０２）。なおこの判定処理は、図１２のステップＳ１０２の前に実行されてもよい。例えば、要求メッセージを呼び出す頻度の制限を超えていないと判定された場合に、ステップＳ１０２の算出処理が実行されてもよい。
【００８０】
図１３の例では、判定部１０２が要求メッセージを呼び出す頻度の制限を超えたと判定したと仮定する。この場合、通信制御部１０１は、制限を超えたことを示すエラーメッセージをアプリケーション２０に送信する（ステップＳ２０３）。
【００８１】
図１３に示すように、この応答メッセージ（エラーメッセージ）のＨＴＴＰヘッダには、“Retry-After”ヘッダが付加されている。ノード１０は、“Retry-After”ヘッダにより、ＡＰＩ呼び出しの再試行までに待つべき時間をアプリケーション２０に通知する。ノード１０の判定部１０２は、例えば上述のパラメータの値を参照して、“Retry-After”ヘッダに設定する時間を算出する。“Retry-After”ヘッダに設定される値は、要求メッセージを次に呼び出し可能となるタイミングを示す情報に相当する。
【００８２】
例えば判定部１０２は、状態記憶部１２１、鍵記憶部１２２、および、鍵共有部１０４から、暗号鍵の共有状況、暗号鍵の蓄積状況、および、アプリケーション２０の状態などの上記パラメータの値を収集する。判定部１０２は、収集した値を参照して、暗号鍵を要求したアプリケーション２０に対して、暗号鍵を提供可能となる時間を予測し、“Retry-After”ヘッダに設定する時間として算出する。
【００８３】
このように、第１の実施形態では、アプリケーションが暗号鍵を要求したときに、制限情報を付加した応答メッセージを返す。このような方式は、例えば図６の１番目のＡＰＩなどを用いてアプリケーションが明示的に制限情報を要求する方式と比較すると、アプリケーションとノード間の通信回数が削減可能になる。
【００８４】
また、第１の実施形態では、アプリケーションが例えば非特許文献１に記載されているウェブＡＰＩを処理可能であれば、さらにアプリケーション側の機能を拡張（改変）する必要がない。
【００８５】
第１の実施形態は、ノードにおける暗号鍵の状況を考慮してＡＰＩの呼び出しを制限する。一方、ＡＰＩには、図６の１番目のＡＰＩのように、必ずしも暗号鍵を提供しないＡＰＩも存在する。ＡＰＩの種類によらずにＡＰＩの呼び出しを制限するように構成した場合は、暗号鍵の量に起因してＡＰＩの呼び出し制限が有効になった結果、暗号鍵を提供しないＡＰＩについても呼び出し制限が働くことになる。
【００８６】
（第２の実施形態）
第２の実施形態は、非特許文献１などの従来の方式とは異なる形式のＨＴＴＰヘッダを新たに定義し、ノードからアプリケーションに対してレート制限の情報をより具体的に通知する。
【００８７】
図１４は、第２の実施形態にかかるノード１０−２の構成の一例を示すブロック図である。図１４に示すように、ノード１０−２は、通信Ｉ／Ｆ１１１、１１２と、状態記憶部１２１と、鍵記憶部１２２と、通信制御部１０１と、判定部１０２−２と、算出部１０３−２と、鍵共有部１０４と、を備えている。
【００８８】
第２の実施形態では、判定部１０２−２および算出部１０３−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかるノード１０のブロック図である図５と同様であるので、同一符号を付し、ここでの説明は省略する。
【００８９】
算出部１０３−２は、第１の実施形態と異なる形式の制限情報を算出する。判定部１０２−２は、第１の実施形態と異なる形式の制限情報を用いて、制限情報が示す制限が満たされているかを判定する。制限情報は、例えば、単位時間あたりに要求メッセージに応じて提供可能な暗号鍵の最大値、および、単位時間あたりに要求メッセージに応じて提供可能な残りの暗号鍵の量のうち少なくとも一方を含む。本実施形態の制限情報の例については後述する。
【００９０】
図１５は、第２の実施形態による通信処理の一例を示すシーケンス図である。図１５は、アプリケーション２０−２からの鍵要求メッセージに対し、ノード１０−２が鍵提供メッセージ（鍵あり）を応答する例を示す。なお第２の実施形態では、アプリケーション２０−２は、第１の実施形態と異なる形式の制限情報を使用できるように機能が拡張される。
【００９１】
ステップＳ３０１〜ステップＳ３０４の流れは、図１２のステップＳ１０１〜ステップＳ１０４と同様である。図１５では、ヘッダに付加する制限情報の形式が図１２と異なる。
【００９２】
図１５に示すように、ノード１０−２の算出部１０３−２は、要求メッセージを受け取ると、上述のパラメータの値を参照して、“X-RateLimit-Limit-keybits”、“X-RateLimit-Remaining-keybits”、および、“X-RateLimit-keybits-Reset”を制限情報として算出する（ステップＳ３０２）。
【００９３】
これらの制限情報は、本実施形態にて新たに導入するＨＴＴＰヘッダである。“X-RateLimit-Limit-keybits”は、例えば、暗号鍵を要求するアプリケーション２０−２が単位時間あたりに利用可能な暗号鍵の最大量（ビット単位）を表す。“X-RateLimit-Remaining-keybits”は、例えば、暗号鍵を要求するアプリケーション２０−２が単位時間あたりに利用可能な、残りの暗号鍵の量（ビット単位）を表す。“X-RateLimit-keybits-Reset”は、例えば、利用可能な暗号鍵の量がリセットされるまでに必要な経過時間を表す。
【００９４】
通信制御部１０１は、これらの制限情報を付加した鍵提供メッセージを、暗号鍵を要求したアプリケーション２０−２に送信する（ステップＳ３０４）。
【００９５】
算出部１０３−２は、例えば、要求された暗号鍵の共有速度を、暗号鍵を必要としている、現在接続しているアプリケーション２０−２の数で割った値を、“X-RateLimit-Limit-keybits”として算出する。
【００９６】
なお、“X-RateLimit-Limit-keybits”の算出方法はこれに限られるものではない。算出部１０３−２は、例えば、アプリケーション２０−２の優先度または認証レベルで重みをつけて制限情報を算出する方法、および、暗号鍵の蓄積量をさらに考慮する方法などを用いてもよい。
【００９７】
算出部１０３−２は、“X-RateLimit-Limit-keybits”から、暗号鍵を要求したアプリケーション２０−２が単位時間内にＡＰＩを呼び出した履歴（提供した暗号鍵の量の実績）を減じることによって“X-RateLimit-Remaining-keybits”を算出してもよい。
【００９８】
図１６は、第２の実施形態による通信処理の他の例を示すシーケンス図である。図１６は、アプリケーション２０−２からの要求メッセージに対して、該当アプリケーション２０−２がレート制限を越えたとノード１０−２が判定し、鍵提供メッセージ（エラー応答、鍵なし）を応答する例を示す。
【００９９】
まずアプリケーション２０−２は、暗号鍵の要求メッセージをノード１０−２に対して送信する（ステップＳ４０１）。ノード１０−２の判定部１０２−２は、アプリケーション２０−２からの要求メッセージを受け取ると、制限情報が示す制限を超えたか否かを判定する（ステップＳ４０２）。判定部１０２−２は、例えば、要求された暗号鍵の量（ビット単位）が、“X-RateLimit-Remaining-keybits”を超えていないか判定する。なおこの判定処理は、図１５のステップＳ３０２の前に実行されてもよい。例えば、制限情報が示す制限を超えていると判定された場合に、ステップＳ３０２の算出処理が実行されてもよい。
【０１００】
図１６の例では、判定部１０２−２が、制限情報が示す制限を超えたと判定したと仮定する。この場合、通信制御部１０１は、制限を超えたことを示すエラーメッセージをアプリケーション２０−２に送信する（ステップＳ４０３）。
【０１０１】
図１６に示すように、この応答メッセージ（エラーメッセージ）のＨＴＴＰヘッダには、“Retry-After”ヘッダが付加されている。ノード１０−２は、“Retry-After”ヘッダにより、ＡＰＩ呼び出しの再試行までに待つべき時間をアプリケーション２０−２に通知する。ノード１０−２の判定部１０２−２は、例えば上述のパラメータの値を参照して、“Retry-After”ヘッダに設定する時間を算出する。
【０１０２】
第２の実施形態では、第１の実施形態と異なり、アプリケーション２０−２の機能拡張が必要となる。すなわち、アプリケーション２０−２は、“X-RateLimit-Limit-keybits”、“X-RateLimit-Remaining-keybits”、および、“X-RateLimit-keybits-Reset”などの新たなヘッダを解釈できるように改変する必要がある。
【０１０３】
一方、第２の実施形態では、暗号鍵の提供を行うＡＰＩ（例えば図６の２番目および３番目）だけに対して、呼び出し制限を適用することが可能となる。すなわち、暗号鍵の提供を行うＡＰＩ（例えば図６の２番目および３番目）と、暗号鍵の提供を行わないＡＰＩ（例えば図６の１番目）とに対して、同一の呼び出し制限が適用されなくなる。
【０１０４】
鍵の提供を行わないＡＰＩ（例えば図６の１番目）と、暗号鍵の提供を行うＡＰＩ（例えば図６の２番目および３番目）と、を独立に呼び出し制限するには、例えば以下の変形例１のような別の機能が必要となる。
【０１０５】
（変形例１）
変形例１は、上述の第１の例または第２の例のようなレート制限のためのステータスコード、または、ＨＴＴＰヘッダを利用するとともに、第２の実施形態で新たに定義したＨＴＴＰヘッダを利用する。
【０１０６】
図１７は、変形例１による通信処理の一例を示すシーケンス図である。図１７は、アプリケーション２０−２からの暗号鍵の要求メッセージに対し、ノード１０−２が鍵提供メッセージ（鍵あり）を応答する例を示す。
【０１０７】
ステップＳ５０１〜ステップＳ５０４の流れは、図１５のステップＳ３０１〜ステップＳ３０４と同様である。図１７では、ヘッダに付加する制限情報の形式が図１５と異なる。すなわち、本変形例では、“X-RateLimit-Limit”、“X-RateLimit-Remaining”、および、“X-RateLimit-Reset”が制限情報として追加される。
【０１０８】
本変形例では、“X-RateLimit-Limit”、“X-RateLimit-Remaining”、および、“X-RateLimit-Reset”は、暗号鍵の共有速度および蓄積量とは無関係に算出される。例えばこれらの制限情報は、ノード１０−２の処理負荷、アプリケーション２０−２の認証レベル、および、アプリケーション２０−２の接続数などに応じたウェブＡＰＩのレート制限のために用いられる。
【０１０９】
本変形例では、これらの制限情報とともに、第２の実施形態で新たに導入したＨＴＴＰヘッダである“X-RateLimit-Limit-keybits”、“X-RateLimit-Remaining-keybits”、“X-RateLimit-keybits-Reset”が用いられる。これにより、第２の実施形態と同様に、暗号鍵の情報をより具体的にアプリケーション２０−２に通知可能となる。本変形例のように構成することで、一般的なウェブＡＰＩにおけるレート制限と、暗号鍵の共有速度や残量などの本実施形態特有の環境に起因するレート制限とを同時に独立に設定することが可能となる。
【０１１０】
（変形例２）
上記各実施形態で、アプリケーション（アプリケーションを備える情報処理装置）が、ノードから通知された制限情報に基づき、自装置の通信を制御するように構成してもよい。例えば、アプリケーションは、通知された“X-RateLimit-Limit”、および、“X-RateLimit-Remaining”を参照し、暗号鍵を要求する要求メッセージを含むメッセージの送信回数を制御してもよい。
【０１１１】
以上説明したとおり、第１および第２の実施形態によれば、暗号鍵の共有速度、および、暗号鍵の蓄積量などに応じて、アプリケーションに提供する暗号鍵の量を制限することができる。
【０１１２】
次に、第１および第２の実施形態にかかる通信装置のハードウェア構成について図１８を用いて説明する。図１８は、第１および第２の実施形態にかかる通信装置のハードウェア構成例を示す説明図である。
【０１１３】
第１および第２の実施形態にかかる通信装置は、ＣＰＵ５１などの制御装置と、ＲＯＭ（Read  Only  Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。
【０１１４】
第１および第２の実施形態にかかる通信装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。
【０１１５】
第１および第２の実施形態にかかる通信装置で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact  Disk  Recordable）、ＤＶＤ（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【０１１６】
さらに、第１および第２の実施形態にかかる通信装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１および第２の実施形態にかかる通信装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１１７】
第１および第２の実施形態にかかる通信装置で実行されるプログラムは、コンピュータを上述した通信装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【０１１８】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１１９】
１０、１０−２  ノード
２０、２０−２  アプリケーション
１０１  通信制御部
１０２、１０２−２  判定部
１０３、１０３−２  算出部
１０４  鍵共有部
１１１、１１２  通信Ｉ／Ｆ
１２１  状態記憶部
１２２  鍵記憶部
【図１】
2019050453.tif 000003
【図２】
2019050453.tif 000004
【図３】
2019050453.tif 000005
【図４】
2019050453.tif 000006
【図５】
2019050453.tif 000007
【図６】
2019050453.tif 000008
【図７】
2019050453.tif 000009
【図８】
2019050453.tif 000010
【図９】
2019050453.tif 000011
【図１０】
2019050453.tif 000012
【図１１】
2019050453.tif 000013
【図１２】
2019050453.tif 000014
【図１３】
2019050453.tif 000015
【図１４】
2019050453.tif 000016
【図１５】
2019050453.tif 000017
【図１６】
2019050453.tif 000018
【図１７】
2019050453.tif 000019
【図１８】
2019050453.tif 000020