知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023136740
(43)【公開日】2023-09-29
(54)【発明の名称】鍵管理装置、量子暗号通信システム及びプログラム
(51)【国際特許分類】
H04L 9/12 20060101AFI20230922BHJP
H04L 9/18 20060101ALI20230922BHJP
【ＦＩ】
H04L9/12
H04L9/18
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2022042596
(22)【出願日】2022-03-17
【国等の委託研究の成果に係る記載事項】（出願人による申告）令和２年度、総務省「グローバル量子暗号通信網構築のための研究開発」に関する委託研究（ＪＰＭＩ００３６１）、産業技術力強化法第１７条の適用を受ける特許出願
(71)【出願人】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】兪 ユ
(72)【発明者】
【氏名】勝部 泰弘
(72)【発明者】
【氏名】谷澤 佳道
(72)【発明者】
【氏名】高橋 莉里香
(72)【発明者】
【氏名】藤吉 靖浩
(57)【要約】
【課題】ＱＫＤネットワークにおいて、アプリケーション鍵を共有するための最適な鍵リレー経路を決定する。
【解決手段】実施形態の鍵管理装置は、複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理する鍵管理装置である。前記鍵管理装置は、収集部と算出部と決定部と通信部とを備える。収集部は、ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する。算出部は、前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する。決定部は、複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する。通信部は、前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する。
【選択図】図１
【解決手段】実施形態の鍵管理装置は、複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理する鍵管理装置である。前記鍵管理装置は、収集部と算出部と決定部と通信部とを備える。収集部は、ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する。算出部は、前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する。決定部は、複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する。通信部は、前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理する鍵管理装置であって、
前記鍵管理装置は、
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部と、
を備える鍵管理装置。
前記鍵管理装置は、
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部と、
を備える鍵管理装置。
【請求項2】
前記リソース情報は、前記リンクにおける前記リンク鍵の生成速度、及び、前記リンクにおける前記リンク鍵の保有量の少なくとも一方を含み、
前記算出部は、前記リンク鍵の生成速度、及び、前記リンク鍵の保有量の少なくとも一方に基づき、前記メトリックを算出する、
請求項１に記載の鍵管理装置。
前記算出部は、前記リンク鍵の生成速度、及び、前記リンク鍵の保有量の少なくとも一方に基づき、前記メトリックを算出する、
請求項１に記載の鍵管理装置。
【請求項3】
前記算出部は、前記鍵リレー経路のホップ数を更に算出し、前記ホップ数に更に基づいて前記メトリックを算出する、
請求項１又は２に記載の鍵管理装置。
請求項１又は２に記載の鍵管理装置。
【請求項4】
前記算出部は、前記鍵リレー経路に含まれる複数のリンクのリソース情報のボトルネックに基づく第１のメトリックと、前記ホップ数に反比例する第２のメトリックとを算出し、
前記決定部は、前記第１のメトリックが同じである前記鍵リレー経路が複数ある場合、前記第２のメトリックに更に基づいて鍵リレー経路を決定する、
請求項３に記載の鍵管理装置。
前記決定部は、前記第１のメトリックが同じである前記鍵リレー経路が複数ある場合、前記第２のメトリックに更に基づいて鍵リレー経路を決定する、
請求項３に記載の鍵管理装置。
【請求項5】
前記算出部は、前記鍵リレー経路に含まれる複数のリンクのリソース情報のボトルネックに基づく第１のメトリックと、前記ホップ数に反比例する第２のメトリックとを算出し、
前記決定部は、前記第２のメトリックが同じである前記鍵リレー経路が複数ある場合、前記第１のメトリックに更に基づいて鍵リレー経路を決定する、
請求項３に記載の鍵管理装置。
前記決定部は、前記第２のメトリックが同じである前記鍵リレー経路が複数ある場合、前記第１のメトリックに更に基づいて鍵リレー経路を決定する、
請求項３に記載の鍵管理装置。
【請求項6】
前記収集部は、前記リンクの状態を示す状態情報を更に収集し、
前記算出部は、前記鍵リレー経路の状態情報を、前記鍵リレー経路に含まれるリンクの状態情報に基づいて算出し、
前記決定部は、前記鍵リレー経路の状態情報が閾値より小さい鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定し、前記鍵リレー経路の状態情報が閾値以上の鍵リレー経路は、異常経路であると判定する、
請求項１乃至５のいずれか１項に記載の鍵管理装置。
前記算出部は、前記鍵リレー経路の状態情報を、前記鍵リレー経路に含まれるリンクの状態情報に基づいて算出し、
前記決定部は、前記鍵リレー経路の状態情報が閾値より小さい鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定し、前記鍵リレー経路の状態情報が閾値以上の鍵リレー経路は、異常経路であると判定する、
請求項１乃至５のいずれか１項に記載の鍵管理装置。
【請求項7】
前記リンクの状態情報は、前記リンクのＱＢＥＲ（Ｑｕａｎｔｕｍ Ｂｉｔ Ｅｒｒｏｒ Ｒａｔｅ）である、
請求項６に記載の鍵管理装置。
請求項６に記載の鍵管理装置。
【請求項8】
前記鍵管理装置は、ＱＫＤネットワークに含まれる複数のドメインのいずれかに属し、
前記鍵管理装置が属するドメインの情報を示す内部情報を記憶する内部情報記憶部と、
前記鍵管理装置が属さないドメインの情報を示す外部情報を記憶する外部情報記憶部と、を更に備え、
前記内部情報は、前記鍵管理装置が属するドメインに含まれるリンクの前記リソース情報を少なくとも含み、
前記外部情報は、前記鍵管理装置が属さないドメインに含まれるリンクの前記リソース情報を少なくとも含む、
請求項１乃至７のいずれか１項に記載の鍵管理装置。
前記鍵管理装置が属するドメインの情報を示す内部情報を記憶する内部情報記憶部と、
前記鍵管理装置が属さないドメインの情報を示す外部情報を記憶する外部情報記憶部と、を更に備え、
前記内部情報は、前記鍵管理装置が属するドメインに含まれるリンクの前記リソース情報を少なくとも含み、
前記外部情報は、前記鍵管理装置が属さないドメインに含まれるリンクの前記リソース情報を少なくとも含む、
請求項１乃至７のいずれか１項に記載の鍵管理装置。
【請求項9】
前記収集部は、前記ＱＫＤネットワークに属する他の鍵管理装置の前記内部情報記憶部に記憶された前記リソース情報を収集し、
前記外部情報記憶部は、前記他の鍵管理装置の前記内部情報記憶部に記憶された前記リソース情報を記憶する、
請求項８に記載の鍵管理装置。
前記外部情報記憶部は、前記他の鍵管理装置の前記内部情報記憶部に記憶された前記リソース情報を記憶する、
請求項８に記載の鍵管理装置。
【請求項10】
複数の鍵管理装置を備える量子暗号通信システムであって、
前記複数の鍵管理装置は、複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理し、
前記鍵管理装置は、
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部と、
を備える量子暗号通信システム。
前記複数の鍵管理装置は、複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理し、
前記鍵管理装置は、
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部と、
を備える量子暗号通信システム。
【請求項11】
前記鍵管理装置は、ＱＫＤネットワークに含まれる複数のドメインのいずれかに属し、
前記鍵管理装置が属するドメインの情報を示す内部情報を記憶する内部情報記憶部と、
前記鍵管理装置が属さないドメインの情報を示す外部情報を記憶する外部情報記憶部と、を更に備え、
前記内部情報は、前記鍵管理装置が属するドメインに含まれるリンクの前記リソース情報を少なくとも含み、
前記外部情報は、前記鍵管理装置が属さないドメインに含まれるリンクの前記リソース情報を少なくとも含む、
請求項１０に記載の量子暗号通信システム。
前記鍵管理装置が属するドメインの情報を示す内部情報を記憶する内部情報記憶部と、
前記鍵管理装置が属さないドメインの情報を示す外部情報を記憶する外部情報記憶部と、を更に備え、
前記内部情報は、前記鍵管理装置が属するドメインに含まれるリンクの前記リソース情報を少なくとも含み、
前記外部情報は、前記鍵管理装置が属さないドメインに含まれるリンクの前記リソース情報を少なくとも含む、
請求項１０に記載の量子暗号通信システム。
【請求項12】
複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理するコンピュータを、
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部、
として機能させるためのプログラム。
ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する収集部と、
前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する算出部と、
複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する決定部と、
前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する通信部、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は鍵管理装置、量子暗号通信システム及びプログラムに関する。
【背景技術】
【0002】
量子鍵配送（ＱＫＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）では、鍵共有ネットワークの中の鍵管理装置（ＫＭ：Ｋｅｙ Ｍａｎａｇｅｒ）間でアプリケーション鍵を共有するための鍵リレー経路決定、すなわち、複数のＫＭを介したアプリケーション鍵の転送が行われる。大規模な鍵共有ネットワークでは、鍵共有ネットワークの管理を効率化し、鍵共有ネットワークの管理を容易にするため、鍵共有ネットワークが、複数のドメインに分割されることが一般的である。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１７－９２９８７号公報
【特許文献2】特許第６４２６４７７号公報
【非特許文献】
【0004】
【非特許文献1】ＩＥＴＦ，“Ａ Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ ４ （ＢＧＰ－４）” ＲＦＣ－４２７１，２０１６．
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来の技術では、ＱＫＤネットワークにおいて、アプリケーション鍵を共有するための最適な鍵リレー経路を決定することが難しかった。
【課題を解決するための手段】
【0006】
実施形態の鍵管理装置は、複数のアプリケーションにより構成されるアプリケーションネットワークの通信を暗号化するアプリケーション鍵を管理する鍵管理装置である。前記鍵管理装置は、収集部と算出部と決定部と通信部とを備える。収集部は、ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する。算出部は、前記リンクを含む鍵リレー経路のメトリックを、前記リソース情報に基づいて算出する。決定部は、複数の鍵リレー経路から、前記メトリックに基づいて、鍵リレー経路を決定する。通信部は、前記リンク鍵により暗号化されたアプリケーション鍵を、前記決定部により決定された鍵リレー経路を使用して、宛先に送信する。
【図面の簡単な説明】
【0007】
【図1】実施形態の量子暗号通信システムの構成の例を示す図。
【図2】実施形態のＢＫＭの機能構成の例を示す図。
【図3A】実施形態のメトリックの例１を示す図。
【図3B】実施形態のメトリックの例２を示す図。
【図3C】実施形態の鍵リレー経路の状態の例を示す図。
【図4】実施形態の鍵リレー経路の決定方法の例を説明するための図。
【図5】実施形態の鍵リレー経路の状態を更に考慮した鍵リレー経路の決定方法の例を説明するための図。
【図6】実施形態の内部情報記憶部に記憶される鍵リレー経路属性情報の例を示す図。
【図7】実施形態のＢＧＰ関連情報の例を示す図。
【図8】実施形態の鍵リレー経路属性情報の共有方法の例を説明するための図。
【図9】実施形態の外部情報記憶部に記憶される鍵リレー経路属性情報の例を示す図。
【図10】実施形態の鍵リレー経路の決定処理の例を示すフローチャート。
【図11】実施形態の鍵リレー経路の決定例を示す図。
【図12】実施形態の変形例１について説明するための図。
【図13】実施形態の変形例２について説明するための図。
【図14】実施形態の変形例３について説明するための図。
【図15】実施形態のＫＭ、ＢＫＭ及びＱＫＤコントローラのハードウェア構成の例を示す図。
【発明を実施するための形態】
【0008】
以下に添付図面を参照して、鍵管理装置、量子暗号通信システム及びプログラムの実施形態を詳細に説明する。
【0009】
［量子暗号通信システムの構成の例］
図１は実施形態の量子暗号通信システムの構成の例を示す図である。図１の量子暗号通信システムは、マルチドメイン鍵共有ネットワークとして、複数のＱＫＤネットワーク鍵共有ドメイン（ＱＫＤＮ ＫＳＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ Ｋｅｙ Ｓｈａｒｉｎｇ Ｄｏｍａｉｎ）１００－１～１００－４を含む。
図１は実施形態の量子暗号通信システムの構成の例を示す図である。図１の量子暗号通信システムは、マルチドメイン鍵共有ネットワークとして、複数のＱＫＤネットワーク鍵共有ドメイン（ＱＫＤＮ ＫＳＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ Ｋｅｙ Ｓｈａｒｉｎｇ Ｄｏｍａｉｎ）１００－１～１００－４を含む。
【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】
上記各部（制御部１、管理部２、プラットフォーム部３、通信部４、収集部７、算出部８及び決定部９）は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの制御装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。また、記憶部６は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、光ディスク、メモリカード、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【0044】
［アプリケーション鍵の共有処理］
ＱＫＤＮ ＫＳＤ１００－１～１００－４におけるアプリケーション鍵の共有処理の一例について説明する。全体の流れとしては、まず、ＫＭの通信部４は、隣接するＫＭとの間でリンク鍵を生成する。次に、各ＫＭの処理部５は、任意のＫＭとの間でアプリケーション鍵を共有するための鍵リレー経路の決定を行う。そして、各ＫＭの通信部４は、決定された経路に従い、各リンクでリンク鍵を用いて暗号化・復号を繰り返しながらアプリケーション鍵を宛先ＫＭまで共有（転送）する。
ＱＫＤＮ ＫＳＤ１００－１～１００－４におけるアプリケーション鍵の共有処理の一例について説明する。全体の流れとしては、まず、ＫＭの通信部４は、隣接するＫＭとの間でリンク鍵を生成する。次に、各ＫＭの処理部５は、任意のＫＭとの間でアプリケーション鍵を共有するための鍵リレー経路の決定を行う。そして、各ＫＭの通信部４は、決定された経路に従い、各リンクでリンク鍵を用いて暗号化・復号を繰り返しながらアプリケーション鍵を宛先ＫＭまで共有（転送）する。
【0045】
次に、鍵リレー経路の決定処理の詳細について説明する。ＱＫＤＮ ＫＳＤ１００－１～１００－４を構成する各ＫＭの通信部４は、利用可能なリソース情報、および経路情報をドメイン内で相互に交換する。各ＫＭは、ほかのＫＭとの間でアプリケーション鍵を共有するための鍵リレー経路に関し、リソースのボトルネック、および、ホップ数を算出する。各ＫＭの記憶部６は、リンク鍵の共有時のＱＢＥＲを記録する。
【0046】
宛先ＫＭがドメイン内の場合、各ＫＭの決定部９は、リソースのボトルネックおよびホップ数をメトリックとして、以下の述べるアルゴリズムを用いて、鍵の生成速度が遅く、鍵保有量が少ないようなリンクの鍵枯渇を回避し、同時にドメイン内における鍵消費を抑制する鍵リレー経路を決定する。ドメイン間境界におけるＢＫＭは、ドメイン内の鍵リレー経路情報を内部情報記憶部６ｂに保存する。
【0047】
なお、ボトルネックの回避、および、ホップ数の削減は、異なるメトリックであり、これを評価する順序や重み付けにより、いくつかのバリエーションがありえる。ＫＭの決定部９は、例えば以下の（Ａ）または（Ｂ）の方法により、あるリンクのリンク鍵の枯渇を避け、ドメイン内における鍵消費を抑制する鍵リレー経路を決定する。
【0048】
（Ａ）メトリック［リソースのボトルネック］が同一の鍵リレー経路に対して、メトリック［ホップ数］を考慮した鍵リレー経路決定を行う。
【0049】
（Ｂ）ボトルネックおよびホップ数の両方を考慮した単一のメトリックを用いて鍵リレー経路決定を行う。
【0050】
アプリケーション鍵共有における特定の宛先ＫＭが送信元ＫＭ属するドメイン内に存在しない場合、送信元ＫＭの通信部４が、送信元ＫＭ属するドメイン内における各ＢＫＭに、宛先までの鍵リレー経路情報を要求する。ドメイン間における各ＢＫＭは、要求を受けて各隣接するドメインのＢＫＭへ特定の宛先ＫＭの鍵リレー経路情報共有を要求する。隣接するＢＫＭが、特定の宛先ＫＭへの鍵リレー経路情報要求を受けて、自分の内部情報記憶部６ｂに保存している最新の鍵リレー経路情報を探索する。内部情報記憶部６ｂに見つかった場合、その鍵リレー経路に関するリソース情報を要求するＢＫＭへ返信する。隣接するＢＫＭの内部情報記憶部６ｂに見つからない場合、隣接するＢＫＭが隣接するドメインのＢＫＭに継続に要求する。従って、見つかった場合、そのＢＫＭ属するドメイン内の特定の宛先ＫＭへの鍵リレー経路に関するリソース情報と、経由しているドメインの鍵リレー経路に関するリソース情報と、を要求するＢＫＭへ返信する。また、経由するドメイン数の上限値に関する設定が可能である。
【0051】
なお、内部情報記憶部６ｂに保存している鍵リレー経路情報は、シーケンス番号より更新される。ＢＫＭが鍵リレー経路情報を要求する際に、最新の鍵リレー経路情報を共有する。また、各ドメイン内のＢＫＭ間の鍵リレー経路に関するリソース情報は外部情報記憶部６ａに保存する。当然、全ての鍵リレー経路情報を同じ記憶部６に保存されてもよい。実施形態では、ドメイン内とドメイン外のプロセスを理解しやすいため、内部情報記憶部６ｂと外部情報記憶部６ａに分けて説明する。
【0052】
さらに、ドメイン間境界の複数のＢＫＭは物理的に同じ場所（トラステッドノード）に置くことを想定する。また、ＢＫＭ間の情報共有は、鍵共有に使用されるリンクに依存しない。
【0053】
また、ＱＫＤＮ ＫＳＤ１００－１～１００－４のあるリンクのＱＢＥＲが規定している閾値を超えたという非常時が発生する場合（盗聴される可能性が高いと判断する）、すぐにＢＫＭへ通知する。通知を受けたＢＫＭの決定部９は、そのリンクを含む鍵リレー経路を使用せず、ドメイン間境界におけるＢＫＭが候補経路から新な経路をすぐに再決定する。
【0054】
さらに、リソースの大きな変動が発生したことを契機としてルーティングプロトコルと鍵リレー経路の決定処理の再実行を行うように構成してもよい。
【0055】
なお、メトリックの一例としてリソースのボトルネックと鍵リレー経路のホップ数とを採用したが、それ以外の要素もメトリックとなり得る。また、メトリックの要素として１つ目にボトルネックを採用し、次の要素としてホップ数を評価したが、これらを評価する順序は逆であっても構わない。すなわち、メトリックとして鍵リレー経路のホップ数によって経路決定処理を行い、ホップ数が等しい場合にボトルネックを評価してもよい。
【0056】
具体的には、例えば、算出部８が、鍵リレー経路に含まれる複数のリンクのリソース情報のボトルネックに基づく第１のメトリックと、ホップ数に反比例する第２のメトリックとを算出する。そして、決定部９が、第１のメトリックが同じである鍵リレー経路が複数ある場合、第２のメトリックに更に基づいて鍵リレー経路を決定する。または、決定部９は、第２のメトリックが同じである鍵リレー経路が複数ある場合、第１のメトリックに更に基づいて鍵リレー経路を決定する。
【0057】
また、リソースのボトルネックと鍵リレー経路のホップ数のそれぞれを、メトリックに反映させる度合いを調整することも可能である。これは、例えばリソースのボトルネックと鍵リレー経路のホップ数とを重み付けしてメトリックを計算することで可能となる。
【0058】
リソースのボトルネックを考慮することは、アプリケーション鍵を共有する速度（スループット）、または、あるリンクにおけるリンク鍵の枯渇に関する回避性向に関係する。また、ホップ数を考慮することはシステム全体の鍵の消費量に関係する。量子暗号通信システムを適応するアプリケーションに応じて、メトリックを使い分けるとよい。
【0059】
本実施形態では、ＫＭドメイン内の経路情報収集には、既存のルーティングプロトコルであるＯＳＰＦを利用し、ＫＭドメイン間の経路情報収集には、既存のルーティングプロトコルＢＧＰを利用することとするが、別のプロトコルを利用することを除外するものではない。
【0060】
初めに、ＱＫＤＮ ＫＳＤ１００－１～１００－４を構成する各ＫＭと隣接ＫＭ間のリンクに対応付けられるデータは以下の通りとする。下のデータは時間順のシーケンス番号を付けられ、シーケンス番号より更新される。
【0061】
リンクに対応付けられるデータ：
・コスト（リソース情報）：リンク鍵の生成速度
・コスト（リソース情報）：リンク鍵の保有量
・状態（リソース情報）：ＱＢＥＲ
・コスト（リソース情報）：リンク鍵の生成速度
・コスト（リソース情報）：リンク鍵の保有量
・状態（リソース情報）：ＱＢＥＲ
【0062】
ＫＭに対応付けられるデータ：
・ドメイン内の構成を表すデータベース（リンクステートデータベース）
・ドメイン内の宛先ＫＭへの最短パスツリーの確定情報
・ドメイン内の各ＢＫＭへの最短パスツリーの確定情報
・送信元からドメイン内の宛先ＫＭまでのボトルネック
・送信元からドメイン内の宛先ＫＭまでのホップ数
・送信元からドメイン内の宛先ＫＭまでの最大ＱＢＥＲ値
・送信元から各ＢＫＭまでのボトルネック
・送信元から各ＢＫＭまでのホップ数
・送信元から各ＢＫＭまでの最大ＱＢＥＲ値
・ネクストホップ
・ドメイン内の構成を表すデータベース（リンクステートデータベース）
・ドメイン内の宛先ＫＭへの最短パスツリーの確定情報
・ドメイン内の各ＢＫＭへの最短パスツリーの確定情報
・送信元からドメイン内の宛先ＫＭまでのボトルネック
・送信元からドメイン内の宛先ＫＭまでのホップ数
・送信元からドメイン内の宛先ＫＭまでの最大ＱＢＥＲ値
・送信元から各ＢＫＭまでのボトルネック
・送信元から各ＢＫＭまでのホップ数
・送信元から各ＢＫＭまでの最大ＱＢＥＲ値
・ネクストホップ
【0063】
リンクに対応づけられるデータは、リソース情報である。リソース情報は、２種類のコスト（リンク鍵の生成速度、および、リンク鍵の保有量）と、リンクの状態（ＱＢＥＲ）とを含む。
【0064】
鍵生成速度は、隣接ＫＭ間で量子鍵配送を行うことでリンク鍵を共有する速度を表す。鍵生成速度は、リンクに接続されたＫＭの設定パラメータ及び接続環境等の影響によって、リンクごとに異なる。
【0065】
鍵保有量は、隣接ＫＭ間で量子鍵配送を行うことで共有した鍵のうち、まだ使用されていない鍵の量である。鍵保有量は、量子鍵配送を行うことによって蓄積し（増加する）、任意の送信元ＫＭ～宛先ＫＭ間のアプリケーション鍵リレーでリンク鍵を利用することによって消費される（減少する）。なお、コストはこれに限られるものではない。例えば、鍵生成速度のみ、または、鍵保有量のみがコストとして用いられてもよい。
【0066】
次に、ＫＭに対応付けられるデータについて説明するため、まずドメイン内の鍵リレー経路決定方法を説明する。
【0067】
［ドメイン内の鍵リレー経路決定方法の例］
ドメイン内の鍵リレー経路決定に必要な情報は、既存のルーティングプロトコルであるＯＳＰＦを利用して、下記（１）～（４）の処理によって収集される。
ドメイン内の鍵リレー経路決定に必要な情報は、既存のルーティングプロトコルであるＯＳＰＦを利用して、下記（１）～（４）の処理によって収集される。
【0068】
（１）ＯＳＰＦでは、ＫＭはリンクステートアップデートと呼ばれるメッセージを出し、ＫＭが接続しているリンクの状態、そのリンクのネットワークアドレス、及びコストなどの情報を他のＫＭと共有する。リンクステートには、あるＫＭが、ほかのＫＭにどのように接続しているか、という情報（経路情報）が含まれる。
【0069】
（２）リンクステートアップデートを受け取った各ＫＭでは、その情報に基づいて、ドメイン内のネットワーク構成を把握する。そして、ドメイン内のネットワーク構成を表す表（リンクステートデータベース）を構築する。
【0070】
（３）各ＫＭは、このデータベースからＤｉｊｋｓｔｒａアルゴリズムを用いて、自身を送信元としたドメイン内の最短パスツリーを計算し、フォワーディングテーブルを作成する。
【0071】
（４）内部情報記憶部６ｂは、あるＫＭからドメイン内のほかのＫＭまでのフォワーディンテーブル情報とリソース情報とを記憶する。
【0072】
以上が、ＱＫＤＮ ＫＳＤ１００－１～１００－４におけるドメイン内の基本的なフォワーディンテーブル決定方法である。本実施形態は、上述の方法のうち、主に（３）のドメイン内の最短パスツリーの作成に関する。（１）、（２）および（４）は、従来と同様の処理で実行できる。ただし、後述のとおり、（１）の手順によって共有される情報の一部に、本実施形態特有の情報が含まれる。
【0073】
上記のように、ＫＭに対応付けられるデータは、リンクステートデータベース、ドメイン内の宛先ＫＭへの最短パスツリーの確定情報、ドメイン内の各ＢＫＭへの最短パスツリーの確定情報、送信元からドメイン内の宛先ＫＭまでのボトルネック、送信元からドメイン内の宛先ＫＭまでのホップ数、送信元からドメイン内の宛先ＫＭまでの最大ＱＢＥＲ値、送信元から各ＢＫＭまでのボトルネック、送信元から各ＢＫＭまでのホップ数、送信元から各ＢＫＭまでの最大ＱＢＥＲ値、及び、ネクストホップである。
【0074】
リンクステートデータベースは、ドメイン内のネットワーク構成（接続関係）を表し、
各ＫＭが、最短パスを計算する時に使用される情報である。
各ＫＭが、最短パスを計算する時に使用される情報である。
【0075】
ドメイン内の宛先ＫＭへの最短パスツリーの確定情報、ドメイン内の宛先ＫＭごとに、当該ＫＭまでの最短パスが確定しているかどうかを表す。確定していない場合は、そのＫＭまでの鍵リレー経路は最短パス候補に過ぎないことを表す。
【0076】
ドメイン内の各ＢＫＭへの最短パスツリーの確定情報、ドメイン内のＢＫＭごとに、当該ＢＫＭまでの最短パスが確定しているかどうかを表す。確定していない場合は、そのＢＫＭまでの鍵リレー経路は最短パス候補に過ぎないことを表す。
【0077】
送信元からドメイン内の宛先ＫＭまでのボトルネックは、宛先ＫＭに到達するための最短パス候補を経由するときのリンクのコストのボトルネックを表す。
【0078】
送信元からドメイン内の宛先ＫＭまでのホップ数は、宛先ＫＭに到達するための最短パス候補を経由するときのホップ数を表す。
【0079】
送信元からドメイン内の宛先ＫＭまでの最大ＱＢＥＲ値は、宛先ＫＭに到達するための最短パス候補を経由するときの最大ＱＢＥＲ値を表す。
【0080】
送信元から各ＢＫＭまでのボトルネックは、各ＢＫＭに到達するための最短パス候補を経由するときのリンクのコストのボトルネックを表す。
【0081】
送信元から各ＢＫＭまでのホップ数は、各ＢＫＭに到達するための最短パス候補を経由するときのホップ数を表す。
【0082】
送信元から各ＢＫＭまでの最大ＱＢＥＲ値は、各ＢＫＭに到達するための最短パス候補を経由するときの最大ＱＢＥＲ値を表す。
【0083】
ネクストホップは、最短パスの候補となるネクストホップを表す。
【0084】
各ＫＭは、リンクステートデータベース、ドメイン内の最短鍵リレー経路ツリーとしての確定情報、送信元ＫＭからほかの各ＫＭまでの各リンクのコストと状態（リソース情報）、送信元からほかの各ＫＭまでのホップ数、および、ネクストホップを持つ。送信元から他のＫＭまでの各リンクのコスト、および、送信元から他のＫＭまでのホップ数は、当該他のＫＭごとに保持される。
【0085】
ＯＳＰＦにおけるダイクストラアルゴリズムでは、メトリックは距離であった。一方、本実施形態の鍵共有ルーティングプロトコルでは、距離ではなく、鍵リレー経路におけるボトルネックをメトリックの算出に用いる。アプリケーション鍵を共有するＫＭ間の、鍵生成速度と鍵保有量とを一定の値以上に保ち、アプリケーションネットワークで必要となる量の暗号鍵の獲得に支障が生じないようにするために、ボトルネックをメトリックとして導入する。
【0086】
［メトリックの例］
図３Ａは実施形態のメトリックの例１を示す図である。図３Ａは、メトリックにボトルネック（コスト）が使用される場合を示す。ボトルネック（コスト）は、各リンクにおけるリンク鍵の生成速度、及び、各リンクにおけるリンク鍵の保有量の少なくとも一方を含むリソース情報から算出される。算出部８は、リソース情報に基づき、メトリックを算出する。
図３Ａは実施形態のメトリックの例１を示す図である。図３Ａは、メトリックにボトルネック（コスト）が使用される場合を示す。ボトルネック（コスト）は、各リンクにおけるリンク鍵の生成速度、及び、各リンクにおけるリンク鍵の保有量の少なくとも一方を含むリソース情報から算出される。算出部８は、リソース情報に基づき、メトリックを算出する。
【0087】
例えば、ボトルネック（コスト）は、下記式により算出される。
Ｃｏｓｔｌｉｎｋ＝Ｕｋｅｙ＋ＳＫＲ×ｔ
Ｃｏｓｔｌｉｎｋ＝Ｕｋｅｙ＋ＳＫＲ×ｔ
【0088】
ここで、Ｕｋｅｙは、各ＫＭのリンク鍵未使用量（鍵残量）を示し、ＳＫＲは、各ＫＭのリンク鍵生成速度を示し、ｔは参照用時間間隔を示す。参照用時間間隔（ｔ）は実際の状況に従い設定される。例えば、Ｕｋｅｙが１０００Ｍｂｉｔｓ、ＳＫＲが３Ｍｂｉｔｓ／ｓｅｃ、ｔが３００ｓｅｃのとき、Ｃｏｓｔｌｉｎｋは１９００（１．９Ｇｂｉｔｓ）となる。
【0089】
図３Ａでは、各リンクに付けられた数値がコストを表す。送信元（Ｓ）からリレー（Ｒ）を経由して宛先（Ｄ）までの鍵リレー経路に含まれる各リンクのコストの最小値がメトリック（ボトルネック）となる。
【0090】
【0091】
図３Ｂは、実施形態のメトリックの例２を示す図である。図３Ｂは、メトリックにホップ数が使用される場合を示す。ホップ数はリレーＫＭの数＋１の値とする。送信元（Ｓ）からリレー（Ｒ）を経由して宛先（Ｄ）までの鍵リレー経路に含まれるリレーＫＭの数＋１の値がメトリック（ホップ数）となる。
【0092】
【0093】
［鍵リレー経路の状態の例］
図３Ｃは実施形態の鍵リレー経路の状態の例を示す図である。図３Ｃは、鍵リレー経路の状態に、ＱＢＥＲが使用される場合を示す。リンクに付けられた数値がＱＢＥＲ値を表す。送信元（Ｓ）からリレー（Ｒ）を経由して宛先（Ｄ）までの鍵リレー経路に含まれる各リンクのＱＢＥＲの最大値が状態となる。
図３Ｃは実施形態の鍵リレー経路の状態の例を示す図である。図３Ｃは、鍵リレー経路の状態に、ＱＢＥＲが使用される場合を示す。リンクに付けられた数値がＱＢＥＲ値を表す。送信元（Ｓ）からリレー（Ｒ）を経由して宛先（Ｄ）までの鍵リレー経路に含まれる各リンクのＱＢＥＲの最大値が状態となる。
【0094】
図３Ｃの例では、ＱＢＥＲは、鍵リレー経路に含まれる各リンクの状態の最大値なので、ｍｉｎ｛４，３，６｝＝６となる。すなわち、この鍵リレー経路の状態は６となる。
【0095】
［鍵リレー経路の決定方法の例］
図４は実施形態の鍵リレー経路の決定方法の例を説明するための図である。図４は、メトリックによる鍵リレー経路（パス）の選択方法を示す。図４では、送信元ＫＭがＳを表し、宛先ＫＭがＤを表し、アプリケーション鍵を共有するためのリレーＫＭをＲで表す。また、リンクに振られた番号がリンクのボトルネック（コスト）を表す。鍵リレー経路Ａは、ボトルネックが３、ホップ数が２となる。鍵リレー経路Ｂは、ボトルネックが５、ホップ数が３となる。鍵リレー経路Ｃは、ボトルネックが６、ホップ数が４となる。
図４は実施形態の鍵リレー経路の決定方法の例を説明するための図である。図４は、メトリックによる鍵リレー経路（パス）の選択方法を示す。図４では、送信元ＫＭがＳを表し、宛先ＫＭがＤを表し、アプリケーション鍵を共有するためのリレーＫＭをＲで表す。また、リンクに振られた番号がリンクのボトルネック（コスト）を表す。鍵リレー経路Ａは、ボトルネックが３、ホップ数が２となる。鍵リレー経路Ｂは、ボトルネックが５、ホップ数が３となる。鍵リレー経路Ｃは、ボトルネックが６、ホップ数が４となる。
【0096】
メトリックが、ボトルネック及びホップ数から算出される場合のメトリック算出方法の例を以下に示す。
【0097】
方法１：決定部９が、ボトルネックとホップ数とを別々の領域に保持する。そして、決定部９は、ボトルネックを優先し、ボトルネックが等しい場合に、ホップ数を比較し、ホップ数が少ない経路を最適な鍵リレー経路に決定する。
【0098】
方法２：決定部９が、ボトルネックとホップ数とを別々の領域に保持する。そして、決定部９は、ホップ数を優先し、ホップ数が等しい場合にボトルネックを比較し、ボトルネックが大きい経路を最適な鍵リレー経路に決定する。
【0099】
方法３：決定部９は、ボトルネック（ＢＮ）とホップ数（Ｈｏｐｓ）とを含むメトリック（Ｍｅｔｒｉｃ）を算出式により、最適な鍵リレー経路を決定する。
【0100】
算出式は、例えば下記式により算出される。
Ｍｅｔｒｉｃ＝δ×ＢＮ＋（１－δ）×（１／Ｈｏｐｓ）
Ｍｅｔｒｉｃ＝δ×ＢＮ＋（１－δ）×（１／Ｈｏｐｓ）
【0101】
ここでδは、１より小さい係数である。
【0102】
一方、メトリックがボトルネックだけの場合、鍵リレー経路Ｃが最適な鍵リレー経路となる。メトリックがホップ数だけの場合、鍵リレー経路Ａが最適な鍵リレー経路となる。上記の算出式の係数を設定することで、メトリックが片方だけの場合を実現することが可能である。例えば、メトリックをボトルネックだけにする場合は、δ＝１に設定する。また、メトリックをホップ数だけにする場合は、δ＝０に設定する。
【0103】
図４の例を用いて、δ＝０．５に設定し、上記方法３に従いメトリックを計算する例について説明する。
【0104】
鍵リレー経路Ａのメトリックは、Ｍｅｔｒｉｃ＝０．５×３＋（１－０．５）×（１／２）＝１．７５となる。鍵リレー経路Ｂのメトリックは、Ｍｅｔｒｉｃ＝０．５×５＋（１－０．５）×（１／３）＝２．６７となる。鍵リレー経路Ｃのメトリックは、Ｍｅｔｒｉｃ＝０．５×６＋（１－０．５）×（１／４）＝３．１２５となる。
【0105】
方法１では、各ＫＭまでのボトルネックとホップ数とをそれぞれ保持し、ボトルネックが等しい場合にのみホップ数の比較を行う。方法２では、各ＫＭまでのボトルネックとホップ数とをそれぞれ保持し、ホップ数が等しい場合にのみボトルネックの比較を行う。方法３では、メトリックを表す算出式を予め作っておき、各ＫＭまでのボトルネックとホップ数とからメトリックを算出しておく。
【0106】
なお、上記メトリックの算出式は一例であり、これらに限られるものではない。例えば、ボトルネックとホップ数とそれぞれに重みを付けて足し合わせた結果をメトリックとする他の式を用いてもよい。この場合、ボトルネックおよびホップ数にかかる係数（重み）は任意である。
【0107】
図５は実施形態の鍵リレー経路の状態を更に考慮した鍵リレー経路の決定方法の例を説明するための図である。決定部９は、メトリック（ボトルネック及びホップ数）に加え、状態として鍵リレー経路のＱＢＥＲを更に考慮する。これにより、ドメイン内の鍵リレー経路決定では、鍵消費を抑制する経路選択が可能となり、かつ、異常が発生する時の対応ができるので、効率的な経路選択が可能になる。
【0108】
図５では、送信元ＫＭがＳを表し、宛先ＫＭがＤを表し、アプリケーション鍵を共有するためのリレーＫＭをＲで表す。また、リンクに振られた番号がリンクの状態を表す。
【0109】
鍵リレー経路の状態は、各リンクのＱＢＥＲの最大値となる。図５に示すように、例えば、鍵リレー経路Ａは、状態が４％となる。鍵リレー経路Ｂは、状態が４％となる。鍵リレー経路Ｃは、状態が５％となる。
【0110】
鍵リレー経路の状態は、鍵リレー経路の安定性・安全性を示す。鍵リレー経路の状態は、鍵リレー経路を決める１つの要素となる。各ドメインにおける状態に同一の閾値を設定する。あるリンクのＱＢＥＲ値が閾値を超える場合、このリンクが盗聴される可能性が非常に高いと想定される。決定部９は、ＱＢＥＲ値が閾値を超える場合、このリンクを含む鍵リレー経路は不安全と判定し、ＱＢＥＲ値が閾値を超えるリンクを回避しながら新たな鍵リレー経路を決定する。閾値は通常１００％以内となる。例えば、閾値は５０％に設定される。なお、回避されたリンクのＱＢＥＲが閾値以下に戻ると、当該リンクを含む経路が、再び鍵リレー経路の候補になる。
【0111】
図５の例では、アプリケーション鍵を、送信元ＫＭ（Ｓ）から宛先ＫＭ（Ｄ）まで、リレーする場合を示す。上記の方法３を基準として、メトリック最良の鍵リレー経路Ｃを決定する場合について説明する。例えば、鍵リレー経路ＣのＱＢＥＲ値が５％のリンクが盗聴され、ＱＢＥＲ値が５５％に急増したとする。このとき、例えば、リレーＫＭであるＲ１０が、鍵リレー経路Ｃの状態が閾値を超えたことを検出した場合、鍵リレー経路Ｃに含まれる全てのＫＭにフィードバックする。
【0112】
送信元ＫＭ（Ｓ）は、鍵リレー経路Ｃのあるリンクの状態が異常という情報を受けると、鍵リレー経路Ｃを回避する。そのあと、送信元ＫＭ（Ｓ）の決定部９は、ドメイン内の鍵リレー経路の決定処理を再実行し、以上リンクを含まない最良の鍵リレー経路を決定する。
【0113】
具体的な各部の動作例としては、まず収集部７が、動的にリンクの状態を示す状態情報を更に収集する。次に、算出部８が、鍵リレー経路の状態情報を、鍵リレー経路に含まれるリンクの状態情報に基づいて算出する。そして、決定部９は、鍵リレー経路の状態情報が閾値より小さい鍵リレー経路から、メトリックに基づいて、鍵リレー経路を決定し、鍵リレー経路の状態情報が閾値以上の鍵リレー経路は、異常経路であると判定する。
【0114】
［内部情報記憶部に記憶される鍵リレー経路属性情報の例］
図６は実施形態の内部情報記憶部６ｂに記憶される鍵リレー経路属性情報の例を示す図である。図６の例では、ＱＫＤＮ ＫＳＤ１００－１の境界にあるＢＫＭ１８１１の内部情報記憶部６ｂに記憶される鍵リレー経路属性情報について説明する。内部情報記憶部６ｂに記憶される鍵リレー経路属性情報は、ドメイン内の各ＫＭ（ＢＫＭも含まれる）からの最短パスの候補となる情報である。
図６は実施形態の内部情報記憶部６ｂに記憶される鍵リレー経路属性情報の例を示す図である。図６の例では、ＱＫＤＮ ＫＳＤ１００－１の境界にあるＢＫＭ１８１１の内部情報記憶部６ｂに記憶される鍵リレー経路属性情報について説明する。内部情報記憶部６ｂに記憶される鍵リレー経路属性情報は、ドメイン内の各ＫＭ（ＢＫＭも含まれる）からの最短パスの候補となる情報である。
【0115】
収集部７が、ドメイン内のＯＳＰＦルーティングを行い、鍵リレー経路属性情報を収集してテーブルを作成し、当該テーブルを内部情報記憶部６ｂに保存する。収集部７により収集される情報は、上記のメトリック情報（ボトルネック及びホップ数）、状態情報（ＱＢＥＲ）、送信元のホスト名、及び、情報の時間を示す値を含む。なお、収集部７により収集される情報に、鍵リレー経路属性情報に関するそのほかの情報が更に含まれていてもよい。
【0116】
図６に示す鍵リレー経路属性情報は、始点（ＩＰアドレス）、シーケンス番号、ボトルネック、ホップ数及び状態を含む。始点（ＩＰアドレス）は、送信元のホスト名（例えば、ＩＰアドレス）である。シーケンス番号は、情報の時間を示す値（例えば、時間順のシーケンス番号）である。ボトルネックは、鍵リレー経路のボトルネックである。ホップ数は、鍵リレー経路のホップ数である。状態は、鍵リレー経路の状態情報（ＱＢＥＲ）である。
【0117】
収集部７は、例えば所定の時間間隔で鍵リレー経路属性情報を収集し、古い鍵リレー経路属性情報をシーケンス番号に基づいて更新・廃棄する。例えば、シーケンス番号がより新しい（例えば、受けた鍵リレー経路属性情報のシーケンス番号が保持している鍵リレー経路属性情報のシーケンス番号より大きい）の場合、最短パスの候補となる鍵リレー経路属性情報を更新する。また例えば、シーケンス番号がより古い（例えば、受けた鍵リレー経路属性情報のシーケンス番号が保持している鍵リレー経路属性情報のシーケンス番号より小さい）場合、受けた鍵リレー経路属性情報をそのまま廃棄する。
【0118】
次は、ドメイン間の鍵リレー経路決定方法を説明する。
【0119】
［ドメイン間の鍵リレー経路決定方法の例］
ドメイン内の鍵リレー経路ができると、ドメイン間の鍵リレー経路の決定プロセスが始まる。ドメイン間の鍵リレー経路は、既存のルーティングプロトコルであるＢＧＰを利用して収集される。ＢＧＰを利用するＫＭは、全てのＫＭではなく、ドメインの境界におけるＢＫＭだけとなる。ＢＫＭは、一般のＫＭが持つ機能以外、別のドメインと情報共有するため機能と、共有した情報を保存する構成（例えば、内部情報記憶部６ｂ及び外部情報記憶部６ａ）と、を含む。
ドメイン内の鍵リレー経路ができると、ドメイン間の鍵リレー経路の決定プロセスが始まる。ドメイン間の鍵リレー経路は、既存のルーティングプロトコルであるＢＧＰを利用して収集される。ＢＧＰを利用するＫＭは、全てのＫＭではなく、ドメインの境界におけるＢＫＭだけとなる。ＢＫＭは、一般のＫＭが持つ機能以外、別のドメインと情報共有するため機能と、共有した情報を保存する構成（例えば、内部情報記憶部６ｂ及び外部情報記憶部６ａ）と、を含む。
【0120】
［ＢＧＰ関連情報の例］
図７は、実施形態のＢＧＰ関連情報の例を示す図である。図７の例では、ＢＫＭ４３２５の外部情報記憶部６ａに記憶されるＢＧＰ関連情報について説明する。収集部７は、ＢＧＰルーティングプロトコルを実行し、ＢＫＭ４３２５が属するドメインのネットワーク構成と、隣接するドメインの経路情報とを把握し、その経路情報に基づくＢＧＰ関連情報として、ＢＧＰに関する経路テーブルを作成する。
図７は、実施形態のＢＧＰ関連情報の例を示す図である。図７の例では、ＢＫＭ４３２５の外部情報記憶部６ａに記憶されるＢＧＰ関連情報について説明する。収集部７は、ＢＧＰルーティングプロトコルを実行し、ＢＫＭ４３２５が属するドメインのネットワーク構成と、隣接するドメインの経路情報とを把握し、その経路情報に基づくＢＧＰ関連情報として、ＢＧＰに関する経路テーブルを作成する。
【0121】
実施形態のＢＧＰ関連情報は、選択情報、ドメイン（ＩＰアドレス）、ネクストホップ、ドメインパス及びメトリックを含む。なお、ＢＧＰ関連情報には、ＢＧＰ関連情報に関するそのほかの情報が更に含まれていてもよい。
【0122】
選択情報は、鍵リレー経路（ＢＧＰルート）の選択状態を示す。「＞」はベスト鍵リレー経路として選択されたルートを示す。「＊」は鍵リレー経路が有効なルート（選択可能なルート）であることを示す。
【0123】
ドメイン（ＩＰアドレス）は、宛先ドメインのネットワークのプレフィックス／マスク長を示す。図７の例では、１．１．１．０／ｘは、ＱＫＤＮ ＫＳＤ１００－１のネットワークのプレフィックス／マスク長を示す。２．２．２．０／ｘは、ＱＫＤＮ ＫＳＤ１００－２のネットワークのプレフィックス／マスク長を示す。３．３．３．０／ｘは、ＱＫＤＮ ＫＳＤ１００－３のネットワークのプレフィックス／マスク長を示す。４．４．４．０／ｘは、ＱＫＤＮ ＫＳＤ１００－４のネットワークのプレフィックス／マスク長を示す。
【0124】
ネクストホップは、ネクストホップのＩＰアドレスまたはホスト名である。
【0125】
ドメインパスは、宛先ドメインまでの鍵リレー経路を示す。右端から順に経由したドメイン番号が列挙される。ルートの種類は、ドメイン内におけるルートはＩＢＧＰ（Ｉｎｔｅｒｎａｌ ＢＧＰ）と、ドメイン外におけるほかのＢＫＭからのリンクはＥＢＧＰ（Ｅｘｔｅｒｎａｌ ＢＧＰ）がある。ＩＢＧＰは「ｉ」で示す。ＥＢＧＰは経由したドメイン番号を記録する。
【0126】
メトリックは、ＢＧＰのメトリックを示す。メトリックは、鍵リレー経路属性情報に基づき算出される。算出方法は、ドメイン内のＯＳＰＦの算出方法と同じである。
【0127】
図７の例では、例えば、ＢＫＭ４３２５が属するドメインであるＱＫＤＮ ＫＳＤ１００－４から、ＱＫＤＮ ＫＳＤ１００までは２つのドメインパスが存在する。１つ目のドメインパスは、ＱＫＤＮ ＫＳＤ１００－２を経由するドメインパス（１００－１，１００－２，ｉ）である。２つ目のドメインパスは、ＱＫＤＮ ＫＳＤ１００－３を経由するドメインパス（１００－１，１００－３，ｉ）である。
【0128】
「＊」が付けられているドメインパス（１００－１，１００－２，ｉ）は、有効なルートであるが、ベスト鍵リレー経路ではない。「＊＞」が付けられているドメインパス（１００－１，１００－３，ｉ）がベスト鍵リレー経路となる。
【0129】
［鍵リレー経路属性情報の共有方法の例］
ドメイン境界のＢＫＭにおける鍵リレー経路属性情報の共有について説明する。図８は実施形態の鍵リレー経路属性情報の共有方法の例を説明するための図である。図８は、送信元ＫＭからドメイン外における宛先ＫＭへの鍵リレー経路属性情報を共有するための基本シーケンスを示す。
ドメイン境界のＢＫＭにおける鍵リレー経路属性情報の共有について説明する。図８は実施形態の鍵リレー経路属性情報の共有方法の例を説明するための図である。図８は、送信元ＫＭからドメイン外における宛先ＫＭへの鍵リレー経路属性情報を共有するための基本シーケンスを示す。
【0130】
図８で説明される処理は、各ＢＫＭが、ＢＧＰルーティングプロトコルを実行し、当該ＢＫＭが属するドメインのネットワーク構成と、隣接するドメインのＢＫＭの情報とを把握した後に実行される。
【0131】
はじめに、ＫＭ０００１が、ドメイン外における宛先ＫＭ４６６６へ鍵共有する際に、ＫＭ０００１の収集部７が、ＱＫＤＮ ＫＳＤ１００－１内のすべてのＢＫＭに、鍵リレー経路の経路探索を要求する（ステップＳ１）。
【0132】
以下、図８の例では、ＢＫＭ１８１１が、ステップＳ１の要求を受け付けた場合を例にして説明する。
【0133】
次に、ＢＫＭ１８１１が、隣接するＱＫＤＮ ＫＳＤ１００－２のＢＫＭ２０３２に、宛先ＫＭ４６６６への鍵リレー経路属性情報を有するか確認する（ステップＳ２）。次に、ＢＫＭ２０３２が、内部情報記憶部６ｂを参照し、宛先ＫＭ４６６６への鍵リレー経路属性情報を探す（ステップＳ３）。
【0134】
ステップＳ３で、宛先ＫＭ４６６６への鍵リレー経路属性情報が見つかった場合には、ＢＫＭ２０３２が、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ１８１１へ返却し、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ１８１１と共有する（ステップＳ９）。
【0135】
ステップＳ３で、宛先ＫＭ４６６６への鍵リレー経路属性情報が見つからなかった場合には、ＢＫＭ２０３２が、ＱＫＤＮ ＫＳＤ１００－４と隣接するＢＫＭ２７３２に、宛先ＫＭ４６６６への鍵リレー経路属性情報を要求する（ステップＳ４）。
【0136】
次に、ＢＫＭ２７３２が、隣接するＱＫＤＮ ＫＳＤ１００－４のＢＫＭ４２１２に、宛先ＫＭ４６６６への鍵リレー経路属性情報を有するか確認する（ステップＳ５）。次に、ＢＫＭ４２１２が、内部情報記憶部６ｂを参照し、宛先ＫＭ４６６６への鍵リレー経路属性情報を探す（ステップＳ６）。
【0137】
ステップＳ６で、宛先ＫＭ４６６６への鍵リレー経路属性情報が見つかった場合には、ＢＫＭ２０３２が、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ１８１１へ返却し、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ２７３２と共有する（ステップＳ７）。
【0138】
次に、ＢＫＭ２７３２が、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ２０３２へ返却し、宛先ＫＭ４６６６への鍵リレー経路属性情報をＢＫＭ２０３２と共有する（ステップＳ８）。
【0139】
次に、ＢＫＭ２０３２が、経由されたＱＫＤＮ ＫＳＤ１００－２内のルート（ＢＫＭ２０３２からＢＫＭ２７３２までのルート）に関する鍵リレー経路属性情報を、内部情報記憶部６ｂから読み出す（ステップＳ３）。次に、ＢＫＭ２０３２が、ステップＳ６で見つかった鍵リレー経路属性情報と、ステップＳ３で読み出された鍵リレー経路属性情報とを、ＢＫＭ１８１１へ返却し、ステップＳ６及びＳ３で読み出された鍵リレー経路属性情報をＢＫＭ１８１１と共有する（ステップＳ９）。
【0140】
以上が、送信元ＫＭ００１と同じドメインに属するＢＫＭ１８１１が、鍵リレー経路属性情報を共有するまでの動作である。
【0141】
なお、ステップＳ６において、宛先ＫＭ４６６６への鍵リレー経路属性情報が見つからなかった場合には、更に隣接するドメインで、鍵リレー経路属性情報の探索処理を繰り返す。探索処理は、例えば、経由したドメインの数を示す経由ドメイン値が、事前設定した経由ドメイン上限値以内であれば、繰り返し継続される。図８の例では、経由されたドメインは、ＱＫＤＮ ＫＳＤ１００－２の１つであるため、経由ドメイン値は、１である。具体的には、図８の例では、経由ドメイン上限値が０の場合、ＢＫＭ２０３２が、宛先ＫＭ４６６６へ到着不可能と判断し、送信元ＢＫＭ０００１に到着不可能ということを通知する。
【0142】
送信元ＫＭ０００１と同じドメインに属する各ＢＫＭの収集部７は、共有した経路に関する鍵リレー経路属性情報を全て外部情報記憶部６ａに記憶する。その後、各ＢＫＭの算出部８が、鍵リレー経路属性情報を外部情報記憶部６ａから読み出し、ＱＫＤＮ ＫＳＤ１００－１外の鍵リレー経路のメトリックを算出する。また、各ＢＫＭの算出部８は、送信元ＫＭ０００１までの鍵リレー経路属性情報を内部情報記憶部６ｂから読み出し、ＱＫＤＮ ＫＳＤ１００－１内の鍵リレー経路のメトリックを算出する。
【0143】
各ＢＫＭの決定部９は、鍵リレー経路候補から、鍵リレー経路の状態と、メトリックとに基づいて、１の鍵リレー経路（メトリックが最良となる鍵リレー経路）を決定する。
【0144】
各ＢＫＭは、決定した最適な経路を送信元ＫＭ０００１へ通知する。送信元ＫＭ０００１は、各ＢＫＭから通知された経路から、最も適切な経路を利用して、アプリケーション鍵を宛先ＢＫＭ４６６６と共有する。
【0145】
［外部情報記憶部に記憶される鍵リレー経路属性情報の例］
図９は実施形態の外部情報記憶部６ａに記憶される鍵リレー経路属性情報の例を示す図である。図９の例では、ＱＫＤＮ ＫＳＤ１００－４の境界にあるＢＫＭ４３２５の外部情報記憶部６ａに記憶される鍵リレー経路属性情報について説明する。外部情報記憶部６ａに記憶される鍵リレー経路属性情報は、ドメイン外の各ＫＭ（ＢＫＭも含まれる）からの最短パスの候補となる情報である。
図９は実施形態の外部情報記憶部６ａに記憶される鍵リレー経路属性情報の例を示す図である。図９の例では、ＱＫＤＮ ＫＳＤ１００－４の境界にあるＢＫＭ４３２５の外部情報記憶部６ａに記憶される鍵リレー経路属性情報について説明する。外部情報記憶部６ａに記憶される鍵リレー経路属性情報は、ドメイン外の各ＫＭ（ＢＫＭも含まれる）からの最短パスの候補となる情報である。
【0146】
収集部７が、ドメイン外の鍵リレー経路属性情報を収集してテーブルを作成し、当該テーブルを外部情報記憶部６ａに保存する。収集部７により収集される情報は、図６と同じなので説明を省略する。
【0147】
なお、物理的に同じサイトにあるＢＫＭへの鍵リレー経路属性情報は一致する。図９の例では、１行目の宛先ＢＫＭ１８３１と、３行目の宛先ＢＫＭ２０３３とは、異なるドメインに属するにも関わらず、物理的に同じサイトにあるので、鍵リレー経路属性情報が一致する。
【0148】
［鍵リレー経路の決定処理の例］
図１０は実施形態の鍵リレー経路の決定処理の例を示すフローチャートである。送信元ＫＭから、送信元ドメインとは異なるドメインにある宛先ＫＭまでの鍵リレー経路を決定する場合を例にして説明する。
図１０は実施形態の鍵リレー経路の決定処理の例を示すフローチャートである。送信元ＫＭから、送信元ドメインとは異なるドメインにある宛先ＫＭまでの鍵リレー経路を決定する場合を例にして説明する。
【0149】
はじめに、送信元ＫＭと同じドメインに属するＢＫＭ（以降、「送信元ＢＫＭ」と呼ぶ）の収集部７が、ドメイン内を対象とするＯＳＰＦルーティングプロトコルと、ドメイン間を対象とするＢＧＰルーティングプロトコルとを実行することによって、ネットワーク構成を把握した後に、送信元ＫＭから送信元ＢＫＭまでの鍵リレー経路属性情報を収集する（ステップＳ２１）。
【0150】
ステップＳ２１で収集される鍵リレー経路属性情報は、下記式（１）により表される。
【0151】
【数1】
【0152】
ここで、Ｃｏｓｔｌｉｎｋは、ＫＭ間の各リンクのコスト（リソース）を示す。リソースは、鍵生成速度、及び、鍵の保有量である。ＱＢＥＲｌｉｎｋは、ＫＭ間の各リンクのＱＢＥＲ（状態）を示す。ＫＳＤｌｉｎｋｓは、ｍ個のリンクを含む集合を示す。
【0153】
次に、送信元ＢＫＭの算出部８が、ドメイン内（送信元ＫＭから送信元ＢＫＭまで）の鍵リレー経路属性情報（コスト、ホップ数及び状態）を算出する（ステップＳ２２）。具体的には、送信元ＢＫＭの算出部８が、ステップＳ２１で取集されたコストのボトルネックを、下記式（２）により算出し、ステップＳ２１で取集されたＱＢＥＲ（状態）の最大値を、下記式（３）により算出し、ホップ数（経由したリンクの合計値＋１）を下記式（４）により算出する。
【0154】
【数2】
【数3】
【数4】
【0155】
ドメイン内（送信元ＫＭから送信元ＢＫＭまで）のコスト（ボトルネック）は、ＣｏｓｔＫＳＤとなり、状態（ＱＢＥＲ）はＳｔａｔｕｓＫＳＤとなり、ホップ数はＨＫＳＤとなる。
【0156】
次に、送信元ＢＫＭの算出部８が、鍵リレー経路のメトリック及び状態を計算する（ステップＳ２３）。具体的には、まず、送信元ＢＫＭが、隣接ドメインＫＳＤ２のＢＫＭに、宛先ＫＭへの鍵リレー経路属性情報を要求する。隣接ドメインＫＳＤ２のＢＫＭは、内部情報記憶部６ｂに、宛先ＫＭへの鍵リレー経路属性情報が記憶されている場合、隣接ドメインＫＳＤ２内におけるコスト（ＣｏｓｔＫＳＤ２）、状態（ＳｔａｔｕｓＫＳＤ２）、及び、ホップ数（ＨＫＳＤ２）を送信元ＢＫＭに送信する。
【0157】
隣接ドメインＫＳＤ２のＢＫＭの内部情報記憶部６ｂに、宛先ＫＭへの鍵リレー経路属性情報が記憶されていない場合、隣接ドメインＫＳＤ２のＢＫＭが、更に隣接するドメインＫＳＤ３に継続的に、宛先ＫＭへの鍵リレー経路属性情報を要求する。この時に、隣接ドメインのＢＫＭ３と同じサイトにあるＢＫＭ２への鍵リレー経路属性情報が、送信元ＢＫＭへ共有される必要がある。
【0158】
次に、送信元ＢＫＭの算出部８が、ドメイン外（ＫＳＤ２～ＫＳＤｎ）における宛先ＫＭへの鍵リレー経路属性情報と、ドメイン内（ＫＳＤ１）における送信元ＫＭから送信元ＢＫＭまでの鍵リレー経路属性情報と、をあわせて、メトリック（Ｍｐａｔｈ）と状態（Ｓｔａｔｕｓｐａｔｈ）とを計算する。
【0159】
メトリック（Ｍｐａｔｈ）の計算例として、まず、送信元ＢＫＭの算出部８は、下記式（５）で鍵リレー経路のコスト（Ｃｏｓｔｐａｔｈ）を計算し、下記式（６）で鍵リレー経路のホップ数（Ｈｐａｔｈ）を計算し、その後に、下記式（７）によりメトリック（Ｍｐａｔｈ）を計算する。
【0160】
【数5】
【数6】
【数7】
【0161】
なおμは、ウェイトを示す係数である。
【0162】
また、状態（Ｓｔａｔｕｓｐａｔｈ）は、下記式（８）により計算される。
【0163】
【数8】
【0164】
なお、ＢＫＭの外部情報記憶部６ａは、送信元ＫＭからドメイン外の宛先ＫＭへの複数の鍵リレー経路ｐａｔｈ１、・・・、ｐａｔｈｊが存在する場合、全ての鍵リレー経路ｐａｔｈ１、・・・、ｐａｔｈｊに関する鍵リレー経路属性情報を記憶する。
【0165】
最後に、送信元ＢＫＭの決定部９が、送信元ＫＭがアプリケーション鍵を共有する要求に応じて、送信元ＫＭから宛先ＫＭまでの複数の鍵リレー経路ｐａｔｈ１、・・・、ｐａｔｈｊから、最適な鍵リレー経路を決定する（ステップＳ２４）。具体的には、送信元ＢＫＭの決定部９は、例えば下記式（９）及び（１０）に基づき、最適な鍵リレー経路を決定する。
【0166】
【数9】
【数10】
【0167】
経路の状態値（Ｓｔａｔｕｓｒｏｕｔｅ）は、経路の安全性を表すパラメータであり、状態値が閾値以内の経路であれば、最適な鍵リレー経路の候補となる。
【0168】
なお、上述のステップＳ２１及びＳ２２の処理は一例であり、コスト、ホップ数及び状態の収集及び算出は、別の方法で行われてもよい。例えば、経由されたＫＭごとに、コストと状態とを比較し続け、経由されたＫＭが、当該ＫＭまでのコストの最小値と状態の最大値とを保持しながら、コストの最小値と状態の最大値とをＢＫＭまで伝えてもよい。この場合、ＢＫＭでは、ＢＫＭまでのコストの最小値と状態の最大値とが収集される。また、ホップ数は経由されたＫＭの累積値となる。
【0169】
［鍵リレー経路の決定例］
図１１は実施形態の鍵リレー経路の決定例を示す図である。ＢＫＭの収集部７は、ＱＫＤＮ ＫＳＤ１００－１における送信元ＫＭ（ＫＭ０００１）から右側のＱＫＤＮ ＫＳＤ１００－４における宛先ＫＭ（ＫＭ４６６６）へ鍵を共有する際に、鍵リレー経路属性情報（例えばボトルネック、ホップ数及び状態値）を収集する。そして、ＢＫＭの算出部８は、鍵リレー経路属性情報に基づき計算された情報をＢＫＭの外部情報記憶部６ａに記憶する。
図１１は実施形態の鍵リレー経路の決定例を示す図である。ＢＫＭの収集部７は、ＱＫＤＮ ＫＳＤ１００－１における送信元ＫＭ（ＫＭ０００１）から右側のＱＫＤＮ ＫＳＤ１００－４における宛先ＫＭ（ＫＭ４６６６）へ鍵を共有する際に、鍵リレー経路属性情報（例えばボトルネック、ホップ数及び状態値）を収集する。そして、ＢＫＭの算出部８は、鍵リレー経路属性情報に基づき計算された情報をＢＫＭの外部情報記憶部６ａに記憶する。
【0170】
例えば、ＫＤＮ ＫＳＤ１００－２を経由してＫＤＮ ＫＳＤ１００－４まで鍵を共有する場合、ボトルネックが９０になる。ＫＤＮ ＫＳＤ１００－３を経由してＫＤＮ ＫＳＤ１００－４まで鍵を共有する場合、ボトルネックが８０になる。図１１のように、複数の経路１～３がある場合、ＢＫＭの決定部９が、要求（メトリックの定義）に応じて、鍵を共有する最適な経路を決定する。
【0171】
なお、リソースは、例えば、量子鍵配送が実行され鍵保有量が増加したり、アプリケーション鍵を転送することで鍵保有量が減少したり、量子暗号装置の環境変化等の影響で、鍵生成速度が変化したり、状態値が変化したりすることで変動しうる。このため、リソースの変動を検出したときに、収集部７が、本実施形態の動作を含むルーティングプロトコルを再実行し、最適な鍵リレー経路の算出をやり直してもよい。例えば、通信部４が、状態値の異変（経路の状態値が閾値に超えている）という通知を受信した場合、決定部９が、速やかに上記異変がない経路（状態値が閾値以内の候補経路）から最適な経路を再決定する。
【0172】
このような状況が好ましくない場合は、送信元ノードがソース・ルーティングの手法で鍵を送り、予め鍵を送る鍵リレー経路を指定しておくことで、送信元ノードが決定した鍵リレー経路を選択させることができる。ソース・ルーティングとは、送信元によってデータが通るべき鍵リレー経路を決定し、決定した鍵リレー経路に沿ってデータの転送を行う方式である。
【0173】
そのほかに、アプリケーション鍵をリンク鍵で暗号化して共有する方式以外の方式にも、本実施形態に関する経路制御は適用可能である。
【0174】
以上説明したように、実施形態の鍵管理装置（ＫＭ、ＢＫＭ）は、複数のアプリケーション２０により構成されるアプリケーションネットワーク２００の通信を暗号化するアプリケーション鍵を管理する鍵管理装置である。鍵管理装置は、収集部７と算出部８と決定部９と通信部４とを備える。収集部７は、ＱＫＤによってリンク鍵が生成されるリンクのリソースを示すリソース情報を収集する。算出部８は、リンクを含む鍵リレー経路のメトリックを、リソース情報に基づいて算出する。決定部９は、複数の鍵リレー経路から、メトリックに基づいて、鍵リレー経路を決定する。通信部４は、リンク鍵により暗号化されたアプリケーション鍵を、決定部９により決定された鍵リレー経路を使用して、宛先に送信する。
【0175】
これにより実施形態の鍵管理装置（ＫＭ、ＢＫＭ）によれば、ＱＫＤネットワークにおいて、アプリケーション鍵を共有するための最適な鍵リレー経路を決定することができる。具体的には、実施形態の鍵管理装置（ＫＭ、ＢＫＭ）によれば、例えば、複数のドメインに分割されたＱＫＤネットワークにおいても、リンク鍵の消費をできるだけ抑制し、かつ、アプリケーション鍵の共有を効率的に行うための鍵リレー経路を決定することができる。これにより、特定のＫＭにおけるリンク鍵の枯渇を避けつつ、スループットを維持しながら、システム全体でのリンク鍵の消費量を小さくすることが可能となる。更に、収集部７が、経路の状態情報を収集することよって、異常時の経路の再決定も効率的に実行できる。
【0176】
（変形例１）
次に実施形態の変形例１について説明する。変形例１の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
次に実施形態の変形例１について説明する。変形例１の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
【0177】
図１２は実施形態の変形例１について説明するための図である。変形例１では、各ドメイン（ＱＫＤＮ ＫＳＤ１００）の鍵リレー経路を集中管理するサーバ装置（ＱＫＤコントローラ３０）を更に備える。
【0178】
ＱＫＤコントローラ３０は、宛先ＫＭと鍵を共有する鍵リレー経路を指定してもよい。ＱＫＤコントローラ３０は、最良の鍵リレー経路を算出し、算出された鍵リレー経路を各ＫＭ（ＢＫＭを含む）の鍵リレー経路テーブルに反映させる。これにより各ＫＭは、最良の鍵リレー経路を選択することが可能となる。
【0179】
（変形例２）
次に実施形態の変形例２について説明する。変形例２の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
次に実施形態の変形例２について説明する。変形例２の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
【0180】
図１３は実施形態の変形例２について説明するための図である。変形例２では、各ドメイン（ＱＫＤＮ ＫＳＤ１００－１～１００－４）毎にＱＫＤコントローラ３０－１～３０－４が存在する。鍵リレー経路属性情報は、隣接するＱＫＤコントローラ３０間で収集され、ＱＫＤコントローラ３０が、送信元ＫＭから宛先ＫＭへの最適な経路を決めて、ＫＭ（ＢＫＭを含む）の鍵リレー経路テーブルに反映させる。
【0181】
各ＱＫＤコントローラ３０は、実施形態のＢＫＭと同じように、内部情報記憶部６ｂと外部情報記憶部６ａとに分けて、情報を管理する方式が好ましい。また、ＱＫＤコントローラ３０間も量子暗号通信（ＱＫＤ）以外の方式で情報を共有する。この変形例２の構成例は集中型対集中型の構成となる。
【0182】
（変形例３）
次に実施形態の変形例３について説明する。変形例３の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
次に実施形態の変形例３について説明する。変形例３の説明では、実施形態と同様の説明については省略し、実施形態と異なる箇所について説明する。
【0183】
図１４は実施形態の変形例３について説明するための図である。変形例３は、いわゆる、分散型と集中型とが混在する構成の例である。変形例３では、ＱＫＤコントローラ３０とＢＫＭの情報共有は、図の左側に示すように、ＱＫＤコントローラ３０が属するドメイン（ＱＫＤＮ ＫＳＤ１００－２）のＢＫＭ（集中型ＢＫＭ）を経由する。この集中型ＢＫＭにはルーティングプロトコル機能などが含まれていない。
【0184】
また、管理のしやすさ、及び、コストの節約の面から、図１４の右側に示すように、分散型に、ＢＫＭ３１１１をプライマリＢＫＭとし、プライマリＢＫＭの異常時に代わりに動作するセカンダリＢＫＭをＢＫＭ３３３３とする設計をしてもよい（ＱＫＤコントローラ３０という集中型とＢＫＭという分散型の結合型）。
【0185】
［ハードウェア構成の例］
図１５は実施形態のＫＭ、ＢＫＭ及びＱＫＤコントローラ３０のハードウェア構成の例を示す図である。実施形態のＫＭ、ＢＫＭ及びＱＫＤコントローラ３０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１などの制御装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３などの記憶装置、及び、ネットワークに接続して通信を行う通信Ｉ／Ｆ３０４を備える。ＣＰＵ）３０１、ＲＯＭ３０２、ＲＡＭ３０３及びネットワークは、バス３０５により接続される。
図１５は実施形態のＫＭ、ＢＫＭ及びＱＫＤコントローラ３０のハードウェア構成の例を示す図である。実施形態のＫＭ、ＢＫＭ及びＱＫＤコントローラ３０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１などの制御装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３などの記憶装置、及び、ネットワークに接続して通信を行う通信Ｉ／Ｆ３０４を備える。ＣＰＵ）３０１、ＲＯＭ３０２、ＲＡＭ３０３及びネットワークは、バス３０５により接続される。
【0186】
例えば、本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムは、ＲＯＭ等に予め組み込まれて提供される。
【0187】
また例えば、本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、及び、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【0188】
さらに、本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムは、コンピュータを上述したＫＭ、ＢＫＭ及びＱＫＤコントローラ３０の各部として機能させうる。このコンピュータは、ＣＰＵがコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
本実施形態にかかるＫＭ、ＢＫＭ及びＱＫＤコントローラ３０で実行されるプログラムは、コンピュータを上述したＫＭ、ＢＫＭ及びＱＫＤコントローラ３０の各部として機能させうる。このコンピュータは、ＣＰＵがコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【0189】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0190】
１ 制御部
２ 管理部
３ プラットフォーム部
４ 通信部
５ 処理部
６ 記憶部
６ａ 外部情報記憶部
６ｂ 内部情報記憶部
７ 収集部
８ 算出部
９ 決定部
２０ アプリケーション
３０ ＱＫＤコントローラ
１００ ＱＫＤＮ ＫＳＤ
２００ アプリケーションネットワーク
３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ 通信Ｉ／Ｆ
３０５ バス
２ 管理部
３ プラットフォーム部
４ 通信部
５ 処理部
６ 記憶部
６ａ 外部情報記憶部
６ｂ 内部情報記憶部
７ 収集部
８ 算出部
９ 決定部
２０ アプリケーション
３０ ＱＫＤコントローラ
１００ ＱＫＤＮ ＫＳＤ
２００ アプリケーションネットワーク
３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ 通信Ｉ／Ｆ
３０５ バス
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】