JP5694247B2 - 鍵生成装置、通信方法および通信システム - Google Patents

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

しかしながら、従来技術では、アプリケーションがノードから取得可能なアプリケーション鍵に関する情報を取得する手順が明らかになっていないため、例えばアプリケーションが取得可能なアプリケーション鍵に応じて適切な暗号アルゴリズムを決定することなどができなかった。

実施形態の通信装置は、暗号鍵を生成する鍵生成装置に接続される。通信装置は、取得部と、算出部と、送信部と、を備える。取得部は、鍵生成装置が提供可能な暗号鍵のリソースを表す鍵リソース情報を取得する。算出部は、取得された鍵リソース情報に基づいて、暗号鍵を利用するアプリケーションに提供可能な暗号鍵の鍵リソース情報を算出する。送信部は、算出された鍵リソース情報をアプリケーションに送信する。

本実施形態にかかる通信システムのネットワーク構成図。 本実施形態が想定するユースケースを示す図。 本実施形態のノードのブロック図。 本実施形態のアプリケーションのブロック図。 本実施形態における鍵リソース算出処理のフローチャート。 本実施形態の通信システムのネットワーク構成図。 本実施形態の通信システムのネットワーク構成図。 本実施形態にかかる装置のハードウェア構成図。

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

通信装置（アプリケーション）は、種類によっては、通信（暗号通信）を開始する前に、どの程度のアプリケーション鍵が鍵生成装置（ノード）から取得可能かに関する情報を必要とする。例えば、継続的にデータ通信を継続する、ビデオまたは音声通信を実行するアプリケーションは、通信開始前に、継続して一定量以上のアプリケーション鍵がノードから取得できるか否かを問い合わせることで、利用できる帯域または暗号アルゴリズムを決定するかもしれない。また、例えば、一度に大きなファイルを転送するファイル転送アプリケーションは、通信開始前に、そのファイルを一度に転送するために十分なアプリケーション鍵を直ちに取得できるかを問い合わせるかもしれない。

すなわち、アプリケーションは、ノードから利用可能なアプリケーション鍵の鍵生成速度（スループット）、または、アプリケーション鍵の鍵保有量に関する情報を必要とすることがある。以下では、鍵生成速度および鍵保有量などの、ノードが提供可能なアプリケーション鍵のリソースを鍵リソース情報、または、単に鍵リソースという。鍵リソース情報は、鍵生成速度および鍵保有量に限られるものではない。また、複数の鍵リソース情報（例えば、鍵生成速度および鍵保有量）を重み付けて加算した値を鍵リソース情報として用いるように構成してもよい。

一方、ノードは、鍵生成速度および鍵保有量などの鍵リソースを応答するためには、自身が保持するアプリケーション鍵の情報だけでなく、他のノードが保持する鍵の情報、リンク鍵の情報、および、他のアプリケーションに関する情報等といった条件も考慮する必要がある。

そこで、本実施形態では、鍵リソースをアプリケーションに回答および割り当てるための、鍵リソースの算出、鍵リソースの管理、および、アプリケーションへの割り当ての方法を明らかにする。本実施形態の通信システムは、例えば以下のような構成を備える。

ノードは、鍵リソースを以下の手法にて算出、管理および割り当てることにより、アプリケーションからの鍵リソースの問い合わせに回答する。
（Ａ１）鍵リソース情報の収集
（Ａ２）他のアプリケーションの情報の収集
（Ａ３）パス候補の算出
（Ａ４）最適パス、および、アプリケーションへの回答の決定

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

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

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

図２は、本実施形態が想定するユースケースの一例を説明するための図である。以下、図２のユースケースについて説明する。

ノード１００ａに接続するアプリケーション２００ａが、ノード１００ｃに接続するアプリケーション２００ｃとの通信を開始するものとする。この際、以下の（１）〜（４）の処理が実行される。
（１）鍵リソース問い合わせ：アプリケーション２００ａは、ノード１００ａに対して、アプリケーション２００ｃと通信する際に利用可能な鍵リソースについて問い合わせを行う。
（２）鍵リソース応答：ノード１００ａは、問い合わせに対して、アプリケーション２００ａが利用可能な鍵リソース情報を応答する。
（３）アプリケーション鍵取得：アプリケーション２００ａは、ノード１００ａに対してアプリケーション鍵を要求し、アプリケーション鍵をノード１００ａから取得する。
（４）暗号通信：アプリケーション２００ａは、ノード１００ａから取得したアプリケーション鍵を使って、アプリケーション２００ｃとの間で暗号通信を行う。

図３は、ノード１００の構成の一例を示すブロック図である。図３に示すように、ノード１００は、第１通信部１０１と、リソース管理部１０２と、取得部１０３と、決定部１０４と、算出部１０５と、第２通信部１０６と、要求管理部１０７と、プラットフォーム部１０８と、を備えている。

第１通信部１０１は、他のノード１００（外部装置）との間の通信リンク（ノード間リンク）によって接続された当該他のノード１００（対向ノード）との間で、量子暗号通信技術を用いて乱数を生成共有し、生成した乱数をリンク鍵として管理する。また、第１通信部１０１は、ノード間リンクによって接続された他のノード１００との間でデータの送受信（ノード間データ通信）を行う際に利用される。

ここで、他のノードとは、リンクによって直接接続された対向ノードである場合もあるし、その対向ノードの別のノード間リンクを介してさらに接続される別のノードである場合もある。後者の場合、第１通信部１０１は、暗号通信ネットワークにおいて、複数ノードを介して通信を行うためのルーティング機能を提供してもよい。第１通信部１０１を介してノード間で交換されるデータは、例えば、アプリケーション鍵のデータである。これらのデータは、ノード１００が管理するリンク鍵を用いて暗号化された通信であってもよい。

リソース管理部１０２は、第１通信部１０１を介して交換するリンク鍵、およびアプリケーション鍵を管理および保持する。リソース管理部１０２は、直接接続された対向ノードとの間で交換したリンク鍵のみを保持する。一方、アプリケーション鍵については、リソース管理部１０２は、暗号通信ネットワーク上のどのようなノード１００との間で交換したアプリケーション鍵であっても、保持管理することができる。

また、一般にリンク鍵は、ノード１００との間のアプリケーション鍵の交換を安全に行うために利用される。利用が終了したリンク鍵は廃棄される。アプリケーション鍵は、後述の方法によって、ノード１００からアプリケーション２００に渡され、アプリケーション２００によって利用される。アプリケーション２００に提供されたアプリケーション鍵は、通常、ノード１００では廃棄される。リソース管理部１０２が保持および管理する鍵は、暗号通信システムにおけるセキュリティ上最も重要なデータの１つである。このため、ファイルシステムやＯＳ（オペレーティングシステム）によって暗号化、改竄防止、および、アクセス制限等のセキュリティ対策が施されていてもよい。リソース管理部１０２は、様々な実現方法が可能であるが、例えば、ファイルシステムやデータベースとして実装できる。

取得部１０３は、上述の（Ａ１）および（Ａ２）の処理を実行する。すなわち、取得部１０３は、他のノード１００が提供可能なアプリケーション鍵の鍵リソース情報を取得（収集）する。また、取得部１０３は、鍵リソース情報を要求したアプリケーション２００以外の他のアプリケーション２００に関する情報（他アプリケーション情報）を取得する。取得部１０３は、鍵リソース情報、および、他アプリケーション情報の収集のために、第１通信部１０１、または、その他の図示しない通信インタフェースを用いて、他のノード１００等と通信を行ってもよい。

決定部１０４は、上述の（Ａ３）の処理を実行する。すなわち、決定部１０４は、自身のノード１００から、暗号通信ネットワーク上の他の各ノード１００へ至るためのパス（経路）の候補を洗い出す。

算出部１０５は、取得部１０３により取得された鍵リソース情報を参照し、鍵リソース情報を要求したアプリケーション２００に提供可能な鍵リソース情報を算出する。このとき、算出部１０５は、決定部１０４により決定されたパスの候補のうち、最大の鍵リソースを提供可能なパス（最適パス）を算出する。そして、算出部１０５は、最適パスで提供可能な鍵リソース情報を、アプリケーション２００に提供可能な鍵リソース情報として算出する。

第２通信部１０６は、アプリケーション２００との間の通信リンク（アプリケーション通信リンク）によって接続された当該アプリケーション２００との間でデータ通信を行う際に利用される。例えば、第２通信部１０６は、アプリケーション２００からのアプリケーション鍵の取得要求などの要求を受け付け、アプリケーション２００に対してアプリケーション鍵を提供する。また、第２通信部１０６は、アプリケーション２００からの、鍵リソースの問い合わせ情報受付と、鍵リソース情報の回答のための通信にも用いられる。

第２通信部１０６は、送信部１０６ａを備える。送信部１０６ａは、アプリケーション２００に対して各種データを送信する。例えば、送信部１０６ａは、算出部１０５により算出された鍵リソース情報をアプリケーション２００に送信する。

要求管理部１０７は、アプリケーション２００が要求する鍵リソース情報の受付および管理、並びに、アプリケーション２００に割り当てた鍵リソース情報の管理および通知等を行う。要求管理部１０７は、例えば、アプリケーション２００の識別子（アドレス等）と、そのアプリケーション２００が要求する鍵リソース情報と、を対応づけて記憶するデータベース等によって鍵リソース情報を管理する。

要求管理部１０７は、アプリケーション２００との通信には第２通信部１０６を利用する。要求管理部１０７は、アプリケーション２００から鍵リソース情報の要求を受け取り、受け取った鍵リソース情報を、算出部１０５等の要求に応じて提供する。一方、割り当てられた鍵リソース情報は、算出部１０５から要求管理部１０７に通知される。要求管理部１０７は、通知された鍵リソース情報を、対応するアプリケーション２００に第２通信部１０６を介して提供する。

プラットフォーム部１０８は、ノード１００上の他の構成要素の管理、動作に必要なコンピュータのオペレーティングシステム機能、基本的なネットワーク機能、および、セキュリティ機能等を提供する。

以上、本実施形態におけるノード１００の構成について説明した。ただし、上記説明は一例である。

次に、本実施形態におけるアプリケーション２００の構成について説明する。図４は、アプリケーション２００の構成例を示すブロック図である。図４に示すように、アプリケーション２００は、通信部２０１と、通信部２０２と、実行部２０３と、プラットフォーム部２０４と、を備えている。

通信部２０１は、ノード１００との間の通信リンク（リンク５２）を介して、ノード１００（具体的にはノード１００の第２通信部１０６）と接続して各種データを送受信する。例えば、通信部２０１は、暗号通信を行うために必要なアプリケーション鍵をノード１００から取得する。この他、通信部２０１は、アプリケーション鍵の取得を開始する前に、利用可能な鍵リソースの問い合わせを行う。

アプリケーション２００が、要求した鍵リソースが得られなかった場合にどのような処理を実行するかについては特に限定しない。また、ノード間リンクを用いて、アプリケーション２００とノード１００とが通信する手順については特に限定しないが、以下のような方法を適用できる。

例えば、通信部２０１は、ノード１００からアプリケーション鍵を取得する通信に際して、ノード１００との間でセッションの確立を行ってもよい。なお、このセッションの情報は、ノード１００を介して、アプリケーション２００による暗号通信の相手となるアプリケーション２００、および、そのアプリケーション２００が接続するノード１００と共有されてもよい。

例えば、アプリケーション２００ａとアプリケーション２００ｃとの暗号通信を行う際に、アプリケーション２００ａとノード１００ａは鍵利用セッションを確立し、また、アプリケーション２００ｃとノード１００ｃも、そのセッションと同一または関連付けられた鍵利用セッションを確立する。このため、通信部２０１は、何らかのセッション制御プロトコルを利用してノード１００と通信してもよい。

実行部２０３は、暗号通信を行うアプリケーション機能を実行する。通信を行うものであれば特にアプリケーション機能の種類は限定しない。例えば、実行部２０３は、ビデオ送信およびファイル転送等の機能を実行する。実行部２０３は、暗号通信の際、通信部２０２を利用してデータを送受信する。

通信部２０２は、実行部２０３の動作に必要な通信機能を提供する。また、通信部２０２は、通信データの暗号化および復号機能を提供する。通信部２０２は、アプリケーション２００から送信データを受けとると、送信データを暗号化し、暗号通信リンク（リンク５３）を介してデータを送信する。また、通信部２０２は、暗号通信リンクからデータを受信すると、受信したデータを復号し、実行部２０３へと復号したデータを受け渡す。

暗号化および復号で必要になった場合は、通信部２０２は、ノード間リンクにより新たなアプリケーション鍵を要求する。通信部２０２は、どのような暗号アルゴリズムを用いて暗号通信を行ってもよい。例えば、ワンタイムパッドのようなバーナム暗号であってもよいし、ＡＥＳのようなブロック暗号であってもよい。また暗号以外にメッセージ認証等を行っていてもよい。ただし、通信部２０２が利用する暗号アルゴリズムの少なくとも１つは、ノード１００から提供されるアプリケーション鍵を利用するものとする。

プラットフォーム部２０４は、アプリケーション２００上の他の構成要素の管理、動作に必要なコンピュータのオペレーティングシステム機能、基本的なネットワーク機能、および、セキュリティ機能等を提供する。

以上、本実施形態におけるアプリケーション２００の構成について説明した。ただし、上記説明は一例である。

次に、このように構成された本実施形態にかかる通信システムによる鍵リソース算出処理について説明する。図５は、本実施形態における鍵リソース算出処理の一例を示すフローチャートである。図６は、通信システムのネットワーク構成例を示す図である。

まず、鍵リソース情報として鍵生成速度を扱う場合について説明する。図６は、鍵生成速度を鍵リソース情報とする場合の例を示す。図６の「リンク鍵ｎ」の記載は、対応するリンクでのリンク鍵の鍵生成速度がｎであることを表している。リンク鍵の鍵生成速度は、例えば、量子暗号通信における、方式、量子通信のスループット、光ファイバのケーブル長、および、ロス率等によって決定できる。リンク鍵の鍵生成速度は、例えば第１通信部１０１によって求められる。なお、リンク鍵の鍵生成速度は、システム運用中に固定的に決定できるものと考えることもできるし、動的に変動するものと考えてもよい。

ノード１００は、図５に示す手順により、収集したリンク鍵の鍵生成速度等の情報を元にして、アプリケーション鍵の生成速度を算出し、アプリケーション２００に回答する。なお、図５のステップＳ１０１〜ステップＳ１０４は、上述の（Ａ１）〜（Ａ４）に対応する。

まず、取得部１０３は、暗号通信ネットワーク上のすべてのノード１００との間のパスにおける、リンク鍵の鍵生成速度の情報を収集する（ステップＳ１０１）。取得部１０３は、例えば、一定の時間間隔で何らかのノード間通信をすることでステップＳ１０１の処理を実行する。なお、アプリケーション２００からの問い合わせを受ける前に事前にステップＳ１０１の処理を行っておいても良いし、アプリケーション２００からの問い合わせを受けてからステップＳ１０１の処理を実行してもよい。アプリケーション２００からの問合せとは無関係にステップＳ１０１を実行しても良い。

リンク鍵の鍵生成速度の収集にはいくつかの方法が存在する。各ノード１００が、自身が保有するリンクにおけるリンク鍵の生成速度情報を図示しない管理サーバ（管理装置）に通知すると共に、必要なリンク鍵の生成速度情報を管理サーバから取得する方法を用いてもよい。管理サーバとは、例えばすべてのノード１００のリンク鍵の生成速度情報を収集して管理するサーバである。この場合、取得部１０３が、管理サーバとの間の通信を行ってもよい。なお、このような管理サーバは、単純なデータベースやディレクトリサーバとして実現可能である。管理サーバが暗号通信ネットワーク上に存在する場合は、各ノード１００は、第１通信部１０１を介して管理サーバと通信してもよい。管理サーバが別のネットワーク上に存在する場合は、各ノード１００は、図示しない別のネットワークインタフェースを介して管理サーバと通信してもよい。

この他の方法として、各ノードが個別に前ノードと通信することで、全リンクのリンク鍵の生成速度情報を収集する方法もある。また、ルーティングプロトコルのメッセージ交換を用いて、各ノード１００が、各ノード１００が保有するリンク鍵の生成速度情報を、ルーティングプロトコルにおけるパラメータの１つとして収集する、という方法を用いてもよい。ルーティングプロトコルとは、暗号通信ネットワークにおけるルーティングを確立する上で実行されるプロトコルである。

このような目的に利用可能なルーティングプロトコルとして、ＯＳＰＦ（Open Shortest Path First）が存在する。ＯＳＰＦは、リンクステートアップデートパケット（ＬＳＵ）を通信システム内のすべてのノード間で交換することで、ルーティングプロトコルに必要なメトリックである各パス（リンク）のコスト情報を交換する。このコストの一種として、リンク鍵の生成速度情報を交換することで、ステップＳ１０１の実施が可能である。この場合、例えば取得部１０３と第１通信部１０１とにより、ルーティングプロトコルを実行するように構成できる。

収集したリンク鍵の生成速度情報は、取得部１０３にて保持される。なお、リンク鍵の生成速度情報とは、例えば図６のリンクそれぞれに示された数字（上述のｎ）のことである。図６の例では、生成速度情報は以下のように保持される。
ノード１００ａ、１００ｅ間：５
ノード１００ｅ、１００ｄ間：１０
ノード１００ｄ、１００ｃ間：１２
ノード１００ａ、１００ｂ間：８
ノード１００ｂ、１００ｃ間：４
ノード１００ａ、１００ｆ間：７
ノード１００ｆ、１００ｃ間：１０

図５に戻り、取得部１０３は、さらに他のアプリケーションの情報を収集する（ステップＳ１０２）。ステップＳ１０２は、暗号通信ネットワークにおいて、同時に複数のアプリケーション２００を実行する場合に必要な手順である。同時に１つのアプリケーション２００のみを実行する場合、本手順は必要ないため省略してよい。

例えば、ノード１００ａに接続するアプリケーション２００ａが、ノード１００ｃに接続するアプリケーション２００ｃと通信するための鍵リソースをノード１００ａに問い合わせると仮定する。また、このとき既に、アプリケーション２００ａと同じくノード１００ａに接続するアプリケーション２００ｂが、アプリケーション２００ｃと同じくノード１００ｃに接続するアプリケーション２００ｄと暗号通信するための鍵リソース（鍵生成速度）をある程度利用済み（割り当て済み）であったと仮定する。この場合、アプリケーション２００ｂとアプリケーション２００ｄとの間の暗号通信に割り当てた分の鍵リソース（鍵生成速度）は利用できない。このため、アプリケーション２００ａがノード１００ａから取得可能な鍵リソース（鍵生成速度）は、アプリケーション２００ｂとアプリケーション２００ｄとの間の暗号通信が存在しない場合と比べ、小さくなる。

従って、鍵リソースを分け合う他のアプリケーション２００の存在を考慮し、他のアプリケーション２００が使用している鍵リソース（鍵生成速度）を差し引いた鍵リソースが、実際にアプリケーション２００ａが利用可能な鍵リソース（アプリケーション鍵の鍵生成速度）であると考える必要がある。

そのため、取得部１０３は、以下の（対応１）および（対応２）のいずれかの処理を行う。

（対応１）
（Ａ１）（すなわちステップＳ１０１）では、取得部１０３は、予め他のアプリケーション２００に割り当て済みの鍵リソースを差し引いた鍵リソース情報を各ノード１００から収集する。この場合、例えばノード１００が予め他のアプリケーション２００に割り当て済みの鍵リソースを差し引いた鍵リソース情報を取得部１０３に提供するように構成する。この処理により、（Ａ２）（すなわちステップＳ１０２）では、特別な対応は不要となる。各ノード１００における取得部１０３は、第１通信部１０１等から取得した各情報を共有できるように保持する。

ただし、他のアプリケーション２００へのアプリケーション鍵の割り当て状況は、時刻とともに大きく変化しうる。このため、ステップＳ１０２を対応１により正確に行うためには、ステップＳ１０１の処理を細粒度で（短い時間間隔で）実行する必要がある。例えば、管理サーバへの問合せを頻繁に行う、あるいは、ＯＳＰＦにおいて、定期的にリンク情報を交換するパケットである、ＬＳＵの送信間隔を短く設定する、等が具体的な対応となる。

（対応２）
（Ａ１）では、他のアプリケーション２００への割り当て済みの鍵リソースは考慮せずに情報収集を行う。一方、（Ａ２）のために、鍵リソースの使用状況を管理する第２の管理サーバ（図示せず）を別途設ける。各ノード１００の取得部１０３は、アプリケーション２００への鍵リソースの割り当てを行った際、この第２の管理サーバに割り当て状況を通知する。また、各ノード１００の取得部１０３は、定期的、または、必要に応じて、第２の管理サーバに、他ノード１００における鍵リソースの割り当て情報を問い合わせる。この手順を実行することで、各ノード１００は、他のアプリケーション２００へ既に割り当て済みの鍵リソース（割り当て情報）を把握できる。また、各ノード１００は、収集した鍵リソースから、割り当て済みの鍵リソースを差し引くことができる。なお、このような第２の管理サーバは、単純なデータベースやディレクトリサーバとして実現可能である。第２の管理サーバが暗号通信ネットワーク上に存在する場合は、各ノード１００は、第１通信部１０１を介して第２の管理サーバと通信してもよい。第２の管理サーバが別のネットワーク上に存在する場合は、各ノード１００は、図示しない別のネットワークインタフェースを介して第２の管理サーバと通信してもよい。なお、第２の管理サーバと管理サーバは、同一のサーバ、または、同一のサーバ上のプロセスとして実現されても良い。

ステップＳ１０１およびステップＳ１０２の後、決定部１０４は、パス候補を決定する（ステップＳ１０３）。決定部１０４は、例えばステップＳ１０１と同時に、または、別途ルーティングプロトコルを実行すること等により収集したノード間のグラフ情報を元に、自身のノード１００から、暗号通信ネットワーク上の他の各ノード１００へ至るためのパスの候補をすべて洗い出す。このためには、ネットワークにおける各ノードの接続関係に関する情報が必要である。このためには、既存のルーティングプロトコルによる接続情報収集の仕組みを利用して良い。前述のルーティングプロトコルと同時に実施しても良いし、別々に実施しても良い。

例えば、図６において、ノード１００ａからノード１００ｃに至るパスの候補は、以下の３通りである。
候補Ａ:ノード１００ａ−ノード１００ｅ−ノード１００ｄ−ノード１００ｃ
候補Ｂ:ノード１００ａ−ノード１００ｂ−ノード１００ｃ
候補Ｃ:ノード１００ａ−ノード１００ｆ−ノード１００ｃ

なお、決定部１０４は、同じノードを二度通るパスは選択しない等の条件を用いて、ループになるパスなどの無駄なパスを排除するように構成してもよい。

次に、算出部１０５は、パス候補のうち鍵リソースが最適となるパス（最適パス）と最適パスで提供可能な鍵リソースを算出する（ステップＳ１０４）。例えば、算出部１０５は、求められたパス候補それぞれについて、鍵リソースの値（すなわち、リンク鍵の鍵生成速度）が最小である箇所（リンク）をそのパス候補のボトルネックとして求める。また、算出部１０５は、そのボトルネックの値が最大であるパスを最適パスとして選択する。

例えば上述の候補Ａ〜Ｃの例の場合、ボトルネットとなるリンクの鍵生成速度は以下のようになる。
候補Ａ：
ノード１００ａ−ノード１００ｅ間の鍵生成速度:５
ノード１００ｅ−ノード１００ｄ間の鍵生成速度:１０
ノード１００ｄ−ノード１００ｃ間の鍵生成速度:１２
ボトルネック:５
候補Ｂ:
ノード１００ａ−ノード１００ｂ間の鍵生成速度:８
ノード１００ｂ−ノード１００ｃ間の鍵生成速度:４
ボトルネック:４
候補Ｃ:
ノード１００ａ−ノード１００ｆ間の鍵生成速度:７
ノード１００ｆ−ノード１００ｃ間の鍵生成速度:１０
ボトルネック:７

このため、算出部１０５は、候補Ｃ（ノード１００ａ−ノード１００ｆ−ノード１００ｃ）を最適パスとする。また、算出部１０５は、最適パスに対応する鍵生成速度を７×αと算出する。ここで、αは、リンク鍵の保有量と、そのリンク鍵を使って交換できるアプリケーション鍵の保有量との比である。αは、理想的には１となる。以上より、アプリケーション鍵の生成速度は７となる。

ノード１００は、算出された鍵生成速度をアプリケーション２００に回答する。鍵リソース情報の回答を受けたアプリケーション２００の動作は特に限定しないが、例えば、以下のように動作してもよい。アプリケーション２００は、回答された最適パスの鍵リソースの提供をノード１００に要求する。ノード１００は、この要求を受けて最適パスからアプリケーション鍵を得てアプリケーション２００に送付する。アプリケーション２００は、提供を受けたアプリケーション鍵を用いて、アプリケーション鍵を用いる暗号通信を開始する。

なお、ステップＳ１０３およびステップＳ１０４を、例えば算出部１０５が１つの手順として実行してもよい。また、最適パスとして選択するパスは、（Ｐ１）１本のパス（Ｐ２）途中で複数のパスに分かれるパス（すなわち、複数のパスを同時に利用し、より大量の鍵リソースを一度に利用する）のいずれであってもよい。上記例では、（Ｐ１）の場合を説明した。

一般に、（Ｐ２）の場合、最大フロー問題を解くことで上記手順を実現できる。最大フロー問題とは、単一の始点から単一の終点へのフローネットワークで、最大となるフローを求める数学の問題である。最大フロー問題の解法としては、線形計画法、および、フォード・ファルカーソンのアルゴリズム等、様々な解法が知られている。算出部１０５は、これらのどのようなアルゴリズムを用いて上記手順を実現しても構わない。

（Ｐ１）の場合も様々な方法が適用できる。算出部１０５は、どのようなアルゴリズムを用いて上記手順を実現しても構わない。前述の最大フロー問題の一部として解いても構わない。また、例えば、一般に最短経路問題を解くアルゴリズムとして知られているダイクストラのアルゴリズムが、ルーティングプロトコルＯＳＰＦには実装されているが、このプロトコルを改良して適用することでも実現できる。通常のダイクストラのアルゴリズムはで、宛先ノードの情報として、パス候補のコストの合計を保持し、これが最小となるパスが最短パスとして選択される。一方、改良ダイクストラアルゴリズムでは、パス候補のコスト（鍵リソース：鍵生成速度）の最小値を保持し、これが最大となるパスを、最適パスとして選択すればよい。

以上が、鍵リソースとして鍵生成速度を扱う場合の、鍵リソース割り当てアルゴリズムのシーケンスとなる。上述の手順の実行結果として、各ノード１００は、自ノードから他のすべてのノード１００との間で、アプリケーション２００に提供可能な鍵生成速度という鍵リソースが決定できる。

ノード１００は、この鍵リソース情報のうち、アプリケーション２００から問い合わせを受けた他のノード１００に関する鍵リソース情報を、該当アプリケーション２００に対し応答する。

例えば、ノード１００ａが、アプリケーション２００ａから、アプリケーション２００ｃと通信するために利用できる鍵リソースとしての鍵生成速度に関する問い合わせを受けたとする。この場合、ノード１００ａは、ノード１００ｃとの間で利用可能な鍵生成速度に関する情報を応答する。

なお、アプリケーション２００ａは、ノード１００ｃそのものの識別子（アドレス等）を直接指定して問い合わせを行ってもよいし、行わなくてもよい。後者の場合、例えば、問い合わせを受けたノード１００ａ自身が、アプリケーション２００ａから通知された情報をもとに、アプリケーション２００ｃが接続するノード１００ｃを特定してもよい。

次に、鍵リソースとして鍵保有量を扱う場合について説明する。図７は、この場合の通信システムのネットワーク構成例を示す図である。図７の「リンク鍵ｎ」の記載は、対応するリンクでのリンク鍵の鍵保有量がｎであることを表している。また、例えば図７のノード１００ａに対応づけられた吹き出し内の「ノード１００ｂ．．．２０」の記載は、ノード１００ａとノード１００ｂとの間で共有するアプリケーション鍵の鍵保有量が２０であることを表している。

まず、取得部１０３は、鍵保有量の情報を収集する（ステップＳ１０１）。鍵保有量のカウント方式には以下の方式Ａおよび方式Ｂの２つの方式がある。
方式Ａ：既にアプリケーション鍵として、自ノードにて保有されているもののみを、鍵保有量としてカウントする。
方式Ｂ：方式Ａでカウントされた鍵保有量に加えて、自ノードと宛先ノードとの間のパス上のリンクにて既に保有されているリンク鍵を使用して交換可能なアプリケーション鍵に関しては、追加的に所有しうるアプリケーション鍵として、鍵保有量に追加してカウントする。

方式Ａの場合、特に鍵リソース情報の収集手順は非常に単純となる。例えば、取得部１０３は、リソース管理部１０２が保持しているノード１００毎のアプリケーション鍵の保有量のデータを参照することで、鍵保有量を決定できる。

方式Ｂの場合は、方式Ａで述べた、リソース管理部１０２が保持しているノード１００毎のアプリケーション鍵の保有量に加えて、リンク鍵の保有量についても考慮する必要がある。そのため、取得部１０３は、暗号通信ネットワーク上のすべてのノード１００との間のパスにおける、リンク鍵の鍵保有量の情報を収集する。

図７では、鍵リソース情報として鍵保有量を扱う場合に必要な情報として、ノード１００（実際に必要なのは自ノードに関する情報のみ）が保有する他の各ノード１００と共有しているアプリケーション鍵の鍵保有量と、暗号通信ネットワーク上のすべてのリンクにおけるリンク鍵の鍵保有量と、が示されている。

アプリケーション鍵およびリンク鍵の鍵保有量の情報は、リソース管理部１０２にアクセスすることで求められる。前述の通り、アプリケーション鍵の鍵保有量は、アプリケーション鍵の該当ノードとの間で交換することで増加し、アプリケーション２００にアプリケーション鍵を提供することで減少する。また、リンク鍵の鍵保有量は、量子暗号通信技術における鍵共有手順によって増加し、ノード間でリンク鍵を用いたセキュア通信を行う（例えばアプリケーション鍵の交換のため）ことで減少する。

図７におけるノード１００ａのリソース管理部１０２が保持する情報の例を以下に示す。

まず、各ノードが保有するアプリケーション鍵の保有量について示す。
ノード１００ｂ:２０
ノード１００ｃ:３０
ノード１００ｄ:４０
ノード１００ｅ:５０
ノード１００ｆ:６０

次に、各ノード間のリンクで保有されるリンク鍵の保有量について示す。
ノード１００ａ−ノード１００ｅ間のリンク:５
ノード１００ｅ−ノード１００ｄ間のリンク:１０
ノード１００ｄ−ノード１００ｃ間のリンク:１２
ノード１００ａ−ノード１００ｂ間のリンク:８
ノード１００ｂ−ノード１００ｃ間のリンク:４
ノード１００ａ−ノード１００ｆ間のリンク:７
ノード１００ｆ−ノード１００ｃ間のリンク:１０

なお、方式Ｂの場合に追加で必要となる、暗号通信ネットワーク上のすべてのノード間のパスにおけるリンク鍵の鍵保有量の情報の収集方法は、鍵生成速度に関する鍵リソース情報の収集と同様の手順で可能であるため、説明を省略する。

方式Ａの場合、他のアプリケーション２００に既に割り当てているアプリケーション鍵の鍵保有量は、例えば、要求管理部１０７またはリソース管理部１０２にて記録されている。取得部１０３は、記録された鍵保有量を参照することにより、割り当て済みの鍵保有量（割り当て情報）を差し引いて、新たに提供可能な鍵保有量を算出することができる。

方式Ｂの場合、取得部１０３は、さらに、リンク鍵の鍵保有量のうち、既に他のアプリケーション２００に割り当て済みのリンク鍵の鍵保有量の情報を収集する。収集の方法は、例えば、鍵生成速度に関する他のアプリケーション２００の情報の収集と同様の方法を適用できる。

方式Ａの場合、決定部１０４によるパス候補の決定処理（ステップＳ１０３）は不要である。方式Ｂの場合、決定部１０４は、鍵生成速度に関するパス候補の算出と同様の手順で、パス候補を算出する。

例えば、図７において、ノード１００ａからノード１００ｃに至るパスの候補は、
候補Ａ:ノード１００ａ−ノード１００ｅ−ノード１００ｄ−ノード１００ｃ
候補Ｂ:ノード１００ａ−ノード１００ｂ−ノード１００ｃ
候補Ｃ:ノード１００ａ−ノード１００ｆ−ノード１００ｃ
の３通りある。

方式Ａの場合、ノード１００は、通信相手となる他のノード１００に対応するアプリケーション鍵の鍵保有量をそのままアプリケーション２００に回答する。

方式Ｂの場合、算出部１０５は、鍵生成速度に関する最適パスと同様の手順で、鍵保有量に関する最適パスを決定する。また、算出部１０５は、方式Ａで求めたノード１００が既に保有するアプリケーション鍵の鍵保有量と、方式Ｂで求めたリンク鍵の鍵保有量とを足し算した結果を、鍵保有量の値としてアプリケーション２００に回答する。

図７の例では、ノード１００ａとノード１００ｃとの間で共有しているアプリケーション鍵は、３０である。また、各パス候補のリンク鍵保有量および追加で所有しうるアプリケーション鍵は、以下のようになる。
候補Ａ:
ノード１００ａ−ノード１００ｅ間のリンク鍵保有量:５
ノード１００ｅ−ノード１００ｄ間のリンク鍵保有量:１０
ノード１００ｄ−ノード１００ｃ間のリンク鍵保有量:１２
候補Ａのパスによって追加的に所有しうるアプリケーション鍵:５×α
候補Ｂ:
ノード１００ａ−ノード１００ｂ間のリンク鍵保有量:８
ノード１００ｂ−ノード１００ｃ間のリンク鍵保有量:４
候補Ｂのパスによって追加的に所有しうるアプリケーション鍵:４×α
候補Ｃ:
ノード１００ａ−ノード１００ｆ間のリンク鍵保有量:７
ノード１００ｆ−ノード１００ｃ間のリンク鍵保有量:１０
候補Ｃのパスによって追加的に所有しうるアプリケーション鍵:７×α

ここで、αは、リンク鍵の保有量と、そのリンク鍵を使って交換できるアプリケーション鍵の保有量との比であり、理想的には１となる。

以上より、アプリケーション鍵保有量は、最適パスとなる候補Ｃのパスを経由することにより、３０＋７＝３７となる。ノード１００は、この値（３７）をアプリケーション２００に回答する。

このように、本実施形態にかかる通信システムでは、各ノードが、鍵生成速度または鍵保有量などの鍵リソース情報を収集し、アプリケーションに対して割り当て可能な鍵リソース情報を回答することができる。これにより、例えばアプリケーションは取得可能なアプリケーション鍵の情報を入手でき、適切な暗号アルゴリズムを決定するなどの処理を実現できる。

本実施形態のノード１００およびアプリケーション２００が備える各部は、ハードウェア回路により実現してもよいし、一部または全部をソフトウェア（プログラム）により実現してもよい。

次に、本実施形態にかかる装置（アプリケーション、ノード）のハードウェア構成について図８を用いて説明する。図８は、本実施形態にかかる装置のハードウェア構成を示す説明図である。

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

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

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

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

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

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

１００ａ〜１００ｆ ノード
１０１ 第１通信部
１０２ リソース管理部
１０３ 取得部
１０４ 決定部
１０５ 算出部
１０６ 第２通信部
１０６ａ 送信部
１０７ 要求管理部
１０８ プラットフォーム部
２００ａ〜２００ｄ アプリケーション
２０１ 通信部
２０２ 通信部
２０３ 実行部
２０４ プラットフォーム部

Claims (9)

1. 暗号鍵を生成する外部装置に接続される鍵生成装置であって、
   前記外部装置が提供可能な前記暗号鍵のリソースを表す第１鍵リソース情報と、前記暗号鍵を利用する複数のアプリケーションのうち第１アプリケーションに割り当て済みの前記暗号鍵のリソースを表す割り当て情報と、を取得する取得部と、
   複数の前記アプリケーションのうち第２アプリケーションによる要求に応じて、前記第１鍵リソース情報および前記割り当て情報に基づいて、前記第２アプリケーションに提供可能な前記暗号鍵のリソースを表す第２鍵リソース情報を算出する算出部と、
   前記第２鍵リソース情報を前記第２アプリケーションに送信する送信部と、
   を備える鍵生成装置。
2. 前記鍵生成装置は、暗号鍵を生成する複数の外部装置に接続され、
   複数の前記外部装置に含まれる第１装置に到達する経路を決定する決定部をさらに備え、
   前記算出部は、取得された前記第１鍵リソース情報および前記割り当て情報に基づいて、前記経路を介して提供可能な前記暗号鍵の前記第２鍵リソース情報を算出する、
   請求項１に記載の鍵生成装置。
3. 前記決定部は、前記第１装置に到達する１以上の経路を決定し、
   前記算出部は、前記経路を介して提供可能な前記暗号鍵の前記第２鍵リソース情報のうち、最大の前記第２鍵リソース情報を算出する、
   請求項２に記載の鍵生成装置。
4. 前記第１鍵リソース情報および前記第２鍵リソース情報は、提供可能な前記暗号鍵の生成速度である、
   請求項３に記載の鍵生成装置。
5. 前記第１鍵リソース情報および前記第２鍵リソース情報は、提供可能な前記暗号鍵の保有量である、
   請求項３に記載の鍵生成装置。
6. 前記取得部は、ＯＳＰＦ（Open Shortest Path First）ルーティングプロトコルに従って交換されるメッセージに含まれる前記第１鍵リソース情報を前記外部装置から取得する、
   請求項１に記載の鍵生成装置。
7. 前記取得部は、前記外部装置の前記第１鍵リソース情報を記憶する管理装置から、前記第１鍵リソース情報を取得する、
   請求項１に記載の鍵生成装置。
8. 暗号鍵を生成する外部装置に接続される鍵生成装置で実行される通信方法であって、
   前記鍵生成装置が、前記外部装置が提供可能な前記暗号鍵のリソースを表す第１鍵リソース情報と、前記暗号鍵を利用する複数のアプリケーションのうち第１アプリケーションに割り当て済みの前記暗号鍵のリソースを表す割り当て情報と、を取得する取得ステップと、
   前記鍵生成装置が、複数の前記アプリケーションのうち第２アプリケーションによる要求に応じて、前記第１鍵リソース情報および前記割り当て情報に基づいて、前記第２アプリケーションに提供可能な前記暗号鍵のリソースを表す第２鍵リソース情報を算出する算出ステップと、
   前記鍵生成装置が、前記第２鍵リソース情報を前記第２アプリケーションに送信する送信ステップと、
   を含む通信方法。
9. 第１鍵生成装置と、第２鍵生成装置と、を備える通信システムであって、
   前記第１鍵生成装置は、
   暗号鍵を生成して前記第２鍵生成装置に送信する通信部を備え、
   前記第２鍵生成装置は、
   前記第１鍵生成装置が提供可能な前記暗号鍵のリソースを表す第１鍵リソース情報と、前記暗号鍵を利用する複数のアプリケーションのうち第１アプリケーションに割り当て済みの前記暗号鍵のリソースを表す割り当て情報と、を取得する取得部と、
   複数の前記アプリケーションのうち第２アプリケーションによる要求に応じて、前記第１鍵リソース情報および前記割り当て情報に基づいて、前記第２アプリケーションに提供可能な前記暗号鍵のリソースを表す第２鍵リソース情報を算出する算出部と、
   前記第２鍵リソース情報を前記第２アプリケーションに送信する送信部と、を備える、
   通信システム。

Images