JP2019195198A - 通信装置、通信方法、プログラムおよび通信システム - Google Patents

Abstract

【課題】量子鍵配送技術により暗号鍵を共有する場合にアプリケーションなどの要求元への暗号鍵の提供を低遅延で実行可能とする。【解決手段】量子鍵配送ネットワーク上のノードである通信装置１００は、共有処理部１１０と、記憶部１５０と、制御部１３０と、を備える。共有処理部１１０は、１以上の他のノードとの間で暗号鍵を共有する。記憶部１５０は、暗号鍵を記憶する。制御部１３０は、記憶された暗号鍵の量を表す現在量と、指定された基準量とを比較し、比較結果に基づいて、共有処理部１１０による暗号鍵の共有処理の継続または停止を制御する。【選択図】図４

Description

本発明の実施形態は、通信装置、通信方法、プログラムおよび通信システムに関する。

量子鍵配送技術（ＱＫＤ）とは、光ファイバーで接続された、単一光子を連続的に送信する送信ノードと、単一光子を受信する受信ノードと、の間で、安全に暗号鍵を共有する手法である。ノードが、ＱＫＤで共有された暗号鍵とは独立に乱数（暗号鍵）を生成し、生成した乱数を別のノードに送信して共有する技術についても知られている。

特許第５６３４４２７号公報

Kollmitzer C., Pivk M. （Eds.）, Applied Quantum Cryptography, Lect. Notes Phys. 797 （Springer, Berlin Heidelberg 2010）, Chapter 8, ＱＫＤ Networks Based on Q3P, pp.151-171, DOI 10.1007/978-3-642-04831-9 Dianati, M., Alleaume, R., Gagnaire, M. and Shen, X. （2008）, Architecture and protocols of the future European quantum key distribution network. Security and Communication Networks, 1: 57-74. DOI: 10.1002/sec.13

しかしながら、従来技術では、アプリケーション等により暗号鍵が要求されてから、暗号鍵の共有処理が実行される。このため、要求元のアプリケーション等が暗号鍵の利用をするまでに処理遅延が発生するという問題点があった。

実施形態の通信装置は、共有処理部と、記憶部と、制御部と、を備える。共有処理部は、１以上の外部装置との間で暗号鍵を共有する。記憶部は、暗号鍵を記憶する。制御部は、記憶された暗号鍵の量を表す現在量と、指定された基準量とを比較し、比較結果に基づいて、共有処理部による暗号鍵の共有処理の継続または停止を制御する。

量子鍵配送システムの構成例を示す図。 ＱＫＤネットワークの構成例を示す図。 暗号鍵共有処理の一例を示すシーケンス図。 第１の実施形態のノードの機能ブロック図。 ノードの鍵情報テーブルの一例を示す図。 第１の実施形態の暗号鍵共有処理のシーケンス図。 アプリ鍵情報テーブルの例を示す図。 第１の実施形態のアプリ鍵の提供制御手順のシーケンス図。 第２の実施形態のノードの機能ブロック図。 最大量の変更処理の具体例を示す図。 最大量の変更処理の具体例を示す図。 第２の実施形態における共有量制御処理のシーケンス図。 第３の実施形態のノードの機能ブロック図。 リンク鍵情報テーブルの一例を示す図。 第３の実施形態の暗号鍵共有処理のシーケンス図。 第３の実施形態の提供制御手順のシーケンス図。 リンク鍵情報テーブルの一例を示す図。 第３の実施形態の共有量制御処理のシーケンス図。 リンク鍵情報テーブルの例を示す図。 第４の実施形態のノードの機能ブロック図。 鍵情報テーブルの一例を示す図。 実施形態にかかる通信装置のハードウェア図。

以下に添付図面を参照して、この発明にかかる通信装置の好適な実施形態を詳細に説明する。

（第１の実施形態）
ＱＫＤにより共有される暗号鍵は、量子力学の原理に基づいて、盗聴されていないことが保証されている。共有された暗号鍵を用いて、ワンタイムパッドと呼ばれる暗号通信方式を利用して暗号データ通信を行うと、送受信されるデータは、いかなる知識を有する盗聴者によっても解読できないことが情報理論によって保証されている。

図１は、量子鍵配送システムの構成例を示す図である。図１に示すように、量子鍵配送システムは、アプリケーション２０ａ、２０ｂと、ノード１０ａ、１０ｂとを含む。ノード１０ａおよびノード１０ｂは、例えば光ファイバー３０により接続される。ノード１０ａ、１０ｂは、送信ノードおよび受信ノードの少なくとも一方に対応する。以下では、送信ノードおよび受信ノードを、ノードと総称する場合がある。アプリケーション２０ａ、２０ｂは、共有された暗号鍵を用いて暗号データ通信する機能である。アプリケーション２０ａ、２０ｂは、それぞれノード１０ａ、１０ｂと一体として実現されてもよい。

ノード１０ａとノード１０ｂとの間で共有された暗号鍵は、それぞれアプリケーション２０ａとアプリケーション２０ｂに提供される。アプリケーション１０ａおよびアプリケーション１０ｂは、取得した暗号鍵を用いてデータを暗号化し、暗号データ通信を行う。ただし、ＱＫＤ技術で暗号鍵を共有する方式は、単一光子をメディアとして利用することに起因する、暗号鍵共有可能な距離の制約がある。

次に、通信システムの一例である量子鍵配送ネットワーク（ＱＫＤネットワーク）について説明する。図２は、ＱＫＤネットワークの構成例を示す図である。図２に示すように、ＱＫＤネットワークは、鍵共有ネットワーク３０１と、暗号データ通信ネットワーク３０２と、を含む。なお、図２は、ノードとアプリケーションとが独立に実現される場合の一例である。鍵共有ネットワーク３０１は、通信装置としてのノード１００ａ〜１００ｅと、アプリケーション２００ａ、２００ｂと、を含む。ノード１００ａ〜１００ｅは、鍵共有ネットワーク３０１によりリンク鍵を共有する。

ノード１００ａ〜１００ｅを区別する必要がない場合は、単にノード１００という場合がある。アプリケーション２００ａ、２００ｂを区別する必要がない場合は、単にアプリケーション２００という場合がある。ノード１００の個数は５に限られるものではない。また、アプリケーション２００の個数は２に限られるものではない。

鍵共有ネットワーク３０１は、複数のノード１００間が、それぞれ光ファイバーなどによるリンク（リンク４０１〜４０６）によって接続されるネットワークである。

なお、図２では、１つのノード１００が、送信ノードまたは受信ノードの機能を複数備えるような構成を例示している（例えば、ノード１００ａ、１００ｃ、１００ｄは２つ、ノード１００ｂ、１００ｅは３つ）。各ノード１００が、送信ノードおよび受信ノードを一体化した機能を備えるように構成してもよい。以下では主に後者の構成を例に説明する。

各ノード１００は、リンクによって接続されるノード１００（隣接ノード）との間でＱＫＤによって暗号鍵を共有する。リンクによって接続されるノード１００間でＱＫＤにより共有される暗号鍵がリンク鍵（第１暗号鍵）に相当する。さらにノード１００は、ＱＫＤとは無関係に、別途乱数情報等から、別の暗号鍵（アプリ鍵、第２暗号鍵）を生成し、暗号鍵をリンク鍵で暗号化して隣接ノードに転送する機能を有する。

リンク鍵によってアプリ鍵を暗号化してアプリ鍵を転送する処理を繰り返すことによって、ノード１００は、鍵共有ネットワーク３０１上の任意のノード１００との間でアプリ鍵を共有することができる。このときアプリ鍵は、ＱＫＤによって共有されるリンク鍵によって暗号化された状態でリンク上を転送される。従って、ノード１００自体の安全性を仮定すると、アプリ鍵の安全性は、リンク鍵と同様に保証されると言える。

一方、アプリケーション２００は、暗号データ通信ネットワーク３０２に収容されている。ここで、アプリケーション２００ａはアプリケーション２００ｂとの間で暗号データ通信を行うものとする。以下、アプリケーション２００が、鍵共有ネットワーク３０１を利用して暗号鍵を取得および共有し、暗号データ通信を行うシーケンスの例を説明する。図３は、３つのノード１００を介してアプリ鍵を共有する場合の暗号鍵共有処理の一例を示すシーケンス図である。

ノード１００ａ、１００ｂ、１００ｃは、事前にリンク鍵を共有している（ステップＳ１０１、ステップＳ１０２）。なお、リンク鍵の共有動作はこの後も繰り返されてよい。暗号通信を行いたいアプリケーション２００は、鍵共有ネットワーク３０１上のノード１００に接続する。例えば図３の例では、アプリケーション２００ａはノード１００ａに接続し、アプリケーション２００ｂはノード１００ｃに接続している。

アプリケーション２００ａは、ノード１００ａに対して、アプリケーション２００ｂと通信するために暗号鍵が利用したい旨を通知する（ステップＳ１０３）。この通知を受けたノード１００ａは、アプリケーション２００ａが通信したいアプリケーション２００ｂが接続しているノード１００ｃを特定し（ステップＳ１０４）、ノード１００ｃとの間でアプリ鍵を共有する。

具体的には、ノード１００ａはノード１００ｃに対し、アプリ鍵を共有したい旨を通知し、アプリ鍵の共有制御を開始する（ステップＳ１０５）。ノード１００ａは、乱数生成器等によってアプリ鍵を生成し、生成したアプリ鍵を、リンク鍵（ノード１００ｂと共有するリンク鍵）によって暗号化する（ステップＳ１０６）。ノード１００ａは、暗号化したアプリ鍵をノード１００ｂに転送する（ステップＳ１０７）。

ノード１００ｂは、暗号化されたアプリ鍵を受信し、このアプリ鍵をノード１００ａとの間で共有しているリンク鍵によって復号する。そしてノード１００ｂは、復号したアプリ鍵を、ノード１００ｃとの間で共有しているリンク鍵によって暗号化する（ステップＳ１０８）。ノード１００ｂは、暗号化したアプリ鍵をノード１００ｃに転送する（ステップＳ１０９）。

ノード１００ｃは、暗号化されたアプリ鍵を受信し、ノード１００ｂとの間で共有しているリンク鍵で復号する（ステップＳ１１０）。ノード１００ｃは、復号したアプリ鍵を記憶部等に記憶する（ステップＳ１１１）。ノード１００ｃは、アプリ鍵の記憶が完了したことをノード１００ａに通知する（ステップＳ１１２）。以上の処理手順によって、ノード１００ａとノード１００ｃはアプリ鍵を共有できる。

ノード１００ａは、共有したアプリ鍵をアプリケーション２００ａへ提供する（ステップＳ１１５）。ノード１００ｃは、アプリケーション２００ｂからの要求を受け（ステップＳ１１３）、共有したアプリ鍵をアプリケーション２００ｂへ提供する（ステップＳ１１４）。これによって、アプリケーション２００ａとアプリケーション２００ｂは、同一の暗号鍵（アプリ鍵）を共有することができる。この後、アプリケーション２００ａとアプリケーション２００ｂは、暗号データ通信ネットワーク３０２を介して安全な暗号データ通信を行うことができる。

以上のような、アプリ鍵とリンク鍵を組み合わせた暗号鍵共有方式は、ＱＫＤを使うことに起因する暗号鍵共有可能な距離の制約を克服できる。また、アプリケーション２００から接続されたノード１００が暗号鍵（アプリ鍵）の生成、共有、および、ルーティングを制御する本方式は、既存のネットワーク技術を活用してシンプルな構成要素によって実現することが可能である。ここでは、ノード１００ａが乱数等によって暗号鍵（アプリ鍵）を生成してこれを共有するシナリオを説明した。共有する情報はこれに限られるものではない。本方式は、ノード１００ａが、他のシステムで生成した暗号鍵、デジタル証明書、および、公開鍵方式における秘密鍵など、任意の秘密情報を共有する仕組みとして利用できる。

量子鍵配送ネットワーク（ＱＫＤネットワーク）を構築することで、ネットワーク上の任意のノード１００との間で暗号鍵を共有することができるようになる。また、例えば特許文献１の技術を用いて、アプリ鍵のセッション状態をノード側で管理し、その状態情報を利用することによって、アプリ鍵を共有するノード、頻度、およびタイミング等を決定することができるようになる。

一方、図３のように暗号鍵が要求されてから（ステップＳ１０３）、暗号鍵の共有処理が実行される方法では、要求元のアプリケーション等が暗号鍵の利用をするまでに処理遅延が発生する可能性がある。

そこで、第１の実施形態にかかる通信装置（ノード）は、アプリケーションに対して、アプリ鍵の提供を低遅延で行う。本実施形態の方法を用いると、各ノードは、アプリケーションに対して提供すべきアプリ鍵を、アプリケーションからの要求を受ける前に事前に共有しておくことができる。これにより、ノードは、アプリケーションからの要求を受けると、アプリ鍵を即座にアプリケーションに提供できる。すなわち本実施形態の方法によって、アプリケーションへのアプリ鍵提供が低遅延で実行可能となる。

図４は、本実施形態におけるノード１００の機能構成例を示すブロック図である。ノード１００は、共有処理部１１０と、提供部１２０と、制御部１３０と、プラットフォーム部１４０と、記憶部１５０と、を備える。

プラットフォーム部１４０は、ノード１００の基本的なコンピュータシステムを管理するＯＳ（オペレーティングシステム）の機能、ネットワーク機能、およびセキュリティ機能等を提供する。

記憶部１５０は、暗号鍵を記憶する。記憶部１５０は、ファイルシステムまたはデータベースなどにより構成できる。また記憶部１５０は、共有先のノード１００（共有先ノード）ごとに、予め定められた基準量と、現在共有している暗号鍵の量（現在量）を示す情報を記憶する。暗号鍵の基準量と現在量とを対応づけた情報を、以下では鍵情報テーブルという。

基準量は、暗号鍵の量の基準となる量を表し、現在量との比較に用いられる。基準量は、例えば、共有される暗号鍵の最大量に相当する量として定めてもよい。基準量はこれに限られるものではなく、暗号鍵の量の基準となる量であればどのような情報であってもよい。例えば、暗号鍵の下限を表す量を基準量としてもよい。基準量は、共有先ノードごとに異なる値であってもよいし、一部または全部の共有先ノードで同じ値であってもよい。以下では基準量として最大量を用いた場合を例に説明する。

共有処理部１１０は、１以上の他のノード１００（外部装置の一例）との間で暗号鍵を共有する共有処理を行う。共有処理部１１０は、生成部１１１と、監視部１１２と、を備える。

生成部１１１は、暗号鍵を生成する。生成部１１１は、リンク鍵を生成する場合は例えば量子暗号を利用し、アプリ鍵を生成する場合は例えば乱数生成器を利用する。監視部１１２は、記憶部１５０に記憶された暗号鍵の減少量などを監視する。

制御部１３０は、ノード全体の制御を行う。例えば制御部１３０は、暗号鍵の共有制御手順（暗号鍵共有処理）、および、提供制御手順等を実行する。例えば制御部１３０は、現在量と基準量とを比較し、比較結果に基づいて、共有処理部１１０による暗号鍵の共有処理の継続（開始）または停止を制御する（暗号鍵共有処理）。制御部１３０による制御の詳細は後述する。

提供部１２０は、記憶部１５０に記憶された暗号鍵をアプリケーション２００に提供する。提供部１２０は、アプリケーション２００に提供した暗号鍵を記憶部１５０から削除してもよい。

共有処理部１１０、提供部１２０、制御部１３０、および、プラットフォーム部１４０は、例えば、ＣＰＵ（Central Processing Unit）などの処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Integrated Circuit）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。

記憶部１５０は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

次に、鍵情報テーブルの具体例について説明する。図５は、図２に示す各ノード１００の鍵情報テーブルの一例を示す図である。各ノード１００は、例えば、共有先ノードと、共有先ノードとの間で共有すべきアプリ鍵の最大量と、現在共有しているアプリ鍵の量（現在量）とを対応づけた鍵情報テーブルを記憶部１５０に記憶する。なお、記憶部１５０ａ〜１５０ｅは、それぞれノード１００ａ〜１００ｅが備える記憶部１５０を示す。以下ではアプリ鍵の鍵情報テーブルをアプリ鍵情報テーブルと称する。

図５のノード１００ａを例に、アプリ鍵情報テーブルについて説明する。図５に示すように、アプリ鍵情報テーブルは、「共有先」のノード（共有先ノード）ごとに「最大量」と「現在量」の情報を記憶する。「共有先」には、例えばノード１００の識別情報（ＩＤ）を設定する。図５のＡ〜Ｅは、例えばノード１００ａ〜ノード１００ｅの識別情報を表す。

アプリ鍵情報テーブルの「最大量」は、例えば、ノード１００ａが、その他のノード１００（共有先ノード：ノード１００ｂ、ノード１００ｃ、ノード１００ｄ、ノード１００ｅ）との間でどれだけの量のアプリ鍵を共有しておくことが望ましいか、を示す情報である。アプリ鍵の量は、例えば、アプリ鍵の数であってもよいし、共有しているアプリ鍵の全体サイズであってもよい。「最大量」の情報は、システム構築時、運用開始時、およびメンテナンス時などに、システム管理者によって設定されてもよい。

アプリ鍵情報テーブルの「現在量」は、ノード１００ａで現在保持されている、各「共有先ノード」との間で共有されているアプリ鍵の量を示す。「現在量」は、現在ノード１００ａで利用可能なアプリ鍵の量を監視することで取得される値である。新規にアプリ鍵を共有した場合には「現在量」が増加し、アプリケーション２００ａへのアプリ鍵提供等によって使用した場合は「現在量」が減少してよい。現在量の監視、および、監視して得られた現在量による鍵情報テーブルの更新は、例えば監視部１１２により実行される。

各ノード１００は、起動時に、アプリ鍵情報テーブルを参照し、「共有先ノード」ごとに設定されている「最大量」の分だけ、アプリ鍵を共有すべく、アプリ鍵の共有制御手順を実行してもよい。このようにすることで、各ノード１００は、アプリケーション２００からの接続を受けてから共有制御手順を実行する従来の方式に比べ、アプリケーション２００に対して低遅延でアプリ鍵を提供できるようになる。

なお、各ノード１００は、起動時だけでなく、任意のタイミングでアプリ鍵の共有制御手順を実行してよい。例えばノード１００は、定期的に各「共有先ノード」との「現在量」を参照して減少していることを検出した場合など、定期的なメンテナンスのタイミングで共有制御手順を実行してもよい。

図６は、本実施形態の暗号鍵共有処理の一例を示すシーケンス図である。なお図６には、アプリケーション２００ａおよび２００ｂも図示しているが、これらのアプリケーション２００は暗号鍵共有処理には関知しない。

ノード１００ａ、１００ｂ、１００ｃは、事前にリンク鍵を共有している（ステップＳ２０１、ステップＳ２０２）。ノード１００ａの制御部１３０は、アプリケーション２００からの要求などとは独立に、アプリ鍵の補充イベントを検出する（ステップＳ２０３）。

補充イベントは、ある共有先ノードとの間でアプリ鍵を共有すべきことを示すイベントである。制御部１３０は、共有先ノードの現在量と基準量とを比較することにより補充イベントを検出してもよい。制御部１３０は、補充イベントの検出結果に応じてアプリ鍵の共有の開始（継続）および停止などを制御してもよい。

例えば制御部１３０は、アプリ鍵情報テーブルを参照し、アプリ鍵の現在量の減少状況が所定の条件を満たす場合に、ある共有先ノード（ここではノード１００ｃ）との間で、アプリ鍵を共有すべきタイミングであることを検出する。所定の条件は、例えば以下のような条件である：
・「現在量」が「最大量」より小さい
・「最大量」と「現在量」との差が閾値（第１閾値）以上
・「最大量」と「現在量」の差と「最大量」との比が閾値（第２閾値）以下
・「現在量」の値が下限値以下

制御部１３０は、イベントを検出するとともに、「最大量」と「現在量」との差などから、共有すべきアプリ鍵の量をさらに決定してもよい。

制御部１３０は、補充イベントを検出した場合、アプリ鍵を共有すべき共有先ノードに対して、アプリ鍵を共有したい旨を示す情報（アプリ鍵共有制御メッセージなど）通知する（ステップＳ２０４）。この後、ノード１００ａの共有処理部１１０とノード１００ｃの共有処理部１１０との間でアプリ鍵を共有するための処理が実行される。この処理で実行されるプロトコル等は従来技術と同様であってもよい。例えば、図６のステップＳ２０５〜ステップＳ２１１は、図３のステップＳ１０６〜ステップＳ１１２と同様の手順で実行してよい。

なお上記説明では、アプリ鍵を共有すべきタイミングであることを検出したノード１００（図６の例ではノード１００ａ）が、アプリ鍵を生成し、生成したアプリ鍵をノード１００ｃまで転送した。アプリ鍵の共有方法はこれに限られるものではない。

例えば、共有するアプリ鍵の全部または一部を、ノード１００ｃが生成してノード１００ａまで転送させるように制御してもよい。このためには、例えば、ノード１００ａからノード１００ｃに対して送信するアプリ鍵共有制御メッセージに、いずれのノード１００がアプリ鍵を生成すべきかを決定する情報、または、それをネゴシエーションするための情報が含まれていてもよい。また、アプリ鍵共有制御メッセージに、アプリ鍵を生成すべき量に関する情報が含まれていてもよい。

アプリケーション２００が、アプリ鍵を用いてワンタイムパッドで通信を行う場合等、アプリ鍵の種別（鍵種別）を区別する場合がある。すなわち、アプリ鍵が、送信鍵（送信用アプリ鍵）であるか受信鍵（受信用アプリ鍵）であるかが区別される場合がある。送信用アプリ鍵は、情報の送信時に用いるアプリ鍵である。受信用アプリ鍵は、情報の受信時に用いるアプリ鍵である。

この場合、例えば、送信用アプリ鍵を生成するノード１００と、受信用アプリ鍵を生成するノード１００が、それぞれ特定されていてもよい。例えば、各ノード１００は、送信用アプリ鍵に関してのみ、アプリ鍵情報テーブルを参照してアプリ鍵を共有すべきタイミングを決定し、アプリ鍵を生成して共有するようにしてもよい。すなわちこの場合、送信用アプリ鍵はノード１００自身（例えばノード１００ａ）によって生成されて補充される。一方、受信用アプリ鍵は、共有先のノード１００（例えばノード１００ｃ）によって生成され、ノード１００（ノード１００ａ）が受信することによって補充される。

図７は、鍵種別（送信鍵と受信鍵）を区別する場合にノード１００ａの記憶部１５０に記憶されるアプリ鍵情報テーブルの例を示す図である。図７に示すように、この場合のアプリ鍵情報テーブルは、共有先ノードの鍵種別ごとに、現在量と最大量とを記憶する。

次に、ノード１００がアプリケーション２００にアプリ鍵を提供する際の手順（アプリ鍵の提供制御手順）について説明する。図８は、本実施形態のアプリ鍵の提供制御手順の一例を示すシーケンス図である。

ノード１００ａ、１００ｂ、１００ｃは、事前にリンク鍵を共有している（ステップＳ３０１、ステップＳ３０２）。アプリケーション２００ａは、暗号通信等を行うためにアプリ鍵が必要になると、ノード１００ａに対してアプリ鍵の要求（アプリ鍵要求）を通知する（ステップＳ３０３）。

アプリ鍵要求を受けたノード１００ａは、共有先ノードを特定する（ステップＳ３０４）。例えばノード１００ａは、アプリ鍵要求のメッセージ等から、アプリケーション２００ａが、アプリケーション２００ｂと通信したい旨を検出したとする。ノード１００ａは、例えばアプリケーション２００とノード１００との接続関係を定めた情報等を参照し、アプリケーション２００ｂがノード１００ｃと接続されていることを特定する。このようにしてノード１００ａは、アプリケーション２００ａに提供すべきアプリ鍵の共有先ノードがノード１００ｃであることを特定する。

図６の暗号鍵共有処理などにより、特定した共有先ノードとの間でアプリ鍵を既に共有していれば、ノード１００の提供部１２０は、共有済みのアプリ鍵をアプリケーション２００に提供することができる。すなわち、ノード１００ａの提供部１２０は、アプリ鍵をアプリケーション２００ａへ提供する（ステップＳ３０８）。ノード１００ｃは、アプリケーション２００ｂからの要求を受け（ステップＳ３０６）、アプリ鍵をアプリケーション２００ｂへ提供する（ステップＳ３０７）。

このように、ノード１００は、アプリ鍵要求を受けた後に乱数生成器によるアプリ鍵の生成処理、および、アプリ鍵をリンク鍵で暗号化して転送する処理などを行うことなく、即座にアプリケーション２００にアプリ鍵を提供できる。すなわち、ノード１００は、アプリ鍵の提供を低遅延で実行できる。

なお、ノード１００ａとノード１００ｃは、アプリ鍵の共有制御手順（図６）を行う必要はないが、単なる制御メッセージの交換（アプリ鍵提供制御）を、アプリケーション２００へアプリ鍵を提供する前に実施してもよい（図８のステップＳ３０５）。制御メッセージは、例えば、既にノード１００ａとノード１００ｃとの間で共有済みのアプリ鍵のうち、いずれのアプリ鍵を当該のアプリケーション２００ａに提供すべきかを決定および通知するために以下のような情報を含んでいてもよい：
・アプリ鍵の識別情報（ＩＤ）に関連する情報
・アプリケーション２００ａに提供する（アプリケーション２００ａが利用することを前提に割り当てる）アプリ鍵の決定方法の情報

ノード１００ａおよびノード１００ｃは、アプリケーション２００ａおよびアプリケーション２００ｃにアプリ鍵を提供した後、自身が記憶するアプリ鍵情報テーブルにおける「現在量」から、提供したアプリ鍵の分量に相当する値を減少させる。

なお、以上説明した鍵共有ネットワーク３０１では、ノード数が５であったが、ノード数は５に限られるものではない。ノード数は２以上の任意の数であってよい。ノード数が多い場合（例えば１００以上等）、各ノード１００が、他のすべてのノード１００との間でアプリ鍵情報テーブルを用いて事前にアプリ鍵を共有するように制御しておくのは、アプリ鍵の記憶容量の観点から望ましくない場合もある。このような場合、すべてのノード１００との間でアプリ鍵を事前に共有しておくのではなく、一部のノード１００との間でのみ、アプリ鍵を事前に共有できるように、アプリ鍵情報テーブルを利用してもよい。この場合、事前にアプリ鍵を共有していない共有先ノードとの間で共有すべきアプリ鍵が要求された場合は、従来技術と同様に、例えば図３に示す方法でアプリ鍵を共有すればよい。

（第２の実施形態）
第１の実施形態では、アプリ鍵情報テーブルにおける「最大量」などの基準量は、管理者等によって事前に設定されるものとした。第２の実施形態では、運用中に基準量を動的に変更させるように構成する。

図９は、第２の実施形態にかかるノード１００−２の構成の一例を示すブロック図である。図９に示すように、ノード１００−２は、共有処理部１１０と、提供部１２０と、制御部１３０−２と、プラットフォーム部１４０と、記憶部１５０と、を備える。

第２の実施形態では、制御部１３０−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかるノード１００のブロック図である図４と同様であるので、同一符号を付し、ここでの説明は省略する。

制御部１３０−２は、基準量を動的に変更する制御（共有量制御手順）の機能が追加される点が、第１の実施形態の制御部１３０と異なる。例えば制御部１３０−２は、アプリ鍵の現在量の減少頻度に応じて基準量を変更する。制御部１３０−２は、例えば「共有先ノード」ごとに、アプリ鍵の減少頻度を監視するように監視部１１２を制御する。アプリ鍵の減少頻度は、アプリ鍵が利用される頻度（利用頻度）に相当する。制御部１３０−２は、利用頻度（減少頻度）の高いアプリ鍵については、基準量としての「最大量」を増加させるように制御する。

基準量の制御方法はこれに限られるものではない。例えば、アプリケーションの個数、アプリケーションによる暗号鍵の要求量、記憶部１５０の記憶容量、および、記憶部１５０の空き容量のうち、少なくとも１つに応じて基準量を変更してもよい。

図１０および図１１は、最大量の変更処理の具体例を示す図である。ここでは、ノード１００−２ａとノード１００−２ｃの間で共有されるアプリ鍵は頻繁に減少する（利用される）とする。図１０の値９０１および値９０２は、ノード１００−２ａとノード１００−２ｃとの間で共有されるアプリ鍵の現在量が５００に減少した例を示している。減少した分のアプリ鍵は、例えば第１の実施形態の図６で説明した暗号鍵共有処理に従って補充される。

これに加え、第２の実施形態では、例えば、アプリ鍵の減少頻度の情報に応じて、図１１の値１００１および値１００２に示すように、ノード１００−２ａとノード１００−２ｃとの間で共有すべきアプリ鍵の「最大量」の情報を増加させる。

ノード１００−２の制御部１３０−２は、例えば共有先ノードごとに単位時間あたりのアプリ鍵の「現在量」の減少量を監視するように監視部１１２を制御し、減少量がある閾値（第３閾値）以上となった場合に、「最大量」を増加させるように制御してもよい。減少量の絶対値と閾値とを比較するのではなく、他のノード１００−２の減少量に対する相対的な変化に応じて「最大量」を変更してもよい。例えば制御部１３０−２は、「共有先ノード」ごとにアプリ鍵の「現在量」の減少量を監視するように監視部１１２を制御し、ある「共有先ノード」（例えばノード１００−２ａとする）の減少量が、他の「共有先ノード」の減少量と比較し、ある閾値（第４閾値）以上に多くなった場合に、該当共有先ノード（ノード１００−２ａ）との「最大量」を増加させるように制御してもよい。

これまでは、アプリ鍵の「最大量」を変化させる際に、アプリ鍵の「現在量」の変化量に基づく方法について説明した。アプリ鍵の「最大量」を変化させる際には、これ以外の値を参照してもよい。例えば、各ノード１００−２に接続されているアプリケーション２００の個数、および、各ノード１００−２で要求されているアプリ鍵の単位時間あたりの量またはサイズ、といった情報を各ノード１００−２が監視し、この情報を参照してもよい。

例えば、ノード１００−２ａにおいて、ノード１００−２ａに接続するアプリケーション２００であって、ノード１００−２ｃに接続したアプリケーション２００と通信するアプリケーション２００の個数が、２台から３台に変化したとする。このとき、ノード１００−２ａの制御部１３０−２は、ノード１００−２ｃとの間で共有するアプリ鍵の「最大量」を増加させるように制御してもよい。

ノード１００−２ｃに接続したアプリケーション２００と通信するアプリケーション２００であって、ノード１００−２ａに接続する、あるアプリケーション２００が、ノード１００−２ａに対して、要求するアプリ鍵の単位時間あたりの量を通知してもよい。このような場合であって、かつ、要求されるアプリ鍵の単位時間あたりの量が増加した場合、ノード１００−２ａの制御部１３０−２は、ノード１００−２ｃとの間で共有するアプリ鍵の「最大量」を増加させるように制御してもよい。

あるノード１００−２で事前に保持できるアプリ鍵の量の総量には、利用する記憶装置（記憶部１５０）の容量に依存する上限が存在する。このため、「共有先ノード」と事前に共有すべきアプリ鍵の「最大量」を無制限に増加させることはできない。従って、制御部１３０−２が、現在該当ノード１００−２で利用できる記憶部１５０の記憶容量または空き容量についても勘案して「最大量」を増加させる制御を実行してもよい。

制御部１３０−２は、ある共有先ノードとの間で共有すべきアプリ鍵の「最大量」を増加させた場合、別の共有先ノードとの間で共有すべきアプリ鍵の「最大量」は減少させてもよい。制御部１３０−２は、例えば、共有先ノードごとに単位時間あたりのアプリ鍵の「現在量」の減少量を監視するように監視部１１２を制御し、減少量がある閾値（第５閾値）以下である共有先ノードの「最大量」を減少させるように制御してもよい。

減少量の絶対値と閾値とを比較するのではなく、他のノード１００−２の減少量に対する相対的な変化に応じて「最大量」を変更してもよい。例えば制御部１３０−２は、「共有先ノード」ごとにアプリ鍵の「現在量」の減少量を監視するように監視部１１２を制御し、ある「共有先ノード」（例えばノード１００−２ａとする）の減少量が、他の「共有先ノード」の減少量と比較し、ある閾値（第６閾値）以上に少ない場合に、該当共有先ノード（ノード１００−２ａ）との「最大量」を減少させるように制御してもよい。

また制御部１３０−２は、「最大量」を減少させる共有先ノードを、現在の「最大量」の大きさをもとに決定してもよい。すなわち制御部１３０−２は、より大きな「最大量」を持つ共有先ノードの「最大量」を優先して減少させるようにしてもよい。

また制御部１３０−２は、最大量の減少と、最大量の増加と同時に実行してもよい。制御部１３０−２は、最大量を増加させると記憶容量が不足する場合に限って最大量の減少を行ってもよい。これにより、アプリ鍵を記憶するための記憶部１５０の有限な記憶容量を効率的に利用することができる。

次に、このように構成された第２の実施形態にかかるノード１００−２による共有量制御処理（共有量制御手順）について図１２を用いて説明する。図１２は、第２の実施形態における共有量制御処理の一例を示すシーケンス図である。

ノード１００−２ａ、１００−２ｂ、１００−２ｃは、事前にリンク鍵を共有している（ステップＳ４０１、ステップＳ４０２）。

ノード１００−２ａは、ノード１００−２ｃに対して、「最大量」を増加させる制御（アプリ鍵共有量制御）を行うことを通知する制御メッセージを送信する（ステップＳ４０３）。この制御メッセージは、独立してノード１００−２間で転送されてもよいし、例えば、図６に示した共有制御処理におけるアプリ鍵共有制御メッセージと一体として転送されてもよい。または、図８に示した、アプリ鍵提供制御手順における、アプリ鍵提供制御のメッセージと一体として転送されてもよい。

アプリ鍵共有量制御の制御メッセージは、増加させる最大量のサイズ、または、増加後の最大量のサイズに関する情報を少なくとも含む。

ノード１００−２ａとノード１００−２ｃとでは、利用可能な記憶容量の大きさが異なる場合がある。そのため、ノード１００−２ａが最大量の増加をノード１００−２ｃに要求しても、ノード１００−２ｃにおいては増加させることができない可能性もある。このため、アプリ鍵共有量制御の制御メッセージに対して、応答メッセージ（ノード１００−２ｃからノード１００−２ａへ）が必要となる場合がある。応答メッセージは、実際に最大量の増加を行ってよいか、増加させるとしたらそのサイズはどの程度か、に関する情報を含んでいてもよい。この応答メッセージの送信の後に、実際に最大量の変更を実施してもよい。

一方、図１０では、ノード１００−２ａがノード１００−２ｂとの間でも、アプリ鍵共有量制御の制御メッセージを交換する。この制御メッセージは、例えば、最大量の減少を通知するメッセージである。一般に、最大量を減少させるノード１００−２との間で同時にアプリ鍵を共有することはない。このため、最大量減少のための制御メッセージは、アプリ鍵共有制御のメッセージと一体として転送される必要はない。

また同様に、最大量減少のための制御メッセージは、アプリ鍵提供制御（図８等）の制御メッセージと一体として転送されることも少ないと考えられる。最大量減少のための制御メッセージには、減少させる最大量のサイズまたは減少後の最大量のサイズに関する情報が少なくとも含まれている。

なお、最大量を減少させることによって、現在量も減少させなければならないケースも考えられる。現在量を減少させることは、現在保持しているアプリ鍵を破棄（削除）することに相当する。この場合、現在保持しているアプリ鍵のうちいずれを破棄するか、に関する情報も、アプリ鍵共有量制御のメッセージに含めてもよい。例えば提供部１２０が、予め定められたルールに従って破棄するアプリ鍵を決定してもよい。例えば、アプリ鍵のうち、最も古くに共有されたアプリ鍵から削除する、アプリ鍵に付与された識別情報（ＩＤ）が最も若いアプリ鍵から順に削除する、および、ＩＤを指定して削除すべきアプリ鍵を決定する、等の方法がある。

このように、第２の実施形態にかかる通信装置では、基準量を動的に変更させることができる。

（第３の実施形態）
上記実施形態では、ノードはアプリ鍵情報テーブルを用いてアプリ鍵の現在量および最大量を保持するようにした。このような構成による効果の１つは、アプリケーションからの鍵要求に対して、即座に鍵を提供できることであった。また、副次的な効果として、複数のノードとの間で鍵を共有する状況において、有限である記憶装置の容量を有効に活用し、最も利用される可能性が高い鍵を保持蓄積するために活用することで、記憶容量の利用効率を向上させられる効果がある。

上記実施形態で述べたアプリ鍵に対する制御と同様の制御を、リンク鍵について実施してもよい。第３の実施形態にかかる通信装置は、アプリ鍵の代わりにリンク鍵に対して上記実施形態と同様の処理を実行する。

図１３は、第３の実施形態にかかるノード１００−３の構成の一例を示すブロック図である。図１３に示すように、ノード１００−３は、共有処理部１１０と、提供部１２０−３と、制御部１３０−３と、プラットフォーム部１４０と、記憶部１５０と、を備える。

第３の実施形態では、提供部１２０−３、および、制御部１３０−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかるノード１００のブロック図である図４と同様であるので、同一符号を付し、ここでの説明は省略する。

提供部１２０−３は、アプリ鍵の代わりにリンク鍵を暗号鍵として提供する点が、上記実施形態の提供部１２０と異なる。制御部１３０−３は、アプリ鍵の代わりにリンク鍵を暗号鍵として、共有制御手順（暗号鍵共有処理）、および、提供制御手順等を実行する。

なお本実施形態の記憶部１５０は、リンク鍵の鍵情報テーブルを記憶する。以下ではリンク鍵の鍵情報テーブルをリンク鍵情報テーブルと称する。図１４は、図１３に示す各ノード１００−３のリンク鍵情報テーブルの一例を示す図である。

図１５は、本実施形態の暗号鍵共有処理（共有制御手順）の一例を示すシーケンス図である。リンク鍵の共有制御手順は、量子暗号におけるリンク鍵の生成に相当する。このため制御部１３０−３は、常時、リンク鍵の生成と共有を実行し、現在量が最大量に達するまで、量子暗号によってリンク鍵を生成および共有するように共有処理部１１０を制御する（ステップＳ５０１）。

制御部１３０−３は、現在量が最大量に達した場合、リンク鍵の生成または記憶を停止してもよい。例えば制御部１３０−３は、量子暗号によるリンク鍵生成を停止する動作、または、量子暗号によるリンク鍵の生成は継続するが生成したリンク鍵を記憶せずに破棄する動作を行う。リンク鍵の生成または記憶を停止する場合、各ノード１００−３の制御部１３０−３は、リンク鍵共有の制御メッセージを交換する（ステップＳ５０２、ステップＳ５０３）。リンク鍵の生成を停止する場合、この制御メッセージは、例えばいずれの識別情報（ＩＤ）が振られたリンク鍵以降の鍵生成を停止するのか、に関する情報を含んでもよい。リンク鍵の記憶を停止する場合、この制御メッセージは、いずれのＩＤが振られたリンク鍵以降の鍵記憶を停止するのか、に関する情報を含んでもよいし、または、リンク鍵のＩＤごとに、鍵を記憶するか否かに関する情報を含んでもよい。

図１６は、本実施形態のリンク鍵の提供制御手順の一例を示すシーケンス図である。ノード１００−３は、アプリケーション２００からのリンク鍵の提供要求を受けると、要求されたリンク鍵をそのまま提供する。

ノード１００−３ａ、１００−３ｂは、事前にリンク鍵を共有している（ステップＳ６０１）。アプリケーション２００ａは、暗号通信等を行うためにリンク鍵が必要になると、ノード１００−３ａに対してリンク鍵の要求（リンク鍵要求）を通知する（ステップＳ６０２）。

リンク鍵要求を受けたノード１００−３ａは、必要に応じてリンク鍵提供制御の制御メッセージをノード１００−３ｂに送信する（ステップＳ６０３）。例えば該当アプリケーション２００に提供するリンク鍵を決定する必要がある場合は、リンク鍵を決定するための情報（例えば識別情報）などを含む制御メッセージを交換してもよい。

ノード１００−３ａは、要求されたリンク鍵をアプリケーション２００ａに提供する（ステップＳ６０４）。同様に、ノード１００−３ｂは、アプリケーション２００ｂからリンク鍵の提供要求を受信すると（ステップＳ６０５）、要求に応じてリンク鍵をアプリケーション２００ｂに提供する（ステップＳ６０６）。

さらに制御部１３０−３は、第２の実施形態と同様に、基準量を動的に変更する制御（共有量制御手順）を実行してもよい。例えば制御部１３０−３は、リンク鍵の現在の保有量（現在量）が最大量に達した場合に、第２の実施形態で述べた手法と同様の手法によって、リンク鍵についても最大量の増加または減少を行ってよい。

図１７は、共有量制御手順を実行した後のリンク鍵情報テーブルの一例を示す図である。テーブルの網掛け部分が、最大量が変更されたデータを示している。

例えば、図１７において、ノード１００−３ａは、複数のノード１００−３（ノード１００−３ｂとノード１００−３ｄ）との間でリンク鍵を共有している。

ノード１００−３ａは、例えばノード１００−３ｂとの間で共有するリンク鍵の方が、ノード１００−３ｄとの間で共有するリンク鍵よりも、減少頻度が高い場合、ノード１００−３ｂとの間で共有するリンク鍵の最大量を増加させてもよい。図１７では、ノード１００−３ｂとの間で共有するリンク鍵の最大量が１００から５００に増加された例が示されている。

ノード１００−３ａは、同時に、ノード１００−３ｄとの間で共有するリンク鍵の最大量を減少させてもよい。図１７では、ノード１００−３ｄとの間で共有するリンク鍵の最大量が３００から２００に減少された例が示されている。

図１８は、本実施形態のリンク鍵の共有量制御処理（共有量制御手順）の一例を示すシーケンス図である。

ノード１００−３ａ、１００−３ｂは、事前にリンク鍵を共有している（ステップＳ７０１）。

ノード１００−３ａは、ノード１００−３ｂに対して、「最大量」を増加させる制御（アプリ鍵共有量制御）を行うことを通知する制御メッセージを送信する（ステップＳ７０２）。ノード１００３−ｂは、必要に応じて応答メッセージをノード１００−３ａに送信する（ステップＳ７０３）。制御メッセージおよび応答メッセージに含まれる情報は第２の実施形態と同様でよい。

このように構成することで、ノード１００−３ａは、有限である記憶装置（記憶部１５０）の記憶容量の有効活用が図れる。また、アプリケーション２００からリンク鍵を要求されたが、該当するノード１００−３と共有しているリンク鍵の最大量が少なく蓄積している暗号鍵が少ない場合などに、十分な量のリンク鍵を提供するために、リンク鍵の生成を待つことによって遅延が増加するという事態を避けることができる。すなわち、十分な量のリンク鍵を低遅延で提供することができる。

また、図１４および図１７に示すリンク鍵情報テーブルは、リンク接続先のノード１００−３ごとに最大量と現在量を記憶した。図７と同様に、ノード１００−３ごとに、送信用リンク鍵と受信用リンク鍵とをそれぞれ区別してリンク鍵情報テーブルに記憶してもよい。図１９は、鍵種別を区別する場合にノード１００−３ａの記憶部１５０に記憶されるリンク鍵情報テーブルの例を示す図である。

制御部１３０−３は、単位時間あたりのリンク鍵（送信鍵または受信鍵）の「現在量」の減少量を監視するように監視部１１２を制御し、より単位時間あたりの減少量が大きい方の鍵の「最大量」を増加させるように制御してもよい。または、例えば、ノード１００−３ａの制御部１３０−３が、ノード１００−３ｂと共有する送信用リンク鍵と、ノード１００−３ｄと共有する受信用リンク鍵と、の単位時間あたりの減少量を比較し、いずれの「最大量」をより大きく設定するかを決定してもよい。なお、量子鍵配送技術によって共有される暗号鍵を送信用リンク鍵とするか受信用リンク鍵とするかを決定する方法としてはＱ３Ｐ（Quantum Point to Point Protocol）等の技術を利用してもよい。

（第４の実施形態）
ノードは、アプリ鍵とリンク鍵の両方の鍵情報テーブルを記憶してもよい。鍵情報テーブルは、アプリ鍵とリンク鍵とで別々であってもよいし、１つのテーブルに両方の鍵の情報を記憶してもよい。また、ノードは、アプリ鍵とリンク鍵とを別々に管理するように構成してもよい。

図２０は、このように構成した第４の実施形態におけるノード１００−４の機能構成例を示すブロック図である。ノード１００−４は、共有処理部１１０−４と、提供部１２０−４と、制御部１３０−４と、プラットフォーム部１４０と、記憶部１５０と、共有処理部１６０−４と、提供部１７０−４と、を備える。

第４の実施形態では、共有処理部１１０−４と提供部１２０−４と制御部１３０−４の機能、および、共有処理部１６０−４と提供部１７０−４を追加したことが第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかるノード１００のブロック図である図４と同様であるので、同一符号を付し、ここでの説明は省略する。

共有処理部１１０−４は、他のノード１００−４との間でアプリ鍵を共有する共有処理を行う。共有処理部１１０−４は、生成部１１１−４と、監視部１１２−４と、を備える。生成部１１１−４は、例えば乱数生成器を利用してアプリ鍵を生成する。監視部１１２−４は、記憶部１５０に記憶されたアプリ鍵の減少量などを監視する。

これに対し共有処理部１６０−４は、他のノード１００−４との間でリンク鍵を共有する共有処理を行う。共有処理部１６０−４は、生成部１６１−４と、監視部１６２−４と、を備える。生成部１６１−４は、例えば量子暗号を利用してリンク鍵を生成する。生成部１６１−４は、共有したリンク鍵を保持する機能を備えていてもよい。監視部１６２−４は、記憶部１５０に記憶されたリンク鍵の減少量などを監視する。

提供部１２０−４は、記憶部１５０に記憶されたアプリ鍵をアプリケーション２００に提供する。一方、提供部１７０−４は、記憶部１５０に記憶されたリンク鍵をアプリケーション２００に提供する。また提供部１７０−４は、アプリ鍵の暗号転送機能等に必要な、リンク間通信するための基本的な機能（リンク制御機能）を提供する。

制御部１３０−４は、共有処理部１１０−４、提供部１２０−４、共有処理部１６０−４、および、提供部１７０−４等の各部の動作を制御する。制御部１３０−４は、第２の実施形態と同様に、鍵情報テーブルの基準量を動的に変更させてもよい。

この場合、制御部１３０−４は、あるノード１００−４と共有するアプリ鍵と、別のノード１００−４と共有するリンク鍵と、の単位時間あたりの減少量を比較し、いずれの「最大量」をより大きく設定するかを決定してもよい。このように構成することで、有限である記憶装置（記憶部１５０）の記憶容量の有効活用が図れる。また、アプリケーション２００から暗号鍵（アプリ鍵またはリンク鍵）を要求されたが、該当するノード１００−４と共有している鍵の最大量が少なく蓄積している暗号鍵が少ない場合などに、十分な量の鍵を提供するために、リンク鍵の生成またはアプリ鍵の共有を待つことによって遅延が増加するという事態を避けることができる。すなわち、十分な量の要求された種別の暗号鍵を低遅延で提供することができる。

図２１は、アプリ鍵とリンク鍵の両方を保持する場合の鍵情報テーブルの一例を示す図である。例えば制御部１３０−４は、すべてのアプリ鍵の現在量が最大量に達しており、これ以上アプリ鍵の生成および暗号転送を行う必要がない場合、新たにアプリ鍵を生成して暗号転送する必要がないため、リンク鍵の生成や蓄積を停止させてもよい。

（変形例）
これまでは複数のノードが（例えば図２では５つ）含まれる通信システムについて説明した。通信システムに含まれるノードは２つ、すなわち一対であっても構わない。この場合、システム構成は図１のようになる。この構成において、アプリケーションに提供する暗号鍵として、上述のような、乱数生成器によって生成して共有するアプリ鍵を用いてもよいし、量子暗号によって生成されるリンク鍵を用いてもよい。アプリ鍵を用いる場合、アプリ鍵情報テーブルとリンク鍵情報テーブルを両方備えてもよいし、アプリ鍵情報テーブルのみを備えてもよい。リンク鍵を用いるシステムの場合、リンク鍵情報テーブルのみを備えればよい。

以上説明したとおり、第１から第４の実施形態によれば、暗号鍵の要求元（アプリケーションなど）への暗号鍵の提供を低遅延で実行可能となる。

次に、第１〜第４の実施形態にかかる通信装置のハードウェア構成について図２２を用いて説明する。図２２は、第１〜第４の実施形態にかかる通信装置のハードウェア構成例を示す説明図である。

第１〜第４の実施形態にかかる通信装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ（Random Access Memory）５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。

第１〜第４の実施形態にかかる通信装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。

第１〜第４の実施形態にかかる通信装置で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

さらに、第１〜第４の実施形態にかかる通信装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１〜第４の実施形態にかかる通信装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

第１〜第４の実施形態にかかる通信装置で実行されるプログラムは、コンピュータを上述した通信装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

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

１００ ノード
１１０ 共有処理部
１１１ 生成部
１１２ 監視部
１２０ 提供部
１３０ 制御部
１４０ プラットフォーム部
１５０ 記憶部
１６０ 共有処理部
２００ アプリケーション
３０１ 鍵共有ネットワーク
３０２ 暗号データ通信ネットワーク

Claims (11)

1. １以上の外部装置との間で情報の送信時に用いる送信用暗号鍵と、情報の受信時に用いる受信用暗号鍵とを共有する共有処理部と、
   記憶部に記憶された前記送信用暗号鍵の量を表す第１現在量と、予め設定された第１最大量とを比較し、比較結果に基づいて、前記共有処理部による前記送信用暗号鍵の共有処理の継続または停止を制御し、前記記憶部に記憶された前記受信用暗号鍵の量を表す第２現在量と、予め設定された第２最大量とを比較し、比較結果に基づいて、前記共有処理部による前記受信用暗号鍵の共有処理の継続または停止を制御する制御部と、
   を備える通信装置。
2. 前記制御部は、前記第１現在量が前記第１最大量より小さい場合に、前記送信用暗号鍵の前記共有処理を継続し、前記第１現在量が前記第１最大量以上の場合に、前記送信用暗号鍵の前記共有処理を停止し、前記第２現在量が前記第２最大量より小さい場合に、前記受信用暗号鍵の前記共有処理を継続し、前記第２現在量が前記第２最大量以上の場合に、前記受信用暗号鍵の前記共有処理を停止する、
   請求項１に記載の通信装置。
3. 記憶された前記送信用暗号鍵および前記受信用暗号鍵を１以上のアプリケーションに提供し、提供した前記送信用暗号鍵および前記受信用暗号鍵を前記記憶部から削除する提供部をさらに備える、
   請求項１に記載の通信装置。
4. 前記記憶部は、前記外部装置ごとに前記送信用暗号鍵および前記受信用暗号鍵を記憶し、
   前記制御部は、前記外部装置ごとに、前記第１現在量と前記第１最大量とを比較し、前記第２現在量と前記第２最大量とを比較し、比較結果に基づいて、前記共有処理部による前記送信用暗号鍵および前記受信用暗号鍵の共有処理の継続または停止を制御する、
   請求項１に記載の通信装置。
5. 前記共有処理部は、前記外部装置のうち第１外部装置との間で第１送信用暗号鍵および第１受信用暗号鍵を共有し、前記第１送信用暗号鍵および第１受信用暗号鍵によって暗号化した第２送信用暗号鍵および第２受信用暗号鍵を、前記外部装置のうち第２外部装置に前記第１外部装置を介して転送することにより、前記第２外部装置との間で前記第２送信用暗号鍵および前記第２受信用暗号鍵を共有し、
   前記制御部は、前記共有処理部による、前記第１送信用暗号鍵、前記第１受信用暗号鍵、前記第２送信用暗号鍵および前記第２受信用暗号鍵の少なくとも１つの共有処理の継続または停止を制御する、
   請求項１に記載の通信装置。
6. 前記共有処理部は、量子鍵配送により前記外部装置との間で前記送信用暗号鍵および前記受信用暗号鍵を共有する、
   請求項１に記載の通信装置。
7. 前記記憶部をさらに備える、
   請求項１に記載の通信装置。
8. 前記第１最大量および前記第２最大量は、前記外部装置との間で共通の値が用いられる、
   請求項１に記載の通信装置。
9. １以上の外部装置との間で情報の送信時に用いる送信用暗号鍵と、情報の受信時に用いる受信用暗号鍵とを共有する共有処理ステップと、
   記憶部に記憶された前記送信用暗号鍵の量を表す第１現在量と、予め設定された第１最大量とを比較し、比較結果に基づいて、前記送信用暗号鍵の共有処理の継続または停止を制御し、前記記憶部に記憶された前記受信用暗号鍵の量を表す第２現在量と、予め設定された第２最大量とを比較し、比較結果に基づいて、前記受信用暗号鍵の共有処理の継続または停止を制御する制御ステップと、
   を含む通信方法。
10. コンピュータを、
    １以上の外部装置との間で情報の送信時に用いる送信用暗号鍵と、情報の受信時に用いる受信用暗号鍵とを共有する共有処理部と、
    記憶部に記憶された前記送信用暗号鍵の量を表す第１現在量と、予め設定された第１最大量とを比較し、比較結果に基づいて、前記共有処理部による前記送信用暗号鍵の共有処理の継続または停止を制御し、前記記憶部に記憶された前記受信用暗号鍵の量を表す第２現在量と、予め設定された第２最大量とを比較し、比較結果に基づいて、前記共有処理部による前記受信用暗号鍵の共有処理の継続または停止を制御する制御部、
    として機能させるためのプログラム。
11. 複数の通信装置を備える通信システムであって、
    前記通信装置のそれぞれは、
    １以上の他の前記通信装置との間で情報の送信時に用いる送信用暗号鍵と、情報の受信時に用いる受信用暗号鍵とを共有する共有処理部と、
    記憶部に記憶された前記送信用暗号鍵の量を表す第１現在量と、予め設定された第１最大量とを比較し、比較結果に基づいて、前記共有処理部による前記送信用暗号鍵の共有処理の継続または停止を制御し、前記記憶部に記憶された前記受信用暗号鍵の量を表す第２現在量と、予め設定された第２最大量とを比較し、比較結果に基づいて、前記共有処理部による前記受信用暗号鍵の共有処理の継続または停止を制御する制御部と、
    を備える通信システム。

Images