JP2012213036A - 通信装置及び通信システム - Google Patents

Abstract

【課題】ＳＳＬ／ＴＬＳ暗号通信では、秘密鍵による公開鍵暗号（復号）処理は非常に重く、この処理に要するＣＰＵ等サーバ費用は非常に高い。特に、多数のクライアントと接続するようなインターネット上の公開サーバにおいて、この傾向は顕著である。
【解決手段】サーバのＣＰＵ使用率（負荷）が高くなってきたら、クライアントを「ＳＳＬ／ＴＬＳ暗号通信のサーバ」に、サーバを「ＳＳＬ／ＴＬＳ暗号通信のクライント」とした、リバースのＳＳＬ／ＴＬＳネゴシエーションを行う。また、サーバは、そのリバースのＳＳＬ／ＴＬＳネゴシエーションの前に行う通常のＳＳＬ／ＴＬＳネゴシエーションにおいて、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するか否かを、クライントに指示する。
【選択図】図１

Description

本発明は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）暗号通信に関するもので、特にＳＳＬ／ＴＬＳ通信のハンドシェイクに関する。

近年、通信を安全に行う方法として、ＳＳＬ／ＴＬＳ暗号通信が普及している（非特許文献１、２、３参照）。

しかし「暗号の２０１０年問題」で指摘されているように、現在の暗号解読能力向上は著しく、現行の暗号鍵（復号鍵を含む）の鍵長では安全と言えなくなってきている。そこで、これに対応するため、近年、鍵長を更に大きくする対策がとられている。これらの対応により、当面の危険性は、大幅に緩和されると期待できる。

Ｔ．Ｄｉｅｒｋｓ、Ｃ．Ａｌｌｅｎ、"Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０"、ＲＦＣ ２２４６、［online］、１９９９年１月、［平成２３年３月２９日検索］ 、インターネット＜http://www.ietf.org/rfc/rfc2246.txt＞ Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、"Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ） Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．１"、ＲＦＣ ４３４６、［online］、２００６年４月、［平成２３年３月２９日検索］、インターネット＜http://www.ietf.org/rfc/rfc4346.txt＞ Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、"Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ） Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．２"、ＲＦＣ ５２４６、［online］、２００８年８月、［平成２３年３月２９日検索］、インターネット＜http://www.ietf.org/rfc/rfc5246.txt＞

しかしながら、暗号鍵（復号鍵を含む）の鍵長を大きくすると、計算処理回数が大幅に増加し、処理時間も大幅に伸びる。特に、秘密鍵による公開鍵暗号を行っているサーバの負荷は無視できないほどに大きなものになる。事実、「暗号の２０１０年問題」対応のため、現在主流の公開鍵暗号である１０２４ビットＲＳＡ暗号は、２０４８ビットＲＳＡ（Ｒｉｖｅｓｔ Ｓｈａｍｉｒ Ａｄｌｅｍａｎ）暗号に移行するが、サーバの負荷は６〜８倍に増加する。

そのため、多数のクライントを相手にするサーバでは、ＣＰＵの能力向上対応等で、大幅なコストアップとなる。しかも公開サーバの場合には、秘密鍵による公開鍵暗号（復号）処理を強要するＤＯＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃が想定されるため、この影響は甚大である。

なお、１つのクライアントしか相手にしないサーバであっても問題となるケースは少なくない。相手が１つのクライアントだったとしても、多くのＳＳＬ／ＴＬＳ暗号通信が利用されれば同じ課題に直面する。

実際、単純なＷｅｂアクセスであっても問題になることがある。Ｗｅｂアクセス等ではＧＥＴの度にＳＳＬ／ＴＬＳ暗号通信の開始・切断が行われることが多く、１ページの中にＧＥＴされる多くの部品が存在するＷｅｂページでは、非常に多くのＳＳＬ／ＴＬＳ暗号通信が実行される。仮に、このサーバのＣＰＵ能力を向上させなければ、頻繁に通信タイムアウトが発生する恐れがある。

本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、ＳＳＬ／ＴＬＳ暗号通信を実行するクライアントとサーバで、暗号（復号）処理の負荷分散を図ことにある。これにより、システム全体での処理速度を向上させ、かつＳＳＬ／ＴＬＳ暗号通信の搭載（実現）費用をより安価なものにする。

上述の課題を解決するために、本発明の通信装置は、他の通信装置と第１の鍵を用いて通信を行う通信装置であって、前記他の通信装置との間でハンドシェイク処理を行う認証処理部を備え、前記認証処理部は、前記第１の鍵を前記他の通信装置との間で交換するための第２の鍵の復号処理を行う鍵復号化部と、前記第２の鍵を用いて暗号処理を行う鍵暗号化部と、を有し、前記鍵復号化部による前記復号処理を除く第１のハンドシェイク処理を行い、前記第１のハンドシェイク処理が終了した場合、前記鍵復号化部による前記復号処理を除く第２のハンドシェイク処理を行い、前記第２のハンドシェイク処理において、前記鍵暗号化部に前記第２の鍵を用いて前記第１の鍵の情報を暗号化させ、前記第２の鍵で暗号化された前記第１の鍵の情報を前記他の通信装置に送信するように構成した。

この通信装置によれば、ファイヤーウォールのチェックにかからずに、鍵復号化部が行う第２の鍵の復号処理を他の通信装置に行わせることができる。すなわち、通信装置の負荷を他の通信装置に分散させることができる。

また、本発明の通信装置は、前記認証処理部は、ダミーデータを用いて前記他の通信装置と第１のハンドシェイク処理を行うように構成した。

この通信装置によれば、通信装置と他の通信装置は第１のハンドシェイク処理では第２の鍵による復号を行わないので、ダミーデータを用いることで不要な処理を省略することができる。

また、本発明の通信装置は、演算処理を行う演算部と、前記演算部の使用状況を検知し、前記使用状況の情報を前記認証処理部に通知する使用状況検知部と、をさらに有し、前記認証処理部は、前記使用状況に基づいて前記第１のハンドシェイク処理で前記鍵復号化部による前記復号処理を除くかどうかを決定するように構成した。

この通信装置によれば、演算部の使用状況に基づいて第２の鍵の復号処理を省略するかどうか判断することができる。すなわち、状況に応じて第２ハンドシェイク処理の必要性を判断することができる。

また、本発明の通信装置は、前記他の通信装置が前記第２のハンドシェイク処理を実行可能なことを通知する第１の情報を前記他の通信装置から受信する場合、前記第１の認証処理部は、前記第１の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定するように構成した。

この通信装置によれば、状況に応じて第２のハンドシェイク処理の必要性を判断することができる。

また、本発明の通信装置は、前記他の通信装置の処理能力を通知する第２の情報を前記他の通信装置から受信する場合、前記第１の認証処理部は、前記第１の情報と前記第２の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定するように構成した。

この通信装置によれば、他の通信装置の処理能力に応じて第２のハンドシェイクの必要性を判断することができる。

また、本発明の通信システムは、第１の通信装置と第２の通信装置との間で第１の鍵を用いて通信を行う通信システムであって、前記第１の通信装置は、前記第２の鍵を用いて暗号処理を行う第１の鍵暗号化部と、前記第１の鍵を前記第２の通信装置との間で交換するための第２の鍵の復号処理を行う第１の鍵復号化部と、を有し、前記第２の通信装置は、前記第２の鍵を用いて暗号処理を行う第２の鍵暗号化部と、前記第１の鍵を前記第１の通信装置との間で交換するための第２の鍵の復号処理を行う第２の鍵復号化部と、を有し、前記第１の鍵復号部による前記第２の鍵の復号処理を除く第１のハンドシェイク処理が前記第１の通信装置と前記第２の通信装置との間で行われた場合、前記第１の通信装置と前記第２の通信装置とは第２のハンドシェイク処理を行い、前記第２のハンドシェイク処理において、前記第１の通信装置は、前記第１の鍵暗号化部に前記第２の鍵を用いて前記第１の鍵の情報を暗号化させ、前記第２の鍵で暗号化された前記第１の鍵の情報を前記第２の通信装置に送信し、前記第２の通信装置の前記第２の鍵復号化部は前記第２の鍵で暗号化された前記第１の鍵の情報の復号処理を行うように構成した。

この通信システムによれば、ファイヤーウォールのチェックにかからずに、通常第１の鍵復号化部が行う第２の鍵の復号処理を第２の通信装置に行わせることができる。すなわち、第１の通信装置の負荷を第２の通信装置に分散させることができる。

また、本発明の通信システムは、前記第１の通信装置と前記第２の通信装置とはダミーデータを用いて前記第１のハンドシェイク処理を行うように構成した。

この通信システムによれば、第１の通信装置と第２の通信装置とは第１のハンドシェイク処理では第２の鍵による復号を行わないので、ダミーデータを用いることで不要な処理を省略することができる。

また、本発明の通信システムは、前記第１のハンドシェイクが終了した場合、前記第２の通信装置は、前記第１の通信装置に第２のハンドシェイクを要求する信号を送信するように構成した。

これ通信システムによれば、第１の通信装置は、第２の通信装置からの信号をきっかけに第２のハンドシェイクを行うことができる。

また、本発明の通信システムは、前記第１のハンドシェイク処理において、第２の通信装置は、前記第２のハンドシェイク処理を実行可能なことを通知する第１の情報を前記第１の通信装置に送信し、前記第１の情報を受信した前記第１の通信装置は、前記第２のハンドシェイク処理を行うことを前記第２の通信装置に通知するように構成した。

この通信システムによれば、第１のハンドシェイク処理を行う段階で、第１の通信装置と第２の通信装置とは、第２のハンドシェイク処理を行うことをお互いに認識することができる。これにより、第１の通信装置と第２の通信装置とは第１のハンドシェイク処理において不要な処理を省略することができる。

また、本発明の通信システムは、前記第２の通信装置は、前記第１の情報と共に、使用可能な暗号方式を前記第１の通信装置に送信し、前記第１の通信装置が前記第２のハンドシェイク処理を行わないと決定した場合、前記第１の通信装置は、前記使用可能な暗号方式の中から前記第１のハンドシェイク処理で使用する暗号方式を選択して前記第２の通信装置に通知する、ように構成した。

この通信システムによれば、第１の通信装置は第２の通信装置に第１のハンドシェイク処理で使用する暗号方式を通知することで、第２のハンドシェイクを行わないことを通知することができる。

また、本発明の通信システムは、前記第１の通信装置は、演算処理を行う演算部と、前記演算部の使用状況を検知する使用状況検知部と、をさらに有し、前記使用状況の情報と前記第１の情報とに基づいて、前記第２のハンドシェイク処理を行うかどうかを決定するように構成した。

この通信システムによれば、演算部の使用状況に応じて第２のハンドシェイク処理の必要性を判断することができる。

また、本発明の通信システムは、前記第２の通信装置は、演算処理を行う演算部をさらに有し、前記演算部の処理能力を通知する第２の情報を前記第１の通信装置に送信し、前記第１の通信装置は、前記第１の情報と前記第２の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定するように構成した。

この通信システムによれば、第１の通信装置は第２の通信装置の処理能力に応じて第２のハンドシェイク処理の必要性を判断することができる。

本発明の暗号通信方法は、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を実行した後に、その通信を切断せずに、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」としてＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行う暗号通信方法であって、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）においては、公開鍵暗号における秘密鍵による復号を実行せず、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）においては、公開鍵暗号における秘密鍵による復号を実行し、クライアント・サーバ間で、第３者には秘密裏に共通鍵暗号における共通鍵を生成するものとした。

これによると、サーバは、処理負荷の高い、公開鍵暗号における秘密鍵による復号処理をクライントに実施させることが可能となり、システム全体の処理速度を向上させ、かつサーバ費用を低減できるようになる。

なお最近は、ＳＳＬ／ＴＬＳ暗号通信のサーバ機能、及び、クライント機能の両方を搭載しているクライント装置が多いため、多くのシステムで本発明を活用することができる。

また、クライアントをＳＳＬ／ＴＬＳ暗号通信におけるクライント、サーバをＳＳＬ／ＴＬＳ暗号通信におけるサーバとして、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を先に実行するので、ＮＡＴやファイヤーウォールに通信を妨害されることもない。

また、本発明の暗号通信方法は、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作可能であることを、クライントがサーバに対して通知する、若しくは、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作させることを、クライントがサーバに対して要求するものとした。

これによると、サーバは、動的に、クライアントがＳＳＬ／ＴＬＳ暗号通信におけるサーバ機能を保有するか否かを知ることができる。つまり、サーバが、サーバ機能を保有しないクライントを含む多数のクライアントと通信する場合に、サーバ機能を保有するクライアントを容易に識別できる。

また、本発明の暗号通信方法は、暗号スイートの提示で、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作可能なことを、クライントがサーバに対して通知する、若しくは、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作させることを、クライントがサーバに対して要求するものとした。

これによると、サーバは、動的に、クライアントがＳＳＬ／ＴＬＳ暗号通信におけるサーバ機能を保有するか否かを確実に知ることができる。

なお、Ｃｌｉｅｎｔ ＨｅｌｌｏのＲａｎｄｏｍ ｂｙｔｅｓやセッションＩＤに、特別な値を設定し、これをクライントがサーバ機能を保有する合図として利用してもよいが、サーバ機能を保有しないクライアントが偶然、その値を設定した場合に問題になる。

また、本発明の暗号通信方法は、クライアントは、クライアントの処理状況を検知するクライアント状況検知手段を有し、このクライアント状況検知手段によって得られた処理状況に応じて、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」とするＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）の実行が動作可能であることを、サーバに対して通知する、若しくは、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作させることを、サーバに対して要求するか否かを判断するものとした。

これによると、クライアントに、公開鍵における秘密鍵による復号処理を実行する余裕がある場合のみ、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」とすることができるので、クライアントが復号処理で破綻することを防ぐことができる。

また、本発明の暗号通信方法は、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作するように、サーバがクライアントに対してリクエスト、若しくは要求するものとした。

これによると、サーバは、処理負荷の高い、公開鍵暗号における秘密鍵による復号処理をクライントに動的に実施させることが可能となる。例えば、接続してきたクライアントの処理能力が優れていると判別できる場合には、サーバはクライアントに対して、公開鍵暗号における秘密鍵による復号処理を任せるような運用が可能となる。

また、本発明の暗号通信方法は、暗号スイートの提示で、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作するように、サーバがクライアントに対してリクエスト、若しくは要求するものとした。

これによると、クライアントは、動的に、クライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作するようにリクエスト、若しくは要求されたか否かを確実に知ることができる。

なお、Ｓｅｒｖｅｒ ＨｅｌｌｏのＲａｎｄｏｍ ｂｙｔｅｓやセッションＩＤに、特別な値を設定し、これをクライアントが「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として動作するリクエスト、若しくは要求として利用してもよいが、クライアントが普通のサーバに接続し、サーバが偶然、その値を設定した場合に問題になる。

また、本発明の暗号通信方法は、サーバはサーバの処理状況を検知するサーバ状況検知手段を有し、このサーバ状況検知手段によって得られた処理状況に応じて、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」とするＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）の実行を、クライアントに対して、リクエスト、若しくは要求するか否かを判断するものとした。

これによると、サーバに、公開鍵における秘密鍵による復号処理を実行する余裕がなくなってきた場合のみ、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」とすることができるので、サーバが復号処理で破綻することを防ぐことができると共に、クライアントの負荷を少なくすることができる。

また、本発明の暗号通信方法は、サーバはクライントの処理能力を検知する処理能力検知手段を有し、この処理能力検知手段によってクライントの処理能力を把握し、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」とするＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）の実行を、一定の処理能力を有するクライアントに対して、リクエスト、若しくは要求するか否かを判断するものとした。

これによると、通常は処理能力の低いクライアントには負担をかけず、サーバの処理能力が危険なレベルまで低下した場合のみ、緊急的に、処理能力の低いクライアントに復号処理を依頼することができるようになる。

また、本発明の暗号通信方法は、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において、Ｆｉｎｉｓｈｅｄを除く各ｈａｎｄｓｈａｋｅやｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃのデータ部に対して、ダミーデータのＭＡＣを付与するものとした。

これによると、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」としてＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行う、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号に見せかけることが可能となる。こうすれば、ファイヤーウォールに通信を妨害されることが少なくなる。

また、本発明の暗号通信方法は、固定値、若しくは事前に決められた方法、若しくは、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において交換したデータや、それを元にして作成したデータによって、クライアントとサーバで共通鍵を作成し、この共通鍵を用いて、Ｆｉｎｉｓｈｅｄを除く各ｈａｎｄｓｈａｋｅやｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃのデータ部を暗号化するものとした。

これによると、ファイヤーウォールに通信を妨害されることが更に少なくなる。

また、本発明の暗号通信方法は、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において、各ｈａｎｄｓｈａｋｅやｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃのデータ部に対して、ダミーデータのＭＡＣと、ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａヘッダを付与するものとした。

これによると、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」としてＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行う、ＳＳＬ／ＴＬＳ暗号通信におけるデータ通信に見せかけることが可能となる。こうすれば、ファイヤーウォールに通信を妨害されることが少なくなる。

また、本発明の暗号通信方法は、固定値、若しくは事前に決められて方法、若しくは、クライアントを「ＳＳＬ／ＴＬＳ暗号通信におけるクライント」、サーバを「ＳＳＬ／ＴＬＳ暗号通信におけるサーバ」として行うＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）において交換したデータや、それを元にして作成したデータによって、クライアントとサーバで共通鍵を作成し、この共通鍵を用いて、各ｈａｎｄｓｈａｋｅやｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃのデータ部を暗号化するものとした。

これによると、ファイヤーウォールに通信を妨害されることが更に少なくなる。

本発明によれば、第２の鍵の復号処理を分散することができる。

本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第１例を示すシーケンス図 本発明の実施の形態における機能ブロックの一例を示す図 本発明の実施の形態におけるクライアント側のフローチャートの一例を示す図 本発明の実施の形態におけるサーバ側のフローチャートの一例を示す図 本発明の実施の形態におけるハードウェア構成の一例を示す図 本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第２例を示すシーケンス図

まず、本発明の実施の形態の概要について説明する。

本実施の形態では、通信装置（または他の通信装置）であるサーバと他の通信装置（または通信装置）であるクライアントとの間における鍵交換を行うハンドシェイクについて説明する。ハンドシェイク終了後にサーバとクライアントとで暗号通信をするための共通鍵を交換するために、サーバとクライアントとはハンドシェイクの際に共通鍵を共有する。本実施の形態では、具体例として、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬハンドシェイク）を用いる。

ＳＳＬ／ＴＬＳネゴシエーションでは、共通鍵を共有するために公開鍵暗号を利用する。具体的には、クライアントは、共通鍵（第１の鍵）を生成し、サーバがクライアントに送付した公開鍵（第２の鍵）を用いて共通鍵を暗号化し、この暗号化された共通鍵をサーバに送付する。そして、サーバは秘密鍵を用いて公開鍵で暗号化された共通鍵の復号処理を行う。

しかしながら、上述した秘密鍵による復号処理は負荷の重い処理であり、サーバには負担がかかる。例えば、複数のクライアントが同時にＳＳＬ／ＴＬＳネゴシエーションを要求する場合等のサーバの負担は大きい。また、サーバよりもクライアントの方が処理能力が高い場合等は、クライアントで秘密鍵による復号処理を行うことが好ましい。しかし、ＳＳＬ／ＴＬＳネゴシエーションのプロトコルにおいて、サーバが秘密鍵による復号処理を行うこととなっているため、このプロトコルに反してクライアントが秘密鍵による復号処理を行ってしまうと、ファーヤーウォールのチェックにかかり、ハンドシェイクが行うことができない。

そこで、本実施の形態では、まずサーバが「ＳＳＬ／ＴＬＳネゴシエーションのサーバ」として形式的な第１のハンドシェイクを行い（すなわち、サーバは秘密鍵による復号処理を行わず、第１のハンドシェイクでは共通鍵の交換は行われない）、次にサーバが「ＳＳＬ／ＴＬＳネゴシエーションのクライアント」として実質的な第２のハンドシェイクを行う（すなわち、第２のハンドシェイクで共通鍵の交換は行われる）。換言すると、第１のハンドシェイクにおいて、クライアントは「ＳＳＬ／ＴＬＳネゴシエーションのクライアント」として動作するが、第１のハンドシェイクにおいて、クライアントは「ＳＳＬ／ＴＬＳネゴシエーションのサーバ」として動作し、秘密鍵による復号処理を行う。

以上のようにＳＳＬ／ＴＬＳネゴシエーションを行うことで、サーバの負荷を分散することができる。

以下、本発明の実施の形態を、図面を参照しながら説明する。

図１は、本発明によるＳＳＬ／ＴＬＳ暗号通信の一例を示すシーケンス図である。なお説明を簡単にするために、ここで用いる公開鍵暗号はＲＳＡ暗号として説明を行う。

図１において、第１のハンドシェイク処理は（Ｓ１）〜（Ｓ８）に相当し、第２のハンドシェイク処理は（Ｓ９）〜（Ｓ１８）に相当する。第１のハンドシェイク処理では公開鍵で暗号された信号を秘密鍵による復号処理は行われず、前述の復号処理は第２のハンドシェイクで行われる。

（図１−（Ｓ１））クライアントがＣｌｉｅｎｔ Ｈｅｌｌｏを生成し、サーバに対して、このＣｌｉｅｎｔ Ｈｅｌｌｏを送信する。クライアントは、このＣｌｉｅｎｔ Ｈｅｌｌｏで、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることをサーバに知らせる。ここでリバースＳＳＬとは、通常のＳＳＬ／ＴＬＳネゴシエーションのプロトコルと反対の手順（反対の立場）で行うことを意味する。また、上述した第２のハンドシェイクを行うことも意味すると共に、サーバ２が秘密鍵による復号処理を第１のハンドシェイクで行わないことも意味する。すなわち、サーバは通常のＳＳＬ／ＴＬＳネゴシエーションの「クライアント」として動作し、クライアントは通常のＳＳＬ／ＴＬＳネゴシエーションの「サーバ」として動作する。

なおクライアントが、リバースのＳＳＬ／ＴＬＳネゴシエーション利用が可能であることを、サーバに対して知らせる方法は様々であり、１つの方法に限定されるものではない。

例えば、Ｃｌｉｅｎｔ Ｈｅｌｌｏの拡張データ（ｅｘｔｒａ ｄａｔａ）に特殊なコマンドを設定することで、それを知らせることもできれば、Ｃｌｉｅｎｔ ＨｅｌｌｏのＲａｎｄｏｍ Ｂｙｔｅｓに特殊な値を設定することで、リバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせることもできる。

同様に、サーバがクライアントに対して行う、リバースのＳＳＬ／ＴＬＳネゴシエーションの利用要求方法も様々であり、１つの方法に限定されるものではない。

例えば、Ｓｅｒｖｅｒ Ｈｅｌｌｏの拡張データ（ｅｘｔｒａ ｄａｔａ）に特殊なコマンドを設定することで、それを要求することもできれば、Ｓｅｒｖｅｒ ＨｅｌｌｏのＲａｎｄｏｍ Ｂｙｔｅｓに特殊な値を設定することで、それを要求することもできる。

なお、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせなくても、サーバはクライアントに対して、リバースのＳＳＬ／ＴＬＳネゴシエーションの利用を強制的に要求してもよい。

なお、常にリバースのＳＳＬ／ＴＬＳネゴシエーションを行うのであれば、クライアントが、リバースのＳＳＬ／ＴＬＳネゴシエーション利用が可能であることを知らせることも、サーバが、リバースのＳＳＬ／ＴＬＳネゴシエーションの利用を要求することも不要である。

しかし上述ように、クライアントが、リバースのＳＳＬ／ＴＬＳネゴシエーション利用が可能であることを知らせ、サーバが、リバースのＳＳＬ／ＴＬＳネゴシエーションの利用を要求するようにすれば、サーバは、通常のＳＳＬ／ＴＬＳネゴシエーション、及び、リバースのＳＳＬ／ＴＬＳネゴシエーションの両方を利用できる上、容易に切り替えられるため好ましい。

本実施の形態では、最初のバイトが０ｘＦＦである、つまりプライベートな暗号スイートをＣｌｉｅｎｔ Ｈｅｌｌｏに設定することで、クライアントがサーバに対して、リバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせるものとする。このように、暗号スイートの提示で、リバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせる方法は、上述の方法に比べ、確実に伝達されるのでよい。

なお、このプライベートな暗号スイートは、どのように設定してもよい。本実施の形態では以下の暗号スイートによって、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせるものとする。
ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬ ＝｛ ０ｘＦＦ，０ｘ００ ｝
なおこれは、｛ ０ｘ００，０ｘ００ ｝とは異なる暗号スイートである。プライベートな暗号スイートの代りに、｛ ０ｘ００，０ｘ００ ｝の暗号スイートで、クライアントがサーバに対して、リバースのＳＳＬ／ＴＬＳネゴシエーションが可能であることを知らせることも可能であるが、ＳＳＬ／ＴＬＳ暗号通信の仕様から外れるので好ましくない。

ここでＣｌｉｅｎｔ Ｈｅｌｌｏには、このプライベートな暗号スイートのみを設定するとしてもよい。しかし、サーバがリバースのＳＳＬ／ＴＬＳネゴシエーションを実行できない場合や、サーバがリバースのＳＳＬ／ＴＬＳネゴシエーションを実行するか否かを動的に判断する場合もある。このため、このＣｌｉｅｎｔ Ｈｅｌｌｏには、このプライベートな暗号スイートだけでなく、このクライアントで使用可能な他の暗号スイートも合わせて指定するのが好ましい。こうすれば、サーバの判断によって、通常のＳＳＬ／ＴＬＳネゴシエーションも実行できるようになる。

本実施の形態では図１に示すように、複数の暗号スイートを指定したものとし、例えば以下の暗号スイート等である。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
・・・
ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬ ＝ [ ０ｘＦＦ，０ｘ００ ]
（図１−（Ｓ２））サーバはこのＣｌｉｅｎｔ Ｈｅｌｌｏを受信し、処理する。なお、サーバはプライベートな暗号スイートが指定されているのを見て、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションが可能であること知る。

（図１−（Ｓ３））サーバはＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを生成し、クライアントに対して、このＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを送信する。ここでＳｅｒｖｅｒ Ｈｅｌｌｏの暗号スイートとしては、上述のプライベートな暗号スイートを指定する。これによって、サーバはクライアントに対して、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行することを要求する。

なおサーバは、現在のＣＰＵ使用率が大きくなければ、通常のＳＳＬ／ＴＬＳネゴシエーションを選択し、実行してもよい。この場合、サーバはプライベートな暗号スイート以外の暗号スイートを選択する。ＣＰＵは演算処理を行う演算部に相当する。

ここではサーバのＣＰＵ使用率が大きく、サーバは図１のように、プライベートな暗号スイートを指定したものとする。

（図１−（Ｓ４））クライアントはこのＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを受信し、処理する。なお、クライアントはプライベートな暗号スイートが指定されたのを見て、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行することを理解する。

仮にプライベートな暗号スイートが指定されていなければ、この後、クライアントは通常のＳＳＬ／ＴＬＳネゴシエーションを実行する。

（図１−（Ｓ５））クライアントはＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを生成する。なお、Ｃｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅとＦｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は、サーバ証明書に記述されている公開鍵を用いて、正しく計算し設定しても構わないが、公開鍵暗号の処理を省けばパフォーマンスが向上するので、ダミーデータとするのがよい。このダミーデータは、乱数、決められた固定値のどちらでも構わない。

次にクライアントはサーバに対して、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを送信する。

（図１−（Ｓ６））サーバはＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを受信する。なお、サーバはＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｆｉｎｉｓｈｅｄのデータ部は処理しない。つまり、秘密鍵による公開鍵暗号の処理は行わない。また、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃも処理しなくてよい。

（図１−（Ｓ７））サーバはＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを生成する。なお、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は、ダミーデータを設定する。このダミーデータは、乱数、決められた固定値のどちらでも構わない。次にサーバは、クライアントに対して、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを送信する。

（図１−（Ｓ８））クライアントはＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを受信する。なお、クライアントはＦｉｎｉｓｈｅｄのデータ部は処理しない。また、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃも処理しなくてよい。

この一連のＳＳＬ／ＴＬＳネゴシエーションでは、サーバは秘密鍵による公開鍵暗号の処理を行わないので、ＣＰＵ負荷は非常に小さい。しかし、このＳＳＬ／ＴＬＳネゴシエーションはダミーのＳＳＬ／ＴＬＳネゴシエーションなので、正しい共通鍵の交換はできない。

このダミーのＳＳＬ／ＴＬＳネゴシエーションを行う最大の目的は、クライアント・サーバ間でリバースのＳＳＬ／ＴＬＳネゴシエーションを利用するか否かを決定する等、システムの負荷分散を図る決定を行うことにある。

また、このダミーのＳＳＬ／ＴＬＳネゴシエーションには、ファイヤーウォール等の通信制御機器に対し、通常のＳＳＬ／ＴＬＳネゴシエーションに見せかけ、これ以降の通信を遮断させない目的もある。ネットワーク上で送受信されるデータは、第３者から見れば、ＳＳＬ／ＴＬＳ暗号通信の仕様に従っているように見えるため、通信が遮断されることはない。

（図１−（Ｓ９））クライアントがＣｌｉｅｎｔ Ｈｅｌｌｏ Ｒｅｑｕｅｓｔを生成し、サーバに対して、このＣｌｉｅｎｔ Ｈｅｌｌｏ Ｒｅｑｕｅｓｔを送信する。この時点から、クライアントは、「ＳＳＬ／ＴＬＳネゴシエーションにおけるサーバ」の役割を果たすようになる。但し、説明を複雑にしないため、これ以降もクライアントはクライアントと呼称する。

（図１−（Ｓ１０））サーバはＣｌｉｅｎｔ Ｈｅｌｌｏ Ｒｅｑｕｅｓｔを受信する。この時点からサーバは「ＳＳＬ／ＴＬＳネゴシエーションにおけるクライアント」の役割を果たすようになる。但し、説明を複雑にしないため、これ以降もサーバはサーバと呼称する。

（図１−（Ｓ１１））サーバは、Ｃｌｉｅｎｔ Ｈｅｌｌｏ Ｒｅｑｕｅｓｔを受けて、Ｃｌｉｅｎｔ Ｈｅｌｌｏを生成し、クライアントに対して、このＣｌｉｅｎｔ Ｈｅｌｌｏを送信する。

なお、８以降から１１のステップでＴＣＰポートのクローズは行わない。つまり、ダミーのＳＳＬ／ＴＬＳネゴシエーションと同じソケットを引き続き利用する。

また、ダミーのＳＳＬ／ＴＬＳネゴシエーションでは正しくセッションを確立していないので、正しいマスターシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）は生成されない。そのため、ダミーのＳＳＬ／ＴＬＳネゴシエーションでサーバが指定したセッションＩＤは有効になっていない。従って、これ以降のＳＳＬ／ＴＬＳネゴシエーションは、既存セッションの再開のネゴシエーションではなく、新規セッションを確立するネゴシエーションとなる。

サーバが、このＣｌｉｅｎｔ ＨｅｌｌｏのセッションＩＤに、ダミーのＳＳＬ／ＴＬＳネゴシエーションでサーバが指定したセッションＩＤを設定することは構わないが、クライアントは既存セッションの再開のネゴシエーションにならないようにしなければならない。同じくクライアントが、Ｓｅｒｖｅｒ ＨｅｌｌｏでそのセッションＩＤを指定した場合に、サーバも同様に、既存セッションの再開のネゴシエーションにならないようにしなければならない。

ここでは、ＳＳＬ／ＴＬＳ暗号通信の仕様に従って、このＣｌｉｅｎｔ Ｈｅｌｌｏのｓｅｓｓｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈは０とするのが望ましい。また、このＣｌｉｅｎｔ Ｈｅｌｌｏの応答であるＳｅｒｖｅｒ Ｈｅｌｌｏで指定するセッションＩＤは、ダミーのＳＳＬ／ＴＬＳネゴシエーションでサーバが指定したセッションＩＤとは別の値にするのが望ましい。

なお、Ｃｌｉｅｎｔ Ｈｅｌｌｏ Ｒｅｑｕｅｓｔの送受信は割愛して、ダミーのＳＳＬ／ＴＬＳネゴシエーション後、直ちにサーバがＣｌｉｅｎｔ Ｈｅｌｌｏを生成し、クライアントに対して、このＣｌｉｅｎｔ Ｈｅｌｌｏを送信するとしてもよい。

なお、ダミーのＳＳＬ／ＴＬＳネゴシエーションからステップ１８が終了するまでに、クライアント、若しくはサーバがデータ送信をした場合には、受信側は、このデータを破棄し、通信を遮断するのが、中間者攻撃を防御する上で望ましい。

（図１−（Ｓ１２））クライアントはこのＣｌｉｅｎｔ Ｈｅｌｌｏを受信し、処理する。

（図１−（Ｓ１３））クライアントはＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを生成し、サーバに対して、このＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを送信する。

（図１−（Ｓ１４））サーバはこのＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを受信し、処理する。

（図１−（Ｓ１５））サーバはＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを生成し、クライアントに対して、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを送信する。

なおサーバは、ＳＳＬ／ＴＬＳ暗号通信の仕様の通り、この時点で正しい共通鍵（ＭＡＣ鍵を含む）を生成できる。従って、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は共通鍵で正しく暗号化される。

なおここで、サーバは、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを生成するに当たって、公開鍵による公開鍵暗号の処理を行うが、秘密鍵による公開鍵暗号の処理に比べれば、一桁以上、演算処理が少なく、ＣＰＵにかかる負荷はとても小さい。

（図１−（Ｓ１６））クライアントはＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを受信する。ここでクライアントは、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを処理するために、秘密鍵による公開鍵暗号の復号処理を行う。

その処理の結果、ＳＳＬ／ＴＬＳ暗号通信の仕様の通り、クライアントはこの時点で正しい共通鍵（ＭＡＣ鍵を含む）を生成できる。従って、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は共通鍵で正しく復号化される。

（図１−（Ｓ１７））クライアントはＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを生成し、サーバに対して、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを送信する。なお、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は共通鍵で正しく暗号化される。

（図１−（Ｓ１８））サーバはＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄを受信し、処理する。なお、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）は共通鍵で正しく復号化され、処理される。

これ以降、クライアント・サーバ間では正しくＳＳＬ／ＴＬＳ暗号通信の共通鍵暗号が行われる。

なお、ＳＳＬ／ＴＬＳ暗号通信の仕様に従えば、（Ｓ９）から（Ｓ１８）のステップでやりとりされる各メッセージのデータ部はすべて暗号化しなければならないが、（Ｓ９）から（Ｓ１８）のステップでやりとりされる各メッセージのデータ部はＦｉｎｉｓｈｅｄを除けば、実際は暗号化しなくてもよい。

次に図６を用いて、図１とは異なる例について説明する。図６は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第２例を示すシーケンス図である。なお、図６において、第１のハンドシェイク処理は（Ｓ１）〜（Ｓ８）に相当し、第２のハンドシェイク処理は（Ｓ９）〜（Ｓ１８）に相当する。

図６に示したように、難読化を目的に、Ｆｉｎｉｓｈｅｄを除く各メッセージのデータ部にダミーのＭＡＣを付与し、共通鍵暗号による暗号化された再接続ネゴシエーションが行われているように見せかけてもよい。更にＳＳＬ／ＴＬＳネゴシエーションで送受信した乱数や固定値を共通鍵として、データ部（ダミーのＭＡＣを含む）を暗号化（スクランブル化）しても構わない。

このような難読化は、ファイヤーウォールが厳密に各メッセージのデータ部をチェックしている場合に有効な手法となる。

なおあえて共通鍵を生成するなら、クライアントが、ｐｒｅ＿ｍａｓｔｅｒ＿ｓｅｃｒｅｔを乱数で生成し、このｐｒｅ＿ｍａｓｔｅｒ＿ｓｅｃｒｅｔを非暗号のままＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔとして扱い、サーバもＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをそのままｐｒｅ＿ｍａｓｔｅｒ＿ｓｅｃｒｅｔとして扱い、クライアントとサーバで共通鍵を生成するとするのが好ましい。

ここではプライベートな暗号スイートを
ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬ ＝｛ ０ｘＦＦ，０ｘ００ ｝
としたが、これを例えば図６のように、
ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＮＵＬＬ
＝｛ ０ｘＦＦ，０ｘ００ ｝
に変え、暗号・復号化を行うとすれば、ＳＳＬ／ＴＬＳ暗号通信の仕様に最も良く合い、ＳＳＬ／ＴＬＳ暗号通信を実現するＳＳＬ／ＴＬＳ暗号モジュールの改変が少なくて済む。

なお、ファイヤーウォールが厳密にＳＳＬ／ＴＬＳの再ネゴシエーションで送受信されるｈａｎｄｓｈａｋｅのパケット数をカウントしている場合には、ダミーのｈａｎｄｓｈａｋｅのパケットを送受信し、何度かＳＳＬ／ＴＬＳネゴシエーションが実行されているように見せかけてもよい。

また、（Ｓ９）から（Ｓ１８）のステップで送受信されるすべてのメッセージ（Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを含む）を、図６のように、暗号化されたデータ通信であるように見せかけるのもよい方法である。つまり、（Ｓ９）から（Ｓ１８）のステップでやりとりされる各メッセージを、データ通信、つまりａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａのデータ部として送受信する。このようにすれば、ファイヤーウォールが厳密にＳＳＬ／ＴＬＳの再ネゴシエーションで送受信されるｈａｎｄｓｈａｋｅのパケット数をカウントしていたとしても、チェックにかからなくなる。

しかし、通常、ＳＳＬ／ＴＬＳ暗号通信は、アプリケーションプログラムとは分離された、ＳＳＬ／ＴＬＳ暗号通信モジュールによって実現されるので、アプリケーションプログラムが利用するデータ通信を使って、ＳＳＬ／ＴＬＳ暗号通信モジュールがＳＳＬ／ＴＬＳネゴシエーションを行うのは良くない。このようなつくりにすると、ＳＳＬ／ＴＬＳ暗号通信モジュールは、アプリケーションプログラムが利用するデータ通信の中身を常にチェックしなければならず、パフォーマンスを落としてしまう。

但しこのケースでは、ダミーのＳＳＬ／ＴＬＳネゴシエーション後、直ちに、９から１８のＳＳＬ／ＴＬＳネゴシエーションが行われるので、データ通信を使ってＳＳＬ／ＴＬＳネゴシエーションを行ったとしても、パフォーマンスを落とすことはない。ＳＳＬ／ＴＬＳ暗号通信モジュールがデータ通信の中身をチェックするのは、ダミーのＳＳＬ／ＴＬＳネゴシエーション開始後から、９から１８のＳＳＬ／ＴＬＳネゴシエーション終了後までで、このＳＳＬ／ＴＬＳネゴシエーション終了後は、データ通信の中身をチェックすることはない。

なお、データ通信でＳＳＬ／ＴＬＳネゴシエーションを行うのであれば、独自の方法で共通鍵交換を行ってもよいように思われるが、これは危険である。ダミーのＳＳＬ／ＴＬＳネゴシエーションでは共通鍵の交換は行っていないので、データ通信であっても、９から１８のＳＳＬ／ＴＬＳネゴシエーションは基本的には非暗号（スクランブル化していたとしても第３者には中身を解析される）である。従って、ここで行う共通鍵の交換には、各種攻撃に耐性や知見のある暗号通信仕様に従うのがよい。クライアントとサーバがＳＳＬ暗号通信に対応していることを考慮すれば、ここで行う共通鍵の交換には、図１のように、ＳＳＬ／ＴＬＳネゴシエーションを利用することが望ましい。

なお、このリバースのＳＳＬ／ＴＬＳネゴシエーション終了後、再接続する場合には、クライアントは「ＳＳＬ／ＴＬＳネゴシエーションにおけるクライアント」の役割に、サーバは「ＳＳＬ／ＴＬＳネゴシエーションにおけるサーバ」の役割に戻し、通常のＳＳＬ／ＴＬＳ暗号通信の仕様に従うのが、複雑にならずによい。

もし新規ＩＤで接続し、かつクライアントで秘密鍵による公開鍵暗号を行いたいときは、ステップ（Ｓ１）に戻ればよい。

このように、図１のようにダミーのＳＳＬ／ＴＬＳネゴシエーションを行えば、ファイヤーウォール等の通信を制御する機器がクライアント・サーバ間に介在していたとしても、通信が遮断されることはない。

また、図１のようにリバースのＳＳＬ／ＴＬＳネゴシエーションを行えば、サーバは秘密鍵による公開鍵暗号処理を行わなくても済むので、ＣＰＵ負荷を小さくできる。従って、サーバ費用を低減できる効果がある。サーバが相手にするクライアント台数が増せば増すほど、この効果は大きくなる。このように本発明は、ＮＡＴトラバーサル技術とは異なるものである。

しかもサーバは、通常のＳＳＬ／ＴＬＳネゴシエーションを行うか、リバースのＳＳＬ／ＴＬＳネゴシエーションを行うかを判断し実行できるので、サーバは的確な負荷分散(ロードバランス)を行うことが可能である。サーバの負荷が低い時は、通常のＳＳＬ／ＴＬＳネゴシエーションを行い（この場合、ダミーのＳＳＬ／ＴＬＳネゴシエーションが本当のＳＳＬ／ＴＬＳネゴシエーションとなる）、サーバの負荷が高い時は、リバースのＳＳＬ／ＴＬＳネゴシエーションを行うことで、システム全体の負荷を最適化することが可能である。つまり、システムの費用対効果を最大化できる。

従って、ダミーのＳＳＬ／ＴＬＳネゴシエーションは、ＮＡＴトラバーサルだけでなく、システムの負荷分散(ロードバランス)を行う上でもとても重要である。

特にインターネット上に公開されるサーバを運用する際にこの効果は非常に高い。一般的に公開サーバに対しては、頻繁なＤＯＳ攻撃がかけられる。ＳＳＬ／ＴＬＳ暗号通信をサポートする公開サーバの場合、無駄な秘密鍵による公開暗号処理を頻繁に実行されると、それに支払うコストは莫大なものになる。

しかしリバースのＳＳＬ／ＴＬＳネゴシエーションをサポートするクライアントのみを公開サーバへの接続対象とするような工夫を行えば、コストをかけずにＣＰＵ使用率を一定に保て、サービスに支障をきたさなくなる。

その上、この一連のＳＳＬ／ＴＬＳネゴシエーションは、ＳＳＬ／ＴＬＳ暗号通信の仕様から外れる部分が少なく、ＳＳＬ／ＴＬＳ暗号通信に対する各種攻撃に対する知見を利用でき安全である。

また、ＳＳＬ／ＴＬＳ暗号通信の仕様から外れる部分が少ないので、ＳＳＬ／ＴＬＳ暗号通信を実現するＳＳＬ／ＴＬＳ暗号モジュールのつくりを単純化でき、開発費を削減できる。

図２は、図１の機能ブロック図の一例である。また図３は、図２のクライアント１のフローチャートを、図４は図２のサーバ２のフローチャートを示す。次にこの図２、図３、図４を用いて説明を行う。

なお、図３において、第１のハンドシェイク処理は（Ｓ１）〜（Ｓ１０）に相当し、第２のハンドシェイク処理は（Ｓ１１）〜（Ｓ２６）に相当する。図４において、第１のハンドシェイク処理は（Ｓ１）〜（Ｓ１１）に相当し、第２のハンドシェイク処理は（Ｓ１３）〜（Ｓ２６）に相当する。

クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を行う。

（図３−（Ｓ１））はじめに、ＳＳＬネゴシエーション（クライアント）部４００がＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを生成し、これをデータ送信部２００に送る。

なお、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージで指定した暗号スイートは、以下のようなものだったとして説明を行う。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
・・・
ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬ ＝ [ ０ｘＦＦ，０ｘ００ ]
ここで、ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬは、プライベートな暗号スイートであり、[ ０ｘ００，０ｘ００ ]とは異なる暗号スイートである。このプライベートな暗号スイートは、クライアントがサーバに対して、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションを実行可能なことを知らせるものである。

なお、クライアント１の処理能力検知（クライアント）部（図示せず）が検知した自らのＣＰＵの処理能力情報（ＣＰＵの最大処理能力情報）をＳＳＬネゴシエーション（クライアント）部４００に通知し、ＳＳＬネゴシエーション（クライアント）部４００はこの処理能力情報をＣｌｉｅｎｔ Ｈｅｌｌｏメッセージに含ませて、サーバに対して知らせるものとする。そのような方法は様々であるが、例えば、Ｒａｎｄｏｍ ｂｙｔｅｓやセッションＩＤの一部に、その処理能力のレベル値を設定するとしてもよい。ここでは、Ｒａｎｄｏｍ ｂｙｔｅｓの一部に、処理能力情報（処理能力のレベル値）を設定したものとする。なお、最大処理能力の情報は予めフラグ（メモリ）等に格納されておいてもよい。

なお、クライアント１は処理（使用）状況検知（クライアント）部（図示せず）をさらに有し、処理（使用）状況検知（クライアント）部はＣＰＵ使用率情報を検知し、この情報をＳＳＬネゴシエーション（クライアント）部４００に通知する。ＳＳＬネゴシエーション（クライアント）部４００はＣＰＵ使用率情報に基づいて、公開鍵暗号における秘密鍵による復号処理を行うことが可能かどうかをサーバ２に通知する。例えば、ＣＰＵ使用率が所定値以上である場合、ＳＳＬネゴシエーション（クライアント）部４００はプライベートな暗号スイートを含む暗号スイートリストをサーバ２に通知し、ＣＰＵ使用率が所定値以下である場合、ＳＳＬネゴシエーション（クライアント）部４００はプライベートな暗号スイートを含まずに暗号スイートリストをサーバ２に通知する。これにより、公開鍵暗号における秘密鍵による復号処理によってクライアント１の他の処理が破綻することを抑制することができる。

以上より（図３−（Ｓ１））では、ＳＳＬネゴシエーション（クライアント）部４００は、プライベートな暗号スイートを含む暗号スイートリストの情報とＣＰＵの処理能力情報の情報とを含むＣｌｉａｎｔ Ｈｅｌｌｏを作成する。なお、Ｃｌｉａｎｔ ＨｅｌｌｏにクライアントのＣＰＵ使用率の情報を含ませてもよい。

（図３−（Ｓ２））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを送信する。

（図３−（Ｓ３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。

（図４−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部３１０は、クライアント１が送信したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを解釈するＳＳＬネゴシエーション（サーバ）部５１０に送る。

（図４−（Ｓ２））ＳＳＬネゴシエーション（サーバ）部５１０は、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを処理する。

（図４−（Ｓ３））この際ＳＳＬネゴシエーション（サーバ）部５１０は、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージに、リバースのＳＳＬ／ＴＬＳネゴシエーションの合図であるＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬの暗号スイートが指定されているかをチェックする。

ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬが指定されていなければ、リバースのＳＳＬ／ＴＬＳネゴシエーションは実行できないので、通常のＳＳＬ／ＴＬＳネゴシエーションを行う。すなわち、プライベートな暗号スイート以外の暗号スイートを選択する。

なおサーバが、リバースのＳＳＬ／ＴＬＳネゴシエーション可能なクライントしか相手にしない場合には、リバースのＳＳＬ／ＴＬＳネゴシエーションができないアクセスはＤＯＳ攻撃なので、ここで処理を中断するのが望ましい。これにより、安全性を高めることができる。

ここでは、図３−（Ｓ１）で説明したように、ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬの暗号スイートが指定されているので、ＳＳＬネゴシエーション（サーバ）部５１０は、クライアントがリバースのＳＳＬ／ＴＬＳネゴシエーションが可能であると判断する。

（図４−（Ｓ４））サーバ２は処理（使用）状況検知（サーバ）部（図示せず）をさらに有し、処置（使用）状況検知（サーバ）部はＣＰＵ使用率情報を検知し、この情報をＳＳＬネゴシエーション（サーバ）部５１０に通知し、ＳＳＬネゴシエーション（サーバ）部５１０はサーバ２のＣＰＵ使用率情報をチェックする。サーバ２のＣＰＵ使用率が小さければ（例えば、所定値（閾値）よりも低ければ）、サーバ２で秘密鍵による公開鍵暗号処理を実行しても、サーバ２に支障が出ないので、通常のＳＳＬ／ＴＬＳネゴシエーションを行う。なおこの判断はせずに、常にリバースのＳＳＬ／ＴＬＳネゴシエーションを行うとすることも可能である。

なお（図４−（Ｓ４））で、ＳＳＬネゴシエーション（サーバ）部５１０は、受信したＣｌｉａｎｔ Ｈｅｌｌｏに含まれるクライアント１のＳＳＬネゴシエーション（サーバ）部５１０は、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージのＲａｎｄｏｍ ｂｙｔｅｓの一部に示されているクライアント１の処理能力情報（処理能力のレベル値）をチェックし、一定のレベル値（図２の処理能力の閾値）以上である場合のみ、リバースのＳＳＬ／ＴＬＳネゴシエーションを行うとすれば、システム全体のパフォーマンスを最適にできる。なお、どのレベルでリバースのＳＳＬ／ＴＬＳネゴシエーションを実行するかはサーバの処理能力に依存する。

本実施の形態ではサーバのＣＰＵ使用率、及び、クライアントの処理能力が高く、ＳＳＬネゴシエーション（サーバ）部５１０がリバースのＳＳＬ／ＴＬＳネゴシエーションを実行すると判断したとして、以下、説明を行う。

（図４−（Ｓ５））ＳＳＬネゴシエーション（サーバ）部５１０は、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークを付ける。

（図４−（Ｓ６））ＳＳＬネゴシエーション（サーバ）部５１０は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。この際、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付いているので、暗号スイートしては、リバースのＳＳＬ／ＴＬＳネゴシエーションの合図であるＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬを指定する。

なお暗号スイート以外は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、及び、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージのデータ部には、正しい値を設定しなくてもよい。乱数や固定値等ダミーデータでも構わない。これにより、サーバ２は不必要な処理を省略できる。

なお、ＳＳＬネゴシエーション（サーバ）部５１０は、これまでのステップに関係なく、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するために、無条件に、ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬを指定することも可能である。

（図４−（Ｓ７））データ送信部２１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。なお、サーバ２の処理を簡略化するために、ここで公開鍵をクライアント１に送らなくてもよい。

（図４−（Ｓ８））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。

（図３−（Ｓ３））クライアント１のデータ受信部３００は、サーバ２が送信したＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部３００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理するＳＳＬネゴシエーション（クライアント）部４００に送る。

（図３−（Ｓ４））ＳＳＬネゴシエーション（クライアント）部４００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏで、リバースのＳＳＬ／ＴＬＳネゴシエーションの合図であるＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬが指定されているかをチェックする。ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬが指定されていなければ、通常のＳＳＬ／ＴＬＳネゴシエーションを実行する。

（図３−（Ｓ５））ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬが指定されている場合、ＳＳＬネゴシエーション（クライアント）部４００は、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するものと判断し、ＳＳＬネゴシエーション（クライアント）部４００が、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークを付ける。

（図３−（Ｓ６））ＳＳＬネゴシエーション（クライアント）部４００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理する。

なお、ＳＳＬネゴシエーション（クライアント）部４００は、フラグ（メモリ）を見て、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークがあれば、実際は、このメッセージは、何も処理せずに廃棄しても構わない。これにより、クライアント１は不必要な処理を省略できる。

（図３−（Ｓ７））ＳＳＬネゴシエーション（クライアント）部４００は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２００に送る。

なお、ＳＳＬネゴシエーション（クライアント）部４００は、フラグ（メモリ）を見て、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークがあれば、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅメッセージ、及び、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）には、正しい値を設定しなくてもよい。乱数や固定値等ダミーデータでも構わない。

（図３−（Ｓ８））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを送信する。

（図３−（Ｓ９））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。

（図４−（Ｓ８））データ受信部３１０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理するＳＳＬネゴシエーション（サーバ）部５１０に送る。

（図４−（Ｓ９））ＳＳＬネゴシエーション（サーバ）部５１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理する。但し、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付いているので、Ｃｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅのＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔは少なくとも処理しない。つまり秘密鍵による公開鍵暗号処理は実施しない。また、Ｆｉｎｉｓｈｅｄメッセージのデータチェックも行わない。その他のデータも処理せずに、廃棄してよい。これにより、クライアント１は不必要な処理を省略できる。

（図４−（Ｓ１０））ＳＳＬネゴシエーション（サーバ）部５１０は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。但し、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付いているので、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）には、乱数や固定値等ダミーデータを設定する。

なお、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付いているので、ＳＳＬネゴシエーション（サーバ）部５１０は、公開鍵暗号における秘密鍵による復号処理を行う共通鍵暗号・復号部７１０ではなく、ＳＳＬネゴシエーション（クライアント）部４１０を呼び出す。そしてＳＳＬネゴシエーション（サーバ）部５１０は、これ以降のメッセージの送受信をＳＳＬネゴシエーション（クライアント）部４１０に任せる。

（図４−（Ｓ１１））データ送信部２１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを送信する。

（図４−（Ｓ１２））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。なおここでメッセージ受信待ちになるのは、ＳＳＬネゴシエーション（クライアント）部４１０である。

（図３−（Ｓ９））クライアント１のデータ受信部３００は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部３００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理するＳＳＬネゴシエーション（クライアント）部４００に送る。

（図３−（Ｓ１０））ＳＳＬネゴシエーション（クライアント）部４００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理する。

但し、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付いているので、少なくともＦｉｎｉｓｈｅｄメッセージのデータチェックは行わない。その他のデータも処理せずに、廃棄してよい。これにより、クライアント１は不必要な処理を省略できる。

以上のように、ここまでのＳＳＬ／ＴＬＳネゴシエーションは、ダミーのＳＳＬ／ＴＬＳネゴシエーションとなる。すなわち、ファイヤーウォールに引っかからないために形式的にＳＳＬネゴシエーションの手順（プロトコル）通りに処理が行われたが、鍵交換等の通常のＳＳＬネゴシエーションで行われる処理は行われていない。

なお、ダミーのＳＳＬ／ＴＬＳネゴシエーション終了後は、次のＳＳＬ／ＴＬＳネゴシエーションが終了するまでは、サーバ２は、中間者攻撃を防御するためデータ受信をしない。サーバ２はデータ受信した場合には、このデータを破棄し、通信を遮断する。これにより、安全性を高めることができる。

次に、ＳＳＬネゴシエーション（クライアント）部４００は、フラグ（メモリ）に、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するマークが付けられているので、共通鍵暗号・復号部７００、若しくは通信データ生成部８００ではなく、ＳＳＬネゴシエーション（サーバ）部５００を呼び出す。そして、ＳＳＬネゴシエーション（クライアント）部４００はこれ以降のメッセージの送受信をＳＳＬネゴシエーション（サーバ）部５００に任せる。

なお、図２では、フラグ（メモリ）を利用して、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するか否かを示すようにしているが、この実現方法はこれに限られるものではなく、様々な方法が可能である。

（図３−（Ｓ１１））ＳＳＬネゴシエーション（サーバ）部５００は、Ｃｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを生成し、これをデータ送信部２００に送る。

（図３−（Ｓ１２））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを送信する。

（図３−（Ｓ１３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。なおここでメッセージ受信待ちになるのは、ＳＳＬネゴシエーション（サーバ）部５００である。

（図４−（Ｓ１２））データ受信部３１０は、クライアント１が送信したＣｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、このＣｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを、Ｃｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを処理するＳＳＬネゴシエーション（クライアント）部４１０に送る。

（図４−（Ｓ１３））ＳＳＬネゴシエーション（クライアント）部４１０は、Ｃｌｉｅｎｔ Ｈｅｌｌｏ ｒｅｑｕｅｓｔメッセージを処理する。具体的には、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージの生成を開始する。

（図４−（Ｓ１４））ＳＳＬネゴシエーション（クライアント）部４１０がＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを生成し、これをデータ送信部２１０に送る。

なお、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージでは、ＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬの暗号スイートは指定しないものとする。

（図４−（Ｓ１５））データ送信部２１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを送信する。

（図４−（Ｓ１６））この後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。

（図３−（Ｓ１３））データ受信部３００は、サーバ２が送信したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部３００は、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを処理するＳＳＬネゴシエーション（サーバ）部５００に送る。

（図３−（Ｓ１４））ＳＳＬネゴシエーション（サーバ）部５００は、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを処理する。

（図３−（Ｓ１５））ＳＳＬネゴシエーション（サーバ）部５００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２００に送る。なお、暗号スイートしては、リバースのＳＳＬ／ＴＬＳネゴシエーションの合図であるＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬを指定しないものとする。

なお、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅは、クライアント１が保持する公開鍵Ｎと公開鍵Ｅの情報を含む。

（図３−（Ｓ１６））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。

（図３−（Ｓ１７））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。

（図４−（Ｓ１６））サーバ２のデータ受信部３１０は、クライアント１が送信したＳｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理するＳＳＬネゴシエーション（クライアント）部４１０に送る。

（図４−（Ｓ１７））ＳＳＬネゴシエーション（クライアント）部４１０は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理する。

なお、ＳＳＬネゴシエーション（クライアント）部４１０はＳｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅから、クライアント１が保持する公開鍵Ｎと公開鍵Ｅの情報を読み出す。

（図４−（Ｓ１８））ＳＳＬネゴシエーション（クライアント）部４１０は、乱数生成部８１０にプリマスターシークレット（ｐｒｅｍａｓｔｅｒ ｓｅｃｒｅｔ）となる乱数を生成させる。

（図４−（Ｓ１９））共通鍵生成部７６０は、乱数から共通鍵暗号方式で用いる共通鍵（ＭＡＣ鍵を含む）を生成する。

（図４−（Ｓ２０））公開鍵暗号部６１０は、公開鍵Ｎと公開鍵Ｅを用いて乱数を暗号化し、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔを生成する。

（図４−（Ｓ２１））ＳＳＬネゴシエーション（クライアント）部４１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。なおこのＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）は共通鍵で暗号化される。

（図４−（Ｓ２２））データ送信部２１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを送信する。

（図４−（Ｓ２３））この後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。

（図３−（Ｓ１７））データ受信部３００は、サーバ２が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部３００は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ／Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理するＳＳＬネゴシエーション（サーバ）部５００に送る。

（図３−（Ｓ１８））ＳＳＬネゴシエーション（サーバ）部５００は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを処理する。なお、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔは公開鍵復号部６００に送る。

（図３−（Ｓ１９））公開鍵復号部６００は、クライアント１が保持する公開鍵Ｎと秘密鍵Ｄを用いて、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔを復号化し、乱数を取得する。

（図３−（Ｓ２０））共通鍵生成部７５０は、乱数から共通鍵暗号方式で用いる共通鍵（ＭＡＣ鍵を含む）を生成する。

（図３−（Ｓ２１））ＳＳＬネゴシエーション（サーバ）部５００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理する。なおこのＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）は共通鍵で復号化され処理される。

（図３−（Ｓ２２））ＳＳＬネゴシエーション（サーバ）部５００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２００に送る。なおこのＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）は共通鍵で暗号化される。

（図３−（Ｓ２３））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを送信する。

（図３−（Ｓ２４））ＳＳＬネゴシエーション（サーバ）部５００は、通信データ生成部８００を呼び出す。通信データ生成部８００は通信データを生成する。

（図３−（Ｓ２５））共通鍵暗号・復号部７００は、共通鍵を用いて、通信データを暗号化し、暗号データ（ＭＡＣを含む）を生成する。そして、共通鍵暗号・復号部７００はこの暗号データ（ＭＡＣを含む）をデータ送信部２００に送る。

（図３−（Ｓ２６））データ送信部２００は、ネットワーク制御装置１００を介して、サーバ２に対して、この暗号データ（ＭＡＣを含む）を送信する。

（図４−（Ｓ２３））データ受信部３１０は、クライアント１が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを解釈するＳＳＬネゴシエーション（クライアント）部４１０に送る。

（図４−（Ｓ２４））ＳＳＬネゴシエーション（クライアント）部４１０は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ／Ｆｉｎｉｓｈｅｄメッセージを処理する。なおこのＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）は共通鍵で復号化され処理される。

（図４−（Ｓ２５））この後、サーバ２はクライアント１からのデータ受信待ち状態になる。なおここでデータ受信待ちになるのは、共通鍵暗号・復号部７１０である。

（図４−（Ｓ２５））データ受信部３１０は、クライアント１が送信した暗号データ（ＭＡＣを含む）を、ネットワーク制御装置１１０を介して受信する。データ受信部３１０は、この暗号データ（ＭＡＣを含む）を、暗号データ（ＭＡＣを含む）を処理する共通鍵暗号・復号部７１０に送る。

（図４−（Ｓ２６））共通鍵暗号・復号部７１０は、共通鍵を用いて、暗号データ（ＭＡＣを含む）を復号化し、通信データを取得する。

これ以降、クライアント・サーバ間では正しくＳＳＬ／ＴＬＳ暗号通信の共通鍵暗号が行われる。

なお、ＳＳＬ／ＴＬＳ暗号通信の仕様に従えば、ダミーのＳＳＬ／ＴＬＳネゴシエーション中のＦｉｎｉｓｈｅｄメッセージ処理から、各メッセージのデータ部はすべて暗号化しなければならないが、実際は暗号化しなくても問題ない。しかし、難読化を目的に、各メッセージのデータ部を、ＳＳＬ／ＴＬＳネゴシエーションで送受信した乱数や固定値を共通鍵として、暗号化（スクランブル化）しても構わない。

このような難読化は、ファイヤーウォールが厳密に各メッセージのデータ部をチェックしている場合に有効な手法となる。

なお、ファイヤーウォールが厳密にＳＳＬ／ＴＬＳの再ネゴシエーションで送受信されるｈａｎｄｓｈａｋｅのパケット数をカウントしている場合には、ダミーのｈａｎｄｓｈａｋｅのパケットを送受信し、何度かＳＳＬ／ＴＬＳネゴシエーションが実行されているように見せかけてもよい。

また、ダミーのＳＳＬ／ＴＬＳネゴシエーション以降の各メッセージ（Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを含む）を、暗号化されたデータ通信であるように見せかけてもよい。つまり、各メッセージを、データ通信、即ちａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａのデータ部として送受信する。つまり、各メッセージ（Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを含む）に、ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａヘッダとダミーのＭＡＣを付与する。

また、ここで上述した図１〜４、６について補足の説明を行う。

図示していないが、クライアント１が有する公開鍵復号部６００をサーバ２も同様に有する。これにより、サーバ２も公開鍵暗号された信号を復号することができる。

また、本実施の形態において、ＳＳＬネゴシエーション（サーバ）部５００とＳＳＬネゴシエーション（クライアント）部４００とは他の通信装置（クライアント１）とハンドシェイクを行うサーバ２側の認証処理部に相当し、さらにこのサーバ２側の認証処理部は鍵復号化部である公開鍵復号部と鍵暗号化部である公開鍵暗号部６１０を含んでもよい。同様に、ＳＳＬネゴシエーション（サーバ）部５１０とＳＳＬネゴシエーション（クライアント）部４１０とはクライアント１側の認証処理部に相当する。

なお、第１の鍵とは、サーバ２（またはクライアント１）で生成される共通鍵のことであり、この共通鍵を生成するための乱数等も含む。第２の鍵とは、第１の鍵の暗号化する公開鍵である。

なお、サーバ部２に処理能力検知（サーバ）部を設けてもよい。これにより、サーバ２はサーバ２の処理能力とクライアント１の処理能力とに基づいて（例えば、それぞれの処理能力を比較して）、リバースＳＳＬを行うかどうかを決定することができる。

なお、リバースＳＳＬを行うかどうかの判断は、クライアント１が行っても、サーバが行ってもよい。クライアント１またはサーバ２は、サーバ２のＣＰＵ使用率、クライアント１のＣＰＵ使用率、サーバ２の最大処理能力、クライアント１の最大処理能力、等に基づいてリバースＳＳＬを行うかどうかを決定すればよい。

図５は、図２のハードウェア構成図の一例である。クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、書き換え不可の不揮発性メモリであるＲＯＭ３０とネットワークのデータ送受信を実行するＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）／ＰＨＹ４０で構成されている。一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ３１とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ４１で構成されている。また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ４０とＭＡＣ／ＰＨＹ４１を介してネットワークで接続されている。

はじめにクライアント１のハード構成に関して説明を行う。図３に示したクライアント１の各処理部は、ＣＰＵ１０、及びＲＡＭ２０で実行される。

共通鍵生成部７５０が生成した共通鍵、クライアントのＣＰＵの使用率状況を示すＣＰＵ使用率情報、及び、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するか否かを示すフラグ（メモリ）は、ＲＡＭ２０に保存される。

処理能力情報、公開鍵Ｎ、公開鍵Ｅ、秘密鍵Ｄは、ＲＯＭ３０に保存する。この内、処理能力情報、公開鍵Ｎ、及び、公開鍵ＥはＲＡＭ２０に移動させて利用してもよいが、秘密鍵Ｄは耐タンパ装置の不揮発性メモリで利用するのが望ましい。

ＭＡＣ／ＰＨＹ４０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。

次にサーバ２のハード構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、及びＲＡＭ２１で実行される。

共通鍵生成部７６０が生成した共通鍵、クライアント１から取得した公開鍵Ｎと公開鍵Ｅ、サーバのＣＰＵの使用率状況を示すＣＰＵ使用率情報、及び、リバースのＳＳＬ／ＴＬＳネゴシエーションを実行するか否かを示すフラグ（メモリ）は、ＲＡＭ２１に保存される。

処理能力の閾値の情報は、通常固定値なのでＲＯＭ３０に保存する。しかしサーバの負荷に応じて動的に閾値を変更させる等、ＲＡＭ２０に移動させて利用してもよい。

ＭＡＣ／ＰＨＹ４１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１１０を実現するものである。

本発明にかかるＳＳＬ／ＴＬＳ暗号通信は、ファイヤーウォール等の通信機器との親和性が良く、しかもサーバがＣＰＵ使用率（負荷）に応じて、クライアントが、秘密鍵による公開鍵暗号（復号）処理を代行できるので、サーバ費用の低減を図れる等有用である。

１ クライアント
２ サーバ
１０ ＣＰＵ（クライアント側）
１１ ＣＰＵ（サーバ側）
２０ ＲＡＭ（クライアント側）
２１ ＲＡＭ（サーバ側）
３０ ＲＯＭ（クライアント側）
３１ ＲＯＭ（サーバ側）
４０ ＭＡＣ／ＰＨＹ（クライアント側）
４１ ＭＡＣ／ＰＨＹ（サーバ側）
１００ ネットワーク制御装置（クライアント側）
１１０ ネットワーク制御装置（サーバ側）
２００ データ送信部（クライアント側）
２１０ データ送信部（サーバ側）
３００ データ受信部（クライアント側）
３１０ データ受信部（サーバ側）
４００ ＳＳＬネゴシエーション（クライアント）部（クライアント側）
４１０ ＳＳＬネゴシエーション（クライアント）部（サーバ側）
５００ ＳＳＬネゴシエーション（サーバ）部（クライアント側）
５１０ ＳＳＬネゴシエーション（サーバ）部（サーバ側）
６００ 公開鍵復号部（クライアント側）
６１０ 公開鍵暗号部（サーバ側）
７００ 共通鍵暗号・復号部（クライアント側）
７１０ 共通鍵暗号・復号部（サーバ側）
７５０ 共通鍵生成部（クライアント側）
７６０ 共通鍵生成部（サーバ側）
８００ 通信データ生成部
８１０ 乱数生成部

Claims (12)

1. 他の通信装置と第１の鍵を用いて通信を行う通信装置であって、
   前記他の通信装置との間でハンドシェイク処理を行う認証処理部を備え、
   前記認証処理部は、
   前記第１の鍵を前記他の通信装置との間で交換するための第２の鍵の復号処理を行う鍵復号化部と、を有し、
   前記第２の鍵を用いて暗号処理を行う鍵暗号化部と、
   前記鍵復号化部による前記復号処理を除く第１のハンドシェイク処理を行い、
   前記第１のハンドシェイク処理が終了した場合、
   前記鍵復号化部による前記復号処理を除く第２のハンドシェイク処理を行い、
   前記第２のハンドシェイク処理において、前記鍵暗号化部に前記第２の鍵を用いて前記第１の鍵の情報を暗号化させ、前記第２の鍵で暗号化された前記第１の鍵の情報を前記他の通信装置に送信する、通信装置。
2. 請求項１記載の通信装置であって、
   前記認証処理部は、ダミーデータを用いて前記他の通信装置と第１のハンドシェイク処理を行う、通信装置。
3. 請求項１記載の通信装置であって、
   演算処理を行う演算部と、
   前記演算部の使用状況を検知し、前記使用状況の情報を前記認証処理部に通知する使用状況検知部と、をさらに有し、
   前記認証処理部は、前記使用状況に基づいて前記第１のハンドシェイク処理で前記鍵復号化部による前記復号処理を除くかどうかを決定する、通信装置。
4. 請求項３記載の通信装置であって、
   前記他の通信装置が前記第２のハンドシェイク処理を実行可能なことを通知する第１の情報を前記他の通信装置から受信する場合、
   前記第１の認証処理部は、前記第１の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定する、通信装置。
5. 請求項４記載の通信装置であって、
   前記他の通信装置の処理能力を通知する第２の情報を前記他の通信装置から受信する場合、
   前記第１の認証処理部は、前記第１の情報と前記第２の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定する、通信装置。
6. 第１の通信装置と第２の通信装置との間で第１の鍵を用いて通信を行う通信システムであって、
   前記第１の通信装置は、
   前記第２の鍵を用いて暗号処理を行う第１の鍵暗号化部と、
   前記第１の鍵を前記第２の通信装置との間で交換するための第２の鍵の復号処理を行う第１の鍵復号化部と、を有し、
   前記第２の通信装置は、
   前記第２の鍵を用いて暗号処理を行う第２の鍵暗号化部と、
   前記第１の鍵を前記第１の通信装置との間で交換するための第２の鍵の復号処理を行う第２の鍵復号化部と、を有し、
   前記第１の鍵復号部による前記第２の鍵の復号処理を除く第１のハンドシェイク処理が前記第１の通信装置と前記第２の通信装置との間で行われた場合、
   前記第１の通信装置と前記第２の通信装置とは第２のハンドシェイク処理を行い、
   前記第２のハンドシェイク処理において、
   前記第１の通信装置は、前記第１の鍵暗号化部に前記第２の鍵を用いて前記第１の鍵の情報を暗号化させ、前記第２の鍵で暗号化された前記第１の鍵の情報を前記第２の通信装置に送信し、
   前記第２の通信装置の前記第２の鍵復号化部は前記第２の鍵で暗号化された前記第１の鍵の情報の復号処理を行う、通信システム。
7. 請求項６記載の通信システムであって、
   前記第１の通信装置と前記第２の通信装置とはダミーデータを用いて前記第１のハンドシェイク処理を行う、通信システム。
8. 請求項６記載の通信システムであって、
   前記第１のハンドシェイクが終了した場合、
   前記第２の通信装置は、前記第１の通信装置に第２のハンドシェイクを要求する信号を送信する、通信システム。
9. 請求項６記載の通信システムであって、
   前記第１のハンドシェイク処理において、
   第２の通信装置は、前記第２のハンドシェイク処理を実行可能なことを通知する第１の情報を前記第１の通信装置に送信し、
   前記第１の情報を受信した前記第１の通信装置は、前記第２のハンドシェイク処理を行うことを前記第２の通信装置に通知する、通信システム。
10. 請求項９記載の通信システムであって、
    前記第２の通信装置は、前記第１の情報と共に、使用可能な暗号方式を前記第１の通信装置に送信し、
    前記第１の通信装置が前記第２のハンドシェイク処理を行わないと決定した場合、
    前記第１の通信装置は、前記使用可能な暗号方式の中から前記第１のハンドシェイク処理で使用する暗号方式を選択して前記第２の通信装置に通知する、通信システム。
11. 請求項９記載の通信システムであって、
    前記第１の通信装置は、
    演算処理を行う演算部と、
    前記演算部の使用状況を検知する使用状況検知部と、をさらに有し、
    前記使用状況の情報と前記第１の情報とに基づいて、前記第２のハンドシェイク処理を行うかどうかを決定する、通信システム。
12. 請求項１１記載の通信システムであって、
    前記第２の通信装置は、
    演算処理を行う演算部をさらに有し、
    前記演算部の処理能力を通知する第２の情報を前記第１の通信装置に送信し、
    前記第１の通信装置は、
    前記第１の情報と前記第２の情報と前記使用状況とに基づいて前記第２のハンドシェイク処理を行うかどうかを決定する、通信システム。