JP5784562B2

JP5784562B2 - 通信装置およびプログラム

Info

Publication number: JP5784562B2
Application number: JP2012197249A
Authority: JP
Inventors: 佳道谷澤; 英昭佐藤; 川村　信一; 信一川村
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2012-09-07
Filing date: 2012-09-07
Publication date: 2015-09-24
Anticipated expiration: 2032-09-07
Also published as: JP2014053787A; US9083682B2; US20140181508A1

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

しかしながら、従来技術では、暗号通信ネットワークを利用して暗号通信機能を利用するアプリケーションは、暗号通信ネットワークに対する事前のアドレス登録、暗号通信ネットワークに対する通信指示、および、鍵取得など、煩雑な処理手順が必要である。そのため、既存のアプリケーションから暗号通信ネットワークを利用した暗号通信を実現することは困難であった。

実施形態の通信装置は、暗号処理部と、第１通信部と、制御部と、を備える。暗号処理部は、外部装置と第１ネットワークを介する暗号通信のための暗号機能を実行する。第１通信部は、暗号通信で用いる暗号鍵を生成する鍵生成装置との間で第２ネットワークを介する通信を行う。制御部は、暗号通信で用いられる要求のうち予め定められた特定要求が送信された場合に、アドレス情報を含むアドレス登録要求を、第１通信部を介して鍵生成装置に送信する制御を行う。

本実施形態にかかる通信システムのネットワーク構成図。本実施形態にかかる通信システムのネットワーク構成図。本実施形態にかかる通信システムのネットワーク構成図。本実施形態のクライアント側のライブラリのブロック図。本実施形態のサーバ側のライブラリのブロック図。本実施形態のアプリケーションのブロック図。本実施形態のＳＳＬ通信の手順の一例を示す図。本実施形態のアドレス登録処理、アドレス共有処理、および、アドレス検索処理の例を説明する図。本実施形態のサービスマッピング情報の一例を示す図。本実施形態のアドレス登録処理、アドレス検索処理、および、アプリケーション鍵取得処理のシーケンス図。本実施形態の暗号データ通信処理のシーケンス図。本実施形態の暗号データ通信終了処理のシーケンス図。本実施形態にかかる通信装置のハードウェア構成図。

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

（本実施形態）
本実施形態にかかる通信装置は、暗号通信ネットワークの暗号機能を利用するためのアドレス登録処理を自動化する。例えば、一般的な、既存暗号ライブラリのＡＰＩ（Application Program Interface）により、アドレス登録、通信指示および鍵取得などの暗号通信ネットワークとの通信処理を適宜呼び出し、適切な暗号通信ネットワーク利用手順を実行する。

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

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

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

図２は、本実施形態にかかる通信システムのネットワーク構成例を示す図である。図２は、図１に示すネットワーク構成例のアプリケーション２００がノードと独立に構成され、且つライブラリ３００（３００ａ、３００ｂ）を備えることを示す図である。ネットワーク５０１（第１ネットワーク）は、図１の暗号通信（アプリケーション鍵利用）に対応する。ネットワーク５０２（第２ネットワーク）は、図１の乱数共有・暗号通信（リンク鍵利用）に対応する。以下では、ネットワーク５０１をアプリケーションネットワークと言い、ネットワーク５０２を暗号通信ネットワークと言う場合がある。

図２に示すように、アプリケーション２００には、クライアントとして動作するアプリケーション２００（アプリケーションクライアント）と、サーバとして動作するアプリケーション２００（アプリケーションサーバ）とがある。なお、両者の機能を共に備えるように構成してもよい。以下では、アプリケーション２００ａがアプリケーションクライアントであり、アプリケーション２００ｂがアプリケーションサーバである場合を例として説明する。

本実施形態では、ライブラリ機能（図２のライブラリ３００ａ、３００ｂ）を導入する。図２は、アプリケーション２００の一部としてライブラリ機能を実現する例を示す。ライブラリ機能をアプリケーション２００から独立し、アプリケーション２００とノード１００との中間に設置される独立した通信装置（ライブラリ装置）として実現してもよい。図３は、このように構成した通信システムのネットワーク構成例を示す図である。すなわち、図３は、ライブラリ機能を備えないアプリケーション２００−２ａ、２００−２ｂの外部にライブラリ３００ａ、３００ｂを備える例である。

以下では、図２のようにアプリケーション２００の一部としてライブラリ機能を実現する場合を例に説明する。

ライブラリ３００は、アプリケーション２００が、暗号通信ネットワークの機能を利用して暗号通信を行うために必要となる処理を、アプリケーション２００に隠蔽した形で行う。図４は、クライアント側のライブラリ機能に相当するライブラリ３００ａの構成例を示すブロック図である。図４に示すように、ライブラリ３００ａは、受付部３０１ａと、制御部３０２ａと、第１通信部３０３ａと、鍵管理部３０４ａと、第２通信部３０５ａと、を備えている。

受付部３０１ａは、アプリケーション２００ａからの、暗号通信に関する要求を受け付ける。制御部３０２ａは、装置全体の動作を制御する。

第１通信部３０３ａは、アプリケーション２００ａからの要求を受けて、ノード１００との間で必要となる暗号通信ネットワークを介した通信（鍵の要求、鍵の取得、アドレス登録、および、アドレス検索等）を行う。

鍵管理部３０４ａは、ノード１００から取得した鍵を、アプリケーション２００ａが利用するまでの間、保持して管理する。

第２通信部３０５ａは、アプリケーション２００ａの代わりに、アプリケーションネットワーク上の暗号データ通信を行う。なお、通信そのものはアプリケーション２００ａが行い、第２通信部３０５ａが、通信に必要なデータの暗号化および復号等の一部の機能（暗号機能）のみを担ってもよい。提供可能な暗号機能の１つとして、鍵管理部で保持するアプリケーション鍵を利用して、暗号通信を行う上で必要なデータの暗号化処理と復号処理を行ってもよい。なお、暗号機能が利用する暗号アルゴリズム（暗号方式）の種類・バリエーションについては特に限定は行わない。アプリケーション鍵を利用してもしなくてもよいし、また、例えば、ＡＥＳ（Advanced Encryption Standard）の様なブロック暗号であってもよいし、ＯＴＰ（One-time Pad）の様なバーナム暗号であってもよい。

図５は、サーバ側のライブラリ機能に相当するライブラリ３００ｂの構成例を示すブロック図である。図５に示すように、ライブラリ３００ｂは、受付部３０１ｂと、制御部３０２ｂと、第１通信部３０３ｂと、鍵管理部３０４ｂと、第２通信部３０５ｂと、を備えている。

受付部３０１ｂは、アプリケーション２００ｂからの、暗号通信に関する要求を受け付ける。

制御部３０２ｂは、装置全体の動作を制御する。例えば制御部３０２ｂは、暗号通信で用いられる要求のうち予め定められた特定要求が送信された場合に、アドレス情報を含むアドレス登録要求を、第１通信部３０３ｂを介してノード１００に送信する制御を行う。

鍵管理部３０４ｂは、ノード１００から取得した鍵を、アプリケーション２００ｂが利用するまでの間、保持して管理する。

第２通信部３０５ｂは、アプリケーション２００ｂの代わりに、アプリケーションネットワーク上の暗号データ通信を行う。なお、通信そのものはアプリケーション２００ｂが行い、第２通信部３０５ｂが、通信に必要なデータの暗号化および復号等の一部の機能（暗号機能）のみを担ってもよい。提供可能な暗号機能の１つとして、鍵管理部で保持するアプリケーション鍵を利用して、暗号通信を行う上で必要なデータの暗号化処理と復号処理を行ってもよい。なお、暗号機能が利用する暗号アルゴリズム（暗号方式）の種類・バリエーションについては特に限定は行わない。アプリケーション鍵を利用してもしなくてもよいし、また、例えば、ＡＥＳ（Advanced Encryption Standard）の様なブロック暗号であってもよいし、ＯＴＰ（One-time Pad）の様なバーナム暗号であってもよい。

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

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

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

暗号通信部２０２は、他のアプリケーション２００などの外部装置とアプリケーションネットワークを介する暗号通信を行う。このとき、暗号通信部２０２は、前述のライブラリ３００の機能を利用して、暗号処理・復号化処理を行なう。また、暗号化したデータの送信処理や、暗号化された(復号化前の)データの受信処理は、ライブラリ３００が行なっても良いし、暗号通信部２０２が行なっても良い。

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

図４〜図６の各部は、例えば、ＣＰＵ（Central Processing Unit）などの処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Integrated Circuit）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。

次に、本実施形態における基本的な処理手順について説明する。本実施形態の説明にあたり、アプリケーション２００は、一般的な既存暗号（古典暗号）ライブラリであるＳＳＬ（またはＴＬＳ）のＡＰＩに従って作成されているものとする。実際には、ＳＳＬのＡＰＩに限らず、コンテキストの生成、コネクションの確立、暗号データの送受信、および、コネクションの解放、といった手順を実現する暗号通信ライブラリＡＰＩであれば適用可能である。

図７は、本実施形態のＳＳＬ通信の手順の一例を示す図である。図７は、ＳＳＬ通信の手順と、その際に呼び出されるＡＰＩの例を示している。図７に従って、基本的なＳＳＬライブラリによる通信の手順を説明する。

まず、アプリケーション２００ａ、２００ｂは、それぞれ暗号通信ライブラリＡＰＩを初期化する（SSL＿Library＿init：ステップＳ１０１、ステップＳ１０２）。アプリケーション２００ａ、２００ｂは、利用する（または利用可能な）暗号パラメータを設定してコンテキストを生成する（SSL＿CTX＿new：ステップＳ１０３、ステップＳ１０４）。

アプリケーション２００ａ、２００ｂは、ソケットを作成し（socket：ステップＳ１０５、socket,bind,listen：ステップＳ１０６）、コネクションを確立する（connect：ステップＳ１０７、accept：ステップＳ１０８）。この手順はＳＳＬライブラリそのものの手順ではなく、ネットワーク通信に必要な手順である。

アプリケーション２００ａ、２００ｂは、ＳＳＬコネクション構造体を生成する（SSL＿new：ステップＳ１０９、ステップＳ１１０）。アプリケーション２００ａ、２００ｂは、生成したＳＳＬコネクション構造体とソケットとを関連付ける（SSL＿set＿fd：ステップＳ１１１、ステップＳ１１２）。

アプリケーション２００ａ、２００ｂは、ＳＳＬのハンドシェイク（SSL HS）を実行する（SSL＿connect：ステップＳ１１３、SSL＿accept：ステップＳ１１４）。このステップで、暗号通信に利用する暗号パラメータのネゴシエーションと、必要な通信相手の認証とを行う。この結果、ＳＳＬのコネクションが確立する。

アプリケーション２００ａ、２００ｂは、データ（Data）の送受信を行う（SSL＿read/write：ステップＳ１１５、ステップＳ１１６）。データは送信時に暗号化され、受信時に復号される。

必要な通信を終えると、アプリケーション２００ａ、２００ｂは、ＳＳＬのコネクションを開放する（SSL＿shutdown：ステップＳ１１７、ステップＳ１１８）。アプリケーション２００ａ、２００ｂは、ＳＳＬコネクション構造体を破棄する（SSL＿free：ステップＳ１１９、ステップＳ１２０）。

アプリケーション２００ａ、２００ｂは、ソケットを閉じる（close：ステップＳ１２１、ステップＳ１２２）。この手順はＳＳＬライブラリそのものの手順ではなく、ネットワーク通信に必要な手順である。

アプリケーション２００ａ、２００ｂは、コンテキストを破棄する（SSL＿CTX＿free：ステップＳ１２３、ステップＳ１２４）。

本実施形態では、ライブラリ３００ａ、３００ｂを用いることにより、以下の（１）〜（４）の手順がさらに実行される。これにより、暗号通信ネットワークを利用した暗号通信が利用可能となる。

（１）ステップＳ１０３、ステップＳ１０４で暗号パラメータを設定する際、暗号通信ネットワークを利用する暗号についても、選択およびパラメータ設定可能とする。暗号通信ネットワークを利用する暗号のパラメータは、例えば、単純に暗号通信ネットワークによる暗号通信の利用可否を示すパラメータであってもよい。また、このパラメータが、暗号通信ネットワークを利用する暗号通信の場合に、要求する暗号鍵の取得頻度に関する情報を含んでいてもよい。取得した暗号鍵を利用して、どのような暗号アルゴリズムで実際の暗号通信を行うかを指定するパラメータでもよい。もし、複数の暗号通信ネットワークが存在する場合には、いずれの暗号通信ネットワークを利用した暗号通信を行うのかを指定する識別子等であってもよい。具体的なライブラリＡＰＩとして、例えばSSL＿CTX＿new（）を利用してもよい。

（２）ステップＳ１１３、ステップＳ１１４で暗号パラメータのネゴシエーションを行った結果、暗号通信ネットワークを利用した暗号通信を行うことが決定した場合、さらに、暗号通信ネットワークを利用して暗号通信を行うために必要な様々な初期化処理を行う。１つは、暗号通信ネットワークを介して同一の暗号鍵（アプリケーション鍵）を共有するために必要な、アドレス登録および検索の処理である。もう１つは、暗号通信または認証を行うために必要な、暗号鍵（アプリケーション鍵）の取得である。これらを行うためには、ノード１００に対してアドレス情報を通知したり、アプリケーション鍵の取得要求を送信したりしてよい。具体的なライブラリＡＰＩとして、例えばSSL＿connect（）およびSSL＿accept（）を利用してもよい。

（３）ステップＳ１１５、ステップＳ１１６で暗号通信ネットワークを利用した暗号通信（データの暗号通信）を行うためには、アプリケーション鍵を定期的に取得する必要がある。このため、ノード１００に対してアプリケーション鍵を要求し、取得する処理と、取得したアプリケーション鍵を利用して通信データを暗号化または復号する処理を行ってもよい。具体的なライブラリＡＰＩとして、例えばSSL＿read（）およびSSL＿write（）を利用してもよい。

（４）ステップＳ１１７、ステップＳ１１８で暗号通信ネットワークを利用した暗号通信（データの暗号通信）を終了するために、ノード１００に対してアプリケーション鍵の利用終了を通知してもよい。具体的なライブラリＡＰＩとして、例えばSSL＿shutdown（）を利用してもよい。

次に、本実施形態のライブラリ３００（制御部３０２）が実行する暗号通信ネットワークにおけるアドレス登録処理、暗号通信ネットワークで行われるアドレス共有処理、および、ライブラリ３００（制御部３０２）が実行するアドレス検索処理について図８および図９を用いて説明する。図８は、アドレス登録処理、アドレス共有処理、および、アドレス検索処理の例を説明するための図である。図９は、ノード１００間で共有される情報（サービスマッピング情報）の一例を示す図である。

アプリケーションクライアント（アプリケーション２００ａ）が、あるアプリケーションサーバ（アプリケーション２００ｂ）との間で、暗号通信を行うために利用するアプリケーション鍵を取得したいとする。このとき、アプリケーションクライアントが接続しているノード１００ａは、アプリケーションサーバが接続しているノード１００ｂとの間で、アプリケーション鍵を交換し、それぞれアプリケーションクライアントとアプリケーションサーバに対して同一のアプリケーション鍵を提供する必要がある。

図８は、この機能を実現するための手順を示す図である。なお、「ＡＰＰ（Ｓ）」は、アプリケーションサーバであるアプリケーション２００（アプリケーション２００ｂ）を表す。「ＡＰＰ（Ｃ）」は、アプリケーションクライアントであるアプリケーション２００（アプリケーション２００ａ）を表す。図８では、通信システムが、４つのアプリケーションサーバ（アプリケーション２００ｂ１〜２００ｂ４）と、５つのノード１００ａ〜１００ｅを含む例が示されている。

アプリケーションサーバは、自身のサーバ機能を起動すると、そのサービス情報を、接続しているノード１００に対して通知する（ステップＳ２０１）。サービス情報は、少なくとも、アプリケーションサーバのＩＰアドレスを含んだ情報である。サービス情報は、サービスが利用するポート番号、サービスの種類を示す識別情報、サービスを利用するために必要なインタフェースに関する情報、および、サービスを利用するために要求されるスループット等を含んでもよい。アプリケーションサーバが、サービス情報をノードに対して通知する処理をアドレス登録処理と呼ぶ。

なお、特に図示しないが、アプリケーションサーバは、例えばアプリケーションサーバが動作するコンピュータが移動する等の影響により、割り当てられるＩＰアドレス等のサービス情報が変更される場合がある。この場合、アプリケーションサーバは、ステップＳ２０１と同様の方式で、ノード１００に対して、ＩＰアドレスが変更される旨を通知してよい。また、アブレーションサーバが、サービスを停止する際も、ステップＳ２０１と同様の方式で、ノード１００に対して、サービスを停止する旨を通知してよい。

ノード１００は、上述のサービス情報を、自身の識別子（一般的にはＩＰアドレス情報）と関連付ける。ノード１００は、サービス情報と識別子とを関連づけた情報（サービスマッピング情報）を、暗号通信ネットワークを構成する他のノード１００と共有する（ステップＳ２０２）。

図９は、サービスマッピング情報の一例を示す図である。サービスマッピング情報は、アプリケーションサーバのＩＰアドレスと、アプリケーションサーバのポート番号と、対応するノード１００のＩＰアドレスと、を含む。

ノード１００同士が、サービスマッピング情報を共有する方法については、特に限定しない。例えば、ノード１００が、暗号通信ネットワークを構成するすべてのノード１００に対して、自身のサービスマッピング情報を通知することで共有してもよい。また、暗号通信ネットワークにおいて、代表となるノード１００（代表ノード）を利用して、サービスマッピング情報を共有してもよい。すなわち、すべてのサービスマッピング情報が代表ノードに通知され、代表ノードがディレクトリサービスとして振る舞うことで、サービスマッピング情報が暗号通信ネットワーク上のすべてのノード１００で共有されるように構成してもよい。

次に、アプリケーションクライアントが、あるアプリケーションサーバと通信したいとする。アプリケーションクライアントは、自身が接続するノード１００ａに対して、自分が通信したいアプリケーションサーバのＩＰアドレスを通知する（ステップＳ２０３）。アプリケーションクライアントが、通信相手と共有されているアプリケーション鍵を取得するために、ノード１００に対して通信相手のＩＰアドレスを通知する処理を、アドレス検索処理と呼ぶ。以下では、アプリケーションクライアントがアプリケーション２００ｂ１と通信する場合を例に説明する。

アプリケーションクライアントからアプリケーションサーバ（アプリケーション２００ｂ１）のＩＰアドレスを通知されたノード１００ａは、サービスマッピング情報から、そのアプリケーションサーバが接続されているノード１００ｂのＩＰアドレスを取得し、ノード１００ｂとの間で、必要なアプリケーション鍵の共有処理を開始する（ステップＳ２０４）。このとき、ノード１００ａは、アプリケーションクライアントに対して、アドレス検索処理が成功した旨の応答などを行ってもよい。また、ノード１００ｂは、ノード１００ａとの間でアプリケーション鍵の共有処理を開始する前に、接続されているアプリケーションサーバに対して、アプリケーションクライアントの情報を提示し、アプリケーション鍵の共有開始の可否を問い合わせてもよい。そして、ノード１００ｂは、問い合わせの結果に応じて、アプリケーション鍵の共有処理の実施可否やその頻度等を決定してもよい。あるいは、既に共有済みのアプリケーション鍵が十分に保持されていたり、既にアプリケーション鍵の共有処理が開始されている場合は、改めて共有処理開始（ステップＳ２０４）を行なわなくても良い。

この時点で、ノード１００ａとノード１００ｂとの間で、アプリケーション鍵の共有処理が開始できている。このため、アプリケーションクライアントおよびアプリケーションサーバは、アプリケーションネットワークを介して暗号データ通信を行うためのセッション確立に必要な、認証用アプリケーション鍵の取得処理（ステップＳ２０５）、セッション確立時の認証処理（ステップＳ２０６）、データの暗号化および復号に使うためのアプリケーション鍵の取得処理（ステップＳ２０７）、および、アプリケーションネットワークを介した実際の暗号データ通信処理（ステップＳ２０６）、を行ってよい。

本実施形態では、アプリケーション２００に代わり、ライブラリ３００が、上述した、アドレス登録処理、アドレス検索処理、必要なアプリケーション鍵の取得処理、セッション確立時の認証処理、および、暗号データ通信処理の少なくとも１つを実行する。

次に、本実施形態において、アプリケーション２００、ライブラリ３００、および、ノード１００の間で実施される詳細シーケンスの例について説明する。まず、上記（２）で実施されるアドレス登録処理、アドレス検索処理、および、最初のアプリケーション鍵取得処理について図１０を用いて説明する。

アプリケーションサーバにおいて、暗号データ通信の待ち受け状態に移行する。この処理は、例えば、アプリケーションサーバが、接続待ち要求であるSSL＿accept（）ＡＰＩを呼び出すことで開始される（ステップＳ３０１）。以後、アプリケーションサーバは待ち状態となってもよい。このように、本実施形態では、接続待ち要求（SSL＿accept）が特定要求として用いられる。暗号通信で用いられる要求（ＡＰＩ）のうち接続待ち要求（SSL＿accept）以外の要求を特定要求としてもよい。

ライブラリ３００ｂは、上記処理を検出し、接続関係にあるノード１００ｂとの間で通信を開始する（ステップＳ３０２）。このときに初めて、例えば通信のためのコネクションをノード１００ｂと確立してもよい（ステップＳ３０３）。同時に、ライブラリ３００ｂは、アプリケーションサーバのＩＰアドレス情報を含むサービス情報（アドレス登録要求）をノード１００ｂに通知する（ステップＳ３０４）。ライブラリ３００ｂは、何らかの方法でサービス情報を事前に取得しておけばよい。これにより、アドレス登録処理が実現される。

この通知を契機として、暗号通信ネットワーク上のノード１００ｂでサービスマッピング情報の共有が行われる（図示せず）。

一方、アプリケーションクライアントでは、アプリケーションサーバのＩＰアドレスを指定して暗号通信の開始（ハンドシェイク処理）が要求される（ステップＳ３０５〜ステップＳ３０７）。ハンドシェイク処理は例えば、SSL＿connect（）ＡＰＩが呼ばれることで開始される（ステップＳ３０５）。この開始要求は、アプリケーションサーバのＩＰアドレスを含む。アプリケーションクライアントは、アプリケーションサーバとの間で直接、暗号パラメータのネゴシエーションを行う（ハンドシェイク処理の一部（SSL HS：top half）、ステップＳ３０７）。なお、本ネゴシエーション処理もアプリケーションクライアントおよびアプリケーションサーバのライブラリを介して行ってもよい。以後、アプリケーションクライアントは待ち状態となってもよい。

ライブラリ３００（制御部３０２）は、ネゴシエーションの結果、アプリケーションサーバが利用する暗号アルゴリズムが、暗号鍵を利用する暗号アルゴリズムである場合に、第２通信部３０５を介した暗号通信を行うように制御する。すなわち、暗号パラメータのネゴシエーションの結果、暗号通信ネットワークを利用した暗号データ通信を行うことで合意すると、アプリケーションクライアント側のライブラリ３００ａは、接続関係にあるノード１００ａに対して、アプリケーションクライアントが通信したいアプリケーションサーバのＩＰアドレス情報を含む情報を通知する（アドレス検索処理、ステップＳ３０９）。なお、ライブラリ３００ａは、このときに初めて、例えば通信のためのコネクションをノード１００ａと確立してもよい（ステップＳ３０８）。

アプリケーションクライアントから通知を受けたノード１００ａは、共有しているサービスマッピング情報から、該当のアプリケーションサーバが接続されるノード１００を特定する。その後、ノード１００ａは、アプリケーションクライアントまたは特定したノード１００に、アプリケーションサーバを発見した旨を応答してもよい（ステップＳ３１０）。

ノード１００ａは、アプリケーション鍵の共有処理を開始する（ステップＳ３１１）。このとき、アプリケーションサーバ側のノード１００ｂは、ライブラリ３００ｂまたはアプリケーションサーバに対して、暗号通信を要求するアプリケーションクライアントのＩＰアドレス情報等を提示し、暗号通信ネットワークを介した暗号通信を行うことの可否を確認してもよい（ステップＳ３１２、ステップＳ３１３）。この結果、該当のノード間（ノード１００ａ、ノード１００ｂ）でアプリケーション鍵の共有が達成される（ステップＳ３１４）。

ノード１００ａおよびノード１００ｂは、それぞれアプリケーションクライアント（ライブラリ３００ａ）およびアプリケーションサーバ（ライブラリ３００ｂ）に対し、共有したアプリケーション鍵と、このアプリケーション鍵の共有を識別するためのセッション識別子の情報とを提供する（ステップＳ３１５、ステップＳ３１６）。

ライブラリ３００ａ、ライブラリ３００ｂは、取得したアプリケーション鍵情報を利用して、暗号通信開始のための認証処理（ハンドシェイク処理の一部（SSL HS：bottom half）、ステップＳ３１７）を行ってもよい。また、ハンドシェイク処理は、アプリケーション鍵情報を利用せずに予め別の認証処理によって完了していてもよい。ハンドシェイク処理が完了した時点で、ライブラリ３００の処理を終了し、アプリケーションクライアントおよびアプリケーションサーバに制御を戻してもよい（ステップＳ３１８、ステップＳ３１９）。

次に、上記（３）で実施される暗号データ通信の処理について図１１を用いて説明する。ノード１００ａ、ノード１００ｂの間では、図１０の処理などにより暗号通信ネットワーク内の通信が確立されている（ステップＳ４０１）。

暗号データの送信側のアプリケーション２００ｂが、データを指定して暗号通信を指示する（ステップＳ４０２、ステップＳ４０３）。なお、図１１ではアプリケーションサーバであるアプリケーション２００ｂが暗号データの送信側になった場合を例に説明するが、アプリケーションクライアント（アプリケーション２００ａ）が送信側であってもよい。暗号通信の指示は、例えば、SSL＿write（）等のＡＰＩ呼び出しであってよい。このとき一般に、通信用のデータとともに、セッションを識別するためのＩＤも指定される。ここでは、前述のセッション識別子が同時に指定されるものとする。

ライブラリ３００ｂは、送信側のアプリケーション２００ｂが、指定するデータを通信するために必要なアプリケーション鍵をノード１００ｂに対して要求する。このため、ノード１００ｂに対して、セッション識別子、必要なアプリケーション鍵のサイズ、および、鍵の用途（送信用か暗号用かなど）、等を指定したアプリケーション鍵要求を行う（ステップＳ４０４）。

ノード１００ｂは、ライブラリ３００ｂからの要求を受けて、そのセッションに関連付けら、指定された用途に利用できるアプリケーション鍵を、指定されたサイズだけ取り出し、ライブラリ３００ｂに提供する（ステップＳ４０５）。

ライブラリ３００ｂは、アプリケーション鍵を取得すると、送信側アプリケーションが指定したデータを、取得したアプリケーションを利用して暗号化する。ライブラリ３００ｂは、アプリケーションネットワークを介して、受信側のアプリケーション２００ａに対して暗号化したデータを送信する（ステップＳ４０６）。なお、アプリケーションクライアント（アプリケーション２００ａ）が送信側の場合は、アプリケーションサーバ（アプリケーション２００ｂ）が受信側となる。暗号化したデータを送信後、ライブラリ３００ｂの処理を終了し、アプリケーションサーバに制御を戻してもよい（ステップＳ４０９、ステップＳ４１０）。

ここでは、ライブラリ３００自身がデータの暗号化と暗号データの送信まで行う例を示したが、ライブラリ３００とアプリケーション２００の機能分担はこれに限られるものではない。例えば、ライブラリ３００が、アプリケーション鍵を取得してデータの暗号化を行った後、暗号化したアプリケーション鍵をアプリケーション２００に渡し、暗号データ送信はアプリケーション２００が行ってもよい。また、ライブラリ３００がアプリケーション鍵を取得すると、取得したアプリケーション鍵をアプリケーション２００に渡し、暗号化と暗号データ送信はアプリケーション２００が行ってもよい。この場合、鍵管理部３０４は、アプリケーション側に存在する構成になる。

またここでは、アプリケーション２００が、データの送信を要求してから、ライブラリ３００がアプリケーション鍵の取得を開始している。このようにすると、ライブラリ３００がノード１００からアプリケーション鍵を取得するまでの時間遅延が、暗号データ送信前に発生するため望ましくない。これを避けるために、例えば、ライブラリ３００は、アプリケーション２００からデータの送信要求を受ける前に、ある程度のアプリケーション鍵を予め取得して、自身に蓄えておくなどの最適化を行ってもよい。

一方、暗号データの受信側のアプリケーション２００ａは、例えば、SSL＿read（）等のＡＰＩ呼び出しにより暗号通信を指示する（ステップＳ４０７、ステップＳ４０８）。ライブラリ３００ａはステップＳ４０６で送信された暗号データを受信する。

ライブラリ３００ａは、受信側のアプリケーション２００ａが、受信した暗号データを復号するために必要なアプリケーション鍵をノード１００ａに対して要求する。このため、ライブラリ３００ａは、ノード１００ａに対して、セッション識別子、必要なアプリケーション鍵のサイズ、鍵の用途（受信用か復号用かなど）、等を指定したアプリケーション鍵要求を行う（ステップＳ４１１）。なお、アプリケーションネットワークから受信した暗号データから、対応するノード１００ａとの間のセッション識別子を特定するため、ライブラリにおいては、暗号データ通信のセッション識別子と、ノード１００ａとの間のセッション識別子を関連付けておく。

ノード１００ａは、ライブラリ３００ａからの要求を受けて、そのセッションに関連付けられ、指定された用途に利用できるアプリケーション鍵を、指定されたサイズだけ取り出し、ライブラリ３００ａに提供する（ステップＳ４１２）。

ライブラリ３００ａは、アプリケーション鍵を取得すると、受信したデータを復号し、アプリケーション２００ａに受け渡す（ステップＳ４１３）。

ここでは、ライブラリ３００自身がデータの受信と復号まで行う例を示したが、ライブラリ３００とアプリケーション２００の機能分担はこれに限られるものではない。例えば、ライブラリ３００がアプリケーション２００からの要求に応じてアプリケーション鍵を取得し、データの暗号化を行った後、暗号化したデータをアプリケーション２００に渡してもよい。また、ライブラリ３００がアプリケーション２００からの要求に応じてアプリケーション鍵を取得してアプリケーション２００に渡し、データの受信と復号はアプリケーションが行ってもよい。この場合、鍵管理部３０４は、アプリケーション側に存在する構成になる。

またここでは、暗号データを実際に受信してから、ライブラリ３００がアプリケーション鍵の取得を開始している。このようにすると、ライブラリ３００がノード１００からアプリケーション鍵を取得するまでの時間遅延が、暗号データ復号前に発生するため望ましくない。これを避けるために、例えば、ライブラリ３００は、実際に暗号データを受信する前（例えば、SSL＿readライブラリＡＰＩ呼び出しがなされた直前、等が一例である）に、ある程度のアプリケーション鍵を予め取得して、自身に蓄えておくなどの最適化を行ってもよい。

次に、上記（４）で実施される暗号データ通信の終了処理について図１２を用いて説明する。なお、この処理は、アプリケーションクライアント側であっても、アプリケーションサーバ側であっても同様の処理となる。

暗号データ通信を終了したいアプリケーション２００ａ（アプリケーションサーバであってもアプリケーションクライアントであってもよい）は、セッション識別子を指定して、暗号データ通信の終了を要求する。これは例えば、SSL＿shutdown（）ＡＰＩが呼ばれることで開始される（ステップＳ５０１、ステップＳ５０２）。

ライブラリ３００ａは、これを受けて、暗号データ通信セッションの終了処理を行う（ステップＳ５０３）。暗号データ通信セッションの終了処理そのものは、一般的な方法で行われ、対向のアプリケーション２００ｂ（のライブラリ３００ｂ）との間でテアダウン処理（SSL TD）が行われる。

ライブラリ３００ａはさらに、ノード１００ａに対して、セッション識別子を指定し、暗号通信ネットワークを利用した暗号データ通信をこれ以上行わない旨を通知する（ステップＳ５０４）。この通知を受けて、ノード１００ａは、該当のセッション識別子で指定される対向ノード（ノード１００ｂ）との間で行われている、アプリケーション鍵の共有処理を終了してもよいし、しなくてもよい。ただし、ノード１００ａは、対向のノード１００ｂに対して、該当のセッション識別子で行われていた暗号データ通信が終了する旨を通知する（ステップＳ５０５）。

対向のノード１００ｂは、セッションが終了すると、そのセッションに関連付けられているライブラリ３００ｂに対してその旨を通知してもよい。この時点で、ノード１００ｂまたはライブラリ３００ｂは、アプリケーション２００ｂに対して、暗号データ通信が終了したことの通知（例えばclose notify）を送信してもよい（ステップＳ５０９、ステップＳ５１０）。

ノード１００ａは、該当のセッション識別子に関連付けられているデータを削除すると、ライブラリ３００ａに対して、セッション終了の応答通知を行う（ステップＳ５０６）。以上を持って、暗号データ通信を終了したいアプリケーション２００ａにおいて、暗号データ通信が終了する（ステップＳ５０７、ステップＳ５０８）。

なお、ステップＳ５１１〜ステップＳ５２０は、アプリケーションサーバであるアプリケーション２００ｂが暗号データ通信を終了する場合の処理である。ステップＳ５１１〜ステップＳ５２０は、ステップＳ５０１〜ステップＳ５１０と同様であるため説明を省略する。

このように、本実施形態にかかる通信装置では、暗号ライブラリのＡＰＩの呼び出し手順の中で、アドレス登録、通信指示および鍵取得などの暗号通信ネットワークとの通信処理を実行するため、暗号通信ネットワークの暗号機能を利用するためのアドレス登録処理等の処理を容易に実現できる。また、既存の暗号ライブラリＡＰＩを利用している既存のアプリケーションであっても、本実施形態のライブラリを用いることで、容易に暗号通信ネットワークを利用した暗号通信が実現できる。

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

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

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

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

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

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

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

２００アプリケーション
２０１実行部
２０２暗号処理部
２０３プラットフォーム部
３００ライブラリ
３０１受付部
３０２制御部
３０３第１通信部
３０４鍵管理部
３０５第２通信部

Claims

暗号鍵を生成する複数の鍵生成装置のうち第２鍵生成装置との間で第２ネットワークを介した通信を行うことによって、前記第２鍵生成装置から暗号鍵を取得する第１通信部と、
前記複数の鍵生成装置のうち第１鍵生成装置に接続される外部装置との間で、第１ネットワークを介して、取得された前記暗号鍵を用いて暗号通信を行う暗号通信部と、
前記暗号通信で用いられる要求のうち予め定められた特定要求が送信された場合に、アドレス情報を含むアドレス登録要求を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行い、前記暗号通信部が暗号通信を行う場合に、暗号通信の通信相手となる前記外部装置のアドレス情報を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行う制御部と、
を備える通信装置。
前記特定要求は、前記暗号通信の接続待ち要求である、
請求項１に記載の通信装置。
前記制御部は、前記外部装置が利用する暗号アルゴリズムが、前記暗号鍵を利用する暗号アルゴリズムである場合に、前記暗号通信部を介して前記暗号通信を行う制御を行う、
請求項１に記載の通信装置。
前記制御部は、前記暗号通信の開始要求が送信された場合に、前記外部装置との間で暗号通信に利用する暗号パラメータのネゴシエーションを行い、前記外部装置が前記暗号鍵を利用する暗号アルゴリズムを利用することが決定された場合に、前記暗号通信部を介して前記暗号通信を行う制御を行う、
請求項３に記載の通信装置。
暗号鍵を生成する複数の鍵生成装置のうち第２鍵生成装置との間で第２ネットワークを介した通信を行うことによって、前記第２鍵生成装置から暗号鍵を取得する第１通信部と、
前記複数の鍵生成装置のうち第１鍵生成装置に接続される外部装置との間で、第１ネットワークを介して、取得された前記暗号鍵を用いて実行される暗号通信で用いられる要求のうち予め定められた特定要求が送信された場合に、アドレス情報を含むアドレス登録要求を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行い、前記暗号通信部が暗号通信を行う場合に、暗号通信の通信相手となる前記外部装置のアドレス情報を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行う制御部と、
を備える通信装置。
コンピュータを、
暗号鍵を生成する複数の鍵生成装置のうち第２鍵生成装置との間で第２ネットワークを介した通信を行うことによって、前記第２鍵生成装置から暗号鍵を取得する第１通信部と、
前記複数の鍵生成装置のうち第１鍵生成装置に接続される外部装置との間で、第１ネットワークを介して、取得された前記暗号鍵を用いて実行される暗号通信で用いられる要求のうち予め定められた特定要求が送信された場合に、アドレス情報を含むアドレス登録要求を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行い、前記暗号通信部が暗号通信を行う場合に、暗号通信の通信相手となる前記外部装置のアドレス情報を、前記第１通信部を介して前記第２鍵生成装置に送信する制御を行う制御部、
として機能させるためのプログラム。