JP2022116672A - 量子鍵配送サービスプラットフォーム - Google Patents

Abstract

【課題】暗号鍵を適応的に管理することができる量子鍵配送サービスプラットフォームを提供する。【解決手段】実施形態によれば、量子鍵配送サービスプラットフォームは、複数の量子鍵配送装置と、管理サーバと、を具備する。複数の量子鍵配送装置は、他の量子鍵配送装置との間で暗号鍵情報を送受信し、前記暗号鍵情報に基づき、前記他の量子鍵配送装置と共有される暗号鍵を生成する。管理サーバは、複数の量子鍵配送装置において複数の暗号通信装置ごとに蓄積される暗号鍵の蓄積量を監視し、複数の暗号通信装置のそれぞれの暗号鍵の消費実績を記録し、暗号鍵の消費実績に基づき、複数の暗号通信装置のそれぞれの暗号鍵の消費量を予測し、暗号鍵の蓄積量と暗号鍵の消費量の予測結果とに基づき、複数の暗号通信装置の間の暗号通信において生じ得る暗号鍵の不足の予兆を検知する。【選択図】図２

Description

本発明の実施形態は、量子鍵配送サービスプラットフォームに関する。

近年、ネットワークを介して接続される拠点間でデータを暗号化して送受信することが日常的に行われている。また、暗号文だけでは解読不可能なＯＴＰ（ワンタイムパッド暗号）が広く使用されている。ＯＴＰは、データと同量の暗号鍵を消費する。そして、ＯＴＰで暗号通信を行うにあたっては、大量に消費される暗号鍵を拠点間で安全に共有することが求められる。このようなことから、量子力学の原理で暗号鍵（量子鍵）を共有する量子鍵配送が注目を集めている。

特許第６６１５７１８号公報

量子鍵配送は、光子の挙動を利用する技術であり、光ファイバ（または真空）を媒体として拠点間で光子により暗号鍵情報を送受信することで暗号鍵を生成・共有する。暗号鍵の生成・共有には一定の時間がかかる。データ通信速度が飛躍的に向上している昨今においては、単位時間当たりに暗号通信により暗号鍵が消費される量が、単位時間当たりに暗号鍵を生成・共有できる量を上回る可能性がある。従って、暗号通信を一定期間安定的に継続させるためには、ある程度の量の暗号鍵を蓄積しておくことが求められる。

たとえば拠点間で暗号通信を行うユーザ向けに、量子鍵配送で生成・共有した暗号鍵を各拠点に提供するサービスを提供する場合、コストとの兼ね合いから、暗号鍵の生成・共有性能や暗号鍵の蓄積可能量、つまり、暗号鍵の供給能力には上限が設けられざるを得ない。そのため、いずれのユーザにおいても暗号鍵の不足（枯渇）が生じないように、各ユーザの暗号鍵の消費状況に応じて、暗号鍵を適応的に管理する必要がある。

本発明が解決しようとする課題は、暗号鍵を適応的に管理することができる量子鍵配送サービスプラットフォームを提供することである。

実施形態によれば、量子鍵配送サービスプラットフォームは、複数の量子鍵配送装置と、管理サーバと、を具備する。複数の量子鍵配送装置は、他の量子鍵配送装置との間で暗号鍵情報を送受信し、前記暗号鍵情報に基づき、前記他の量子鍵配送装置と共有される暗号鍵を生成する。管理サーバは、複数の量子鍵配送装置において複数の暗号通信装置ごとに蓄積される暗号鍵の蓄積量を監視し、複数の暗号通信装置のそれぞれの暗号鍵の消費実績を記録し、暗号鍵の消費実績に基づき、複数の暗号通信装置のそれぞれの暗号鍵の消費量を予測し、暗号鍵の蓄積量と暗号鍵の消費量の予測結果とに基づき、複数の暗号通信装置の間の暗号通信において生じ得る暗号鍵の不足の予兆を検知する。

実施形態の量子鍵配送サービスプラットフォームの一構成例を示す図 実施形態の量子鍵配送サービスプラットフォームの量子鍵配送サービス管理サーバの機能ブロックの一例を示す図 実施形態の量子鍵配送サービスプラットフォームにおいて行われ得る暗号鍵の振り替え制御を説明するための図 実施形態の量子鍵配送サービスプラットフォームにおいて用いられるユーザ管理ＤＢの一例を示す図 実施形態の量子鍵配送サービスプラットフォームにおいて用いられる暗号鍵蓄積量管理ＤＢの一例を示す図 実施形態の量子鍵配送サービスプラットフォームにおいて用いられる暗号鍵消費実績管理ＤＢの一例を示す図 実施形態の量子鍵配送サービスプラットフォームにおいて用いられる暗号鍵消費予測管理ＤＢの一例を示す図 実施形態の量子鍵配送サービスプラットフォームの量子鍵配送サービス管理サーバによる暗号鍵の消費量の予測の流れの一例を示すフローチャート 実施形態の量子鍵配送サービスプラットフォームの量子鍵配送サービス管理サーバによる暗号鍵の割り当て量の決定および暗号鍵の不足の予兆の検知の流れの一例を示すフローチャート 実施形態の量子鍵配送サービスプラットフォームの量子鍵配送サービス管理サーバによる暗号鍵の融通処理の流れの一例を示すフローチャート

以下、実施の形態について、図面を参照して説明する。

図１は、本実施形態の量子鍵配送サービスプラットフォーム１の一構成例を示す図である。図１には、量子鍵配送サービスプラットフォーム１から暗号鍵（量子鍵）の提供を受ける量子鍵ユーザ２が実行する暗号通信の一態様例が併せて示されている。

量子鍵配送サービスプラットフォーム１は、ＯＴＰで暗号通信を行うユーザ向けに量子鍵配送サービスを提供する。具体的には、量子鍵配送サービスプラットフォーム１は、拠点間で暗号通信を行うユーザの各拠点に共有化された暗号鍵を供給する。この量子鍵配送サービスを利用することで、ユーザは、拠点間で暗号鍵を生成・共有するために必要なリソースが不要となる。

量子鍵配送サービスプラットフォーム１は、量子鍵配送システム２０を有する。量子鍵配送システム２０は、各地に点在する複数の量子鍵配送センター２１の量子鍵配送装置２１Ａが光ファイバを介して接続される光ファイバ網として構成される。複数の量子鍵配送センター２１のそれぞれには、１以上の量子鍵配送装置２１Ａが配置されている。

量子鍵配送装置２１Ａは、他の量子鍵配送装置２１Ａとの間で、光子により暗号鍵情報を送受信し、双方で、暗号鍵情報に基づき、共有化された暗号鍵を生成する。量子鍵配送装置２１Ａは、暗号鍵情報を中継する中継装置としても機能する。つまり、光ファイバで直接的に接続される量子鍵配送装置２１Ａの間だけでなく、１以上の量子鍵配送装置２１Ａが介在する量子鍵配送装置２１Ａの間でも、暗号鍵を共有することができる。量子鍵配送センター２１がＮ箇所に存在すると想定した場合、共有化された暗号鍵を生成することができる２つの量子鍵配送センター２１の組みは、（Ｎ×（Ｎ－１））／（２×１）通り設定し得る。

また、量子鍵配送サービスプラットフォーム１は、量子鍵流通レイヤ３０を有する。量子鍵流通レイヤ３０は、量子鍵配送システム２０の量子鍵配送センター２１をノード３１に擬し、かつ、ノード３１の間が通信路で接続されているものと想定した仮想的な通信網として構成される。量子鍵流通レイヤ３０は、複数の通信網を含み得る。量子鍵流通レイヤ３０の複数の通信網は、地域で分けて作成されてもよいし、量子鍵ユーザ２をいくつかのグループに分散させるために作成されてもよい。

量子鍵流通レイヤ３０のノード３１は、量子鍵配送サービスプラットフォーム１のアクセスポイントとして位置づけられる。ＯＴＰで暗号通信を行う量子鍵ユーザ２の暗号通信サーバ５０は、それぞれ、たとえば最寄りの量子鍵配送センター２１に対応するノード３１から暗号鍵の供給を受ける。この際、暗号通信サーバ５０と、ノード３１は、同一敷地、あるいは、同一の建屋内に配置され、その間の通信については物理的な防御がなされているものとする。

前述したように、量子鍵配送センター２１がＮ箇所に存在すると想定した場合、暗号鍵を共有する２つの量子鍵配送センター２１の組みは、（Ｎ×（Ｎ－１））／（２×１）通り設定し得る。従って、量子鍵配送サービスプラットフォーム１は、（Ｎ×（Ｎ－１））／（２×１）通りの区間について、暗号鍵を供給するサービスを提供し得る。また、前述したように、量子鍵配送センター２１には、１以上の量子鍵配送装置２１Ａが配置されている。当該１以上の量子鍵配送装置２１Ａによって生成される暗号鍵は、その量子鍵配送センター２１を一端として設定されている各区間で行われる各暗号通信に対して割り当てられる。また、当該１以上の量子鍵配送装置２１Ａによって生成される暗号鍵の一部は、それらの暗号通信の予備として割り当てられる。

つまり、暗号通信サーバ５０が、複数の暗号通信サーバ５０との間で暗号通信を行う場合、この暗号通信サーバ５０に対しては、通信相手別に暗号鍵が供給される。たとえば、東京の拠点の暗号通信サーバ［１］５０が、大阪の拠点の暗号通信サーバ［２］５０と暗号通信を行うとともに、福岡の暗号通信サーバ［３］５０とも暗号通信を行うケースにおいては、量子鍵配送サービスプラットフォーム１は、暗号通信サーバ［１］５０と暗号通信サーバ［２］５０との組みに対して、それぞれが接続されるノード３１に対応する量子鍵配送センター２１の間で生成・共有された暗号鍵を供給し、暗号通信サーバ［１］５０と暗号通信サーバ［３］５０との組みに対して、それぞれが接続されるノード３１に対応する量子鍵配送センター２１の間で生成・共有された暗号鍵を供給する。すなわち、このケースにおいては、暗号通信サーバ［１］５０には、暗号通信サーバ［２］５０との暗号通信のための暗号鍵がノード３１から供給され、かつ、暗号通信サーバ［３］５０との暗号通信のための暗号鍵が同一のノード３１から供給される。

また、量子鍵配送サービスプラットフォーム１は、暗号通信を行う暗号通信サーバ５０に対して、通信相手に送信するデータを暗号化するための暗号鍵と、通信相手から受信した暗号化されたデータを復号するための暗号鍵とを供給する。従って、上記のケースにおいては、量子鍵配送サービスプラットフォーム１は、たとえば暗号通信サーバ［１］５０に対しては、通信相手別・通信方向別の６種の暗号鍵をノード３１から供給する。

なお、量子鍵流通レイヤ３０は、仮想的な通信網としてではなく、現実的な通信網として構成されてもよい。量子鍵配送サービスプラットフォーム１は、量子鍵流通レイヤ３０の通信網を、ノード３１から暗号鍵の供給を受けて暗号通信を行う量子鍵ユーザ２に暗号通信路として貸与してもよい。この通信網は、光ファイバ網である必要はない（光ファイバ網であってもよい）。

量子鍵配送サービスプラットフォーム１は、以上のような、量子鍵ユーザ２の暗号通信サーバ５０に対する、量子鍵流通レイヤ３０のノード３１を介した、量子鍵配送システム２０の量子鍵配送センター２１（量子鍵配送装置２１Ａ）からの暗号鍵の供給を適応的に管理するための量子鍵配送サービス管理サーバ１０を有する。本実施形態の量子鍵配送サービスプラットフォーム１は、量子鍵配送サービス管理サーバ１０が、暗号鍵の不足（枯渇）の予兆を検知し、暗号鍵が不足する前に、たとえばユーザ間で暗号鍵を融通し合うことなどを可能としたものであり、以下、この点について詳述する。

図２は、量子鍵配送サービス管理サーバ１０の機能ブロックの一例を示す図である。図２には、量子鍵配送装置２１Ａおよび暗号通信サーバ５０の機能ブロックの一例が併せて示されている。

暗号通信サーバ５０は、暗号通信部５１を有する。暗号通信部５１は、他の拠点の暗号通信サーバ５０の暗号通信部５１と暗号通信を実行する。暗号通信サーバ５０は、たとえば拠点内の複数のＰＣ（personal computer）とＬＡＮ（local area network）経由で接続されている。暗号通信部５１は、量子鍵配送装置２１Ａ（暗号通信部５１からはノード３１として認識されている）から暗号鍵の供給を受けて、暗号通信サーバ５０に接続されているＰＣが他の拠点の暗号通信サーバ５０に接続されているＰＣとの間で送受信するデータの暗号化および復号を実行する。

量子鍵配送装置２１Ａは、暗号鍵生成部２０１、暗号鍵供給部２０２および暗号鍵振替制御部２０３を有する。また、量子鍵配送装置２１Ａは、たとえばＨＤＤ（hard disk drive）などの記憶媒体上に設けられる暗号鍵蓄積部２５１を有する。なお、図２には、量子鍵配送センター２１に配置される１以上の量子鍵配送装置２１Ａの集合体を、１つの量子鍵配送装置２１Ａとして示している。従って、図２の量子鍵配送装置２１Ａは、量子鍵配送センター２１と読み替えることもできる。また、たとえば、図２に量子鍵配送装置２１Ａの構成要素として示す各部の一部が、個々の量子鍵配送装置２１Ａにではなく量子鍵配送センター２１に存在してもよい。

暗号鍵生成部２０１は、他の量子鍵配送装置２１Ａの暗号鍵生成部２０１との間で光子により暗号鍵情報を送受信し、この暗号鍵情報に基づき、当該暗号鍵生成部２０１を搭載する量子鍵配送装置２１Ａと他の量子鍵配送装置２１Ａとの間で共有される暗号鍵を生成する。暗号鍵情報の送受信は、一方から他方へ一方的に行わるものであってもよいし、双方向で行われるものであってもよい。双方向で行われる場合、たとえば、一方から他方へ転送される暗号鍵情報は、一方から他方へ転送されるデータの暗号化に用いられる暗号鍵を生成するためのものであってもよいし、他方から一方へ転送される暗号鍵情報は、他方から一方へ転送されるデータの暗号化に用いられる暗号鍵を生成するためのものであってもよい。

暗号鍵生成部２０１は、生成した暗号鍵を暗号鍵蓄積部２５１に蓄積する。前述したように、暗号鍵は、通信相手別・通信方向別に用意する必要がある。従って、暗号鍵生成部２０１は、生成した暗号鍵を、この通信相手別・通信方向別に暗号鍵蓄積部２５１に蓄積する。生成した暗号鍵をどのような割合で通信相手別・通信方向別に割り当てて暗号鍵蓄積部２５１に蓄積するかは、後述する、量子鍵配送サービス管理サーバ１０の暗号鍵融通制御部１０３の暗号鍵消費予測の結果に基づく。なお、暗号鍵生成部２０１は、単位時間当たりの暗号鍵の生成量のうちの一定量については通信相手別・通信方向別に均等に割り当てて、残りの分を、暗号鍵融通制御部１０３の暗号鍵消費予測の結果に基づき、通信相手別・通信方向別に割り当てるようにしてもよい。また、暗号鍵生成部２０１は、一定量の暗号鍵を、予備として暗号鍵蓄積部２５１上に確保する。

暗号鍵生成部２０１は、暗号鍵の生成を継続的に行っている。暗号通信が行われていない場合など、暗号鍵蓄積部２５１の暗号鍵の蓄積量が上限値に達した場合、暗号鍵生成部２０１は、たとえば古い順に暗号鍵を破棄して新たに生成した暗号鍵に置き換える。

暗号鍵供給部２０２は、暗号通信部５１からの要求に応じて、暗号鍵蓄積部２５１に蓄積されている暗号鍵を読み出して暗号通信部５１に送信する。ここでは、量子鍵配送装置２１Ａは、暗号通信サーバ５０に対して、暗号通信部５１が行う暗号通信ごとに対応づけられるものと想定する。つまり、暗号通信サーバ５０に対しては、複数の量子鍵配送装置２１Ａが対応づけられ得る。また、ここでは、単位時間当たりに暗号通信部５１により暗号鍵が消費される量が、単位時間当たりに暗号鍵生成部２０１が暗号鍵を生成できる量を上回るものと想定する。従って、暗号通信部５１の暗号通信が継続している間、その暗号通信のための暗号鍵蓄積部２５１の暗号鍵の蓄積量は減少していく。暗号鍵供給部２０２は、たとえば一定量の暗号鍵を供給する都度といった所定のタイミングごとに、暗号鍵の消費量と、暗号鍵蓄積部２５１の暗号鍵の蓄積量とを、量子鍵配送サービス管理サーバ１０に通知する。

暗号鍵振替制御部２０３は、量子鍵配送サービス管理サーバ１０の指示に基づき、暗号鍵蓄積部２５１に蓄積されている暗号鍵を、たとえば、同じ量子鍵配送センター２１に配置されている他の量子鍵配送装置２１Ａとの間で融通し合うといった、暗号鍵の振り替え制御を実行する。

ここで、図３を参照して、量子鍵配送サービス管理サーバ１０の支配下で暗号鍵振替制御部２０３が行い得る暗号鍵の振り替え制御について説明する。

たとえば、量子鍵流通レイヤ３０のノード［Ａ］３１とノード［Ｂ］３１とを結ぶ区間を利用するユーザとして、量子鍵ユーザ［１］２と量子鍵ユーザ［２］２とが存在するものと想定する。量子鍵ユーザ［１］２は、暗号通信サーバ［１］５０がノード［Ａ］３１から暗号鍵の供給を受け、また、暗号通信サーバ［２］５０がノード［Ｂ］３１から暗号鍵の供給を受けて、暗号通信サーバ［１］５０と暗号通信サーバ［２］５０との間で暗号通信を行う。

一方、量子鍵ユーザ［２］２は、暗号通信サーバ［３］５０がノード［Ａ］３１から暗号鍵の供給を受け、また、暗号通信サーバ［４］５０がノード［Ｂ］３１から暗号鍵の供給を受けて、暗号通信サーバ［３］５０と暗号通信サーバ［４］５０との間で暗号通信を行う。

また、量子鍵配送システム２０においては、量子鍵配送装置［Ａ１］２１と量子鍵配送装置［Ｂ１］との間で暗号鍵が生成・共有されるとともに、量子鍵配送装置［Ａ２］２１と量子鍵配送装置［Ｂ２］との間で暗号鍵が生成・共有される。ここでは、分かりやすくするために、暗号通信サーバ［１］５０に対しては、量子鍵配送装置［Ａ１］２１によって生成された暗号鍵がノード［Ａ］３１経由で供給され、また、暗号通信サーバ［２］５０に対しては、量子鍵配送装置［Ｂ１］２１によって生成された暗号鍵がノード［Ｂ］３１経由で供給されるものと想定する。さらに、暗号通信サーバ［３］５０に対しては、量子鍵配送装置［Ａ２］２１によって生成された暗号鍵がノード［Ａ］３１経由で供給され、また、暗号通信サーバ［４］５０に対しては、量子鍵配送装置［Ｂ２］２１によって生成された暗号鍵がノード［Ｂ］３１経由で供給されるものと想定する。

量子鍵配送装置［Ａ１］２１は、暗号通信サーバ［１］５０が暗号通信サーバ［２］５０へ送信するデータを暗号化するための暗号鍵ａ１と、暗号通信サーバ［１］５０が暗号通信サーバ［２］５０から受信した（暗号化されている）データを復号するための暗号鍵ａ２とを、暗号鍵蓄積部２５１に蓄積する。

量子鍵配送装置［Ｂ１］２１も、暗号鍵ａ１と、暗号鍵ａ２とを、暗号鍵蓄積部２５１に蓄積する。量子鍵配送装置［Ｂ１］２１においては、暗号鍵ａ１は、暗号通信サーバ［２］５０が暗号通信サーバ［１］５０から受信した（暗号化されている）データを復号するために用いられ、暗号鍵ａ２は、暗号通信サーバ［２］５０が暗号通信サーバ［１］５０へ送信するデータを暗号化するために用いられる。

量子鍵配送装置［Ａ２］２１は、暗号通信サーバ［３］５０が暗号通信サーバ［４］５０へ送信するデータを暗号化するための暗号鍵ａ３と、暗号通信サーバ［３］５０が暗号通信サーバ［４］５０から受信した（暗号化されている）データを復号するための暗号鍵ａ４とを、暗号鍵蓄積部２５１に蓄積する。

量子鍵配送装置［Ｂ２］２１も、暗号鍵ａ３と、暗号鍵ａ４とを、暗号鍵蓄積部２５１に蓄積する。量子鍵配送装置［Ｂ２］２１においては、暗号鍵ａ３は、暗号通信サーバ［４］５０が暗号通信サーバ［３］５０から受信した（暗号化されている）データを復号するために用いられ、暗号鍵ａ４は、暗号通信サーバ［４］５０が暗号通信サーバ［３］５０へ送信するデータを暗号化するために用いられる。

前述したように、ある暗号通信の継続している間、その暗号通信に関しては、暗号鍵の需要量（消費量）が暗号鍵の供給量（生成量）を上回る。従って、その暗号通信のための暗号鍵の蓄積量は減少していく。暗号鍵の不足（枯渇）を回避するために、本実施形態の量子鍵配送サービスプラットフォーム１においては、量子鍵配送サービス管理サーバ１０の支配の下、暗号鍵振替制御部２０３が、暗号鍵ａ１～ａ４の間で暗号鍵の振り替えを行う。たとえば、ある暗号通信の第１方向のデータ転送に使用される暗号鍵の蓄積量が枯渇しかかっているとき、第１方向と逆の第２方向のデータ転送に使用される暗号鍵の蓄積量に余裕がある場合、その暗号通信の２方向間で暗号鍵の振り替えを行い得る（ａ１１、ａ１２）。また、同一区間の２つの暗号通信の一方の暗号鍵の蓄積量が枯渇しかかっているとき、他方の暗号鍵の蓄積量に余裕がある場合、当該２つの暗号通信間で暗号鍵の振り替えを行い得る（ａ１３～ａ１６）。２つの暗号通信間での暗号鍵の振り替えは、同一方向のデータ転送に使用される暗号鍵を対象として行い得るし（ａ１３、ａ１４）、互いに異なる方向のデータ転送に使用される暗号鍵を対象として行い得る（ａ１５、ａ１６）。ある暗号通信の２方向間での暗号鍵の振り替え（ａ１１、ａ１２）と、２つの暗号通信間での暗号鍵の振り替え（ａ１３～ａ１６）とは、複合的に行い得る。

図２に戻り、量子鍵配送サービス管理サーバ１０について説明する。

量子鍵配送サービス管理サーバ１０は、ユーザ管理部１０１、暗号鍵需給管理部１０２および暗号鍵融通制御部１０３を有する。また、量子鍵配送サービス管理サーバ１０は、たとえばＨＤＤなどの記憶媒体上に設けられる、ユーザ管理ＤＢ（data base）１５１、暗号鍵蓄積量管理ＤＢ１５２、暗号鍵消費実績管理ＤＢ１５３および暗号鍵消費予測管理ＤＢ１５４を有する。

ユーザ管理部１０１は、たとえばインターネットを介して、量子鍵配送サービスプラットフォーム１の利用申請を受け付け、その申請時に得られた量子鍵ユーザ２の情報を、ユーザ管理ＤＢ１５１を用いて管理する。ユーザ管理部１０１は、量子鍵配送サービスプラットフォーム１の利用形態の変更の申請や利用停止の申請も受け付ける。図４は、ユーザ管理ＤＢ１５１の一例を示す図である。

ユーザ管理ＤＢ１５１は、ユーザＩＤと、１以上の区間情報とを格納する。ユーザＩＤは、量子鍵ユーザ２を識別するための情報である。区間情報は、量子鍵ユーザ２が利用する区間を示す情報である。区間情報は、たとえば２つのノード３１の組みで表される。たとえば３つの区間について暗号鍵の供給を受ける量子鍵ユーザ２の場合、３つの区間情報が格納される。

暗号鍵需給管理部１０２は、量子鍵配送装置２１Ａから通知されてくる、暗号鍵の消費量と、暗号鍵の蓄積量とに基づき、暗号鍵蓄積量管理ＤＢ１５２と、暗号鍵消費実績管理ＤＢ１５３とを更新する。

図５は、暗号鍵蓄積量管理ＤＢ１５２の一例を示す図である。暗号鍵蓄積量管理ＤＢ１５２は、量子鍵流通レイヤ３０の２つのノード３１の組みである区間ごとに、ユーザＩＤと、第１方向の暗号鍵の蓄積量と、（第１方向と逆の）第２方向の暗号鍵の蓄積量とを格納する。また、暗号鍵蓄積量管理ＤＢ１５２は、予備の暗号鍵の蓄積量も格納する。

ユーザＩＤは、ユーザ管理ＤＢ１５１と同様、量子鍵ユーザ２を識別するための情報である。第１方向の暗号鍵の蓄積量は、ユーザＩＤで示される量子鍵ユーザ２が行う暗号通信の第１方向の暗号鍵の蓄積量である。第２方向の暗号鍵の蓄積量は、当該暗号通信の第２方向の暗号鍵の蓄積量である。暗号鍵の蓄積量は、暗号通信が実行されている間は減少し、暗号通信が実行されていない間は増加し、または、上限値に保たれている。

図６は、暗号鍵消費実績管理ＤＢ１５３の一例を示す図である。暗号鍵消費実績管理ＤＢ１５３は、区間およびユーザごとに、第１方向の暗号鍵の消費量と、第２方向の暗号鍵の消費量とを、たとえば１０分間や１時間などの一定幅の時間帯単位に格納する。これらの情報は、たとえば３年分など、予め設定された期間分、暗号鍵消費実績管理ＤＢ１５３によって蓄積される。

図２に戻り、量子鍵配送サービス管理サーバ１０の説明を続ける。

暗号鍵融通制御部１０３は、暗号鍵消費実績管理ＤＢ１５３の情報を用いて、量子鍵配送サービスプラットフォーム１を利用して行われ得るすべての暗号通信を対象として、一定期間先までの暗号鍵の消費量を予測することを定期的に行い、その結果を暗号鍵消費予測管理ＤＢ１５４に格納する。暗号鍵融通制御部１０３は、前回の予測時と今回の予測時との間で予測対象期間が重複する場合、その重複する期間の暗号鍵の消費量を今回の予測結果に更新する。暗号鍵融通制御部１０３は、この予測を、たとえばＡＩ（artificial intelligence）１１０により実行する。

ＡＩ１１０は、過去の暗号鍵の消費傾向から将来の暗号鍵の消費量を予測するための暗号鍵消費予測モデル１１１を有する。暗号鍵消費予測モデル１１１は、たとえば直近１時間の暗号鍵の消費量の推移、直近１週間の同一時間帯の暗号鍵の消費量、直近１ヵ月の同一曜日・同一時間帯の暗号鍵の消費量、直近３年の同一年月日・同一時間帯の暗号鍵の消費量などを入力し、たとえば向こう１日分の暗号鍵の消費量を予測するために構築されるモデルである。この暗号鍵消費予測モデル１１１を含む、ＡＩ１１０の各種モデルを構築する方法は、特定の方法に限らず、既知の様々な方法を採用し得る。

図７は、暗号鍵消費予測管理ＤＢ１５４の一例を示す図である。暗号鍵消費予測管理ＤＢ１５４は、区間およびユーザごとに、第１方向の暗号鍵の消費予測量と、第２方向の暗号鍵の消費予測量とを一定幅の時間帯単位に格納する。時間帯の幅は、図６に示した暗号鍵消費実績管理ＤＢ１５３の時間帯の幅と一致していることが好ましい。

また、暗号鍵融通制御部１０３は、暗号鍵蓄積量管理ＤＢ１５２の情報と、暗号鍵消費予測管理ＤＢ１５４の情報とを用いて、量子鍵配送サービスプラットフォーム１を利用して実行中の暗号通信を対象として、暗号鍵の不足の予兆を検知する。暗号鍵の不足の予兆の検知には、さらに、暗号鍵消費実績管理ＤＢ１５３の情報が用いられてもよい。暗号鍵融通制御部１０３は、この検知を、たとえばＡＩ１１０により実行する。

ＡＩ１１０は、現在の暗号鍵の蓄積量と、暗号鍵消費予測モデル１１１で予想された暗号鍵の消費量とから、暗号鍵の不足の予兆を検知するための暗号鍵不足予知モデル１１２を有する。暗号鍵不足予知モデル１１２は、さらに、たとえば直近１時間などの過去の暗号鍵の消費傾向を考慮するものであってもよい。暗号鍵不足予知モデル１１２は、たとえば暗号鍵消費予測モデル１１１で予想された暗号鍵の消費量を大きく上回る突発的な暗号鍵の消費などによって生じる、暗号鍵の不足の予兆を検知するために構築されるモデルである。暗号鍵不足予知モデル１１２は、実行中の暗号通信の暗号鍵の不足の予兆を検知するとともに、その暗号通信の暗号鍵の不足を回避するために必要な暗号鍵の量を出力する。

また、暗号鍵融通制御部１０３は、暗号鍵の不足の予兆が検知された場合であって、予備として蓄積される暗号鍵では不足分を補填しきれない場合、暗号鍵蓄積量管理ＤＢ１５２の情報と、暗号鍵消費予測管理ＤＢ１５４の情報とを用いて、その暗号鍵の不足の予兆の検知に伴って出力された、その暗号鍵の不足を回避するために必要な量の暗号鍵を、どこから捻出して補填すべきかを判定する。図３には、２つの量子鍵ユーザ２間での暗号鍵の補填ルート（ａ１１～ａ１６）を示したが、同一区間で多数の量子鍵ユーザが暗号通信を行う現実では、暗号鍵の補填源の候補は多数に上る。暗号鍵融通制御部１０３は、この判定を、たとえばＡＩ１１０により実行する。

ＡＩ１１０は、現在の暗号鍵の蓄積量と、予測される将来の暗号鍵の消費量とから、暗号鍵に余剰が生じることが見込まれ、暗号鍵の補填源とするのに適した暗号通信を選定するための暗号鍵補填ルート選定モデル１１３を有する。暗号鍵補填ルート選定モデル１１３は、さらに、たとえば直近１時間などの過去の暗号鍵の消費傾向を考慮するものであってもよい。暗号鍵補填ルート選定モデル１１３は、複数の暗号通信を選定し得る。暗号鍵補填ルート選定モデル１１３は、選定した１以上の暗号通信のそれぞれからの暗号鍵の補填量を出力する。

暗号鍵融通制御部１０３は、暗号鍵の不足の予兆が検知された暗号通信に関する量子鍵配送装置２１Ａの暗号鍵振替制御部２０３と、暗号鍵の補填源として選定された暗号通信に関する量子鍵配送装置２１Ａとのそれぞれに対して、暗号鍵の融通量を通知する。暗号鍵の不足が、暗号通信の２方向間での暗号鍵の振り替えによって解消し得る場合には、その暗号通信に関する量子鍵配送装置２１Ａのみに通知が行われる。

量子鍵配送装置２１Ａの暗号鍵振替制御部２０３は、量子鍵配送サービス管理サーバ１０からの指示に基づき、たとえば他の量子鍵配送装置２１Ａの暗号鍵振替制御部２０３との間で、暗号鍵蓄積部２５１に蓄積される暗号鍵についての振り替えを実行する。

このように、本実施形態の量子鍵配送サービスプラットフォーム１においては、ＡＩによって、暗号鍵の消費予測を行い、暗号鍵の不足の予兆を検知し、その不足を回避するための補填ルートを選定する。これにより、本実施形態の量子鍵配送サービスプラットフォーム１は、暗号鍵を適応的に管理することができる。

前述したように、量子鍵配送装置２１Ａの暗号鍵生成部２０１によって生成される暗号鍵は、一定量が、通信相手別・通信方向別に均等に割り当てられ、残りが、量子鍵配送サービス管理サーバ１０の暗号鍵融通制御部１０３の暗号鍵消費予測の結果に基づき、通信相手別・通信方向別に割り当てられてもよい。そこで、たとえば、均等に割り当てられる分の暗号鍵について融通が行われた場合、量子鍵配送サービス管理サーバ１０は、それらの量を管理し、量子鍵ユーザ２に対する課金額へ反映させてもよい。より詳しくは、均等に割り当てられた分の暗号鍵についての融通量に応じて、課金額を増減するといった料金体系を制定してもよい。

図８は、本実施形態の量子鍵配送サービスプラットフォーム１の量子鍵配送サービス管理サーバ１０による暗号鍵の消費量の予測の流れの一例を示すフローチャートである。量子鍵配送サービス管理サーバ１０は、暗号鍵の消費量の予測を、たとえば図６に示した暗号鍵消費実績管理ＤＢ１５３の時間帯の幅や図７に示した暗号鍵消費予測管理ＤＢ１５４の時間帯の幅ごとに定期的に実行する。前述したように、量子鍵流通レイヤ３０は、複数の通信網を含み得る。量子鍵配送サービス管理サーバ１０は、量子鍵流通レイヤ３０に含まれる通信網ごとに当該暗号鍵の消費量の予測を実行してもよい。

量子鍵配送サービス管理サーバ１０は、暗号鍵消費実績管理ＤＢ１５３から暗号鍵の消費量を取得する（Ｓ１０１）。量子鍵配送サービス管理サーバ１０は、取得した暗号鍵の消費量から暗号鍵の消費予測量を算出する（Ｓ１０２）。量子鍵配送サービス管理サーバ１０は、算出した暗号鍵の消費予測量を、暗号鍵消費予測管理ＤＢ１５４に格納する（Ｓ１０３）。

図９は、本実施形態の量子鍵配送サービスプラットフォーム１の量子鍵配送サービス管理サーバ１０による暗号鍵の割り当て量の決定および暗号鍵の不足の予兆の検知の流れの一例を示すフローチャートである。量子鍵配送サービス管理サーバ１０は、暗号鍵の割り当て量の決定および暗号鍵の不足の予兆の検知を継続的に実行する。暗号鍵の割り当て量の決定および暗号鍵の不足の予兆の検知も、量子鍵流通レイヤ３０に含まれる通信網ごとに実行されてもよい。

量子鍵配送サービス管理サーバ１０は、暗号鍵蓄積量管理ＤＢ１５２から暗号鍵の蓄積量を取得する（Ｓ２０１）。また、量子鍵配送サービス管理サーバ１０は、暗号鍵消費予測管理ＤＢ１５４から暗号鍵の消費予測量を取得する（Ｓ２０２）。量子鍵配送サービス管理サーバ１０は、取得した暗号鍵の蓄積量と暗号鍵の消費予測量とから、量子鍵配送装置２１Ａが生成する暗号鍵の割り当て量を決定する（Ｓ２０３）。このとき、量子鍵配送サービス管理サーバ１０は、さらに、暗号鍵消費実績管理ＤＢ１５３の情報を使用してもよい。また、このとき、量子鍵配送サービス管理サーバ１０は、量子鍵配送装置２１Ａによる暗号鍵の生成量を所定の割合で二分し、一方については均等に割り当てて、他方について割り当て量を動的に決定するようにしてもよい。

続いて、量子鍵配送サービス管理サーバ１０は、暗号鍵の蓄積量と暗号鍵の消費予測量とから、実行中の暗号通信の中で、たとえば予測された暗号鍵の消費量を大きく上回る突発的な暗号鍵の消費などによって生じる、暗号鍵の不足の予兆が現れている暗号通信が存在しないかを判定する（Ｓ２０４）。このとき、量子鍵配送サービス管理サーバ１０は、さらに、暗号鍵消費実績管理ＤＢ１５３の情報を使用してもよい。暗号鍵の不足の予兆を検知した場合（Ｓ２０４：ＹＥＳ）、量子鍵配送サービス管理サーバ１０は、図１０に詳細な流れの一例を示す、暗号鍵の融通処理を実行する（Ｓ２０６）。暗号鍵の不足の予兆が検知されない場合（Ｓ２０４：ＮＯ）、量子鍵配送サービス管理サーバ１０は、Ｓ２０６の処理をスキップする。

図１０は、暗号鍵の不足の予兆が検知された場合に実行される、図９のＳ２０６の暗号鍵の融通処理の詳細な流れの一例を示すフローチャートである。

量子鍵配送サービス管理サーバ１０は、まず、予備として蓄積される暗号鍵の補填を実行する（Ｓ３０１）。予備の補填で暗号鍵の不足が解消する場合（Ｓ３０１：ＹＥＳ）、量子鍵配送サービス管理サーバ１０は、その暗号通信に関する暗号鍵の融通処理を終了する。

暗号鍵の不足が解消されない場合（Ｓ３０２：ＮＯ）、量子鍵配送サービス管理サーバ１０は、暗号鍵蓄積量管理ＤＢ１５２から暗号鍵の蓄積量を取得する（Ｓ３０３）。また、量子鍵配送サービス管理サーバ１０は、暗号鍵消費実績管理ＤＢ１５３から暗号鍵の消費量を取得する（Ｓ３０４）。さらに、量子鍵配送サービス管理サーバ１０は、暗号鍵消費予測管理ＤＢ１５４から暗号鍵の消費予測量を取得する（Ｓ３０５）。

量子鍵配送サービス管理サーバ１０は、まず、暗号鍵の不足の予兆が検知された暗号通信に関して、不足の予兆が検知された方向とは逆方向の暗号通信の暗号鍵の蓄積量に余剰分があるかどうかを判定する（Ｓ３０６）。余剰分がある場合（Ｓ３０６：ＹＥＳ）、量子鍵配送サービス管理サーバ１０は、まずは、その暗号通信の２方向間での暗号鍵の融通を実行する（Ｓ３０７）。量子鍵配送サービス管理サーバ１０は、この２方向間での暗号鍵の融通で、暗号鍵の不足が解消するかどうかを判定する（Ｓ３０８）。解消する場合（Ｓ３０８：ＹＥＳ）、量子鍵配送サービス管理サーバ１０は、その暗号通信に関する暗号鍵の融通処理を終了する。

不足の予兆が検知された方向とは逆方向の暗号通信の暗号鍵の蓄積量に余剰分がない場合（Ｓ３０６：ＮＯ）、または、２方向間での暗号鍵の融通では暗号鍵の不足が解消されない場合（Ｓ３０８：ＮＯ）、量子鍵配送サービス管理サーバ１０は、同一区間で暗号通信を行う他の量子鍵ユーザ２の暗号通信において存在する暗号鍵の蓄積量の余剰分を検出する（Ｓ３０９）。量子鍵配送サービス管理サーバ１０は、暗号鍵の蓄積量の余剰分が検出された他の量子鍵ユーザ２を融通元として、ユーザ間での暗号鍵の融通を実行し（Ｓ３１０）、その暗号通信に関する暗号鍵の融通処理を終了する。

以上のように、本実施形態の量子鍵配送サービスプラットフォーム１においては、暗号鍵の消費予測を行い、暗号鍵の不足の予兆を検知し、その不足を回避するための補填ルートを選定する。これにより、本実施形態の量子鍵配送サービスプラットフォーム１は、暗号鍵を適応的に管理することができる。

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

１…量子鍵配送サービスプラットフォーム、２…量子鍵ユーザ、１０…量子鍵配送サービス管理サーバ、２０…量子鍵配送システム、２１…量子鍵配送センター、２１Ａ…量子鍵配送装置、３０…量子鍵流通レイヤ、３１…ノード、５０…暗号通信サーバ、５１…暗号通信部、１０１…ユーザ管理部、１０２…暗号鍵需給管理部、１０３…暗号鍵融通制御部、１１０…ＡＩ、１１１…暗号鍵消費予測モデル、１１２…暗号鍵不足予知モデル、１１３…暗号鍵補填ルート選定モデル、１５１…ユーザ管理ＤＢ、１５２…暗号鍵蓄積量管理ＤＢ、１５３…暗号鍵消費実績管理ＤＢ、１５４…暗号鍵消費予測管理ＤＢ、２０１…暗号鍵生成部、２０２…暗号鍵供給部、２０３…暗号鍵振替制御部、２５１…暗号鍵蓄積部。

Claims (9)

1. 他の量子鍵配送装置との間で暗号鍵情報を送受信し、前記暗号鍵情報に基づき、前記他の量子鍵配送装置と共有される暗号鍵を生成する複数の量子鍵配送装置と、
   前記暗号鍵を用いて暗号通信を行う複数の暗号通信装置に対する前記複数の量子鍵配送装置による前記暗号鍵の供給を管理する管理サーバと、
   を具備し、
   前記管理サーバは、
   前記複数の量子鍵配送装置において前記複数の暗号通信装置ごとに蓄積される前記暗号鍵の蓄積量を監視し、
   前記複数の暗号通信装置のそれぞれの前記暗号鍵の消費実績を記録し、
   前記暗号鍵の消費実績に基づき、前記複数の暗号通信装置のそれぞれの前記暗号鍵の消費量を予測し、
   前記暗号鍵の蓄積量と前記暗号鍵の消費量の予測結果とに基づき、前記複数の暗号通信装置の間の暗号通信において生じ得る前記暗号鍵の不足の予兆を検知する、
   量子鍵配送サービスプラットフォーム。
2. 前記管理サーバは、第１量子鍵配送装置と第２量子鍵配送装置との間で生成された前記暗号鍵が前記第１量子鍵配送装置から供給される第１暗号通信装置と、前記第２量子鍵配送装置から前記暗号鍵が供給される第２暗号通信装置とが第１暗号通信を行い、かつ、前記第１量子鍵配送装置から前記暗号鍵が供給される第３暗号通信装置と、前記第２量子鍵配送装置から前記暗号鍵が供給される第４暗号通信装置とが第２暗号通信を行うとき、前記第１暗号通信に使用される前記暗号鍵の不足の予兆が検知された場合、前記第２暗号通信向けに蓄積される前記暗号鍵を前記第１暗号通信向けに振り替えるように前記第１量子鍵配送装置および前記第２量子鍵配送装置に指示する請求項１に記載の量子鍵配送サービスプラットフォーム。
3. 前記管理サーバは、第３量子鍵配送装置と第４量子鍵配送装置との間で生成された前記暗号鍵が前記第３量子鍵配送装置から供給される第５暗号通信装置と、前記第４量子鍵配送装置から前記暗号鍵が供給される第６暗号通信装置とが暗号通信を行うとき、前記暗号通信の第１方向のデータ転送に使用される前記暗号鍵の不足の予兆が検知された場合、前記第１方向と逆の第２方向のデータ転送向けに蓄積される前記暗号鍵を前記第１方向のデータ転送向けに振り替えるように前記第３量子鍵配送装置および前記第４量子鍵配送装置に指示する請求項１に記載の量子鍵配送サービスプラットフォーム。
4. 前記管理サーバは、前記複数の暗号通信装置の間で行われている複数の暗号通信の中のいずれかの暗号通信について前記暗号鍵の不足の予兆が検知された場合、前記暗号鍵の蓄積量と前記暗号鍵の消費量の予測結果とに基づき、前記暗号鍵の不足の予兆が検知された暗号通信へ前記暗号鍵を振り替える他の暗号通信を前記複数の暗号通信の中から選択する請求項１に記載の量子鍵配送サービスプラットフォーム。
5. 前記管理サーバは、さらに、前記暗号鍵の消費実績に基づき、前記他の暗号通信を選択する請求項４に記載の量子鍵配送サービスプラットフォーム。
6. 前記管理サーバは、さらに、前記暗号鍵の消費実績に基づき、前記暗号鍵の不足の予兆を検知する請求項１に記載の量子鍵配送サービスプラットフォーム。
7. 前記管理サーバは、前記暗号鍵の蓄積量と前記暗号鍵の消費量の予測結果とに基づき、前記複数の量子鍵配送装置によって生成される前記暗号鍵の前記複数の暗号通信装置への割り当てを制御する請求項１～４のいずれか１項に記載の量子鍵配送サービスプラットフォーム。
8. 前記管理サーバは、さらに、前記暗号鍵の消費実績に基づき、前記暗号鍵の割り当てを制御する請求項７に記載の量子鍵配送サービスプラットフォーム。
9. 前記管理サーバは、前記複数の量子鍵配送装置によって生成される前記暗号鍵の一部を予備として確保し、前記複数の暗号通信装置の間で行われている複数の暗号通信の中のいずれかの暗号通信について前記暗号鍵の不足の予兆が検知された場合、前記暗号鍵の不足の予兆が検知された暗号通信へ前記予備として確保される暗号鍵を割り当てる請求項１に記載の量子鍵配送サービスプラットフォーム。

Images