JP2016181814A - 量子鍵配送装置、量子鍵配送システムおよび量子鍵配送方法 - Google Patents

Abstract

【課題】暗号鍵の共有動作の処理遅延を低減することができる量子鍵配送装置、量子鍵配送システムおよび量子鍵配送方法を提供する。【解決手段】実施形態の量子鍵配送装置は、量子鍵共有手段と、鍵蒸留手段と、第１管理手段と、第２管理手段と、鍵管理手段と、を備える。記憶手段は、内部または外部である。量子鍵共有手段は、量子鍵配送によって光子ビット列を取得する。鍵蒸留手段は、鍵蒸留処理によってリンク鍵を生成する。第１管理手段は、リンク鍵を、リンク送信鍵として内部または外部の記憶手段に記憶させる。第２管理手段は、暗号データ通信のための暗号鍵であるアプリ鍵から所定の役割を決定した第１アプリ鍵を記憶手段に記憶させ、第１アプリ鍵に対応する役割を決定した第２アプリ鍵をリンク送信鍵で暗号化して、他の量子鍵配送装置に送信する。鍵管理手段は、アプリケーションが暗号化または復号化で利用するために第１アプリ鍵を管理する。【選択図】図７

Description

本発明の実施形態は、量子鍵配送装置、量子鍵配送システムおよび量子鍵配送方法に関する。

量子鍵配送システムは、送信機、受信機と、それを接続する光ファイバリンクとを含んで構成される。送信機は、光ファイバの通信路である光ファイバリンク（量子通信路）を介して、単一光子の列を受信機に送信する。その後、送信機と受信機が相互に制御情報を交換することによって、送信機と受信機との間で暗号鍵を共有する。この技術は、一般に量子鍵配送（ＱＫＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）と呼ばれる技術により実現される。

また、量子鍵配送では、暗号鍵を共有するために利用される光子は、観測されることで物理的な状態が変化するという量子力学の基本原理の一つである不確定性原理を有する。この原理により、送信機が送信した暗号鍵の情報を含む光子を量子通信路上で盗聴者が観測すると、光子の物理的な状態が変化し、光子を受け取った受信機は、盗聴者に光子を観測されたことを検出することができる。この結果、送信機で得られた光子列、および受信機で検出された光子列を基にして、送信機と受信機との相互間で制御情報を交換することにより、最終的に安全な暗号鍵が得られる。

２つのノード（例えば、上述の送信機および受信機）に接続された各アプリケーションは、２つのノードで共有された上述の暗号鍵を使用して暗号化および復号化を行い、ワンタイムパッドと呼ばれる暗号通信方式を利用して暗号データ通信を行う。複数のノードに接続された各アプリケーションは、何らかの安全な通信リンクで接続され、または、同じ筺体もしくは同じ敷地に設置される等により、その間の通信に関しては安全を仮定できるものと考える。一方のノードのアプリケーションと、他方のノードのアプリケーションとが、同じタイミングで暗号データ通信を行うためには、共有した暗号鍵を、送信時に暗号化を行う送信鍵と、受信時に復号化を行う受信鍵とに仕分けておく必要がある。ワンタイムパッドは、データ１バイトを暗号鍵１バイトで暗号化して送信し、受信時には同じ１バイトの暗号鍵を利用して復号化する方式であり、一度利用した暗号鍵は破棄し、常に新しい鍵を使い続けることで成立する。このワンタイムパッド方式の暗号鍵による暗号通信では、いかなる知識を有する盗聴者によっても解読できないことが情報理論により保証されている。

このように、複数のノードが、暗号鍵を共有する動作における最も一般的な方式として、まず、リンク鍵方式がある。リンク鍵方式では、上述のように、量子通信路を介して、共有した単一光子の列である光子列に基づくビット情報から、鍵蒸留処理によって暗号鍵が生成される。この鍵蒸留処理は、シフティング処理、誤り訂正処理および秘匿性増強処理によって構成される。この鍵蒸留処理によって生成された暗号鍵をリンク鍵と称する。リンク鍵方式では、このリンク鍵を使用して、暗号化および復号化を行い、暗号データ通信を行う。ここでは、暗号アルゴリズムとして、上述のようにワンタイムパッドを想定する。

このリンク鍵については、あるノードが送信時に暗号化を行う送信鍵と、受信時に復号化を行う受信鍵とを事前に仕分けておく必要がある。このリンク鍵の送信鍵および受信鍵への仕分け動作として、Ｑ３Ｐ（Ｑｕａｎｔｕｍ Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコル処理が実行される。Ｑ３Ｐでは、まず、鍵蒸留処理により生成され、ピックアップストアと呼ばれる複数の記憶部に記憶されたリンク鍵を、送信機および受信機で、同一のリンク鍵を選択するように同期制御を行い、同じタイミングでコモンストアと呼ばれる単一の記憶部に移動させるＳＴＯＲＥサブプロトコルによる処理を実行する。さらに、Ｑ３Ｐでは、コモンストアに記憶されたリンク鍵を、送信鍵として記憶するための送信バッファ、および、受信鍵として記憶するための受信バッファに仕分けるＬＯＡＤサブプロトコルによる処理を実行する。

次に、暗号鍵を共有する動作の方式として、リンク鍵方式とは異なるアプリ鍵方式と称する方式について説明する。アプリ鍵方式では、Ｑ３Ｐを用いて暗号鍵を送信鍵および受信鍵に仕分ける処理までは、リンク鍵方式と同様である。一方のノードは、既に共有し終わっているリンク鍵とは独立に、乱数生成器等を用いて乱数を生成しこれを暗号鍵（アプリ鍵と称する）とする。一方のノードは、生成したアプリ鍵を、送信鍵であるリンク鍵で暗号化し、これを、他方のノードへ暗号送信する。これを受信した他方のノードは、対応する受信鍵であるリンク鍵で復号化し、元のアプリ鍵を記憶する。アプリ鍵を送信する側のノードは、アプリ鍵（暗号鍵）だけでなく、鍵のＩＤの他、鍵の役割情報（送信鍵か受信鍵かを区別する情報）をも付与した形で送信することで、ノード間でアプリ鍵を送信鍵として使うか受信鍵として使うかを同期することができる。なお、アプリ鍵は、量子鍵配送により生成および共有したリンク鍵によってワンタイムパッドで暗号化されてノード間で共有されることから、リンク鍵と同様の安全性を持つ。なお、乱数を生成してこれを暗号鍵（アプリ鍵）として、リンク鍵で暗号化して送信することで共有するのは、一方のノードに限らない。双方のノードでアプリ鍵を生成し、これをリンク鍵である送信鍵で暗号化して送信することで、互いにアプリ鍵を共有することができる。アプリ鍵方式は、暗号鍵の中継及びネットワーク化が可能であるという大きなメリットを持つ。一般に量子鍵配送による鍵共有は、単一光子を送信して検出することを前提とするため、光ファイバ上の光の減衰によって暗号鍵共有ができなくなるため、リンク鍵共有を行うことができるノード間の距離には物理的な制約が生じ、１００［ｋｍ］程度以下に限定される。一方、アプリ鍵方式を採用すれば、中間にノードを配置し、そのノードの安全性を仮定することで、距離の制約を打破することができる。

しかし、リンク鍵方式およびアプリ鍵方式における上述のＱ３Ｐによるリンク鍵の仕分け動作は、各ノードで、データの同期を行うための制御データの交換、およびプロトコル処理が必要となるため、処理遅延が大きいという問題点がある。

Kollmitzer C., Pivk M. (Eds.), Applied Quantum Cryptography,Lect. Notes Phys. 797 (Springer, Berlin Heidelberg 2010), DOI:10.1007/978-3-642-04831-9

本発明は、上記に鑑みてなされたものであって、暗号鍵の共有動作の処理遅延を低減することができる量子鍵配送装置、量子鍵配送システムおよび量子鍵配送方法を提供することを目的とする。

実施形態の量子鍵配送装置は、他の量子鍵配送装置と、量子通信路および古典通信路で接続され、暗号鍵を共有する量子鍵配送装置であって、量子鍵共有手段と、鍵蒸留手段と、第１管理手段と、第２管理手段と、鍵管理手段と、を備える。量子鍵共有手段は、量子通信路を介した量子鍵配送によって、他の量子鍵配送装置と光子列を共有して、光子列に対応する光子ビット列を取得する。鍵蒸留手段は、光子ビット列から、鍵蒸留処理によって暗号鍵であるリンク鍵を生成する。第１管理手段は、リンク鍵を、データの暗号化のためのリンク送信鍵として内部または外部の記憶手段に記憶させる。第２管理手段は、暗号データ通信のための暗号鍵であるアプリ鍵から所定の役割を決定した第１アプリ鍵を記憶手段に記憶させ、アプリ鍵から第１アプリ鍵に対応する役割を決定した第２アプリ鍵を、リンク送信鍵で暗号化して、古典通信路を介して他の量子鍵配送装置に送信する。鍵管理手段は、アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために記憶手段に記憶された第１アプリ鍵を管理する。

図１は、第１の実施形態の量子鍵配送システムの全体構成の一例を示す図である。 図２は、一般的なリンク鍵共有動作を示すシーケンス図である。 図３は、Ｑ３Ｐのプロトコル処理の動作を説明する図である。 図４は、一般的なアプリ鍵共有動作を示すシーケンス図である。 図５は、生成した暗号鍵を中継する場合のアプリ鍵共有動作の一例を示すシーケンス図である。 図６は、ノードのハードウェア構成の一例を示す図である。 図７は、ノードの機能ブロックの構成の一例を示す図である。 図８は、第１の実施形態のアプリ鍵共有動作を示すシーケンス図である。 図９は、第１の実施形態の変形例のアプリ鍵共有動作を示すシーケンス図である。 図１０は、第２の実施形態のアプリ鍵共有動作を示すシーケンス図である。 図１１は、第２の実施形態の変形例のアプリ鍵共有動作を示すシーケンス図である。 図１２は、ノードのリンク鍵の生成動作の一例を示すシーケンス図である。 図１３は、鍵蒸留処理での制御データの一例を示す図である。 図１４は、暗号化されたアプリ鍵の送信と応答とを示す図である。 図１５は、第３の実施形態のアプリ鍵共有動作を示すシーケンス図である。 図１６は、第４の実施形態の制御データの変化の一例を示す図である。

以下に、図面を参照しながら、本発明の実施形態に係る量子鍵配送装置、量子鍵配送システムおよび量子鍵配送方法を詳細に説明する。ただし、図面は模式的なものであるため、具体的な構成は以下の説明を参酌して判断すべきものである。

（第１の実施形態）
図１は、第１の実施形態の量子鍵配送システムの全体構成の一例を示す図である。図１を参照しながら、量子鍵配送システム１００の構成について説明する。

図１に示すように、量子鍵配送システム１００は、送信機であるノード１と、受信機であるノード２と、光ファイバリンク４と、アプリＡと、アプリＢと、を含んで構成されている。

ノード１は、レーザにより発生した、暗号鍵を生成する基となる単一光子から構成される光子列を、光ファイバリンク４を介して、ノード２へ送信する送信機（量子鍵配送装置、ＱＫＤ装置）である。ノード１は、送信した光子列を基に、後述する鍵蒸留処理（シフティング処理、誤り訂正処理および秘匿性増強処理）等を実行して、暗号鍵（リンク鍵）を生成する。また、鍵蒸留処理の際、ノード１は、ノード２との間で制御データ（単一光子ではなく一般のデジタルデータであり、鍵蒸留処理データと称する）の交換を行う。なお、鍵蒸留処理データは、ノード１とノード２との間の光ファイバリンク４を介して転送されてもよく、これ以外の通信経路（例えば、一般のインターネット回線等）を用いて転送されてもよい。鍵蒸留処理データの交換に用いられるデジタルデータの通信経路を、古典通信路と呼ぶことがある。

ノード２は、暗号鍵を生成する基となる単一光子から構成される光子列を、光ファイバリンク４を介して、ノード１から受信する受信機（量子鍵配送装置、ＱＫＤ装置）である。ノード２は、受信した光子列を基に、後述する鍵蒸留処理（シフティング処理、誤り訂正処理および秘匿性増強処理）等を実行して、ノード１が生成した暗号鍵と同一の暗号鍵（リンク鍵）を生成する。鍵蒸留処理の際、ノード２は、ノード１との間で制御データ（（鍵蒸留処理データ）の交換を行う。

光ファイバリンク４は、ノード１が出力した単一光子の送信路となる量子通信路として機能する光ファイバケーブルである。なお、図示していないが、送信機１と受信機２とは、光ファイバリンク４の量子通信路以外に、鍵蒸留処理データを交換するための、通常の「０」および「１」のデジタルデータを通信する通信ケーブル（古典通信路）で接続されている。

このようなノード１とノード２とを含む量子鍵配送システム１００によって、ノード１が送信した光子列を光ファイバリンク４上で盗聴者が観測すると、光子の物理的状態が変化し、光子を受信したノード２は、盗聴者に光子を観測されたことを認識することができる。

アプリＡは、ノード１に安全な通信リンクで接続された装置の機能、またはノード１において実行されるアプリケーションである。アプリＡは、ノード１によりノード２と共有したアプリ鍵の提供を受け、このアプリ鍵によりデータを暗号化または復号化し、ノード２のアプリＢとの間で暗号データ通信を行う。

アプリＢは、ノード２に安全な通信リンクで接続された装置の機能、またはノード２において実行されるアプリケーションである。アプリＢは、ノード２によりノード１と共有したアプリ鍵の提供を受け、このアプリ鍵によりデータを暗号化または復号化し、ノード１のアプリＡとの間で暗号データ通信を行う。

この暗号データ通信におけるアプリ鍵によるデータの暗号化および復号化も、ワンタイムパッド方式により実行される。ここで、アプリＡとアプリＢとが同じタイミングでデータの暗号化および送信を行う場合（双方向通信を行う場合）を考える。アプリＡおよびアプリＢが、同じアプリ鍵をそれぞれ暗号化のために利用してしまうと、受信側のアプリが同じアプリ鍵を用いて復号化することができなくなるため、暗号データ通信が成立しなくなる。このような事態を避けるため、生成および共有されたアプリ鍵を、送信時に暗号化に使う送信鍵と、受信時の復号化に使う受信鍵と、に分類する必要がある。ノード１とノード２との間で共有されたアプリ鍵を、送信鍵と受信鍵とに分類する動作の詳細については後述する。

図２は、一般的なリンク鍵共有動作を示すシーケンス図である。図３は、Ｑ３Ｐのプロトコル処理の動作を説明する図である。まず、図２を参照しながら、ノード間でリンク鍵を共有するための従来のリンク鍵共有動作について説明する。ここで、リンク鍵共有動作とは、ノード間で量子鍵配送により暗号鍵であるリンク鍵を共有する動作を示すものとする。

＜ステップＳ１０１＞
ノード１は、例えば、乱数によって発生させたビット情報について、ランダムに選択した基底により生成した基底情報に基づいて生成した単一光子から構成される光子列を、量子通信路を介して、ノード２に送信する。

＜ステップＳ１０２＞
ノード２は、量子通信路を介して、ノード１から光子列を受信し、受信した光子列を、ランダムに選択した基底により生成した基底情報に基づいて読み取ることによってビット情報を得る。

＜ステップＳ１０３＞
ノード１は、ノード２との間で制御データ（鍵蒸留処理データ）の通信を行うことによって、ビット情報から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行し、ノード２の間でリンク鍵を共有する。なお、鍵蒸留処理データは、ノード１とノード２との間を、古典通信路を介して送受信される。

＜ステップＳ１０４＞
ノード２は、ノード１との間で制御データ（鍵蒸留処理データ）の通信を行うことによって、ビット情報から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行し、ノード１の間でリンク鍵を共有する。なお、鍵蒸留処理データは、ノード１とノード２との間を、古典通信路を介して送受信される。

＜ステップＳ１０５＞
ノード１は、ノード２との間で制御データ（Ｑ３Ｐデータ）の通信を行うことによって、生成したリンク鍵を送信鍵と受信鍵とに仕分けるためのＱ３Ｐによるプロトコル処理を実行する。なお、Ｑ３Ｐデータは、ノード１とノード２との間を、古典通信路を介して送受信される。図２に示すように、Ｑ３Ｐによるプロトコル処理の結果、ノード１で仕分けされた送信鍵をリンク送信鍵１５０とし、受信鍵をリンク受信鍵１５１とする。

＜ステップＳ１０６＞
ノード２は、ノード１との間で制御データ（Ｑ３Ｐデータ）の通信を行うことによって、生成したリンク鍵を送信鍵と受信鍵とに仕分けるためのＱ３Ｐによるプロトコル処理を実行する。なお、Ｑ３Ｐデータは、ノード１とノード２との間を、古典通信路を介して送受信される。図２に示すように、Ｑ３Ｐによるプロトコル処理の結果、ノード２で仕分けされた送信鍵をリンク送信鍵１６０とし、受信鍵をリンク受信鍵１６１とする。なお、Ｑ３Ｐによるプロトコル処理の詳細は、図３で後述する。

次に、図３を参照しながら、従来のリンク鍵共有動作におけるＱ３Ｐによるプロトコル処理の詳細を説明する。なお、Ｑ３Ｐは、複数の光ファイバリンク（量子通信路）を有するシステムについても想定している。

Ｑ３Ｐによるプロトコル処理では、まず、ノード１、２は、それぞれ共有したリンク鍵を、ピックアップストアと称する複数の記憶部に記憶させる。複数のピックアップストアは、それぞれ各光ファイバリンクに対応しており、各光ファイバリンクを介して共有されたリンク鍵をそれぞれ記憶する。図３に示すように、例えば、ノード１は、ピックアップストア１７０ａ、１７０ｂそれぞれにリンク鍵を記憶させ、ノード２は、ピックアップストア１８０ａ、１８０ｂそれぞれにリンク鍵を記憶させる。

次に、ノード１とノード２との間で、同一のリンク鍵を選択するように同期制御を行い、同じタイミングで同じリンク鍵をコモンストアと称する単一の記憶部に移動させるためのＳＴＯＲＥサブプロトコルと称するプロトコル処理が実行される。ここで、図３に示すように、ノード１が有するコモンストアを、コモンストア１７１とし、ノード２が有するコモンストアを、コモンストア１８１とする。以下、Ｑ３ＰにおけるＳＴＯＲＥサブプロトコルについて説明する。

Ｑ３Ｐでは、ノードの一方がマスタ、他方がスレーブとなるが、ここでは、ノード１がマスタで、ノード２がスレーブであるとする。ＳＴＯＲＥサブプロトコルでは、マスタは、スレーブに対して、少なくともピックアップストアの番号と、リンク鍵のＩＤ情報とを含むコモンストア移動要求を送信する。スレーブは、マスタからコモンストア移動要求を受信すると、同様に、少なくともピックアップストアの番号と、リンク鍵のＩＤ情報とを含む移動了解応答を、マスタに送信する。マスタは、スレーブから移動了解応答を受信すると、これに応答するための応答情報（例えば「Ａｃｋｎｏｗｌｅｄｇｅ」等のメッセージ）を、スレーブに送信する。以上のやりとりが行われると、ノード１、２は、ピックアップストアの番号で指定されたピックアップストアから、ＩＤ情報で指定されたリンク鍵をコモンストアに移動させる。このリンク鍵の移動に際し、ピックアップストアに記憶される際にリンク鍵に付与されていたリンク鍵のＩＤ情報等のメタデータおよび鍵長等のデータは全て削除され、結果として、コモンストアに移動されるのは単一の暗号鍵データストリームとなる。以上の手順によって、ＳＴＯＲＥサブプロトコルによる処理が行われる。

次に、Ｑ３Ｐによるプロトコル処理では、ノード１、２は、コモンストアに格納された暗号鍵データストリーム（リンク鍵）を、送信鍵として記憶させる送信バッファと、受信鍵として記憶させる受信バッファとに振り分ける。ここで、図３に示すように、ノード１が有する送信バッファおよび受信バッファを、それぞれ送信バッファ１７２ａおよび受信バッファ１７２ｂとし、ノード２が有する送信バッファおよび受信バッファを、それぞれ送信バッファ１８２ａおよび受信バッファ１８２ｂとする。一方のノードにおいて、送信バッファに送信鍵として記憶されたリンク鍵は、他方のノードにおいて、受信バッファに受信鍵として記憶されるべきである。また、一方のノードにおいて、受信バッファに受信鍵として記憶されたリンク鍵は、他方のノードにおいて、送信バッファに送信鍵として記憶されるべきである。ノードは、データを暗号化して送信する場合、送信バッファから送信鍵（リンク鍵）を取り出してこれを利用する。そして、利用された送信鍵は、送信バッファから削除される。また、ノードは、暗号化されたデータを受信して復号化する場合、受信バッファから受信鍵（リンク鍵）を取り出してこれを利用する。そして、利用された受信鍵は、受信バッファから削除される。

ノードは、それぞれ自身の受信バッファ（受信バッファ１７２ｂ、１８２ｂ）を監視しており、受信バッファに記憶されている受信鍵が減少してくると、コモンストアに記憶されているリンク鍵を、自身の受信鍵として受信バッファに補充する。また、ノードは、相手のノードに対してコモンストアに記憶されている同じリンク鍵を、送信鍵として送信バッファに補充するように制御する。この際に利用されるプロトコルがＬＯＡＤサブプロトコルである。以下、Ｑ３ＰにおけるＬＯＡＤサブプロトコルについて説明する。

ＬＯＡＤサブプロトコルでは、マスタは、受信鍵を補充しようとする場合、スレーブに対して、リンク鍵のＩＤに相当する情報、そのサイズ、および認証情報を含むバッファ移動要求を送信する。なお、鍵のＩＤの情報は、コモンストアにデータを格納した時点で削除されているため、ＬＯＡＤサブプロトコルを実行するマスタは、ＬＯＡＤサブプロトコルを実行するタイミングで新しくリンク鍵のＩＤに相当する情報を生成している。スレーブは、マスタからバッファ移動要求を受信すると、バッファ移動要求に含まれるサイズの鍵を、指定された鍵のＩＤを持つリンク鍵として、コモンストアから送信鍵として送信バッファに移動させ、認証情報を含む移動了解応答を送信する。マスタは、スレーブから移動了解応答を受信すると、ＩＤに相当する情報により指定したリンク鍵を、コモンストアから受信鍵として受信バッファに移動させ、移動了解応答に応答するための応答情報を、スレーブに送信する。一方、スレーブが、受信鍵を補充しようとする場合、マスタに対して、少なくともリンク鍵のサイズ、および認証情報を含むバッファ移動要求を送信する。以降の動作は、上述と同様である。以上の手順によって、ＬＯＡＤサブプロトコルによる処理が行われる。

以上の動作によって、リンク鍵を送信鍵と受信鍵とに仕分けるためのＱ３Ｐによるプロトコル処理が実行される。Ｑ３Ｐによるプロトコル処理は、既にノード間で共有済みの暗号鍵（リンク鍵）を、ノード間で仕分けるためのプロトコルであり、量子鍵配送における鍵管理に特有の方式である。また、ノード１とノード２との間で、暗号鍵を１つ仕分けるたびに同期制御用の通信が必要となり、処理遅延が大きい点等の特徴がある。

図４は、一般的なアプリ鍵共有動作を示すシーケンス図である。図４を参照しながら、ノード間でアプリ鍵を共有するための従来のアプリ鍵共有動作について説明する。ここで、アプリ鍵共有動作とは、上述のリンク鍵共有動作によってリンク鍵を共有し、さらに、このリンク鍵を用いて、別途生成する暗号鍵（アプリ鍵）を暗号化および復号化により、暗号データ通信し、ノード間でアプリ鍵を共有する動作を示すものとする。アプリ鍵共有動作においては、まず、ノード間でリンク鍵を共有する必要があり、リンク鍵を共有する動作は、上述の図２、３で示したリンク鍵共有動作と同様である。

＜ステップＳ１０１〜Ｓ１０６＞
図２に示したステップＳ１０１〜Ｓ１０６と同様である。

＜ステップＳ１０７＞
ノード１は、リンク鍵共有動作により共有が終了しているリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。ノード１は、例えば、生成したアプリ鍵を、アプリＡが送信するデータを暗号化するための送信鍵（図４に示すアプリ送信鍵１５２）として、記憶部に記憶させる。なお、ノード１は、生成したアプリ鍵を送信鍵として記憶部に記憶させることに限定されるものではなく、アプリＡが受信するデータを復号化するための受信鍵として記憶させるものとしてもよい。この場合、後述するステップＳ１０９で、ノード２が復号化したアプリ鍵を送信鍵か受信鍵かいずれの役割として使用するかについて同期をとる必要がある。この場合の同期をとるための情報が、以下のステップＳ１０８におけるノード１が生成したアプリ鍵に付与するアプリ鍵の役割を決定する情報である。

＜ステップＳ１０８＞
ノード１は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵１５０を用いて、生成したアプリ鍵をワンタイムパッドにより暗号化して、古典通信路を介して、ノード２に送信する。また、ノード１は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（例えば、送信鍵か受信鍵かを区別する情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。

＜ステップＳ１０９＞
ノード２は、ノード１から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵１６１を用いて、アプリ鍵をワンタイムパッドにより復号化し、アプリＢが受信するデータを復号化するための受信鍵（図４に示すアプリ受信鍵１６３）として、記憶部に記憶させる。

＜ステップＳ１１０＞
また、生成したアプリ鍵をリンク鍵により暗号化して送信するのは、一方のノード（上述ではノード１）に限らない。図４に示すように、ノード２は、リンク鍵共有動作により共有が終了しているリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。ノード２は、例えば、生成したアプリ鍵を、アプリＢが送信するデータを暗号化するための送信鍵（図４に示すアプリ送信鍵１６２）として、記憶部に記憶させる。なお、ノード２は、生成したアプリ鍵を送信鍵として記憶部に記憶させることに限定されるものではなく、アプリＢが受信するデータを復号化するための受信鍵として記憶させるものとしてもよい。この場合、後述するステップＳ１１２で、ノード１が復号化したアプリ鍵を送信鍵か受信鍵かいずれの役割として使用するかについて同期をとる必要がある。この場合の同期をとるための情報が、以下のステップＳ１１１におけるノード２が生成したアプリ鍵に付与するアプリ鍵の役割を決定する情報である。

＜ステップＳ１１１＞
ノード２は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵１６０を用いて、生成したアプリ鍵をワンタイムパッドにより暗号化して、古典通信路を介して、ノード１に送信する。また、ノード２は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（例えば、送信鍵か受信鍵かを区別する情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。

＜ステップＳ１１２＞
ノード１は、ノード２から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵１５１を用いて、アプリ鍵をワンタイムパッドにより復号化し、アプリＡが受信するデータを復号化するための受信鍵（図４に示すアプリ受信鍵１５３）として、記憶部に記憶させる。

以上のステップによって、ノード１とノード２は、アプリ鍵を共有し、利用することができる。なお、アプリ鍵は、リンク鍵共有動作により共有したリンク鍵によってワンタイムパッドで暗号化されてノード間で共有されることから、リンク鍵と同様の安全性を有する。なお、アプリ鍵を導入するメリットは、以下に述べるように、アプリ鍵を中継するノードを設けることによって、リンク鍵だけを用いる場合では実現できなかった、距離の制約の打破を実現する点にある。

図５は、生成した暗号鍵を中継する場合のアプリ鍵共有動作の一例を示すシーケンス図である。図５を参照しながら、ノードがアプリ鍵を中継する従来の動作ついて説明する。

図５に示すように、ノード１が光ファイバリンク４によってノード２に接続され、ノード２がさらに光ファイバリンク４ａによってノード３に接続された量子鍵配送システムを考える。そして、アプリＡは、上述のように、ノード１からアプリ鍵の提供を受けるアプリケーションであり、アプリＣは、ノード３からアプリ鍵の提供を受けるアプリケーションであるものとする。

＜ステップＳ１２１、１２２＞
ノード１およびノード２は、図２で示したリンク鍵共有動作によってリンク鍵を共有する。ノード２およびノード３は、図２で示したリンク鍵共有動作によってリンク鍵を共有する。

＜ステップＳ１２３＞
ノード１は、リンク鍵共有動作により共有が終了しているリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。

＜ステップＳ１２４、１２５＞
ノード１は、ノード２との間でリンク鍵共有動作により共有した送信鍵（リンク送信鍵）を用いて、生成したアプリ鍵をワンタイムパッドにより暗号化して、古典通信路を介して、ノード２に送信する。

＜ステップＳ１２６〜１２８＞
ノード２は、ノード１から暗号化されたアプリ鍵を受信すると、ノード１との間でリンク鍵共有動作により共有した受信鍵（リンク受信鍵）を用いて、アプリ鍵をワンタイムパッドにより復号化する。そして、ノード２は、ノード３との間でリンク鍵共有動作により共有した送信鍵（リンク送信鍵）を用いて、アプリ鍵をワンタイムパッドにより暗号化して、古典通信路を介して、ノード３に送信する。

＜ステップＳ１２９、１３０＞
ノード３は、ノード２から暗号化されたアプリ鍵を受信すると、ノード２との間でリンク鍵共有動作により共有した受信鍵（リンク受信鍵）を用いて、アプリ鍵をワンタイムパッドにより復号化する。ノード３は、アプリ鍵を復号化すると、ノード１からアプリ鍵を受信した旨を示すアプリ鍵受信応答を、古典通信路を介して、ノード１へ送信する。以上のような、ステップＳ１２３〜Ｓ１３０の処理によって、ノード１とノード３との間でアプリ鍵を共有することができる。この場合、ノード１とノード３とが、直接、量子鍵配送を行ってリンク鍵を共有できる距離にないとしても、アプリ鍵の共有が可能となる。なお、アプリ鍵は、リンク鍵共有動作により共有したリンク鍵によってワンタイムパッドで暗号化されてノード間で共有されることから、リンク鍵と同様の安全性を有する。

＜ステップＳ１３１、Ｓ１３２＞
アプリＡは、アプリＣとのデータ通信での暗号化および復号化のために使用するアプリ鍵の提供をノード１から受ける。アプリＣは、アプリＡとのデータ通信での暗号化および復号化のために使用するアプリ鍵の提供をノード３から受ける。

なお、図５に示す量子鍵配送システムでは、ノードが３つの場合を示したが、これに限定されるものではなく、ノードの数は４つ以上でもよく、理論上、無限に距離を延長することが可能である。

このように、アプリ鍵共有動作は、暗号鍵（アプリ鍵）の中継およびネットワーク化が可能となる。上述したリンク鍵共有動作による暗号鍵（リンク鍵）の共有動作は、単一光子を送受信することを前提とするため、光ファイバリンク上の光の減衰によってリンク鍵の共有ができなくなる可能性があり、リンク鍵の共有を行うことができるノード間の距離には物理的な制約（例えば、１００［ｋｍ］以下）が生じることが考えられる。一方、アプリ鍵共有動作におけるアプリ鍵の共有動作は、中間にノードを配置し、そのノードの安全性を仮定することで、距離の制約を打破することができる。

また、アプリ鍵共有動作は、リンク鍵共有動作に対して、動作を追加することによって実現するものである。具体的には、乱数の生成によるアプリ鍵の生成、ワンタイムパッド方式による、リンク鍵を用いたアプリ鍵の暗号化・復号化、及びその暗号化されたアプリ鍵の通信、をリンク鍵共有動作に対して追加することで、アプリ鍵共有動作は実現できる。このような、アプリ鍵共有動作を実現するために、リンク鍵共有動作に追加される動作は全て、一般的なネットワーク・プロトコル技術であり、処理遅延としても小さく、さらに、開発コストおよびメインテナンスコストも十分低いものである。

また、アプリ鍵共有動作は、上記以外にも、リンク鍵共有動作にないメリットを持つ。アプリ鍵の共有動作は、共有する暗号鍵（アプリ鍵）のフォーマットを、量子鍵配送の内部処理に依存することなく、任意に決定できることから、純粋な乱数である暗号鍵以外にも、任意のパスフレーズ、証明書、または暗号に関するパラメータ等を含んだ形で安全に共有することができる。

一方で、図４に示すアプリ鍵共有動作は、図２および３に示すリンク鍵共有動作を含むものであり、全体としては処理プロセスが長く、処理遅延が大きいという問題点がある。特に、図２、３に示すリンク鍵共有動作は、Ｑ３Ｐによるプロトコル処理を含み、同一のリンク鍵を選択するように同期制御を行うため、制御データの交換、およびプロトコル処理が必要となるため、処理遅延が大きいという問題点がある。また、Ｑ３Ｐは、量子鍵配送におけるリンク鍵の共有の手法としてのみ用いられる特殊なプロトコルであり、汎用性がなく、他の技術分野で利用されることがないことから、開発コストおよびメインテナンスコストが高くなるという問題点もある。以上のような、図２および３に示すリンク鍵共有動作が有する問題点を解消するために、本実施形態では、Ｑ３Ｐによるプロトコル処理を要しないリンク鍵共有動作およびアプリ鍵共有動作を採用する。以下、Ｑ３Ｐによるプロトコル処理を含まないリンク鍵共有動作およびアプリ鍵共有動作を適用した本実施形態に係る量子鍵配送システム１００について説明をする。

図６は、第１の実施形態に係るノードのハードウェア構成の一例を示す図である。図６を参照しながら、ノードのハードウェア構成について説明する。なお、以下では、ノード１を例にして説明をする。

図６に示すように、ノード１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８２と、通信Ｉ／Ｆ８３と、補助記憶装置８４と、光学処理装置８５と、を備えている。

ＣＰＵ８０は、ノード１全体の動作を制御する演算装置である。ＲＯＭ８１は、ＣＰＵ８０が各機能を制御するために実行するプログラムを記憶する不揮発性記憶装置である。ＲＡＭ８２は、ＣＰＵ８０のワークメモリ等として機能する揮発性記憶装置である。

通信Ｉ／Ｆ８３は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークまたは無線ネットワーク等の古典通信路を介してデータ通信を行うためのインターフェースである。通信Ｉ／Ｆ８３は、例えば、１０Ｂａｓｅ−Ｔ、１００Ｂａｓｅ−ＴＸもしくは１０００Ｂａｓｅ−Ｔ等のＥｔｈｅｒｎｅｔ（登録商標）に対応したインターフェースであってもよいし、光ファイバであってもよい。

補助記憶装置８４は、ＣＰＵ８０で実行される各種プログラム、リンク鍵共有動作、およびアプリ鍵共有動作の過程で生成したデータ等を記憶して蓄積する不揮発性記憶装置である。補助記憶装置８４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリまたは光ディスク等の電気的、磁気的または光学的に記憶可能な記憶装置である。

光学処理装置８５は、量子通信路を介して、光子列を送信または受信する光学装置である。ノード１の光学処理装置８５は、例えば、乱数によって発生させたビット情報であるビット列（光子ビット列）を基に、ランダムに選択した基底により生成した基底情報に基づく偏光状態となるように生成した単一光子から構成される光子列を、量子通信路（図１に示す光ファイバリンク４）を介して、ノード２の光学処理装置８５に送信する。すなわち、ノード１の光学処理装置８５により発生された光子列の各光子は、「０」から「１」かの１ビットの情報を有する。ノード２の光学処理装置８５は、量子通信路を介して、ノード１の光学処理装置８５から光子列を受信し、受信した光子列を、ランダムに選択した基底により生成した基底情報に基づいて読み取ることによってビット情報である光子ビット列を得る。

上述のＣＰＵ８０、ＲＯＭ８１、ＲＡＭ８２、通信Ｉ／Ｆ８３、補助記憶装置８４、および光学処理装置８５は、アドレスバスおよびデータバス等のバス８６によって互いに通信可能に接続されている。

図７は、第１の実施形態に係るノードの機能ブロックの構成の一例を示す図である。図７を参照しながら、ノード１およびノード２の機能ブロックの構成について説明する。

図７に示すように、ノード１は、量子鍵共有部１０（量子鍵共有手段、第１量子鍵共有手段）と、鍵蒸留部１１（鍵蒸留手段、第１鍵蒸留手段）と、リンク鍵管理部１２（第１管理手段、第１リンク鍵管理手段）と、暗号通信トンネル部１３と、アプリ鍵管理部１４（第２管理手段、第１アプリ鍵管理手段）と、鍵提供部１５（鍵管理手段、第１鍵管理手段）と、制御部１６と、記憶部１７と、を有する。

量子鍵共有部１０は、例えば、乱数によって発生させたビット情報である光子ビット列を基に、ランダムに選択した基底により生成した基底情報に基づく偏光状態となるように生成した単一光子から構成される光子列を、量子通信路（図１に示す光ファイバリンク４）を介して、ノード２の量子鍵共有部２０に送信する機能部である。量子鍵共有部１０は、図６に示す光学処理装置８５によって実現される。

鍵蒸留部１１は、ノード２の鍵蒸留部２１との間で、古典通信路を介して、鍵蒸留処理データの通信を行うことによって、光子ビット列から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行する機能部である。

リンク鍵管理部１２は、鍵蒸留部１１の鍵蒸留処理により生成されたリンク鍵を管理する機能部である。具体的には、リンク鍵管理部１２は、鍵蒸留部１１により生成されたリンク鍵を、記憶部１７に記憶させる。

暗号通信トンネル部１３は、リンク鍵管理部１２により記憶部１７に記憶されたリンク送信鍵により、ノード１からノード２へと暗号化したデータを送信するために、古典通信路上で暗号通信路（以下、「暗号通信トンネル」と称する）を確立する機能部である。なお、この暗号通信トンネルは、ノード１からノード２に暗号鍵（アプリ鍵）を送信するための、古典通信路上に確立された一方通行の通信路として利用されてもよい。

アプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成し、記憶部１７に記憶されたリンク送信鍵を用いてアプリ鍵を暗号化し、暗号通信トンネルを介して、ノード２のアプリ鍵管理部１４に送信する機能部である。アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡが送信するデータを暗号化するためのアプリ送信鍵、およびアプリＡが受信したデータを復号化するためのアプリ受信鍵として、記憶部１７に記憶させる。

鍵提供部１５は、アプリＡがデータを暗号化および復号化するために、記憶部１７に記憶されたアプリ送信鍵およびアプリ受信鍵を、アプリＡに提供する機能部である。

制御部１６は、上述の各機能部の動作を制御する機能部である。特に、制御部１６は、上述の各機能部によって実行されるリンク鍵共有動作、およびリンク鍵共有動作を含むアプリ鍵共有動作の制御を行う。

記憶部１７は、鍵蒸留部１１により生成されたリンク鍵、およびアプリ鍵管理部１４により生成されたアプリ鍵を記憶する機能部である。記憶部１７は、図６に示す補助記憶装置８４によって実現される。

上述の鍵蒸留部１１、リンク鍵管理部１２、暗号通信トンネル部１３、アプリ鍵管理部１４、鍵提供部１５、および制御部１６は、図６に示すＣＰＵ８０が補助記憶装置８４等に記憶されたプログラムをＲＡＭ８２に読み出して実行することによって実現される。なお、鍵蒸留部１１、リンク鍵管理部１２、暗号通信トンネル部１３、アプリ鍵管理部１４、鍵提供部１５、および制御部１６のすべてがプログラムの実行により実現されることに限定されるものではなく、少なくともいずれかが、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはその他の集積回路等のハードウェア回路によって実現されるものとしてもよい。

なお、図７に示す量子鍵共有部１０、鍵蒸留部１１、リンク鍵管理部１２、暗号通信トンネル部１３、アプリ鍵管理部１４、鍵提供部１５、制御部１６、および記憶部１７は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図７で独立した機能部として図示した複数の機能部を、１つの機能部として構成してもよい。一方、図７の１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

図７に示すように、ノード２は、量子鍵共有部２０（量子鍵共有手段、第２量子鍵共有手段）と、鍵蒸留部２１（鍵蒸留手段、第２鍵蒸留手段）と、リンク鍵管理部２２（第１管理手段、第２リンク鍵管理手段）と、暗号通信トンネル部２３と、アプリ鍵管理部２４（第２管理手段、第２アプリ鍵管理手段）と、鍵提供部２５（鍵管理手段、第２鍵管理手段）と、制御部２６と、記憶部２７と、を有する。

量子鍵共有部２０は、量子通信路を介して、ノード１の量子鍵共有部１０から光子列を受信し、受信した光子列を、ランダムに選択した基底により生成した基底情報に基づいて読み取ることによってビット情報である光子ビット列を得る機能部である。量子鍵共有部２０は、図２に示す光学処理装置８５によって実現される。

鍵蒸留部２１は、ノード１の鍵蒸留部１１との間で、古典通信路を介して、鍵蒸留処理データの通信を行うことによって、光子ビット列から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行する機能部である。

リンク鍵管理部２２は、鍵蒸留部２１の鍵蒸留処理により生成されたリンク鍵を管理する機能部である。具体的には、リンク鍵管理部２２は、鍵蒸留部２１により生成されたリンク鍵を、記憶部２７に記憶させる。

暗号通信トンネル部２３は、リンク鍵管理部２２により記憶部２７に記憶されたリンク受信鍵により、ノード１からノード２へと送信される暗号化されたデータを受信するために、古典通信路上で暗号通信路（暗号通信トンネル）を確率する機能部である。なお、この暗号通信トンネルは、のノード１からノード２に暗号鍵（アプリ鍵）を送信するための、古典通信路上に確立された一方通行の通信路として利用されてもよい。

アプリ鍵管理部２４は、アプリ鍵管理部１４から暗号通信トンネルを介して受信した暗号化されたアプリ鍵を、記憶部２７に記憶されたリンク受信鍵を用いて復号化する機能部である。アプリ鍵管理部２４は、復号化したアプリ鍵を、アプリＢが送信するデータを暗号化するためのアプリ送信鍵、およびアプリＢが受信したデータを復号化するためのアプリ受信鍵として、記憶部２７に記憶させる。

鍵提供部２５は、アプリＢがデータを暗号化および復号化するために、記憶部２７に記憶されたアプリ送信鍵およびアプリ受信鍵を、アプリＢに提供する機能部である。

制御部２６は、上述の各機能部の動作を制御する機能部である。特に、制御部２６は、上述の各機能部によって実行されるリンク鍵共有動作、およびリンク鍵共有動作を含むアプリ鍵共有動作の制御を行う。

記憶部２７は、鍵蒸留部２１により生成されたリンク鍵、およびアプリ鍵管理部２４により復号化されたアプリ鍵を記憶する機能部である。記憶部２７は、図６に示す補助記憶装置８４によって実現される。

上述の鍵蒸留部２１、リンク鍵管理部２２、暗号通信トンネル部２３、アプリ鍵管理部２４、鍵提供部２５、および制御部２６は、図６に示すＣＰＵ８０が補助記憶装置８４等に記憶されたプログラムをＲＡＭ８２に読み出して実行することによって実現される。なお、鍵蒸留部２１、リンク鍵管理部２２、暗号通信トンネル部２３、アプリ鍵管理部２４、鍵提供部２５、および制御部２６のすべてがプログラムの実行により実現されることに限定されるものではなく、少なくともいずれかが、例えば、ＡＳＩＣ、ＦＰＧＡまたはその他の集積回路等のハードウェア回路によって実現されるものとしてもよい。

なお、図７に示す量子鍵共有部２０、鍵蒸留部２１、リンク鍵管理部２２、暗号通信トンネル部２３、アプリ鍵管理部２４、鍵提供部２５、制御部２６、および記憶部２７は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図７で独立した機能部として図示した複数の機能部を、１つの機能部として構成してもよい。一方、図７の１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

本実施形態のリンク鍵共有動作は、量子鍵共有部１０、２０の光子列の送受信、鍵蒸留部１１、２１の鍵蒸留処理によるリンク鍵の生成、およびリンク鍵管理部１２、２２のリンク鍵の記憶によって実現される。また、本実施形態のアプリ鍵共有動作のうちリンク鍵共有動作以外の動作、すなわち、アプリ鍵を共有する動作は、アプリ鍵管理部１４、２４の動作によって実現される。

図８は、第１の実施形態のアプリ鍵共有動作を示すシーケンス図である。図８を参照しながら、本実施形態のアプリ鍵共有動作について説明する。

＜ステップＳ２１＞
ノード１の量子鍵共有部１０は、例えば、乱数によって発生させたビット情報（光子ビット列）について、ランダムに選択した基底により生成した基底情報に基づいて生成した単一光子から構成される光子列を、量子通信路を介して、ノード２の量子鍵共有部２０に送信する。

＜ステップＳ２２＞
ノード２の量子鍵共有部２０は、量子通信路を介して、量子鍵共有部１０から光子列を受信し、受信した光子列を、ランダムに選択した基底により生成した基底情報に基づいて読み取ることによって光子ビット列を得る。

＜ステップＳ２３＞
ノード１の鍵蒸留部１１は、ノード２の鍵蒸留部２１との間で古典通信路を介して鍵蒸留処理データの通信を行うことによって、光子ビット列から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行する。

＜ステップＳ２４＞
ノード２の鍵蒸留部２１は、ノード１の鍵蒸留部１１との間で古典通信路を介して鍵蒸留処理データの通信を行うことによって、光子ビット列から暗号鍵（リンク鍵）を生成する鍵蒸留処理を実行する。

＜ステップＳ２５＞
ノード１のリンク鍵管理部１２は、鍵蒸留部１１の鍵蒸留処理により生成されたリンク鍵を、アプリ鍵管理部１４により生成されるアプリ鍵を暗号化するためのリンク送信鍵５０として、記憶部１７に記憶させる。

＜ステップＳ２６＞
ノード２のリンク鍵管理部２２は、鍵蒸留部２１の鍵蒸留処理により生成されたリンク鍵を、アプリ鍵管理部２４によりアプリ鍵を復号化するためのリンク受信鍵６１として、記憶部２７に記憶させる。

以上のステップＳ２１〜２６の動作によって、本実施形態のリンク鍵共有動作が実行される。すなわち、鍵蒸留部１１、２１によってそれぞれ生成されたリンク鍵は、Ｑ３Ｐ等のプロトコル処理によって仕分けされることなく、リンク送信鍵またはリンク受信鍵として特化して記憶される。つまり、鍵蒸留部１１により生成されたリンク鍵は、ノード２に送信するアプリ鍵の暗号化のためのリンク送信鍵としてのみ利用され、鍵蒸留部２１により生成されたリンク鍵は、ノード１から受信したアプリ鍵を復号化するためのリンク受信鍵としてのみ利用される。

＜ステップＳ２７＞
ノード１のアプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡが送信するデータを暗号化するためのアプリ送信鍵５２（第１アプリ鍵の一例）、およびアプリＡが受信したデータを復号化するためのアプリ受信鍵５３（第１アプリ鍵の一例）として、記憶部１７に記憶させる。

＜ステップＳ２８＞
アプリ鍵管理部１４は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵５０を用いて、生成したアプリ鍵を暗号化して、暗号通信トンネルを介して、ノード２のアプリ鍵管理部２４に送信する。このように、アプリ鍵管理部１４により生成されたアプリ鍵は、暗号通信トンネルを介して、ノード２に対して一方通行で送信される。また、アプリ鍵管理部１４は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（例えば、送信鍵か受信鍵かを区別する情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。なお、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報は、アプリ鍵と同様に暗号化されても良い。また、暗号化は行わず、データ認証のみを実施しても良い。

＜ステップＳ２９＞
ノード２のアプリ鍵管理部２４は、ノード１のアプリ鍵管理部１４から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵６１を用いて、アプリ鍵を復号化する。また、アプリ鍵管理部２４は、アプリ鍵に付与された、役割を決定する情報に従って、復号化したアプリ鍵を、アプリＢが送信するデータを暗号化するためのアプリ送信鍵６２（第２アプリ鍵の一例）、およびアプリＢが受信したデータを復号化するためのアプリ受信鍵６３（第２アプリ鍵の一例）として、記憶部２７に記憶させる。

以上の動作によって、本実施形態のアプリ鍵共有動作が実行され、ノード１とノード２との間でアプリ鍵が共有される。

このように、本実施形態に係る量子鍵配送システム１００では、鍵蒸留部１１により生成されたリンク鍵は、ノード２に送信するアプリ鍵の暗号化のためのリンク送信鍵としてのみ利用され、鍵蒸留部２１により生成されたリンク鍵は、ノード１から受信したアプリ鍵を復号化するためのリンク受信鍵としてのみ利用されるものとしている。そして、ノード１のアプリ鍵管理部１４は、アプリ鍵として、アプリＡが送信するデータを暗号化するためのアプリ送信鍵５２（アプリＢにとっては、受信したデータを復号化するためのアプリ受信鍵６３）、およびアプリＡが受信したデータを復号化するためのアプリ受信鍵５３（アプリＢにとっては、送信するデータを暗号化するためのアプリ送信鍵６２）の双方を生成するものとしている。これによって、ノード１およびノード２は、Ｑ３Ｐ等のプロトコル処理を実行することなく、アプリ鍵（アプリ送信鍵およびアプリ受信鍵）を共有することができ、アプリＡおよびアプリＢは、共有されたアプリ鍵を利用することによって、ワンタイムパッド方式の暗号データ通信が可能となる。このように、アプリ鍵の共有のために、Ｑ３Ｐ等のプロトコル処理を実行する必要がないので、暗号鍵（リンク鍵およびアプリ鍵）の共有動作の処理遅延を低減することができる。

なお、図８の例では、暗号通信トンネルは、ノード１からノード２にアプリ鍵を送信するための一方通行の通信路としたが、これに限定されるものではなく、ノード２からノード１にアプリ鍵を送信するための一方通行の通信路としてもよい。この場合、ノード１で生成したリンク鍵は、リンク受信機として記憶し、ノード２で生成したリンク鍵は、リンク送信機として記憶すればよい。

＜変形例＞
本変形例のアプリ鍵共有動作について、上述の図８に示すアプリ鍵共有動作と相違する点を中心に説明する。第１の実施形態では、アプリ鍵として、１組のアプリケーション（アプリＡ、Ｂ）が用いるアプリ送信鍵およびアプリ受信鍵という２種類の暗号鍵を共有する動作を示した。本変形例では、複数組のアプリケーションが稼働している場合の、ノード１およびノード２でのアプリ鍵共有動作について説明する。

図９は、第１の実施形態の変形例のアプリ鍵共有動作を示すシーケンス図である。図９を参照しながら、本変形例のアプリ鍵共有動作について説明する。

図９に示すように、ノード１に接続された、またはノード１において実行されているアプリケーションとして、アプリＡ１、Ｂ１、Ｃ１が稼働しているものとする。また、ノード２に接続された、またはノード１において実行されているアプリケーションとして、アプリＡ２、Ｂ２、Ｃ２が稼働しているものとする。ノード１のアプリＡ１は、ノード２のアプリＡ２とワンタイムパッド方式で暗号データ通信をするものとし、双方とも、データを相手に送信する場合には、データを暗号化するアプリ送信鍵を必要とし、相手からデータを受信する場合には、データを復号化するアプリ受信鍵を必要とするものする。また、ノード１のアプリＢ１は、ノード２のアプリＢ２とワンタイムパッド方式で暗号データ通信をするものとし、双方とも、データを相手に送信する場合には、データを暗号化するアプリ送信鍵を必要とし、相手からデータを受信する場合には、データを復号化するアプリ受信鍵を必要とするものする。また、ノード１のアプリＣ１は、ノード２のアプリＣ２と暗号データ通信をするものとし、例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）のような、アプリケーションが送信および受信する際の送信鍵と受信鍵とを区別する必要のない暗号データ通信を行うものとする。この場合、アプリＣ１、Ｃ２が、送信鍵と受信鍵とをせずに暗号データ通信を行う場合に必要とするアプリ鍵を「アプリＣ鍵」と称するものとする。

＜＜ステップＳ２１〜Ｓ２６＞＞
図８に示したステップＳ２１〜Ｓ２６のリンク鍵共有動作と同様である。

＜＜ステップＳ２７ａ＞＞
ノード１のアプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡ１が送信するデータを暗号化するためのアプリＡ送信鍵５２ａ（第１アプリ鍵の一例）、アプリＡ１が受信したデータを復号化するためのアプリＡ受信鍵５３ａ（第１アプリ鍵の一例）、アプリＢ１が送信するデータを暗号化するためのアプリＢ送信鍵５２ｂ（第１アプリ鍵の一例）、アプリＢ１が受信したデータを復号化するためのアプリＢ受信鍵５３ｂ（第１アプリ鍵の一例）、およびアプリＣ１が送受信するデータを暗号化および復号化するためのアプリＣ鍵５２ｃ（第１アプリ鍵の一例）として、記憶部１７に記憶させる。

＜＜ステップＳ２８ａ＞＞
アプリ鍵管理部１４は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵５０を用いて、生成したアプリ鍵を暗号化して、暗号通信トンネルを介して、ノード２のアプリ鍵管理部２４に送信する。また、アプリ鍵管理部１４は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（例えば、どのアプリケーションで用いられるか、または、送信鍵および受信鍵のどちらとして使用されるか等の情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵がどのアプリケーションで使用されるかについて、および、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。なお、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報は、アプリ鍵と同様に暗号化されてもよい。また、暗号化は行わず、データ認証のみを実施してもよい。

＜＜ステップＳ２９ａ＞＞
ノード２のアプリ鍵管理部２４は、ノード１のアプリ鍵管理部１４から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵６１を用いて、アプリ鍵を復号化する。また、アプリ鍵管理部２４は、アプリ鍵に付与された、役割を決定する情報に従って、復号化したアプリ鍵を、アプリＡ２が送信するデータを暗号化するためのアプリＡ送信鍵６２ａ（第２アプリ鍵の一例）、アプリＡ２が受信したデータを復号化するためのアプリＡ受信鍵６３ａ（第２アプリ鍵の一例）、アプリＢ２が送信するデータを暗号化するためのアプリＢ送信鍵６２ｂ（第２アプリ鍵の一例）、アプリＢ２が受信したデータを復号化するためのアプリＢ受信鍵６３ｂ（第２アプリ鍵の一例）、およびアプリＣ２が送受信するデータを暗号化および復号化するためのアプリＣ鍵６２ｃ（第２アプリ鍵の一例）として、記憶部２７に記憶させる。

以上のように、ノード間で複数のアプリケーションが稼働している場合にも、アプリ鍵に３種類以上の役割を割り当てて、暗号鍵（リンク鍵およびアプリ鍵）の共有動作の処理遅延を低減させつつ、アプリ鍵を複数のアプリケーションに提供することができる。

なお、アプリケーションによっては、そもそも片方向通信しか行わない場合もある。この場合には、データを送信するアプリケーション側にアプリ送信鍵を割り当て、データを受信するアプリケーション側にアプリ受信鍵を割り当てるものとすればよい。

（第２の実施形態）
第２の実施形態のアプリ鍵共有動作について、上述の図８に示す第１の実施形態のアプリ鍵共有動作と相違する点を中心に説明する。第１の実施形態では、アプリケーションに提供する暗号鍵はアプリ鍵のみであった。本実施形態では、アプリケーションに提供する暗号鍵として、アプリ鍵の他、リンク鍵をも用いる。

図１０は、第２の実施形態に係るノードのアプリ鍵共有動作の一例を示すシーケンス図である。図１０を参照しながら、本実施形態のアプリ鍵共有動作について説明する。

＜ステップＳ３１〜Ｓ３６＞
本実施形態のステップＳ３１〜Ｓ３６は、図８に示したステップＳ２１〜Ｓ２６のリンク鍵共有動作と同様である。

＜ステップＳ３７＞
ノード１のアプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。ただし、アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡが受信したデータを復号化するためのアプリ受信鍵５３（第１アプリ鍵の一例）（すなわち、アプリＢが送信するデータを暗号化するためのアプリ送信鍵６２）としてのみ、記憶部１７に記憶させる。

＜ステップＳ３８＞
アプリ鍵管理部１４は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵５０を用いて、生成したアプリ鍵を暗号化して、暗号通信トンネルを介して、ノード２のアプリ鍵管理部２４に送信する。このように、アプリ鍵管理部１４により生成されたアプリ鍵は、暗号通信トンネルを介して、ノード２に対して一方通行で送信される。また、アプリ鍵管理部１４は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（ここでは、アプリ送信鍵としての役割を決定する情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。なお、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報は、アプリ鍵と同様に暗号化されてもよい。また、暗号化は行わず、データ認証のみを実施してもよい。

＜ステップＳ３９＞
ノード２のアプリ鍵管理部２４は、ノード１のアプリ鍵管理部１４から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵６１を用いて、アプリ鍵を復号化する。また、アプリ鍵管理部２４は、アプリ鍵に付与された、役割を決定する情報に従って、復号化したアプリ鍵を、アプリＢが送信するデータを暗号化するためのアプリ送信鍵６２（第２アプリ鍵の一例）としてのみ、記憶部２７に記憶させる。

以上の動作によって、本実施形態のアプリ鍵共有動作が実行され、ノード１とノード２との間で共有されるアプリ鍵としては、ノード１のアプリ受信鍵５３、およびノード２のアプリ送信鍵６２のみが共有される。

以上のステップＳ３１〜Ｓ３９の動作の結果、ノード１は、アプリ鍵であるアプリ受信鍵５３、およびリンク鍵であるリンク送信鍵５０を有することになり、ノード２は、アプリ鍵であるアプリ送信鍵６２、およびリンク鍵であるリンク受信鍵６１を有することになる。そして、ノード１の鍵提供部１５は、アプリＡが送信するデータを暗号化するためにリンク送信鍵５０を提供し、アプリＡが受信したデータを復号化するためにアプリ受信鍵５３を提供する。また、ノード２の鍵提供部２５は、アプリＢが送信するデータを暗号化するためにアプリ送信鍵６２を提供し、アプリＢが受信したデータを復号化するためにリンク受信鍵６１を提供する。すなわち、ノードは、アプリケーションに対して、アプリ鍵とリンク鍵との組み合わせを提供する。この場合、ノード１のアプリＡから、ノード２のアプリＢへの暗号データ通信の場合、リンク鍵（リンク送信鍵５０）をそのまま暗号化に使用することができ、リンク鍵共有動作以降に発生する処理をなくすことができる。すなわち、暗号データ通信が、アプリＡからアプリＢへの方向がほとんどを占めており、アプリＢからアプリＡへの方向の暗号データ通信が稀にしか発生しないような、暗号データ通信量が非対称なシステムにおいて、特に、暗号鍵の共有動作の処理遅延を低減することが可能になる。稀に発生するアプリＢからアプリＡの方向の暗号データ通信が必要になった場合、ノード１は、アプリ鍵としてアプリ受信鍵５３（ノード２にとってのアプリ送信鍵６２）を生成し、これを、暗号通信トンネルを介して、ノード２に暗号送信すればよい。

なお、アプリＡからアプリＢへの方向の暗号データ通信、および、アプリＢからアプリＡへの方向の暗号データ通信は、共に、ワンタイムパッド方式であってもよく、そうでなくてもよい。例えば、アプリＡからアプリＢへの方向の暗号データ通信は、ワンタイムパッド方式を採用し、アプリＢからアプリＡへの方向の暗号データ通信は、ＡＥＳの方式を採用するものとしてもよい。

また、図１０の例では、暗号通信トンネルは、ノード１からノード２にアプリ鍵を送信するための一方通行の通信路としたが、これに限定されるものではなく、ノード２からノード１にアプリ鍵を送信するための一方通行の通信路としてもよい。この場合、ノード１で生成したリンク鍵は、リンク受信機として記憶し、ノード２で生成したリンク鍵は、リンク送信機として記憶すればよい。ある方向の暗号通信にはワンタイムパッドを、別の方向の暗号通信にはＡＥＳを用いる場合を考えると、必ずしも、通信量と必要な暗号鍵量は一致しない。したがって、本実施形態は、ある方向の暗号通信に利用される暗号鍵の量と、別の方向の暗号通信に利用される暗号鍵の量が偏っており、利用される暗号鍵の量が非対称である場合にも適すると考えられる。

＜変形例＞
本変形例のアプリ鍵共有動作について、上述の図１０に示すアプリ鍵共有動作と相違する点を中心に説明する。第２の実施形態では、ノード１がアプリ鍵として生成し、ノード２へ暗号送信するのは、ノード１にとってのアプリ受信鍵５３（ノード２にとってのアプリ送信鍵６２）の一種類としていた。本変形例では、複数組のアプリケーションが稼働している場合の、ノード１およびノード２でのアプリ鍵共有動作について説明する。

図１１は、第２の実施形態の変形例に係るノードのアプリ鍵共有動作の一例を示すシーケンス図である。図１１を参照しながら、本変形例のアプリ鍵共有動作について説明する。

図１１に示すように、ノード１に接続された、またはノード１において実行されているアプリケーションとして、アプリＡ１、Ｂ１、Ｃ１が稼働しているものとする。また、ノード２に接続された、またはノード１において実行されているアプリケーションとして、アプリＡ２、Ｂ２、Ｃ２が稼働しているものとする。これらのアプリケーションの動作は、上述の図９で示した動作に準じるものとする。

＜＜ステップＳ３１〜Ｓ３６＞＞
図１０に示したステップＳ３１〜Ｓ３６のリンク鍵共有動作と同様である。

＜＜ステップＳ３７ａ＞＞
ノード１のアプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡ１が受信したデータを復号化するためのアプリＡ受信鍵５３ａ（第１アプリ鍵の一例）、アプリＢ１が送信するデータを暗号化するためのアプリＢ送信鍵５２ｂ（第１アプリ鍵の一例）、アプリＢ１が受信したデータを復号化するためのアプリＢ受信鍵５３ｂ（第１アプリ鍵の一例）、およびアプリＣ１が送受信するデータを暗号化および復号化するためのアプリＣ鍵５２ｃ（第１アプリ鍵の一例）として、記憶部１７に記憶させる。すなわち、アプリＡ１が送信するデータを暗号化するための暗号鍵としては、鍵提供部１５によりリンク送信鍵５０が提供される。

＜＜ステップＳ３８ａ＞＞
アプリ鍵管理部１４は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵５０を用いて、生成したアプリ鍵を暗号化して、暗号通信トンネルを介して、ノード２のアプリ鍵管理部２４に送信する。また、アプリ鍵管理部１４は、アプリ鍵の他、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報（例えば、どのアプリケーションで用いられるか、または、送信鍵および受信鍵のどちらとして使用されるか等の情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵がどのアプリケーションで使用されるかについて、および、アプリ鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。なお、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報は、アプリ鍵と同様に暗号化されてもよい。また、暗号化は行わず、データ認証のみを実施してもよい。

＜＜ステップＳ３９ａ＞＞
ノード２のアプリ鍵管理部２４は、ノード１のアプリ鍵管理部１４から暗号化されたアプリ鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵６１を用いて、アプリ鍵を復号化する。また、アプリ鍵管理部２４は、アプリ鍵に付与された、役割を決定する情報に従って、復号化したアプリ鍵を、アプリＡ２が送信するデータを暗号化するためのアプリＡ送信鍵６２ａ（第２アプリ鍵の一例）、アプリＢ２が送信するデータを暗号化するためのアプリＢ送信鍵６２ｂ（第２アプリ鍵の一例）、アプリＢ２が受信したデータを復号化するためのアプリＢ受信鍵６３ｂ（第２アプリ鍵の一例）、およびアプリＣ２が送受信するデータを暗号化および復号化するためのアプリＣ鍵６２ｃ（第２アプリ鍵の一例）として、記憶部２７に記憶させる。

以上のように、ノード間で複数のアプリケーションが稼働している場合にも、一部のアプリケーション（上述ではアプリＡ１、Ａ２）にリンク送信鍵５０およびリンク受信鍵６１を提供し、リンク鍵をそのまま暗号化に使用することができ、リンク鍵共有動作以降に発生する処理をなくすことができる。すなわち、暗号データ通信が、アプリＡ１からアプリＡ２への方向がほとんどを占めており、アプリＡ２からアプリＡ１への方向の暗号データ通信、および他のアプリケーション間の暗号データ通信が稀にしか発生しないような、暗号データ通信量が非対称なシステムにおいて、特に、暗号鍵の共有動作の処理遅延を低減することが可能になる。稀に発生する暗号データ通信が必要になった場合、ノード１は、対応するアプリケーションの暗号データ通信用のアプリ鍵を生成し、これを、暗号通信トンネルを介して、ノード２に暗号送信すればよい。

なお、アプリケーションによっては、そもそも片方向通信しか行わない場合もある。この場合には、データを送信するアプリケーション側にアプリ送信鍵を割り当て、データを受信するアプリケーション側にアプリ受信鍵を割り当てるものとすればよい。

（第３の実施形態）
第３の実施形態のアプリ鍵共有動作について、上述の図８に示す第１の実施形態のアプリ鍵共有動作と相違する点を中心に説明する。

上述のようなアプリ鍵共有動作が安全な暗号鍵を共有するための条件として、これらの通信が正しく実行されることが必須である。例えば、古典通信路において、鍵蒸留部１１、２１による鍵蒸留処理における鍵蒸留処理データの通信、ならびに、暗号通信トンネルの通信（リンク送信鍵で暗号化したアプリ鍵の送信）、およびその受信応答が改ざんされるリスクがある場合、これを検出できなければならない。通信データが改ざんされていないことを保証するためには、一般に、メッセージ認証と呼ばれる技術が使用される。メッセージ認証は、送信側が、通信データに、通信データそのものと、送信側および受信側しか知らない秘密データ（認証鍵）とに基づいて演算により得られる認証データを付加して送信し、受信側が、受信した通信データから同様に認証データを演算し、受信した通信データに付加されていた認証データと一致することを確認することによって、改ざんされていないことを確認する技術である。通信データが改ざんされるリスクがある場合、上述したメッセージ認証を、鍵蒸留処理データの通信および暗号通信トンネルの通信を含む全ての通信に対して実施しなければならない。以上の観点から、メッセージ認証に利用する暗号鍵である認証鍵を、ノード１とノードとの間で共有する仕組みが必要である。

図１２は、ノードのリンク鍵の生成動作の一例を示すシーケンス図である。図１２を参照しながら、鍵蒸留処理データが通信される通信鍵蒸留処理を含むリンク鍵の生成動作の流れを説明する。

＜ステップＳ１１＞
量子鍵共有部１０は、例えば、乱数によって発生させたビット情報である光子ビット列を基に、ランダムに選択した基底により生成した基底情報に基づく偏光状態となるように生成した単一光子から構成される光子列を、量子通信路を介して、ノード２の量子鍵共有部２０に送信する。量子鍵共有部１０は、生成した基底情報および光子ビット列を鍵蒸留部１１に送る。

＜ステップＳ１２＞
量子鍵共有部２０は、量子通信路を介して、ノード１の量子鍵共有部１０から光子列を受信し、受信した光子列を、ランダムに選択した基底により生成した基底情報に基づいて読み取ることによってビット情報である光子ビット列を得る。量子鍵共有部２０は、生成した基底情報および光子ビット列を鍵蒸留部２１に送る。

＜ステップＳ１３＞
鍵蒸留部１１は、ノード２の量子鍵共有部２０が生成した基底情報を、ノード２の鍵蒸留部２１から古典通信路を介して受信し、受信した基底情報と、量子鍵共有部１０が生成した基底情報とを比較して、一致する部分に対応するビットを光子ビット列から抽出して、共有ビット列を生成するシフティング処理を実行する。

＜ステップＳ１４＞
鍵蒸留部２１は、ノード１の量子鍵共有部１０が生成した基底情報を、ノード１の鍵蒸留部１１から古典通信路を介して受信し、受信した基底情報と、量子鍵共有部２０が生成した基底情報とを比較して、一致する部分に対応するビットを光子ビット列から抽出して、共有ビット列を生成するシフティング処理を実行する。

＜ステップＳ１５＞
鍵蒸留部１１は、古典通信路を介して、ノード２の鍵蒸留部２１と制御データ（ＥＣ（Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ：誤り訂正）情報）を交換することにより、生成した共有ビット列のビット誤りを訂正して訂正後ビット列を生成する誤り訂正処理を実行する。

＜ステップＳ１６＞
鍵蒸留部２１は、古典通信路を介して、ノード１の鍵蒸留部１１と制御データ（ＥＣ情報）を交換することにより、生成した共有ビット列のビット誤りを訂正して訂正後ビット列を生成する誤り訂正処理を実行する。

＜ステップＳ１７＞
鍵蒸留部１１は、古典通信路を介して、ノード２の鍵蒸留部２１から制御データ（ＰＡ（Ｐｒｉｖａｃｙ Ａｍｐｌｉｆｉｃａｔｉｏｎ：秘匿性増強）情報）を受信して、このＰＡ情報に基づいて、生成した訂正後ビット列に対して、誤り訂正処理により訂正した誤りの数から、盗聴者により盗聴された可能性のあるビットを打ち消すための鍵圧縮処理（秘匿性増強処理）を行ってリンク鍵を生成する。

＜ステップＳ１８＞
鍵蒸留部２１は、古典通信路を介して、制御データ（ＰＡ情報）を生成してノード１の鍵蒸留部１１に送信し、このＰＡ情報に基づいて、生成した訂正後ビット列に対して、誤り訂正処理の際に古典通信したデータ量等から、盗聴者により盗聴された可能性のある情報量を打ち消すための鍵圧縮処理（秘匿性増強処理）を行ってリンク鍵を生成する。

以上のような動作によって、ノード１およびノード２において、同一のリンク鍵が生成される。上述の動作によって生成されたリンク鍵は、一度しか使用しないいわゆるワンタイムパッド方式の鍵であるので、上述の動作を繰り返し実行することによって、異なるリンク鍵が繰り返し生成される。

図１３は、鍵蒸留処理での制御データの一例を示す図である。図１３を参照しながら、メッセージ認証の対象となる鍵蒸留処理での制御データ、すなわち、鍵蒸留処理データ（制御情報）の一例について説明する。

図１２で上述した鍵蒸留処理のうちシフティング処理においては、鍵蒸留部１１、２１は、図１３に示すように、それぞれ光子ビット列から共有ビット列を生成するために、古典通信路を介して、基底情報を互いに送受信する。この基底情報が、鍵蒸留処理データの一例である。

また、鍵蒸留処理のうち誤り訂正処理において、例えば、図１３に示すように、ＬＤＰＣ（Ｌｏｗ Ｄｅｎｓｉｔｙ Ｐａｒｉｔｙ Ｃｈｅｃｋ）のアルゴリズムが用いられるものとする。この場合、ノード１の鍵蒸留部１１は、生成した共有ビット列のシンドローム情報を演算し、このシンドローム情報をＥＣ情報として、古典通信路を介して、ノード２の鍵蒸留部２１へと送信する。シンドローム情報を受信した鍵蒸留部２１は、受信したシンドローム情報と、自身が生成した共有ビット列を元に演算を繰り返し、最終的に鍵蒸留部１１が生成した共有ビット列と全く同じビット情報を作成する。これによりノード１とノード２との間では、同一の訂正後ビット列を共有することができる。この誤り訂正処理において、古典通信路を介して、鍵蒸留部１１から鍵蒸留部２１に送信されるＥＣ情報であるシンドローム情報が、鍵蒸留処理データの一例となる。

また、鍵蒸留処理のうち秘匿性増強処理においては、鍵蒸留部１１、２１は、訂正後ビット列に対して、誤り訂正処理の際に古典通信したデータ量等から、盗聴者により盗聴された可能性のある情報量を打ち消すための圧縮をするために、例えば、行列データを用いる。この行列データは、ノード１およびノード２が予め共有していてもよいし、ノード１の鍵蒸留部１１が生成して、図１３に示すように、古典通信路を介して、ＰＡ情報としてノード２の鍵蒸留部２１に送信するものとしてもよい。この秘匿性増強処理において、古典通信路を介して、鍵蒸留部１１から鍵蒸留部２１に送信されるＰＡ情報である行列データが、鍵蒸留処理データの一例となる。

図１４は、暗号化されたアプリ鍵の送信と応答とを示す図である。図１４を参照しながら、メッセージ認証の対象となる暗号通信トンネルの通信、およびその受信応答について説明する。

図８等で上述したように、ノード１のアプリ鍵管理部１４は、乱数を用いて生成した暗号鍵であるアプリ鍵を、リンク送信鍵によって暗号化し、古典通信路上の暗号通信トンネルを介して、ノード２のアプリ鍵管理部１４に送信する。これによって、ノード１とノード２との間で、アプリ鍵が共有される。ここで、暗号通信トンネルを介して送信されるアプリ鍵には、アプリ鍵を識別する情報、およびアプリ鍵の役割を決定する情報等が付与されている。この暗号通信トンネルを介した送信は、ノード１からノード２への一方向の通信であるが、オプションとして、ノード２は、図１４に示すように、暗号鍵を受信した旨、または受信に失敗した旨等を示すアプリ鍵受信応答を、古典通信路を介して、ノード１に送信してもよい。以上のように、古典通信路における、アプリ鍵共有動作での暗号通信トンネルの通信（すなわち、リンク送信鍵で暗号化したアプリ鍵の送信）、およびその応答であるアプリ鍵受信応答がメッセージ認証の対象となる。また、アプリ鍵およびそれと同時に送信される、アプリ鍵を識別する情報、ならびにアプリ鍵の役割を決定する情報についても、メッセージ認証の対象としてもよい。

図１５は、第３の実施形態に係るノードのアプリ鍵共有動作の一例を示すシーケンス図である。図１５を参照しながら、本実施形態におけるアプリ鍵と共にメッセージ認証のための暗号鍵である認証鍵についても共有するアプリ鍵共有動作について説明する。なお、図１５の例では、ノード１とノード２との通信の方向毎に一種類の認証鍵を生成する場合を説明する。

＜ステップＳ４１〜Ｓ４６＞
本実施形態のステップＳ４１〜Ｓ４６は、図８に示したステップＳ２１〜Ｓ２６のリンク鍵共有動作と同様である。

＜ステップＳ４７＞
ノード１のアプリ鍵管理部１４は、鍵蒸留部１１により生成されたリンク鍵とは独立して、乱数を用いて暗号鍵であるアプリ鍵を生成する。さらに、アプリ鍵管理部１４は、乱数を用いてメッセージ認証のための暗号鍵である認証鍵を生成する。アプリ鍵管理部１４は、生成したアプリ鍵を、アプリＡが送信するデータを暗号化するためのアプリ送信鍵５２（第１アプリ鍵の一例）、およびアプリＡが受信したデータを復号化するためのアプリ受信鍵５３（第１アプリ鍵の一例）として、記憶部１７に記憶させる。また、アプリ鍵管理部１４は、生成した認証鍵を、ノード１がノード２へ送信するデータについて認証データを演算するための認証送信鍵５４（第１認証鍵の一例）、およびノード１がノード２から受信したデータについて認証データを演算するための認証受信鍵５５（第１認証鍵の一例）として、記憶部１７に記憶させる。

＜ステップＳ４８＞
アプリ鍵管理部１４は、リンク鍵共有動作により送信鍵として仕分けたリンク送信鍵５０を用いて、生成したアプリ鍵および認証鍵を暗号化して、暗号通信トンネルを介して、ノード２のアプリ鍵管理部２４に送信する。このように、アプリ鍵管理部１４により生成されたアプリ鍵および認証鍵は、暗号通信トンネルを介して、ノード２に対して一方通行で送信される。また、アプリ鍵管理部１４は、アプリ鍵および認証鍵の他、アプリ鍵および認証鍵を識別する情報、およびアプリ鍵および認証鍵の役割を決定する情報（例えば、送信鍵か受信鍵かを区別する情報）を付与した形で送信する。これによって、ノード間で、アプリ鍵および認証鍵を送信鍵として利用するか受信鍵として利用するかについて同期をとることができる。

＜ステップＳ４９＞
ノード２のアプリ鍵管理部２４は、ノード１のアプリ鍵管理部１４から暗号化されたアプリ鍵および認証鍵を受信すると、リンク鍵共有動作により受信鍵として仕分けたリンク受信鍵６１を用いて、アプリ鍵および認証鍵を復号化する。また、アプリ鍵管理部２４は、アプリ鍵に付与された、役割を決定する情報に従って、復号化したアプリ鍵を、アプリＢが送信するデータを暗号化するためのアプリ送信鍵６２（第２アプリ鍵の一例）、およびアプリＢが受信したデータを復号化するためのアプリ受信鍵６３（第２アプリ鍵の一例）として、記憶部２７に記憶させる。また、アプリ鍵管理部２４は、認証鍵に付与された、役割を決定する情報に従って、復号化した認証鍵を、ノード２がノード１に送信するデータについて認証データを演算するための認証送信鍵６４（第２認証鍵の一例）、およびノード２がノード１から受信したデータについて認証データを演算するため認証受信鍵６５（第２認証鍵の一例）として、記憶部２７に記憶させる。

以上の動作によって、本実施形態のアプリ鍵共有動作が実行され、ノード１とノード２との間で、アプリ鍵および認証鍵が共有される。

そして、ノード１の鍵提供部１５は、ノード１からノード２へデータを送信する場合、認証データを演算するために、データの送信対象に認証送信鍵５４を提供し、ノード１がノード２からデータを受信した場合、認証データを演算するために、データの受信対象に認証受信鍵５５を提供する。例えば、鍵蒸留部１１（第１データ通信機能の一例）は、鍵蒸留部２１に対して、古典通信路を介して鍵蒸留処理データを送信する場合に、メッセージ認証のために、鍵提供部１５から認証送信鍵５４が提供される。また、鍵蒸留部１１（第１データ通信機能の一例）は、鍵蒸留部２１から、古典通信路を介して鍵蒸留処理データを受信した場合、認証データを演算するために、鍵提供部１５から認証受信鍵５５が提供される。また、アプリ鍵管理部１４（第１データ通信機能の一例）は、アプリ鍵管理部２４に対して、暗号通信トンネルを介して、リンク送信鍵５０により暗号化したアプリ鍵を送信する場合に、メッセージ認証のために、鍵提供部１５から認証送信鍵５４が提供される。また、アプリ鍵管理部１４（第１データ通信機能の一例）は、アプリ鍵管理部２４から、古典通信路を介して、アプリ鍵受信応答を受信した場合、認証データを演算するために、鍵提供部１５から認証受信鍵５５が提供される。

また、ノード２の鍵提供部２５は、ノード２からノード１へデータを送信する場合、認証データを演算するために、データの送信対象に認証送信鍵６４を提供し、ノード２がノード１からデータを受信した場合、認証データを演算するために、データの受信対象に認証受信鍵６５を提供する。例えば、鍵蒸留部２１（第２データ通信機能の一例）は、鍵蒸留部１１に対して、古典通信路を介して鍵蒸留処理データを送信する場合に、メッセージ認証のために、鍵提供部２５から認証送信鍵６４が提供される。また、鍵蒸留部２１（第２データ通信機能の一例）は、鍵蒸留部１１から、古典通信路を介して鍵蒸留処理データを受信した場合、認証データを演算するために、鍵提供部２５から認証受信鍵６５が提供される。また、アプリ鍵管理部２４（第２データ通信機能の一例）は、アプリ鍵管理部１４から、暗号通信トンネルを介して、リンク送信鍵５０により暗号化されたアプリ鍵を受信した場合、認証データを演算するために、鍵提供部２５から認証受信鍵６５が提供される。また、アプリ鍵管理部２４（第２データ通信機能の一例）は、アプリ鍵管理部１４に対して、古典通信路を介して、アプリ鍵受信応答を送信する場合、メッセージ認証のために、鍵提供部２５から認証送信鍵６４が提供される。

以上のように、ノード１とノード２と間で、アプリ鍵だけではなく、メッセージ認証で使用する認証鍵を共有するものとし、古典通信路を介してデータ通信を行う場合、データの送信対象または受信対象に、認証鍵を提供するものとしている。これによって、古典通信路における通信データが改ざんされていないかどうかを確認することができる。

なお、図１５の例では、ノード１とノード２との通信の方向毎に一種類の認証鍵を生成する場合を説明したが、これに限定されるものではなく、通信の方向によらず、単一の認証鍵を利用するものとしてもよい。この場合、ノード１とノード２との間で共有される認証鍵は一種類となる。

また、図１５の例では、ノード１とノード２との通信の方向毎に一種類の認証鍵を生成する場合を説明したが、これに限定されるものではなく、通信データ毎に異なる認証鍵を生成するものとしてもよい。例えば、鍵蒸留処理データ、暗号通信トンネルの通信、およびアプリ鍵受信応答の各データ毎に異なる認証鍵を生成するものとしてもよい。さらに、鍵蒸留処理データのうち、シフティング処理時の制御データ、誤り訂正処理時の制御データ（ＥＣ情報）、および秘匿性増強処理時の制御データ（ＰＡ情報）の各データ毎に異なる認証鍵を生成するものとしてもよい。ただし、暗号通信トンネルの通信に関して、ノード１とノード２との間で、暗号通信トンネルの確立方法として、単純なワンタイムパッド方式でなく、予めメッセージ認証も行うような暗号通信トンネルを確立しておくこともできる。この場合、上述したような暗号通信トンネル用の認証鍵については別途ノード１からノード２に送信して共有する必要はない。

また、ノード１およびノード２において複数のアプリケーションが稼働している場合、アプリケーションごとに異なる認証鍵が生成されるものとしてもよい。ただし、アプリケーションにおいて、アプリ送信鍵およびアプリ受信鍵が割り当てられた場合、単純なワンタイムパッドでなく、予めメッセージ認証も行うような暗号データ通信を行うように設定しておけば、各アプリケーションに対して別途認証鍵を割り当てなくてもよい。

上述のように、通信データ毎に異なる認証鍵を生成し、または、複数のアプリケーションごとに異なる認証鍵を生成することによって、認証鍵を要する各処理が並行して動作するような場合に、各認証鍵の更新タイミングを別個に設定することができる。メッセージ認証を安全に行うためには、認証鍵を適切に更新する必要がある。認証鍵の更新タイミングは、通信データ量または経過時間等によって決定されることが一般的である。並行に実行される各処理は、他の処理の通信タイミングまたは通信データ量と独立に、適切なタイミングで認証鍵の更新を行うことができる。これによって、アプリ鍵共有動作の高速化という観点の他、各処理を独立して開発できるので開発工数を低減することができる。

なお、本実施形態で説明したメッセージ認証のための認証鍵の共有動作は、上述の第２の実施形態にも適用できることは、言うまでもない。

＜変形例＞
図１５に示したアプリ鍵共有動作において、ノード間でアプリ鍵を共有する前に、そもそもリンク鍵を共有するために必要な鍵蒸留処理データ等をメッセージ認証するための認証鍵が必要である。本変形例では、その対応方法について説明する。

図１５に示したアプリ鍵共有動作から明らかなように、最初のリンク鍵を生成するための鍵蒸留処理データを通信する前に、ノード１とノード２との間で、認証鍵を、暗号通信トンネルを介して共有することはできない。このような状況に対処するため、ノード１およびノード２は、図１５に示すアプリ鍵共有動作で共有する暗号鍵とは別に、システム起動時に安全にメッセージ認証を行うための認証鍵である初期鍵（第１初期鍵、第２初期鍵）を、記憶部１７、２７（第３記憶手段、第４記憶手段の一例）にそれぞれ予め記憶しておく。このような初期鍵として、鍵蒸留処理データのメッセージ認証用の認証鍵の他、暗号通信トンネルの通信のメッセージ認証用の認証鍵、アプリ鍵受信応答のメッセージ認証用の認証鍵についても、予め記憶部１７、２７にそれぞれ記憶しておくものとしてもよい。このような初期鍵は、システム起動後に、ノード１とノード２との間で、リンク鍵、アプリ鍵および認証鍵が共有されるようになると、その役割を終え、その後は、アプリ鍵共有動作によって共有された認証鍵によって置換されていく。なお、初期鍵は、これらリンク鍵およびアプリ鍵が記憶されるのと同じ記憶部１７、２７に記憶されていてもよいし、初期鍵専用の別の記憶部（第３記憶手段、第４記憶手段の一例）に格納されていてもよい。

以上のように認証鍵についての初期鍵を予め備えておくことによって、システム起動後の、ノード間でアプリ鍵および認証鍵を共有する前においても、各通信データについてメッセージ認証を行うことが可能となる。

（第４の実施形態）
第４の実施形態のアプリ鍵共有動作について、第３の実施形態のアプリ鍵共有動作と相違する点を中心に説明する。第４の実施形態では、動的に変化する鍵蒸留処理のアルゴリズムに応じて、認証鍵を送信する際に付与する認証鍵の役割を決定する情報を変更する動作について説明する。

図１６は、第４の実施形態における制御データの変化の一例を示す図である。

上述の図１２で示した鍵蒸留処理（シフティング処理、誤り訂正処理および秘匿性増強処理）の内容は一例を示したものであり、これ以外にも鍵蒸留処理の方法は存在する。例えば、上述の図１３においては、誤り訂正処理のアルゴリズムとして、ＬＤＰＣのアルゴリズムを適用した場合について説明したが、図１６に示すように、ｃａｓｃａｄｅというアルゴリズムを適用することもできる。ｃａｓｃａｄｅのアルゴリズムでは、ＬＤＰＣのアルゴリズムと異なり、ノード１とノード２との間で何度も制御データ（ＥＣ情報）の通信が行われる。誤り訂正処理に、このｃａｓｃａｄｅのアルゴリズムを適用することによって、複数のスレッドを用いて並行に実行することにより誤り訂正処理を高速に実行できる可能性がある。

また、上述の図１３においては、秘匿性増強処理において、ノード１からノード２にＰＡ情報である行列データが送信されるものとしたが、ノード２からノード１に送信されるものとしてもよい。

このように、鍵蒸留処理を含むリンク鍵共有動作によってリンク鍵を高速に共有するためには、逐次変化する光子列の誤り率および光子の到達数等の変動するパラメータに応じて、採用する鍵蒸留処理のアルゴリズムを動的に切り替えることが必要になる可能性がある。鍵蒸留処理のアルゴリズムが切り替えられることによって、通信方向（すなわち必要な認証鍵の種類）が変化したり、アルゴリズムを実行するスレッド数を変化させることによって、必要となる認証鍵の種類の数が変化したりすることがあり得る。そこで、本実施形態において、ノード１は、生成したアプリ鍵および認証鍵を暗号化して、暗号通信トンネルを介して、ノード２に送信する際に、切り替えられた鍵蒸留処理のアルゴリズムに対応した認証鍵の役割を決定する情報を付与して送信する。

以上の動作によって、動的に変化する鍵蒸留処理のアルゴリズムに応じて、ノード間で共有する認証鍵の役割を切り替えることができるので、アルゴリズムが動的に切り替わっても、適切にメッセージ認証を行うことができる。

なお、上述の各実施形態および変形例に係るノード（量子鍵配送装置）で実行されるプログラムは、例えば、ＲＯＭ８１等に予め組み込まれて提供されるものとしてもよい。

また、上述の各実施形態および変形例に係るノードで実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

さらに、上述の各実施形態および変形例に係るノードで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の各実施形態および変形例に係るノードで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、上述の各実施形態および変形例に係るノードで実行されるプログラムは、コンピュータを上述したノードの各機能部として機能させ得る。このコンピュータは、ＣＰＵ８０がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

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

１〜３ ノード
４、４ａ 光ファイバリンク
１０ 量子鍵共有部
１１ 鍵蒸留部
１２ リンク鍵管理部
１３ 暗号通信トンネル部
１４ アプリ鍵管理部
１５ 鍵提供部
１６ 制御部
１７ 記憶部
２０ 量子鍵共有部
２１ 鍵蒸留部
２２ リンク鍵管理部
２３ 暗号通信トンネル部
２４ アプリ鍵管理部
２５ 鍵提供部
２６ 制御部
２７ 記憶部
５０ リンク送信鍵
５２ アプリ送信鍵
５２ａ アプリＡ送信鍵
５２ｂ アプリＢ送信鍵
５２ｃ アプリＣ鍵
５３ アプリ受信鍵
５３ａ アプリＡ受信鍵
５３ｂ アプリＢ受信鍵
５４ 認証送信鍵
５５ 認証受信鍵
６１ リンク受信鍵
６２ アプリ送信鍵
６２ａ アプリＡ送信鍵
６２ｂ アプリＢ送信鍵
６２ｃ アプリＣ鍵
６３ アプリ受信鍵
６３ａ アプリＡ受信鍵
６３ｂ アプリＢ受信鍵
６４ 認証送信鍵
６５ 認証受信鍵
８０ ＣＰＵ
８１ ＲＯＭ
８２ ＲＡＭ
８３ 通信Ｉ／Ｆ
８４ 補助記憶装置
８５ 光学処理装置
８６ バス
１００ 量子鍵配送システム
１５０ リンク送信鍵
１５１ リンク受信鍵
１５２ アプリ送信鍵
１５３ アプリ受信鍵
１６０ リンク送信鍵
１６１ リンク受信鍵
１６２ アプリ送信鍵
１６３ アプリ受信鍵
１７０ａ、１７０ｂ ピックアップストア
１７１ コモンストア
１７２ａ 送信バッファ
１７２ｂ 受信バッファ
１８０ａ、１８０ｂ ピックアップストア
１８１ コモンストア
１８２ａ 送信バッファ
１８２ｂ 受信バッファ
Ａ〜Ｃ アプリ
Ａ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２ アプリ

Claims (11)

1. 他の量子鍵配送装置と、量子通信路および古典通信路で接続され、暗号鍵を共有する量子鍵配送装置であって、
   前記量子通信路を介した量子鍵配送によって、前記他の量子鍵配送装置と光子列を共有して、前記光子列に対応する光子ビット列を取得する量子鍵共有手段と、
   前記光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する鍵蒸留手段と、
   前記リンク鍵を、データの暗号化のためのリンク送信鍵として内部または外部の記憶手段に記憶させる第１管理手段と、
   暗号データ通信のための前記暗号鍵であるアプリ鍵から所定の役割を決定した第１アプリ鍵を前記記憶手段に記憶させ、前記アプリ鍵から前記第１アプリ鍵に対応する役割を決定した第２アプリ鍵を、前記リンク送信鍵で暗号化して、前記古典通信路を介して前記他の量子鍵配送装置に送信する第２管理手段と、
   アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために前記記憶手段に記憶された前記第１アプリ鍵を管理する鍵管理手段と、
   を備えた量子鍵配送装置。
2. 他の量子鍵配送装置と、量子通信路および古典通信路で接続され、暗号鍵を共有する量子鍵配送装置であって、
   前記量子通信路を介した量子鍵配送によって、前記他の量子鍵配送装置と光子列を共有して、前記光子列に対応する光子ビット列を取得する量子鍵共有手段と、
   前記光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する鍵蒸留手段と、
   前記リンク鍵を、データの復号化のためのリンク受信鍵として内部または外部の記憶手段に記憶させる第１管理手段と、
   前記他の量子鍵配送装置から受信し、かつ所定の役割が決定された暗号データ通信のための前記暗号鍵であるアプリ鍵を、前記古典通信路を介して受信し、受信した前記アプリ鍵を前記リンク受信鍵で復号化して前記記憶手段に記憶させる第２管理手段と、
   アプリケーションがデータ通信を行う際に暗号化または復号化で利用するために前記記憶手段に記憶された前記アプリ鍵を管理する鍵管理手段と、
   を備えた量子鍵配送装置。
3. 第１量子鍵配送装置と、第２量子鍵配送装置とが、量子通信路および古典通信路で接続され、暗号鍵を共有する量子鍵配送システムであって
   前記第１量子鍵配送装置は、
   前記量子通信路を介した量子鍵配送によって、前記第２量子鍵配送装置と光子列を共有して、前記光子列に対応する光子ビット列を取得する第１量子共有手段と、
   該光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する第１鍵蒸留手段と、
   該リンク鍵を、データの暗号化のためのリンク送信鍵として内部または外部の第１記憶手段に記憶させる第１リンク鍵管理手段と、
   暗号データ通信のための前記暗号鍵であるアプリ鍵から所定の役割を決定した第１アプリ鍵を前記第１記憶手段に記憶させ、前記アプリ鍵から前記第１アプリ鍵に対応する役割を決定した第２アプリ鍵を、前記リンク送信鍵で暗号化して、前記古典通信路を介して前記第２量子鍵配送装置に送信する第１アプリ鍵管理手段と、
   アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために前記第１記憶手段に記憶された前記第１アプリ鍵を管理する第１鍵管理手段と、
   を備え、
   前記第２量子鍵配送装置は、
   前記量子通信路を介した量子鍵配送によって、前記第１量子鍵配送装置と前記光子列を共有して、前記光子列に対応する光子ビット列を取得する第２量子鍵共有手段と、
   該光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する第２鍵蒸留手段と、
   該リンク鍵を、データの復号化のためのリンク受信鍵として内部または外部の第２記憶手段に記憶させる第２リンク鍵管理手段と、
   前記第１アプリ鍵管理手段から前記古典通信路を介して受信した前記第２アプリ鍵を、前記リンク受信鍵で復号化して前記第２記憶手段に記憶させる第２アプリ鍵管理手段と、
   アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために前記第２記憶手段に記憶された前記第２アプリ鍵を管理する第２鍵管理手段と、
   を備えた量子鍵配送システム。
4. 前記第１鍵管理手段は、アプリケーションがデータ通信を行う際の暗号化で利用するために前記第１記憶手段に記憶された前記リンク送信鍵を管理し、
   前記第２鍵管理手段は、アプリケーションがデータ通信を行う際の復号化で利用するために前記第２記憶手段に記憶された前記リンク受信鍵を管理する請求項３に記載の量子鍵配送システム。
5. 前記第１アプリ鍵管理手段は、データ認証のための前記暗号鍵である認証鍵に所定の役割を決定した第１認証鍵を前記第１記憶手段に記憶させ、前記認証鍵に前記第１認証鍵に対応する役割を決定した第２認証鍵を、前記リンク送信鍵で暗号化して、前記古典通信路を介して前記第２量子鍵配送装置に送信し、
   前記第１鍵管理手段は、前記第１記憶手段に記憶された前記第１認証鍵を、第１データ通信機能がデータ認証の対象となる通信データを通信する際に、該通信データに基づいて認証データを生成するために、前記第１データ通信機能に提供し、
   前記第２アプリ鍵管理手段は、前記第１アプリ鍵管理手段から前記古典通信路を介して受信した前記第２認証鍵を、前記リンク受信鍵で復号化して前記第２記憶手段に記憶させ、
   前記第２鍵管理手段は、前記第２記憶手段に記憶された前記第２認証鍵を、第２データ通信機能がデータ認証の対象となる通信データを通信する際に、該通信データに基づいて認証データを生成するために、前記第２データ通信機能に提供する請求項３に記載の量子鍵配送システム。
6. 前記第１アプリ管理手段は、前記第１データ通信機能として動作し、前記第１鍵管理手段から提供された前記第１認証鍵を用いて、前記リンク送信鍵で暗号化したデータ認証の対象となる前記第２アプリ鍵から認証データを生成し、暗号化した第２アプリ鍵に該認証データを付加して、前記古典通信路を介して前記第２量子鍵配送装置に送信し、
   前記第２アプリ管理手段は、前記第２データ通信機能として動作し、前記第２鍵管理手段から提供された前記第２認証鍵を用いて、前記第１アプリ鍵管理手段から前記古典通信路を介して受信した、暗号化された前記第２アプリ鍵から認証データを生成する請求項５に記載の量子鍵配送システム。
7. 前記第１鍵蒸留手段は、前記第１データ通信機能として動作し、鍵蒸留処理の実行時に、前記第２鍵蒸留手段と、前記古典通信路を介してデータ認証の対象となる制御情報を送受信する際に、前記第１鍵管理手段から提供された前記第１認証鍵を用いて、前記制御情報から認証データを生成し、
   前記第２鍵蒸留手段は、前記第２データ通信機能として動作し、鍵蒸留処理の実行時に、前記第１鍵蒸留手段と、前記古典通信路を介して前記制御情報を送受信する際に、前記第２鍵管理手段から提供された前記第２認証鍵を用いて、前記制御情報から認証データを生成する請求項５に記載の量子鍵配送システム。
8. 前記第１アプリ鍵管理手段は、前記第１鍵蒸留手段および前記第２鍵蒸留手段の鍵蒸留処理のアルゴリズムが変更された場合、前記認証鍵に、変更されたアルゴリズムに対応した役割を決定した前記第１認証鍵を前記第１記憶手段に記憶させる請求項７に記載の量子鍵配送システム。
9. 前記第１鍵管理手段は、前記第１記憶手段に記憶された前記第１認証鍵を、前記第１データ通信機能としてのアプリケーションがデータ認証の対象となる通信データを通信する際に、該通信データに基づいて認証データを生成するために、該アプリケーションに提供し、
   前記第２鍵管理手段は、前記第２記憶手段に記憶された前記第２認証鍵を、前記第２データ通信機能としてのアプリケーションがデータ認証の対象となる通信データを通信する際に、該通信データに基づいて認証データを生成するために、該アプリケーションに提供する請求項５に記載の量子鍵配送システム。
10. 前記第１量子鍵配送装置は、前記第１アプリ鍵管理手段により前記第１認証鍵が前記第１記憶手段に記憶される前に、前記第１認証鍵の代わりに前記第１データ通信機能によって認証データが生成される場合に用いられる第１初期鍵を記憶する第３記憶手段を、さらに備え、
    前記第２量子鍵配送装置は、前記第２アプリ鍵管理手段により前記第２認証鍵が前記第２記憶手段に記憶される前に、前記第２認証鍵の代わりに前記第２データ通信機能によって認証データが生成される場合に用いられる第２初期鍵を記憶する第４記憶手段を、さらに備えた請求項５に記載の量子鍵配送システム。
11. 第１量子鍵配送装置と、第２量子鍵配送装置とが、量子通信路および古典通信路で接続され、暗号鍵を共有する量子鍵配送システムの量子鍵配送方法であって、
    前記第１量子鍵配送装置で、前記量子通信路を介した量子鍵配送によって、前記第２量子鍵配送装置と光子列を共有して、前記光子列に対応する光子ビット列を取得する第１量子鍵共有ステップと、
    前記第１量子鍵配送装置で、該光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する第１鍵蒸留ステップと、
    前記第１量子鍵配送装置で、該リンク鍵を、データの暗号化のためのリンク送信鍵として内部または外部の第１記憶手段に記憶させる第１リンク鍵管理ステップと、
    前記第１量子鍵配送装置で、暗号データ通信のための前記暗号鍵であるアプリ鍵から所定の役割を決定した第１アプリ鍵を前記第１記憶手段に記憶させ、前記アプリ鍵から前記第１アプリ鍵に対応する役割を決定した第２アプリ鍵を、前記リンク送信鍵で暗号化して、前記古典通信路を介して前記第２量子鍵配送装置に送信する第１アプリ鍵管理ステップと、
    前記第１量子鍵配送装置で、アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために前記第１記憶手段に記憶された前記第１アプリ鍵を管理する第１鍵管理ステップと、
    前記第２量子鍵配送装置で、前記量子通信路を介した量子鍵配送によって、前記第１量子鍵配送装置と前記光子列を共有して、前記光子列に対応する光子ビット列を取得する第２量子鍵共有ステップと、
    前記第２量子鍵配送装置で、該光子ビット列から、鍵蒸留処理によって前記暗号鍵であるリンク鍵を生成する第２鍵蒸留ステップと、
    前記第２量子鍵配送装置で、該リンク鍵を、データの復号化のためのリンク受信鍵として内部または外部の第２記憶手段に記憶させる第２リンク鍵管理ステップと、
    前記第２量子鍵配送装置で、前記第１量子鍵配送装置から前記古典通信路を介して受信した前記第２アプリ鍵を、前記リンク受信鍵で復号化して前記第２記憶手段に記憶させる第２アプリ鍵管理ステップと、
    前記第２量子鍵配送装置で、アプリケーションがデータ通信を行う際の暗号化または復号化で利用するために前記第２記憶手段に記憶された前記第２アプリ鍵を管理する第２鍵管理ステップと、
    を有する量子鍵配送方法。

Images