JP6192998B2

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

Info

Publication number: JP6192998B2
Application number: JP2013122410A
Authority: JP
Inventors: 佳道谷澤; 英昭佐藤; 莉里香高橋; 川村　信一; 信一川村; 村井　信哉; 信哉村井
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2013-06-11
Filing date: 2013-06-11
Publication date: 2017-09-06
Anticipated expiration: 2033-06-11
Also published as: US9356780B2; US20140365774A1; JP2014241464A

Description

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

鍵生成・共有システムには、２つのネットワーク（鍵共有ネットワーク、アプリケーションネットワーク）が存在する。鍵共有ネットワークは、複数のリンクによって相互に接続され、ネットワーク化された複数のノードから構成される。各ノードは、リンクによって接続された対向ノードとの間で乱数を生成および共有する機能と、生成および共有した乱数を暗号鍵（以下、リンク鍵）として利用して、リンク上で暗号通信を行う機能とを備える。また、ノードのうちの幾つかは、リンクとは独立に乱数である暗号鍵（以下、アプリケーション鍵）を生成する機能と、別のノードに対してリンクを介してアプリケーション鍵を送信する機能を備える。

アプリケーションは、ノードから、アプリケーション鍵を取得し、取得したアプリケーション鍵を暗号鍵として利用して、別のアプリケーションとの間で暗号データ通信を行う機能を備える。このときの暗号データ通信は、インターネット等の鍵共有ネットワークとは異なるネットワーク（アプリケーションネットワーク）によって実現されてよい。また、ノードとアプリケーションは、一体として実現されてもよい。ノードとアプリケーションを独立した端末として構成し、その間でアプリケーション鍵を送受信するようにしてもよい。

ノードにおいて、リンクによって接続された対向ノードとの間で乱数（リンク鍵）を生成および共有する機能は、例えば、一般に量子暗号または量子鍵配送（ＱＫＤ（Quantum Key Distribution））と呼ばれる技術によっても実現できる。

特開２００８−１５４０１９号公報米国特許第７，６４６，８７３号明細書

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 Kollmitzer C., Pivk M. （Eds.）, Applied Quantum Cryptography, Lect. Notes Phys. 797 （Springer, Berlin Heidelberg 2010）, p155-p168, DOI 10.1007/978-3-642-04831-9

鍵生成・共有システムにおいて、最も重要なリソースの１つは鍵である。従って、複数のアプリケーションが接続するノードにおいて、アプリケーション鍵を各アプリケーションに割り当てる方式（鍵割り当て方式）が重要になる。例えば、システム運用中にアプリケーションが要求する量（鍵要求レート）を満たす鍵割り当てが実現できなくなるような場合に適切に対処する必要がある。

実施形態の通信装置は、記憶部と、決定部と、を備える。記憶部は、暗号鍵を利用する１以上のアプリケーションごとに、優先度と、アプリケーションが要求する暗号鍵の量を表す第１要求量と、を記憶する。決定部は、アプリケーションに割り当てる暗号鍵の量の合計である第１合計値が、割り当て可能な暗号鍵の量の合計値である第２合計値以下となり、かつ、優先度が高いアプリケーションを優先して第１要求量の暗号鍵を割り当てるように、アプリケーションそれぞれに割り当てる暗号鍵の量を決定する。

本実施形態にかかる通信システムのネットワーク構成図。本実施形態におけるノードの構成例を示すブロック図。アプリケーション関連情報の構成例を示す図。本実施形態における鍵割当処理のフローチャート。通知メッセージが送信される様子を示す図。変形例におけるアプリケーション関連情報の構成例を示す図。本変形例における鍵割当処理のフローチャート。通知メッセージが送信される様子を示す図。本実施形態にかかる通信装置のハードウェア構成図。

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

アプリケーションに対するアプリケーション鍵の割り当て方式ではないが、リンク鍵の割り当て方式として以下のような方式が知られている
（Ｍ１）送信鍵バッファおよび受信鍵バッファに対するリンク鍵の割り当て方式：現在の蓄積量が少ないバッファに優先的に割り当てる。
（Ｍ２）アプリケーションに対するリンク鍵の割り当て方式：ノードに予めアプリケーションごとの鍵要求レートを設定しておき、この鍵要求レートに基づいて、リンク鍵をアプリケーションに割り当てる。

しかし、これらの従来技術では、システム運用中の新たなアプリケーションの追加、および、要求されるアプリケーション鍵の量（鍵要求レート）の変化などにより、複数のアプリケーションが要求する鍵レートを満たす鍵割り当てが実現できなくなるような事態への対応方法が考慮されていない。

本実施形態の通信装置は、ノードに対して複数のアプリケーションが接続する鍵生成・共有システムにおいて、複数のアプリケーションが要求する鍵レートを満たす鍵割り当てが実現できない場合には、アプリケーションの優先度を考慮して鍵を割り当てる。例えば、本実施形態では、重要なアプリケーションの要求する鍵レートを優先的に満たすように制御する優先度考慮型のアプリケーション鍵の割り当て方式を実現する。

このように、本実施形態は、ノードがアプリケーションに対してアプリケーション鍵を割り当てる方法（特定のアプリケーションが専用に利用できるようにするため、ノードにおいて、あるアプリケーション鍵をそのアプリケーションのために事前に確保する方法）に関する。

図１は、本実施形態にかかる通信システムのネットワーク構成例を示す図である。通信システムは、鍵共有ネットワーク３０１と、アプリケーションネットワーク３０２と、プライベートネットワーク３０３ａ、３０３ｂと、を含む。また、通信システムは、通信装置としてのノード１００ａ〜１００ｃと、アプリケーション２００ａ〜２００ｆと、を含む。

ノード１００ａ〜１００ｃを区別する必要がない場合は、単にノード１００という場合がある。アプリケーション２００ａ〜２００ｆを区別する必要がない場合は、単にアプリケーション２００という場合がある。ノード１００の個数は３に限られるものではない。また、アプリケーション２００の個数は６に限られるものではない。図１は、ノード１００とアプリケーション２００が独立に実現される場合の一例である。

プライベートネットワーク３０３ａ、３０３ｂは、あるノード１００と、このノード１００がアプリケーション鍵を提供するアプリケーション２００とを接続するためのネットワークである。

ノード１００ａ〜１００ｃは、上述のように、対向ノードとの間で乱数を生成して共有する機能と、生成した乱数をリンク鍵として利用して、リンク上で暗号通信を行う機能とを備える。

ノード１００は、リンクとは独立に乱数を生成する機能と、別のノードに対して生成した乱数を送信する機能とを備えてもよい。

図２は、本実施形態におけるノード１００の構成例を示すブロック図である。ノード１００は、プラットフォーム部１０１と、リンク鍵共有部１０２と、アプリ鍵共有部１０３と、鍵記憶部１０４と、提供部１０５と、アプリ情報記憶部１０６と、制御部１０７と、決定部１０８と、通知部１０９と、を備える。

プラットフォーム部１０１は、ノード１００を実現するコンピュータのオペレーティングシステムとして、基本的なプロセス管理機能、ネットワーク機能、セキュリティ機能、および、データ蓄積機能等を実現する。

リンク鍵共有部１０２は、直接接続される他のノード１００との間で量子鍵配送技術等を用いてリンク鍵を共有する。アプリ鍵共有部１０３は、他のノード１００（直接接続されるノードであっても直接接続されないノードであっても良い）との間で、アプリケーション鍵を交換して共有する。アプリ鍵共有部１０３は、アプリケーション鍵の交換のために必要な制御等も行う。

鍵記憶部１０４は、リンク鍵やアプリケーション鍵を保持する。提供部１０５は、アプリケーション２００との間の通信インタフェースである。提供部１０５は、例えばアプリケーション２００からの通信開始要求の処理等を行い、アプリケーション鍵要求に対してアプリケーション鍵を提供する。

アプリ情報記憶部１０６は、アプリケーション関連情報を記憶する。アプリ情報記憶部１０６は、例えば、以下の（Ａ１）および（Ａ２）のような情報を「アプリケーション関連情報」として、アプリケーション２００（の識別情報）と関連付けて保持する。

（Ａ１）アプリケーション２００の鍵の要求量（鍵要求レート）：要求量は、例えば、１００Ｋｂｐｓといったスループットを示す形式や、５０ＫＢｙｔｅ／３分、といった一定時間単位で必要な鍵量を示す形式、および、１０ＭＢｙｔｅといったトータルで必要な鍵量を示す形式等により表される。これらの情報は、アプリケーション２００がノード１００に接続する際にノード１００に対して送信するメッセージの中に含まれていてもよい。ノード１００は、メッセージに含まれる情報をもとにして鍵要求レートを設定してもよい。または、ノード１００またはシステムの管理者が、各アプリケーション２００の鍵要求レートをノード１００に対して予め設定しておいてもよい。また、いずれの方法を用いる場合であっても、システム運用中に鍵要求レートの値を変更することができてもよい。なお、アプリケーション２００の鍵要求レートは、いわゆる鍵要求レートの他に、この値を下回ることは許容できないことを示す最低鍵要求レート、等の複数の種類が存在してもよい。

（Ａ２）アプリケーション２００の優先度：優先度は、例えば数値で表され、その大小によって、そのアプリケーション２００への鍵割り当てがシステムにおいてどの程度重要で優先すべきかを示す。例えば、値が小さい方が優先度が高く、大きいほうが優先度が低くなるように構成してもよいし、この逆でもよい。優先度の情報は、アプリケーション２００がノード１００に接続する際にノード１００に対して送信するメッセージの中に含まれていてもよい。ノード１００は、メッセージに含まれる情報をもとにして優先度を設定してもよい。または、ノード１００またはシステムの管理者が、各アプリケーション２００の優先度をノード１００に対して予め設定しておいてもよい。また、いずれの方法を用いる場合であっても、システム運用中にこの優先度の値を変更することができてもよい。

図３は、アプリケーション関連情報の構成例を示す図である。図３に示すように、アプリケーション関連情報は、アプリＩＤと、優先度（Ｐ_ｉ）と、鍵要求レート（Ｒ_ｉ）と、鍵割当レート（Ａ_ｉ）と、を含む。

アプリＩＤは、アプリケーション２００を識別する情報である。アプリＩＤは、例えば現在接続しており、かつ通信を行っているアプリケーション２００を識別する情報である。形式は一意であればなんでもよく、例えば図３に示すようにアプリケーション２００が接続に利用している送信元のＩＰアドレスおよびポート等が利用可能である。

優先度（Ｐ_ｉ）および鍵要求レート（Ｒ_ｉ）は上述の通りである。鍵割当レートＡ_ｉは、現在アプリケーション２００に実際に割り当てられているアプリケーション鍵の量（鍵レート）を示す。

これらの情報は、常に変更しうる。また、新しくアプリケーション２００が追加（接続）されると、アプリケーション関連情報のエントリが一行新たに追加される（例えば図３のアプリケーション関連情報３５１）。

アプリ情報記憶部１０６は、この他に、割り当て可能なアプリケーション鍵の量の合計値（第２合計値）である鍵レート総量Ｔを記憶してもよい。鍵レート総量Ｔは、例えば、アプリケーション２００の組ごとに保持してもよい。

アプリケーション２００の組とは、同じノード１００との間で共有したアプリケーション鍵を利用できる１以上のアプリケーション２００である。ノード１００は、複数のノード１００との間でアプリケーション鍵を共有する。よって、アプリケーション２００は、暗号通信の相手となるアプリケーションが接続しているノードが異なる場合、同じアプリケーション鍵を割り当てられ利用することができない。同じアプリケーション鍵を割り当てて利用可能であるアプリケーション２００の組とは、ある特定のノード１００ａに接続しており、かつ、暗号通信の相手となるアプリケーション２００が、ある特定のノード１００ｃに接続しているようなアプリケーションの集合を指す。なお図３で示しているのは、全て同じアプリケーション鍵を利用できるアプリケーション２００の組である。ノード１００が、異なるアプリケーション鍵を利用する（すなわち、異なるノードとの間で共有したアプリケーション鍵を割り当てて利用する）アプリケーション２００の組についても同様の情報（すなわち鍵レート総量とアプリケーション関連情報）を保持していてもよい。

図２に戻り、決定部１０８は、アプリ情報記憶部１０６が保持するアプリケーション関連情報等を参照し、後述のアルゴリズムを実行することによって、優先度を考慮した鍵割り当て方式（ポリシー）を決定する。決定した鍵割り当て方式は、制御部１０７に伝えられる。

制御部１０７は、ノード１００全体を制御する。制御部１０７は、例えば、決定部１０８が決定した割り当て方式にしたがって、アプリ鍵共有部１０３が共有したアプリケーション鍵を各ノード１００に対して実際に割り当てる処理を行う。

通知部１０９は、決定部１０８が決定した割り当て方式に従った場合に、鍵割り当て量が変更されるアプリケーション２００に対し、鍵割り当て状態（鍵割り当て量）が変化したことを示す通知メッセージ（鍵割当状態変化通知）を送信する。

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

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

次に、このように構成された本実施形態にかかるノード１００による鍵割当処理について図４を用いて説明する。図４は、本実施形態における鍵割当処理の一例を示すフローチャートである。図４は、本実施形態の鍵割り当てアルゴリズムを示している。このアルゴリズムが、アプリケーション２００が新たに追加されたり、アプリケーション２００の優先度および鍵要求レートの情報が変化したり、さらに、割り当て可能な鍵レート総量Ｔが一定以上変化したりした場合に実行される。

決定部１０８は、優先度Ｐ_ｉが高い順番にアプリケーション２００を並び替える（ステップＳ１０１）。決定部１０８は、優先度Ｐ_ｉが高いｋ個（１≦ｋ≦Ｎ、Ｎはアプリケーションの総数）のアプリケーションについて、以下の（１）式を満たす最大のｋを算出する（ステップＳ１０２）。

決定部１０８は、ｋ個に含まれるアプリケーション２００の鍵割当レートを、アプリケーション２００それぞれの鍵要求レートに決定する（ステップＳ１０３）。決定部１０８は、ｋ個に含まれないアプリケーション２００の鍵割当レートを、ゼロまたは鍵レート残量に決定する（ステップＳ１０４）。鍵レート残量とは、鍵レート総量Ｔからｋ個のアプリケーション２００の鍵要求レートの合計値を減算した値である。

このように、優先度の高いアプリケーション２００から順に鍵要求レートが合計される。合計値が鍵レート総量Ｔ以下の値に収まるアプリケーション２００の鍵割当レートは、鍵要求レートの値そのものとなる。合計値が鍵レート総量Ｔを超えるアプリケーション２００への鍵割当レートは、ゼロまたは鍵レート残量となる。

通知部１０９は、鍵割当レートが変更となったアプリケーション２００に対して、鍵割当レートが変更されたことを示す通知メッセージを送信する（ステップＳ１０５）。

なお、新たに追加されたアプリケーション２００、および、優先度や鍵要求レートが変化したアプリケーション２００に対しては、常に通知メッセージが送信される。また、このようなアプリケーション２００に対しても、追加直後（または変更直後）から、鍵割当レートがゼロとなる場合もある。

なお、図３は、事前に４つのアプリケーション２００が接続して動作中であったノード１００に対し、優先度３のアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）が追加された例を示している。この場合、新しく追加されたアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）に鍵割当レート２０Ｋｂｐｓを優先して確保したことにより、動作中であった優先度１０のアプリケーション２００（アプリＩＤ：１０．０．０．１０５：８７６７）は、鍵割当レートが１０Ｋｂｐｓから０へと変化する。このため、この２つのアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１、アプリＩＤ：１０．０．０．１０５：８７６７）に対して通知メッセージが送信される。

図５は、通知メッセージが送信される様子を示す図である。図５の５個のアプリケーション２００は、図３の５個のアプリＩＤのアプリケーション２００にそれぞれ対応する。最下部のアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）が追加されると、上述のように、２番目の（優先度１０の）アプリケーション２００（アプリＩＤ：１０．０．０．１０５：８７６７）、および、追加されたアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）に対して通知メッセージが送信される。

（変形例）
次に図６および図７を用いて、他の鍵割り当て方法について説明する。図６は、変形例におけるアプリケーション関連情報の構成例を示す図である。

図３との違いは、最低鍵要求レート（Ｍ_ｉ）が追加されている点である。最低鍵要求レートは、そのアプリケーション２００の鍵要求レート（Ｒ_ｉ）が満たされない場合であっても、満たされることをアプリケーション２００が要求する鍵レートである。最低鍵要求レートの値は、鍵要求レートの値以下である。

図７は、本変形例における鍵割当処理の一例を示すフローチャートである。図７に示す鍵割り当てアルゴリズムが、アプリケーション２００が新たに追加されたり、アプリケーション２００の優先度や鍵要求レートの情報が変化したり、さらに、割り当て可能な鍵レート総量Ｔが一定以上変化したりした場合に実行される。

決定部１０８は、優先度Ｐ_ｉが高い順番にアプリケーション２００を並び替える（ステップＳ２０１）。決定部１０８は、全てのアプリケーション２００の鍵要求レートの合計ＴＲを算出する（ステップＳ２０２）。決定部１０８は、全てのアプリケーション２００の最低鍵要求レートの合計ＴＭを算出する（ステップＳ２０３）。決定部１０８は、割り当て可能な鍵レート総量Ｔを算出する（ステップＳ２０４）。

決定部１０８は、ステップＳ２０２〜ステップＳ２０４の算出結果に基づいて、以下のように、各アプリケーション２００の鍵割当レートを設定する。

決定部１０８は、ＴＲがＴ以下であるか否かを判断する（ステップＳ２０５）。ＴＲがＴ以下である場合（ステップＳ２０５：Ｙｅｓ）、全てのアプリケーション２００の鍵要求レートを満たすことが可能であるため、決定部１０８は、全てのアプリケーション２００の鍵割当レートをその鍵要求レートとする（ステップＳ２０６）。

ＴＲがＴより大きい場合（ステップＳ２０５：Ｎｏ）、決定部１０８は、ＴＭがＴより大きいか否かを判断する（ステップＳ２０７）。ＴＭがＴより大きい場合（ステップＳ２０７：Ｙｅｓ）、全てのアプリケーション２００の最低鍵要求レートすら満たすことができないことになる。この場合、決定部１０８は、最低鍵要求レートを鍵要求レートの代わりに用いて、図４に示すアルゴリズムを実行する（ステップＳ２０８）。これにより、決定部１０８は、全てのアプリケーション２００に対して最低鍵要求レートと一致する鍵割当レートを割り当てる、または、ゼロもしくは鍵レート総量Ｔから直前までの最低鍵要求レートの合計値を引いたもの（鍵レート残量）となる鍵割当レートを割り当てる。

ＴＭがＴ以下である場合（ステップＳ２０７：Ｎｏ）、決定部１０８は、優先度Ｐ_ｉが高いｋ個（１≦ｋ≦Ｎ）のアプリケーション２００について、以下の（２）式を満たす最大のｋを算出する（ステップＳ２０９）。ここで、Ｘ_ｉはアプリケーション２００がｋ個に含まれるときはＲ_ｉであり、アプリケーション２００がｋ個に含まれないときはＭｉである。

決定部１０８は、ｋ個に含まれるアプリケーション２００の鍵割当レートを、アプリケーション２００それぞれの鍵要求レートに決定する（ステップＳ２１０）。決定部１０８は、ｋ個に含まれないアプリケーション２００の鍵割当レートを、最低鍵要求レートまたは鍵レート残量に決定する（ステップＳ２１１）。

通知部１０９は、鍵割当レートが変更となったアプリケーション２００に対して、鍵割当レートが変更されたことを示す通知メッセージを送信する（ステップＳ２１２）。

図６の例は、事前に４つのアプリケーション２００が接続して動作中であったノード１００に対し、優先度３のアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）が追加されたところを示している（アプリケーション関連情報６５１）。この場合、新しく追加されたアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）に鍵割当レート２０Ｋｂｐｓが優先して確保される。この結果、優先度１０のアプリケーション２００（アプリＩＤ：１０．０．０．１０５：８７６７）は、鍵割当レートが１０Ｋｂｐｓから最低鍵要求レートである５Ｋｂｐｓへと変化する。次に低い優先度を持つ優先度５のアプリケーション２００（アプリＩＤ：１０．０．０．１０３：７１７０）は、鍵割当レートが２０Ｋｂｐｓから１５Ｋｂｐｓへと変化している。このため、追加されたアプリケーション２００を含むこれら３つのアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１、アプリＩＤ：１０．０．０．１０５：８７６７、アプリＩＤ：１０．０．０．１０３：７１７０）に対して通知メッセージが送信される。

図８は、通知メッセージが送信される様子を示す図である。図８の５個のアプリケーション２００は、図６の５個のアプリＩＤのアプリケーション２００にそれぞれ対応する。最下部のアプリケーション２００（アプリＩＤ：１０．０．０．１０８：９２０１）が追加されると、２番目の（優先度１０の）アプリケーション２００（アプリＩＤ：１０．０．０．１０５：８７６７）、３番目の（優先度５の）アプリケーション２００、および、追加されたアプリケーション２００（アプリＩＤ：１０．０．０．１０３：７１７０）に対して通知メッセージが送信される。

上述のように、優先度が高いアプリケーション２００の追加によって、優先度が低いアプリケーション２００は鍵要求レートを満たされなくなることがある。アプリケーション２００はこの状態を、ノード１００からの通知メッセージの受信によって把握する。以下では、この通知メッセージを受信した際に可能なアプリケーション２００の動作の一例（（Ｂ１）〜（Ｂ５））を説明する。

（Ｂ１）何もしない：アプリケーション２００は特別何らかの対応が必須となる訳ではない。アプリケーション鍵に関して鍵要求レートを下回ったことから、アプリケーション２００がノード１００に対してアプリケーション鍵の取得要求を行ってから、実際にアプリケーション鍵を受信するまでに、より長い時間を要するようになるかもしれない。そのため、アプリケーション２００におけるデータの送受信が遅延する可能性がある。ただし、このような時間的な遅延を気にしないアプリケーション２００（時間的に余裕のあるバッチ処理等）もあるため、このような「何もしない」という選択肢を取ってもよい。

（Ｂ２）アプリケーション２００を終了する：ノード１００に要求していた鍵要求レート、または、最低鍵要求レートが満たされなくなり、アプリケーション２００の実行開始時に期待していたデータスループットまたはセキュリティ（またはその両方）が今後満たされないことが明らかとなった時点で、アプリケーション２００はその実行を終了してもよい。

（Ｂ３）アプリケーション２００の実行形態を変更する：鍵割当レートが低下する場合、通信データ量を低減させることができれば、アプリケーション２００の実行そのものには影響を生じない可能性がある。例えば、リアルタイム映像伝送等の場合、使用する符号化方式および圧縮率等のパラメータを変更または調整する。これにより、例えば、ある程度の映像品質を犠牲にした上で、鍵割当レート低下前と同様のアプリケーション２００を実行することも可能となる。

（Ｂ４）暗号方式を変更する：鍵割当レートが低下する場合であっても、鍵の使用量（すなわち、通信データ量と、そのために使用する鍵量の比率）を変更すれば、通信データ量そのものは維持できる可能性がある。例えば、暗号方式としてＯＴＰ（One Time Pad）を使っていたアプリケーション２００が、古典暗号技術を組み合わせた暗号方式（例えば、１０２４バイトごとに１２８バイトの鍵を使う暗号方式）に切り替えた場合、鍵の使用量はＯＴＰ使用時に比べ、この場合では１／８に減少する。ただしこの場合、厳密な意味での安全性は、変更前に比べて低下する。

（Ｂ５）量子鍵配送に依存しない暗号（古典暗号）に切り替える：鍵割当レートが低下した際、ノード１００から受け取るアプリケーション鍵を使わず、古典暗号での通信を行うという方法も可能である。古典暗号だけを使うのであれば、鍵割当レートがゼロであっても（ネットワーク帯域や処理速度によって律速された上で）任意のスループットで暗号データ通信を行うことが可能となる。

次に、本実施形態が適用されうるユースケース（適用シナリオ）について説明する。本実施形態は、複数のアプリケーション２００が接続されるノード１００において、アプリケーション２００の優先度に応じて鍵割り当てを行うアプリケーション２００を決定する。この技術は、例えば以下の（Ｃ１）〜（Ｃ３）のようなユースケース（シナリオ）にて利用される。

（Ｃ１）権限が異なる複数のユーザのアプリケーション２００が同一のノード１００で動作する：より強い権限を持つユーザのアプリケーション２００には高い優先度を割り当てる。これによって、アプリケーション２００を所有するユーザの権限に対応するアプリケーション鍵の割り当てが可能となる。

（Ｃ２）アプリケーション２００の種類によって優先度が異なる：例えば、映像中継アプリケーションと、機密データファイルを転送するアプリケーションと、を考える。この場合、データそのものに冗長性がある映像中継データよりも、機密データファイルのデータをより厳密に守りたいという要求が考えられる。このような状況において、機密データファイルを転送するアプリケーションにより高い優先度を与えることが可能である。映像中継アプリケーションにおいては、映像のクオリティまたはセキュリティ安全性面等で、一部妥協をすることによって、アプリケーション２００を継続することも可能である。

（Ｃ３）鍵生成・共有システムをリモート管理・監視するためのアプリケーション２００を優先する：システムのリモート管理・監視のためのソフトウェアも本実施形態におけるアプリケーション２００として実現可能である。このとき、これらのリモート管理・監視アプリケーションのセキュリティおよび動作品質は、一般のアプリケーション２００のセキュリティおよび動作品質よりも重要であると考えられることがある。このような状況において、リモート管理・監視アプリケーションの優先度を高くし、一般のアプリケーションの優先度を低くする。これにより、常にリモート管理・監視アプリケーションへの鍵割り当てを優先し、そのトラフィックを制約しないように維持することが可能である。

以上説明したとおり、本実施形態によれば、アプリケーションそれぞれが要求する鍵レートを満たす鍵割り当てを効率的に実行することができる。

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

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

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

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

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

本実施形態にかかる通信装置で実行されるプログラムは、コンピュータを上述した通信装置の各部（プラットフォーム部、リンク鍵共有部、アプリ鍵共有部、提供部、制御部、決定部、および、通知部）として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

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

１００ａ、１００ｂ、１００ｃノード
１０１プラットフォーム部
１０２リンク鍵共有部
１０３アプリ鍵共有部
１０４鍵記憶部
１０５提供部
１０６アプリ情報記憶部
１０７制御部
１０８決定部
１０９通知部
２００ａ〜２００ｆアプリケーション
３０１鍵共有ネットワーク
３０２アプリケーションネットワーク
３０３ａ、３０３ｂプライベートネットワーク

Claims

１以上のアプリケーションに割り当てる暗号鍵の量の合計である第１合計値が、割り当て可能な前記暗号鍵の量の合計値である第２合計値以下となり、かつ、優先度が高い前記アプリケーションを優先して前記アプリケーションが要求する前記暗号鍵の量を表す第１要求量の前記暗号鍵を割り当てるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する決定部、
を備える通信装置。
前記決定部は、前記アプリケーションが要求する前記暗号鍵の量を表し前記第１要求量より小さい第２要求量の合計が前記第２合計値より大きい場合、前記第１合計値が前記第２合計値以下となり、かつ、前記優先度が高い前記アプリケーションを優先して前記第２要求量の前記暗号鍵を割り当てられるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する、
請求項１に記載の通信装置。
前記決定部は、前記第１合計値が前記第２合計値以下となり、かつ、前記優先度が高い前記アプリケーションを優先して前記第１要求量の前記暗号鍵を割り当て、かつ、前記優先度が低い前記アプリケーションに対して前記アプリケーションが要求する前記暗号鍵の要求量であって前記第１要求量より小さい第２要求量以下の前記暗号鍵を割り当てるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する、
請求項１に記載の通信装置。
前記暗号鍵の量が変更された前記アプリケーションに対して、前記暗号鍵の量が変更されたことを通知する通知部をさらに備える、
請求項１に記載の通信装置。
前記優先度と前記第１要求量とは、前記アプリケーションから受信される、
請求項１に記載の通信装置。
前記決定部は、前記アプリケーションが接続された場合、前記アプリケーションが要求する前記第１要求量が変更された場合、および、前記第２合計値が変更された場合、の少なくともいずれかの場合に、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する、
請求項１に記載の通信装置。
１以上のアプリケーションに割り当てる暗号鍵の量の合計である第１合計値が、割り当て可能な前記暗号鍵の量の合計値である第２合計値以下となり、かつ、優先度が高い前記アプリケーションを優先して前記アプリケーションが要求する前記暗号鍵の量を表す第１要求量の前記暗号鍵を割り当てるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する決定ステップ、
を含む通信方法。
コンピュータを、
１以上のアプリケーションに割り当てる暗号鍵の量の合計である第１合計値が、割り当て可能な前記暗号鍵の量の合計値である第２合計値以下となり、かつ、優先度が高い前記アプリケーションを優先して前記アプリケーションが要求する前記暗号鍵の量を表す第１要求量の前記暗号鍵を割り当てるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する決定部、
として機能させるためのプログラム。
暗号鍵を利用する１以上のアプリケーションと、前記アプリケーションに前記暗号鍵を提供する通信装置と、を備える通信システムであって、
前記通信装置は、
１以上のアプリケーションに割り当てる暗号鍵の量の合計である第１合計値が、割り当て可能な前記暗号鍵の量の合計値である第２合計値以下となり、かつ、優先度が高い前記アプリケーションを優先して前記アプリケーションが要求する前記暗号鍵の量を表す第１要求量の前記暗号鍵を割り当てるように、前記アプリケーションそれぞれに割り当てる前記暗号鍵の量を決定する決定部、を備える、
通信システム。