JP5614465B2 - 暗号通信装置、代行サーバ、暗号通信装置プログラム及び代行サーバプログラム - Google Patents

Description

本発明は、暗号通信装置、代行サーバ、暗号通信装置プログラム及び代行サーバプログラムに関し、例えば、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）ハンドシェイクのクライアント機能を代行サーバが代行するシステムにおいて、代行サーバがＴＬＳサーバの正当性をＴＬＳクライアントに代わって検証するシステムに適用し得る。

近年、ＩＰ−ｒｅａｃｈａｂｌｅな（インターネットに接続可能な）無線マルチホップネットワークの研究開発が進められている。

従来の無線マルチホップネットワークでは、サービスサーバとノードとが事前に対称鍵を共有しておくことが想定されてきたが、今後ＩＰ化が加速し、様々なＩＰネットワークノードと連携するようになってくると、必ずしも事前に暗号鍵を共有していないインターネット上のホストコンピュータともセキュアな通信をするケースがでてくることが想定される。このような場合にセキュアな通信路を構築するプロトコルとして、証明書ベースのＴＬＳプロトコルがインターネットで広く普及している（非特許文献１参照）。ＴＬＳプロトコルは、一般に、クライアント（以下、ＴＬＳクライアントという）と、サーバ（以下、ＴＬＳサーバという）とが証明書を交換して互いを認証し、対称鍵を共有するクライアント認証付きハンドシェイクフェーズ（以下、ＴＬＳハンドシェイクという）と、その後の前述の対称鍵を用いた暗号通信フェーズとからなる。

しかし、ＴＬＳハンドシェイクでは、計算リソースを比較的多く消費する公開鍵暗号アルゴリズムを用いるので、省電力性が重視される無線マルチホップネットワークのノードに対しては大きな負担になると考えられる。

そこで、ＴＬＳクライアントの秘密鍵情報を利用することなく、代行サーバが負荷の高い計算の代行を行う代行システム（ＴＬＳハンドシェイクに準拠しているので、以下、ＴＬＳ代行システムという）が提案されている（非特許文献２参照）。

図５は、非特許文献２で提案されているＴＬＳ代行システムの接続動作（ＴＬＳハンドシェイク）を示すラダー図である。

例えば、ＴＬＳクライアント１は、無線マルチホップネットワークのノードであり、ＴＬＳサーバ２は、無線マルチホップネットワークのサービスサーバである。ＴＬＳクライアント１は、代行サーバ３にＴＬＳハンドシェイクの代行を依頼し、最終的に対称鍵の生成と自己証明のためのディジタル署名の生成をして署名情報を代行サーバに渡す通信装置である。

代行サーバ３は、ＴＬＳクライアント１に代わってＴＬＳハンドシェイクを代行する。図５におけるＴＬＳサーバ２が授受するメッセージは、代行サーバ３を利用しないＴＬＳハンドシェイクと同様である。代行サーバ３には、鍵共有とディジタル署名に必要な秘密情報は与えられていないため、鍵共有プロトコルによって、共有される対称鍵情報、及び、これを必要とする処理や、ディジタル署名の作成処理はできない。但し、代行サーバ３は、これら鍵共有やディジタル署名計算において、負荷の高い一部の計算を行うことで、ＴＬＳクライアント１側では少ない計算量で対称鍵の導出やディジタル署名の生成を行うことができる。

ＲＦＣ５２４６ 中嶋純、八百健嗣共著、"無線マルチホップネットワークノードの認証・鍵共有計算の一部計算委託方式の提案"、２０１２年度暗号と情報セキュリティシンポジウム、２０１２年１月

通常のＴＬＳハンドシェイク（代行サーバを利用しないＴＬＳハンドシェイク）においては、ＴＬＳクライアントがＴＬＳサーバの正当性を検証する方法として、（１）ＴＬＳサーバの公開鍵証明書の検証を行うステップと、（２）当該公開鍵証明書に記載の公開鍵と自らの秘密鍵情報とを用いて対称鍵を生成するステップと、（３）対称鍵で暗号化された所定のＴＬＳハンドシェイクメッセージ（Ｓｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージ）を受け取って正しく暗号化されていることを確認するステップを実行することで、対向するＴＬＳサーバが該公開鍵証明書に記載の公開鍵に対応する秘密鍵を所持することを確認する。

上述した提案されている代行システムでは、ステップ（１）の公開鍵証明書の検証において、公開鍵暗号アルゴリズムを利用しているので、ＴＬＳクライアント１の処理負荷の一段の軽減のため、ＴＬＳサーバ２の公開鍵証明書の検証を代行サーバ３で行うことが望ましい。

しかし、従来の代行システムの場合、ＴＬＳサーバ２の公開鍵証明書の検証を代行サーバ３で行おうとすると、代行サーバ３には秘密にしておくべき対称鍵を代行サーバ３に教えなければならなくなる。

そのため、代行サーバが対称鍵を知得していなくても、第１の暗号通信装置の検証を、第２の暗号通信装置に代わって代行サーバが実行できる、暗号通信装置、代行サーバ、暗号通信装置プログラム及び代行サーバプログラムが望まれている。

第１の本発明は、第２の暗号通信装置に代わって、代行サーバが、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報に従って上記第２の暗号通信装置が対称鍵を生成する暗号通信システムにおける上記第２の暗号通信装置が該当する暗号通信装置において、（１）上記第１の暗号通信装置が、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージに含める第１の検証データを生成するのに利用したパラメータ情報のうち、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を上記代行サーバから取得し、この一部のパラメータ情報の取得により完備した、上記第１の検証データを生成したパラメータ情報を入力パラメータ情報として第２の検証データを生成し、上記代行サーバに返信する第２の検証データ生成手段を有し、（２）上記所定の通信セキュリティプロトコルがＴＬＳであり、（３）上記代行サーバから取得する、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであり、（４）上記第２の検証データ生成手段は、（４−１）上記第１の検証データのバイト数から、メッセージ認証アルゴリズムに規定のメッセージ認証符号長と、上記ハッシュ値のバイト数と、その他実装に依存するヘッダ等の情報のバイト数を差し引いた値をパディング長とし、（４−２）初期ベクタとして、上記代行サーバから受信した初期ベクタを適用し、（４−３）上記ハッシュ値を引数として所定の演算を行った結果を、所定の暗号化プロトコルの入力として、（４−４）上記第２の検証データを生成することを特徴とする。

第２の本発明の暗号通信装置プログラムは、第２の暗号通信装置に代わって、代行サーバが、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報に従って上記第２の暗号通信装置が対称鍵を生成する暗号通信システムにおける上記第２の暗号通信装置が該当する暗号通信装置に搭載されるコンピュータを、（１）上記第１の暗号通信装置が、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージに含める第１の検証データを生成するのに利用したパラメータ情報のうち、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を上記代行サーバから取得し、この一部のパラメータ情報の取得により完備した、上記第１の検証データを生成したパラメータ情報を入力パラメータ情報として第２の検証データを生成し、上記代行サーバに返信する第２の検証データ生成手段として機能させるプログラムであって、（２）上記所定の通信セキュリティプロトコルがＴＬＳであり、（３）上記代行サーバから取得する、当該暗号通信装置プログラムを実行する上記コンピュータを搭載した上記暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであり、（４）上記第２の検証データ生成手段は、（４−１）上記第１の検証データのバイト数から、メッセージ認証アルゴリズムに規定のメッセージ認証符号長と、上記ハッシュ値のバイト数と、その他実装に依存するヘッダ等の情報のバイト数を差し引いた値をパディング長とし、（４−２）初期ベクタとして、上記代行サーバから受信した初期ベクタを適用し、（４−３）上記ハッシュ値を引数として所定の演算を行った結果を、所定の暗号化プロトコルの入力として、（４−４）上記第２の検証データを生成することを特徴とする。

第３の本発明は、第２の暗号通信装置に代わって、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報を与えて上記第２の暗号通信装置に対称鍵を生成させる代行サーバにおいて、（１）上記第１の暗号通信装置から到来した、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージから、その一部を抽出して得たデータを第１の検証データとして保持する第１検証データ保持手段と、（２）上記第２の暗号通信装置へ、上記第１の暗号通信装置が上記第１の検証データを生成するのに利用したパラメータ情報のうち、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を与え、上記第２の暗号通信装置が生成した上記第２の検証データを取込む第２の検証データ生成依頼・取込手段と、（３）上記第１検証データ保持手段に保持されている第１の検証データと、上記第２の暗号通信装置から取り込んだ第２の検証データとを比較し、上記第１の暗号通信装置の正当性を検証する検証データ比較手段とを有し、（４）上記所定の通信セキュリティプロトコルがＴＬＳであり、（５）上記第２の検証データ生成依頼・取込手段が上記第２の暗号通信装置へ与える、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであることを特徴とする。

第４の本発明の代行サーバプログラムは、第２の暗号通信装置に代わって、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報を与えて上記第２の暗号通信装置に対称鍵を生成させる代行サーバに搭載されるコンピュータを、（１）上記第１の暗号通信装置から到来した、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージから、その一部を抽出して得たデータを第１の検証データとして保持する第１検証データ保持手段と、（２）上記第２の暗号通信装置へ、上記第１の暗号通信装置が上記第１の検証データを生成するのに利用したパラメータ情報のうち、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を与え、上記第２の暗号通信装置が生成した上記第２の検証データを取込む第２の検証データ生成依頼・取込手段と、（３）上記第１検証データ保持手段に保持されている第１の検証データと、上記第２の暗号通信装置から取り込んだ第２の検証データとを比較し、上記第１の暗号通信装置の正当性を検証する検証データ比較手段として機能させるプログラムであって、（４）上記所定の通信セキュリティプロトコルがＴＬＳであり、（５）上記第２の検証データ生成依頼・取込手段が上記第２の暗号通信装置へ与える、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであることを特徴とする。
ことを特徴とする。

本発明によれば、代行サーバが対称鍵を知得していなくても、第１の暗号通信装置の検証を、第２の暗号通信装置に代わって代行サーバが実行できる、暗号通信装置、代行サーバ、暗号通信装置プログラム及び代行サーバプログラムを実現できる。

実施形態の代行システムの全体構成を示すブロック図である。 実施形態のＴＬＳクライアントにおけるＴＬＳハンドシェイク中の特徴の実現に係る機能的構成を示すブロック図である。 実施形態の代行サーバにおけるＴＬＳハンドシェイク中の特徴の実現に係る機能的構成を示すブロック図である。 実施形態の代行システムにおけるＴＬＳハンドシェイクのフェーズでの動作を示すラダー図である。 非特許文献２で提案されているＴＬＳ代行システムの接続動作（ＴＬＳハンドシェイク）を示すラダー図である。

（Ａ）主たる実施形態
以下、本発明による暗号通信装置、代行サーバ、暗号通信装置プログラム及び代行サーバプログラムの一実施形態を、図面を参照しながら説明する。

実施形態の暗号通信システム（以下、実施形態の説明において代行システムという）は、ＴＬＳクライアント（第２の暗号通信装置）に代わって代行サーバが、ＴＬＳサーバ（第１の暗号通信装置）との間でクライアント認証付きハンドシェイクを実行し、代行サーバがＴＬＳサーバの正当性をＴＬＳクライアントに代わって検証するシステムである。

なお、実施形態の代行システムは、ＴＬＳハンドシェイク（のフェーズ）後の暗号通信フェーズにおいては、当然に、実施形態のＴＬＳクライアント及びＴＬＳサーバ間で、代行サーバを介さずに、対称鍵を用いた暗号通信を行うものである。

実施形態の代行システムは、非特許文献２に記載の代行システムを基本としながら、さらに、代行サーバが、対称鍵を知ることなく、ＴＬＳクライアントとＴＬＳサーバとの間で正しく対称鍵を共有できていることを確認できるシーケンスを追加したことを特徴としているものである。すなわち、後述するように、代行サーバが、Ｓｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージの生成に必要なパラメータをＴＬＳクライアントに与えて、ＴＬＳクライアントがＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージを生成して代行サーバに送信し、代行サーバが、ＴＬＳサーバから受信したＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージから得られたデータと、ＴＬＳクライアントから受信したＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージから得られたデータとを比較することで、対称鍵を知ることなく、ＴＬＳクライアントとＴＬＳサーバとの間で正しく対称鍵を共有できていることを確認できることを特徴とする。

なお、実施形態の代行システムでは、ＴＬＳの暗号通信プロトコルとして、ブロック暗号アルゴリズムとメッセージ認証アルゴリズムを用いた認証暗号アルゴリズムを用いた暗号化を採用しているものとする。

（Ａ−１）実施形態の構成
実施形態の代行システム１０も、図１に示すように、ＴＬＳクライアント１００、代行サーバ２００及びＴＬＳサーバ３００を構成要素とし、ＴＬＳハンドシェイクのフェーズでは、基本的には、ＴＬＳクライアント１００に代わって代行サーバ２００が、ＴＬＳサーバ３００との間でクライアント認証付きハンドシェイクを実行し、代行サーバ２００がＴＬＳサーバ３００の正当性をＴＬＳクライアント１００に代わって検証し、その後の暗号通信フェーズにおいては、当然に、ＴＬＳクライアント１００及びＴＬＳサーバ３００間で、代行サーバ２００を介さずに、対称鍵を用いた暗号通信を行う。

図２は、実施形態のＴＬＳクライアント１００におけるＴＬＳハンドシェイク中の特徴の実現に係る機能的構成を示すブロック図である。図２は、上述した実施形態の特徴を理解し易いように機能分けしたブロック図である。実施形態のＴＬＳクライアント１００は、後述する送受信部１０１におけるハードウェア構成を除いた部分を、ＣＰＵと、ＣＰＵが実行するプログラム（暗号通信装置プログラム）で実現することも可能であるが、このようなソフトウェアを利用した実現構成でも、機能的には、図２で表すことができる。

図２において、ＴＬＳクライアント１００は、送受信部１０１、代行計算処理部１０２、検証データ生成部１０３及び結果処理部１０４を有する。

送受信部１０１は、ＴＬＳハンドシェイクフェーズにおいて、代行サーバ２００と通信を行うものである。

代行計算処理部１０２は、代行サーバ２００から、対称鍵の生成と、ディジタル署名の生成に必要な代行パラメータ（Ｐａｒａｍｅｔｅｒｓ（１））を受信して、対称鍵の生成と、ディジタル署名の生成とを行う。代行パラメータは、この実施形態の代行システム１０において予め定義されている。

上記ディジタル署名については、送受信部１０１を介して代行サーバ２００に送信する。

この実施形態では、上述のように、ＴＬＳクライアント１００（の代行計算処理部１０２）が対称鍵を生成し、代行サーバ２００は対称鍵を知得することができない。

また、代行計算処理部１０２は、代行サーバ２００から、Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージの生成に必要な代行パラメータ（Ｐａｒａｍｅｔｅｒｓ（２））を受信して、Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージの生成を行う。これは、Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージの生成を行うことを通じて、それまでのハンドシェイク処理が正当に実行されていることを、ＴＬＳサーバ３００に証明するためである。

検証データ生成部１０３は、代行サーバ２００から受信した、ハッシュ値Ｈａｓｈと、第１の検証データ（ＴＬＳサーバ３００が生成した検証データをいう）のバイト数情報と、初期ベクタ等の暗号アルゴリズムに依存するパラメータ（この実施形態では初期ベクタ情報のみとする）とを適用して（これら３種類のパラメータは後述する図４ではＰａｒａｍｅｔｅｒｓ（３）と表記している）、ＲＦＣ５２４６の７．４．９節に記載の（１）式で表されるｖｅｒｉｆｙ＿ｄａｔａを計算し、このｖｅｒｉｆｙ＿ｄａｔａを適用して検証データ（第２の検証データ；ＴＬＳクライアント１００が生成した検証データをいう）を生成する。

ｖｅｒｉｆｙ＿ｄａｔａ＝ＰＲＦ（ｍａｓｔｅｒ＿ｓｅｃｒｅｔ，ｆｉｎｉｓｈｅｄ＿ｌａｂｅｌ，Ｈａｓｈ） …（１）
ここで、ｍａｓｔｅｒ＿ｓｅｃｒｅｔは対称鍵のことであり、ｆｉｎｉｓｈｅｄ＿ｌａｂｅｌとはアスキー文字列”ｓｅｒｖｅｒ ｆｉｎｉｓｈｅｄ”であり、Ｈａｓｈは前述のハッシュ値Ｈａｓｈであり、ＰＲＦ（）関数はＲＦＣ５２４６のセクション５に記載の擬似乱数関数（Ｐｓｅｕｄｏｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎ）である。ＴＬＳクライアント１００に設けられた検証データ生成部１０３ではあるが、ｆｉｎｉｓｈｅｄ＿ｌａｂｅｌに、アスキー文字列“ｃｌｉｅｎｔ ｆｉｎｉｓｈｅｄ”ではなく、上述のようにアスキー文字列”ｓｅｒｖｅｒ ｆｉｎｉｓｈｅｄ”を導入することにより、ＴＬＳクライアント１００が、ＴＬＳサーバ３００が実行するｖｅｒｉｆｙ＿ｄａｔａの生成操作と同様な操作を行う。

検証データ生成部１０３は、ｖｅｒｉｆｙ＿ｄａｔａをＲＦＣ５２４６の６．２．３節に記載の暗号化プロトコルに従って暗号化して、第２の検証データを生成する。

ここで、受信した第１の検証データのバイト数をＬとし、メッセージ認証符号アルゴリズムに規定の符号長と、ハッシュ値Ｈａｓｈのバイト数と、その他実装に依存するヘッダ等の情報のバイト数との総和をＭとしたとき、検証データ生成部１０３は、パディング長Ｐを（２）式に従って計算する。検証データ生成部１０３は、ｖｅｒｉｆｙ＿ｄａｔａを入力とし、初期ベクタには代行サーバ２００から受信した初期ベクタを適用し、（２）式に従って得たパディング長Ｐを適用して、所定の暗号化プロトコルを実行することにより、第２の検証データを生成し、Ｓｅｒｖｅｒ Ｆｉｎｉｓｈｅｄメッセージに含めて代行サーバ２００に送信する。

Ｐ＝Ｌ−Ｍ …（２）
結果処理部１０４は、代行サーバ２００からの、ＴＬＳサーバ３００の正当性に係る検証結果を受けて、検証結果に応じた処理を行う。例えば、結果処理部１０４は、検証が成功ならば暗号通信フェーズに移行させて通信を続行させ、検証が失敗ならば暗号通信フェーズに移行させずに通信を中断させる。なお、検証結果に応じた処理の内容は、この例に限定されるものではない。

図３は、実施形態の代行サーバ２００におけるＴＬＳハンドシェイク中の特徴の実現に係る機能的構成を示すブロック図である。図３は、上述した実施形態の特徴を理解し易いように機能分けしたブロック図である。実施形態の代行サーバ２００は、後述する送受信部２０１におけるハードウェア構成を除いた部分を、ＣＰＵと、ＣＰＵが実行するプログラム（代行サーバプログラム）で実現することも可能であるが、このようなソフトウェアを利用した実現構成でも、機能的には、図３で表すことができる。また、実施形態の代行サーバ２００は、１台の物理的なサーバでなっている必要はなく、複数のサーバの分散配置構成で実現されていても良い（非特許文献２参照）。

図３において、代行サーバ２００は、送受信部２０１、代行計算処理部２０２、検証データ比較部２０３及びパラメータ通知部２０４を有する。

送受信部２０１は、ＴＬＳハンドシェイクフェーズにおいて、ＴＬＳクライアント１００及びＴＬＳサーバと通信を行う。

代行計算処理部２０２は、ＴＬＳハンドシェイクの代行を行う。

代行計算処理部２０２は、代行処理の中で、ＴＬＳクライアント１００に必要なパラメータ情報（Ｐｒａｍｅｔｅｒｓ（１））をパラメータ通知部２０４を介して与え、ＴＬＳクライアント１００からディジタル署名情報（Ｓｉｇｎａｔｕｒｅ）を受け取り、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージを生成してＴＬＳサーバ３００に送信する。

また、代行計算処理部２０２は、代行処理の中で、ＴＬＳクライアント１００に必要なパラメータ情報（Ｐｒａｍｅｔｅｒｓ（２））をパラメータ通知部２０４を介して与え、ＴＬＳクライアント１００からＣｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージを受け取り、ＴＬＳサーバ３００に送信する。

さらに、代行計算処理部２０２は、ＴＬＳクライアント１００からＣｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージを受信したときに、ハンドシェイクメッセージのハッシュ値Ｈａｓｈを所定のハッシュ関数を適用して計算した後、ＴＬＳクライアント１００がＳｅｒｖｅｒ Ｆｉｎｉｓｈｅｄメッセージに含める第２の検証データの生成に必要なパラメータ情報（Ｐａｒａｍｅｔｅｒｓ（３））を、パラメータ通知部２０４を介して、ＴＬＳクライアント１００に与えると共に、ＴＬＳサーバ３００からのＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージに含まれている第１の検証データを検証データ比較部２０３に与える。上述したように、ＴＬＳクライアント１００がＳｅｒｖｅｒ Ｆｉｎｉｓｈｅｄメッセージに含める第２の検証データの生成に必要なパラメータ情報は、計算で得られたハッシュ値Ｈａｓｈと、ＴＬＳサーバ３００からのＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージに含まれている第１の検証データのバイト数情報と、初期ベクタ情報とである。

検証データ比較部２０３は、代行計算処理部２０２から第１の検証データを受け取り、送受信部２０１から第２の検証データを受け取って、第１の検証データ及び第２の検証データを比較し、両者が同一である場合には成功とし（ＴＬＳクライアントとＴＬＳサーバとの間で正しく対称鍵を共有できているとし）、そうでない場合には失敗として、結果をＴＬＳクライアント１００に送信する。

パラメータ通知部２０４は、代行計算処理部２０２から供給されたパラメータ情報（Ｐａｒａｍｅｔｅｒｓ（１）、（２）、（３））をＴＬＳクライアント端末１００に通知する。

この実施形態の場合、ＴＬＳサーバ３００の構成には特徴はなく、図示は省略するが、ＴＬＳサーバ３００は、ＴＬＳハンドシェイクにおけるＴＬＳサーバプロトコルを実行できる一般的な構成を有する。

（Ａ−２）実施形態の動作
次に、実施形態の代行システム１０におけるＴＬＳハンドシェイクのフェーズでの動作を説明する。

図４は、実施形態の代行システム１０におけるＴＬＳハンドシェイクのフェーズでの動作を示すラダー図である。

例えば、ＴＬＳクライアント１００がＴＬＳサーバ３００との通信が必要となったときに、代行サーバ２００による代行処理を起動する。また例えば、ＴＬＳクライアント１００及びＴＬＳサーバ３００間の通信を、所定期間毎の定時に実行するような場合であれば、代行サーバ２００が定時になると自動的に代行処理を起動する。

代行処理が起動されると、代行サーバ２００（の代行計算処理部２０２）は、ＴＬＳハンドシェイクの代行プロトコルに従って、まず、ＴＬＳサーバ３００に、ＴＬＳクライアント１００が提示する暗号技術に関するパラメータや、鍵生成に使用する乱数等を含むＣｌｉｅｎｔＨｅｌｌｏメッセージをＴＬＳサーバ３００に送信する。

ＣｌｉｅｎｔＨｅｌｌｏメッセージの到来に応じて、ＴＬＳサーバ３００は、ＳｅｒｖｅｒＨｅｌｌｏメッセージ、Ｓｅｒｖｅｒ−Ｃｅｒｔｉｆｉｃａｔｅメッセージ、ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージ、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージを代行サーバ２００に順次送信する。

ＴＬＳサーバ３００は、ＳｅｒｖｅｒＨｅｌｌｏメッセージによって、例えば、選択した暗号化や圧縮化のアルゴリズムや、ＴＬＳサーバ３００側の乱数を通知する。ＴＬＳサーバ３００は、Ｓｅｒｖｅｒ−Ｃｅｒｔｉｆｉｃａｔｅメッセージによって、例えば、ＴＬＳサーバ３００側の公開鍵を通知する。ＴＬＳサーバ３００は、ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージによって、例えば、クライアント認証を要求すると共に、証明書の種類に関する情報を通知する。ＴＬＳサーバ３００は、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージによって、ＣｌｉｅｎｔＨｅｌｌｏメッセージの到来に応じて送信するメッセージ群の終了を通知する。

ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージの到来に応じて、代行サーバ２００は、Ｃｌｉｅｎｔ−Ｃｅｒｔｉｆｉｃａｔｅメッセージ、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージ、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージ、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ、Ｃｌｉｅｎｔ−ＦｉｎｉｓｈｅｄメッセージをＴＬＳサーバ３００に順次送信する。

ここで、Ｃｌｉｅｎｔ−Ｃｅｒｔｉｆｉｃａｔｅメッセージ及びＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージは、クライアント認証の要求に応じて送信するものであり、Ｃｌｉｅｎｔ−ＣｅｒｔｉｆｉｃａｔｅメッセージはＴＬＳクライアント１００の証明書を送信するものであり、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージは、ＴＬＳサーバ３００がＴＬＳクライアント１００を認証するものである。代行サーバ２００（の代行計算処理部２０２）は、ＴＬＳクライアント１００に第１のパラメータ情報（Ｐｒａｍｅｔｅｒｓ（１））を与えて、ＴＬＳクライアント１００に、ディジタル署名情報（Ｓｉｇｎａｔｕｒｅ）を生成させて受け取り、ディジタル署名情報をＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージに盛り込んでＴＬＳサーバ３００に送信する。なお、ＴＬＳクライアント１００は、ディジタル署名情報の生成に先立ち、対称鍵の生成を行う。

また、代行サーバ２００が送信するＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージは、鍵交換用のメッセージであり、この実施形態では、暗号スイートの鍵共有プロトコルがＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵共有プロトコルであり、当該メッセージには、クライアント公開鍵が含まれていることとする。その後に送信するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージは、後続する全てのメッセージを、今取り決めた暗号スイートで暗号化することを通知する。Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージには、接続全体のチェック値を含み、これにより、ＴＬＳサーバ３００は、暗号スイートが安全に取り決められたことを確信できる。この実施形態の場合、Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージの生成をＴＬＳクライアント１００が行うこととしており、代行サーバ２００（の代行計算処理部２０２）は、ＴＬＳクライアント１００に第２のパラメータ情報（Ｐｒａｍｅｔｅｒｓ（２））を与えて、ＴＬＳクライアント１００にＣｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージを生成させ、そのＣｌｉｅｎｔ−ＦｉｎｉｓｈｅｄメッセージをＴＬＳサーバ３００に転送する。

Ｃｌｉｅｎｔ−Ｆｉｎｉｓｈｅｄメッセージを受信したＴＬＳサーバ３００は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ、Ｓｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージを代行サーバ２００に順次送信する。

これらメッセージの送受信を通じて、一般的には、アプリケーションデータの送信が開始できる状態になる。

しかし、この実施形態では、代行サーバ２００は、ＴＬＳクライアント１００とＴＬＳサーバ３００間で共有する対称鍵情報を知らないため、当該対称鍵を用いて行うＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージの処理をすることができない。ただし、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージやＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージを代行サーバ２００が受信する前においても、ＴＬＳサーバ３００の公開鍵証明書の検証を代行サーバ２００で行うための前処理等も実行されるものとする。

そこで以下、当該対称鍵を知ることなく代行サーバ２００がＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージを処理するための一連の処理を取り上げて説明する。

代行サーバ２００の代行計算処理部２０２は、ＴＬＳクライアント１００から受信したＣｌｉｅｎｔ−ＦｉｎｉｓｈｅｄメッセージをＴＬＳサーバ３００に送信したときにハッシュ値Ｈａｓｈを計算し、パラメータ通知部２０４に与え、パラメータ通知部２０４は、このハッシュ値Ｈａｓｈを一時的に保持する。

その後、該代行計算処理部２０２は、ＴＬＳサーバ３００からＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ及びＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージを受信すると、Ｓｅｒｖｅｒ−ＦｉｎｉｓｈｅｄメッセージのＴＬＳペイロード部から、まず初期ベクタを抽出し、次に残りの部分を第１の検証データとして抽出する。ここで、初期ベクタの長さは、ＴＬＳ暗号通信プロトコルで利用するブロック暗号アルゴリズムのブロックサイズと同じである。代行計算処理部２０２は、抽出した初期ベクタと、第１の検証データのバイト数とをパラメータ通知部２０４に与えると共に、抽出した第１の検証データを検証データ比較部２０３に与える。検証データ比較部２０３は、第１の検証データを一時的に保持する。パラメータ通知部２０４は、ハッシュ値Ｈａｓｈと、初期ベクタと、第１の検証データのバイト数とを、ＴＬＳクライアント１００に送信する（図４ではＰａｒａｍｅｔｅｒｓ（３）と表記している）。

ＴＬＳクライアント１００は、ハッシュ値Ｈａｓｈと、初期ベクタと、第１の検証データのバイト数とを受信すると、検証データ生成部１０３に渡し、検証データ生成部１０３は、ハッシュ値Ｈａｓｈを入力として、（１）式に従ってｖｅｒｉｆｙ＿ｄａｔａを計算する。また、検証データ生成部１０３は、第１の検証データのバイト数から、メッセージ認証符号のバイト数と、ハッシュ値ｈａｓｈのバイト数と、その他実装に依存するヘッダ情報等のバイト数を差し引いた数値をパディング長とし、初期ベクタを代行サーバ２００から受信した初期ベクタとして、ｖｅｒｉｆｙ＿ｄａｔａをＲＦＣ５２４６の６．２．３節に記載の暗号化プロトコルに従って暗号化して、第２の検証データを生成して照合用のＳｅｒｖｅｒ−Ｆｉｎｉｓｈｅｄメッセージに盛り込んで代行サーバ２００に送信する。

代行サーバ２００は、第２の検証データを受信すると、検証データ比較部２０３に送り、検証データ比較部２０３は、保持してある第１の検証データと、この第２の検証データとを比較する。そして、代行サーバ２００は、双方の検証データが一致すれば成功を示す所定のメッセージ（その内容は特に限定しない）をＴＬＳクライアント１００に送信し、そうでなければ失敗を示すメッセージをＴＬＳクライアント１００に送信する（図４ではＲｅｓｕｌｔと表記している）。

ＴＬＳクライアント１００は、２つの検証データの比較結果のメッセージを受信すると、結果処理部１０４に与え、比較結果のメッセージに応じた所定の処理（特に限定されない）を実行する。例えば、成功を示す比較結果のメッセージが与えられた際には、ＴＬＳクライアント１００は、暗号通信フェーズに移行する。なお、この実施形態の場合、ＴＬＳクライアント１００がアプリケーションデータの暗号通信を実行するために必要な情報は、比較結果のメッセージが与えられる前に、ＴＬＳクライアント１００は取得できている。

（Ａ−３）実施形態の効果
上記実施形態によれば、代行サーバ２００がＴＬＳハンドシェイク中で生成される対称鍵を知らなくても、ＴＬＳサーバ３００の正当性を検証することができる。

（Ｂ）他の実施形態
背景技術等では、無線マルチホップネットワークに言及したが、本発明の暗号通信システムが適用されるシステムは無線マルチホップネットワークに限定されるものではない。言い換えると、ＴＬＳクライアント１００やＴＬＳサーバ３００を搭載している具体的な暗号通信装置の種類は限定されないものである。

上記実施形態では、通信セキュリティプロトコルがＴＬＳである場合を示したが、ＴＬＳと同様な構成を有する他の通信セキュリティプロトコル（例えば、ＳＳＬｖ３）を適用しているシステムにも、本発明を適用することができる。

１０…代行システム、
１００…ＴＬＳクライアント、
１０１…送受信部、１０２…代行計算処理部、１０３…検証データ生成部、１０４…結果処理部、
２００…代行サーバ、
２０１…送受信部、２０２…代行計算処理部、２０３…検証データ比較部、２０４…パラメータ通知部、
３００…ＴＬＳサーバ。

Claims (4)

1. 第２の暗号通信装置に代わって、代行サーバが、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報に従って上記第２の暗号通信装置が対称鍵を生成する暗号通信システムにおける上記第２の暗号通信装置が該当する暗号通信装置において、
   上記第１の暗号通信装置が、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージに含める第１の検証データを生成するのに利用したパラメータ情報のうち、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を上記代行サーバから取得し、この一部のパラメータ情報の取得により完備した、上記第１の検証データを生成したパラメータ情報を入力パラメータ情報として第２の検証データを生成し、上記代行サーバに返信する第２の検証データ生成手段を有し、
   上記所定の通信セキュリティプロトコルがＴＬＳであり、
   上記代行サーバから取得する、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであり、
   上記第２の検証データ生成手段は、
   上記第１の検証データのバイト数から、メッセージ認証アルゴリズムに規定のメッセージ認証符号長と、上記ハッシュ値のバイト数と、その他実装に依存するヘッダ等の情報のバイト数を差し引いた値をパディング長とし、
   初期ベクタとして、上記代行サーバから受信した初期ベクタを適用し、
   上記ハッシュ値を引数として所定の演算を行った結果を、所定の暗号化プロトコルの入力として
   上記第２の検証データを生成する
   ことを特徴とする暗号通信装置。
2. 第２の暗号通信装置に代わって、代行サーバが、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報に従って上記第２の暗号通信装置が対称鍵を生成する暗号通信システムにおける上記第２の暗号通信装置が該当する暗号通信装置に搭載されるコンピュータを、
   上記第１の暗号通信装置が、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージに含める第１の検証データを生成するのに利用したパラメータ情報のうち、当該暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を上記代行サーバから取得し、この一部のパラメータ情報の取得により完備した、上記第１の検証データを生成したパラメータ情報を入力パラメータ情報として第２の検証データを生成し、上記代行サーバに返信する第２の検証データ生成手段として機能させる暗号通信装置プログラムであって、
   上記所定の通信セキュリティプロトコルがＴＬＳであり、
   上記代行サーバから取得する、当該暗号通信装置プログラムを実行する上記コンピュータを搭載した上記暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とであり、
   上記第２の検証データ生成手段は、
   上記第１の検証データのバイト数から、メッセージ認証アルゴリズムに規定のメッセージ認証符号長と、上記ハッシュ値のバイト数と、その他実装に依存するヘッダ等の情報のバイト数を差し引いた値をパディング長とし、
   初期ベクタとして、上記代行サーバから受信した初期ベクタを適用し、
   上記ハッシュ値を引数として所定の演算を行った結果を、所定の暗号化プロトコルの入力として
   上記第２の検証データを生成する
   ことを特徴とする暗号通信装置プログラム。
3. 第２の暗号通信装置に代わって、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報を与えて上記第２の暗号通信装置に対称鍵を生成させる代行サーバにおいて、
   上記第１の暗号通信装置から到来した、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージから、その一部を抽出して得たデータを第１の検証データとして保持する第１検証データ保持手段と、
   上記第２の暗号通信装置へ、上記第１の暗号通信装置が上記第１の検証データを生成するのに利用したパラメータ情報のうち、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を与え、上記第２の暗号通信装置が生成した上記第２の検証データを取込む第２の検証データ生成依頼・取込手段と、
   上記第１検証データ保持手段に保持されている第１の検証データと、上記第２の暗号通信装置から取り込んだ第２の検証データとを比較し、上記第１の暗号通信装置の正当性を検証する検証データ比較手段とを有し、
   上記所定の通信セキュリティプロトコルがＴＬＳであり、
   上記第２の検証データ生成依頼・取込手段が上記第２の暗号通信装置へ与える、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とである
   ことを特徴とする代行サーバ。
4. 第２の暗号通信装置に代わって、第１の暗号通信装置との間で、所定の通信セキュリティプロトコルに従ったハンドシェイクを実行すると共に、所定のパラメータ情報を与えて上記第２の暗号通信装置に対称鍵を生成させる代行サーバに搭載されるコンピュータを、
   上記第１の暗号通信装置から到来した、合意したばかりの暗号通信アルゴリズムで保護されたハンドシェイク終了メッセージから、その一部を抽出して得たデータを第１の検証データとして保持する第１検証データ保持手段と、
   上記第２の暗号通信装置へ、上記第１の暗号通信装置が上記第１の検証データを生成するのに利用したパラメータ情報のうち、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報を与え、上記第２の暗号通信装置が生成した上記第２の検証データを取込む第２の検証データ生成依頼・取込手段と、
   上記第１検証データ保持手段に保持されている第１の検証データと、上記第２の暗号通信装置から取り込んだ第２の検証データとを比較し、上記第１の暗号通信装置の正当性を検証する検証データ比較手段として機能させる代行サーバプログラムであって、
   上記所定の通信セキュリティプロトコルがＴＬＳであり、
   上記第２の検証データ生成依頼・取込手段が上記第２の暗号通信装置へ与える、上記第２の暗号通信装置が上記第１の暗号通信装置との間で共有していない一部のパラメータ情報が、少なくとも、ハッシュ値と、上記第１の検証データのバイト数情報と、初期ベクタ情報とである
   ことを特徴とする代行サーバプログラム。

Images