JP2013201537A - 鍵生成装置および鍵生成方法 - Google Patents

Abstract

【課題】暗号鍵の効率的な生成および共有を行う。
【解決手段】鍵生成装置は、外部装置と接続される。鍵生成装置は、生成部と第１通信部と保持部と制御部とを備える。生成部は、暗号鍵を生成する。第１通信部は、外部装置との間で暗号鍵を送受信する。保持部は、暗号鍵を利用するアプリケーションとの間の通信の状態を表す状態情報を保持する。制御部は、状態情報に応じて、生成部が暗号鍵を生成する頻度を変更する制御、または、第１通信部が暗号鍵を送受信する頻度を変更する制御を行う。
【選択図】図２

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

しかしながら、従来技術では、リンクとは独立に生成する乱数（アプリケーション鍵）の生成タイミングや頻度などの具体的な生成手順が明らかになっていないため、アプリケーション鍵の効率的な生成・共有を行うことができない。

実施形態の鍵生成装置は、外部装置と接続される。鍵生成装置は、生成部と第１通信部と保持部と制御部とを備える。生成部は、暗号鍵を生成する。第１通信部は、外部装置との間で暗号鍵を送受信する。保持部は、暗号鍵を利用するアプリケーションとの間の通信の状態を表す状態情報を保持する。制御部は、状態情報に応じて、生成部が暗号鍵を生成する頻度を変更する制御、または、第１通信部が暗号鍵を送受信する頻度を変更する制御を行う。

本実施形態にかかる通信システムのネットワーク構成図。 ノードのブロック図。 アプリケーション鍵情報の一例を示す図。 対応情報の一例を示す図。 セッション情報の一例を示す図。 セッションの状態の一例を示す図。 アプリケーションのブロック図。 セッション開始処理のシーケンス図。 セッション継続処理のシーケンス図。 セッション終了処理のシーケンス図。 本実施形態の鍵生成装置のハードウェア構成図。

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

本実施形態にかかる鍵生成装置（ノード）は、暗号鍵（アプリケーション鍵）を利用するアプリケーションとの間の通信の状態に応じて、アプリケーション鍵の生成頻度、および、アプリケーション鍵を他のノードとの間で送受信（交換）する頻度などを制御する。

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

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

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

ノード１００は、リンクとは独立に乱数を生成する機能と、別のノードに対して生成した乱数を送信する機能とを備えてもよい。以下では、ノード１００ａおよび１００ｃ（アプリケーション２００ａ、２００ｃと接続されるノード）がこれらの機能を備える例を説明する。具体的には、図１に示す以下のようなネットワーク構成の例を説明する。
・ノード１００ａとノード１００ｂが暗号通信ネットワークであるリンク３００ａで接続され、ノード１００ｂとノード１００ｃが、暗号通信ネットワークであるリンク３００ｂで接続されているネットワークである。
・アプリケーション２００ａは、アプリケーション２００ｃと暗号通信を行う。
・アプリケーション２００ａは、暗号通信のために、ノード１００ａからアプリケーション鍵を取得する。
・アプリケーション２００ｃは、暗号通信のために、ノード１００ｃからアプリケーション鍵を取得する。

図２は、ノード１００の構成の一例を示すブロック図である。図２に示すように、ノード１００は、第１生成部１０１と、第１通信部１０２と、第２生成部１０３と、鍵管理部１０４と、第２通信部１０５と、保持部１０６と、制御部１０７と、プラットフォーム部１０８と、を備えている。

第１生成部１０１は、リンク鍵を生成・共有するリンク（リンク鍵生成共有リンク）であるリンク５１によって接続された対向ノードとの間で、乱数を生成して共有する。第１生成部１０１は、生成された乱数をリンク鍵として、自身により管理する。リンク鍵は、例えば第１生成部１０１の内部または外部の記憶装置（ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）など）に記憶されて管理される。

第１生成部１０１は、例えば量子暗号通信技術を用いて乱数を生成する。乱数生成方法はこれに限られるものではなく、従来から用いられているあらゆる乱数生成方法を適用できる。

第１通信部１０２は、他のノード１００（外部装置）との間の通信リンク（ノード間通信リンク）であるリンク５２によって接続された当該他のノード１００との間でデータの送受信（ノード間データ通信）を行う際に利用される。ここで、リンク５２は、リンク５１と同一であってもよいし、異なっていてもよい。また、リンク５２で接続された対向ノードと、リンク５１で接続された対向ノードとが同一である場合もあるし、異なる場合もある。

ノード間データ通信の相手となる他のノード１００は、リンク５２によって直接接続された対向ノード（ノード１００ａに対するノード１００ｂ）である場合もあるし、その対向ノードの別のノード間通信リンクを介してさらに接続される別のノード１００（例えばノード１００ａに対するノード１００ｃ）である場合もある。この場合、第１通信部１０２は、暗号通信ネットワークにおいて、複数のノード１００を介して通信を行うためのルーティング機能を提供してもよい。また、ノード間データ通信は、第１生成部１０１が生成・共有したリンク鍵を用いて暗号化された通信であってもよい。

第２生成部１０３は、第１生成部１０１とは独立に、乱数を生成し、生成した乱数を他のノード１００と共有する機能を持つ。他のノード１００と乱数を共有する際に、第１通信部１０２の機能を用いてもよい。第２生成部１０３が生成して共有した乱数を、アプリケーション鍵と呼ぶ。第２生成部１０３は、アプリケーション鍵の生成または／および共有を行うタイミングまたは／および頻度、並びに、アプリケーション鍵を交換するノード１００、を決定する際に、保持部１０６が保持するセッション情報（詳細は後述）を参照する。

鍵管理部１０４は、第２生成部１０３が生成して共有したアプリケーション鍵を管理する。鍵管理部１０４は、第２通信部１０５からの要求に応じて、適切なアプリケーション鍵を選択して受け渡す。

図３は、鍵管理部１０４が記憶するアプリケーション鍵情報の一例を示す図である。アプリケーション鍵情報とは、鍵管理部１０４がアプリケーション鍵の管理のために用いる情報である。アプリケーション鍵情報は、各ノード１００におけるアプリケーション鍵の共有状況を示す。図３に示すように、アプリケーション鍵情報は、相手ノードのＩＤと、生成元情報と、アプリケーション鍵とを含む。

相手ノードのＩＤは、アプリケーション鍵を共有する相手となるノード１００を識別する情報（例えばＩＰアドレス）である。生成元情報は、アプリケーション鍵の生成元を特定する情報である。例えば、生成元情報が１のとき、自装置がアプリケーション鍵を生成したことを表す。また、生成元情報が０のとき、アプリケーション鍵を共有する他のノード１００が当該アプリケーション鍵を生成したことを表す。

通常、ノード１００は、複数の他のノード１００とアプリケーション鍵を共有する。また、ノード１００は、１つの他のノード１００との間に複数のアプリケーション鍵を共有する。

アプリケーション鍵情報は、少なくとも相手ノードのＩＤとアプリケーション鍵を含めばよく、例えば生成元情報は含まなくてもよい。また、アプリケーション情報は、アプリケーション鍵自体を含んでもよいし、アプリケーション鍵へのリンクまたはアプリケーション鍵のＩＤのみを含むように構成してもよい。また、アプリケーション鍵情報では、アプリケーション鍵を利用するセッション（鍵利用セッション）ごとの区別は行わない。

鍵管理部１０４は、例えば図示しない記憶部に記憶される対応情報（アプリケーションディレクトリ）を参照してアプリケーション２００とノード１００との接続関係を特定する。図４は、対応情報の一例を示す図である。図４に示すように、対応情報は、アプリケーションのＩＤと、ノードのＩＤとを含む。アプリケーションのＩＤは、アプリケーション２００を識別する情報である。ノードのＩＤは、対応するアプリケーション２００と接続されるノード１００を識別する情報である。アプリケーションのＩＤ、および、ノードのＩＤは、例えばそれぞれアプリケーション２００のＩＰアドレスおよびノード１００のＩＰアドレスである。

例えば、図１の例では、アプリケーション２００ａから、アプリケーション２００ｃとの通信にアプリケーション鍵を利用したい旨の通知を受けるノード１００ａは、アプリケーション２００ｃの情報から、これが接続されているノードであるノード１００ｃを特定する必要がある。ノード１００ａの鍵管理部１０４は、この特定処理のために図４のような特定情報を参照する。

なお、各ノード１００が特定情報を取得する方法については、特に限定しない。例えば、アプリケーション２００からの登録を受け付けたノード１００が全てのノード１００に対して情報を通知するようにしてもよい。また、所定のサーバなどで特定情報を集中管理し、必要に応じて各ノードがこのサーバに対して特定情報を問い合わせるようにしてもよい。

図２に戻る。第２通信部１０５は、アプリケーション２００との間の通信リンク（アプリケーション通信リンク）によって接続された当該アプリケーション２００との間でデータ通信を行う際に利用される。例えば、第２通信部１０５は、アプリケーション２００からの要求を受け付け、アプリケーション２００に対してアプリケーション鍵を提供する。

ここで、アプリケーション通信リンクについては特に規定しないため、アプリケーション２００は、何らかのネットワークを介してノード１００と接続される別のコンピュータ上に存在していてもよい。この場合、ノード１００とアプリケーション２００とを接続するネットワーク上では、ファイアウォール、データの暗号化、およびデータの認証等、既存のネットワークセキュリティ機能が実現されていてもよい。アプリケーション２００がノード１００上に存在し、ソフトウェアのＡＰＩ（Application Program Interface）を介して第２通信部１０５と接続していてもよい。

また、アプリケーション２００とノード１００（すなわち第２通信部１０５）との間の通信、すなわち、ノード１００とアプリケーション２００との間で実施されるアプリケーション鍵の要求および取得のための通信は、セッション情報を用いて管理される。セッション情報は、ノード１００とアプリケーション２００との間の通信の状態（ステート）を表す情報（状態情報）である。

また、アプリケーション２００が暗号通信を行う際に、アプリケーション２００から接続される２つのノード１００は、その暗号通信に関して同一のまたは関連付けられたセッション情報を共有する。すなわち、例えばアプリケーション２００ａとアプリケーション２００ｃとが暗号通信を行う際、アプリケーション２００ａとノード１００ａの間でセッション情報が管理され、また、ノード１００ｃとアプリケーション２００ｃとの間でセッション情報が管理される。これら２つのセッションは、同一であるか、または関連付けられる。

そのため、第２通信部１０５は、アプリケーション２００との間で何らかのセッション制御プロトコルを利用して通信してもよい。セッション制御プロトコルの一例として、例えばＳＩＰ（Session Initiation Protocol）を用いてもよい。第２通信部１０５が、さらに、セッション制御に関する情報を、暗号通信ネットワークを介して他のノード１００へ（例えばノード１００ａからノード１００ｃへ）中継するように構成してもよい。なお、このような他のノード１００との通信に際し、第２通信部１０５は、第１通信部１０２を利用することができる。

第２通信部１０５が、アプリケーション２００からの要求を検証し、検証された場合に当該アプリケーション２００との間の通信を実行するように構成してもよい。ここで、検証とは、アプリケーション２００のアプリケーション鍵利用権限の確認や、要求データの完全性確認、等である。

図２に戻る。保持部１０６は、第２通信部１０５がアプリケーション２００と通信することによって更新されるセッション情報を、鍵利用セッションごとに保持する。セッションの状態は、例えば、アプリケーション２００と通信することによって、第２通信部１０５によって遷移（更新）される。また、例えば第２通信部１０５は、鍵利用セッション開始時に対応するセッション情報を登録し、鍵利用セッション終了後に対応するセッション情報を削除する。

図５は、セッション情報の一例を示す図である。図５に示すように、セッション情報は、セッション識別子と、相手先ノードのＩＤと、アプリケーションのＩＤ１と、アプリケーションのＩＤ２と、セッションの状態と、要求スループットと、を含む。

セッション識別子は、セッションを識別する情報である。相手先ノードのＩＤは、通信相手となるノード１００のＩＤである。アプリケーションのＩＤ１は、自装置に対応する（接続される）アプリケーション２００のＩＤである。アプリケーションのＩＤ２は、通信相手となるノード１００に対応する（接続される）アプリケーション２００のＩＤである。

要求スループットは、自装置に対応するアプリケーション２００（アプリケーションのＩＤ１で識別されるアプリケーション２００）が要求する鍵の利用頻度を表す。アプリケーション２００は、例えば通信のたびに、ノード１００に対して安全なアプリケーション鍵の生成（利用）を要求する。このような通信ごとにアプリケーション鍵の生成は、例えば、理論的に解読不可能なワンタイムパッド暗号を用いた通信の場合などに必要となる。アプリケーション２００は、例えば予測される通信量などに応じて、必要となる鍵生成のスループット（要求スループット）を変更し、ノード１００に通知する。ノード１００は、通知された要求スループットをセッション情報内に保持する。要求スループットの指定方法は問わないが、例えば単位時間あたりに必要とするアプリケーション鍵の個数を指定するように構成できる。

セッション情報に含まれる各ＩＤは、例えばＩＰアドレス、または、ＩＰアドレスとポート番号との組として表されてもよい。また、セッション識別子を、対応するアプリケーション２００のＩＰアドレス（またはＩＰアドレスとポート番号）で表すように構成してもよい。この場合、アプリケーションのＩＤ１は省略してもよい。

図６は、セッションの状態の一例を示す図である。図６では、セッションの状態として「開始中」、「接続中」および「終了中」の３つの状態と、各状態間の状態遷移の例が示されている。セッションの状態はこれに限定されるものではない。

初期状態から「開始中」状態（状態７０１）へは、例えば、ノード１００が、対応するアプリケーション２００から、アプリケーション鍵の利用開始要求を受信した場合に遷移する（遷移７１１）。「開始中」状態から「接続中」状態（状態７０２）へは、例えば、ノード１００が、対応するアプリケーション２００に対して、アプリケーション鍵の提供を開始した場合に遷移する（遷移７１２）。

ノード１００が、対応するアプリケーション２００から、要求スループットの変更要求を受信した場合には、「接続中」状態から「接続中」状態に遷移する（遷移７１３）。

「接続中」状態から「終了中」状態（状態７０３）へは、例えば、ノード１００が、対応するアプリケーション２００から、アプリケーション鍵の利用停止要求を受信した場合に遷移する（遷移７１４）。

「終了中」状態は、例えば、ノード１００が、対応するアプリケーション２００から、セッション情報の削除を完了したときに、終了状態に遷移する（遷移７１５）。

図２に戻る。制御部１０７は、図５に示すようなセッション情報を参照して、他のノード１００との間でのアプリケーション鍵の生成および共有を制御する。例えば、制御部１０７は、セッション状態が接続中の鍵利用セッションの数、要求スループットの値の合計、および、保持部１０６にて管理するセッション情報の相手先ノード毎の数等に応じて、第２生成部１０３がアプリケーション鍵を生成する頻度を変更する。また、制御部１０７は、セッション状態が接続中の鍵利用セッションの数、要求スループットの値の合計、および、保持部１０６にて管理するセッション情報の相手先ノード毎の数等に応じて、第１通信部１０２がアプリケーション鍵を他のノード１００に送信する頻度を変更する。

アプリケーション鍵を生成する頻度とは、第２生成部１０３が第１生成部１０１とは独立に、アプリケーション鍵（乱数）を生成する頻度である。アプリケーション鍵を共有（交換）する頻度とは、既に生成されたアプリケーション鍵を実際に通信相手のノード１００との間で送受信（交換）して互いに共有する頻度である。生成するとともに送受信も行う場合は、両者（アプリケーション鍵を生成する頻度、および、アプリケーション鍵を共有する頻度）を同じ意味に扱ってもよい。

例えば、制御部１０７は、接続中の鍵利用セッションの数の増加に応じて、アプリケーション鍵を生成する頻度を増加させる。増加させる程度は問わないが、例えば、鍵利用セッションの個数に比例するようにアプリケーション鍵を生成する頻度を増加させてもよい。また、例えば、制御部１０７は、各鍵利用セッションのセッション情報に含まれる要求スループットの合計値の増加に応じて、アプリケーション鍵を生成する頻度を増加させる。

また、制御部１０７は、アプリケーション鍵の生成または／および共有を行うノード１００を、セッション情報に含まれる相手先ノードのＩＤによって決定する。

なお、制御部１０７は、セッション情報が削除された場合、すなわち、他のノード１００に接続されたアプリケーション２００との間で暗号通信を行っていない場合には、他のノード１００との間でアプリケーション鍵を生成して共有する動作を終了してもよい。

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

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

通信部２０１は、ノード１００との間の通信リンク（リンク５３）を介して、ノード１００（具体的にはノード１００の第２通信部１０５）と接続して各種データを送受信する。例えば、通信部２０１は、暗号通信を行うために必要なアプリケーション鍵をノード１００から取得する。通信部２０１は、ノード１００からアプリケーション鍵を取得する通信に際して、ノード１００との間でセッションの確立を行ってもよい。なお、このセッションの情報は、ノード１００を介して、アプリケーション２００による暗号通信の相手となるアプリケーション２００、および、そのアプリケーション２００が接続するノード１００と共有されてもよい。

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

暗号処理部２０２は、アプリケーション鍵を用いた暗号処理を行う。例えば、暗号処理部２０２は、通信部２０１が取得したアプリケーション鍵を保持し、アプリケーション鍵を利用して、暗号通信を行う上で必要なデータの暗号化処理と復号処理を行う。なお、利用する暗号アルゴリズムは特に限定しない。例えば、ＡＥＳ（Advanced Encryption Standard）の様なブロック暗号であってもよいし、ＯＴＰ（One-time Pad）の様なバーナム暗号であってもよい。

実行部２０３は、暗号通信を行うアプリケーション機能を実行する。通信を行うものであれば特にアプリケーション機能の種類は限定しない。例えば、実行部２０３は、ビデオ送信等の機能を実行する。実行部２０３は、送信データを通信部２０４へと受け渡し、受信データを通信部２０４から受け取る。

通信部２０４は、実行部２０３の動作に必要な通信機能を提供する。また、データ通信の際には、暗号処理部２０２を用いてデータの暗号化と復号を行うことができる。通信部２０４は、アプリケーション２００から送信データを受けとると、暗号処理部２０２を用いてこれを暗号化し、データ通信リンク（リンク５４）を介してデータを送信する。データ通信リンクは、通信相手のアプリケーション２００との間でデータを送受信するためのリンクである。また、通信部２０４は、データ通信リンクからデータを受信すると、暗号処理部２０２を用いて受信したデータを復号し、アプリケーション２００へと復号したデータを受け渡す。

プラットフォーム部２０５は、アプリケーション２００上の他の構成要素の管理や、動作に必要なコンピュータのオペレーティングシステム機能等を提供する。

以上、本実施形態におけるアプリケーション２００の構成について説明した。上記説明は一例であり、例えばアプリケーション２００が、アプリケーション鍵を格納するための記憶部（ストレージ）に対する読み書きを制御する機能（通信部２０１）のみを備えるように構成してもよい。

次に、本実施形態における３つの基本シーケンスについて説明する。図８は、本実施形態におけるセッション開始処理の全体の流れを示すシーケンス図である。セッション開始処理は、アプリケーション２００ａがアプリケーション２００ｃとの間で暗号通信を開始する際に、アプリケーション２００ａ、ノード１００ａ、ノード１００ｃ、および、アプリケーション２００ｃとの間で実施される。

アプリケーション２００ａは、ノード１００ａに対して、アプリケーション鍵の要求を開始するためのメッセージ（開始要求メッセージ）を送信する（ステップＳ１０１）。開始要求メッセージは、例えばアプリケーション２００ａの暗号通信の相手となるアプリケーション２００ｃのＩＤ（ＩＰアドレスと接続するポート番号）に関する情報を含む。

開始要求メッセージが、確立するセッションを識別するためのセッション識別子（例えば、アプリケーション２００ａに割り当てられたＩＰアドレスと、アプリケーション２００ａがアプリケーション２００ｃと通信するために用いるアプリケーション２００ａのポート番号）を含んでもよい。さらに開始要求メッセージが、アプリケーション２００ａが、アプリケーション２００ｃとの暗号通信に際して利用すると思われるアプリケーション鍵の利用頻度に関する情報（例えば、アプリケーション２００ａが予測するアプリケーション２００ｃとの間の通信スループットと関連する要求スループット）等を含んでもよい。

この時点で、ノード１００ａの第２通信部１０５は、鍵利用セッションに関する情報の管理を開始し、そのセッション状態は開始中となる。

なお、上述のように第２通信部１０５が開始要求メッセージを転送するためのアプリケーション２００とノード１００との間の通信のメッセージフォーマットやプロトコルについては特に限定しない。例えば、セッション制御プロトコルを用いてもよい。セッション制御プロトコルの一例としてＳＩＰを用いてもよい。

開始要求メッセージを受け取ったノード１００ａは、図４に示すアプリケーションディレクトリの機能を利用するなどにより、通信相手を特定する（ステップＳ１０２）。例えば、ノード１００ａの鍵管理部１０４は、アプリケーション２００ａが指定した通信相手であるアプリケーション２００ｃの特定と、アプリケーション２００ｃが暗号通信の際に利用するノード１００であるノード１００ｃの特定を行う。

また、第２通信部１０５は、本暗号通信に関連付けられるセッション識別子（必要なら生成する）、アプリケーション２００ａ、ノード１００ｃ、および、アプリケーション２００ｃを関連付けたセッション情報を生成し、保持部１０６に保持させる。第２通信部１０５が、ノード１００ａがアプリケーション２００ｃ、およびノード１００ｃを特定したことを確認するためのメッセージをアプリケーション２００ａに対して送信してもよい（ステップＳ１０３）。

ノード１００ａの第１通信部１０２は、開始要求メッセージにて受け取った情報である、アプリケーション２００ｃのＩＤ（例えば、ＩＰアドレスと接続するポート番号）に関する情報、および、本暗号通信に関連付けられるセッション識別子を含むメッセージ（鍵要求メッセージ）を、ノード１００ｃに対して送信する（ステップＳ１０４）。鍵要求メッセージが、メッセージの送信元であるノード１００ａおよびアプリケーション２００ａの情報を含んでいてもよい。ノード１００ａとノード１００ｃとの間のメッセージの交換は、一般に暗号化され、図１のリンク３００を介して行われる。

なお、鍵要求メッセージを転送するためのノード間（ノード１００ａとノード１００ｃとの間）の通信のメッセージフォーマットやプロトコルについては特に限定しない。第１通信部１０２が、前述のアプリケーション２００ａとノード１００ａとの間の通信と同一のメッセージフォーマットやプロトコルを用いてもよいし、異なるものを用いてもよい。例えば、セッション制御プロトコルを用いてもよい。セッション制御プロトコルの一例としてＳＩＰを用いてもよい。

ノード１００ｃの第２通信部１０５は、鍵要求メッセージを受け取ると、鍵要求メッセージに含まれるデータから、関連付けられるセッション識別子、アプリケーション２００ａ、ノード１００ａ、および、アプリケーション２００ｃを関連付けたセッション情報を生成し、保持部１０６に保持させる（ステップＳ１０５）。第２通信部１０５が、鍵要求メッセージに含まれるアプリケーション２００ｃのＩＤに関する情報を含むメッセージ（要求元メッセージ）を、アプリケーション２００ｃに対して通知してもよい（ステップＳ１０６）。また、要求元メッセージは、メッセージの送信元であるノード１００ａおよびアプリケーション２００ａの情報を含んでいてもよい。

この時点で、ノード１００ｃの第２通信部１０５は、鍵利用セッションに関する情報の管理を開始し、そのセッション状態は開始中となる。

アプリケーション２００ｃは、要求元メッセージに含まれる、メッセージの送信元であるノード１００ａおよびアプリケーション２００ａの情報、または、アプリケーション２００ａが指定するアプリケーション鍵の利用頻度に関する情報（例えば、アプリケーション２００ａが予測するアプリケーション２００ｃとの間の通信スループットと関連する要求スループット）に基づいて、アプリケーション２００ａとの暗号通信を受け入れるか否かを判定する（ステップＳ１０７）。アプリケーション２００ｃは、判定結果を、メッセージ（結果メッセージ）としてノード１００ｃに通知してもよい（ステップＳ１０８）。

ノード１００ｃは、結果メッセージを受けとると、結果メッセージを、ノード１００ａへと通知する（ステップＳ１０９）。

ノード１００ａは、鍵利用セッションのためのアプリケーション鍵生成および割り当てを行うアプリケーション鍵共有処理を開始する（ステップＳ１１０）。具体的には、制御部１０７が、第２生成部１０３および第１通信部１０２を用いて、ノード１００ｃとの間で、アプリケーション鍵の共有を開始する。なお、ノード１００ａが生成および共有を開始したアプリケーション鍵をノード１００ｃが受け取った場合、ノード１００ｃが、受け取り応答メッセージをノード１００ａに対して送信してもよい。

以後、ノード１００ａとノード１００ｃとの間のアプリケーション鍵共有処理は、本セッションの状態が終了状態となるまで継続する。このとき、制御部１０７は、アプリケーション鍵共有処理を行う頻度を、ノード１００ａが保持するアプリケーション鍵の利用頻度に関する情報（要求スループット）に基づいて決定する。なお、制御部１０７は、鍵利用セッションに関連付けられた対向ノードであることから、生成するアプリケーション鍵を共有する相手をノード１００ｃであると決定してもよい。さらに制御部１０７は、アプリケーション鍵の利用頻度を、保持する他の鍵利用セッションの状態（対向ノードごと）や、保持する他のアプリケーション鍵の利用頻度の合計（対向ノードごと）等、対応する鍵利用セッション以外のセッション情報をも参照して得られる情報に基づいて決定してもよい。

ノード１００ａは、ノード１００ｃとの共有が完了した鍵のうちの１つを、アプリケーション２００ａに対して通知する（ステップＳ１１１）。この通知のためのメッセージ（鍵通知メッセージ）は、セッション識別子の情報を含んでもよい。また、この時点で、ノード１００ａが保持する鍵利用セッションの状態は、接続中となる。

鍵通知メッセージによるノード１００ａからアプリケーション２００ａへのアプリケーション鍵通知のイベントは、ノード１００ｃにも通知される（ステップＳ１１２）。なお、このときの通知のためのメッセージにてアプリケーション鍵を共有してもよい。

ノード１００ｃは、ノード１００ａとの共有が完了した鍵のうちの１つを、アプリケーション２００ｃに対して通知する（ステップＳ１１３）。この通知のためのメッセージ（鍵通知メッセージ）は、セッション識別子の情報を含んでもよい。また、この時点で、ノード１００ｃが保持する鍵利用セッションの状態は、接続中となる。

図９は、本実施形態におけるセッション継続処理の全体の流れを示すシーケンス図である。セッション継続処理は、暗号通信を行っているアプリケーション２００ａおよびアプリケーション２００ｃにおいて、データの送受信に伴い、新しいアプリケーション鍵が必要となったため、アプリケーション鍵をノード１００ａまたはノード１００ｃから取得する際に実施される。

アプリケーション２００ａは、ノード１００ａに対して、アプリケーション鍵の追加要求を行うためのメッセージ（追加要求メッセージ）を送信する（ステップＳ２０１）。追加要求メッセージは、セッション識別子、要求するアプリケーション鍵のサイズ、および、要求するアプリケーション鍵の用途（送信用・受信用）などが含まれてよい。

追加要求メッセージを受け取ったノード１００ａの鍵管理部１０４は、追加要求メッセージに含まれるセッション識別子等から、アプリケーション２００ａに受け渡すアプリケーション鍵を特定する（ステップＳ２０２）。このとき、第２通信部１０５が、セッション識別子によって別途特定されるノード１００ｃに対して、アプリケーション２００ａに対してアプリケーション鍵を追加提供する旨を通知するメッセージを送信し（ステップＳ２０３）、ノード１００ｃからアプリケーション２００ｃへのアプリケーション鍵の提供を同期して実行してもよい。

この場合、ステップＳ２０３で送信されたメッセージによって通知を受けたノード１００ｃは、アプリケーション２００ｃに対して、アプリケーション鍵を含むメッセージを通知してもよい（図示しない）。この場合、本シーケンスのステップＳ２０５〜ステップＳ２０８は実行しなくてもよい。

ノード１００ａの第２通信部１０５は、アプリケーション２００ａに対して、特定した追加のアプリケーション鍵を含むメッセージを通知する（ステップＳ２０４）。このメッセージは、セッション識別子の情報を含んでもよい。

なお、これらのアプリケーション鍵の追加提供が行われている際にも、鍵利用セッションが接続中となっているため、ノード１００ａとノード１００ｃの間のアプリケーション鍵共有処理（図８のステップＳ１１０）は継続して行われる。

アプリケーション２００ｃは、ノード１００ｃに対して、アプリケーション鍵の追加要求を行うためのメッセージ（追加要求メッセージ）を送信する（ステップＳ２０５）。追加要求メッセージは、セッション識別子、要求するアプリケーション鍵のサイズ、および、要求するアプリケーション鍵の用途（送信用・受信用）などが含まれてよい。通常、用途は、アプリケーション２００ａが指定したものと逆になる。例えば、アプリケーション２００ａから暗号化されたデータを受信した際に、このデータを復号するアプリケーション鍵を取得するため、追加要求メッセージの送信を開始するなどのケースがありうる。

追加要求メッセージを受け取ったノード１００ｃの鍵管理部１０４は、追加要求メッセージに含まれるセッション識別子等から、アプリケーション２００ｃに受け渡すアプリケーション鍵を特定する（ステップＳ２０６）。このとき、第２通信部１０５が、セッション識別子によって別途特定されるノード１００ａに対して、アプリケーション２００ｃに対してアプリケーション鍵を追加提供する旨を通知するメッセージを送信し（ステップＳ２０７）、ノード１００ａからアプリケーション２００ａへのアプリケーション鍵の提供を同期して実行してもよい。

ノード１００ｃは、アプリケーション２００ｃに対して、特定した追加のアプリケーション鍵を含むメッセージを通知する（ステップＳ２０８）。このメッセージは、セッション識別子の情報を含んでもよい。

図８に示すように、本実施形態では、アプリケーション鍵の利用開始が要求されたときに、アプリケーション鍵共有処理を開始する。そして、セッション状態に応じてアプリケーション鍵の生成頻度または交換頻度などを制御して、必要な量のアプリケーション鍵を複数のノード１００間で共有しておくことができる。これにより、アプリケーション２００が必要なときにアプリケーション鍵が枯渇することなく、適切に暗号通信を実行できる。すなわち、図９に示すように、実際に追加のアプリケーション鍵が必要になった場合に、適切な頻度で生成および交換済みのアプリケーション鍵をアプリケーション２００に提供することができる。このように、本実施形態によれば、アプリケーション鍵を効率的に生成および共有できる。

図１０は、本実施形態におけるセッション終了処理の全体の流れを示すシーケンス図である。セッション終了処理は、アプリケーション２００ａとアプリケーション２００ｃにおいて実行されていた暗号通信を終了させ、今後アプリケーション鍵を利用することがないときに、鍵利用セッションを終了するために実行される。

アプリケーション２００ａは、ノード１００ａに対して、アプリケーション鍵を以後利用しない旨を通知するためのメッセージ（終了メッセージ）を送信する（ステップＳ３０１）。終了メッセージは、セッション識別子等を含んでもよい。

ノード１００ａの第２通信部１０５は、終了メッセージを受け取る。この時点で、ノード１００ａが保持する鍵利用セッションの状態は、終了中となる。また、ノード１００ａの制御部１０７は、セッションの状態が終了中に遷移したことから、ノード１００ｃとの間で鍵利用セッションのために実行していたアプリケーション鍵共有処理を停止してもよい。

ノード１００ａの第２通信部１０５は、セッション終了処理を実行する（ステップＳ３０２）。例えば、第２通信部１０５は、受け取った終了メッセージに含まれるセッション識別子に対応するセッション情報を削除する。

なお、異なるセッションが別途アプリケーション鍵を利用中等の場合、すなわち、セッション状態が接続中であるセッションが存在している場合は、アプリケーション鍵共有処理を継続してもよい。ノード１００ａは、ノード１００ｃと共有しているアプリケーション鍵の終了処理を行うため、ノード１００ｃに対して終了することを通知してもよい（ステップＳ３０３）。

ノード１００ａの第２通信部１０５は、鍵利用セッションに関連付けられていた情報の削除が完了すると、アプリケーション２００ａに対して削除が完了したことを通知するメッセージ（削除完了メッセージ）を送信する（ステップＳ３０４）。削除完了メッセージは、削除が完了した鍵利用セッションの情報が含まれていてもよい。この時点で、鍵利用セッションに関する情報はノード１００ａから削除されてもよい。

一方、アプリケーション２００ｃは、ノード１００ｃに対して、アプリケーション鍵を以後利用しない旨を通知するためのメッセージ（終了メッセージ）を送信する（ステップＳ３０５）。終了メッセージは、セッション識別子等を含んでもよい。

ノード１００ｃの第２通信部１０５は、終了メッセージを受け取る。この時点で、ノード１００ｃが保持する鍵利用セッションの状態は、終了中となる。また、ノード１００ｃの制御部１０７は、セッションの状態が終了中に遷移したことから、ノード１００ａとの間で鍵利用セッションのために実行していたアプリケーション鍵共有処理を停止してもよい。

ノード１００ｃの第２通信部１０５は、セッション終了処理を実行する（ステップＳ３０６）。例えば、第２通信部１０５は、受け取った終了メッセージに含まれるセッション識別子に対応するセッション情報を削除する。

なお、異なるセッションが別途アプリケーション鍵を利用中等の場合、すなわち、セッション状態が接続中であるセッションが存在している場合は、アプリケーション鍵共有処理を継続してもよい。ノード１００ｃは、ノード１００ａと共有しているアプリケーション鍵の終了処理を行うため、ノード１００ａに対して終了することを通知してもよい（ステップＳ３０７）。

ノード１００ｃの第２通信部１０５は、鍵利用セッションに関連付けられていた情報の削除が完了すると、アプリケーション２００ｃに対して削除が完了したことを通知するメッセージ（削除完了メッセージ）を送信する（ステップＳ３０８）。削除完了メッセージは、削除が完了した鍵利用セッションの情報が含まれていてもよい。この時点で、鍵利用セッションに関する情報はノード１００ｃから削除されてもよい。

なお、上記の各シーケンスに記載はないが、アプリケーション２００から要求スループットを変更する要求を受信した際、各ノード１００が、セッション情報に関連付けられている要求スループットを変更してもよい。この場合、ノード１００は、相手ノード（ノード１００ａに対するノード１００ｃなど）にも要求スループットの変更を通知し、相手ノードにおいても要求スループットを変更してもよい。そして、変更された要求スループットに応じて、ノード１００がアプリケーション鍵を生成して共有する頻度を変更してもよい。

以上説明したとおり、本実施形態によれば、アプリケーションとの間のセッションの状態に応じて暗号鍵（アプリケーション鍵）を生成する頻度や交換する頻度を変更する。これにより、アプリケーション鍵を効率的に生成および共有することができる。

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

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

本実施形態にかかる鍵生成装置は、ＣＰＵ（Central Processing Unit）３５１などの制御装置と、ＲＯＭ（Read Only Memory）３５２やＲＡＭ（Random Access Memory）３５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ３５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス３６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。

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

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

また、本実施形態の鍵生成プログラムを、ＲＯＭ３５２等に予め組み込んで提供するように構成してもよい。

本実施形態にかかる鍵生成装置で実行される鍵生成プログラムは、上述した各部（第１生成部、第１通信部、第２生成部、鍵管理部、第２通信部、保持部、制御部、プラットフォーム部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ３５１（プロセッサ）が上記記憶媒体から鍵生成プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

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

１００ ノード
１０１ 第１生成部
１０２ 第１通信部
１０３ 第２生成部
１０４ 鍵管理部
１０５ 第２通信部
１０６ 保持部
１０７ 制御部
１０８ プラットフォーム部
２００ アプリケーション
２０１ 通信部
２０２ 暗号処理部
２０３ 実行部
２０４ 通信部
２０５ プラットフォーム部

Claims (10)

1. 外部装置と接続される鍵生成装置であって、
   暗号鍵を生成する生成部と、
   前記外部装置との間で前記暗号鍵を送受信する第１通信部と、
   前記暗号鍵を利用するアプリケーションとの間の通信の状態を表す状態情報を保持する保持部と、
   前記状態情報に応じて、前記生成部が前記暗号鍵を生成する頻度を変更する制御、または、前記第１通信部が前記暗号鍵を送受信する頻度を変更する制御を行う制御部と、
   を備える鍵生成装置。
2. 前記制御部は、前記アプリケーションとの間の通信の個数に応じて、前記生成部が前記暗号鍵を生成する頻度を変更する制御、または、前記第１通信部が前記暗号鍵を送受信する頻度を変更する制御を行う、
   請求項１に記載の鍵生成装置。
3. 前記状態情報は、前記アプリケーションが要求した前記暗号鍵の利用頻度を含み、
   前記制御部は、前記状態情報に含まれる前記利用頻度に応じて、前記生成部が前記暗号鍵を生成する頻度を変更する制御、または、前記第１通信部が前記暗号鍵を送受信する頻度を変更する制御を行う、
   請求項１に記載の鍵生成装置。
4. 前記制御部は、さらに、前記アプリケーションからの要求に応じて、前記保持部が保持する前記状態情報に含まれる前記利用頻度を更新し、更新した前記利用頻度に応じて、前記生成部が前記暗号鍵を生成する頻度を変更する制御、または、前記第１通信部が前記暗号鍵を送受信する頻度を変更する制御を行う、
   請求項３に記載の鍵生成装置。
5. 予め定められたセッション制御プロトコルに従って前記アプリケーションとの間で情報を送受信する第２通信部をさらに備え、
   前記保持部は、前記セッション制御プロトコルによる通信の状態を表す前記状態情報を保持する、
   請求項１に記載の鍵生成装置。
6. 前記セッション制御プロトコルは、ＳＩＰ（Session Initiation Protocol）である、
   請求項５に記載の鍵生成装置。
7. 前記第２通信部は、前記アプリケーションからの要求を検証し、要求が検証された場合に、前記アプリケーションとの間で情報を送受信する、
   請求項５に記載の鍵生成装置。
8. 前記保持部は、記憶部に前記暗号鍵を記憶する機能を備えるアプリケーションとの間の通信の状態を表す前記状態情報を保持する、
   請求項１に記載の鍵生成装置。
9. 前記制御部は、前記状態情報に応じて前記暗号鍵を送受信する前記外部装置を決定する、
   請求項１に記載の鍵生成装置。
10. 外部装置と接続される鍵生成装置で実行される鍵生成方法であって、
    暗号鍵を生成する生成ステップと、
    前記外部装置との間で前記暗号鍵を送受信する通信ステップと、
    前記暗号鍵を利用するアプリケーションとの間の通信の状態を表す状態情報を保持する保持ステップと、
    前記状態情報に応じて、前記生成ステップが前記暗号鍵を生成する頻度を変更する制御、または、前記通信ステップが前記暗号鍵を送受信する頻度を変更する制御を行う制御ステップと、
    を含む鍵生成方法。

Images