JP2014053816A - 通信ノード、鍵同期方法、鍵同期システム - Google Patents

Abstract

【課題】 ノード同士がアプリケーション鍵の生成・共有を行えるようにする。
【解決手段】 実施形態によれば、鍵同期制御部およびアプリケーション通信部を具備する通信ノードが提供される。鍵同期制御部は、ノードベースのシグナリング処理とセッションベースのシグナリング処理とに基づいてアプリケーション鍵の同期を制御する。ノードベースのシグナリング処理では、相手ノードとのアプリケーション鍵の交換を開始または終了する。セッションベースのシグナリング処理では、前記相手ノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記相手ノードと同期する。アプリケーション通信部は、前記セッションを持つアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供する。
【選択図】図１

Description

本発明の実施形態は、通信ノード、鍵同期方法、鍵同期システムに関する。

暗号通信ネットワークは、複数のノードが複数のリンクを介して相互に接続されたネットワークである。各ノードは、リンクを介して接続された対向ノードとの間で乱数を生成・共有する機能と、この乱数を暗号鍵（以下、「リンク鍵」という）として利用して、リンク上で暗号通信を行う機能とを備える。複数のノードのうちの幾つかは、リンク鍵に利用するものとは別の乱数を生成する機能と、別のノードに対し、この乱数をリンク上で送信する機能とを備える。

暗号通信ネットワークにおけるアプリケーションは、リンク鍵とは別の乱数を暗号鍵（以下、「アプリケーション鍵」という）として利用して、別のアプリケーションとの間で暗号通信を行う機能を備える。

ノード間で暗号鍵を生成し共有する機能は、例えば一般に量子暗号通信と呼ばれる技術により実現される。この場合において、ノードは、リンク鍵およびアプリケーション鍵を生成し、リンク鍵によってアプリケーション鍵を暗号化し、別のノードに対しこの暗号化されたアプリケーション鍵をリンク上で送信する。この技術は、量子鍵配送（Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ：ＱＫＤ）と呼ばれることがある。

特開２００８−１５４０１９号公報

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

暗号通信ネットワークを構成するノードに複数のアプリケーションが接続し、これら複数のアプリケーション向けに複数のアプリケーション鍵を提供する場合において、ノード同士が、アプリケーション鍵の生成・共有を行う具体的な方法が明らかになっていない。

実施形態によれば、鍵同期制御部およびアプリケーション通信部を具備する通信ノードが提供される。鍵同期制御部は、ノードベースのシグナリング処理とセッションベースのシグナリング処理とに基づいてアプリケーション鍵の同期を制御する。ノードベースのシグナリング処理では、相手ノードとのアプリケーション鍵の交換を開始または終了する。セッションベースのシグナリング処理では、前記相手ノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記相手ノードと同期する。アプリケーション通信部は、前記セッションを持つアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供する。

実施形態に係る暗号通信ネットワークの概略図 アプリケーション間の暗号通信と鍵の提供を示す図 実施形態に係るノードを示すブロック図 実施形態に係るアプリケーションを示すブロック図 暗号通信開始時のシーケンス概要を示す図 暗号通信終了時のシーケンス概要を示す図 暗号通信開始処理のフローチャート 暗号通信開始処理のフローチャート 暗号通信開始時のノードベースのシグナリング処理およびセッションベースのシグナリング処理のシーケンスを示す図 暗号通信終了処理のフローチャート 暗号通信終了処理のフローチャート 暗号通信終了時のノードベースのシグナリング処理およびセッションベースのシグナリング処理のシーケンスを示す図 アプリケーション鍵の割り当ての実現例を説明するための図

以下、実施の形態について、図面を参照して説明する。

図１は、実施形態に係る暗号通信ネットワークの概略図である。該ネットワークにおいて、複数のノード（例えば１００ａ〜１００ｄ）が複数のリンク（例えば３００ａ〜３００ｃ）を介して相互に接続される。各ノードは、リンクを介して接続された対向ノードとの間で暗号通信を行う。例えば、ノード１００ａとノード１００ｂは、あるリンク鍵を用いてリンク３００ａ上で暗号通信を行う。ノード１００ｂとノード１００ｃは、別のリンク鍵を用いてリンク３００ｂ上で暗号通信を行う。ノード１００ｂとノード１００ｄは、さらに別のリンク鍵を用いてリンク３００ｄ上で暗号通信を行う。

ノード間で暗号鍵を生成し共有する機能は、例えば量子鍵配送（ＱＫＤ）により実現される。例えばノード１００ａは、リンク鍵によってアプリケーション鍵を暗号化し、この暗号化されたアプリケーション鍵をリンク３００ａ上でノード１００ｂに送信する。

暗号通信ネットワークにおけるアプリケーションは、アプリケーション鍵を利用して、別のアプリケーションとの間で暗号通信を行う。例えば、アプリケーション２００ａは、アプリケーション鍵を用いて、アプリケーション間の通信リンク４００上でアプリケーション２００ｂとの間で暗号通信を行う。アプリケーションは、ノードとともに一体として実現されても良いし、ノードから独立した端末として実現されても良い。図１は、アプリケーションがノードと一体として実現される例を示しており、以降で説明する図２は、アプリケーションがノードから独立した端末として実現される例に相当する。

図２は、アプリケーション間の暗号通信と鍵の提供を示す図である。ノードＡには複数のアプリケーションＡ、Ｂ、Ｃが接続している。ノードＢには複数のアプリケーションα、β、γが接続している。ノードＡとノードＢは暗号通信ネットワーク３００を構成している。ノードＡは複数のアプリケーション鍵５００ＡをアプリケーションＡ、Ｂ、Ｃに分配する。ノードＢは複数のアプリケーション鍵５００Ｂをアプリケーションα、β、γに分配する。例えばインターネット４００を利用して、アプリケーションＡはアプリケーションαと暗号通信を行い、アプリケーションＢはアプリケーションβと暗号通信を行い、アプリケーションＣはアプリケーションγと暗号通信を行う。

このような場合、どのアプリケーション鍵をどのアプリケーションに提供するかをノードＡとノードＢの間で合意し、次に使用するアプリケーション鍵をノード間で同期する方法が明らかでない。また、アプリケーションによる暗号通信が新たに開始および終了する際に、ノードＡとノードＢとの間でどのようにアプリケーション鍵の割り当てを行うかが明らかでない。さらに、ノードにおいて、最初にアプリケーション鍵の生成を開始するタイミングも明らかでない。

上記の問題に対処する一般的な方法として、次の２つの方法が考えられる。それぞれ次に述べるようなメリットとデメリットがある。

方法１は、アプリケーションによる暗号通信の開始のセッションや終了のセッションに関連付けて、アプリケーション鍵のノード間での共有や生成を開始するというものである。この方法１は、アプリケーション単位で局所的に管理を行なうものであり、アプリケーション鍵の同期を維持しやすいというメリットがある。しかし、方法１では、アプリケーションが暗号通信を開始する前にあらかじめアプリケーション鍵を共有しておくような最適化が困難である。また方法１を採用した場合、アプリケーションが終了すると、該アプリケーションについて共有済みのアプリケーション鍵は一般的に破棄されることになる。したがって、アプリケーション鍵の有効利用ができない。

方法２は、アプリケーション鍵交換を、アプリケーションから独立してノードを主体として行うというものである。アプリケーションに対するアプリケーション鍵の割り当ては、ノードに従う。方法２は、個々のアプリケーションではなくノードが集中的に管理を行うものである。この場合、暗号通信開始前にアプリケーション鍵を共有しておくような最適化が可能である。また方法２では、あるアプリケーションが終了した際に、既に共有済みのアプリケーション鍵を別のアプリケーションに融通する等、アプリケーション鍵の有効利用がしやすい。

しかし、１つのノードに複数のアプリケーションが接続し、それらの開始および終了が非同期で発生する状況において、アプリケーション鍵の同期を全てのアプリケーションにわたって維持することに技術的な困難性がある。この点に関して具体的な方法は確立されていない。

そして以下に説明する実施形態は、アプリケーション鍵の有効利用というメリットを享受し得る上述の方法２を基礎とし、かつアプリケーション鍵の適切な同期を実現する。

一実施形態では、ノード間のアプリケーション鍵の共有および同期に関して、次のような２階層型のアーキテクチャを導入する。

第１の階層においては、相手ノードとのアプリケーション鍵の交換を開始または終了するためのノードベースのシグナリング処理を行う。第１の階層は、次に説明する第２の階層から独立しており、アプリケーション鍵のノード間の共有を、アプリケーションによる暗号通信（以下、「セッション」という）の発生有無とは無関係に、効率的に行うことができる。

第２の階層においては、新たなセッションが発生し、およびセッションが終了するたびに、ノードが各セッションにアプリケーション鍵を割り当てるための通信を行う。具体的には、相手ノードと共有するセッションへのアプリケーション鍵の割り当てのルールを該相手ノードと同期するためのセッションベースのシグナリング処理を行う。これによれば、ノードは、アプリケーション（セッション）毎のアプリケーション鍵の同期を保証しながら、アプリケーション（セッション）から要求されたアプリケーション鍵を割り当てることができる。

図３は、実施形態に係るノードを示すブロック図である。ノード１００は、図１に示した例えばノード１００ａであり、図２ではノードＡに対応するものであって、ノード間通信部１０１、アプリケーション鍵の生成部１０２、アプリケーション鍵の同期制御部１０３、状態管理部１０４、アプリケーション鍵の保持部１０５、アプリケーション通信部１０６、ノードプラットホーム１０７で構成される。

ノード間通信部１０１は、ノード間の暗号通信リンク１０によって接続された対向ノード（図２のノードＢ）との間で、量子暗号通信を用いて、乱数を生成および共有する。生成された乱数はリンク鍵として管理される。リンク鍵は、ノード間の暗号通信リンク１０を介して接続された他のノードとの間でノード間データ通信を行う際に利用される。ノード間データ通信は、データをリンク鍵を用いて暗号化する暗号通信である。

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

アプリケーション鍵の生成部（以下、「鍵生成部」という）１０２は、乱数としてアプリケーション鍵（Ａｐｐ Ｋｅｙ）を生成する。生成されたアプリケーション鍵には、鍵ＩＤ（Ｋｅｙ ＩＤ）が付加される。アプリケーション鍵の鍵ＩＤのフォーマットは特に定めないが、例えば連続した数字によりその順序が識別されるものとする。生成されたアプリケーション鍵そのものは、後述する保持部１０５に保持される。なお、鍵ＩＤの付与（対応づけ）を鍵生成部１０２ではなく保持部１０５が行っても良い。

保持部１０５は、アプリケーション鍵を保持する。ここに保持されるアプリケーション鍵は、鍵生成部１０２によって生成されたものと、ノード間通信部１０１を介して別のノードから受信したものとがある。

ノード１００が保持しているアプリケーション鍵は、アプリケーション２００に提供される。具体的には、ノード１００の保持部１０５に保持されたアプリケーション鍵をアプリケーション通信部１０６が取り出し、ノード−アプリケーション間のリンク２０を介してアプリケーション２００の鍵取得部２０１に送信する。このノード−アプリケーション間の通信については、例えば、本願と同一出願人による出願に係る特願２０１２−６７７１９号明細書に記載の方法が利用可能である。

アプリケーション２００に提供された鍵は、保持部１０５から削除されても良い。保持部１０５で保持されるアプリケーション鍵は、暗号通信システムにおけるセキュリティ上もっとも重要なデータの一つであるため、ファイルシステムやオペレーティングシステム（ＯＳ）によって暗号化、改竄防止、アクセス制限等のセキュリティ対策が施されていても良い。保持部１０５は、様々な実現方法が可能であるが、ファイルシステムやデータベースとして実装することができる。

アプリケーション通信部１０６は、ノード−アプリケーション間のリンク２０を介してアプリケーション２００と接続して通信し、アプリケーション２００からの要求を受け付ける。この要求には、アプリケーション２００からの暗号通信開始／終了要求（すなわちアプリケーション鍵提供開始／終了要求）、アプリケーション鍵取得要求等がある。

アプリケーション２００によって行われる個々の暗号通信のことを「セッション」と呼ぶ。セッションには、セッション識別子（ｓｅｓｓｉｏｎ ＩＤ）が付与される。セッションの情報は後述の状態管理部１０４によって管理される。セッションの情報は、どのようなセッションが存在するか、どのセッションにどのアプリケーション鍵を割り当てているか等を表す。

またアプリケーション通信部１０６は、アプリケーション２００の鍵取得部２０１に対してアプリケーション鍵のデータを提供する。アプリケーション２００にアプリケーション鍵のデータを提供する際の単位は、ノード１００がアプリケーション鍵を他のノードと交換する際の単位とは異なっても良い。このため、アプリケーション通信部１０６および保持部１０５は、セッションに割り当て済みのアプリケーション鍵のうち、どの部分までの鍵のデータを提供済みであるかを管理する。

状態管理部１０４は、前述のセッションの情報、アプリケーション鍵交換に関連するルールや状況の情報といった各種の状態情報を管理する。これら情報は、前述のアプリケーション通信部１０６あるいは次に説明する同期制御部１０３によって参照および変更される。

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

同期制御部１０３は、本実施形態の特徴的な部分である。同期制御部１０３は、ノード間通信部１０１、鍵生成部１０２、保持部１０５、アプリケーション通信部１０６を次のように制御する。

・保持部１０５が保持しているアプリケーション鍵をノード間通信部１０１がノード間の暗号通信リンク１０を介して相手ノードに送信する。

・ノード間通信部１０１がノード間の暗号通信リンク１０を介して相手ノードからアプリケーション鍵を受信し、これを保持部１０５が保持する。

・鍵生成部１０２がアプリケーション鍵を生成する。

・アプリケーション通信部１０６がアプリケーション２００から様々な要求を受信し、これに応じて、ノード間通信部１０１がノード間の暗号通信リンク１０を介して相手ノードとの間でアプリケーション鍵割り当てのためのシグナリングプロトコルを実行する。

・アプリケーション通信部１０６が、シグナリングプロトコルの実行結果に従い、保持部１０５に保持されたアプリケーション鍵のセッションへの割り当て開始／終了を行う。

以上説明した実施形態に係るノードの構成はあくまで一例である。

図４は、実施形態に係るアプリケーションを示すブロック図である。アプリケーション２００は、鍵取得部２０１、アプリケーション間通信部２０２、アプリケーション実行部２０３、アプリケーションプラットホーム２０４で構成される。

鍵取得部２０１は、ノード間の暗号通信リンク１０を介して接続されたノード１００（具体的にはノード１００のアプリケーション通信部１０６）と通信し、アプリケーション２００が暗号通信を行うために必要なアプリケーション鍵をノード１００から取得する。

鍵取得部２０１は、アプリケーション鍵の取得を開始するにあたり、アプリケーション鍵取得の開始要求を行い、アプリケーション鍵の取得を終了する際にはアプリケーション鍵取得の終了要求を行う。これによって区別されるアプリケーション鍵の利用がセッションとして識別される。鍵取得部２０１は、取得したアプリケーション鍵を保持、管理する。これは、アプリケーション間通信部２０２によるアプリケーション間の暗号通信に使用される。

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

アプリケーション間通信部２０２は、アプリケーション実行部２０３の動作に必要な通信機能、通信データの暗号化、復号化の機能を提供するものである。アプリケーション間通信部２０２は、アプリケーション実行部２０３からの送信データを受けとると、これを暗号化し、アプリケーション間の暗号通信リンク３０を介して送信する。

また、アプリケーション間通信部２０２は、アプリケーション間の暗号通信リンク３０からデータを受信すると、これを復号化し、アプリケーション実行部２０３に渡す。暗号化および復号化で必要になった場合は、鍵取得部２０１に対して新たな鍵取得を要求する。

本実施形態において、アプリケーション間通信部２０２がどのような暗号アルゴリズムを使うかは特に規定しない。例えば、Ｖｅｒｎａｍ'ｓ Ｏｎｅ−ｔｉｍｅ Ｐａｄ（バーナム使い捨て鍵暗号）であっても良いし、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）のようなブロック暗号であっても良い。また暗号以外にメッセージ認証等を行っていても良い。ただし、アプリケーション間通信部２０２が利用する暗号アルゴリズムの少なくとも一つは、ノード１００から提供されて鍵取得部２０１が取得するアプリケーション鍵を利用するものとする。

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

以上説明した実施形態に係るアプリケーションの構成はあくまで一例である。

暗号通信開始時のシーケンス概要を図５に示す。同図は、想定ネットワーク構成を示している。ノードＡとノードＢはアプリケーション鍵を共有可能な状態にある。ノードＡにはクライアントアプリケーション２００ａが接続しており、ノードＢにはサーバアプリケーション２００ｂが接続している。ノードＡおよびノードＢ以外の他のノードがリンクを介して接続されていても良い（図示しない）。アプリケーション同士は、ノードＡとノードＢが構成するネットワークから独立した別のネットワークを介して接続されてもよい。

（１）クライアントアプリケーション２００ａは、ノードＡに対して暗号通信の開始を要求する。これに応じて、ノードＡとノードＢは、このアプリケーションのセッション用のアプリケーション鍵割り当てを開始する。アプリケーション鍵割り当て開始時の処理については後述する。

（２）クライアントアプリケーション２００ａは、ノードＡからアプリケーション鍵を取得する。

（３）クライアントアプリケーション２００ａは、ノードＡから取得したアプリケーション鍵で暗号化された暗号通信をサーバアプリケーション２００ｂとの間で開始する。

（４）サーバアプリケーション２００ｂは、復号化のために必要なアプリケーション鍵をノードＢから取得し、これにより暗号通信が成立する。

なお、上記ではサーバアプリケーション２００ｂがアプリケーション鍵を取得するのは暗号通信のデータを受け取った後としたが、暗号通信行う前に事前にノードＢからアプリケーション鍵を取得するような最適化もあり得る。

暗号通信終了時のシーケンス概要を図６に示す。

（１）クライアントアプリケーション２００ａは、ノードＡに対して暗号通信の終了を要求する。これに応じて、ノードＡとノードＢは、このアプリケーションのセッション用のアプリケーション鍵割り当てを終了する。アプリケーション鍵割り当て終了時の処理については後述する。

（２）アプリケーション鍵割り当てを終了したノードＡとノードＢはそれぞれ、クライアントアプリケーション２００ａとサーバアプリケーション２００ｂに対して暗号要求の終了を通知する。

以上の暗号通信開始要求から暗号通信終了要求までの一連の暗号通信が、セッションとして識別される。

以下、ノードＡとノードＢとの間でアプリケーション鍵を交換し、同期する通信処理について詳しく説明する。当該処理は、暗号通信開始処理と、暗号通信終了処理とに大別される。

＜暗号通信開始処理＞
図７および図８に暗号通信開始処理のフローチャートを示す。

まず、ノードＡのアプリケーション通信部１０６は、クライアントアプリケーション２００ａから暗号通信の開始要求を受け取る。これに応じて、状態管理部１０４は、クライアントアプリケーション２００ａが開始する暗号通信に関するセッションの情報を登録する。

ここで、同期制御部１０３は、現在、鍵生成部１０２が動作しているか否か（すなわち、乱数生成動作を行っているか否か）を確認する（ステップＳ１）。もし、動作していなければ、動作を開始するよう鍵生成部１０２に指示する（ステップＳ２）。ただし、既に多くの乱数が作り貯めてあり、特に新たに乱数を生成する必要性は無いと判断した場合は、何もしなくて良い。一方、鍵生成部１０２が既に動作していれば何もしない。あるいは、乱数生成動作を速め（送信レートを上げる）、より多くの乱数生成を行うように指示しても良い（ステップＳ７）。

同期制御部１０３は、状態管理部１０４を参照し、セッション情報から決定される対象ノードへの鍵割り当てが行われているか否かを確認する（ステップＳ３）。なお、本実施形態では、対象ノードを特定する方法について特に定めないが、例えば、クライアントアプリケーション２００ａが暗号通信の開始要求に対象ノードのアドレスを明示的に指定したり、対象ノードのアドレスを事前に状態管理部１０４に登録したり、ディレクトリサービスを利用して、対象ノードのアドレスを求めてもよい。

対象ノードへの鍵割り当てが行われていないならば（ステップＳ３：ＮＯ）、対象ノードに対するノードベースのシグナリング処理を開始する（ステップＳ４）。ノードベースのシグナリング処理（ステップＳ５）においては、（１）開始のシグナリングおよび（２）アプリケーション鍵および鍵ＩＤ（Ａｐｐ Ｋｅｙ＋Ｋｅｙ ＩＤ）を対象ノードに送信し（ステップＳ５−１）、対象ノードからそのＡｃｋ（確認応答）を受信する（ステップＳ５−２）。以後、アプリケーション鍵および鍵ＩＤの送信を継続的に行う（ステップＳ６）。

一方、対象ノードへの鍵割り当てが既に開始しているならば（ステップＳ３：ＹＥＳ）、図８のステップＳ８に進む。あるいは、追加的にステップＳ５のノードベースのシグナリング処理を実行することによりノードベースの鍵割り当ての処理を速め、より多くのアプリケーション鍵共有が行うようにしても良い。

同期制御部１０３は、ノードベースのシグナリング処理に伴う変更結果を状態管理部１０４に登録する。アプリケーション鍵を送信する際には、鍵生成部１０２が生成し保持部１０５が保持しているアプリケーション鍵をノード間通信部１０１が対象ノードに送信する。アプリケーション鍵を対象ノードから受信した際には、これを保持部１０５が保持する。以上の処理により、ノード間でのアプリケーション鍵の共有が完了する。

図８のステップＳ８において、同期制御部１０３は、状態管理部１０４を参照し、暗号通信の開始要求を受けたクライアントアプリケーション２００ａに対応する対象セッションへの鍵割り当てが既に開始されているか否かを確認する。もし、開始されているならば（ステップＳ８：ＹＥＳ）、以後の処理を行わずに終了してもよいが、クライアントアプリケーション２００ａから暗号通信の開始要求を受け付けたことはセッション確立の重複要求であるため、これをエラーとしてクライアントアプリケーション２００ａに通知する（ステップＳ１１）。

対象セッションへの鍵割り当てが開始されていない場合（ステップＳ８：ＮＯ）、対象セッションを含む新しいセッションベースのシグナリング処理を開始する（ステップＳ９）。

セッションベースのシグナリング処理（ステップＳ１０）においては、（１）新しいセッションＩＤ（ｓｅｓｓｉｏｎ ＩＤ）を含むセッション開始シグナリングと、（２）新しいセッションベースの鍵割り当てのルールと、（３）旧ルール下での各セッションの最後のアプリケーション鍵（Ａｐｐ Ｋｅｙ）の鍵ＩＤ（Ｋｅｙ ＩＤ）とを対象ノードに送信する（ステップＳ１０−１）。これに応じて、新ルール下での各セッションの最初のアプリケーション鍵（Ａｐｐ Ｋｅｙ）の鍵ＩＤ（Ｋｅｙ ＩＤ）を含むＡｃｋ（確認応答）を対象ノードから受信する（ステップＳ１０−２）。

以上により、各セッションに対する鍵割り当てのルールが決定され、ノード間で合意される。つまり、ノード間で、各セッションに利用するアプリケーション鍵の割り当てが決定する。この決定された鍵割り当てのルールは、状態管理部１０４に格納される。

クライアントアプリケーション２００ａからの要求に応じて、最初のアプリケーション鍵のデータを例えば鍵ストリームとして提供してもよい。具体的には、アプリケーション通信部１０６が、クライアントアプリケーション２００ａから要求を受けると、同期制御部１０３は、状態管理部１０４が管理している割り当てルールに従って該当セッションに割り当てるべき最初のアプリケーション鍵を特定し、これを保持部１０５から取得してアプリケーション通信部１０６に渡す。アプリケーション通信部１０６では、このアプリケーション鍵を保持し、クライアントアプリケーション２００ａが要求する適切なサイズの鍵データをアプリケーション鍵から切り出し、これをクライアントアプリケーション２００ａに提供する。

一つのアプリケーション鍵をクライアントアプリケーション２００ａに提供し終えると、アプリケーション通信部１０６は、同期制御部１０３に依頼して次のアプリケーション鍵を取得し、クライアントアプリケーション２００ａへのアプリケーション鍵の提供を継続する。なお、アプリケーション通信部１０６は、クライアントアプリケーション２００ａからの要求に即時に対応できるよう、複数（例えば２つ）のアプリケーション鍵をバッファしておき、該バッファを通じてアプリケーション鍵の提供を行ってもよい。

図９に、暗号通信開始時のノードベースのシグナリング処理およびセッションベースのシグナリング処理のシーケンスを示す。

ノードベースのシグナリング処理は、図７のステップＳ５に対応するノード間の通信処理である。セッションベースのシグナリング処理は、図８のステップＳ１０に対応するノード間の通信処理である。

ノードベースのシグナリング処理では、ノードＡ（アプリケーション鍵の共有を開始する側、クライアントアプリケーション２００ａから要求を受けた側であって良い）が、ノードベースのシグナリング処理を開始する旨を示す識別子（Ｓｔａｒｔ）、鍵ＩＤ（Ｋｅｙ ＩＤ）、アプリケーション鍵（Ａｐｐ Ｋｅｙ）を含むメッセージ３０をノードＢ（相手ノード）へ送信する。メッセージ３０を受信したノードＢは、受信完了した旨を示す識別子（Ａｃｋ）、受信完了した鍵ＩＤ（Ｋｅｙ ＩＤ）を含むメッセージ３１をノードＡへ送信する。

以上の手続きが終わると、ノードＡからメッセージ３０（但し、開始の識別子は含まない）をノードＢに送信し、ノードＢからメッセージ３１を受信するというシーケンスが継続される。このシーケンスにより、ノードＡとノードＢは、アプリケーション鍵をノード単位で共有することになる。

なお、図示しないが、このメッセージ交換において、要求するアプリケーション鍵の交換速度を決定しても良い。

セッションベースのシグナリング処理では、ノードＡが、新たにセッションを追加する旨を示す識別子（オプション）、セッションの識別子（ｓｅｓｓｉｏｎ ＩＤ）、アプリケーション鍵を、新たに追加されたセッションを含む現時点で存在する全てのセッションにそれぞれ割り当てて利用するためのルール（以下、「新ルール（ｒｕｌｅ）」）、該当セッションが追加される以前に存在した全てのセッションにアプリケーション鍵をそれぞれ割り当てていたルール（以下、「旧ルール」）における各セッションの最後のアプリケーション鍵の鍵ＩＤ（Ｋｅｙ ＩＤ）を含むメッセージ３２をノードＢへ送信する。メッセージ３２を受信したノードＢは、受信完了した旨を示す識別子（Ａｃｋ）、新ルールにおいて各セッションが使用する最初のアプリケーション鍵の鍵ＩＤ（Ｋｅｙ ＩＤ）を含むメッセージ３をノードＡへ送信する。

なお、ノードＡとノードＢとの間にセッションがひとつも存在せず、初めて確立されるセッションの場合には、旧ルールに関するデータはメッセージに含める必要は無い。

ノードＡとノードＢとの間では、当然、アプリケーションに提供したアプリケーション鍵の量が異なっている可能性が考えられる。しかし、ノードＡは、旧ルール下でどこまでのアプリケーション鍵をクライアントアプリケーション２００ａに提供したかをノードＢに通知する（メッセージ３２）。これを受信したノードＢは、自身が旧ルール下でどこまでのアプリケーション鍵をサーバアプリケーション２００ｂに提供したかについての情報と比較する。そして、両者のうち、いずれかより多くのアプリケーション鍵を提供している方が使った最後のアプリケーション鍵より以前のアプリケーション鍵は旧ルールの下で提供し、あるいは廃棄し、それよりも新しいアプリケーション鍵を、新ルールの下で各セッションが使用する鍵として選定してノードＡに通知（メッセージ３３）すれば、鍵の同期の観点から、「ずれ」は生じない。

ただし、一方のノードが大量にアプリケーションにアプリケーション鍵を提供しているような場合に限っては、他方のノードでアプリケーション鍵の大量の廃棄が発生することになる可能性があり、効率的でなくなるかもしれない。

なお、上記のルールは、例えば、セッションが３つであれば、鍵ＩＤのＭＯＤ３（３で割った余り）が０、１、２の場合、それぞれ、１つめのセッション、２つめのセッション、３つめのセッションにアプリケーション鍵を割り当てて使うといったルールである。

また、ルールは、セッションが３つの場合であっても、鍵ＩＤのＭＯＤ５（５で割った余り）を計算し、ＭＯＤ５が０、１、２の場合は１つめのセッション、３の場合は２つめのセッション、４の場合は３つめのセッションにアプリケーション鍵を割り当てることを定めてもよい。これにより、特定のセッションに特に多くのアプリケーション鍵を利用させることも可能である。この場合、セッションに割り当てられるアプリケーション鍵の量の重みがセッションＩＤごとに異なる。この重みは、アプリケーションからのアプリケーション鍵の要求スループットに応じて決定されてもよい。

このようなルールがどのようなデータ表現でメッセージに含まれるかは特に定めないが、例えば（ＭＯＤ３，０：ｓｅｓｓｉｏｎ ＩＤ１，１：ｓｅｓｓｉｏｎ ＩＤ２，２：ｓｅｓｓｉｏｎ ＩＤ３）といった表現は最初に例示した場合のルールのデータ表現になり得るかもしれない。

以上により、セッションの新規追加に伴うアプリケーション鍵の割り当てが完了する。

なお、ノードベースのシグナリング処理およびセッションベースのシグナリング処理に係る通信は、全てノード間通信部１０１がノード間通信リンク１０を介してノード間で行うものとして説明した。しかし、通信の形態はこれに限定されない。例えば、セッションベースのシグナリング処理におけるセッションＩＤ、ルール、鍵ＩＤの情報に関して、ノード間通信リンク１０とは別のネットワーク（例えばインターネット等）を介してノード間で交換しても良い。また、セッションベースのシグナリング処理における、開始や受信完了を示す識別子についても、ノード間通信リンク１０とは別のネットワーク（例えばインターネット等）を介してノード間で交換しても良い。これに対し、アプリケーション鍵と、それを識別するために付与される鍵ＩＤに関しては、必ずノード間通信部１０１がノード間通信リンク１０を介して交換し、セキュリティを確保する必要がある。

＜暗号通信終了処理＞
図１０および図１１に暗号通信終了処理のフローチャートを示す。

まず、ノードＡのアプリケーション通信部１０６は、クライアントアプリケーション２００ａから暗号通信の終了要求を受け取る。これに応じて、状態管理部１０４は、クライアントアプリケーション２００ａが終了する暗号通信に関するセッションの情報を登録する。

同期制御部１０３は、状態管理部１０４を参照し、暗号通信の終了要求を受けたセッションに対応するアプリケーションの鍵割り当てが既に開始されているか否かを確認する（ステップＳ２０）。もし、開始されていないならば（ステップＳ２０：ＮＯ）、何も行わないが、クライアントアプリケーション２００ａから暗号通信の終了の要求を受け付けたことがセッション終了の重複要求であるため、これをエラーとしてクライアントアプリケーション２００ａに通知しても良い（ステップＳ２３）。

アプリケーションの鍵割り当てが既に開始されている場合（ステップＳ２０：ＹＥＳ）、終了要求を受けたセッションを削除した新しいセッションベースのシグナリング処理を開始する（ステップＳ２１）。

このセッションベースのシグナリング処理（ステップＳ２２）においては、（１）削除するセッションＩＤ（ｓｅｓｓｉｏｎ ＩＤ）を含むセッション終了シグナリングと、（２）新しいセッションベースの鍵割り当てのルールと、（３）旧ルール下での各セッションの最後のアプリケーション鍵（Ａｐｐ Ｋｅｙ）の鍵ＩＤ（Ｋｅｙ ＩＤ）とを対象ノードに送信する（ステップＳ２２−１）。これに応じて、新ルール下での各セッションの最初のアプリケーション鍵（Ａｐｐ Ｋｅｙ）の鍵ＩＤ（Ｋｅｙ ＩＤ）を含むＡｃｋ（確認応答）を対象ノードから受信する（ステップＳ２２−２）。

ノードＡとノードＢとの間では、当然、アプリケーションに提供したアプリケーション鍵の量が異なっている可能性が考えられる。しかし、ノードＡは、旧ルール下でどこまでのアプリケーション鍵をクライアントアプリケーション２００ａに提供したかをノードＢに通知する（メッセージ３４）。これを受信したノードＢは、自身が旧ルール下でどこまでのアプリケーション鍵をサーバアプリケーション２００ｂに提供したかについての情報と比較する。そして、両者のうち、いずれかより多くのアプリケーション鍵を提供している方が使った最後のアプリケーション鍵より以前のアプリケーション鍵は旧ルールの下で提供し、あるいは廃棄し、それよりも新しいアプリケーション鍵を、新ルールの下で各セッションが使用する鍵として選定してノードＡに通知（メッセージ３５）すれば、鍵の同期の観点から、「ずれ」は生じない。

以上により、セッション削除後の各セッションに対する鍵割り当てのルールが決定され、ノード間で合意される。この決定された鍵割り当てのルールは、状態管理部１０４に格納される。ただし、後述するように、該当セッションの削除により対象ノードとの間のセッションが全て無くなる場合には、以後のアプリケーション鍵の割り当て（新ルール）を決定する必要は無い。

ステップＳ２４において、同期制御部１０３は状態管理部１０４を参照し、終了要求を受けたセッションに対応する対象ノードとの間に、現時点でセッションが１つ以上存在しているか否かを確認する（ステップＳ２４）。

もし、１つ以上セッションが残っていれば、特に何もせずに処理を終了する（ステップＳ２４：ＹＥＳ）。ここで、セッションが残っているということは、対象ノードとの間で、ノードベースのシグナリング処理のシーケンス（図７のステップＳ６）が継続中であることに注意しなければならない。ここで、特に何もせずに処理を終了するのではなく、ノードベースのシグナリング処理のシーケンスを実行して、ノードベース鍵割り当ての速度を遅くし（送信レートを下げる）、無駄となる可能性の高いアプリケーション鍵共有を抑制しても良い（ステップＳ３２）。

一方、暗号通信の終了要求を受けたセッションに対応する対象ノードとの間に現時点でセッションが１つも存在しなかった場合（ステップＳ２４：ＮＯ）、同期制御部１０３は、状態管理部１０４を参照し、対象ノードとの間でノードベースの鍵割り当てが実施されているか否かを確認する（ステップＳ２５）。もし、実施されていなければロジックエラーとして処理を終了してもよい（ステップＳ３０）。実施されていれば、この対象ノードとの間のノードベースの鍵割り当てを終了するよう指示する（ステップＳ２６）。具体的には、対象ノードとの間のアプリケーション鍵交換を終了するためのノードベースのシグナリング処理を実行する（ステップＳ２７）。このノードベースのシグナリング処理では、（１）終了のシグナリングおよび（２）利用した最後のアプリケーション鍵の鍵ＩＤ（Ｋｅｙ ＩＤ）を対象ノードに送信し（ステップＳ２７−１）、対象ノードが破棄する最後のアプリケーション鍵の鍵ＩＤ（Ｋｅｙ ＩＤ）を含むＡｃｋ（確認応答）を対象ノードから受信する（ステップＳ２７−２）。そして、対象ノードに対するアプリケーション鍵およびその鍵ＩＤ（Ａｐｐ Ｋｅｙ＋Ｋｅｙ ＩＤ）の送信を終了する（ステップＳ２８）。

次に、同期制御部１０３は、状態管理部１０４を参照し、現時点で１つ以上のノードとの間でノードベースの鍵割り当てが実施されているか否かを確認する（ステップＳ２９）。もし、実施されていなければ（ステップＳ２９：ＮＯ）、アプリケーション鍵交換が全く行われていないため、アプリケーション鍵生成を終了するように指示する（ステップＳ３１）。

図１２に、暗号通信終了時のセッションベースのシグナリング処理およびノードベースのシグナリング処理のシーケンスを示す。暗号通信の終了時では、セッションベースのシグナリング処理とノードベースのシグナリング処理が実行される順番が暗号通信の開始時とは異なる。セッションベースのシグナリング処理は、図１０のステップＳ２２で実行されるノード間の通信処理である。ノードベースのシグナリング処理は、図１１のステップＳ２７で実行されるノード間の通信処理である。

セッションベースのシグナリング処理は、暗号通信の開始時とほぼ同様である。異なる点は以下の通りである。最初に送付するメッセージ３４に、セッションの削除を示す旨の識別子（Ｓｔｏｐ）が含まれること、追加するセッションの識別子に代えて削除対象のセッションの識別子（ｓｅｓｓｉｏｎ ＩＤ）、が含まれることである。

新ルールの定義は、対象のセッションが削除された後の、全てのセッションにそれぞれ割り当てて利用するためのルールとなり、旧ルールの定義は、該当セッションが削除される以前に存在した全てのセッションに、アプリケーション鍵をそれぞれ割り当てていたルールとなることである。

図１２におけるメッセージ３５は、図９における暗号通信の開始時のメッセージ３３と同様である。

暗号通信の終了時ノードベースのシグナリング処理では、ノードＡが、ノードベースのシグナリング処理を終了する旨を示す識別子（Ｓｔｏｐ）を含むメッセージを送信する。これを受信したノードＢは、受信完了した旨を示す識別子（Ａｃｋ）を含むメッセージを送信し、ノードＡが受信する。

ただし、対象ノードとの間でアプリケーション鍵の交換を再開するためのノードベースのシグナリング処理を行う際に、以前に交換していたアプリケーション鍵を再利用し、交換したアプリケーション鍵（およびその際に使用された通信帯域）を有効活用するため、次のメッセージにデータを含める。最初のメッセージ３６には、ノードＡが利用した最後の（最新の）アプリケーション鍵の鍵ＩＤを含める。ノードＢが応答するメッセージ３７には、ノードＢが利用した最後の（最新の）アプリケーション鍵の鍵ＩＤと比較し、より新しいものを選択し、ここまでの鍵をノードＡとノードＢとの両者で廃棄する（使用した／アプリケーションに提供したことにする）ことを確認するために必要な、廃棄する最後のアプリケーション鍵の鍵ＩＤを含める。つまり、この処理によって、次に、同一のノード間でアプリケーション鍵の交換を再開した場合、ここで交換した鍵ＩＤ以降のアプリケーション鍵は、既に共有済みであり、且つ未使用のアプリケーション鍵であるとして、アプリケーション(セッション)にて利用・提供できる。これは、既に交換したアプリケーション鍵の有効利用となる。

次に、本実施形態を実現する、各ノードにおけるアプリケーション鍵の管理方法・割り当て方法（鍵管理アーキテクチャ）について、図１３を用いて説明する。同図は、ノードが生成したアプリケーション鍵、ノードが受信したアプリケーション鍵が、それぞれどのように管理されてゆくかを図示したものである。

図１３に示すように、本実施形態におけるノードの鍵管理アーキテクチャは、４つの階層（鍵生成層(Key-gen), ノードベース鍵割り当て・シグナリング層, セッションベース鍵割り当て・シグナリング層, 鍵ストリームインタフェース層）で構成される。

なお、図１３は、鍵割り当ておよびセッションの進捗に沿ってアプリケーション鍵が様々なデータとして捉えられることを意味しているのみであり、実際にアプリケーション鍵が何度もコピーされて運用されることを意味しているのでは無いことに注意されたい。

アプリケーション鍵間の矢印は、これらのアプリケーション鍵が異なる層で異なるとらえ方をされることを意味するだけであり、例えば、データベースにおける付与番号を変更したり、あるいは、データベースへのアクセス方法を単に変更したりといった、関連付けの変更のみで実現可能である。

ここでは、自身が生成するアプリケーション鍵をＯＵＴ鍵、受信するアプリケーション鍵をＩＮ鍵として区別して管理している。ＯＵＴ鍵とは、アプリケーションの暗号通信において、データの送信の際に用いる暗号化のために使うアプリケーション鍵のことである。ＩＮ鍵とは、アプリケーションの暗号通信において、データの受信の際に用いる復号化のために使うアプリケーション鍵のことである。ＯＵＴ鍵とＩＮ鍵をそれぞれ、生成したアプリケーション鍵と受信したアプリケーション鍵として対応付けるのはあくまで一例である。以下の説明ではこの例を用いることとするが、その他の対応付けも可能である。例えば、単純に逆に対応付けても構わないし、常に一方のノードでのみ鍵の生成を行い、上述の鍵の割り当て処理や鍵ＩＤ割り当てにおいて、どのＩＤを持つアプリケーション鍵がＩＮ鍵・ＯＵＴ鍵かを別途決定するような方式もありえる。さらに、アプリケーション鍵に対するＩＤの付け方についても、ここでは詳しく言及しない。ＯＵＴ鍵については、アプリケーション鍵の生成時に鍵ＩＤも同時に生成するようにしており、ＩＮ鍵については、アプリケーション鍵を受信する際に鍵ＩＤも同時に受信するようにしている。

ただし、アプリケーション鍵に割り当てられる鍵ＩＤには何通りかの種類が存在しても良い。例えば後述するように、生成時には、生成順に連番になる鍵ＩＤが、ノードに割り当てられた際にはノード毎に連番になる鍵ＩＤが、ノードにおけるセッションに割り当てられた際にはセッション毎に連番になる鍵ＩＤが、それぞれ別の種類の鍵ＩＤとして割り当てられても良い。

まず、鍵生成層(Key-gen)について説明する。鍵生成層(Key-gen)は、一般的な乱数生成器と、その鍵をアプリケーション鍵として格納するものとして構成される。

次に、ノードベース鍵割り当て・シグナリング層について説明する。

鍵生成処理５０において生成されたアプリケーション鍵（Ｋｅｙ Ｂｌｏｃｋ：ＯＵＴ鍵）は、ノードベースのシグナリング処理５１によって、宛先となるノード毎に適当に分割され、ノードで閉じた範囲でユニークな連番となるような鍵ＩＤが付与される。このアプリケーション鍵の単位が宛先ノードに送信され、共有される。

ノードベースのシグナリング処理５１によって受信したアプリケーション鍵（ＩＮ鍵）も、同様に送信元となるノード毎に別々に管理される。受信したアプリケーション鍵（Ｋｅｙ Ｂｌｏｃｋ）には、あらかじめ鍵ＩＤ（送信元となるノードに閉じた範囲でユニークな連番となるもの）が与えられている。

次に、セッションベース鍵割り当て・シグナリング層について説明する。

セッションベースのシグナリング処理５２によって、ノード毎に割り当てられたアプリケーション鍵（ＩＮ鍵およびＯＵＴ鍵とも）は、セッション毎に分割され、セッションが識別可能な形で管理されても良い。ただし、セッションへの割り当ては、アプリケーションによる暗号通信の終了や新規開始等を契機とした、セッションベースのシグナリング処理５２によって、変更され得る。

セッション毎に連番の鍵ＩＤを必ずしも付与する必要は無い。例えば、各セッションに割り当てられたアプリケーション鍵に、順番にアクセス可能なアクセス方法が与えられても良い。一例として、ノード毎に割り当てられた連番の鍵ＩＤに対して、セッションＰ（０，１，２）は、３Ｎ＋ＰにおいてＮを順番に１つづつ大きくしていくことでアクセスする、等があり得る（上記例は、セッション数が３の場合を想定）。

最後に、鍵ストリームインタフェース層について説明する。

実際にアプリケーションに提供されるアプリケーション鍵は、上述のセッションベースのシグナリング処理５２によって決定した割り当てルールによって求められる一つのアプリケーション鍵である。ただし、アプリケーションは、アプリケーション鍵のサイズをそのまま取り扱うことは考えにくい。より小さいサイズ（あるいは可変長サイズ）で、アプリケーションが鍵を要求してくる度に提供することになる。そのため、各セッション毎に、選択されたアプリケーション鍵を２つ格納可能なバッファ領域を用意しておき、アプリケーション鍵をここにコピーし、サイクリックに使ってゆく。アプリケーション鍵が一つ分無くなりそうであれば、もう一つ補充してバッファを埋めてゆく（鍵ストリームインタフェース処理５３）。このようにバッファを活用することで、アプリケーションへ鍵を提供する際の時間的遅延を削減することができる。

以下、実施形態の変形例を幾つか説明する。

本実施形態において、ノード間ではアプリケーション鍵そのものに加え、制御データ（鍵ＩＤ、セッションＩＤ等の識別子）が交換されるが、リンク鍵を用いたノード間の暗号通信において必須であるのは、アプリケーション鍵のみである。そのため、例えばセッションベースのシグナリング処理における通信や、ノードベースのシグナリング処理における終了時シーケンス等をノード間でやりとりする際に必ずしも暗号化しなくて良い。このため、上記制御データの交換時には、単純にリンク鍵を使わないノード間通信を行なうという実現方法も可能な他、（リンク鍵を用いた暗号通信を常に行なう）暗号通信ネットワークから独立した、非暗号化の通信経路をノード間に別途作成し、これを用いてノード間の制御データ交換を行なわせる実現方法も可能である。あるいは、制御データに関して、暗号化は行わず、（リンク鍵を用いて）データ認証のみを行なうように構成しても良い。

また、特にアプリケーション鍵のサイズについて言及しなかったが、一般的にはシステムにおいて一意な固定長（例えば１ＭＢｙｔｅ等）の鍵を利用する。

また、アプリケーション鍵の交換を含む全てのシグナリングの通信は、その信頼性が保証されるトランスポート上で行われることを想定している。例えば、ＴＣＰ／ＩＰ上でシグナリングを実行することは一例である。シグナリングそのものにおいても、Ａｃｋ（到達確認）メッセージを交換することで、相手ノードの受信確認を確認することができる。ただし、ＴＣＰ／ＩＰのようなトランスポート上でシグナリングを実行していても、ＴＣＰエラー（ソケットエラー・タイムアウト）等が発生する可能性がある。このような場合、以下のように対応し、復帰を試みてもよい。

１．ノードにおいて、ＴＣＰエラーを検出する。

２．現在のセッション（接続しているアプリケーション）情報を保存する。

３．検出ノードは、ノードベースのシグナリング処理（終了時）をＴＣＰエラーの対象となった通信の相手であるノードとの間で実行して、ノード間で既に共有しているアプリケーション鍵をリセットする。

４．保存してある現在のセッションを元にして、再度、ノードベースのシグナリング処理（開始時）と、必要な数のセッションベースのシグナリング処理を実行する。

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

１００ａ〜ｄ…ノード、
２００ａ，ｂ…アプリケーション、
３００ａ〜ｃ…ノード間リンク、
４００…アプリケーション間リンク、
１０１…ノード間通信部、
１０２…アプリケーション鍵の生成部、
１０３…アプリケーション鍵の同期制御部、
１０４…状態管理部、
１０５…アプリケーション鍵の保持部、
１０６…アプリケーション通信部、
１０７…ノードプラットホーム、
２０１…鍵取得部、
２０２…アプリケーション間通信部、
２０３…アプリケーション実行部、
２０４…アプリケーションプラットホーム

Claims (10)

1. 相手ノードとのアプリケーション鍵の交換を開始または終了するノードベースのシグナリング処理と、前記相手ノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記相手ノードと同期するセッションベースのシグナリング処理とに基づいて前記アプリケーション鍵の同期を制御する鍵同期制御部と、
   前記セッションを持つアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供するアプリケーション通信部と、
   を具備する通信ノード。
2. 前記鍵同期制御部は、
   前記セッションの開始時には、前記ノードベースのシグナリング処理を実行したのちに前記セッションベースのシグナリング処理を実行し、
   前記セッションの終了時には、前記セッションベースのシグナリング処理を実行したのちに前記ノードベースのシグナリング処理を実行する、請求項１記載の通信ノード。
3. 前記鍵同期制御部は、前記セッションの追加および削除に応じて前記ルールの変更を行い、当該変更がなされたルールを前記相手ノードと同期する請求項１記載の通信ノード。
4. 前記鍵同期制御部は、前記変更の前のルールに従い最後に用いられたアプリケーション鍵の鍵ＩＤと、前記変更の後のルールに従い最初に用いられるアプリケーション鍵の鍵ＩＤとを前記相手ノードと交換する請求項３記載の通信ノード。
5. 前記ルールは、前記セッションに割り当てられる前記アプリケーション鍵の量の重みがセッションＩＤごとに異なることを表す請求項１記載の通信ノード。
6. 前記相手ノードと共通に管理するセッションの数に応じて、該当ノードとの間で行なうアプリケーション鍵の交換に関する速度を変更する請求項１記載の通信ノード。
7. 前記重みは、前記アプリケーションからの前記アプリケーション鍵の要求スループットに応じて決定される請求項５記載の通信ノード。
8. 前記アプリケーション鍵は、量子暗号通信によって前記相手ノードと交換される請求項１記載の通信ノード。
9. 相手ノードとのアプリケーション鍵の交換を開始または終了するノードベースのシグナリング処理と、前記相手ノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記相手ノードと同期するセッションベースのシグナリング処理とに基づいて前記アプリケーション鍵の同期を制御すること、
   前記セッションを持つアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供すること、
   を含む鍵同期方法。
10. 第１の通信ノードと第２の通信ノードの間でアプリケーション鍵を同期する鍵同期システムであって、
    前記第１の通信ノードは、
    前記第２の通信ノードとのアプリケーション鍵の交換を開始または終了するノードベースのシグナリング処理と、前記第２のノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記第２のノードと同期するセッションベースのシグナリング処理とに基づいて前記アプリケーション鍵の同期を制御する鍵同期制御部と、
    前記セッションを持つ第１のアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供するアプリケーション通信部と、
    を具備し、
    前記第２の通信ノードは、
    前記第１の通信ノードとのアプリケーション鍵の交換を開始または終了するノードベースのシグナリング処理と、前記第１のノードと共有するセッションへの前記アプリケーション鍵の割り当てのルールを前記第１のノードと同期するセッションベースのシグナリング処理とに基づいて前記アプリケーション鍵の同期を制御する鍵同期制御部と、
    前記セッションを持つ第２のアプリケーションによる利用のために、前記ルールに従って前記アプリケーション鍵を提供するアプリケーション通信部と、
    を具備する鍵同期システム。

Images