特開 2024-134304 量子鍵配送システム、ノード、鍵リレー経路計算エンジン、プログラム、及び量子鍵配送方法

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

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

(11)【公開番号】P2024134304

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

(54)【発明の名称】量子鍵配送システム、ノード、鍵リレー経路計算エンジン、プログラム、及び量子鍵配送方法

(51)【国際特許分類】

   H04L 9/12 20060101AFI20240926BHJP

【ＦＩ】

H04L9/12

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023044537

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

(71)【出願人】

【識別番号】301022471

【氏名又は名称】国立研究開発法人情報通信研究機構

(74)【代理人】

【識別番号】100116850

【弁理士】

【氏名又は名称】廣瀬 隆行

(74)【代理人】

【識別番号】100165847

【弁理士】

【氏名又は名称】関 大祐

(72)【発明者】

【氏名】宮澤 高也

(72)【発明者】

【氏名】朝枝 仁

(72)【発明者】

【氏名】藤原 幹生

(57)【要約】

【課題】量子鍵配送ネットワークにおいて鍵リレー要求の棄却率や鍵消費量等を低減しつつ鍵リレー経路計算を自動化する。
【解決手段】量子鍵配送により他のノードと共有される暗号鍵を生成する量子鍵配送ネットワーク用のノード１０は、始端のノード１０（Ａ）と終端のノード１０（Ｃ）との間で共有される第１の暗号鍵を中継先のノードに供給する暗号鍵マネージャ１２と、中継先のノードとなり得る複数の候補の中から中継先のノードを決定する鍵リレー経路計算エンジン１４を含む。鍵リレー経路計算部１４は、Ａ）複数の候補との各リンクにおける暗号鍵の残量値、Ｂ）複数の候補との各リンクにおける暗号鍵の消費量の予測値、及びＣ）複数の候補との各リンクにおける暗号鍵の生成量の予測値に基づいて中継先のノードを決定する。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数の他のノードとの間で量子鍵を送受信し、当該量子鍵に基づいて当該他のノードと共有される暗号鍵を生成する量子鍵配送ネットワーク用のノードであって、前記量子鍵配送ネットワークは、始端のノードと終端のノードの間に複数の中継用のノードが介在しており、
前記ノードは、
生成した前記暗号鍵を記憶する暗号鍵記憶部と、
前記始端のノードと前記終端のノードとの間で共有される第１の暗号鍵を、中継先のノードとの間で共有している第２の暗号鍵を用いて暗号化して、当該中継先のノードに供給する鍵リレー部と、
前記中継先のノードとなり得る複数の候補の中から、前記中継先のノードを決定する鍵リレー経路計算部を有し、
前記鍵リレー経路計算部は、
Ａ）前記複数の候補との各リンクについて前記暗号鍵記憶部に記憶されている前記暗号鍵の残量値、
Ｂ）前記複数の候補との各リンクにおける前記暗号鍵の消費量の予測値、及び
Ｃ）前記複数の候補との各リンクにおける前記暗号鍵の生成量の予測値のうち、
前記Ａ）の情報と、前記Ｂ）と前記Ｃ）の情報の両方又はいずれか一方とに基づいて前記中継先のノードを決定する
ノード。

【請求項2】

前記鍵リレー経路計算部は、前記Ａ）、前記Ｂ）、及び前記Ｃ）の情報に基づいて前記中継先のノードを決定する
請求項１に記載のノード。

【請求項3】

前記暗号鍵の消費量の予測値は、前記複数の候補との各リンクにおけるｔ時間の鍵消費量の予測値であり、
前記暗号鍵の生成量の予測値は、前記複数の候補との各リンクにおけるｔ時間の鍵生成量の予測値であって、
前記ｔ時間は、前記始端のノードから前記第１の暗号鍵の供給を受ける送信端末と前記終端のノードから前記第１の暗号鍵の供給を受ける受信端末との間で行われる暗号通信の動作時間である
請求項１に記載のノード。

【請求項4】

請求項１に記載の前記ノードと、前記ノードが生成した前記暗号鍵の供給先を管理する管理サーバと、を備える量子鍵配送システムであって、
前記管理サーバは、
前記ノード間のリンクごとの前記暗号鍵の消費量の予測値を求める予測部を有し、
前記消費量の予測値を前記ノードに提供する
量子鍵配送システム。

【請求項5】

前記予測部は、過去の前記暗号鍵の消費量に関するデータを教師データとして機械学習を実行することにより得られた学習済みモデルを用いて、前記暗号鍵の消費量の予測値を求める
請求項４に記載の量子鍵配送システム。

【請求項6】

前記予測部は、さらに、前記ノード間のリンクごとの前記暗号鍵の生成量の予測値を求めるものであり、
前記管理サーバは、前記生成量の予測値を前記ノードに提供する
請求項４に記載の量子鍵配送システム。

【請求項7】

前記予測部は、さらに、過去の前記暗号鍵の消費量に関するデータを教師データとして機械学習を実行することにより得られた学習モデルを用いて、前記暗号鍵を利用した送信端末と受信端末との間で行われる暗号通信の需要を予測する
請求項４に記載の量子鍵配送システム。

【請求項8】

複数の他のノードとの間で量子鍵を送受信し、当該量子鍵に基づいて当該他のノードと共有される暗号鍵を生成する量子鍵配送方法であって、
前記量子鍵配送方法は、始端のノードと終端のノードの間に複数の中継用のノードが介在するネットワークにおいて行われ、
前記量子鍵配送方法は、
前記中継用のノードが、前記始端のノードと前記終端のノードとの間で共有される第１の暗号鍵を、中継先のノードとの間で共有している第２の暗号鍵を用いて暗号化して、当該中継先のノードに供給する鍵リレー工程と、
前記中継用のノードが、前記中継先のノードとなり得る複数の候補の中から、前記中継先のノードを決定する鍵リレー経路計算工程を含み、
前記鍵リレー経路計算工程は、
Ａ）前記複数の候補との各リンクについて前記中継用のノードの記憶部に記憶されている前記暗号鍵の残量値、
Ｂ）前記複数の候補との各リンクにおける前記暗号鍵の消費量の予測値、及び
Ｃ）前記複数の候補との各リンクにおける前記暗号鍵の生成量の予測値のうち、
前記Ａ）の情報と、前記Ｂ）と前記Ｃ）の情報の両方又はいずれか一方とに基づいて前記中継先のノードを決定する工程である
量子鍵配送方法。

【請求項9】

複数の他のノードとの間で量子鍵を送受信し、当該量子鍵に基づいて当該他のノードと共有される暗号鍵を生成するノード用の鍵リレー経路計算エンジンであって、
前記ノードは、
生成した前記暗号鍵を記憶する暗号鍵記憶部と、
始端のノードと終端のノードの間に複数の中継用のノードが介在している場合に、当該始端のノードと当該終端のノードとの間で共有される第１の暗号鍵を、中継先のノードとの間で共有している第２の暗号鍵を用いて暗号化して、当該中継先のノードに供給する鍵リレー部を有しており、
前記鍵リレー経路計算エンジンは、
前記中継先のノードとなり得る複数の候補の中から、前記中継先のノードを決定するものであって、
Ａ）前記複数の候補との各リンクについて前記暗号鍵記憶部に記憶されている前記暗号鍵の残量値、
Ｂ）前記複数の候補との各リンクにおける前記暗号鍵の消費量の予測値、及び
Ｃ）前記複数の候補との各リンクにおける前記暗号鍵の生成量の予測値のうち、
前記Ａ）の情報と、前記Ｂ）と前記Ｃ）の情報の両方又はいずれか一方とに基づいて前記中継先のノードを決定する
鍵リレー経路計算エンジン。

【請求項10】

コンピュータを、請求項９に記載の鍵リレー経路計算エンジンとして機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、量子鍵配送システム、当該システムを構成するノード、当該ノードが具備する鍵リレー経路計算エンジン、及びコンピュータプログラムに関する。また、本発明は、量子鍵配送方法にも関するものである。

【背景技術】

【0002】

近年の量子コンピュータ技術の進展に伴い、将来のネットワークでは、既存の暗号方式で暗号化された機密情報を短時間で容易に復号化されてしまう懸念がある。従って、機密情報等をやりとりするアプリケーションサービスにおいては、盗聴者が元のデータを絶対解読不可能とするなど極めて高い秘匿性を維持しつつ送受信間で情報のやり取り可能な技術が必須であり、早急に商用ネットワークに導入することが求められている。

【0003】

このため、量子通信チャネル及びワンタイムパッド等の暗号化方式を用いることで、情報理論的安全性を実現できる量子鍵配送ネットワーク（ＱＫＤＮ：Quantum Key Distribution Network）技術が注目されている（例えば特許文献１）。ＱＫＤＮ技術は、たとえ無限の計算能力を持つ盗聴者が居ても元データを解読不可能であることが理論的に証明されている量子暗号鍵を生成し、送受信間で安全に共有することを可能とする。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２２－１４９４９８号公報

【発明の概要】

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

【0005】

ところで、ＱＫＤは、光子の量子状態の不安定性といった量子特有の物理的な特徴があり、鍵の生成速度や光子の通信距離が制限されてしまうという問題がある。このため、量子鍵を転送する中継ノードを配備する等の技術によって、互いに地理的距離が遠いＱＫＤＮノード間で鍵の共有を可能とする仕組みが必要である。

【0006】

一般に、ＱＫＤＮは、（１）トラステッドノードＱＫＤＮと、（２）量子中継ＱＫＤＮの２種類に分類できる。トラステッドノードＱＫＤＮでは、各々の隣接ノード間（すなわち各々のリンク）において、ＢＢ８４方式のような量子暗号通信プロトコルによって、鍵が生成及び共有される。そのうえで、複数の中継ノードを経由する必要がある送受信間では、ＱＫＤの鍵リレー技術を用いて各中継ノードで量子鍵を安全に転送していくことによって、鍵を共有する。一方、量子中継ＱＫＤＮでは、各中継ノードにおいて単一光子通信を終端せず、量子状態を維持したまま転送していくことによって、送受信間で単一光子通信を実現し、鍵を共有する。ただし、現状、量子中継ＱＫＤＮを実現するためのデバイス技術（例えば量子メモリ）が実用化レベルに達していないため、早期実用化は困難とされている。従って、現在は、トラステッドノードＱＫＤＮの実用化に向けた研究が先行して進められている。

【0007】

前述の通り、トラステッドノードＱＫＤＮでは、鍵生成速度や光子の通信距離の制約が厳しく、各中継ノードに蓄積される量子鍵の量に厳しい制限がある。すなわち、トラステッドノードＱＫＤＮには、不安定な量子通信により暗号鍵の生成速度が非常に遅いため、各ネットワークノードに蓄積された鍵の量が極めて少なく、送信端末と受信端末の間で鍵を共有するための鍵リレー要求の棄却が問題視されている。このように、鍵不足に起因する鍵リレー要求棄却が問題となることから、現在は、ネットワーク全体において限られた量の暗号鍵を有効利用（暗号鍵の浪費を抑制）し、鍵リレー要求の棄却率や鍵消費量を低減するための技術が求められている。

【0008】

また、ＱＫＤＮ全体の鍵残量が時々刻々と変動する環境下において、鍵リレー要求棄却率や鍵提供失敗率といったＱＫＤＮ性能を考慮すると、アプリケーション毎に最適な経路を常時自動選択できるとは限らず、ＱＫＤＮ性能が劣化する可能性がある。具体的には、大規模かつ複雑なトポロジー下では、最適経路の選択が困難であるかその選択に長時間要することとなるため、比較的短期に変動する状況（鍵蓄積量や障害等）には対応できず、何らかのポリシーで決定した経路が必ずしも最適な経路になるとは限らない。このため、トラステッドノードＱＫＤＮの大規模化や、時々刻々と変動するリソース状況（各ノードにおける暗号鍵の残量等）や障害発生等に迅速に対応するため、鍵リレー経路計算を自動化する技術が求められている。

【0009】

そこで、本発明は、主にトラステッドノードＱＫＤＮを対象として、鍵リレー要求の棄却率や鍵消費量等を低減しつつ、鍵リレー経路計算を自動化し、ＱＫＤＮサービスの品質の維持及び向上を図ることを目的とする。

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

【0010】

本発明の発明者らは、上記課題を解決する手段について鋭意検討した結果、ＱＫＤシステムにおいて、ユーザからの鍵リレー要求を基に、アプリケーション動作時間後の未来におけるＱＫＤＮ全体のリンク毎の鍵消費量及び／又は鍵生成量を予測し、その予測結果と現在の鍵残量とを踏まえて鍵リレー経路の自動選択を行うことにより、鍵リレー要求の棄却率や鍵消費量等を低減のための鍵リレー経路の自動計算を実現できるという知見を得た。そして、本発明者らは、上記知見に基づけば従来技術の課題を解決できることに想到し、本発明を完成させた。以下、具体的に説明する。

【0011】

本発明の第１の側面は、量子鍵配送ネットワーク（ＱＫＤＮ）を構成するノードに関する。量子鍵配送ネットワークでは、複数の他のノードとの間で量子鍵が送受信され、当該量子鍵に基づいて当該他のノードと共有される暗号鍵が生成される。本発明では、始端のノードと終端のノードの間に複数の中継用のノードが介在する量子鍵配送ネットワークを想定している。

【0012】

本発明に係るノードは、暗号鍵記憶部、鍵リレー部、及び鍵リレー経路計算部を有する。暗号鍵記憶部は、ノードが生成した暗号鍵を記憶する記憶装置であり、不揮発性メモリや揮発性メモリによって構成される。鍵リレー部は、始端のノードと終端のノードとの間で共有される第１の暗号鍵を、自己のノードと中継先のノードとの間で共有している第２の暗号鍵を用いて暗号化して、当該中継先のノードに供給するための演算処理を行う。リレー経路計算部は、中継先のノードとなり得る複数の候補の中から、中継先のノードを決定するための演算処理を行う。鍵リレー部とリレー経路計算部は、ノードに搭載されたＣＰＵやＧＰＵといったプロセッサで構成される。

【0013】

具体的には、ノードの鍵リレー経路計算部は、以下に記載したＡ）の情報に加え、Ｂ）とＣ）の情報の両方又はいずれか一方の情報に基づいて、中継先のノードとなり得る複数の候補の中から、一つの中継先のノードを決定する。
Ａ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクについて暗号鍵記憶部に記憶されている暗号鍵の残量値
Ｂ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の消費量の予測値
Ｃ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の生成量の予測値

【0014】

上記構成のように、本発明に係るノードは、暗号鍵の残量値だけでなく、機械学習等の技術を用いて暗号鍵の消費量及び／又は生成量を予測し、暗号鍵の残量値とこれらの予測値に基づいて最適な鍵リレー経路計算を自動的かつリアルタイムに決定する。これにより、限られた量の暗号鍵を有効利用しつつ、ネットワーク全体における鍵消費の時変動に対応することが可能となる。従って、鍵リレー要求の棄却率や鍵消費量等を低減することができ、量子鍵配送ネットワークの品質を維持及び向上させることができる。

【0015】

本発明に係るノードにおいて、鍵リレー経路計算部は、上記したＡ）、Ｂ）、及びＣ）のすべての情報に基づいて中継先のノード、つまり鍵リレー経路を決定することが好ましい。これにより、鍵リレー経路計算の精度を向上させることができる。

【0016】

本発明に係るノードにおいて、Ｂ）暗号鍵の消費量の予測値は、自己ノードと複数の候補との間の各リンクにおけるｔ時間の鍵消費量の予測値であり、Ｃ）暗号鍵の生成量の予測値は、自己ノードと複数の候補との間の各リンクにおけるｔ時間の鍵生成量の予測値であることが好ましい。なお、ここにいう「ｔ時間」とは、始端のノードから第１の暗号鍵の供給を受ける送信端末と終端のノードから第１の暗号鍵の供給を受ける受信端末との間で行われる暗号通信の動作時間である。例えば、送信端末と受信端末の間の暗号通信が１０秒間（ｔ時間）行われる場合、この１０秒間で、自己ノードと各候補との間で消費される暗号鍵の消費量や、自己ノードと各候補との間で生成される暗号鍵の生成量を予測すればよい。これにより、比較的短期に変動する状況（暗号鍵の蓄積量や障害等）に対応した適切な鍵リレー経路を自動的に求めることができる。

【0017】

本発明の第２の側面は、量子鍵配送システムに関する。本発明に係る量子鍵配送システムは、前述した第１の側面に係るノードと、このノードが生成した暗号鍵の供給先を管理する管理サーバとを備える。ここで、管理サーバは、予測部を有する。予測部は、ノード間のリンクごとの暗号鍵の消費量の予測値を求める。このとき、予測部は、過去の暗号鍵の消費量に関するデータを教師データとして機械学習を実行することにより得られた学習済みモデルを用いて、暗号鍵の消費量の予測値を求めることとしてもよい。また、管理サーバの予測部は、ノード間のリンクごとの暗号鍵の生成量の予測値をさらに求めることとしてもよい。管理サーバは、暗号鍵の消費量及び／又は生成量の予測値をノードに提供する。

【0018】

本発明に係る量子鍵配送システムにおいて、管理サーバの予測部は、過去の暗号鍵の消費量に関するデータを教師データとして機械学習を実行することにより得られた学習モデルを用いて、暗号鍵を利用した送信端末と受信端末との間で行われる暗号通信の需要を予測することとしてもよい。このように暗号通信の需要予測を行うことで、例えば、ＱＫＤＮを運営する事業者は、アプリケーション毎の鍵の需要（＝鍵の必要量）を機械学習（ＡＩ）を活用して予測し、その予測結果をユーザに事前提供することができる。この場合、ユーザは、各ユーザのアプリケーション毎の予測結果に応じて、例えばＱＫＤＮサービス課金契約やサービスレベル合意（ＳＬＡ）も踏まえ、ＱＫＤＮ事業者に鍵リレー要求を行うことができる。

【0019】

本発明の第３の側面は、量子鍵配送方法に関する。本発明に係る量子鍵配送方法では、複数のノードの間で量子鍵が送受信され、当該量子鍵に基づいて複数のノードの間で共有される暗号鍵が生成される。この量子鍵配送方法は、始端のノードと終端のノードの間に複数の中継用のノードが介在するネットワークにおいて実行される。量子鍵配送方法は、鍵リレー工程と、鍵リレー経路計算工程を含む。鍵リレー工程では、中継用のノードが、始端のノードと終端のノードとの間で共有される第１の暗号鍵を、自己と中継先のノードとの間で共有している第２の暗号鍵を用いて暗号化して、当該中継先のノードに供給する。鍵リレー経路計算工程は、中継用のノードが、中継先のノードとなり得る複数の候補の中から、中継先のノードを決定する。ここで、鍵リレー経路計算工程では、以下に記載したＡ）の情報に加え、Ｂ）とＣ）の情報の両方又はいずれか一方の情報に基づいて、中継先のノードとなり得る複数の候補の中から、一つの中継先のノードが決定される。
Ａ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクについて暗号鍵記憶部に記憶されている暗号鍵の残量値
Ｂ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の消費量の予測値
Ｃ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の生成量の予測値

【0020】

本発明の第４の側面は、鍵リレー経路計算エンジンに関する。本発明に係る鍵リレー経路計算エンジンは、複数の他のノードとの間で量子鍵を送受信し、当該量子鍵に基づいて当該他のノードと共有される暗号鍵を生成するノードに具備される。ここで、ノードは、前述した第１の側面に係るノードと同様に、暗号鍵記憶部と鍵リレー部を有している。ここで、本発明に係る鍵リレー経路計算エンジンは、以下に記載したＡ）の情報に加え、Ｂ）とＣ）の情報の両方又はいずれか一方の情報に基づいて、中継先のノードとなり得る複数の候補の中から、一つの中継先のノードを決定する。
Ａ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクについて暗号鍵記憶部に記憶されている暗号鍵の残量値
Ｂ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の消費量の予測値
Ｃ）中継元のノードと中継先のノードとなり得る複数の候補との間の各リンクにおける暗号鍵の生成量の予測値

【0021】

本発明の第５の側面は、コンピュータを、前述した第４の側面に係る鍵リレー経路計算エンジンとして機能させるためのプログラムである。このプログラムは、インターネット等の通信回線を介してコンピュータにダウンロード可能なものであってもよいし、ＣＤ－ＲＯＭ等の記憶媒体に非一時的に記憶されたものであってもよい。

【発明の効果】

【0022】

本発明によれば、主にトラステッドノードＱＫＤＮを対象として、鍵リレー要求の棄却率や鍵消費量等を低減しつつ、鍵リレー経路計算を自動化し、ＱＫＤＮサービスの品質の維持及び向上を図ることができる。

【図面の簡単な説明】

【0023】

【図1】図１は、本発明における量子鍵配送ネットワーク（ＱＫＤＮ）のアーキテクチャの一例を示している。

【図2】図２は、本発明の一実施形態に係る量子鍵配送（ＱＫＤ）システムのブロック図を示している。

【図3】図３は、暗号鍵の生成方法の一例を示している。

【図4】図４は、鍵リレー方法の一例を示している。

【図5】図５は、鍵リレー経路の一例を示している。

【図6】図６は、本発明の一実施形態について、鍵リレー経路計算を含む制御処理のシーケンス図を示している。

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

【0024】

以下、図面を用いて本発明を実施するための形態について説明する。本発明は、以下に説明する形態に限定されるものではなく、以下の形態から当業者が自明な範囲で適宜変更したものも含む。

【0025】

図１は、本発明におけるＱＫＤＮのアーキテクチャの例を示している。このアーキテクチャは、基本的にＩＴＵ－Ｔ（国際電気通信連合電気通信標準化部門）により量子鍵配送をサポートするネットワークのフレームワークとして承認された国際標準規格（Ｙ．３８００）を踏襲したものである。ただし、本発明に係るアーキテクチャは、ＱＫＤＮ制御レイヤが鍵リレー経路計算エンジン１４を備える点、及び、ＱＫＤＮ管理レイヤがＡＩエンジン２２を備える点を特徴の一つとしており、これらの点において上記の国際標準規格（Ｙ．３８００）とは異なる。また、図２は、このアーキテクチャに従って構成されたＱＫＤシステム１００を構成する各要素の機能ブロックを示している。これらの図を参照して、ＱＫＤシステム１００の機能について説明する。

【0026】

図１は、ＱＫＤＮからユーザネットワークに提供された暗号鍵（Ｋ_１）を利用して、送信端末３０と受信端末４０のアプリケーション間で実行される暗号通信の例を示している。このように、ＱＫＤＮは、主にＯＴＰ（ワンタイムパッド暗号）で暗号通信を行うユーザ向けに量子鍵の配送サービスを提供する。つまり、ＱＫＤＮは、暗号通信を行う送信端末３０と受信端末４０の各拠点に、共有化された暗号鍵（Ｋ_１）を供給するものである。

【0027】

ＱＫＤＮを構成する量子鍵配送システム１００は、複数のＱＫＤノード１０と、ＱＫＤＮを管理するための管理サーバ２０を有している。ＱＫＤノード１０は、それぞれ一又は複数の他のＱＫＤノード１０と光ファイバを介して接続されており、この光ファイバ網によってＱＫＤノード１０同士を接続するネットワークが構成されている。ＱＫＤノード１０は、例えば各地に点在する量子鍵配送センターにそれぞれ配備されることとなる。また、管理サーバ２０は、主に暗号鍵の供給を適応的に管理する役割を担う。管理サーバ２０は、一台のサーバ装置によって構成されていてもよいが、インターネット等で接続された複数のサーバ装置を含むクラウドサーバによって構成されていてもよい。

【0028】

ＱＫＤノード１０は、それぞれ、他のＱＫＤノード１０と光ファイバを介して光子を送受信することにより、互いにペアとなる量子鍵を共有し、この量子鍵に基づいて暗号鍵を生成し蓄積する。また、ＱＫＤノード１０は、量子鍵を中継する中継装置としても機能する。つまり、ＱＫＤノード１０は、それぞれ、光ファイバで直接的に接続されているＱＫＤノード１０との間だけでなく、一又は複数のＱＫＤノード１０を超えて光ファイバ網によって間接的に接続されている他のＱＫＤノード１０との間でも量子鍵を共有することができる。

【0029】

図１に示されるように、複数のＱＫＤノード１０と管理サーバ２０によって構成されるＱＫＤＮは、量子レイヤ、暗号鍵管理レイヤ、ＱＫＤＮ制御レイヤ、及びＱＫＤＮ管理レイヤを有するものと観念できる。複数のＱＫＤノード１０のそれぞれは、量子レイヤ、暗号鍵管理レイヤ、及びＱＫＤＮ制御レイヤを有しており、つまりこれらのレイヤは複数のＱＫＤノード１０を横断するものであるといえる。また、ＱＫＤＮ管理レイヤは、管理サーバ２０によって構成されており、量子レイヤ、暗号鍵管理レイヤ、及びＱＫＤＮ制御レイヤとそれぞれ情報の授受を行うことができるように接続されている。

【0030】

量子レイヤは、各ＱＫＤノード１０の量子鍵配送モジュール１１と、これらを接続する光ファイバ（ＱＫＤリンク）によって構成される。量子鍵配送モジュール１１は、基本的に他の同モジュールと一対一で接続されており、量子鍵配送モジュール１１の各ペアは、独自の方法で対称的なランダムビット列を生成し、これを量子鍵として共有する。量子鍵配送モジュール１１は、ここで生成した量子鍵を同じノード内に設けられた暗号鍵マネージャ１２（ＫＭ：Key Managerともいう。）へと送る。また、量子鍵配送モジュール１１は、光ファイバ（ＱＫＤリンク）のパラメータ（量子ビット誤り率等）を、管理サーバ２０のＱＫＤＮマネージャ２１に送信することとしてもよい。

【0031】

図１に示した例では、始端となるＱＫＤノード１０（Ａ）と終端となるＱＫＤノード１０（Ｃ）の間に中継用のＱＫＤノード１０（Ｂ）が介在している。中継用のＱＫＤノード１０（Ｂ）には、始端となるＱＫＤノード１０（Ａ）と接続される第１の量子鍵配送モジュール１１（Ｂ１）と、終端となるＱＫＤノード１０（Ｃ）と接続される第２の量子鍵配送モジュール１１（Ｂ２）がそれぞれ設けられている。このとき、始端となるＱＫＤノード１０（Ａ）の量子鍵配送モジュール１１（Ａ）と中継用のＱＫＤノード１０（Ｂ）の第１の量子鍵配送モジュール１１（Ｂ１）の間で暗号鍵（Ｋ_ＡＢ）が共有され、中継用のＱＫＤノード１０（Ｂ）の第２の量子鍵配送モジュール１１（Ｂ２）と終端となるＱＫＤノード１０（Ｃ）の量子鍵配送モジュール１１（Ｃ）の間で別の暗号鍵（Ｋ_ＢＣ）が共有される。

【0032】

暗号鍵管理レイヤは、各ＱＫＤノード１０の暗号鍵マネージャ１２と、これらを接続するリンク（ＫＭリンク）によって構成される。このＫＭリンクには、インターネットや、電話回線、衛星通信回線等の汎用的な通信回線を利用することができる。各暗号鍵マネージャ１２は、これと同じノードに設けられた量子鍵配送モジュール１１から量子鍵（ランダムなビット列）を受け取ると、この量子鍵を再フォーマットして、暗号鍵としてストレージに格納する。また、暗号鍵マネージャ１２には、送信端末３０又は受信端末４０の間で利用される各種暗号通信用のアプリケーションのインタフェースが搭載されている。暗号鍵マネージャ１２は、暗号アプリケーションから暗号鍵の要求を受けると、ストレージから必要な量の暗号鍵を読み出すとともに、送信側と受信側とで同期をとりながら、暗号アプリケーションに適切な形式で送信端末３０又は受信端末４０に供給する。また、暗号鍵マネージャ１２、量子鍵配送モジュール１１及び光ファイバ（ＱＫＤリンク）にアクセスし、それらの活性化、非活性化、パラメータ制御、及び較正を行うこともできる。さらに、暗号鍵マネージャ１２は、暗号鍵のライフサイクル管理も実行する。

【0033】

また、送信端末３０に対応するＱＫＤノード１０と受信端末４０に対応するＱＫＤノード１０を暗号鍵管理レイヤのＫＭリンクで直接接続することができない場合には、この暗号鍵管理レイヤにて暗号鍵を中継することにより、送信端末３０と受信端末４０に暗号鍵を共有させる。この場合、暗号鍵マネージャ１２は、ＱＫＤＮ制御レイヤのＱＫＤＮコントローラ１３に適切な中継経路を問い合わせる。ＱＫＤＮコントローラ１３の制御に基づいて、各暗号鍵マネージャ１２は、ＫＭリンクを介して始端と終端のＱＫＤノード１０の間で供給されるべき暗号鍵を受け取ると、中継元と中継先のＱＫＤノード１０で共有している別の暗号鍵を用いて安全性の高い暗号化（ＯＴＰなど）を行い、中継先のＱＫＤノード１０へと送信していく。その結果、暗号鍵が中継され、最終的に暗号化アプリケーションへと供給される。

【0034】

図１では、中継用のＱＫＤノード１０（Ｂ）を経由して始端となるＱＫＤノード１０（Ａ）と終端となるＱＫＤノード１０（Ｃ）と間で暗号鍵（Ｋ_１）を共有する鍵リレーを例示している。この場合、暗号鍵（Ｋ_１）は、例えばＱＫＤノード１０（Ａ）とＱＫＤノード１０（Ｃ）の間で生成された量子鍵（Ｋ_ＡＢ）（ケース１）から生成したもの、又は、ＱＫＤノード１０（Ａ）でローカルに生成されたランダムなビット列（例えば量子鍵Ｋ_ＲＮ）（ケース２）から生成されたもののいずれかとすることができる。ケース１では、暗号鍵（Ｋ_ＡＢ）は、ＱＫＤノード１０（Ｂ）とＱＫＤノード１０（Ｃ）の間で共有する量子鍵（Ｋ_ＢＣ）から生成された暗号鍵によるＯＴＰ暗号化によって、ＱＫＤノード１０（Ｂ）からＱＫＤノード１０（Ｃ）に中継され、最後にＱＫＤノード１０（Ｃ）で復号される。また、ケース２では、暗号鍵（Ｋ_ＲＮ）は、まず、量子鍵（Ｋ_ＡＢ）から生成された暗号鍵によるによるＯＴＰ暗号化によってＱＫＤノード１０（Ａ）からＱＫＤノード１０（Ｂ）に送信され、ＱＫＤノード１０（Ｂ）で復号される。次に、暗号鍵（Ｋ_ＲＮ）は、量子鍵（Ｋ_ＢＣ）から生成された暗号鍵によるＯＴＰ暗号化され、ＱＫＤノード１０（Ｂ）からＱＫＤノード１０（Ｃ）に送信され、最後にＱＫＤノード１０（Ｃ）で復号される。したがって、暗号鍵Ｋ_１は、ＱＫＤノード１０（Ａ）とＱＫＤノード１０（Ｃ）の間で共有される。

【0035】

ＱＫＤＮ制御レイヤは、ＱＫＤノード１０のＱＫＤＮコントローラ１３と鍵リレー経路計算エンジン１４によって構成される。このＱＫＤＮ制御レイヤは、ＱＫＤＮ全体の制御に関わるものであり、ＱＫＤＮコントローラ１３の機能には、例えば、暗号鍵中継のルーティング制御、ＱＫＤリンク及びＫＭリンクの制御、ＱＫＤサービスのセッション制御、認証及び認可制御、並びに、ＱｏＳ（Quality of Service）及び課金ポリシー制御が含まれる。なお、集中型アーキテクチャでは、図１のＱＫＤノード１０（Ｂ）に示されるように、単一のＱＫＤＮコントローラ１３がＱＫＤＮ制御機能を実行すればよい。この場合、一つのＱＫＤノード１０（Ｂ）に設けられたＱＫＤＮコントローラ１３が、ある暗号鍵の鍵リレーを実行するＱＫＤノード１０全体の制御を行う。一方、分散型アーキテクチャでは、実線と点線で囲まれたＱＫＤＮコントローラ１３のように、各ＱＫＤノード１０（Ａ，Ｂ，Ｃ）のそれぞれにＱＫＤＮコントローラ１３が設けられた、それぞれのＱＫＤＮコントローラ１３がＱＫＤノード１０の制御を行う。

【0036】

鍵リレー経路計算エンジン１４は、本発明特有の要素である。鍵リレー経路計算エンジン１４は、始端のＱＫＤノード１０から終端のＱＫＤノード１０までの暗号鍵の適切なリレー経路を自動的に計算する。詳細については後述するが、鍵リレー経路計算エンジン１４は、各ＫＭリンクにおける暗号鍵の残量値や、暗号鍵の消費量の予測値に基づいて、各ＫＭリンクにおけるコスト値を算出する。そして、鍵リレー経路計算エンジン１４は、始端のＱＫＤノード１０から終端のＱＫＤノード１０までに経由するＫＭリンクのコスト値が最小限となるように、暗号鍵のリレー経路を求める。鍵リレー経路計算エンジン１４が自動的に求めたリレー経路は、ＱＫＤＮコントローラ１３に伝達される。各ＱＫＤノード１０の暗号鍵マネージャ１２は、ＱＫＤＮコントローラ１３の制御に従って暗号鍵と中継することとなる。

【0037】

ＱＫＤＮ管理レイヤは、管理サーバ２０のＱＫＤＮマネージャ２１とＡＩエンジン２２によって構成される。ＱＫＤＮ管理レイヤでは、ＱＫＤＮ全体の管理と監視が行われる。具体的には、管理サーバ２０のＱＫＤＮマネージャ２１は、例えば、量子レイヤのＱＫＤモジュール１１とＱＫＤリンク（中継点を含む）の性能に関する情報と、暗号鍵管理レイヤにおける暗号鍵の管理情報を収集し、これら２層の監視を行う。暗号鍵管理レイヤにおける暗号鍵の管理情報には、暗号鍵のライフサイクルに関する情報、具体的には、暗号鍵の現在の蓄積量や、蓄積量の推移に関する情報の他、暗号鍵の消費日時や消費量の推移に関する情報や、暗号鍵の生成日時や生成量の推移に関する情報が含まれる。ＱＫＤＮマネージャ２１が収集した暗号鍵の管理情報は、ＡＩエンジン２２に提供される。

【0038】

ＡＩエンジン２２（予測部）は、本発明特有の要素である。ＡＩエンジン２２は、主に暗号鍵の実際のライフサイクルに関する情報を教師データとして機械学習を実行し、アプリケーション毎の暗号鍵の需要予測や、鍵管理レイヤのＫＭリンク毎の暗号鍵の消費量の予測に利用される学習済みモデルを生成する。ＡＩエンジン２２は、ＱＫＤＮマネージャ２１から暗号鍵のライフサイクルに関する情報を常時又は定期的に受信し、機械学習を実行することで学習済みモデルの精度向上や更新を行うとよい。

【0039】

アプリケーション毎の暗号鍵の需要予測としては、ＱＫＤＮを運営するサービス事業者が、将来発生し得るアプリケーションの各々について、ＡＩ技術（機械学習）を活用して暗号鍵の需要（＝必要量）の予測を行い、エンドユーザに提供する。エンドユーザとしては、例えば、金融分野における暗号通信であれば銀行や証券会社等が想定され、医療分野における暗号通信であれば病院や薬局等が想定される。具体的には、ＡＩエンジン２２は、過去のアプリケーションごとの暗号鍵の消費日時や消費変動に関するデータに対して教師有り学習を実行し、将来の同じアプリケーションについて暗号鍵の鍵の需要（＝必要量）の予測を行うための学習済みモデルを生成する。教師有り学習のアルゴリズムは、特に限定されず、主に時系列データを扱う公知の学習アルゴリズムを用いることができる。例えば、学習アルゴリズムとしては、ディープラーニングモデルの１種である長・短期記憶（ＬＳＴＭ：Long Short Term Memory）や、回帰型ニューラルネットワーク（ＲＮＮ：Recurrent Neural Network）を用いてもよい。なお、過去の同アプリケーションのデータセットが少ない場合には、類似のアプリケーションの過去のデータセットを教師データとして使用してもよい。また、データセットが少ない場合においても有効な学習アルゴリズム、例えば転移学習等を利用してもよい。

【0040】

上記の暗号鍵の需要の予測結果に基づいて、ＱＫＤＮサービスの提供を受けるエンドユーザは、ＱＫＤＮサービスの課金契約やＳＬＡ（Service Level Agreement）等も踏まえて、ＱＫＤＮサービス事業者（具体的にはＱＫＤＮマネージャ２１）に対して、暗号鍵の提供を依頼する。その際、エンドユーザは、必ずしも全ての暗号鍵をワンタイムパッド（ＯＴＰ）方式で依頼する必要はなく、状況に応じて、一部もしくは全てをＡＥＳ（Advanced Encryption Standard）等の他方式で依頼することとしてもよい。例えば、あるエンドユーザのあるアプリケーションについて１ヶ月間の暗号鍵の需要予測を行った結果、月ごと契約容量（ＧＢ）を超えていた場合、エンドユーザは、一部をＡＥＳ方式にすることなどを検討する。このような方式の切り替えも考慮に入れつつ、エンドユーザは、ＱＫＤＮサービス事業者に対して、適切なサイズの暗号鍵の提供を依頼する。そして、その依頼を基に、ＱＫＤＮサービス事業者（主に管理サーバ２０の運営事業者）は、ＱＫＤＮインフラ事業者（主にＱＫＤノードの運営事業者）に対して、送信端末と受信端末の間の鍵リレー要求を行う。

【0041】

鍵管理レイヤのＫＭリンク毎の暗号鍵の消費量の予測としては、ＱＫＤＮインフラ事業者が、ＱＫＤＮの鍵管理レイヤのＫＭリンク毎に、ＡＩ技術（機械学習）を活用して、過去の鍵消費量の時間変動データに対して教師有り学習を実行し、各リンクにおける未来（ｔ時間後）の暗号鍵の消費量を予測する学習済みモデルを構築する。この学習済みモデルを利用して取得した暗号鍵の消費量の予測値は、管理サーバ２０のＱＫＤＮマネージャ２１からＱＫＤノード１０の鍵リレー経路計算エンジン１４に提供され、この鍵リレー経路計算エンジン１４による暗号鍵のリレー経路を算出するための一つの要素として利用される。また、ここに記載した「ｔ時間後」の変数ｔは、正の整数であり、アプリケーションの動作時間、すなわち、送信端末３０と受信端末４０との間で行われる暗号通信の動作時間である。このため、変数ｔはアプリケーション毎に異なる数値となる。すなわち、アプリケーション毎にｔ時間内で消費されるリンク毎の鍵消費量を予測することで、当該予測値に基づいて各アプリケーションに適した鍵リレー経路選択が可能となる。

【0042】

具体的には、ＡＩエンジン２２は、ＱＫＤＮの鍵管理レイヤを構成するＫＭリンク毎に、過去の暗号鍵の消費日時や鍵消費量の時間変動データに対して教師有り学習を実行し、各ＫＭリンクにおける未来の鍵消費量を予測するための学習済みモデルを生成する。教師有り学習のアルゴリズムは、特に限定されず、主に時系列データを扱う公知の学習アルゴリズムを用いることができる。例えば、学習アルゴリズムとしては、ディープラーニングモデルの１種である長・短期記憶（ＬＳＴＭ：Long Short Term Memory）や、回帰型ニューラルネットワーク（ＲＮＮ：Recurrent Neural Network）を用いてもよい。なお、過去の同アプリケーションのデータセットが少ない場合には、擬似的なデータを生成して教師データとして使用してもよい。また、データセットが少ない場合においても有効な学習アルゴリズム、例えば転移学習等を利用してもよい。

【0043】

また、ＡＩエンジン２２は、前述した暗号鍵の消費量の予測と同様の手法を用いて、鍵管理レイヤのＫＭリンク毎の暗号鍵の未来（ｔ時間後）の生成量を予測するための学習済みモデルを構築することとしてもよい。ただし、暗号鍵の生成量は、リンクを構成するＱＫＤノード１０の処理性能に依存するものであり、基本的には単位時間あたり一定の暗号鍵の生成量が見込めることから、ＡＩ技術（機械学習）を用いなくても、ある程度確度の高い予測が可能である。このため、暗号鍵の生成量の予測値については、ＡＩエンジン２２を利用せずに、ＱＫＤＮマネージャ２１又はＱＫＤＮコントローラ１３にて所定の演算によって求めることとしてもよい。

【0044】

図１に示されるように、量子レイヤ、暗号鍵管理レイヤ、ＱＫＤＮ制御レイヤ、及びＱＫＤＮ管理レイヤを含むＱＫＤＮは、ユーザネットワークに対して暗号鍵（Ｋ_１）を提供する。ユーザネットワークは、サービスレイヤ及びユーザネットワーク管理レイヤを有するものと観念できる。サービスレイヤには、送信端末３０と受信端末４０の暗号アプリケーションが配置される。送信端末３０と受信端末４０は、ＱＫＤＮから暗号鍵の供給を受けて、インターネット等のアプリケーションリンクを介して安全な通信を行う。ユーザネットワーク管理レイヤは、ネットワークマネージャ２３により構成される。ネットワークマネージャ２３は、ユーザネットワーク内の仮想化と非仮想化リソースの管理及びオーケストレーション（管理の自動化）を実行する。図１に示した例では、ネットワークマネージャ２３は、管理サーバ２０に備えられている。ただし、管理サーバ２０とは別のサーバ装置にネットワークマネージャ２３を設けることとしてもよい。

【0045】

図２は、ＱＫＤシステム１００，送信端末３０，及び受信端末４０を構成する機能ブロックを示している。ＱＫＤシステム１００は、前述した通り、主に複数のＱＫＤノード１０と管理サーバ２０を含む。各ＱＫＤノード１０は、前述した量子鍵配送モジュール１１を備え、これは光ファイバを介した量子鍵配送のための専用のハードウェアである。また、各ＱＫＤノード１０は、前述した暗号鍵マネージャ１２、ＱＫＤＮコントローラ１３、及び鍵リレー経路計算エンジン１４を備え、これらの要素はコンピュータが備えるプロセッサ、メモリ、及びストレージといったハードウェアによって実現される。プロセッサとしては、ＣＰＵ及び／又はＧＰＵを採用すればよい。プロセッサは、メモリに記憶されているプログラムやデータに従って所定の演算処理を行い、その演算結果をメモリやストレージに書き出しながら各種の制御処理を実行する。メモリは、例えばＲＡＭ等の揮発性メモリや、フラッシュメモリ等の不揮発性メモリから構成され、上記したプロセッサによる演算処理に利用される。ストレージは、例えばＨＤＤ及びＳＤＤといった不揮発性メモリによって実現され、プロセッサにより処理される前のデータや、プロセッサにより処理された後のデータを蓄積する用途で用いられる。また、各ＱＫＤノード１０は、インターネット等の汎用的な通信回線を通じて管理サーバ２０や送信端末３０，受信端末４０と通信するための通信部１５を有する。通信部１５は、例えば有線ＬＡＮや無線ＬＡＮで通信回線に接続するためのインタフェースを含む。無線ＬＡＮでの接続である場合、通信部１３は、例えば３Ｇ（W-CDMA）、４Ｇ（LTE／LTE-Advanced）、５Ｇといった公知の移動通信規格や、Wi-Fi（登録商標）等の公知の通信モジュールを採用すればよい。

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

１０…ＱＫＤノード １１…量子鍵配送モジュール
１２…暗号鍵マネージャ １３…ＱＫＤＮコントローラ
１２ａ…暗号鍵生成部 １２ｂ…暗号鍵記憶部
１２ｃ…鍵リレー部 １４…鍵リレー経路計算エンジン
１５…通信部 ２０…管理サーバ
２１…ＱＫＤＮマネージャ ２２…ＡＩエンジン（予測部）
２２ａ…学習済みモデル ２３…ネットワークマネージャ
２４…通信部 ３０…送信端末
３１…制御部 ３２…記憶部
３３…通信部 ３４…出力部
３５…入力部 ４０…受信端末
４１…制御部 ４２…記憶部
４３…通信部 ４４…出力部
４５…入力部 １００…ＱＫＤシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】