(57)【要約】【課題】量子鍵配送により共有された暗号鍵を利用できないアプリケーションがネットワーク内に存在する場合でも、ネットワーク内の通信の安全性を維持できるようにする。【解決手段】実施形態の通信装置は、受信部と生成部と判定部と共有制御部と送信部とを備える。受信部は、アプリケーションから、アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信する。生成部は、暗号鍵を生成する。判定部は、通信先と接続された他の通信装置があるか否かを判定する。共有制御部は、他の通信装置との間で、量子鍵配送により暗号鍵を共有できる場合、量子鍵配送により暗号鍵を共有し、量子鍵配送により暗号鍵を共有できない場合、他の鍵共有方式により暗号鍵を共有する。送信部は、暗号鍵と、暗号鍵の共有方式を示す情報とをアプリケーションに送信する。【選択図】図６
2018207348.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションから、前記アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信する受信部と、
前記暗号鍵を生成する生成部と、
前記通信先と接続された他の通信装置があるか否かを判定する判定部と、
前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できる場合、量子鍵配送により前記暗号鍵を共有し、量子鍵配送により前記暗号鍵を共有できない場合、他の鍵共有方式により前記暗号鍵を共有する共有制御部と、
前記暗号鍵と、前記暗号鍵の共有方式を示す情報とを前記アプリケーションに送信する送信部と、
を備える通信装置。
【請求項２】
前記送信部は、別途設定されたあるいは前記アプリケーションの種別によって決定される指定鍵共有方式を示す情報を参照し、前記指定鍵共有方式により指定された鍵共有方式により前記暗号鍵を共有できない場合、指定された鍵共有方式が使用できないことを示すエラー情報を前記アプリケーションに送信する、
請求項１に記載の通信装置。
【請求項３】
前記取得要求は、鍵共有方式を指定する情報を含み、
前記送信部は、前記取得要求により指定された鍵共有方式により前記暗号鍵を共有できない場合、指定された鍵共有方式が使用できないことを示すエラー情報を前記アプリケーションに送信する、
請求項１に記載の通信装置。
【請求項４】
前記送信部は、前記通信先と接続された他の通信装置がない場合、前記暗号鍵を提供できないことを示すエラー情報を前記アプリケーションに送信する、
請求項１に記載の通信装置。
【請求項５】
前記共有制御部は、前記暗号鍵の共有に使用される鍵共有ネットワークに含まれるリンク間の状態を示す情報を参照することにより、前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できるか否かを判定する、
請求項１に記載の通信装置。
【請求項６】
前記送信部は、前記暗号鍵が共有される際に利用されたリンクの経路を示す情報、前記リンクの経路毎のセキュリティ保護方式を示す情報、前記暗号鍵の生成方式を示す情報、前記他の通信装置と前記暗号鍵が共有された日時を示す情報、及び、自装置の性能情報のうち、少なくとも１つを前記アプリケーションに更に送信する、
請求項１に記載の通信装置。
【請求項７】
複数の通信装置と、アプリケーションを実行する複数の情報処理装置と、を備える通信システムであって、
前記通信装置は、
アプリケーションから、前記アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信する受信部と、
前記暗号鍵を生成する生成部と、
前記通信先と接続された他の通信装置があるか否かを判定する判定部と、
前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できる場合、量子鍵配送により前記暗号鍵を共有し、量子鍵配送により前記暗号鍵を共有できない場合、他の鍵共有方式により前記暗号鍵を共有する共有制御部と、
前記暗号鍵と、前記暗号鍵の共有方式を示す情報とを前記アプリケーションに送信する送信部と、
を備える通信システム。
【請求項８】
アプリケーションから、前記アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信するステップと、
前記暗号鍵を生成するステップと、
前記通信先と接続された他の通信装置があるか否かを判定するステップと、
前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できる場合、量子鍵配送により前記暗号鍵を共有し、量子鍵配送により前記暗号鍵を共有できない場合、他の鍵共有方式により前記暗号鍵を共有するステップと、
前記暗号鍵と、前記暗号鍵の共有方式を示す情報とを前記アプリケーションに送信するステップと、
を含む鍵共有方法。
【請求項９】
コンピュータを、
アプリケーションから、前記アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信する受信部と、
前記暗号鍵を生成する生成部と、
前記通信先と接続された他の通信装置があるか否かを判定する判定部と、
前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できる場合、量子鍵配送により前記暗号鍵を共有し、量子鍵配送により前記暗号鍵を共有できない場合、他の鍵共有方式により前記暗号鍵を共有する共有制御部と、
前記暗号鍵と、前記暗号鍵の共有方式を示す情報とを前記アプリケーションに送信する送信部、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は通信装置、通信システム、鍵共有方法及びプログラムに関する。
【背景技術】
【０００２】
光ファイバーにより接続された送信装置と、受信装置と、の間で連続的に送信された単一光子を利用して、安全に暗号鍵を共有する量子鍵配送（ＱＫＤ：Ｑｕａｎｔｕｍ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ）が従来から知られている。量子鍵配送により共有された暗号鍵は、量子力学の原理に基づいて、盗聴されていないことが保証されている。共有された暗号鍵は、例えばワンタイムパッド等の暗号データ通信に利用される。ワンタイムパッドにより送受信された暗号データは、如何なる知識を有する盗聴者によっても解読できないことが情報理論によって保証されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第５７８４５６２号公報
【特許文献２】特開２０１６−１７１５３０号公報
【特許文献３】特開２０１５−９７４２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら従来の技術では、量子鍵配送により共有された暗号鍵を利用できないアプリケーションがネットワーク内に存在する場合、ネットワーク内の通信の安全性を維持することが難しかった。本発明が解決しようとする課題は、量子鍵配送により共有された暗号鍵を利用できないアプリケーションがネットワーク内に存在する場合でも、ネットワーク内の通信の安全性を維持できるようにする通信装置、通信システム、鍵共有方法及びプログラムを提供することである。
【課題を解決するための手段】
【０００５】
実施形態の通信装置は、受信部と生成部と判定部と共有制御部と送信部とを備える。受信部は、アプリケーションから、前記アプリケーションの通信先との暗号データ通信に使用される暗号鍵の取得要求を受信する。生成部は、前記暗号鍵を生成する。判定部は、前記通信先と接続された他の通信装置があるか否かを判定する。共有制御部は、前記他の通信装置との間で、量子鍵配送により前記暗号鍵を共有できる場合、量子鍵配送により前記暗号鍵を共有し、量子鍵配送により前記暗号鍵を共有できない場合、他の鍵共有方式により前記暗号鍵を共有する。送信部は、前記暗号鍵と、前記暗号鍵の共有方式を示す情報とを前記アプリケーションに送信する。
【図面の簡単な説明】
【０００６】
【図１】通信システムの基本構成の例を説明するための図。
【図２】量子鍵配送ネットワークの例を示す図。
【図３】図２の量子鍵配送ネットワークによりグローバルキー（アプリ暗号鍵）を共有する方法の例を示すシーケンス図。
【図４】接続ノード情報の例を示す図。
【図５Ａ】量子鍵配送を行うノードに接続できないアプリケーションの例１を示す図。
【図５Ｂ】量子鍵配送を行うノードに接続できないアプリケーションの例２を示す図。
【図６】第１実施形態のノードの機能構成の例を示す図。
【図７】第１実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図。
【図８】第１実施形態の鍵共有方法の例を示すフローチャート。
【図９Ａ】第１実施形態の応答データのフォーマットの例１を示す図。
【図９Ｂ】第１実施形態の応答データのフォーマットの例２を示す図。
【図９Ｃ】第１実施形態の応答データのフォーマットの例３を示す図。
【図９Ｄ】第１実施形態の応答データのフォーマットの例４を示す図。
【図１０Ａ】第１実施形態の鍵共有方法が実施される通信システムの構成の例１を示す図。
【図１０Ｂ】図１０Ａの通信システムの構成に対応する接続ノード情報の例を示す図。
【図１１Ａ】第１実施形態の鍵共有方法が実施される通信システムの構成の例２を示す図。
【図１１Ｂ】図１１Ａの通信システムの構成に対応する接続ノード情報の例を示す図。
【図１１Ｃ】図１１Ａの通信システムの構成に対応するノード状態情報の例を示す図。
【図１２】第２実施形態のアプリケーションの暗号鍵取得方法の例を示すフローチャート。
【図１３】第２実施形態の変形例のアプリケーションの暗号鍵取得方法の例を示すフローチャート。
【図１４】第３実施形態のリンク情報の例を示す図。
【図１５】第４実施形態の応答データのフォーマットの例を示す図。
【図１６】第５実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図。
【図１７】第６実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図。
【図１８】第１乃至第６実施形態のノードの主要部のハードウェア構成の例を示す図。
【図１９】第１乃至第６実施形態のアプリケーションを動作させる情報処理装置のハードウェア構成の例を示す図。
【発明を実施するための形態】
【０００７】
以下に添付図面を参照して、通信装置、通信システム、鍵共有方法及びプログラムの実施形態を詳細に説明する。
【０００８】
（第１実施形態）
はじめに第１実施形態について説明する。
【０００９】
［基本構成］
図１は通信システムの基本構成の例を説明するための図である。図１の通信システムは、ノード１０ａ及び１０ｂを含む量子鍵配送システム、並びに、アプリケーション２０ａ及び２０ｂを含む暗号データ通信システムを備える。アプリケーション２０ａ及び２０ｂは、暗号データ通信ネットワーク１０１を介して暗号データ通信を行う。
【００１０】
ノード１０ａ及び１０ｂは、量子鍵配送を行うノード（Ｔｒｕｓｔｅｄ  Ｎｏｄｅ）である。図１の説明では、ノード１０ａを送信側の通信装置とし、ノード１０ｂを受信側の通信装置とする。以下、ノード１０ａ及び１０ｂを区別しない場合、単にノード１０という。
【００１１】
アプリケーション２０ａ及び２０ｂは、ノード１０ａ及び１０ｂにより共有された暗号鍵を使用して、暗号データ通信を行う。アプリケーション２０ａにより使用される暗号鍵は、ノード１０ａにより提供される。アプリケーション２０ｂにより使用される暗号鍵は、ノード１０ｂにより提供される。アプリケーション２０ａ及び２０ｂは、サーバ装置、パーソナルコンピュータ及びスマートデバイス等の情報処理装置により実行される。以下、アプリケーション２０ａ及び２０ｂを区別しない場合、単にアプリケーション２０という。なおアプリケーション２０を実行する情報処理装置は、ノード１０でもよい。
【００１２】
量子鍵配送技術により暗号鍵を共有する方式では、単一光子をメディアとして利用するので、暗号鍵を共有可能な距離の制約がある。そのため、図２に示すような量子鍵配送ネットワーク（ＱＫＤネットワーク）が利用される。
【００１３】
図２は量子鍵配送ネットワークの例を示す図である。図２の量子鍵配送ネットワークは、光ファイバーリンクにより接続されたノード１０ａ〜１０ｃを備える。アプリケーション２０ａを実行する情報処理装置は、ノード１０ａと接続される。また、アプリケーション２０ｃを実行する情報処理装置は、ノード１０ｃと接続される。アプリケーション２０ａ及び２０ｃは、暗号データ通信ネットワーク１０１を介して暗号データ通信を行う。
【００１４】
各ノード１０は、光ファイバーリンクによって接続された隣接するノード１０との間で量子鍵配送を行うことにより、暗号鍵を共有する。ここで、第１実施形態の説明では、光ファイバーリンクによって接続された隣接するノード間で量子鍵配送により共有される暗号鍵をローカルキーという。すなわちローカルキーは、リンク間で使用されるリンク鍵である。
【００１５】
さらにノード１０は、量子鍵配送とは無関係に、別途、乱数情報等から暗号鍵を生成する。第１実施形態の説明では、この暗号鍵をグローバルキーという。すなわちグローバルキーは、アプリケーション２０の暗号データ通信に使用されるアプリ暗号鍵である。
【００１６】
ノード１０は、グローバルキーをローカルキーにより暗号化し、暗号化されたグローバルキーを隣接するノード１０に転送する。各ノード１０は、隣接するノード１０との間で、ローカルキーにより暗号化されたグローバルキーを転送する処理を繰り返す。これにより各ノードは、任意のノード１０との間でグローバルキーを共有することができる。
【００１７】
上述のようにグローバルキーは、量子鍵配送によって共有されるローカルキーによって暗号化された状態でリンク上を転送される。したがって、ノード１０自体の安全性を仮定すると、グローバルキーの安全性は、ローカルキーと同様に保証されると言える。
【００１８】
図３は、図２の量子鍵配送ネットワークによりグローバルキー（アプリ暗号鍵）を共有する方法の例を示すシーケンス図である。図３の説明では、アプリケーション２０ａが、アプリケーション２０ｃと暗号データ通信を行う場合について説明する。
【００１９】
はじめに、ノード１０ａ及び１０ｂが、量子鍵配送によりローカルキーを共有する（ステップＳ１）。次に、ノード１０ｂ及び１０ｃが、量子鍵配送によりローカルキーを共有する（ステップＳ２）。
【００２０】
次に、アプリケーション２０ａが、アプリケーション２０ａの通信先との暗号データ通信に使用されるグローバルキーの取得要求を、ノード１０ａに送信する（ステップＳ３）。取得要求は、例えば通信先を特定する通信先特定情報を含む。通信先特定情報は、例えば、通信先のアプリケーション名、及び、通信先のアドレス等である。
【００２１】
次に、ノード１０ａが、ステップＳ３の処理により送信された取得要求に含まれる通信先と接続されるノード１０ｃを、グローバルキーを共有するノード１０として特定する（ステップＳ４）。具体的には、ノード１０ａは、例えば接続ノード情報を参照することにより、グローバルキーを共有するノード１０を特定する。接続ノード情報は、例えばアプリケーション２０とノード１０との接続関係が記述されたディレクトリデータである。
【００２２】
図４は接続ノード情報の例を示す図である。図４の接続ノード情報は、エントリＮｏ．、アプリＩＤ及びノードＩＤを含む。エントリＮｏ．は、接続ノード情報に含まれる各データを識別する番号である。アプリＩＤは、アプリケーション２０を識別する識別情報である。例えばＡは、アプリケーション２０ａのアプリＩＤを示す。ノードＩＤは、ノード１０を識別する識別情報である。図４の例では、ノード１０の識別情報としてＩＰアドレスが使用されている。
【００２３】
図３に戻り、次に、ノード１０ａは、グローバルキーを生成する（ステップＳ５）。生成されたグローバルキーは、当該グローバルキーを識別する鍵ＩＤ等の識別情報により識別される。次に、ノード１０ａは、ステップＳ１の処理により共有されたローカルキーにより、ステップＳ５の処理により生成されたグローバルキーを、当該グローバルキーの鍵ＩＤとともに暗号化する（ステップＳ６）。次に、ノード１０ａは、ステップＳ６の処理により暗号化されたグローバルキーをノード１０ｂに送信する（ステップＳ７）。
【００２４】
次に、ノード１０ｂは、ノード１０ａから暗号化されたグローバルキーを受信すると、当該暗号化されたグローバルキーの復号、及び、暗号化を行う（ステップＳ８）。具体的には、ノード１０ｂは、暗号化されたグローバルキーを、ステップＳ１の処理により共有されたローカルキーにより復号し、復号されたグローバルキーを、ステップＳ２の処理により共有されたローカルキーにより暗号化する。
【００２５】
次に、ノード１０ｂは、ステップＳ８の処理により暗号化されたグローバルキーを、ノード１０ｃに送信する（ステップＳ９）。
【００２６】
次に、ノード１０ｃが、ノード１０ｂから暗号化されたグローバルキーを受信すると、ステップＳ２の処理により共有されたローカルキーにより復号する（ステップＳ１０）。次に、ノード１０ｃは、ステップＳ１０の処理により復号されたグローバルキーを格納する（ステップＳ１１）。
【００２７】
次に、ノード１０ａが、ステップＳ５の処理により生成されたグローバルキーを、当該グローバルキーの鍵ＩＤとともにアプリケーション２０ａに提供する（ステップＳ１２）。
【００２８】
次に、アプリケーション２０ａが、ステップＳ１２の処理により提供されたグローバルキーの鍵ＩＤをアプリケーション２０ｃに通知する（ステップＳ１３）。
【００２９】
次に、アプリケーション２０ｃが、ステップＳ１３の処理により通知された鍵ＩＤを含むグローバルキーの取得要求を、ノード１０ｃに送信する（ステップＳ１４）。次に、アプリケーション２０ｃは、ステップＳ１４の処理により送信された鍵ＩＤにより識別されるグローバルキーを、ノード１０ｃから受信する（ステップＳ１５）。
【００３０】
次に、アプリケーション２０ａ及び２０ｂは、ステップＳ１〜ステップＳ１５の処理により共有されたグローバルキーにより、暗号データ通信を行う（ステップＳ１６）。
【００３１】
なお、上述の説明では、ステップＳ３の処理によりグローバルキーの取得要求がノード１０ａにより受信された後に、ステップＳ５〜ステップＳ１１の処理により、グローバルキーの共有処理を行われる場合について説明した。しかしながら、グローバルキーの共有処理を行われるタイミングは任意でよい。例えば、ノード１０ａは、ノード１０ａ及び１０ｃの間で予め共有されていたグローバルキーを、ステップＳ３の処理によりグローバルキーの取得要求を受信した後に使用してもよい。
【００３２】
また、上述の説明では、アプリケーション２０ａとアプリケーション２０ｃとの間の暗号データ通信に先立って、ステップＳ１３の処理により鍵ＩＤが通知される場合について説明した。しかしながら、鍵ＩＤの通知処理が行われるタイミングは任意でよい。例えば、アプリケーション２０ａは、ステップＳ１２の処理により提供されたグローバルキーにより暗号化された暗号データとともに、当該グローバルキーを識別する鍵ＩＤを、アプリケーション２０ｃに送信してもよい。
【００３３】
一般に、上述の各ノード１０は、それぞれ地理的に離れた場所に設置され、各アプリケーション２０は、各ノード１０上、または、ノード１０と同一のサーバールーム等で動作する情報処理装置上で実行される。ノード１０には、量子鍵配送を行うＱＫＤ装置が配備されている必要があるが、当該ＱＫＤ装置は一般に高価である。そのため、通信システムに必要な全てのノード１０を予め準備することは困難であり、通信システムの稼働後に、ノード１０が徐々に導入されていく可能性が考えられる。
【００３４】
図５Ａは、量子鍵配送を行うノード１０に接続できないアプリケーション２０の例１を示す図である。図５Ｂは、量子鍵配送を行うノード１０に接続できないアプリケーション２０の例２を示す図である。図５Ａ及びＢにおいて、Ｑは、ＱＫＤ装置を示す。Ｑ−Ｑで接続されたノード１０間のリンク（ＱＫＤリンク）は、ＱＫＤ装置が稼働していることを示す。一方、Ｑが示されていないノード１０間のリンクでは、ＱＫＤ装置が稼働していないことを示す。ＱＫＤ装置が稼働していない場合は、例えば当該ＱＫＤ装置が未配備である場合、及び、当該ＱＫＤ装置が故障中である場合等である。
【００３５】
図５Ａの例では、アプリケーション２０ｅ〜２０ｇには、接続可能なノード１０が存在しない。図５Ａの状況は、例えば量子鍵配送ネットワーク（ノード１０ａ〜１０ｄ）、及び、暗号データ通信ネットワーク（アプリケーション２０ａ〜２０ｄ）を含む通信システムと、現時点でノード１０の導入が済んでいないアプリケーション２０ｅ〜２０ｇを含むネットワークとを相互に接続し、さらに大規模な通信システムへと移行を進める状況等に相当する。
【００３６】
図５Ｂの例では、ノード１０ｅ〜１０ｇの量子鍵配送機能が利用できない。図５Ｂの状況は、例えばノード１０がコンピュータサーバとしては導入されたが、当該ノード１０に量子鍵配送を行う装置が配備されていない状況あるいは、該当ノード１０に導入されたＱＫＤ装置が稼働していないあるいは故障中である状況等に相当する。
【００３７】
第１実施形態の説明では、図５Ａ及び５Ｂ等のような場合でも、ネットワーク内の通信の安全性を維持できるようにする通信システムの動作について説明する。
【００３８】
［機能構成の例］
図６は第１実施形態のノード１０の機能構成の例を示す図である。第１実施形態のノード１０は、記憶部１１、受信部１２、生成部１３、判定部１４、共有制御部１５及び送信部１６を備える。
【００３９】
記憶部１１は情報を記憶する。記憶部１１に記憶される情報は、例えば接続ノード情報（図４及び図１０Ｂの説明を参照）、及び、ノード状態情報（図１１Ｃの説明を参照）である。
【００４０】
受信部１２は、アプリケーション２０から、アプリケーション２０の通信先との暗号データ通信に使用されるグローバルキーの取得要求を受信する。
【００４１】
ここで、暗号データ通信セッションを開始する側のアプリケーション２０をマスターと呼び、暗号データ通信セッションを受け付ける側のアプリケーション２０をスレーブと呼ぶこととする。グローバルキーの取得要求を、ウェブＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）によって実現する場合、当該ウェブＡＰＩは、例えば図７のように定義される。
【００４２】
図７は第１実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図である。
【００４３】
図７の例では、上述の通信先特定情報は、ｕｒｌに含まれる｛アプリ名｝である。また、ｕｒｌに含まれる｛ＱＫＤ？ＡＮＹ？｝は、鍵タイプを示す。なお、より具体的には、｛ＱＫＤ？ＡＮＹ？｝は、ＱＫＤかあるいはＡＮＹのいずれかを取るという意味であり、例えばＱＫＤを採用する場合は、／アプリ名／ＱＫＤ／ｅｎｃ＿ｋｅｙｓ．ｊｓｏｎ、ＡＮＹをとる場合は、／アプリ名／ＡＮＹ／ｅｎｃ＿ｋｅｙｓ．ｊｓｏｎ等となる。同様に、例えば鍵タイプの指定方法が３種類ある場合には、ｕｒｌに｛ＱＫＤ？ＡＮＹ？ＤＨ？｝が含まれる。
【００４４】
鍵タイプは、グローバルキーの共有方式を示す。鍵タイプがＱＫＤの場合、アプリケーション２０が、量子鍵配送により共有されたグローバルキーを要求していることを示す。
【００４５】
鍵タイプがＡＮＹの場合、アプリケーション２０が、量子鍵配送以外の鍵共有方式により共有されたグローバルキーも許容していることを示す。鍵タイプがＡＮＹの場合、アプリケーション２０は、取得されたグローバルキーの鍵タイプに応じて、その後の動作を変更してもよい。
【００４６】
マスター向けのウェブＡＰＩにはインプットがなく、スレーブ向けのウェブＡＰＩには鍵ＩＤのインプットがある理由について説明する。これは、スレーブ側では、マスター側から通知された鍵ＩＤを、スレーブ向けのウェブＡＰＩのインプットに設定することにより、マスター側で取得されたグローバルキーと同じグローバルキーを取得するためである。
【００４７】
図６に戻り、生成部１３は、グローバルキーを生成する。
【００４８】
判定部１４は、受信部１２により受信された取得要求に含まれる通信先と接続されるノード１０があるか否かを判定する。
【００４９】
共有制御部１５は、通信先と接続されるノード１０との間で、量子鍵配送によりグローバルキーを共有できる場合、量子鍵配送によりグローバルキーを共有し、量子鍵配送によりグローバルキーを共有できない場合、他の鍵共有方式によりグローバルキーを共有する。他の鍵共有方式は、例えばディフィー・ヘルマン（ＤＨ：Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）鍵共有方式である。
【００５０】
送信部１６は、グローバルキーと、当該グローバルキーの共有方式を示す情報とをアプリケーション２０に送信する。
【００５１】
［鍵共有方法］
図８は、第１実施形態の鍵共有方法の例を示すフローチャートである。はじめに、受信部１２が、アプリケーション２０から、当該アプリケーション２０の通信先との暗号データ通信に使用されるグローバルキーの取得要求を受信する（ステップＳ３１）。グローバルキーの取得要求は、上述の鍵タイプ（ＱＫＤ又はＡＮＹ）、及び、上述の通信先特定情報を含む。
【００５２】
次に、判定部１４が、ステップＳ３１の処理により送信された取得要求に含まれる通信先と接続されるノード１０があるか否かを判定する（ステップＳ３２）。
【００５３】
通信先と接続されるノード１０がない場合（ステップＳ３２，Ｎｏ）、送信部１６が、グローバルキーを提供できないことを示すエラー情報をアプリケーション２０に送信する（ステップＳ３３）。
【００５４】
通信先と接続されるノード１０がある場合（ステップＳ３２，Ｙｅｓ）、共有制御部１５が、量子鍵配送（ＱＫＤ）が利用可能であるか否かを判定する（ステップＳ３４）。
【００５５】
量子鍵配送（ＱＫＤ）が利用可能である場合（ステップＳ３４，Ｙｅｓ）、共有制御部１５が、ＱＫＤにより共有されたグローバルキーを応答データに設定する（ステップＳ３５）。次に、共有制御部１５は、鍵タイプ（ＱＫＤ）を応答データに設定する（ステップＳ３８）。次に、送信部１６が、グローバルキーと、当該グローバルキーの共有方式を示す鍵タイプ（ＱＫＤ）とを含む応答データを、アプリケーション２０に送信する（ステップＳ３９）。このとき、送信される応答データは、例えば図９Ａ及び９Ｂのようになる。
【００５６】
図９Ａは第１実施形態の応答データのフォーマットの例１を示す図である。図９Ｂは第１実施形態の応答データのフォーマットの例２を示す図である。“Ｋｅｙ  ＩＤ”は、鍵ＩＤを示す。“Ｋｅｙ”は、鍵データ（グローバルキー）を示す。“Ｋｅｙ  ｔｙｐｅ”は、鍵タイプを示す。図９Ａ及び図９Ｂの例では、鍵タイプにＱＫＤが設定されている。
【００５７】
図８に戻り、量子鍵配送（ＱＫＤ）が利用可能でない場合（ステップＳ３４，Ｎｏ）、共有制御部１５が、ステップＳ３１の処理により受信された取得要求を参照することにより、ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容されるか否かを判定する（ステップＳ３６）。ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容されない場合（ステップＳ３６，Ｎｏ）、送信部１６が、グローバルキーを提供できないことを示すエラー情報をアプリケーション２０に送信する（ステップＳ３３）。
【００５８】
ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容される場合（ステップＳ３６，Ｙｅｓ）、共有制御部１５が、ＤＨ（ＱＫＤ以外の鍵共有方式）により共有されたグローバルキーを応答データに設定する（ステップＳ３７）。次に、共有制御部１５、鍵タイプ（ＤＨ）を応答データに設定する（ステップＳ３８）。次に、送信部１６が、グローバルキーと、当該グローバルキーの共有方式を示す鍵タイプ（ＤＨ）とを含む応答データを、アプリケーション２０に送信する（ステップＳ３９）。このとき、送信される応答データは、例えば図９Ｃ及び９Ｄのようになる。
【００５９】
図９Ｃは第１実施形態の応答データのフォーマットの例３を示す図である。図９Ｄは第１実施形態の応答データのフォーマットの例４を示す図である。“Ｋｅｙ  ＩＤ”は、鍵ＩＤを示す。“Ｋｅｙ”は、鍵データ（グローバルキー）を示す。“Ｋｅｙ  ｔｙｐｅ”は、鍵タイプを示す。図９Ｃ及び図９Ｄの例では、鍵タイプにＤＨが設定されている。
【００６０】
＜具体例の説明＞
図１０Ａは第１実施形態の鍵共有方法が実施される通信システムの構成の例１を示す図である。図１０Ｂは、図１０Ａの通信システムの構成に対応する接続ノード情報の例を示す図である。
【００６１】
図１０Ａの通信システムは、ノード１０ａ及び１０ｂ、並びに、アプリケーション２０ａ〜２０ｄを備える。アプリケーション２０ｃ及び２０ｄには、接続可能なノード１０が存在しない。図１０Ａでは、アプリケーション２０ａが、アプリケーション２０ｃと暗号データ通信を行うためのグローバルキーの取得要求を送信する場合を例にして説明する。
【００６２】
はじめに、アプリケーション２０ａが、アプリケーション２０ｃとの暗号データ通信に使用されるグローバルキーの取得要求を、ノード１０ａに送信する。次に、ノード１０ａの判定部１４が、図１０Ｂの接続ノード情報を参照して、アプリケーション２０ｃと接続されるノード１０があるか否かを判定する。図１０Ｂの接続ノード情報では、アプリケーション２０ｃのアプリＩＤを含むデータが存在しない。そのため、ノード１０の判定部１４は、図１０Ｂの接続ノード情報から、アプリケーション２０ｃと接続されるノード１０がないことを特定することができる。次に、ノード１０の送信部１６が、グローバルキーを提供できないことを示すエラー情報をアプリケーション２０ａに送信する。
【００６３】
図１１Ａは第１実施形態の鍵共有方法が実施される通信システムの構成の例２を示す図である。図１１Ｂは、図１１Ａの通信システムの構成に対応する接続ノード情報の例を示す図である。図１１Ｃは、図１１Ａの通信システムの構成に対応するノード状態情報の例を示す図である。
【００６４】
図１１Ａの通信システムは、ノード１０ａ〜１０ｄ、及び、アプリケーション２０ａ〜２０ｄを備える。アプリケーション２０ｃに接続されるノード１０ｃには、ＱＫＤ装置が未配備又は故障中である。同様に、アプリケーション２０ｄに接続されるノード１０ｄには、ＱＫＤ装置が未配備又は故障中である。図１１Ａでは、アプリケーション２０ａが、アプリケーション２０ｃと暗号データ通信を行うためのグローバルキーの取得要求を送信する場合を例にして説明する。
【００６５】
はじめに、アプリケーション２０ａが、アプリケーション２０ｃとの暗号データ通信に使用されるグローバルキーの取得要求を、ノード１０ａに送信する。グローバルキーの取得要求は、上述の鍵タイプ（ＱＫＤ又はＡＮＹ）、及び、上述の通信先特定情報を含む。
【００６６】
次に、ノード１０ａの判定部１４が、図１１Ｂの接続ノード情報を参照して、アプリケーション２０ｃと接続されるノード１０ｃがあるか否かを判定する。図１１Ｂの接続ノード情報では、アプリケーション２０ｃのアプリＩＤ（Ｃ）を含むデータが存在する。そのため、ノード１０ａの判定部１４は、図１１Ｂの接続ノード情報から、アプリケーション２０ｃと接続されるノード１０ｃがあることを特定することができる。
【００６７】
次に、ノード１０ａの共有制御部１５が、図１１Ｃのノード状態情報を参照して、量子鍵配送（ＱＫＤ）が利用可能であるか否かを判定する。ここで、ノード状態情報について説明する。
【００６８】
図１１Ｃのノード状態情報は、エントリＮｏ．、ノード及び状態を含む。エントリＮｏ．は、ノード状態情報に含まれる各データを識別する番号である。ノードは、各ノード１０を示す。具体的には、「ＴＮ１」は、ノード１０ａを示す。「ＴＮ２」は、ノード１０ｂを示す。「ＴＮ３」は、ノード１０ｃを示す。「ＴＮ４」は、ノード１０ｄを示す。状態は、量子鍵配送が利用可能であるか否かを示す。具体的には、「ＱＫＤ  ｅｎａｂｌｅ」は、量子鍵配送が利用可能であることを示す。「Ｎｏ  ＱＫＤ」は、量子鍵配送が利用可能でないことを示す。
【００６９】
ノード１０の共有制御部１５は、図１１Ｃのノード状態情報から、アプリケーション２０ｃと接続されるノード１０ｃでは量子鍵配送が利用できないことを特定することができる。
【００７０】
グローバルキーの取得要求に含まれる鍵タイプがＱＫＤの場合、ノード１０の送信部１６が、グローバルキーを提供できないことを示すエラー情報をアプリケーション２０ａに送信する。
【００７１】
グローバルキーの取得要求に含まれる鍵タイプがＡＮＹの場合、ノード１０の共有制御部１５が、ノード１０ａ及び１０ｃの間でＤＨ鍵共有方式によりグローバルキーを共有する。なお、ＤＨ鍵共有方式によりグローバルキーを共有するタイミングは任意でよい。ノード１０ａ及び１０ｃは、ＤＨ鍵共有方式により事前に共有されていたグローバルキーを使用してもよい。次に、ノード１０ａの送信部１６は、上述の図９Ｃ及び９Ｄのような応答データをアプリケーション２０ａに送信する。
【００７２】
アプリケーション２０ａは、ノード１０ａから、上述の図９Ｃ及び９Ｄのような応答データを受信する。これによりアプリケーション２０ａは、ノード１０ａから提供されたグローバルキーは、量子鍵配送（ＱＫＤ）によってその安全性が保証されたものではなく、ＤＨ鍵共有方式によって共有されていることを特定することができる。そのため、アプリケーション２０ａは、鍵タイプに応じた動作をすることができる。
【００７３】
アプリケーション２０ａは、例えばグローバルキーがＤＨ鍵共有方式によって共有されている場合、当該グローバルキーのリフレッシュレートを、量子鍵配送（ＱＫＤ）により共有されたグローバルキーのリフレッシュレートよりも短くしてもよい。また例えば、アプリケーション２０ａは、グローバルキーがＤＨ鍵共有方式によって共有されている場合、アプリケーション２０へ送信されるコンテンツを変更してもよい。また例えば、アプリケーション２０ａは、グローバルキーがＤＨ鍵共有方式によって共有されている場合、アプリケーション２０ｃとの間で通信を行わなくてもよい。
【００７４】
以上説明したように、第１実施形態のノード１０（通信装置）では、受信部１２が、アプリケーション２０から、アプリケーション２０の通信先との暗号データ通信に使用されるグローバルキー（アプリ暗号鍵）の取得要求を受信する。生成部１３が、グローバルキーを生成する。判定部１４が、アプリケーション２０の通信先と接続された他のノード１０があるか否かを判定する。共有制御部１５が、他のノード１０との間で、量子鍵配送によりグローバルキーを共有できる場合、量子鍵配送によりグローバルキーを共有し、量子鍵配送によりグローバルキーを共有できない場合、他の鍵共有方式によりグローバルキーを共有する。そして、送信部１６が、グローバルキーと、当該グローバルキーの共有方式を示す鍵タイプとをアプリケーション２０に送信する。
【００７５】
これにより第１実施形態のノード１０によれば、量子鍵配送により共有された暗号鍵を利用できないアプリケーションがネットワーク内に存在する場合でも、ネットワーク内の通信の安全性を維持できるようにすることができる。例えば、アプリケーション２０が、取得されたグローバルキーの鍵タイプに応じて、その後の動作を変更することができる。
【００７６】
（第２実施形態）
次に第２実施形態について説明する。第２実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。第２実施形態では、アプリケーション２０が、上述のグローバルキーの取得要求を送信する前に、上述の接続ノード情報を参照できる場合について説明する。
【００７７】
図１２は第２実施形態のアプリケーションの暗号鍵取得方法の例を示すフローチャートである。はじめに、アプリケーション２０が、上述の接続ノード情報を参照して、アプリケーション２０の通信先と接続されるノード１０があるか否かを判定する（ステップＳ５１）。
【００７８】
アプリケーション２０の通信先と接続されるノード１０がない場合（ステップＳ５１，Ｎｏ）、処理を終了する。
【００７９】
アプリケーション２０の通信先と接続されるノード１０がある場合（ステップＳ５１，Ｙｅｓ）、アプリケーション２０が、当該アプリケーション２０の通信先と暗号データ通信を行うためのグローバルキーの取得要求を、当該アプリケーション２０に接続されたノード１０に送信する（ステップＳ５２）。次に、アプリケーション２０が、ノード１０から、上述の応答データを受信する（ステップＳ５３）。次に、アプリケーション２０が、ステップＳ５３の処理により受信された応答データに含まれるグローバルキーを利用して、アプリケーション２０の通信先と暗号データ通信を行う（ステップＳ５４）。
【００８０】
（第２実施形態の変形例）
次に第２実施形態の変形例について説明する。第２実施形態の変形例では、アプリケーション２０が、上述のグローバルキーの取得要求を送信する前に、上述の接続ノード情報だけでなく、上述のノード状態情報も参照できる場合について説明する。
【００８１】
図１３は第２実施形態の変形例のアプリケーションの暗号鍵取得方法の例を示すフローチャートである。はじめに、アプリケーション２０が、上述の接続ノード情報を参照して、アプリケーション２０の通信先と接続されるノード１０があるか否かを判定する（ステップＳ６１）。
【００８２】
アプリケーション２０の通信先と接続されるノード１０がない場合（ステップＳ６１，Ｎｏ）、処理を終了する。
【００８３】
アプリケーション２０の通信先と接続されるノード１０がある場合（ステップＳ６１，Ｙｅｓ）、アプリケーション２０が、上述のノード状態情報を参照して、アプリケーション２０に接続されたノード１０と、当該アプリケーション２０の通信先に接続されたノード１０との間で量子鍵配送（ＱＫＤ）が利用可能であるか否かを判定する（ステップＳ６２）。
【００８４】
ＱＫＤが利用可能でない場合（ステップＳ６２，Ｎｏ）、アプリケーション２０が、ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容されるか否かを判定する（ステップＳ６３）。ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容されない場合（ステップＳ６３，Ｎｏ）、処理を終了する。
【００８５】
ＱＫＤが利用可能である場合（ステップＳ６２，Ｙｅｓ）、又は、ＱＫＤ以外の鍵共有方式により共有されたグローバルキーが許容される場合（ステップＳ６３，Ｙｅｓ）、アプリケーション２０が、当該アプリケーション２０の通信先と暗号データ通信を行うためのグローバルキーの取得要求を、当該アプリケーション２０に接続されたノード１０に送信する（ステップＳ６４）。次に、アプリケーション２０が、ノード１０から、上述の応答データを受信する（ステップＳ６５）。次に、アプリケーション２０が、ステップＳ６４の処理により受信された応答データに含まれるグローバルキーを利用して、アプリケーション２０の通信先と暗号データ通信を行う（ステップＳ６６）。
【００８６】
以上説明したように、第２実施形態及びその変形例によれば、アプリケーション２０が実行されることにより実現される情報処理装置の機能によっても、第１実施形態と同様の効果が得られる。
【００８７】
（第３実施形態）
次に第３実施形態について説明する。第３実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。
【００８８】
第１実施形態では、ノード１０の共有制御部１５が、あるノード１０がＱＫＤに対応しているか否かを、上述のノード状態情報を参照することにより判定する場合について説明した。第３実施形態は、ある量子鍵配送（ＱＫＤ）ネットワーク（ＱＫＤ装置配備済み）と、今後、ＱＫＤ装置を導入予定の一般的なネットワークと、を接続しようとするようなケースに好適である。
【００８９】
一方、ＱＫＤ装置をネットワークにおけるリンク毎に徐々に導入していくようなケースでは、あるノード１０とあるノード１０との間が、量子鍵配送を利用可能なＱＫＤリンクで完全に保護されているか否かは判断が難しくなる。
【００９０】
同様に、ある量子鍵配送（ＱＫＤ）ネットワークの一部のＱＫＤリンクに障害が発生したような場合、あるノード１０間のグローバルキーの共有動作が、その影響を受けるか否かの判断も難しいケースがある。
【００９１】
第３実施形態では、これらの状況において、量子鍵配送（ＱＫＤ）が利用可能であるか否かを、できるだけ正確に判断可能とするための方法１及び２について説明する。
【００９２】
＜方法１＞
方法１は、ノード１０の共有制御部１５が、上述の接続ノード情報、及び、上述のノード状態情報に加え、リンク情報を参照する方法である。
【００９３】
図１４は第３実施形態のリンク情報の例を示す図である。第３実施形態のリンク情報は、エントリＮｏ．、リンク及び状態を含む。エントリＮｏ．は、リンク情報に含まれる各データを識別する番号である。リンクは、ノード１０間の各リンクを示す。状態は、各リンクの状態を示す。「ＱＫＤ  ａｃｔｉｖｅ」は、量子鍵配送（ＱＫＤ）が利用可能であることを示す。「ＱＫＤ  ｅｒｒｏｒ」は、リンクに異常が発生していることにより、量子鍵配送（ＱＫＤ）が利用できないことを示す。「Ｎｏ  ＱＫＤ」は、リンクの両端のノード１０にＱＫＤ装置が未配備であることにより、量子鍵配送（ＱＫＤ）が利用できないことを示す。共有制御部１５は、リンク情報を参照することにより、量子鍵配送（ＱＫＤ）ネットワークのリンク毎に、量子鍵配送（ＱＫＤ）が利用可能であるか否かを判定することができる。
【００９４】
図１４の例では、共有制御部１５は、例えばリンクＴＮ２−ＴＮ３の状態が「ＱＫＤ  ｅｒｒｏｒ」なので、リンクＴＮ２−ＴＮ３では量子鍵配送（ＱＫＤ）が利用可能でないと判定する。
【００９５】
共有制御部１５は、グローバルキーの共有が行われるノード１０の経路と、リンク情報とから、経路上の全てのリンクで量子鍵配送（ＱＫＤ）が利用可能であるか否かを判定することができる。経路上の全てのリンクで量子鍵配送（ＱＫＤ）が利用可能な場合、グローバルキーは量子鍵配送（ＱＫＤ）によって保護されているとすることができる。したがって、共有制御部１５は、経路上の全てのリンクで量子鍵配送（ＱＫＤ）が利用可能な場合、上述の応答データの鍵タイプにＱＫＤを設定する。
【００９６】
なお、図１４のリンク情報の状態に、量子鍵配送（ＱＫＤ）に関する情報だけでなく、リンクのセキュリティという観点から、量子鍵配送（ＱＫＤ）以外の情報を保持させてもよい。例えば量子鍵配送（ＱＫＤ）でなく、他の鍵共有方式によって、リンクの安全性を保護している場合に、当該リンクの状態として、その情報を保持させてもよい。すなわち、あるリンク（例えばＴＮ１−ＴＮ２間）の安全性が、ＤＨ鍵共有方式によって保護されている場合、リンクＴＮ１−ＴＮ２の状態に、ＤＨが保持されてもよい。
【００９７】
ここで、グローバルキーの実際の共有経路情報をどのように把握して、上記リンク情報を参照するかという課題がある。以下に３つの案を説明する。
【００９８】
案１は、ソースルーティングを用いる方法である。ソースルーティングは、例えば上述の図５Ａのノード１０ａとノード１０ｃとがグローバルキーを共有する場合、ノード１０ａの共有制御部１５が、その経路を、例えばノード１０ａ―ノード１０ｂ―ノード１０ｃにより指定する方法である。
【００９９】
案２は、ノード１０の共有制御部１５が、グローバルキーの共有動作を行う前又は後にその経路を調査する方法である。具体的には、共有制御部１５が、ｔｒａｃｅｒｏｕｔｅコマンド等の機能を利用することにより、経路を調査することができる。
【０１００】
案３は、グローバルキーの共有動作を行う度に、途中経路上のノード１０の共有制御部１５が、自装置のノード情報（またはリンク情報であってもよい）を、共有されるグローバルキーの付加情報として付加しながら転送してゆく方法である。
【０１０１】
ノード１０の共有制御部１５は、上述の案１乃至案３のいずれかを利用することによって、グローバルキーの共有経路を正確に特定することができる。そのため、共有制御部１５は、グローバルキーの鍵タイプを正確に付与することができる。
【０１０２】
＜方法２＞
方法２は、アプリケーション２０が接続する鍵共有ネットワークとして、量子鍵配送（ＱＫＤ）により保護された第１の鍵共有ネットワークと、量子鍵配送以外の鍵共有方式により保護された第２の鍵共有ネットワークを用意する方法である。
【０１０３】
第１の鍵共有ネットワークを構成するノード１０間の全てのリンクは、量子鍵配送（ＱＫＤ）によって保護される。一方、第２の鍵共有ネットワークは、量子鍵配送（ＱＫＤ）によって保護されていないリンクを含む。
【０１０４】
ノード１０の共有制御部１５は、まず、第１の鍵共有ネットワークを介して、グローバルキーの共有を試みる。第１の鍵共有ネットワークを介してグローバルキーを共有することに成功した場合、当該グローバルキーは量子鍵配送（ＱＫＤ）によって安全性が保障される。この場合、共有制御部１５は、グローバルキーの鍵タイプをＱＫＤに設定する。
【０１０５】
共有制御部１５は、第１の鍵共有ネットワークを介してグローバルキーを共有することに失敗した場合、例えばＤＨ鍵共有方式により保護された第２の鍵共有ネットワークを介して、グローバルキーの共有を試みる。この場合、共有制御部１５は、グローバルキーの鍵タイプをＤＨに設定する。
【０１０６】
以上説明したように、第３実施形態の通信システムによれば、量子鍵配送（ＱＫＤ）が利用可能であるか否かを、より正確に判断することができ、かつ、第１実施形態と同様の効果が得られる。
【０１０７】
（第４実施形態）
次に第４実施形態について説明する。第４実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。第４実施形態では、上述の応答データに更に情報を付与する場合について説明する。
【０１０８】
図１５は第４実施形態の応答データのフォーマットの例を示す図である。“ｋｅｙｓ”フィールドは、上述の“ｋｅｙ  ＩＤ”、及び、上述の“Ｋｅｙ”を含む。“ｒｅｓｅｒｖｅｄ”フィールドは、上述の”Ｋｅｙ  ｔｙｐｅ”に加えて、“ｒｏｕｔｅ”、“ｌｉｎｋ”及び“ｄａｔｅ”を含む。
【０１０９】
“ｒｏｕｔｅ”は、グローバルキーの共有に使用されたノード１０を示す。
【０１１０】
“ｌｉｎｋ”は、グローバルキーの共有に使用されたリンク、及び、当該リンクのセキュリティ保護方式を示す。
【０１１１】
“ｄａｔｅ”は、グローバルキーが共有された日時を示す。
【０１１２】
なお応答データには、上記以外の情報を付与されてもよい。例えば、グローバルキーの生成方式を示す情報として、グローバルキーの生成に利用された乱数の質、又は、乱数生成器に関する情報が、応答データに付与されてもよい。
【０１１３】
また例えば、リンクのセキュリティ保護方式として、上述の鍵共有方式だけでなく、鍵共有方式の詳細情報が、応答データに付与されてもよい。鍵共有方式の詳細情報は、例えば量子鍵配送（ＱＫＤ）の場合、使用されるプロトコル（ＢＢ８４及びＥ９１等）、及び、使用されるセキュリティ理論等を示す。
【０１１４】
また例えば、ノード１０の性能情報が、応答データに付与されてもよい。ノード１０の性能情報は、例えばノード１０に配備されたＱＫＤ装置のベンダー名等である。なお、ＱＫＤ装置が未導入のノード１０の場合は、ＱＫＤ装置の導入予定時期等をノード１０の性能情報に含めてもよい。
【０１１５】
以上説明したように、第４実施形態の通信システムによれば、アプリケーション２０が、応答データに付与された情報から、取得されたグローバルキーの安全性をより詳細に判断することができる。
【０１１６】
（第５実施形態）
次に第５実施形態について説明する。第５実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。第５実施形態では、グローバルキーの鍵共有方式を、アプリケーション２０により指定できるようにする場合について説明する。
【０１１７】
図１６は第５実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図である。図１６のウェブＡＰＩの例では、ｕｒｌに｛ＱＫＤ？ＤＨ？ＡＮＹ？｝が含まれる。ＱＫＤ及びＡＮＹは、上述の図７の説明と同じである。ＤＨの場合、アプリケーション２０が、ＤＨ鍵共有方式により共有されたグローバルキーを要求していることを示す。
【０１１８】
以上説明したように、第５実施形態の通信システムによれば、利用可能な暗号方式が異なるアプリケーション２０が混在している場合でも、アプリケーション２０に適切なグローバルキーを提供することができる。
【０１１９】
（第６実施形態）
次に第６実施形態について説明する。第６実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。第６実施形態では、ウェブＡＰＩのＵＲＬに鍵タイプが埋め込まれないケースについて説明する。図１７は、第６実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図である。図１７のウェブＡＰＩの例では、ｕｒｌに鍵タイプ情報は含まれない。第１実施形態において、鍵タイプの情報は、アプリケーション２０がＱＫＤ以外を許容するか否かを判断するために利用した。ただし、アプリケーション２０がＱＫＤ以外を許容するか否かの情報は、ＵＲＬに埋め込む以外の方法も可能である。例えば、指定鍵共有方式を示す情報として、アプリケーション２０毎にＱＫＤ以外を許容するか否かを示す情報を、あらかじめノード１０が保持しておく場合もある。
【０１２０】
また、指定鍵共有方式を示す情報を、ＵＲＬへの埋め込み以外のアプリケーション２０のパラメータとして保持させる方法もある。また、システム全体あるいはノード全体のシステム設定として、指定鍵共有方式を示す情報（例えばＱＫＤ以外を許容するか否かを示す情報）を保持しておくケースもある。さらには、アプリケーション２０の種別に応じて、指定鍵共有方式を示す情報（例えばＱＫＤを許容するアプリケーション２０であるか否かを示す情報）を、ノード１０あるいはシステム側が判断する方法もある。
【０１２１】
例えばノード１０の送信部１６は、別途設定されたあるいはアプリケーション２０の種別によって決定される指定鍵共有方式を示す情報を参照し、指定鍵共有方式により指定された鍵共有方式によりグローバルキー（アプリ暗号鍵）を共有できない場合、指定された鍵共有方式が使用できないことを示すエラー情報をアプリケーション２０に送信する。
【０１２２】
図１７は第６実施形態のグローバルキー（アプリ暗号鍵）の取得要求の例を示す図である。図１７に示すようなウェブＡＰＩを利用する場合、鍵タイプの指定機能に対応していないアプリケーション２０がノード１０に接続してきた場合であっても、「ノード１０に接続して暗号鍵を取得し、暗号鍵を利用して暗号通信を行う」という、基本的な機能は動作させることができる。ここで、例えば図９Ａ乃至図９Ｄに示した、アプリケーションに返される鍵データに含まれる“ｋｅｙ  ｔｙｐｅ”の情報は、オプションあるいは拡張フィールドとして扱われ、この拡張を理解しないアプリケーションは鍵タイプ情報を無視できることが重要である。
【０１２３】
なお、図１５に示す鍵データに含まれるｒｅｓｅｒｖｅｄフィールドも同様であり、これに対応しないアプリケーション２０はこれを無視でき、これに対応するアプリケーション２０のみがこれを解釈して鍵データの利用方法の判断に利用できる点が重要である。このようにすることによって、鍵タイプの指定機能や実施例に示す拡張応答データの解釈等の機能は拡張機能であって、これらに対応しない基本的な機能のみをもつアプリケーション２０、本願で述べた各種拡張機能を備えるアプリケーション２０、の両方を同時に許容できる柔軟なシステムとすることができる。
【０１２４】
また、ウェブＡＰＩとしては図１７の構成としておくことで、本願で述べたような機能構成を、アプリケーション２０の変更無く導入することも可能となる点もまた重要である。
【０１２５】
最後に、第１乃至第６実施形態の通信システムのハードウェア構成の例について説明する。
【０１２６】
［ハードウェア構成の例］
図１８は第１乃至第６実施形態のノード１０の主要部のハードウェア構成の例を示す図である。第１乃至第６実施形態のノード１０は、制御装置２０１、主記憶装置２０２、補助記憶装置２０３、表示装置２０４、入力装置２０５、量子通信ＩＦ（Ｉｎｔｅｒｆａｃｅ）２０６及び古典通信ＩＦ２０７を備える。
【０１２７】
制御装置２０１、主記憶装置２０２、補助記憶装置２０３、表示装置２０４、入力装置２０５、量子通信ＩＦ２０６及び古典通信ＩＦ２０７は、バス２１０を介して接続されている。
【０１２８】
制御装置２０１は、補助記憶装置２０３から主記憶装置２０２に読み出されたプログラムを実行する。主記憶装置２０２は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等のメモリである。補助記憶装置２０３は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）及びメモリカード等である。
【０１２９】
表示装置２０４は、ノード１０の状態等を表示する。入力装置２０５はユーザーからの入力を受け付ける。
【０１３０】
量子通信ＩＦ２０６は、単一光子が送信される量子通信路に接続するためのインターフェースである。なお、ＱＫＤ装置が配備されていないノード１０の場合、量子通信ＩＦ２０６はなくてもよい。
【０１３１】
古典通信ＩＦ２０７は、イーサネット（登録商標）等の古典通信路（制御通信路）に接続するためのインターフェースである。なお古典通信ＩＦ２０７は、無線方式でもよい。
【０１３２】
第１乃至第６実施形態のノード１０は、図１８のハードウェア構成を備えていれば、汎用のコンピュータ等を含む任意の装置により実現可能である。
【０１３３】
第１乃至第６実施形態のノード１０で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、メモリカード、ＣＤ−Ｒ、及び、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）等のコンピュータで読み取り可能な記憶媒体に記憶されてコンピュータ・プログラム・プロダクトとして提供される。
【０１３４】
また第１乃至第６実施形態のノード１０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。
【０１３５】
また第１乃至第６実施形態のノード１０が実行するプログラムを、ダウンロードさせずにインターネット等のネットワーク経由で提供するように構成してもよい。
【０１３６】
また第１乃至第６実施形態のノード１０で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１３７】
第１乃至第６実施形態のノード１０で実行されるプログラムは、第１乃至第６実施形態のノード１０の機能構成のうち、プログラムにより実現可能な機能を含むモジュール構成となっている。
【０１３８】
プログラムにより実現される機能は、制御装置２０１が補助記憶装置２０３等の記憶媒体からプログラムを読み出して実行することにより、主記憶装置２０２にロードされる。すなわちプログラムにより実現される機能は、主記憶装置２０２上に生成される。
【０１３９】
なお第１乃至第６実施形態のノード１０の機能の一部又は全部を、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等のハードウェアにより実現してもよい。ＩＣは、例えば専用の処理を実行するプロセッサである。
【０１４０】
また複数のプロセッサを用いて各機能を実現する場合、各プロセッサは、各機能のうち１つを実現してもよいし、各機能のうち２つ以上を実現してもよい。
【０１４１】
また第１乃至第６実施形態のノード１０の動作形態は任意でよい。第１乃至第６実施形態のノード１０を、例えばネットワーク上のクラウドシステムを構成する装置として動作させてもよい。
【０１４２】
図１９は第１乃至第６実施形態のアプリケーション２０を動作させる情報処理装置のハードウェア構成の例を示す図である。なおアプリケーション２０をノード１０で動作させる場合は、ハードウェア構成はノード１０（図１８参照）と同じである。第１乃至第６実施形態のアプリケーション２０を動作させる情報処理装置は、制御装置３０１、主記憶装置３０２、補助記憶装置３０３、表示装置３０４、入力装置３０５及び通信ＩＦ３０６を備える。
【０１４３】
制御装置３０１、主記憶装置３０２、補助記憶装置３０３、表示装置３０４及び通信ＩＦ３０６は、バス３１０を介して接続されている。制御装置３０１、主記憶装置３０２、及び補助記憶装置３０３の説明は、図１８の制御装置２０１、主記憶装置２０２、及び補助記憶装置２０３の説明と同様であるので省略する。
【０１４４】
表示装置３０４は、情報処理装置で動作するアプリケーション２０の状態等を表示する。入力装置３０５はユーザーからの入力を受け付ける。通信ＩＦ３０６は、イーサネット（登録商標）等に接続するためのインターフェースである。なお通信ＩＦ３０６は、無線方式でもよい。
【０１４５】
第１乃至第６実施形態のアプリケーション２０を動作させる情報処理装置は、図１９のハードウェア構成を備えていれば、汎用のコンピュータ等を含む任意の装置により実現可能である。
【０１４６】
第１乃至第６実施形態の情報処理装置で実行されるアプリケーション２０等のプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、メモリカード、ＣＤ−Ｒ、及び、ＤＶＤ等のコンピュータで読み取り可能な記憶媒体に記憶されてコンピュータ・プログラム・プロダクトとして提供される。
【０１４７】
また第１乃至第６実施形態の情報処理装置で実行されるアプリケーション２０等のプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。
【０１４８】
また第１乃至第６実施形態の情報処理装置で実行されるアプリケーション２０等のプログラムを、ダウンロードさせずにインターネット等のネットワーク経由で提供するように構成してもよい。
【０１４９】
また第１乃至第６実施形態の情報処理装置で実行されるアプリケーション２０等のプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１５０】
なお第１乃至第６実施形態のアプリケーション２０の機能の一部又は全部を、ＩＣ等のハードウェアにより実現してもよい。ＩＣは、例えば専用の処理を実行するプロセッサである。
【０１５１】
また複数のプロセッサを用いて各機能を実現する場合、各プロセッサは、各機能のうち１つを実現してもよいし、各機能のうち２つ以上を実現してもよい。
【０１５２】
また第１乃至第６実施形態のアプリケーション２０を動作させる情報処理装置の動作形態は任意でよい。第１乃至第６実施形態のアプリケーション２０を動作させる情報処理装置を、例えばネットワーク上のクラウドシステムを構成する装置として動作させてもよい。
【０１５３】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１５４】
１０  ノード
１１  記憶部
１２  受信部
１３  生成部
１４  判定部
１５  共有制御部
２０  アプリケーション
１０１  暗号データ通信ネットワーク
２０１  制御装置
２０２  主記憶装置
２０３  補助記憶装置
２０４  表示装置
２０５  入力装置
２０６  量子通信ＩＦ
２０７  古典通信ＩＦ
２１０  バス
３０１  制御装置
３０２  主記憶装置
３０３  補助記憶装置
３０４  表示装置
３０５  入力装置
３０６  通信ＩＦ
３１０  バス
【図１】
2018207348.tif 000003
【図２】
2018207348.tif 000004
【図３】
2018207348.tif 000005
【図４】
2018207348.tif 000006
【図５Ａ】
2018207348.tif 000007
【図５Ｂ】
2018207348.tif 000008
【図６】
2018207348.tif 000009
【図７】
2018207348.tif 000010
【図８】
2018207348.tif 000011
【図９Ａ】
2018207348.tif 000012
【図９Ｂ】
2018207348.tif 000013
【図９Ｃ】
2018207348.tif 000014
【図９Ｄ】
2018207348.tif 000015
【図１０Ａ】
2018207348.tif 000016
【図１０Ｂ】
2018207348.tif 000017
【図１１Ａ】
2018207348.tif 000018
【図１１Ｂ】
2018207348.tif 000019
【図１１Ｃ】
2018207348.tif 000020
【図１２】
2018207348.tif 000021
【図１３】
2018207348.tif 000022
【図１４】
2018207348.tif 000023
【図１５】
2018207348.tif 000024
【図１６】
2018207348.tif 000025
【図１７】
2018207348.tif 000026
【図１８】
2018207348.tif 000027
【図１９】
2018207348.tif 000028