特開 2024-132522 鍵管理装置、量子暗号通信システム、ＱＫＤＮ制御装置、情報処理装置、鍵管理方法、ＱＫＤＮ制御方法、情報処理方法及びプログラム

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

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

(11)【公開番号】P2024132522

(43)【公開日】2024-10-01

(54)【発明の名称】鍵管理装置、量子暗号通信システム、ＱＫＤＮ制御装置、情報処理装置、鍵管理方法、ＱＫＤＮ制御方法、情報処理方法及びプログラム

(51)【国際特許分類】

   H04L 9/12 20060101AFI20240920BHJP

【ＦＩ】

H04L9/12

【審査請求】有

【請求項の数】15

【出願形態】ＯＬ

(21)【出願番号】P 2023043319

(22)【出願日】2023-03-17

【国等の委託研究の成果に係る記載事項】（出願人による申告）令和４年度、総務省「グローバル量子暗号通信網構築のための研究開発」に関する委託研究、産業技術力強化法第１７条の適用を受ける特許出願

(71)【出願人】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】兪 ユ

(72)【発明者】

【氏名】谷澤 佳道

(57)【要約】

【課題】ＱＫＤＮの規模に関わらず、アプリと、当該アプリへ暗号鍵を送信する鍵管理装置とを容易に対応付けることができるようにする。
【解決手段】実施形態の鍵管理装置は、ＱＫＤ装置と接続される鍵管理装置であって、通信インターフェースと処理部とを備える。通信インターフェースは、送信元アプリから、第１識別情報と、第２識別情報と、アプリ鍵の要求量と、を含むアプリ鍵の要求情報を受信する。処理部は、前記第２識別情報から、前記アプリ鍵の共有先の鍵管理装置を特定し、前記アプリ鍵の要求量から前記アプリ鍵の共有量を決定し、前記リンク鍵を使用して暗号化され、前記共有量を満たす前記アプリケーション鍵を、前記共有先の鍵管理装置へ前記通信インターフェースに送信させ、前記通信インターフェースに前記要求量のアプリ鍵を、前記第１識別情報により識別される送信元アプリへ送信させる。
【選択図】図３

【特許請求の範囲】

【請求項1】

ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置であって、
ユーザネットワークの送信元アプリケーションから、前記送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を受信する通信インターフェースと、
前記第２識別情報から前記アプリケーション鍵の共有先の鍵管理装置を特定し、
前記アプリケーション鍵の要求量から前記アプリケーション鍵の共有量を決定し、
前記リンク鍵を使用して暗号化され、前記共有量を満たす前記アプリケーション鍵を、前記共有先の鍵管理装置へ前記通信インターフェースに送信させ、
前記通信インターフェースに前記要求量のアプリケーション鍵を、前記第１識別情報により識別される送信元アプリケーションへ送信させる処理部と、
を備える鍵管理装置。

【請求項2】

前記アプリケーション鍵の要求情報は、前記アプリケーション鍵を送信する提供時刻を更に含み、
前記通信インターフェースは、前記提供時刻までに、前記要求量のアプリケーション鍵を前記送信元アプリケーションへ送信する、
請求項１に記載の鍵管理装置。

【請求項3】

前記通信インターフェースは、前記宛先アプリケーションを識別する第２識別情報と、前記宛先アプリケーションにアプリケーション鍵を送信する鍵管理装置を識別する第３識別情報と、が対応付けられたマッピング情報を記憶するＱＫＤＮ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）制御装置と通信し、
前記通信インターフェースは、前記ＱＫＤＮ制御装置から前記マッピング情報を取得し、
前記処理部は、前記マッピング情報から前記アプリケーション鍵の共有先の鍵管理装置を特定する、
請求項１又は２に記載の鍵管理装置。

【請求項4】

前記ＱＫＤＮ制御装置は、前記送信元アプリケーションに接続される鍵管理装置と、宛先アプリケーションに接続される鍵管理装置との間で既に共有されているアプリケーション鍵の量を示す状態情報を更に記憶し、
前記処理部は、前記アプリケーション鍵の要求量と、前記状態情報とから前記アプリケーション鍵の共有量を決定する、
請求項３に記載の鍵管理装置。

【請求項5】

請求項３に記載の鍵管理装置である、第１鍵管理装置及び第２鍵管理装置を備え、
前記第１及び第２鍵管理装置により構成される鍵共有ネットワークと、
前記第１及び第２鍵管理装置と通信する前記ＱＫＤＮ制御装置と、
前記送信元アプリケーションと前記宛先アプリケーションとを含む複数のアプリケーションと、
前記複数のアプリケーションが前記アプリケーション鍵を使用して暗号化通信をする前記ユーザネットワークと、
を備える量子暗号通信システム。

【請求項6】

ＱＫＤによって、前記リンク鍵を生成する前記ＱＫＤ装置である、第１ＱＫＤ装置及び第２ＱＫＤ装置を更に備え、
前記第１ＱＫＤ装置は前記第１鍵管理装置に前記リンク鍵を送信し、
前記第２ＱＫＤ装置は前記第２鍵管理装置に前記リンク鍵を送信する、
請求項５に記載の量子暗号通信システム。

【請求項7】

ユーザネットワークにおけるアプリケーション間で通信の暗号化又は復号に使用されるアプリケーション鍵を、アプリケーションに送信する複数の鍵管理装置と接続されるＱＫＤＮ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）制御装置であって、
通信インターフェースに、前記アプリケーションを識別する識別情報と、前記アプリケーションにアプリケーション鍵を送信する鍵管理装置を識別する識別情報と、が対応付けられたマッピング情報と、前記アプリケーション鍵の状態情報と、を前記複数の鍵管理装置から取得させ、前記マッピング情報と前記状態情報とを記憶装置に記憶させる処理部、
を備えるＱＫＤＮ制御装置。

【請求項8】

前記状態情報は、送信元アプリケーションに接続される第１鍵管理装置と、宛先アプリケーションに接続される第２鍵管理装置との間で既に共有されているアプリケーション鍵の量を示す、
請求項７に記載のＱＫＤＮ制御装置。

【請求項9】

前記第１鍵管理装置と前記第２鍵管理装置との間で既に共有されているアプリケーション鍵は、前記第１鍵管理装置に接続される送信元ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）装置と、前記第１鍵管理装置に接続される宛先ＱＫＤ装置との間のＱＫＤＮで、ＱＫＤにより生成されたリンク鍵で暗号化通信されることによって共有される、
請求項８に記載のＱＫＤＮ制御装置。

【請求項10】

ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置に、ユーザネットワークの送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を送信し、前記第２識別情報から特定された前記アプリケーション鍵の共有先の鍵管理装置との間で、前記要求量を満たすように共有されたアプリケーション鍵を受信する通信インターフェースと、
前記送信元アプリケーションを動作させることによって、前記ユーザネットワークにおける通信を暗号化する処理部と、
を備える情報処理装置。

【請求項11】

ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置の鍵管理方法であって、
通信インターフェースが、ユーザネットワークの送信元アプリケーションから、前記送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を受信するステップと、
処理部が、前記第２識別情報から、前記アプリケーション鍵の共有先の鍵管理装置を特定するステップと、
前記処理部が、前記アプリケーション鍵の要求量から前記アプリケーション鍵の共有量を決定するステップと、
前記処理部が、前記リンク鍵を使用して暗号化され、前記共有量を満たす前記アプリケーション鍵を、前記共有先の鍵管理装置へ前記通信インターフェースに送信させるステップと、
前記処理部が、前記通信インターフェースに前記要求量のアプリケーション鍵を、前記第１識別情報により識別される送信元アプリケーションへ送信させるステップと、
を含む鍵管理方法。

【請求項12】

ユーザネットワークにおけるアプリケーション間で通信の暗号化又は復号に使用されるアプリケーション鍵を、アプリケーションに送信する複数の鍵管理装置と接続されるＱＫＤＮ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）制御装置のＱＫＤＮ制御方法であって、
処理部が、通信インターフェースに、前記アプリケーションを識別する識別情報と、前記アプリケーションにアプリケーション鍵を送信する鍵管理装置を識別する識別情報と、が対応付けられたマッピング情報と、前記アプリケーション鍵の状態情報と、を前記複数の鍵管理装置から取得させるステップと、
前記処理部が、前記マッピング情報と前記状態情報とを記憶装置に記憶させるステップと、
を含むＱＫＤＮ制御方法。

【請求項13】

通信インターフェースが、ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置に、ユーザネットワークの送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を送信するステップと、
前記通信インターフェースが、前記第２識別情報から特定された前記アプリケーション鍵の共有先の鍵管理装置との間で、前記要求量を満たすように共有されたアプリケーション鍵を受信するステップと、
処理部が、前記送信元アプリケーションを動作させることによって、前記ユーザネットワークにおける通信を暗号化するステップと、
を備える情報処理方法。

【請求項14】

ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置を、
ユーザネットワークの送信元アプリケーションから、前記送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を受信する通信インターフェースと、
前記第２識別情報から、前記アプリケーション鍵の共有先の鍵管理装置を特定し、
前記アプリケーション鍵の要求量から前記アプリケーション鍵の共有量を決定し、
前記リンク鍵を使用して暗号化され、前記共有量を満たす前記アプリケーション鍵を、前記共有先の鍵管理装置へ前記通信インターフェースに送信させ、
前記通信インターフェースに前記要求量のアプリケーション鍵を、前記第１識別情報により識別される送信元アプリケーションへ送信させる処理部、
として機能させるためのプログラム。

【請求項15】

ユーザネットワークにおけるアプリケーション間で通信の暗号化又は復号に使用されるアプリケーション鍵を、アプリケーションに送信する複数の鍵管理装置と接続されるＱＫＤＮ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）制御装置を、
通信インターフェースに、前記アプリケーションを識別する識別情報と、前記アプリケーションにアプリケーション鍵を送信する鍵管理装置を識別する識別情報と、が対応付けられたマッピング情報と、前記アプリケーション鍵の状態情報と、を前記複数の鍵管理装置から取得させ、前記マッピング情報と前記状態情報とを記憶装置に記憶させる処理部、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は鍵管理装置、量子暗号通信システム、ＱＫＤＮ制御装置、情報処理装置、鍵管理方法、ＱＫＤＮ制御方法、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

アプリケーションが、量子鍵配送（ＱＫＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）を利用して別のアプリケーションとの間で共有された乱数を、鍵管理装置から取得し、この乱数を暗号鍵として利用して、別のアプリケーションとの間で暗号通信を行う技術が従来から知られている。このアプリケーションによる暗号通信は、ＱＫＤネットワークとは異なる、インターネットなどのユーザネットワークで行われる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第６４２６４７７号公報

【特許文献2】特許第５７８４５６２号公報

【非特許文献】

【0004】

【非特許文献1】ＩＴＵ－Ｔ， Ｙ．３８００， “Ｏｖｅｒｖｉｅｗ ｏｎ ｎｅｔｗｏｒｋｓ ｓｕｐｐｏｒｔｉｎｇ ｑｕａｎｔｕｍ ｋｅｙ ｄｉｓｔｒｉｂｕｔｉｏｎ，” ２０１９．

【非特許文献2】ＥＴＳＩ ＧＳ ＱＫＤ ０１４， “Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ （ＱＫＤ）； Ｐｒｏｔｏｃｏｌ ａｎｄ ｄａｔａ ｆｏｒｍａｔ ｏｆ ＲＥＳＴ－ｂａｓｅｄ ｋｅｙ ｄｅｌｉｖｅｒｙ ＡＰＩ，” ２０１９．

【発明の概要】

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

【0005】

しかしながら従来の技術では、ＱＫＤネットワークの規模が大きくなるほど、アプリケーションと、当該アプリケーションへ暗号鍵を送信する鍵管理装置とを対応付けることが困難だった。

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

【0006】

実施形態の鍵管理装置は、ＱＫＤ（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）によって、リンク鍵を生成するＱＫＤ装置と接続される鍵管理装置であって、通信インターフェースと処理部とを備える。通信インターフェースは、ユーザネットワークの送信元アプリケーションから、前記送信元アプリケーションを識別する第１識別情報と、宛先アプリケーションを識別する第２識別情報と、前記ユーザネットワークにおける通信の暗号化又は復号に使用されるアプリケーション鍵の要求量と、を含むアプリケーション鍵の要求情報を受信する。処理部は、前記第２識別情報から、前記アプリケーション鍵の共有先の鍵管理装置を特定し、前記アプリケーション鍵の要求量から前記アプリケーション鍵の共有量を決定し、前記リンク鍵を使用して暗号化され、前記共有量を満たす前記アプリケーション鍵を、前記共有先の鍵管理装置へ前記通信インターフェースに送信させ、前記通信インターフェースに前記要求量のアプリケーション鍵を、前記第１識別情報により識別される送信元アプリケーションへ送信させる。

【図面の簡単な説明】

【0007】

【図1】第１実施形態の量子暗号通信システムの構成の例を示す図。

【図2】第１実施形態の量子暗号通信ネットワークの例を示す図。

【図3】第１実施形態の鍵管理装置の機能構成の例を示す図。

【図4】第１実施形態のＱＫＤＮ制御装置の機能構成の例を示す図。

【図5】第１実施形態の情報処理装置の機能構成の例を示す図。

【図6】第１実施形態のセキュア通信方法の例を示すシーケンス図。

【図7】第１実施形態のマッピング情報の例を示す図。

【図8A】第２実施形態のＫＳＮドメインの例１を示す図。

【図8B】第２実施形態のＫＳＮドメインの例２を示す図。

【図9】第２実施形態のＫＭを識別するＩＤ体系の例を示す図。

【図10】第２実施形態の量子暗号通信ネットワークの例を示す図。

【図11】第２実施形態のセキュア通信方法の例を示すシーケンス図。

【図12】第２実施形態のマッピング情報の例を示す図。

【図13】第２実施形態の状態情報の例を示す図。

【図14】第２実施形態のマッピング情報の共有に関する問い合わせメッセージのフォーマットの例を示す図。

【図15】第２実施形態のマッピング情報の共有に関する応答メッセージのフォーマットの例を示す図。

【図16】第２実施形態の分散管理の構成の例を示す図。

【図17】第２実施形態の集中管理の構成の例を示す図。

【図18】第１及び第２実施形態のＫＭ、ＱＫＤＮ制御装置及び情報処理装置のハードウェア構成の例を示す図。

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

【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】

応答メッセージのデータ部分は、８つのフィールドを含む。はじめの４フィールドは問い合わせメッセージのデータ部分と一致する。応答メッセージのデータ部分では、マッピング情報の２フィールドと、アプリ鍵の蓄積状態の２フィールドとが追加されている。

【0152】

Ｄｅｓｔｉｎａｔｉｏｎ ＫＭ ＩＤは、宛先のＫＭ１０のＩＤ情報を示すフィールドである。

【0153】

Ｄｅｓｔｉｎａｔｉｏｎ ＫＳＮ ＩＤは、宛先のＫＳＮドメインのＩＤ情報を示すフィールドである。

【0154】

Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒは、シーケンス番号を示すフィールドである。

【0155】

Ａｖａｉｌａｂｌｅ Ａｍｏｕｎｔ ｏｆ Ａｐｐｌｉｃａｔｉｏｎ Ｋｅｙは、送信元のＫＭ１０と宛先のＫＭ１０との間で既に共有されているアプリ鍵の蓄積状態を示すフィールドである。

【0156】

なお、メッセージのフィールド長は実際の要求に従って定義される。上述の図１２及び図１３により示されるメッセージのフィールド長は一例である。

【0157】

図８Ａ及び７Ｂの構成例では、例えば、鍵共有ネットワーク１０２ａにおけるＫＭ１０ａに接続するアプリケーション５からアプリ鍵が要求され、鍵共有ネットワーク１０２ｄにおけるＫＭ１０ｄに接続するアプリケーションとセキュア通信を行う際の動作は、基本的には図１０と同じである。しかし、ＱＫＤＮ制御装置６ａ～６ｄ間の情報共有が１本のリンクで繋がっているわけではないため、少し複雑になる。

【0158】

ＱＫＤＮ制御装置６ａ～６ｄ間で情報を共有するための形態として、分散管理により共有する形態と、集中管理により共有する形態とがある。分散管理では、ＱＫＤＮ制御装置６の専用ネットワークが構築される。集中管理では、権威ルートサーバ装置が設置され、全てのＱＫＤＮ制御装置６が権威ルートサーバ装置に接続する。

【0159】

図１６は第２実施形態の分散管理の構成の例を示す図である。図１６の例では、ＱＫＤＮ制御装置６は専用ネットワークを構築し、各ＱＫＤＮ制御装置６が、マッピング情報、及び、アプリ鍵の状態情報を記憶する。また、各ＱＫＤＮ制御装置６が、マッピング情報、及び、アプリ鍵の状態情報の作成、更新及び削除を行う。

【0160】

ユーザネットワークにおけるアプリケーション５からアプリ鍵が要求される際に、各ＱＫＤＮ制御装置６間で関連情報（例えば、マッピング情報及びアプリ鍵の鍵状態情報）が共有される。

【0161】

各ＱＫＤＮ制御装置６は、宛先の情報を見つけるために、例えば、ブロードキャスト（Ｂｒｏａｄｃａｓｔ）の方式で、同じ問い合わせメッセージを専用ネットワーク内の他のＱＫＤＮ制御装置６に同時に転送する。

【0162】

他のＱＫＤＮ制御装置６が問い合わせメッセージを受信し、Ｄｅｓｔｉｎａｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ ＩＤのフィールドを参照し、マッピング情報を確認し、応答メッセージを返す。

【0163】

問い合わせメッセージを送信したＱＫＤＮ制御装置６は、他のＱＫＤＮ制御装置６から応答メッセージが来ると、Ｔｙｐｅ及びＣｏｄｅのフィールドを確認する。ＱＫＤＮ制御装置６は、Ｔｙｐｅ及びＣｏｄｅのフィールドを確認した結果、エラーの場合、宛先のアプリケーション５の関連情報がないので、アプリケーション５間とのセキュア通信が不可能と判断する。また、ＱＫＤＮ制御装置６は、ＴｙｐｅとＣｏｄｅのフィールドを確認した結果、エラーではない場合、Ｄｅｓｔｉｎａｔｉｏｎ ＫＭ ＩＤフィールドから４つのフィールド情報に基づく鍵送信・鍵リレー処理を実施する。

【0164】

図１６の例では、分散管理のため、関連情報にシーケンス番号（例えば、時間順）を付けて、常に最新の情報を利用する。なお、ＱＫＤＮ制御装置６間のリンクはＱＫＤリンク３でもよいし、ＱＫＤ以外の方式で守られる普通のリンクでもよい。

【0165】

図１７は第２実施形態の集中管理の構成の例を示す図である。図１７の例では、ＱＫＤＮ制御装置６は権威ルートサーバ装置９に接続する。マッピング情報及びアプリ鍵の状態情報などの関連情報は、権威ルートサーバ装置９で統一管理される。ＱＫＤＮ制御装置６は、ユーザネットワークにおけるアプリケーション５からアプリ鍵が要求される際に、権威ルートサーバ装置９に関連情報を問い合わせる。ＱＫＤＮ制御装置６は、権威ルートサーバ装置９から受信された応答メッセージに含まれるＴｙｐｅ及びＣｏｄｅのフィールドを確認した結果、エラーではない場合、マッピング情報及びアプリ鍵の状態情報に基づく鍵送信・鍵リレー処理を実施する。

【0166】

ＱＫＤＮ制御装置６は、権威ルートサーバ装置９から受信された応答メッセージに含まれるＴｙｐｅ及びＣｏｄｅのフィールドを確認した結果、エラーの場合、宛先のアプリケーション５の関連情報がないので、アプリケーション５間のセキュア通信が不可能とＫＭ１０にフィードバックする。

【0167】

権威ルートサーバ装置９の情報更新については、情報が常に更新される場合、権威ルートサーバ装置９とＱＫＤＮ制御装置６とが一致するシーケンス番号を付ける。マッピング情報、及び、アプリ鍵の状態情報を問い合わせる時だけ、権威ルートサーバ装置９の情報が更新される場合、関連するＱＫＤＮ制御装置６が、問い合わせがあったときに、権威ルートサーバ装置９へ最新の情報を通知する。

【0168】

なお、権威ルートサーバ装置９とＱＫＤＮ制御装置６との間のリンクはＱＫＤリンク３でもよいし、ＱＫＤ以外の方式で守られる普通のリンクでもよい。

【0169】

最後に、本実施形態にかかるＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８のハードウェア構成の例について説明する。
［ハードウェア構成の例］
図１８は第１及び第２実施形態のＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８のハードウェア構成の例を示す図である。ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８は、ＣＰＵ２０１などの制御装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、ＲＡＭ２０３などの記憶装置、及び、ネットワークに接続して通信を行う通信Ｉ／Ｆ２０４を備える。ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３及び通信Ｉ／Ｆ２０４は、バス２０５により接続される。

【0170】

例えば、ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８で実行されるプログラムは、ＲＯＭ２０２等に予め組み込まれて提供される。

【0171】

また例えば、ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、及び、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

【0172】

さらに、ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８で実行されるプログラムを、インターネット等のネットワークに接続されるコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

【0173】

ＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８で実行されるプログラムは、コンピュータを上述したＫＭ１０、ＱＫＤＮ制御装置６及び情報処理装置８の各部として機能させうる。このコンピュータは、ＣＰＵ２０１がコンピュータ読取可能な記憶媒体からプログラムをＲＡＭ２０３などの主記憶装置上に読み出して実行することができる。

【0174】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0175】

１ ノード
２ ＱＫＤモジュール
３ ＱＫＤリンク
４ ＱＫＤネットワークコントローラ
５ アプリケーション
６ ＱＫＤＮ制御装置
７ ユーザネットワーク制御装置
８ 情報処理装置
９ 権威ルートサーバ装置
１０ 鍵管理装置（ＫＭ）
１１ 通信部
１２ 記憶部
１３ 処理部
６１ 通信部
６２ 記憶部
６３ 処理部
１００ 量子暗号通信ネットワーク
１０１ ＱＫＤリンクのネットワーク
１０２ 鍵共有ネットワーク
１０３ データ通信ネットワーク
１１１ ＫＭ通信部
１１２ 制御通信部
１１３ アプリ通信部
１３１ 取得部
１３２ 実行部
１３３ 鍵処理部
１３４ 提供部
１３５ 制御部
１３６ 管理部
１３７ プラットフォーム部
６１１ ＫＭ通信部
６１２ 制御通信部
６３１ 取得部
６３２ 制御部
６３３ 管理部
６３４ プラットフォーム部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】