説明

秘匿通信ネットワークにおける暗号鍵管理方法および装置

【課題】複数ノードの暗号鍵を容易にかつ安定的に管理できる暗号鍵管理方法および装置を提供する。
【解決手段】少なくとも1つの第1ノードと各第1ノードに接続された複数の第2ノードとを有し、各第1ノードとそれに接続された複数の第2ノードの各々との間で暗号鍵を個別に生成し消費するシステムにおける暗号鍵管理装置であって、各第1ノードおける各第2ノードに対応する暗号鍵の鍵蓄積量を監視するモニタと、前記鍵蓄積量に基づいて対応する第1ノードに対する鍵生成制御を実行する鍵管理制御部と、を有する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は秘匿通信ネットワークに係り、特にノード間で使用される暗号鍵を管理する方法および装置に関する。
【背景技術】
【0002】
インターネットは様々なデ−タが行き交う経済社会インフラとなっており、それゆえにネット上を流れるデ−タを盗聴リスクから事前に守る予防策を整えることが重要な課題となっている。予防策の一つとして、通信するデ−タを暗号化する秘匿通信システムが挙げられる。暗号化の方法としては、共通鍵暗号と公開鍵暗号の二種類がある。
【0003】
共通鍵暗号は、AES(Advanced Encryption Standard)に代表されるように暗号化と復号化に共通の暗号化鍵を用いる方式で高速処理が可能である。そのため本方式はデ−タ本体の暗号化に用いられている。
【0004】
一方、公開鍵暗号はRSA暗号方式に代表されるように一方向性関数を用いた方式で、公開鍵によって暗号化を行い、秘密鍵によって復号化を行う。高速処理には適していないため、共通鍵方式の暗号鍵配送などに用いられている。
【0005】
デ−タの暗号化によって秘匿性を確保する秘匿通信において、秘匿性を確保するために重要なことは、たとえ盗聴者によって暗号化デ−タを盗聴されたとしても、その暗号化デ−タを解読されないことである。そのため、暗号化に同じ暗号鍵を使い続けないことが必要である。それは、同じ暗号鍵を使い続けて暗号化していると、盗聴された多くのデ−タから暗号鍵を推測される可能性が高くなるからである。
【0006】
そこで送信側と受信側で共有している暗号化鍵を更新することが求められる。鍵更新時には更新する鍵を盗聴・解読されないことが必須であるので、(1)公開鍵暗号によって暗号化して送る方法、(2)予め鍵更新用に設定した共通鍵であるマスタ鍵を用いて暗号化して送る方法、の大きく二通りがある(たとえば特開2002−344438号公報(特許文献1)および特開2002−300158号公報(特許文献2)を参照)。これらの方法における安全性は、解読するための計算量が膨大であることに依っている。
【0007】
一方、量子暗号鍵配布技術(QKD)は、通常の光通信とは異なり、1ビットあたりの光子数を1個として伝送することにより送信−受信間で暗号鍵を生成・共有する技術である(非特許文献1および2参照)。この量子暗号鍵配布技術は、上述した計算量による安全性ではなく、量子力学によって安全性が保証されており、光子伝送部分での盗聴が不可能であることが証明されている。さらに、一対一の鍵生成・共有だけでなく、光スイッチング技術やパッシブ光分岐技術により一対多あるいは多対多ノード間での鍵生成および鍵共有を実現する提案もされている(非特許文献3参照)。
【0008】
このようなQKD技術では、光子1個に暗号鍵の基となる情報を載せて伝送するので、光子伝送を行なう限り暗号鍵を生成し続けることができる。たとえば、1秒あたり数10kビットの最終鍵を生成することが可能である。
【0009】
さらに、QKD技術によって生成した暗号鍵を、解読不可能なことが証明されているワンタイムパッド(OTP:one-time-pad)暗号に使用することで、絶対安全な暗号通信を提供することができる。ワンタイムパッド暗号により暗号化通信を行うと、暗号鍵はデータと同じ容量分だけ消費され、しかも一回限りで必ず使い捨てされる。例えば、1Mビットのファイルをワンタイム暗号化して送受信すると、1Mビットの暗号鍵が消費される。
【0010】
このように大量に暗号鍵を生成し消費する量子暗号システムでは、記憶媒体に格納されている暗号鍵の管理が必須といえる。特に、QKD技術において、非特許文献3で提案されているような光スイッチング技術やパッシブ光分岐技術によって一対多あるいは多対多の鍵生成・共有への拡張を実現するためには、多ノード間での暗号鍵の管理が重要となる。
【0011】
【特許文献1】特開2002−344438号公報
【特許文献2】特開2002−300158号公報
【非特許文献1】"QUANTUM CRYPTOGRAPHY: PUBLIC KEY DISTRIBUTION AND COIN TOSSING" C. H. Bennett and G. Brassard, IEEE Int. Conf. on Computers, Systems, and Signal Processing, Bangalore, India, December 10−12, 1984 pp.175−179
【非特許文献2】"Automated 'plug & play' quantum key distribution" G. Ribordy, J. Gauiter, N. Gisin, O. Guinnard and H. Zbinden, Electron. Lett., Vol. 34, No. 22 pp.2116−2117, (1998)
【非特許文献3】"Quantum cryptography on multiuser optical fibre Networks" P. D. Townsend, Nature vol. 385, 2 January 1997 pp. 47−49
【非特許文献4】"Temperature independent QKD system using alternative−shifted phase modulation method" A.Tanaka, A.Tomita, A.Tajima, T.Takeuch, S.Takahashi, and Y.Nambu, Proc. of ECOC 2004, Tu4.5.3.
【非特許文献5】"Single−photon Interference over 150km Transmission Using Silica−based Integrated−optic Interferometers for Quantum Cryptography" T.Kimura, Y.Nambu, T.Hatanaka, A.Tomita, H.Kosaka and K.Nakamura, Japanese Journal of Applied Physics Lett. Vol. 43, No. 9A/B, 2004, pp. L1217−L1219.
【発明の開示】
【発明が解決しようとする課題】
【0012】
しかしながら、これまでの技術では暗号鍵を生成することにのみ重点を置き、消費することも考慮した暗号鍵管理はほとんど行なわれていない。上述したように、各ノードにおける暗号鍵の蓄積量は、鍵生成・共有プロセスにより増加すると共に暗号通信を実行する毎に消費されて減少する。また、鍵生成・共有プロセスによる暗号鍵の生成速度は、ノード間の距離や通信品質などにも依存するために、一般にノード間で一定ではない。このために各ノードでの鍵蓄積量は時事刻々と増減することとなり、ノード数が増えるに従って暗号鍵の管理は益々複雑化する。
【0013】
また、1対多接続のようなセンタ・リモート構成のネットワークでは、センタノードと各リモートノード間で暗号鍵が生成・共有されるために、リモートノード間で暗号鍵が共有されていない。したがって、リモートノード同士で暗号化通信を行うことができない。同様に、多対多接続のネットワークにおいても、鍵生成・共有プロセスを実行するノード間では暗号化通信を行うことができるが、それ以外のノードとの間では暗号鍵が共有されていないので暗号化通信を行うことができない。
【0014】
本発明の目的は、複数ノードの暗号鍵を容易にかつ安定的に管理できる暗号鍵管理方法および装置を提供することにある。
【課題を解決するための手段】
【0015】
本発明による暗号鍵管理装置は、第1ノードと前記第1ノードに接続された複数の第2ノードとを含むネットワークを少なくとも1つ有するシステムにおける前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵を管理する装置であって、前記第1ノードにおける前記複数の第2ノードの各々との間の暗号鍵の鍵蓄積量をそれぞれ監視する監視手段と、前記鍵蓄積量に基づいて前記第1ノードにおける前記暗号鍵の生成管理を行う鍵管理手段と、を有することを特徴とする。
【発明の効果】
【0016】
本発明によれば、第1ノードおける各第2ノードに対応する暗号鍵の鍵蓄積量に基づいて第1ノードに対する鍵生成制御を行うことで、複数ノードの暗号鍵を容易にかつ安定的に管理できる。
【発明を実施するための最良の形態】
【0017】
1.第1実施例
1.1)ネットワーク構成
図1(A)および(B)は本発明の第1実施例による暗号鍵管理システムを適用した秘匿通信ネットワークの2つの例をそれぞれ示す概略的構成図である。ここでは説明を複雑化しないために、図1(A)に示す秘匿通信ネットワークは、複数のセンタノード10、複数のリモートノード20および鍵管理サーバ30を有し、各センタノード10は複数個のリモートノード20と接続し、各センタノード10が鍵管理サーバ30に接続されているものとする。さらに図中の二重線で例示されるように、センタノード10間、センタノード10とリモートノード20間および/またはリモートノード間のいくつかが閉じた通信経路により安全に接続され、全体が1つのネットワークを構成しているものとする。
【0018】
また、各センタノード10は、後述するように、配下のリモートノード20との間でそれぞれ暗号鍵を生成し、また暗号化通信を実行する毎に暗号鍵を消費する。鍵管理サーバ30は、生成あるいは消費される共有鍵の蓄積量をリモートノード毎に管理する。
【0019】
鍵管理サーバ30には鍵蓄積量モニタ31および鍵管理制御部32が設けられている。鍵蓄積量モニタ31は、各センタノードにおけるリモートノード毎の鍵蓄積量をモニタする。たとえば鍵蓄積量モニタ31が定期的に各センタノード10へ問い合わせて鍵蓄積量を取得することができる。またはセンタノードとリモートノードとの間で鍵が生成された時あるいは消費された時にセンタノード10から鍵管理サーバ30へ生成あるいは消費量が通知されてもよい。
【0020】
鍵管理制御部32は、後述するように、鍵蓄積量が低下した場合あるいは暗号化通信要求が生じた場合などに、対応するセンタノードに対して鍵生成プロセスを開始するように指示することができる。
【0021】
また、鍵蓄積量モニタ31によりモニタされた鍵蓄積量を鍵管理テーブルに格納し、鍵管理テーブルを参照しながら鍵管理制御部32が鍵生成制御を行ってもよい。
【0022】
なお、図1(B)に示すように、1つのセンタノード10に複数のリモートノードが収容されている1:Nネットワークであれば、上述した鍵管理サーバ30の機能をセンタノード10で実行することもできる。言い換えれば、図1(A)に示す鍵管理サーバ30は、物理的にセンタノード10と別個に設ける必要はなく、論理的に別にあればよい。
【0023】
1.2)暗号鍵管理
図2は本発明の第1実施例による暗号鍵管理方法を示すフローチャートである。鍵蓄積量モニタ31は、各センタノード10がリモートノード20と共有する鍵の蓄積量を監視する(ステップS1)。鍵管理制御部32は、各センタノードにおいて鍵蓄積量が最も少ないリモートノード20に対する鍵生成プロセスの開始を指示する(ステップS2)。続いて、鍵管理制御部32は、リモートノード間の通信要求が発生したか否かを判断し(ステップS3)、発生していない場合は(ステップS3のNO)、上記ステップS1およびS2を繰り返すことで、ネットワーク内の各リモートノードに対する鍵蓄積量を均一化あるいは所定量以上に維持することができる。
【0024】
ある2つのリモートノード間で暗号化通信要求が発生すると(ステップS3のYES)、鍵管理制御部32は、当該2つのリモートノードに対してそれぞれ確保されている鍵蓄積量の両方が当該暗号化通信に要求される暗号鍵の量より大きいか否かを判断する(ステップS4)。少なくとも一方の鍵蓄積量が不足している場合には(ステップS4のNO)、鍵管理制御部32は、不足している方のリモートノード20が収容されているセンタノード10に対して鍵生成プロセスの開始を指示する(ステップS5)。鍵生成プロセスは、当該2つのリモートノードに対する鍵蓄積量の両方が要求量より大きくなるまで続けられる。なお、暗号化通信に要求される暗号鍵の量は、ワンタイムパッド暗号化通信の場合、送信データと同じ容量となる。
【0025】
当該2つのリモートノードに対する鍵蓄積量の両方が当該暗号化通信に要求される暗号鍵の量より大きくなると(ステップS4のYES)、鍵管理制御部32は、暗号化通信に使用すべき暗号鍵を当該2つのリモートノード20に設定するように、対応するセンタノード10へ指示する(ステップS6)。
【0026】
センタノード10が両方のリモートノードを収容している場合には、それぞれのリモートノードとの間で暗号鍵を共有している。したがって、一方のリモートノードに対しては、その共有乱数から使用すべき暗号鍵を決定し、その暗号鍵を特定する情報を通知すればよい。他方のリモートノード20に対しては、当該使用すべき暗号鍵を当該他方のリモートノードとの間の共有鍵を用いてOTP暗号化して送信すればよい。図1(A)に示すように、両方のリモートノードが別々のセンタノードに従属している場合には、二重線で示す閉じた経路を通して、当該使用すべき暗号鍵をノード間で順次OTP暗号化して転送すればよい。
【0027】
1.3)効果
本発明の第1実施例によれば、鍵管理サーバ30は、センタノード10に接続された各リモートノード20に対する暗号鍵の鍵蓄積量に基づいて鍵生成制御を行うことで、複数ノードの暗号鍵を容易にかつ安定的に管理できる。たとえば、多対多量子鍵配付ネットワークにおいて、センタノード10に保持されている量子鍵の蓄積量を監視するだけで各リモートノードの暗号鍵管理を容易に行うことができる。たとえば、暗号鍵の消費を前提とした暗号鍵管理を行うことで、センタノード10およびリモートノード20間で安定したワンタイムパッド暗号化通信を実現することができる。
【0028】
2.第2実施例
2.1)構成
図3は本発明の第2実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。ここでは、N個(複数)のリモートノード20(以下、RN−1〜RN−Nと記す。)がそれぞれ光ファイバによってセンタノード10に接続され、各リモートノードとセンタノード10との間で暗号鍵の生成、共有およびそれを用いた暗号化通信が行われるものとする。
【0029】
リモートノードRN−1〜RN−Nの各々は同様の構成を有し、量子チャネルユニット201、古典チャネルユニット202、それらを制御する制御部203、量子鍵を格納するための量子鍵メモリ204、およびリモートノード間通信用の暗号鍵を格納するためリモート鍵メモリ205を有する。
【0030】
リモートノードRN−1〜RN−Nの量子鍵メモリ204には、各リモートノードとセンタノード10との間で生成・共有された乱数列K1、K2、・・・KNがそれぞれ格納されている。また、リモート鍵メモリ205には、要求に応じてリモートノード間通信用の暗号鍵Krが格納される。例えば、リモートノードRN−1とリモートノードRN−2との間で暗号化通信が要求されると、これらのリモートノードのリモート鍵メモリ205には暗号鍵Kr(1−2)がそれぞれ格納される。
【0031】
制御部203は、センタノード10との間で共有乱数の生成、共有乱数を用いた暗号化/復号化などを実行する。制御部203はプログラム制御プロセッサでもよく、図示しないメモリから読み出されたプログラムを実行することで、上記共有乱数生成機能および暗号化/復号化機能を実現することもできる。
【0032】
センタノード10は、量子チャネル用のスイッチ部101および量子チャネルユニット102と、古典チャネル用のスイッチ部103および古典チャネルユニット104と、それらを制御する制御部105と、リモートノードRN−1〜RN−Nのそれぞれとの間で共有された共有乱数K1、K2、・・・KNを格納する量子鍵メモリ106と、を有する。制御部105は、各リモートノードの間での共有乱数の生成、スイッチ部101および103の切り替え制御、共有乱数を用いた暗号化/復号化、鍵メモリ106に格納された各鍵量のモニタなどを実行する。
【0033】
各リモートノードの量子チャネルユニット201とセンタノード10の量子チャネルユニット102とは、量子チャネルおよびスイッチ部101を通して微弱光信号を送信し、両者で共有すべき乱数列を生成する。また、各リモートノードの古典チャネルユニット202とセンタノード10の古典チャネルユニット104とは、共有乱数を生成するためのデータをスイッチ部103および古典チャネルを通して相互に送受信し、共有された乱数列に基づいて暗号化したデータをスイッチ部103および古典チャネルを通して相互に送受信する。
【0034】
制御部105は、スイッチ部101を制御することで、リモートノードRN−1〜RN−Nから選択された1つのリモートノードの量子チャネルを量子チャネルユニット102に接続することができる。この量子チャネルの切替制御とは独立に、制御部105は、スイッチ部103を制御することで、リモートノードRN−1〜RN−Nから選択された1つのリモートノードの古典チャネルを古典チャネルユニット104に接続することができる。
【0035】
鍵管理サーバ30は、センタノード10の量子鍵メモリ106に格納されている共有乱数K1、K2、・・・KNのそれぞれの量を監視している。ここでは、センタノード10の制御部105が鍵メモリ106に格納された各鍵量をモニタし、そのモニタされた鍵量の情報が鍵管理サーバ30へ送信され、鍵管理サーバ30の鍵蓄積量モニタ31により監視されているものとする。
【0036】
各リモートノードは、センタノード10との間で生成した乱数列を量子鍵メモリ204にそれぞれ格納し、センタノード10は各リモートノードとの間で生成したすべての乱数列を量子鍵メモリ106に格納している。このように、センタノード10は、自身に従属するリモートノードのすべての量子鍵を把握しているので、鍵管理サーバ30はセンタノード10の量子鍵メモリ106を監視すればよい。鍵管理サーバ30は、センタノード10の量子鍵メモリ106にある量子鍵の残量が少なくなれば、センタノード10の制御部105に指示を送り、制御部105が量子チャネルのスイッチ部101および量子ユニット102を制御して、意図するリモートノードとの間で量子鍵を優先的に生成することができる。
【0037】
なお、量子チャネルと古典チャネルとはチャネルとして区別できればよく、量子チャネルは量子鍵の生成に利用されるチャネルであり、古典チャネルは通常の光パワー領域での通信チャネルである。古典チャネルは、共有乱数を生成するためのデータ送受信および暗号化されたデータの送受信のために利用される。量子チャネルは、パワーが1photon/bit以下の微弱な状態の光信号を送信器(Alice)から受信器(Bob)へ送信するが、通常の光通信で使用される光パワーの光信号を伝送することもできる。詳しくは後述する。
【0038】
なお、鍵管理サーバ30とセンタノードとの通信では、量子鍵自身を公開することなく、量子鍵のファイル番号や鍵蓄積量などの鍵管理情報のみをやりとりするので、鍵情報が公開されることはない。また、鍵管理情報を量子鍵によって暗号化することで秘密に通信することも可能である。さらに、鍵管理サーバはセンタノードの認証を行うことで成りすましを防止することができる。
【0039】
また、図3における量子チャネルと古典チャネルとは光ファイバに多重化されているが、多重化方式を特定するものではない。波長分割多重(WDM)方式であれば、各リモートノードに対応するスイッチ部101および103の前段に波長多重分離部を設けて、量子チャネルの波長信号をスイッチ部101へ、古典チャネルの波長信号をスイッチ部103へそれぞれ分離するように構成すればよい。
【0040】
2.2)量子鍵の生成・共有
センタノード10の制御部105および任意のリモートノード20の制御部203は、それぞれのノードの全体的な動作を制御するが、ここでは特に鍵生成機能について説明を行なう。制御部105および203は、所定の鍵生成シーケンスを実行することで暗号鍵用の乱数列をセンタノード10とリモートノード20との間で共有する。代表的なものとしては、BB84プロトコル(非特許文献1参照)、誤り検出・訂正および秘匿増強を行って暗号鍵を生成し共有することができる。一例としてリモートノードRN−1との間で共有される乱数列K1を生成する場合を説明する。
【0041】
まず、リモートノードRN−1の量子ユニット201とセンタノード10の量子ユニット102とは量子チャネルを介して単一光子伝送を行なう。センタノード10の量子ユニット102では光子検出を行い、この結果を制御部105へ出力する。各ノードの制御部105および203は、古典チャネルを介して、基底照合、誤り訂正および秘匿増強処理を光子検出の結果に基づいて行なう。センタノード10では、このようにして得られた共有乱数列K1をリモートノードRN−1に対応付けて量子鍵メモリ106に格納する。その他のリモートノードRN−2〜Nの共有乱数列K2〜KNについても同様のプロセスにより順次生成される。
【0042】
リモートノードRN−x(x=1〜N)の量子ユニット201とセンタノード10の量子ユニット102とは、Alice(微弱光信号の送信器)およびBob(微弱信号の受信器)の一方と他方にそれぞれ対応する。しかしながら、Bobは光子検出器を含むため、消費電力、監視制御の観点から、Bobがセンタノード10に配置される方が望ましい。
【0043】
次に、量子ユニット102および201にプラグアンドプレイ(Plug & Play)方式を用い、センタノード10がBobとなるQKDシステムを例示して詳細に説明する。
【0044】
図4はプラグアンドプレイ方式QKDシステムを示すブロック図である。リモートノードRN−xの量子ユニット201はAlice側の量子送信部であり、量子ユニット102はBob側の量子受信部である。なお、量子ユニット201および102は交互シフト位相変調型プラグアンドプレイ方式とする(非特許文献2および4を参照)。ここでは、スイッチ部101および103によって量子チャネルと古典チャネルとがリモートノードRN−xに接続されている場合が図示されている。
【0045】
この例において送信側量子ユニット201は、偏光ビ−ムスプリッタ(PBS)21および位相変調部22から構成されるPBSループを有し、PBS21が光ファイバに接続されている。PBSループはファラデーミラーと同様の機能を有し、入射光の偏光状態が90度回転して送出される(非特許文献4を参照)。
【0046】
位相変調器22はドライバ23によって駆動され、古典チャネルユニット202から供給されるクロック信号Syncに従って、通過する光パルス列に対して位相変調を行う。位相変調の深さは、2つの乱数RND1およびRND2の4通りの組み合わせにそれぞれ対応する4通りの深さ(0、π/2、π、3π/2)となり、光パルスが位相変調器22を通過するタイミングで位相変調が行われる。乱数RND1およびRND2は鍵生成処理部203.1から供給されるが、それらは後の基底照合処理のために保存されている。
【0047】
鍵生成処理部203.1は制御部203により実現される機能部であり、鍵生成プロセスを実行することで暗号鍵メモリ204に共有乱数列Kxを格納する。乱数列Kxは、所定の基準に従って乱数列の位置が特定されるように格納される。ここでは乱数列Kxが一定量ずつファイル化され、それぞれファイル番号#1、#2・・・により特定可能となっている。
【0048】
受信側量子ユニット102は、偏光ビ−ムスプリッタ(PBS)11、位相変調部12、ドライバ13、光カプラ14、光サーキュレータ15、パルス光源16、および、光子検出器17を有し、PBS11が光ファイバ伝送路60に接続されている。ドライバ13、パルス光源16および光子検出器17は、古典チャネルユニット104から供給されるクロック信号syncに同期して動作する。ドライバ13は、鍵生成処理部105.1から供給される乱数RND3に従って位相変調器12を駆動し、位相変調器12が通過する光パルスに対して位相変調を行う。
【0049】
パルス光源16はクロック信号syncに従って駆動され、パルス光源16により生成された光パルスPは、光サーキュレータ15により光カプラ14へ導かれ、光カプラ14により2分割される。分割された一方の光パルスP1は短いパス(Short Path)を通ってPBS11へ送られる。分割された他方の光パルスP2は長いパス(Long Path)に設けられた位相変調器12を通してPBS11へ送られる。これら光パルスP1およびP2はPBS11で合波され、時間的に分割されたダブルパルスとして光ファイバ伝送路60を通して送信側量子ユニット201へ送信される。
【0050】
送信側量子ユニット201において、光ファイバ伝送路60を通して到来した量子チャネルのダブルパルスP1およびP2は、PBS21でさらに分離され、時計回りのダブルパルスP1CWおよびP2CWと反時計回りのダブルパルスP1CCWおよびP2CCWの4つのパルス、すなわちカルテットパルスとなって位相変調器22をそれぞれ反対方向で通過し、それぞれ出射したポートとは反対のPBSポートへ入射する。
【0051】
位相変調器22は時計回りのダブルパルスの後方のパルスP2CWを前方のパルスP1CWに対して位相変調するとともに、反時計回りのダブルパルスと時計回りのダブルパルスとの間にπの位相差を与える。このように、必要に応じて位相変調されたカルテットパルスはPBS21で合波され再びダブルパルスに戻る。上述したように後方のパルスのみが2つの乱数RND1およびRND2の4通りの組み合わせに従って位相変調されたので、出射ダブルパルスをP1およびP2*aと記す。このときPBSループ入射時に対して出射時は偏波が90°回転しているので、結果的にファラデーミラーと同等の効果が得られる。
【0052】
受信側量子ユニット102のPBS11は、送信側量子ユニット201から受信した光パルスP1およびP2*aの偏光状態が90度回転していることから、これら受信パルスをそれぞれ送信時とは異なるパスへ導く。すなわち受信した光パルスP1は長いパスを通り、位相変調器12によって乱数RND3に従った位相変調が施され、位相変調された光パルスP1*bが光カプラ14に到達する。他方、光パルスP2*aは送信時とは異なる短いパスを通って同じく光カプラ14に到達する。
【0053】
こうして送信側量子ユニット201で位相変調された光パルスP2*aと受信側量子ユニット102で位相変調された光パルスP1*bとが光カプラ14で干渉し、その結果が光子検出器17のAPD0またはAPD1により乱数RND4として検出される。光子検出器17は、古典チャネルユニットから供給されるクロック信号syncに従ってガイガーモードで駆動され、高感度受信を行なう。このような送信側量子ユニット201と受信側量子ユニット102によって光子伝送が行われる。
【0054】
鍵生成処理部105.1は制御部105により実現される機能部であり、検出された乱数RND4に基づいて鍵生成プロセスを実行することにより暗号鍵メモリ106に共有乱数列Kxを格納する。乱数列Kxは、所定の基準に従って乱数列の位置が特定されるように格納される。ここでは乱数列Kxが一定量ずつファイル化され、それぞれファイル番号#1、#2・・・により特定可能となっている。こうしてリモートノードRN−1〜RN−Nの各々に対する乱数列K1〜KNをメモリ106に蓄積する。
【0055】
2.3)リモート鍵の共有
次に、ワンタイムパッド暗号通信を用いて、リモートノード間で暗号鍵を安全に共有する手法について説明する。N個のリモートノードRN−1〜RN−Nのうち、暗号化通信を行ないたい任意の2つのリモートノードは、鍵管理サーバ30に対してリモート鍵の要求を行なう。以下、リモートノードRN−1とリモートノードRN−2との間で暗号化通信が要求された場合を例にとり、そのリモート間の暗号化通信に使用されるリモート鍵Kr(1―2)の共有手順について説明する。なお、共有できたリモート鍵は各リモートノードのリモート鍵メモリ205に格納される。
【0056】
図5はリモートノード間でリモート鍵を共有する手順を説明するための模式図であり、図6はリモート鍵を共有する手順を示すシーケンス図である。ここでは、リモートノードRN−1がリモートノードRN−2との間の暗号化通信のためにセンタノード30を通して鍵管理サーバ30に対してリモート鍵の要求を行なったものとする(ステップS301)。このリモート鍵要求を受けると、鍵管理サーバ30はリモートノードRN−1およびRN−2の乱数列K1およびK2の鍵蓄積量(残量)をチェックする(ステップS302)。鍵管理サーバ30は、K1およびK2の残量の少なくとも一方がリモート鍵の要求量以下ならば(ステップS302のno)、不足しているリモートノードに対する鍵生成プロセスの開始をセンタノード10へ指示する(ステップS303)。これによってセンタノード10の制御部105は、量子チャネルのスイッチ部101を指定されたリモートノードに切り替え、当該リモートノードに対する鍵生成プロセスを実行する。K1およびK2の残量が双方とも要求量より不足している場合は、残量が少ない方のリモートノードから鍵生成を開始する。
【0057】
K1およびK2の残量がいずれもリモート鍵の要求量より大きいならば(ステップS302のyes)、鍵管理サーバ30はリモート鍵共有プロセスの開始をセンタノード10へ指示する。まず、センタノード10は、鍵管理サーバ30の指示により乱数列K1の中からリモート鍵Kr(1―2)として使用する部分を選択し、古典チャネルを介してリモートノードRN−1へKr(1−2)に相当する領域を示す情報を通知する(ステップS304)。リモートノードRN−1は、自身の鍵メモリ204に格納している量子鍵K1のうち、リモート鍵に相当する部分をリモート鍵メモリ205にKr(1−2)として付け替え処理を行なう(ステップS305)。上述したように、リモートノードにおいて、量子鍵メモリ204の乱数列を一定容量ごとにファイル化し、生成順の番号をファイル名に付けて管理している場合には、センタノード10がリモートノードRN−1にリモート鍵Kr(1−2)を通知する際は、ファイル番号のみを古典チャネルを用いて送信すればよい。
【0058】
次に、センタノード10は、リモートノードRN−2との間で共有している乱数K2から量子鍵K2OTPを取り出してリモート鍵Kr(1−2)をワンタイムパッド暗号化し、古典チャネルを通してリモートノードRN−2に送信する(ステップS306)。
【0059】
リモートノードRN−2は、自身の乱数列K2から同じ量子鍵K2OTPを取り出してワンタイムパッド暗号化されたリモート鍵Kr(1−2)を復号し、リモート鍵メモリ205に格納する(ステップS307)。ここで、ワンタイムパッド暗号化に用いる量子鍵K2OTPの領域(ファイル番号)も鍵管理サーバ30により指示することができる。
【0060】
ワンタイムパッド暗号化は、暗号鍵と平文の容量が等しく、暗号鍵に周期性がない限り、解読できないことが保証された暗号方式である。リモート鍵Kr(1―2)を量子鍵K2OTPでワンタイムパッド暗号化してOTP配送することにより、リモートノードRN−2は安全にリモート鍵Kr(1―2)を共有することが可能になる。
【0061】
2.4)暗号鍵の補充
このようにリモートノード間でワンタイムパッド暗号化通信が発生すると、センタノード10とリモートノードRN−2との間で共有されている乱数列K2が消費される。一般に、センタノード10と配下のリモートノードとの間で古典チャネルを介して暗号化通信が行なわれた場合も共有乱数列は消費される。他方、すでに述べたように、センタノード10において量子チャネルのスイッチ部101と古典チャネルのスイッチ部103とは独立して切り替えることができるので、各リモートノードとの間での共有乱数列の消費と並行して、量子チャネルを介した鍵生成を行うこともできる。このように各リモートノードにおける鍵蓄積量は常に増減を繰り返している。
【0062】
そこで、OTP配送が終了すると、鍵管理サーバ30は、センタノード10の量子鍵メモリ106に格納された共有乱数列K1−KNのうち残量が最も少ない乱数列を検出し、そのリモートノードとの間で鍵生成プロセスを開始するようにセンタノード10へ指示する(ステップS308)。すなわち、鍵管理サーバ30の指示に従って、センタノード10の制御部105は、量子チャネルのスイッチ部101を指定されたリモートノードに切り替えて鍵生成プロセスを開始する。この鍵生成を行なうリモートノードは、OTP配送を行なったリモートノード(ここではRN−2)とは限らない。OTP配送によって量子鍵が消費された場合だけでなく、暗号化通信を行なうことでも量子鍵が消費されるからである。したがって、ステップS308は、暗号化通信が行われた時には常に実行されることが望ましい。なお、リモート鍵要求が発生したときの鍵生成プロセスであるステップS303は、ステップS308よりも優先される。
【0063】
このようにして、ワンタイムパッド暗号化通信による量子鍵の消費が発生しても、鍵管理サーバ30はセンタノード10の鍵蓄積量を監視し適切に鍵生成開始の指示をすることにより、各リモートノード間の鍵蓄積量を平均化させることができる。これによってセンタノード10と各リモートノードとの間で安定したワンタイムパッド暗号化通信を提供することが可能となる。
【0064】
3.第3実施例
3.1)構成
図7は本発明の第3実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。本実施例では、多対多(N:M)接続ネットワークにおいて、異なるセンタノードに従属するリモートノード間でリモート鍵を共有する場合を説明する。
【0065】
まず、QKDネットワークA(QKD−NW−A)では、N個のリモートノードRN−A1〜RN−ANとセンタノード10aとがそれぞれ光ファイバによって接続され1:Nのネットワークを構成している。また、QKDネットワークB(QKD−NW−B)では、M個のリモートノードRN−B1〜RN−BMとセンタノード10bとがそれぞれ光ファイバによって接続され1:Mのネットワークを構成している。
【0066】
それぞれのQKDネットワークにおける各リモートノードとセンタノードとは、すでに述べたように暗号鍵の生成および共有プロセスおよび暗号鍵を用いた暗号化通信を行う。各リモートノードとセンタノードの構成は図3に示すものと基本的に同じであるから、図7では、簡単のために、センタノードの量子ユニットおよび古典ユニットとリモートノードの制御部とは省略されている。
【0067】
また、センタノード10aとセンタノード10bとは安全に量子鍵のやり取りを行うことができるものとする。例えば、センタノード10aとセンタノード10bとは同じデータセンタ内に設置された閉じたネットワーク内にあって、特に暗号化通信などを行なわなくても装置の設置・管理の面から安全が保証されている場合である。従って、図7に示すネットワークは、センタノード10aおよびセンタノード10bを1つのセンタノードとすれば、M個のリモートノードとN個のリモートノードとが光ファイバで接続されたM:Nネットワークである。
【0068】
鍵管理サーバ30はセンタノード10aおよびセンタノード10bの量子鍵メモリ106aおよび106bを監視している。各リモートノードは、生成した乱数列を量子鍵メモリ204aおよび204bにそれぞれ格納している。センタノード10aは、リモートノードRN−A1〜RN−ANと生成したすべての乱数列を量子鍵メモリ106aに格納している。また、センタノード10bは、リモートノードRN−B1〜RN−BMと生成したすべての乱数列を量子鍵メモリ106bに格納している。このように、センタノードは、自身に従属するリモートノードすべての量子鍵を把握しているので、鍵管理サーバ30はセンタノード10a、10bの量子鍵メモリ106a、106bを監視すればよい。鍵管理サーバ30は、上述したように、センタノード10a/10bの量子鍵の残量に応じて制御部105a/105bに指示を送り、量子チャネルのスイッチ部101a/101bを制御して、意図するリモートノードとの間の量子鍵を優先的に生成することが可能となる。量子鍵の生成・共有に関しては上記2.2)項で説明したとおりであるから、ここでは省略する。
【0069】
3.2)リモート鍵の共有
図8はリモートノード間でリモート鍵を共有する手順を説明するための模式図であり、図9はリモート鍵を共有する手順を示すシーケンス図である。ここでは、センタノード10aに従属するリモートノードRN−A1とセンタノード10bに従属するリモートノードRN−B1との間で安全にリモート鍵Kr(1a−1b)を共有する場合を一例として説明する。ただし、図6のフローチャートと同じステップには同じ参照符号を付して説明は簡略化する。
【0070】
まず、リモートノードRN−A1がリモートノードRN−B1との間の暗号化通信のためにセンタノード10を通して鍵管理サーバ30に対してリモート鍵の要求を行なったものとする(ステップS301)。このリモート鍵要求を受けると、鍵管理サーバ30はリモートノードRN−A1およびRN−B1の乱数列K1AおよびK1Bの鍵蓄積量(残量)をチェックする(ステップS302)。鍵管理サーバ30は、K1AおよびK1Bの残量の少なくとも一方がリモート鍵の要求量以下ならば(ステップS302のno)、不足しているリモートノードに対する鍵生成プロセスの開始をセンタノード10a/10bへ指示する(ステップS303)。この指示を受けたセンタノードの制御部105は、量子チャネルのスイッチ部101を指定されたリモートノードに切り替え、当該リモートノードに対する鍵生成プロセスを実行する。K1AおよびK1Bの残量が双方とも要求量より不足している場合は、残量が少ない方のリモートノードから鍵生成を開始する。
【0071】
K1AおよびK1Bの残量がいずれもリモート鍵の要求量より大きいならば(ステップS302のyes)、鍵管理サーバ30はリモート鍵共有プロセスの開始をセンタノード10aおよび10bへ指示する。センタノード10aは、鍵管理サーバ30の指示により乱数列K1Aの中からリモート鍵Kr(1a―1b)として使用する部分を選択し、古典チャネルを介してリモートノードRN−A1へKr(1a−1b)に相当する領域を示す情報を通知する(ステップS304)。リモートノードRN−A1は、自身の鍵メモリ204に格納している量子鍵K1Aのうち、リモート鍵に相当する部分をリモート鍵メモリ205にKr(1a−1b)として付け替え処理を行なう(ステップS305)。上述したように、リモートノードにおいて、量子鍵メモリ204の乱数列を一定容量ごとにファイル化し、生成順の番号をファイル名に付けて管理している場合には、センタノード10aがリモートノードRN−A1にリモート鍵Kr(1a−1b)を通知する際は、ファイル番号のみを古典チャネルを用いて送信すればよい。
【0072】
続いて、センタノード10aはリモート鍵Kr(1a−1b)をセンタノード10bに受け渡す(ステップ304a)。ここでは、センタノード10aとセンタノード10bとは閉じた経路を用いるので特に暗号化などは行なわない。
【0073】
次に、センタノード10bは、リモートノードRN−B1との間で共有している乱数K1Bから量子鍵K1BOTPを取り出してリモート鍵Kr(1a−1b)をワンタイムパッド暗号化し、古典チャネルを通してリモートノードRN−B1に送信する(ステップS306)。
【0074】
リモートノードRN−B1は、自身の乱数列K1Bから同じ量子鍵K1BOTPを取り出してワンタイムパッド暗号化されたリモート鍵Kr(1a−1b)を復号し、リモート鍵メモリ205に格納する(ステップS307)。ここで、ワンタイムパッド暗号化に用いる量子鍵K1BOTPの領域(ファイル番号)も鍵管理サーバ30により指示することができる。
【0075】
ワンタイムパッド暗号化は、暗号鍵と平文の容量が等しく、暗号鍵に周期性がない限り、解読できないことが保証された暗号方式である。リモート鍵Kr(1a−1b)を量子鍵K1BOTPでワンタイムパッド暗号化してOTP配送することにより、リモートノードRN−B1は安全にリモート鍵Kr(1a−1b)を共有することが可能になる。
【0076】
3.3)暗号鍵の補充
このようにリモートノード間でワンタイムパッド暗号化通信が発生すると、センタノード10とリモートノードRN−B1との間で共有されている乱数列K1Bが消費される。一般に、センタノード10と配下のリモートノードとの間で古典チャネルを介して暗号化通信が行なわれた場合も共有乱数列は消費される。他方、すでに述べたように、センタノードにおいて量子チャネルのスイッチ部101と古典チャネルのスイッチ部103とは独立して切り替えることができるので、各リモートノードとの間での共有乱数列の消費と並行して、量子チャネルを介した鍵生成を行うこともできる。このように各リモートノードにおける鍵蓄積量は常に増減を繰り返している。
【0077】
そこで、OTP配送が終了すると、鍵管理サーバ30は、センタノード10aおよび10bの量子鍵メモリ106に格納された共有乱数列のうち残量が最も少ない乱数列を検出し、そのリモートノードとの間で鍵生成プロセスを開始するようにセンタノードへ指示する(ステップS308)。すなわち、鍵管理サーバ30の指示に従って、センタノード10a/10bの制御部105は、量子チャネルのスイッチ部101を指定されたリモートノードに切り替えて鍵生成プロセスを開始する。この鍵生成を行なうリモートノードは、OTP配送を行なったリモートノード(ここではRN−B1)とは限らない。OTP配送によって量子鍵が消費された場合だけでなく、暗号化通信を行なうことでも量子鍵が消費されるからである。したがって、ステップS308は、暗号化通信が行われた時には常に実行されることが望ましい。なお、リモート鍵要求が発生したときの鍵生成プロセスであるステップS303は、ステップS308よりも優先される。
【0078】
このようにして、ワンタイムパッド暗号化通信による量子鍵の消費が発生しても、鍵管理サーバ30はセンタノード10の鍵蓄積量を監視し適切に鍵生成開始の指示をすることにより、各リモートノード間の鍵蓄積量を平均化させることができる。これによってセンタノード10と各リモートノードとの間で安定したワンタイムパッド暗号化通信を提供することが可能となる。
【0079】
4.第4実施例
4.1)構成
図10は本発明の第4実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。本実施例では、センタノードを中継ノードとして用いることで、異なるセンタノードに従属するリモートノード間でリモート鍵を共有する例である。
【0080】
まず、QKDネットワークA(QKD−NW−A)では、N個のリモートノードRN−A1〜RN−ANとセンタノード10aとがそれぞれ光ファイバによって接続され1:Nのネットワークを構成している。また、QKDネットワークC(QKD−NW−C)では、センタノード10cとリモートノードRN−Cとが光ファイバによって接続され、Point−to−Pointのネットワークを構成している。したがって、図10では、センタノード10cにスイッチ部101および103が図示されていない。
【0081】
それぞれのQKDネットワークにおける各リモートノードとセンタノードとは、すでに述べたように暗号鍵の生成および共有プロセスおよび暗号鍵を用いた暗号化通信を行う。各リモートノードとセンタノードの構成は図3に示すものと基本的に同じであるから、図10では、簡単のために、センタノードの量子ユニットおよび古典ユニットとリモートノードの制御部とは省略されている。
【0082】
ここでは、センタノード10cとQKD−NW−AのリモートノードRN−A2とが安全に量子鍵のやり取りを行うことができるものとする。例えば、センタノード10cとリモートノードRN−A2とは同じデータセンタ内に設置された閉じたネットワーク内にあって、特に暗号化通信などを行なわなくても装置の設置・管理の面から安全が保証されている場合である。本実施例によれば、センタノード10cとリモートノードRN−A2とを1つの中継ノードとして用いることにより、センタノード10aは、自局ネットワークのリモートノードと別ネットワークQKD−NW−CのリモートノードRN−Cとの間でのリモート鍵の共有を可能にする。
【0083】
鍵管理サーバ30はセンタノード10aおよびセンタノード10cの量子鍵メモリ106aおよび106cを監視している。各リモートノードは、生成した乱数列を量子鍵メモリ204aおよび204cにそれぞれ格納している。センタノード10aは、リモートノードRN−A1〜RN−ANと生成したすべての乱数列を量子鍵メモリ106aに格納している。また、センタノード10cは、リモートノードRN−Cと生成した乱数列を量子鍵メモリ106cに格納している。このように、センタノードは、自身に従属するリモートノードすべての量子鍵を把握しているので、鍵管理サーバ30はセンタノード10a、10cの量子鍵メモリ106a、106cを監視すればよい。鍵管理サーバ30は、上述したように、センタノード10a/10cの量子鍵の残量に応じてセンタノード10a/10cに指示を送り、意図するリモートノードとの間の量子鍵を優先的に生成することが可能となる。量子鍵の生成・共有に関しては上記2.2)項で説明したとおりであるから、ここでは省略する。
【0084】
なお、鍵管理サーバ30とセンタノード10cとの通信では、量子鍵自身を公開することなく、量子鍵のファイル番号や鍵蓄積量などの鍵管理情報のみをやりとりするので、鍵情報が公開されることはない。また、鍵管理情報を暗号化することで鍵管理情報も秘密に通信することが可能である。さらに、鍵管理サーバ30はセンタノード10cの認証を行なって成りすましを防止することもできる。
【0085】
4.2)リモート鍵の共有
図11はリモートノード間でリモート鍵を共有する手順を説明するための模式図であり、図12はリモート鍵を共有する手順を示すシーケンス図である。ここでは、センタノード10aに従属するリモートノードRN−A1とセンタノード10cに従属するリモートノードRN−Cとの間で安全にリモート鍵Kr(1a−c)を共有する場合を一例として説明する。ただし、図6のフローチャートと同じステップには同じ参照符号を付して説明は簡略化する。
【0086】
まず、リモートノードRN−A1がリモートノードRN−Cとの間の暗号化通信のためにセンタノード10aを通して鍵管理サーバ30に対してリモート鍵の要求を行なったものとする(ステップS301)。このリモート鍵要求を受けると、鍵管理サーバ30は、リモートノードRN−A1からリモートノードRN−Cに至る経路にある全てのリモートノードの鍵蓄積量(残量)をチェックする(ステップS302)。この実施例では、リモートノードRN−A1、RN−A2およびRN−Cの乱数列K1a、K2aおよびKcの鍵蓄積量(残量)がチェックされる。
【0087】
鍵管理サーバ30は、K1a、K2aおよびKcの残量の少なくとも1つがリモート鍵の要求量以下ならば(ステップS302のno)、不足しているリモートノードに対する鍵生成プロセスの開始をセンタノード10a/10cへ指示する(ステップS303)。この指示を受けたセンタノードの制御部105は当該リモートノードに対する鍵生成プロセスを実行する。K1a、K2aおよびKcの残量が双方とも要求量より不足している場合は、残量が少ない方のリモートノードから鍵生成を開始する。
【0088】
K1a、K2aおよびKcの残量がいずれもリモート鍵の要求量より大きいならば(ステップS302のyes)、鍵管理サーバ30はリモート鍵共有プロセスの開始をセンタノード10aおよび10cへ指示する。まず、センタノード10aは、鍵管理サーバ30の指示により乱数列K1aの中からリモート鍵Kr(1a−c)として使用する部分を選択し、古典チャネルを介してリモートノードRN−A1へKr(1a−c)に相当する領域を示す情報を通知する(ステップS304)。リモートノードRN−A1は、自身の鍵メモリ204に格納している量子鍵K1aのうち、リモート鍵に相当する部分をリモート鍵メモリ205にKr(1a−c)として付け替え処理を行なう(ステップS305)。上述したように、リモートノードにおいて、量子鍵メモリ204の乱数列を一定容量ごとにファイル化し、生成順の番号をファイル名に付けて管理している場合には、センタノード10aがリモートノードRN−A1にリモート鍵Kr(1a−c)を通知する際は、ファイル番号のみを古典チャネルを用いて送信すればよい。
【0089】
次に、センタノード10aは、リモートノードRN−A2との間で共有している乱数K2aから量子鍵K2AOTPを取り出してリモート鍵Kr(1a−c)をワンタイムパッド暗号化し、古典チャネルを通してリモートノードRN−A2に送信する(ステップS401)。
【0090】
OTP暗号化されたリモート鍵Kr(1a−c)を受け取ると、リモートノードRN−A2は、自身の乱数列K2aから同じ量子鍵K2AOTPを取り出してワンタイムパッド暗号化されたリモート鍵Kr(1a−c)を復号する(ステップS402)。ここで、ワンタイムパッド暗号化に用いる量子鍵K2AOTPの領域(ファイル番号)も鍵管理サーバ30により指示することができる。ワンタイムパッド暗号化は、暗号鍵と平文の容量が等しく、暗号鍵に周期性がない限り、解読できないことが保証された暗号方式である。リモート鍵Kr(1a−c)を量子鍵K2AOTPでワンタイムパッド暗号化してOTP配送することにより、リモートノードRN−A2は安全にリモート鍵Kr(1a−c)を共有することが可能になる。
【0091】
続いて、リモートノードRN−A2はリモート鍵Kr(1a−c)をセンタノード10cに受け渡す(ステップ403)。ここでは、センタノード10cとリモートノードRN−A2とは閉じた経路を用いるので特に暗号化などは行なわない。
【0092】
次に、センタノード10cは、リモートノードRN−Cとの間で共有している乱数Kcから量子鍵KcOTPを取り出してリモート鍵Kr(1a−c)をワンタイムパッド暗号化し、古典チャネルを通してリモートノードRN−Cに送信する(ステップS404)。
【0093】
リモートノードRN−Cは、自身の乱数列Kcから同じ量子鍵KcOTPを取り出してワンタイムパッド暗号化されたリモート鍵Kr(1a−c)を復号し、リモート鍵メモリ205に格納する(ステップS405)。ここで、ワンタイムパッド暗号化に用いる量子鍵KcOTPの領域(ファイル番号)も鍵管理サーバ30により指示することができる。
【0094】
ワンタイムパッド暗号化は、暗号鍵と平文の容量が等しく、暗号鍵に周期性がない限り、解読できないことが保証された暗号方式である。リモート鍵Kr(1a−c)を量子鍵KcOTPでワンタイムパッド暗号化してOTP配送することにより、リモートノードRN−Cは安全にリモート鍵Kr(1a−c)を共有することが可能になる。
【0095】
4.3)暗号鍵の補充
このようにリモートノード間でワンタイムパッド暗号化通信が発生すると、センタノード10aとリモートノードRN−A2との間で共有されている乱数列K2aおよびセンタノード10cとリモートノードRN−Cとの間で共有されている乱数列kcが消費される。一般に、センタノードと配下のリモートノードとの間で古典チャネルを介して暗号化通信が行なわれた場合も共有乱数列は消費される。他方、すでに述べたように、センタノード10aにおいて量子チャネルのスイッチ部101と古典チャネルのスイッチ部103とは独立して切り替えることができるので、各リモートノードとの間での共有乱数列の消費と並行して、量子チャネルを介した鍵生成を行うこともできる。このように各リモートノードにおける鍵蓄積量は常に増減を繰り返している。
【0096】
そこで、OTP配送が終了すると、鍵管理サーバ30は、センタノード10aおよび10cの量子鍵メモリ106に格納された共有乱数列のうち残量が最も少ない乱数列を検出し、そのリモートノードとの間で鍵生成プロセスを開始するようにセンタノードへ指示する(ステップS406)。すなわち、鍵管理サーバ30の指示に従って、センタノード10a/10cの制御部105は指定されたリモートノードに対する鍵生成プロセスを開始する。この鍵生成を行なうリモートノードは、OTP配送を行なったリモートノード(ここではRN−A2、RN−C)とは限らない。OTP配送によって量子鍵が消費された場合だけでなく、暗号化通信を行なうことでも量子鍵が消費されるからである。したがって、ステップS406は、暗号化通信が行われた時には常に実行されることが望ましい。なお、リモート鍵要求が発生したときの鍵生成プロセスであるステップS303は、ステップS406よりも優先される。
【0097】
このようにして、ワンタイムパッド暗号化通信による量子鍵の消費が発生しても、鍵管理サーバ30はセンタノードの鍵蓄積量を監視し適切に鍵生成開始の指示をすることにより、各リモートノード間の鍵蓄積量を平均化させることができる。これによってセンタノードと各リモートノードとの間で安定したワンタイムパッド暗号化通信を提供することが可能となる。
【0098】
5.ネットワーク例
図13は秘匿通信ネットワークの他の例を示すブロック図である。ここでは、センタノード10aはN個のリモートノードと1:Nネットワークを構成し、センタノード10bはM個のリモートノードと1:Mネットワークを構成している。また、センタノード10cはリモートノードRN−CとPoint−to−Pointネットワークを構成している。センタノードは、それぞれのノードに従属するリモートノードと量子暗号鍵を生成・共有することができるものとする。また、センタノード10aと10bとは閉じた経路で接続され、センタノード10cとリモートノードRN−A2とも閉じた経路で接続され、それぞれ暗号化通信は必要ないものとする。鍵管理サーバ30はセンタノード10a、センタノード10bおよびセンタノード10cに格納されている量子鍵の残量を監視している。
【0099】
このようなネットワーク構成では、リモートノードRN−A1とRN−A2との間のリモート暗号化通信501は上述した第2実施例により可能となり、リモートノードRN−A1とRN−B1との間のリモート暗号化通信502は上述した第3実施例により可能となり、リモートノードRN−A1とRN−Cとの間のリモート暗号化通信503は上述した第4実施例により可能となる。
【0100】
なお、本発明は、上述した第1〜第4実施例のそれぞれに限定されるものではなく、これらの実施例の組み合わせにより任意のネットワーク構成における暗号化管理に適用可能である。
【0101】
また、量子暗号鍵配付(QKD)技術は、Plug & Play方式、単一方向型、差動位相シフト型でも構わない。量子暗号鍵配布プロトコルは、BB84プロトコルに限らず、B92でもE91でもよく、本発明をこれらに限定されるものではない。
【0102】
6.ネットワークの二重化
さらに、本発明は冗長系ネットワークに適用することで秘匿通信ネットワークの信頼性を向上させることができる。たとえば、上述した第2実施例によれば、リモートノード間のリモート鍵共有だけでなく、プロテクション機能としても利用することができる。図7に示された中央の破線より折り返してQKD−NW−AとQKD−NW−Bとをちょうど重ねるようにし、N=Mとする。センタノードと各リモートノードとは、QKD−NW−AとQKD−NW−Bとで同じようにリモート鍵を共有することにより、ネットワークを二重化構造にすることができる。以下、本発明を提供した冗長系ネットワークの一例を簡単に説明する。
【0103】
図14は本発明の第2実施例を適用した冗長系ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。ここでは、N個(複数)のリモートノードRN−1〜RN−Nがそれぞれ2本の光ファイバ(現用系および予備系)によってセンタノード10に接続されている。通常は現用系ファイバを通して各リモートノードとセンタノード10との間で暗号鍵の生成、共有およびそれを用いた暗号化通信が行われるが、現用系に障害あるいは基準を超える品質劣化が発生すると、当該リモートノードとセンタノード10とは現用系から予備系に切り替えて、同様の暗号鍵生成および暗号化通信をやり直したり続行したりすることができる。現用系における障害あるいは品質劣化の検出については周知技術を用いればよい。
【0104】
リモートノードRN−1〜RN−Nの各々は、現用系ファイバと予備系ファイバのいずれかを量子チャネルユニット201および古典チャネルユニット202に接続するためのスイッチ206を有する。制御部203は、上述した鍵生成およびリモート鍵付け替え制御に加えて、スイッチ206の現用系/予備系切り替え制御も行う。量子鍵メモリ204およびリモート鍵メモリ205についてはすでに説明したとおりである。
【0105】
センタノード10はすでに説明したとおりであるが、制御部105は上述した制御に加えて、スイッチ部101および103を制御することで、あるリモートノードに関する現用系/予備系の切り替え制御も行う。現用系あるいは予備系を用いた鍵生成プロセスや暗号化通信は、第2実施例で説明したとおりであるからここでは省略する。
【産業上の利用可能性】
【0106】
本発明は、量子暗号鍵配付QKDに代表される共通暗号鍵配布技術を用いた1対多および多対多の秘匿情報通信に利用可能である。
【図面の簡単な説明】
【0107】
【図1】(A)および(B)は本発明の第1実施例による暗号鍵管理システムを適用した秘匿通信ネットワークの2つの例をそれぞれ示す概略的構成図である。
【図2】本発明の第1実施例による暗号鍵管理方法を示すフローチャートである。
【図3】本発明の第2実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。
【図4】プラグアンドプレイ方式QKDシステムを示すブロック図である。
【図5】リモートノード間でリモート鍵を共有する手順を説明するための模式図である。
【図6】リモート鍵を共有する手順を示すシーケンス図である。
【図7】本発明の第3実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。
【図8】リモートノード間でリモート鍵を共有する手順を説明するための模式図である。
【図9】リモート鍵を共有する手順を示すシーケンス図である。
【図10】本発明の第4実施例による秘匿通信ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。
【図11】リモートノード間でリモート鍵を共有する手順を説明するための模式図である。
【図12】リモート鍵を共有する手順を示すシーケンス図である。
【図13】秘匿通信ネットワークの他の例を示すブロック図である。
【図14】本発明の第2実施例を適用した冗長系ネットワークにおけるセンタノードおよびリモートノードの概略的構成を示すブロック図である。
【符号の説明】
【0108】
10 センタノード
20 リモートノード
30 鍵管理サーバ
31 鍵蓄積量モニタ
32 鍵管理制御部
101 スイッチ部
102 量子チャネルユニット
103 スイッチ部
104 古典チャネルユニット
105 制御部
106 量子鍵メモリ
201 量子チャネルユニット
202 古典チャネルユニット
203 制御部
204 量子鍵メモリ
205 リモート鍵メモリ

【特許請求の範囲】
【請求項1】
第1ノードと前記第1ノードに接続された複数の第2ノードとを含むネットワークを少なくとも1つ有するシステムにおける前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵を管理する装置であって、
前記第1ノードにおける前記複数の第2ノードの各々との間の暗号鍵の鍵蓄積量をそれぞれ監視する監視手段と、
前記鍵蓄積量に基づいて前記第1ノードにおける前記暗号鍵の生成管理を行う鍵管理手段と、
を有することを特徴とする暗号鍵管理装置。
【請求項2】
前記第1ノードは、
当該第1ノードに従属する前記複数の第2ノードの各々の間で生成した暗号鍵を各第2ノードに対応づけて格納する記憶手段と、
前記鍵管理手段の指示に従って暗号鍵を生成する第2ノードを切り換える制御手段と、
を有することを特徴とする請求項1に記載の暗号鍵管理装置。
【請求項3】
前記鍵管理手段は、前記鍵蓄積量が最も少ない第2ノードとの間で鍵生成を開始するように前記第1ノードに対して指示することを特徴とする請求項1または2に記載の暗号鍵管理装置。
【請求項4】
前記鍵管理手段は、異なる第2ノード間での暗号鍵共有要求があった場合、当該暗号鍵の要求量と前記異なる第2ノード間の経路内における鍵蓄積量とを比較し、その比較結果に従って前記第1ノードに鍵生成を指示することを特徴とする請求項1−3のいずれかに記載の暗号鍵管理装置。
【請求項5】
前記鍵管理手段は、前記経路内における鍵蓄積量が不足している部分に接続された第1ノードに対して鍵生成開始を指示することを特徴とする請求項4に記載の暗号鍵管理装置。
【請求項6】
前記鍵管理手段は、異なる第2ノード間での暗号鍵共有要求があった場合、前記異なる第2ノードの一方の間で生成した暗号鍵のなかから共有すべき暗号鍵を決定して前記第1ノードに対して指定することを特徴とする請求項1−5のいずれかに記載の暗号鍵管理装置。
【請求項7】
前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵は、パルスあたりの光子数が1個以下の光パルス信号を送信することで生成され共有される乱数列であることを特徴とする請求項1−6のいずれかに記載の暗号鍵管理装置。
【請求項8】
前記光パルス信号は前記第2ノードから前記第1ノードへ送信され、前記第1ノードにおいて検出された光パルス信号に基づいて前記暗号鍵が生成されることを特徴とする請求項7に記載の暗号鍵管理装置。
【請求項9】
前記システムは、前記第1ノードをセンタノードとし前記第2ノードをリモートノードとする1対多接続のネットワークを1つ以上含む秘匿通信ネットワークを構成することを特徴とする請求項1−8のいずれかに記載の暗号鍵管理装置。
【請求項10】
第1ノードと前記第1ノードに接続された複数の第2ノードとを含むネットワークを少なくとも1つ有するシステムにおける前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵を管理する方法であって、
前記第1ノードの記憶手段に格納された前記複数の第2ノードの各々との間の暗号鍵の鍵蓄積量を監視し、
前記鍵蓄積量に基づいて前記第1ノードにおける前記暗号鍵の生成を管理する、
ことを特徴とする暗号鍵管理方法。
【請求項11】
前記鍵蓄積量が最も少ない第2ノードとの間で鍵生成を開始するように前記第1ノードに対して指示することを特徴とする請求項10に記載の暗号鍵管理方法。
【請求項12】
異なる第2ノード間での暗号鍵共有要求があった場合、当該暗号鍵の要求量と前記異なる第2ノード間の経路内における鍵蓄積量とを比較し、
前記比較結果に従って前記第1ノードに鍵生成を指示する、
ことを特徴とする請求項10または11に記載の暗号鍵管理方法。
【請求項13】
前記経路内における鍵蓄積量が不足している部分に接続された第1ノードに対して鍵生成開始を指示することを特徴とする請求項12に記載の暗号鍵管理方法。
【請求項14】
異なる第2ノード間での暗号鍵共有要求があった場合、前記異なる第2ノードの一方の間で生成した暗号鍵のなかから共有すべき暗号鍵を決定して前記第1ノードに対して指定することを特徴とする請求項10−13のいずれかに記載の暗号鍵管理方法。
【請求項15】
前記第1ノードは、前記異なる第2ノードの前記一方の第2ノードに対しては前記共有すべき暗号鍵を識別する情報を通知し、他方の第2ノードに対しては当該共有すべき暗号鍵を当該他方の第2ノードとの間で生成した暗号鍵を用いて暗号化して送信する、ことを特徴とする請求項14に記載の暗号鍵管理方法。
【請求項16】
第1ノードと前記第1ノードに接続された複数の第2ノードとを含むサブネットワークを少なくとも1つ有し、前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵を管理する鍵管理装置を更に有する秘匿通信ネットワークにおいて、
前記鍵管理装置は、
前記第1ノードにおける前記複数の第2ノードの各々との間の暗号鍵の鍵蓄積量をそれぞれ監視する監視手段と、
前記鍵蓄積量に基づいて前記第1ノードにおける前記暗号鍵の生成管理を行う鍵管理手段と、
を有することを特徴とする秘匿通信ネットワーク。
【請求項17】
前記第1ノードは、
当該第1ノードに従属する前記複数の第2ノードの各々の間で生成した暗号鍵を各第2ノードに対応づけて格納する記憶手段と、
前記鍵管理手段の指示に従って暗号鍵を生成する第2ノードを切り換える制御手段と、
を有することを特徴とする請求項16に記載の秘匿通信ネットワーク。
【請求項18】
前記鍵管理手段は、異なる第2ノード間での暗号鍵共有要求があった場合、当該暗号鍵の要求量と前記異なる第2ノード間の経路内における鍵蓄積量とを比較し、その比較結果に従って前記第1ノードに鍵生成を指示することを特徴とする請求項16または17に記載の秘匿通信ネットワーク。
【請求項19】
前記鍵管理手段は、前記経路内における鍵蓄積量が不足している部分に接続された第1ノードに対して鍵生成開始を指示することを特徴とする請求項18に記載の秘匿通信ネットワーク。
【請求項20】
前記鍵管理手段は、異なる第2ノード間での暗号鍵共有要求があった場合、前記異なる第2ノードの一方の間で生成した暗号鍵のなかから共有すべき暗号鍵を決定して前記第1ノードに対して指定することを特徴とする請求項16−19のいずれかに記載の秘匿通信ネットワーク。
【請求項21】
前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵は、パルスあたりの光子数が1個以下の光パルス信号を送信することで生成され共有される乱数列であることを特徴とする請求項16−20のいずれかに記載の秘匿通信ネットワーク。
【請求項22】
前記光パルス信号は前記第2ノードから前記第1ノードへ送信され、前記第1ノードにおいて検出された光パルス信号に基づいて前記暗号鍵が生成されることを特徴とする請求項21に記載の秘匿通信ネットワーク。
【請求項23】
前記サブネットワークを複数個有し、それぞれのサブネットワークの第1ノードが互いに閉じた経路で接続され当該複数のサブネットワークにおける1つの第1ノードとして機能することを特徴とする請求項16−22のいずれかに記載の秘匿通信ネットワーク。
【請求項24】
前記サブネットワークを複数個有し、1つのサブネットワークの第1ノードが別のサブネットワークの1つの第2ノードと互いに閉じた経路で接続されていることを特徴とする請求項16−22のいずれかに記載の秘匿通信ネットワーク。
【請求項25】
前記第1ノードは、前記複数の第2ノードの1つと閉じた経路で接続された中継ノードを介して、別の第2ノードに接続されていることを特徴とする請求項16−22のいずれかに記載の秘匿通信ネットワーク。
【請求項26】
コンピュータを、
第1ノードと前記第1ノードに接続された複数の第2ノードとを含むネットワークを少なくとも1つ有するシステムにおける前記第1ノードと前記複数の第2ノードの各々との間の暗号鍵を管理する装置であって、
前記第1ノードにおける前記複数の第2ノードの各々との間の暗号鍵の鍵蓄積量をそれぞれ監視する監視手段と、
前記鍵蓄積量に基づいて前記第1ノードにおける前記暗号鍵の生成管理を行う鍵管理手段と、
を有する暗号鍵管理装置として機能させることを特徴とするプログラム。
【請求項27】
複数のリモートノードと接続されたセンタノードであって、
前記複数のリモートノードの各々の間で生成した暗号鍵をそれぞれ対応づけて格納する記憶手段と、
前記複数のリモートノードから選択された1つのリモートノードとの間で暗号鍵を生成する制御手段と、
を有することを特徴とするセンタノード。
【請求項28】
前記制御手段は、鍵管理サーバからの鍵生成指示に従って選択されたリモートノードとの間で暗号鍵を生成することを特徴とする請求項27に記載のセンタノード。
【請求項29】
前記複数のリモートノードの各々との間で生成された暗号鍵の鍵蓄積量をそれぞれ監視する監視手段と、
前記鍵蓄積量に基づいて前記制御手段の暗号鍵生成管理を行う鍵管理手段と、
を更に有することを特徴とする請求項27に記載のセンタノード。
【請求項30】
請求項1−9のいずれかに記載の暗号鍵管理装置を有する鍵管理サーバ。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate


【公開番号】特開2008−306633(P2008−306633A)
【公開日】平成20年12月18日(2008.12.18)
【国際特許分類】
【出願番号】特願2007−153807(P2007−153807)
【出願日】平成19年6月11日(2007.6.11)
【国等の委託研究の成果に係る記載事項】(出願人による申告)国等の委託研究の成果に係る特許出願(平成18年度、独立行政法人情報通信研究機構、高度通信・放送研究開発における委託研究)は産業再生法第30条の適用を受ける特許出願
【出願人】(000004237)日本電気株式会社 (19,353)
【Fターム(参考)】