"他の通信装置と第1の鍵を用いて通信を行う通信装置であって、前記他の通信装置との間でハンドシェイク処理を行う認証処理部を備え、前記認証処理部は、前記第1の鍵を前記他の通信装置との間で交換するための第2の鍵の復号処理を行う鍵復号化部と、を有し、前記第2の鍵を用いて暗号処理を行う鍵暗号化部と、前記鍵復号化部による前記復号処理を除く第1のハンドシェイク処理を行い、前記第1のハンドシェイク処理が終了した場合、前記鍵復号化部による前記復号処理を除く第2のハンドシェイク処理を行い、前記第2のハンドシェイク処理において、前記鍵暗号化部に前記第2の鍵を用いて前記第1の鍵の情報を暗号化させ、前記第2の鍵で暗号化された前記第1の鍵の情報を前記他の通信装置に送信する、通信装置。請求項1記載の通信装置であって、前記認証処理部は、ダミーデータを用いて前記他の通信装置と第1のハンドシェイク処理を行う、通信装置。請求項1記載の通信装置であって、演算処理を行う演算部と、前記演算部の使用状況を検知し、前記使用状況の情報を前記認証処理部に通知する使用状況検知部と、をさらに有し、前記認証処理部は、前記使用状況に基づいて前記第1のハンドシェイク処理で前記鍵復号化部による前記復号処理を除くかどうかを決定する、通信装置。請求項3記載の通信装置であって、前記他の通信装置が前記第2のハンドシェイク処理を実行可能なことを通知する第1の情報を前記他の通信装置から受信する場合、前記第1の認証処理部は、前記第1の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定する、通信装置。請求項4記載の通信装置であって、前記他の通信装置の処理能力を通知する第2の情報を前記他の通信装置から受信する場合、前記第1の認証処理部は、前記第1の情報と前記第2の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定する、通信装置。第1の通信装置と第2の通信装置との間で第1の鍵を用いて通信を行う通信システムであって、前記第1の通信装置は、前記第2の鍵を用いて暗号処理を行う第1の鍵暗号化部と、前記第1の鍵を前記第2の通信装置との間で交換するための第2の鍵の復号処理を行う第1の鍵復号化部と、を有し、前記第2の通信装置は、前記第2の鍵を用いて暗号処理を行う第2の鍵暗号化部と、前記第1の鍵を前記第1の通信装置との間で交換するための第2の鍵の復号処理を行う第2の鍵復号化部と、を有し、前記第1の鍵復号部による前記第2の鍵の復号処理を除く第1のハンドシェイク処理が前記第1の通信装置と前記第2の通信装置との間で行われた場合、前記第1の通信装置と前記第2の通信装置とは第2のハンドシェイク処理を行い、前記第2のハンドシェイク処理において、前記第1の通信装置は、前記第1の鍵暗号化部に前記第2の鍵を用いて前記第1の鍵の情報を暗号化させ、前記第2の鍵で暗号化された前記第1の鍵の情報を前記第2の通信装置に送信し、前記第2の通信装置の前記第2の鍵復号化部は前記第2の鍵で暗号化された前記第1の鍵の情報の復号処理を行う、通信システム。請求項6記載の通信システムであって、前記第1の通信装置と前記第2の通信装置とはダミーデータを用いて前記第1のハンドシェイク処理を行う、通信システム。請求項6記載の通信システムであって、前記第1のハンドシェイクが終了した場合、前記第2の通信装置は、前記第1の通信装置に第2のハンドシェイクを要求する信号を送信する、通信システム。請求項6記載の通信システムであって、前記第1のハンドシェイク処理において、第2の通信装置は、前記第2のハンドシェイク処理を実行可能なことを通知する第1の情報を前記第1の通信装置に送信し、前記第1の情報を受信した前記第1の通信装置は、前記第2のハンドシェイク処理を行うことを前記第2の通信装置に通知する、通信システム。請求項9記載の通信システムであって、前記第2の通信装置は、前記第1の情報と共に、使用可能な暗号方式を前記第1の通信装置に送信し、前記第1の通信装置が前記第2のハンドシェイク処理を行わないと決定した場合、前記第1の通信装置は、前記使用可能な暗号方式の中から前記第1のハンドシェイク処理で使用する暗号方式を選択して前記第2の通信装置に通知する、通信システム。請求項9記載の通信システムであって、前記第1の通信装置は、演算処理を行う演算部と、前記演算部の使用状況を検知する使用状況検知部と、をさらに有し、前記使用状況の情報と前記第1の情報とに基づいて、前記第2のハンドシェイク処理を行うかどうかを決定する、通信システム。請求項11記載の通信システムであって、前記第2の通信装置は、演算処理を行う演算部をさらに有し、前記演算部の処理能力を通知する第2の情報を前記第1の通信装置に送信し、前記第1の通信装置は、前記第1の情報と前記第2の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定する、通信システム。しかしながら、暗号鍵復号鍵を含むの鍵長を大きくすると、計算処理回数が大幅に増加し、処理時間も大幅に伸びる。特に、秘密鍵による公開鍵暗号を行っているサーバの負荷は無視できないほどに大きなものになる。事実、暗号の2010年問題対応のため、現在主流の公開鍵暗号である1024ビットRSA暗号は、2048ビットRSARivestShamirAdleman暗号に移行するが、サーバの負荷は6~8倍に増加する。そのため、多数のクライントを相手にするサーバでは、CPUの能力向上対応等で、大幅なコストアップとなる。しかも公開サーバの場合には、秘密鍵による公開鍵暗号復号処理を強要するDOSDenialofService攻撃が想定されるため、この影響は甚大である。なお、1つのクライアントしか相手にしないサーバであっても問題となるケースは少なくない。相手が1つのクライアントだったとしても、多くのSSL/TLS暗号通信が利用されれば同じ課題に直面する。実際、単純なWebアクセスであっても問題になることがある。Webアクセス等ではGETの度にSSL/TLS暗号通信の開始切断が行われることが多く、1ページの中にGETされる多くの部品が存在するWebページでは、非常に多くのSSL/TLS暗号通信が実行される。仮に、このサーバのCPU能力を向上させなければ、頻繁に通信タイムアウトが発生する恐れがある。本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、SSL/TLS暗号通信を実行するクライアントとサーバで、暗号復号処理の負荷分散を図ことにある。これにより、システム全体での処理速度を向上させ、かつSSL/TLS暗号通信の搭載実現費用をより安価なものにする。上述の課題を解決するために、本発明の通信装置は、他の通信装置と第1の鍵を用いて通信を行う通信装置であって、前記他の通信装置との間でハンドシェイク処理を行う認証処理部を備え、前記認証処理部は、前記第1の鍵を前記他の通信装置との間で交換するための第2の鍵の復号処理を行う鍵復号化部と、前記第2の鍵を用いて暗号処理を行う鍵暗号化部と、を有し、前記鍵復号化部による前記復号処理を除く第1のハンドシェイク処理を行い、前記第1のハンドシェイク処理が終了した場合、前記鍵復号化部による前記復号処理を除く第2のハンドシェイク処理を行い、前記第2のハンドシェイク処理において、前記鍵暗号化部に前記第2の鍵を用いて前記第1の鍵の情報を暗号化させ、前記第2の鍵で暗号化された前記第1の鍵の情報を前記他の通信装置に送信するように構成した。この通信装置によれば、ファイヤーウォールのチェックにかからずに、鍵復号化部が行う第2の鍵の復号処理を他の通信装置に行わせることができる。すなわち、通信装置の負荷を他の通信装置に分散させることができる。また、本発明の通信装置は、前記認証処理部は、ダミーデータを用いて前記他の通信装置と第1のハンドシェイク処理を行うように構成した。この通信装置によれば、通信装置と他の通信装置は第1のハンドシェイク処理では第2の鍵による復号を行わないので、ダミーデータを用いることで不要な処理を省略することができる。また、本発明の通信装置は、演算処理を行う演算部と、前記演算部の使用状況を検知し、前記使用状況の情報を前記認証処理部に通知する使用状況検知部と、をさらに有し、前記認証処理部は、前記使用状況に基づいて前記第1のハンドシェイク処理で前記鍵復号化部による前記復号処理を除くかどうかを決定するように構成した。この通信装置によれば、演算部の使用状況に基づいて第2の鍵の復号処理を省略するかどうか判断することができる。すなわち、状況に応じて第2ハンドシェイク処理の必要性を判断することができる。また、本発明の通信装置は、前記他の通信装置が前記第2のハンドシェイク処理を実行可能なことを通知する第1の情報を前記他の通信装置から受信する場合、前記第1の認証処理部は、前記第1の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定するように構成した。この通信装置によれば、状況に応じて第2のハンドシェイク処理の必要性を判断することができる。また、本発明の通信装置は、前記他の通信装置の処理能力を通知する第2の情報を前記他の通信装置から受信する場合、前記第1の認証処理部は、前記第1の情報と前記第2の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定するように構成した。この通信装置によれば、他の通信装置の処理能力に応じて第2のハンドシェイクの必要性を判断することができる。また、本発明の通信システムは、第1の通信装置と第2の通信装置との間で第1の鍵を用いて通信を行う通信システムであって、前記第1の通信装置は、前記第2の鍵を用いて暗号処理を行う第1の鍵暗号化部と、前記第1の鍵を前記第2の通信装置との間で交換するための第2の鍵の復号処理を行う第1の鍵復号化部と、を有し、前記第2の通信装置は、前記第2の鍵を用いて暗号処理を行う第2の鍵暗号化部と、前記第1の鍵を前記第1の通信装置との間で交換するための第2の鍵の復号処理を行う第2の鍵復号化部と、を有し、前記第1の鍵復号部による前記第2の鍵の復号処理を除く第1のハンドシェイク処理が前記第1の通信装置と前記第2の通信装置との間で行われた場合、前記第1の通信装置と前記第2の通信装置とは第2のハンドシェイク処理を行い、前記第2のハンドシェイク処理において、前記第1の通信装置は、前記第1の鍵暗号化部に前記第2の鍵を用いて前記第1の鍵の情報を暗号化させ、前記第2の鍵で暗号化された前記第1の鍵の情報を前記第2の通信装置に送信し、前記第2の通信装置の前記第2の鍵復号化部は前記第2の鍵で暗号化された前記第1の鍵の情報の復号処理を行うように構成した。この通信システムによれば、ファイヤーウォールのチェックにかからずに、通常第1の鍵復号化部が行う第2の鍵の復号処理を第2の通信装置に行わせることができる。すなわち、第1の通信装置の負荷を第2の通信装置に分散させることができる。また、本発明の通信システムは、前記第1の通信装置と前記第2の通信装置とはダミーデータを用いて前記第1のハンドシェイク処理を行うように構成した。この通信システムによれば、第1の通信装置と第2の通信装置とは第1のハンドシェイク処理では第2の鍵による復号を行わないので、ダミーデータを用いることで不要な処理を省略することができる。また、本発明の通信システムは、前記第1のハンドシェイクが終了した場合、前記第2の通信装置は、前記第1の通信装置に第2のハンドシェイクを要求する信号を送信するように構成した。これ通信システムによれば、第1の通信装置は、第2の通信装置からの信号をきっかけに第2のハンドシェイクを行うことができる。また、本発明の通信システムは、前記第1のハンドシェイク処理において、第2の通信装置は、前記第2のハンドシェイク処理を実行可能なことを通知する第1の情報を前記第1の通信装置に送信し、前記第1の情報を受信した前記第1の通信装置は、前記第2のハンドシェイク処理を行うことを前記第2の通信装置に通知するように構成した。この通信システムによれば、第1のハンドシェイク処理を行う段階で、第1の通信装置と第2の通信装置とは、第2のハンドシェイク処理を行うことをお互いに認識することができる。これにより、第1の通信装置と第2の通信装置とは第1のハンドシェイク処理において不要な処理を省略することができる。また、本発明の通信システムは、前記第2の通信装置は、前記第1の情報と共に、使用可能な暗号方式を前記第1の通信装置に送信し、前記第1の通信装置が前記第2のハンドシェイク処理を行わないと決定した場合、前記第1の通信装置は、前記使用可能な暗号方式の中から前記第1のハンドシェイク処理で使用する暗号方式を選択して前記第2の通信装置に通知する、ように構成した。この通信システムによれば、第1の通信装置は第2の通信装置に第1のハンドシェイク処理で使用する暗号方式を通知することで、第2のハンドシェイクを行わないことを通知することができる。また、本発明の通信システムは、前記第1の通信装置は、演算処理を行う演算部と、前記演算部の使用状況を検知する使用状況検知部と、をさらに有し、前記使用状況の情報と前記第1の情報とに基づいて、前記第2のハンドシェイク処理を行うかどうかを決定するように構成した。この通信システムによれば、演算部の使用状況に応じて第2のハンドシェイク処理の必要性を判断することができる。また、本発明の通信システムは、前記第2の通信装置は、演算処理を行う演算部をさらに有し、前記演算部の処理能力を通知する第2の情報を前記第1の通信装置に送信し、前記第1の通信装置は、前記第1の情報と前記第2の情報と前記使用状況とに基づいて前記第2のハンドシェイク処理を行うかどうかを決定するように構成した。この通信システムによれば、第1の通信装置は第2の通信装置の処理能力に応じて第2のハンドシェイク処理の必要性を判断することができる。本発明の暗号通信方法は、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを実行した後に、その通信を切断せずに、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとしてSSL/TLSネゴシエーションSSL/TLSハンドシェイクを行う暗号通信方法であって、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいては、公開鍵暗号における秘密鍵による復号を実行せず、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいては、公開鍵暗号における秘密鍵による復号を実行し、クライアントサーバ間で、第3者には秘密裏に共通鍵暗号における共通鍵を生成するものとした。これによると、サーバは、処理負荷の高い、公開鍵暗号における秘密鍵による復号処理をクライントに実施させることが可能となり、システム全体の処理速度を向上させ、かつサーバ費用を低減できるようになる。なお最近は、SSL/TLS暗号通信のサーバ機能、及び、クライント機能の両方を搭載しているクライント装置が多いため、多くのシステムで本発明を活用することができる。また、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして、SSL/TLSネゴシエーションSSL/TLSハンドシェイクを先に実行するので、NATやファイヤーウォールに通信を妨害されることもない。また、本発明の暗号通信方法は、クライアントをSSL/TLS暗号通信におけるクライントとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて、クライアントがSSL/TLS暗号通信におけるサーバとして動作可能であることを、クライントがサーバに対して通知する、若しくは、クライアントをSSL/TLS暗号通信におけるサーバとして動作させることを、クライントがサーバに対して要求するものとした。これによると、サーバは、動的に、クライアントがSSL/TLS暗号通信におけるサーバ機能を保有するか否かを知ることができる。つまり、サーバが、サーバ機能を保有しないクライントを含む多数のクライアントと通信する場合に、サーバ機能を保有するクライアントを容易に識別できる。また、本発明の暗号通信方法は、暗号スイートの提示で、クライアントがSSL/TLS暗号通信におけるサーバとして動作可能なことを、クライントがサーバに対して通知する、若しくは、クライアントがSSL/TLS暗号通信におけるサーバとして動作させることを、クライントがサーバに対して要求するものとした。これによると、サーバは、動的に、クライアントがSSL/TLS暗号通信におけるサーバ機能を保有するか否かを確実に知ることができる。なお、ClientHelloのRandombytesやセッションIDに、特別な値を設定し、これをクライントがサーバ機能を保有する合図として利用してもよいが、サーバ機能を保有しないクライアントが偶然、その値を設定した場合に問題になる。また、本発明の暗号通信方法は、クライアントは、クライアントの処理状況を検知するクライアント状況検知手段を有し、このクライアント状況検知手段によって得られた処理状況に応じて、クライアントをSSL/TLS暗号通信におけるサーバとするSSL/TLSネゴシエーションSSL/TLSハンドシェイクの実行が動作可能であることを、サーバに対して通知する、若しくは、クライアントをSSL/TLS暗号通信におけるサーバとして動作させることを、サーバに対して要求するか否かを判断するものとした。これによると、クライアントに、公開鍵における秘密鍵による復号処理を実行する余裕がある場合のみ、クライアントをSSL/TLS暗号通信におけるサーバとすることができるので、クライアントが復号処理で破綻することを防ぐことができる。また、本発明の暗号通信方法は、サーバをSSL/TLS暗号通信におけるサーバとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて、クライアントがSSL/TLS暗号通信におけるサーバとして動作するように、サーバがクライアントに対してリクエスト、若しくは要求するものとした。これによると、サーバは、処理負荷の高い、公開鍵暗号における秘密鍵による復号処理をクライントに動的に実施させることが可能となる。例えば、接続してきたクライアントの処理能力が優れていると判別できる場合には、サーバはクライアントに対して、公開鍵暗号における秘密鍵による復号処理を任せるような運用が可能となる。また、本発明の暗号通信方法は、暗号スイートの提示で、クライアントがSSL/TLS暗号通信におけるサーバとして動作するように、サーバがクライアントに対してリクエスト、若しくは要求するものとした。これによると、クライアントは、動的に、クライアントがSSL/TLS暗号通信におけるサーバとして動作するようにリクエスト、若しくは要求されたか否かを確実に知ることができる。なお、ServerHelloのRandombytesやセッションIDに、特別な値を設定し、これをクライアントがSSL/TLS暗号通信におけるサーバとして動作するリクエスト、若しくは要求として利用してもよいが、クライアントが普通のサーバに接続し、サーバが偶然、その値を設定した場合に問題になる。また、本発明の暗号通信方法は、サーバはサーバの処理状況を検知するサーバ状況検知手段を有し、このサーバ状況検知手段によって得られた処理状況に応じて、サーバをSSL/TLS暗号通信におけるクライントとするSSL/TLSネゴシエーションSSL/TLSハンドシェイクの実行を、クライアントに対して、リクエスト、若しくは要求するか否かを判断するものとした。これによると、サーバに、公開鍵における秘密鍵による復号処理を実行する余裕がなくなってきた場合のみ、クライアントをSSL/TLS暗号通信におけるサーバとすることができるので、サーバが復号処理で破綻することを防ぐことができると共に、クライアントの負荷を少なくすることができる。また、本発明の暗号通信方法は、サーバはクライントの処理能力を検知する処理能力検知手段を有し、この処理能力検知手段によってクライントの処理能力を把握し、サーバをSSL/TLS暗号通信におけるクライントとするSSL/TLSネゴシエーションSSL/TLSハンドシェイクの実行を、一定の処理能力を有するクライアントに対して、リクエスト、若しくは要求するか否かを判断するものとした。これによると、通常は処理能力の低いクライアントには負担をかけず、サーバの処理能力が危険なレベルまで低下した場合のみ、緊急的に、処理能力の低いクライアントに復号処理を依頼することができるようになる。また、本発明の暗号通信方法は、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて、Finishedを除く各handshakeやchange_cipher_specのデータ部に対して、ダミーデータのMACを付与するものとした。これによると、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとしてSSL/TLSネゴシエーションSSL/TLSハンドシェイクを、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして行う、SSL/TLS暗号通信における共通鍵暗号に見せかけることが可能となる。こうすれば、ファイヤーウォールに通信を妨害されることが少なくなる。また、本発明の暗号通信方法は、固定値、若しくは事前に決められた方法、若しくは、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて交換したデータや、それを元にして作成したデータによって、クライアントとサーバで共通鍵を作成し、この共通鍵を用いて、Finishedを除く各handshakeやchange_cipher_specのデータ部を暗号化するものとした。これによると、ファイヤーウォールに通信を妨害されることが更に少なくなる。また、本発明の暗号通信方法は、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて、各handshakeやchange_cipher_specのデータ部に対して、ダミーデータのMACと、application_dataヘッダを付与するものとした。これによると、クライアントをSSL/TLS暗号通信におけるサーバ、サーバをSSL/TLS暗号通信におけるクライントとしてSSL/TLSネゴシエーションSSL/TLSハンドシェイクを、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして行う、SSL/TLS暗号通信におけるデータ通信に見せかけることが可能となる。こうすれば、ファイヤーウォールに通信を妨害されることが少なくなる。また、本発明の暗号通信方法は、固定値、若しくは事前に決められて方法、若しくは、クライアントをSSL/TLS暗号通信におけるクライント、サーバをSSL/TLS暗号通信におけるサーバとして行うSSL/TLSネゴシエーションSSL/TLSハンドシェイクにおいて交換したデータや、それを元にして作成したデータによって、クライアントとサーバで共通鍵を作成し、この共通鍵を用いて、各handshakeやchange_cipher_specのデータ部を暗号化するものとした。これによると、ファイヤーウォールに通信を妨害されることが更に少なくなる。本発明によれば、第2の鍵の復号処理を分散することができる。まず、本発明の実施の形態の概要について説明する。本実施の形態では、通信装置または他の通信装置であるサーバと他の通信装置または通信装置であるクライアントとの間における鍵交換を行うハンドシェイクについて説明する。ハンドシェイク終了後にサーバとクライアントとで暗号通信をするための共通鍵を交換するために、サーバとクライアントとはハンドシェイクの際に共通鍵を共有する。本実施の形態では、具体例として、SSL/TLSネゴシエーションSSLハンドシェイクを用いる。SSL/TLSネゴシエーションでは、共通鍵を共有するために公開鍵暗号を利用する。具体的には、クライアントは、共通鍵第1の鍵を生成し、サーバがクライアントに送付した公開鍵第2の鍵を用いて共通鍵を暗号化し、この暗号化された共通鍵をサーバに送付する。そして、サーバは秘密鍵を用いて公開鍵で暗号化された共通鍵の復号処理を行う。しかしながら、上述した秘密鍵による復号処理は負荷の重い処理であり、サーバには負担がかかる。例えば、複数のクライアントが同時にSSL/TLSネゴシエーションを要求する場合等のサーバの負担は大きい。また、サーバよりもクライアントの方が処理能力が高い場合等は、クライアントで秘密鍵による復号処理を行うことが好ましい。しかし、SSL/TLSネゴシエーションのプロトコルにおいて、サーバが秘密鍵による復号処理を行うこととなっているため、このプロトコルに反してクライアントが秘密鍵による復号処理を行ってしまうと、ファーヤーウォールのチェックにかかり、ハンドシェイクが行うことができない。そこで、本実施の形態では、まずサーバがSSL/TLSネゴシエーションのサーバとして形式的な第1のハンドシェイクを行いすなわち、サーバは秘密鍵による復号処理を行わず、第1のハンドシェイクでは共通鍵の交換は行われない、次にサーバがSSL/TLSネゴシエーションのクライアントとして実質的な第2のハンドシェイクを行うすなわち、第2のハンドシェイクで共通鍵の交換は行われる。換言すると、第1のハンドシェイクにおいて、クライアントはSSL/TLSネゴシエーションのクライアントとして動作するが、第1のハンドシェイクにおいて、クライアントはSSL/TLSネゴシエーションのサーバとして動作し、秘密鍵による復号処理を行う。以上のようにSSL/TLSネゴシエーションを行うことで、サーバの負荷を分散することができる。以下、本発明の実施の形態を、図面を参照しながら説明する。図1は、本発明によるSSL/TLS暗号通信の一例を示すシーケンス図である。なお説明を簡単にするために、ここで用いる公開鍵暗号はRSA暗号として説明を行う。図1において、第1のハンドシェイク処理はS1~S8に相当し、第2のハンドシェイク処理はS9~S18に相当する。第1のハンドシェイク処理では公開鍵で暗号された信号を秘密鍵による復号処理は行われず、前述の復号処理は第2のハンドシェイクで行われる。図1-S1クライアントがClientHelloを生成し、サーバに対して、このClientHelloを送信する。クライアントは、このClientHelloで、クライアントがリバースのSSL/TLSネゴシエーションが可能であることをサーバに知らせる。ここでリバースSSLとは、通常のSSL/TLSネゴシエーションのプロトコルと反対の手順反対の立場で行うことを意味する。また、上述した第2のハンドシェイクを行うことも意味すると共に、サーバ2が秘密鍵による復号処理を第1のハンドシェイクで行わないことも意味する。すなわち、サーバは通常のSSL/TLSネゴシエーションのクライアントとして動作し、クライアントは通常のSSL/TLSネゴシエーションのサーバとして動作する。なおクライアントが、リバースのSSL/TLSネゴシエーション利用が可能であることを、サーバに対して知らせる方法は様々であり、1つの方法に限定されるものではない。例えば、ClientHelloの拡張データextradataに特殊なコマンドを設定することで、それを知らせることもできれば、ClientHelloのRandomBytesに特殊な値を設定することで、リバースのSSL/TLSネゴシエーションが可能であることを知らせることもできる。同様に、サーバがクライアントに対して行う、リバースのSSL/TLSネゴシエーションの利用要求方法も様々であり、1つの方法に限定されるものではない。例えば、ServerHelloの拡張データextradataに特殊なコマンドを設定することで、それを要求することもできれば、ServerHelloのRandomBytesに特殊な値を設定することで、それを要求することもできる。なお、クライアントがリバースのSSL/TLSネゴシエーションが可能であることを知らせなくても、サーバはクライアントに対して、リバースのSSL/TLSネゴシエーションの利用を強制的に要求してもよい。なお、常にリバースのSSL/TLSネゴシエーションを行うのであれば、クライアントが、リバースのSSL/TLSネゴシエーション利用が可能であることを知らせることも、サーバが、リバースのSSL/TLSネゴシエーションの利用を要求することも不要である。しかし上述ように、クライアントが、リバースのSSL/TLSネゴシエーション利用が可能であることを知らせ、サーバが、リバースのSSL/TLSネゴシエーションの利用を要求するようにすれば、サーバは、通常のSSL/TLSネゴシエーション、及び、リバースのSSL/TLSネゴシエーションの両方を利用できる上、容易に切り替えられるため好ましい。本実施の形態では、最初のバイトが0xFFである、つまりプライベートな暗号スイートをClientHelloに設定することで、クライアントがサーバに対して、リバースのSSL/TLSネゴシエーションが可能であることを知らせるものとする。このように、暗号スイートの提示で、リバースのSSL/TLSネゴシエーションが可能であることを知らせる方法は、上述の方法に比べ、確実に伝達されるのでよい。なお、このプライベートな暗号スイートは、どのように設定してもよい。本実施の形態では以下の暗号スイートによって、クライアントがリバースのSSL/TLSネゴシエーションが可能であることを知らせるものとする。TLS_NULL_WITH_NULL_NULL={0xFF,0x00}なおこれは、{0x00,0x00}とは異なる暗号スイートである。プライベートな暗号スイートの代りに、{0x00,0x00}の暗号スイートで、クライアントがサーバに対して、リバースのSSL/TLSネゴシエーションが可能であることを知らせることも可能であるが、SSL/TLS暗号通信の仕様から外れるので好ましくない。ここでClientHelloには、このプライベートな暗号スイートのみを設定するとしてもよい。しかし、サーバがリバースのSSL/TLSネゴシエーションを実行できない場合や、サーバがリバースのSSL/TLSネゴシエーションを実行するか否かを動的に判断する場合もある。このため、このClientHelloには、このプライベートな暗号スイートだけでなく、このクライアントで使用可能な他の暗号スイートも合わせて指定するのが好ましい。こうすれば、サーバの判断によって、通常のSSL/TLSネゴシエーションも実行できるようになる。本実施の形態では図1に示すように、複数の暗号スイートを指定したものとし、例えば以下の暗号スイート等である。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_AES_128_CBC_SHATLS_NULL_WITH_NULL_NULL=0xFF,0x00図1-S2サーバはこのClientHelloを受信し、処理する。なお、サーバはプライベートな暗号スイートが指定されているのを見て、クライアントがリバースのSSL/TLSネゴシエーションが可能であること知る。図1-S3サーバはServerHello/ServerCertificate/ServerHelloDoneを生成し、クライアントに対して、このServerHello/ServerCertificate/ServerHelloDoneを送信する。ここでServerHelloの暗号スイートとしては、上述のプライベートな暗号スイートを指定する。これによって、サーバはクライアントに対して、リバースのSSL/TLSネゴシエーションを実行することを要求する。なおサーバは、現在のCPU使用率が大きくなければ、通常のSSL/TLSネゴシエーションを選択し、実行してもよい。この場合、サーバはプライベートな暗号スイート以外の暗号スイートを選択する。CPUは演算処理を行う演算部に相当する。ここではサーバのCPU使用率が大きく、サーバは図1のように、プライベートな暗号スイートを指定したものとする。図1-S4クライアントはこのServerHello/ServerCertificate/ServerHelloDoneを受信し、処理する。なお、クライアントはプライベートな暗号スイートが指定されたのを見て、リバースのSSL/TLSネゴシエーションを実行することを理解する。仮にプライベートな暗号スイートが指定されていなければ、この後、クライアントは通常のSSL/TLSネゴシエーションを実行する。図1-S5クライアントはClientKeyExchange/ChangeCipherSpec/Finishedを生成する。なお、ClientKeyExchangeとFinishedのデータ部MACを含むは、サーバ証明書に記述されている公開鍵を用いて、正しく計算し設定しても構わないが、公開鍵暗号の処理を省けばパフォーマンスが向上するので、ダミーデータとするのがよい。このダミーデータは、乱数、決められた固定値のどちらでも構わない。次にクライアントはサーバに対して、このClientKeyExchange/ChangeCipherSpec/Finishedを送信する。図1-S6サーバはClientKeyExchange/ChangeCipherSpec/Finishedを受信する。なお、サーバはClientKeyExchange/Finishedのデータ部は処理しない。つまり、秘密鍵による公開鍵暗号の処理は行わない。また、ChangeCipherSpecも処理しなくてよい。図1-S7サーバはChangeCipherSpec/Finishedを生成する。なお、Finishedのデータ部MACを含むは、ダミーデータを設定する。このダミーデータは、乱数、決められた固定値のどちらでも構わない。次にサーバは、クライアントに対して、このChangeCipherSpec/Finishedを送信する。図1-S8クライアントはChangeCipherSpec/Finishedを受信する。なお、クライアントはFinishedのデータ部は処理しない。また、ChangeCipherSpecも処理しなくてよい。この一連のSSL/TLSネゴシエーションでは、サーバは秘密鍵による公開鍵暗号の処理を行わないので、CPU負荷は非常に小さい。しかし、このSSL/TLSネゴシエーションはダミーのSSL/TLSネゴシエーションなので、正しい共通鍵の交換はできない。このダミーのSSL/TLSネゴシエーションを行う最大の目的は、クライアントサーバ間でリバースのSSL/TLSネゴシエーションを利用するか否かを決定する等、システムの負荷分散を図る決定を行うことにある。また、このダミーのSSL/TLSネゴシエーションには、ファイヤーウォール等の通信制御機器に対し、通常のSSL/TLSネゴシエーションに見せかけ、これ以降の通信を遮断させない目的もある。ネットワーク上で送受信されるデータは、第3者から見れば、SSL/TLS暗号通信の仕様に従っているように見えるため、通信が遮断されることはない。図1-S9クライアントがClientHelloRequestを生成し、サーバに対して、このClientHelloRequestを送信する。この時点から、クライアントは、SSL/TLSネゴシエーションにおけるサーバの役割を果たすようになる。但し、説明を複雑にしないため、これ以降もクライアントはクライアントと呼称する。図1-S10サーバはClientHelloRequestを受信する。この時点からサーバはSSL/TLSネゴシエーションにおけるクライアントの役割を果たすようになる。但し、説明を複雑にしないため、これ以降もサーバはサーバと呼称する。図1-S11サーバは、ClientHelloRequestを受けて、ClientHelloを生成し、クライアントに対して、このClientHelloを送信する。なお、8以降から11のステップでTCPポートのクローズは行わない。つまり、ダミーのSSL/TLSネゴシエーションと同じソケットを引き続き利用する。また、ダミーのSSL/TLSネゴシエーションでは正しくセッションを確立していないので、正しいマスターシークレットmastersecretは生成されない。そのため、ダミーのSSL/TLSネゴシエーションでサーバが指定したセッションIDは有効になっていない。従って、これ以降のSSL/TLSネゴシエーションは、既存セッションの再開のネゴシエーションではなく、新規セッションを確立するネゴシエーションとなる。サーバが、このClientHelloのセッションIDに、ダミーのSSL/TLSネゴシエーションでサーバが指定したセッションIDを設定することは構わないが、クライアントは既存セッションの再開のネゴシエーションにならないようにしなければならない。同じくクライアントが、ServerHelloでそのセッションIDを指定した場合に、サーバも同様に、既存セッションの再開のネゴシエーションにならないようにしなければならない。ここでは、SSL/TLS暗号通信の仕様に従って、このClientHelloのsession_id_lengthは0とするのが望ましい。また、このClientHelloの応答であるServerHelloで指定するセッションIDは、ダミーのSSL/TLSネゴシエーションでサーバが指定したセッションIDとは別の値にするのが望ましい。なお、ClientHelloRequestの送受信は割愛して、ダミーのSSL/TLSネゴシエーション後、直ちにサーバがClientHelloを生成し、クライアントに対して、このClientHelloを送信するとしてもよい。なお、ダミーのSSL/TLSネゴシエーションからステップ18が終了するまでに、クライアント、若しくはサーバがデータ送信をした場合には、受信側は、このデータを破棄し、通信を遮断するのが、中間者攻撃を防御する上で望ましい。図1-S12クライアントはこのClientHelloを受信し、処理する。図1-S13クライアントはServerHello/ServerCertificate/ServerHelloDoneを生成し、サーバに対して、このServerHello/ServerCertificate/ServerHelloDoneを送信する。図1-S14サーバはこのServerHello/ServerCertificate/ServerHelloDoneを受信し、処理する。図1-S15サーバはClientKeyExchange/ChangeCipherSpec/Finishedを生成し、クライアントに対して、このClientKeyExchange/ChangeCipherSpec/Finishedを送信する。なおサーバは、SSL/TLS暗号通信の仕様の通り、この時点で正しい共通鍵MAC鍵を含むを生成できる。従って、Finishedのデータ部MACを含むは共通鍵で正しく暗号化される。なおここで、サーバは、ClientKeyExchangeを生成するに当たって、公開鍵による公開鍵暗号の処理を行うが、秘密鍵による公開鍵暗号の処理に比べれば、一桁以上、演算処理が少なく、CPUにかかる負荷はとても小さい。図1-S16クライアントはClientKeyExchange/ChangeCipherSpec/Finishedを受信する。ここでクライアントは、ClientKeyExchangeを処理するために、秘密鍵による公開鍵暗号の復号処理を行う。その処理の結果、SSL/TLS暗号通信の仕様の通り、クライアントはこの時点で正しい共通鍵MAC鍵を含むを生成できる。従って、Finishedのデータ部MACを含むは共通鍵で正しく復号化される。図1-S17クライアントはChangeCipherSpec/Finishedを生成し、サーバに対して、このChangeCipherSpec/Finishedを送信する。なお、Finishedのデータ部MACを含むは共通鍵で正しく暗号化される。図1-S18サーバはChangeCipherSpec/Finishedを受信し、処理する。なお、Finishedのデータ部MACを含むは共通鍵で正しく復号化され、処理される。これ以降、クライアントサーバ間では正しくSSL/TLS暗号通信の共通鍵暗号が行われる。なお、SSL/TLS暗号通信の仕様に従えば、S9からS18のステップでやりとりされる各メッセージのデータ部はすべて暗号化しなければならないが、S9からS18のステップでやりとりされる各メッセージのデータ部はFinishedを除けば、実際は暗号化しなくてもよい。次に図6を用いて、図1とは異なる例について説明する。図6は、本発明の実施の形態におけるSSL/TLS暗号通信の第2例を示すシーケンス図である。なお、図6において、第1のハンドシェイク処理はS1~S8に相当し、第2のハンドシェイク処理はS9~S18に相当する。図6に示したように、難読化を目的に、Finishedを除く各メッセージのデータ部にダミーのMACを付与し、共通鍵暗号による暗号化された再接続ネゴシエーションが行われているように見せかけてもよい。更にSSL/TLSネゴシエーションで送受信した乱数や固定値を共通鍵として、データ部ダミーのMACを含むを暗号化スクランブル化しても構わない。このような難読化は、ファイヤーウォールが厳密に各メッセージのデータ部をチェックしている場合に有効な手法となる。なおあえて共通鍵を生成するなら、クライアントが、pre_master_secretを乱数で生成し、このpre_master_secretを非暗号のままEncryptedPreMasterSecretとして扱い、サーバもEncryptedPreMasterSecretをそのままpre_master_secretとして扱い、クライアントとサーバで共通鍵を生成するとするのが好ましい。ここではプライベートな暗号スイートをTLS_NULL_WITH_NULL_NULL={0xFF,0x00}としたが、これを例えば図6のように、TLS_NULL_WITH_AES_128_CBC_NULL={0xFF,0x00}に変え、暗号復号化を行うとすれば、SSL/TLS暗号通信の仕様に最も良く合い、SSL/TLS暗号通信を実現するSSL/TLS暗号モジュールの改変が少なくて済む。なお、ファイヤーウォールが厳密にSSL/TLSの再ネゴシエーションで送受信されるhandshakeのパケット数をカウントしている場合には、ダミーのhandshakeのパケットを送受信し、何度かSSL/TLSネゴシエーションが実行されているように見せかけてもよい。また、S9からS18のステップで送受信されるすべてのメッセージChangeCipherSpecを含むを、図6のように、暗号化されたデータ通信であるように見せかけるのもよい方法である。つまり、S9からS18のステップでやりとりされる各メッセージを、データ通信、つまりapplication_dataのデータ部として送受信する。このようにすれば、ファイヤーウォールが厳密にSSL/TLSの再ネゴシエーションで送受信されるhandshakeのパケット数をカウントしていたとしても、チェックにかからなくなる。しかし、通常、SSL/TLS暗号通信は、アプリケーションプログラムとは分離された、SSL/TLS暗号通信モジュールによって実現されるので、アプリケーションプログラムが利用するデータ通信を使って、SSL/TLS暗号通信モジュールがSSL/TLSネゴシエーションを行うのは良くない。このようなつくりにすると、SSL/TLS暗号通信モジュールは、アプリケーションプログラムが利用するデータ通信の中身を常にチェックしなければならず、パフォーマンスを落としてしまう。但しこのケースでは、ダミーのSSL/TLSネゴシエーション後、直ちに、9から18のSSL/TLSネゴシエーションが行われるので、データ通信を使ってSSL/TLSネゴシエーションを行ったとしても、パフォーマンスを落とすことはない。SSL/TLS暗号通信モジュールがデータ通信の中身をチェックするのは、ダミーのSSL/TLSネゴシエーション開始後から、9から18のSSL/TLSネゴシエーション終了後までで、このSSL/TLSネゴシエーション終了後は、データ通信の中身をチェックすることはない。なお、データ通信でSSL/TLSネゴシエーションを行うのであれば、独自の方法で共通鍵交換を行ってもよいように思われるが、これは危険である。ダミーのSSL/TLSネゴシエーションでは共通鍵の交換は行っていないので、データ通信であっても、9から18のSSL/TLSネゴシエーションは基本的には非暗号スクランブル化していたとしても第3者には中身を解析されるである。従って、ここで行う共通鍵の交換には、各種攻撃に耐性や知見のある暗号通信仕様に従うのがよい。クライアントとサーバがSSL暗号通信に対応していることを考慮すれば、ここで行う共通鍵の交換には、図1のように、SSL/TLSネゴシエーションを利用することが望ましい。なお、このリバースのSSL/TLSネゴシエーション終了後、再接続する場合には、クライアントはSSL/TLSネゴシエーションにおけるクライアントの役割に、サーバはSSL/TLSネゴシエーションにおけるサーバの役割に戻し、通常のSSL/TLS暗号通信の仕様に従うのが、複雑にならずによい。もし新規IDで接続し、かつクライアントで秘密鍵による公開鍵暗号を行いたいときは、ステップS1に戻ればよい。このように、図1のようにダミーのSSL/TLSネゴシエーションを行えば、ファイヤーウォール等の通信を制御する機器がクライアントサーバ間に介在していたとしても、通信が遮断されることはない。また、図1のようにリバースのSSL/TLSネゴシエーションを行えば、サーバは秘密鍵による公開鍵暗号処理を行わなくても済むので、CPU負荷を小さくできる。従って、サーバ費用を低減できる効果がある。サーバが相手にするクライアント台数が増せば増すほど、この効果は大きくなる。このように本発明は、NATトラバーサル技術とは異なるものである。しかもサーバは、通常のSSL/TLSネゴシエーションを行うか、リバースのSSL/TLSネゴシエーションを行うかを判断し実行できるので、サーバは的確な負荷分散を行うことが可能である。サーバの負荷が低い時は、通常のSSL/TLSネゴシエーションを行いこの場合、ダミーのSSL/TLSネゴシエーションが本当のSSL/TLSネゴシエーションとなる、サーバの負荷が高い時は、リバースのSSL/TLSネゴシエーションを行うことで、システム全体の負荷を最適化することが可能である。つまり、システムの費用対効果を最大化できる。従って、ダミーのSSL/TLSネゴシエーションは、NATトラバーサルだけでなく、システムの負荷分散を行う上でもとても重要である。特にインターネット上に公開されるサーバを運用する際にこの効果は非常に高い。一般的に公開サーバに対しては、頻繁なDOS攻撃がかけられる。SSL/TLS暗号通信をサポートする公開サーバの場合、無駄な秘密鍵による公開暗号処理を頻繁に実行されると、それに支払うコストは莫大なものになる。しかしリバースのSSL/TLSネゴシエーションをサポートするクライアントのみを公開サーバへの接続対象とするような工夫を行えば、コストをかけずにCPU使用率を一定に保て、サービスに支障をきたさなくなる。その上、この一連のSSL/TLSネゴシエーションは、SSL/TLS暗号通信の仕様から外れる部分が少なく、SSL/TLS暗号通信に対する各種攻撃に対する知見を利用でき安全である。また、SSL/TLS暗号通信の仕様から外れる部分が少ないので、SSL/TLS暗号通信を実現するSSL/TLS暗号モジュールのつくりを単純化でき、開発費を削減できる。図2は、図1の機能ブロック図の一例である。また図3は、図2のクライアント1のフローチャートを、図4は図2のサーバ2のフローチャートを示す。次にこの図2、図3、図4を用いて説明を行う。なお、図3において、第1のハンドシェイク処理はS1~S10に相当し、第2のハンドシェイク処理はS11~S26に相当する。図4において、第1のハンドシェイク処理はS1~S11に相当し、第2のハンドシェイク処理はS13~S26に相当する。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信を行う。図3-S1はじめに、SSLネゴシエーションクライアント部400がClientHelloメッセージを生成し、これをデータ送信部200に送る。なお、このClientHelloメッセージで指定した暗号スイートは、以下のようなものだったとして説明を行う。TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_AES_128_CBC_SHATLS_NULL_WITH_NULL_NULL=0xFF,0x00ここで、TLS_NULL_WITH_NULL_NULLは、プライベートな暗号スイートであり、0x00,0x00とは異なる暗号スイートである。このプライベートな暗号スイートは、クライアントがサーバに対して、クライアントがリバースのSSL/TLSネゴシエーションを実行可能なことを知らせるものである。なお、クライアント1の処理能力検知クライアント部図示せずが検知した自らのCPUの処理能力情報CPUの最大処理能力情報をSSLネゴシエーションクライアント部400に通知し、SSLネゴシエーションクライアント部400はこの処理能力情報をClientHelloメッセージに含ませて、サーバに対して知らせるものとする。そのような方法は様々であるが、例えば、RandombytesやセッションIDの一部に、その処理能力のレベル値を設定するとしてもよい。ここでは、Randombytesの一部に、処理能力情報処理能力のレベル値を設定したものとする。なお、最大処理能力の情報は予めフラグメモリ等に格納されておいてもよい。なお、クライアント1は処理使用状況検知クライアント部図示せずをさらに有し、処理使用状況検知クライアント部はCPU使用率情報を検知し、この情報をSSLネゴシエーションクライアント部400に通知する。SSLネゴシエーションクライアント部400はCPU使用率情報に基づいて、公開鍵暗号における秘密鍵による復号処理を行うことが可能かどうかをサーバ2に通知する。例えば、CPU使用率が所定値以上である場合、SSLネゴシエーションクライアント部400はプライベートな暗号スイートを含む暗号スイートリストをサーバ2に通知し、CPU使用率が所定値以下である場合、SSLネゴシエーションクライアント部400はプライベートな暗号スイートを含まずに暗号スイートリストをサーバ2に通知する。これにより、公開鍵暗号における秘密鍵による復号処理によってクライアント1の他の処理が破綻することを抑制することができる。以上より図3-S1では、SSLネゴシエーションクライアント部400は、プライベートな暗号スイートを含む暗号スイートリストの情報とCPUの処理能力情報の情報とを含むCliantHelloを作成する。なお、CliantHelloにクライアントのCPU使用率の情報を含ませてもよい。図3-S2データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信する。図3-S3この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図4-S1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部310は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置110を介して受信する。データ受信部310は、このClientHelloメッセージを、ClientHelloメッセージを解釈するSSLネゴシエーションサーバ部510に送る。図4-S2SSLネゴシエーションサーバ部510は、ClientHelloメッセージを処理する。図4-S3この際SSLネゴシエーションサーバ部510は、ClientHelloメッセージに、リバースのSSL/TLSネゴシエーションの合図であるTLS_NULL_WITH_NULL_NULLの暗号スイートが指定されているかをチェックする。TLS_NULL_WITH_NULL_NULLが指定されていなければ、リバースのSSL/TLSネゴシエーションは実行できないので、通常のSSL/TLSネゴシエーションを行う。すなわち、プライベートな暗号スイート以外の暗号スイートを選択する。なおサーバが、リバースのSSL/TLSネゴシエーション可能なクライントしか相手にしない場合には、リバースのSSL/TLSネゴシエーションができないアクセスはDOS攻撃なので、ここで処理を中断するのが望ましい。これにより、安全性を高めることができる。ここでは、図3-S1で説明したように、TLS_NULL_WITH_NULL_NULLの暗号スイートが指定されているので、SSLネゴシエーションサーバ部510は、クライアントがリバースのSSL/TLSネゴシエーションが可能であると判断する。図4-S4サーバ2は処理使用状況検知サーバ部図示せずをさらに有し、処置使用状況検知サーバ部はCPU使用率情報を検知し、この情報をSSLネゴシエーションサーバ部510に通知し、SSLネゴシエーションサーバ部510はサーバ2のCPU使用率情報をチェックする。サーバ2のCPU使用率が小さければ例えば、所定値閾値よりも低ければ、サーバ2で秘密鍵による公開鍵暗号処理を実行しても、サーバ2に支障が出ないので、通常のSSL/TLSネゴシエーションを行う。なおこの判断はせずに、常にリバースのSSL/TLSネゴシエーションを行うとすることも可能である。なお図4-S4で、SSLネゴシエーションサーバ部510は、受信したCliantHelloに含まれるクライアント1のSSLネゴシエーションサーバ部510は、ClientHelloメッセージのRandombytesの一部に示されているクライアント1の処理能力情報処理能力のレベル値をチェックし、一定のレベル値図2の処理能力の閾値以上である場合のみ、リバースのSSL/TLSネゴシエーションを行うとすれば、システム全体のパフォーマンスを最適にできる。なお、どのレベルでリバースのSSL/TLSネゴシエーションを実行するかはサーバの処理能力に依存する。本実施の形態ではサーバのCPU使用率、及び、クライアントの処理能力が高く、SSLネゴシエーションサーバ部510がリバースのSSL/TLSネゴシエーションを実行すると判断したとして、以下、説明を行う。図4-S5SSLネゴシエーションサーバ部510は、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークを付ける。図4-S6SSLネゴシエーションサーバ部510は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部210に送る。この際、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付いているので、暗号スイートしては、リバースのSSL/TLSネゴシエーションの合図であるTLS_NULL_WITH_NULL_NULLを指定する。なお暗号スイート以外は、ServerHello、及び、ServerCertificateメッセージのデータ部には、正しい値を設定しなくてもよい。乱数や固定値等ダミーデータでも構わない。これにより、サーバ2は不必要な処理を省略できる。なお、SSLネゴシエーションサーバ部510は、これまでのステップに関係なく、リバースのSSL/TLSネゴシエーションを実行するために、無条件に、TLS_NULL_WITH_NULL_NULLを指定することも可能である。図4-S7データ送信部210は、ネットワーク制御装置110を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。なお、サーバ2の処理を簡略化するために、ここで公開鍵をクライアント1に送らなくてもよい。図4-S8その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図3-S3クライアント1のデータ受信部300は、サーバ2が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部300は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理するSSLネゴシエーションクライアント部400に送る。図3-S4SSLネゴシエーションクライアント部400は、ServerHelloで、リバースのSSL/TLSネゴシエーションの合図であるTLS_NULL_WITH_NULL_NULLが指定されているかをチェックする。TLS_NULL_WITH_NULL_NULLが指定されていなければ、通常のSSL/TLSネゴシエーションを実行する。図3-S5TLS_NULL_WITH_NULL_NULLが指定されている場合、SSLネゴシエーションクライアント部400は、リバースのSSL/TLSネゴシエーションを実行するものと判断し、SSLネゴシエーションクライアント部400が、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークを付ける。図3-S6SSLネゴシエーションクライアント部400は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理する。なお、SSLネゴシエーションクライアント部400は、フラグメモリを見て、リバースのSSL/TLSネゴシエーションを実行するマークがあれば、実際は、このメッセージは、何も処理せずに廃棄しても構わない。これにより、クライアント1は不必要な処理を省略できる。図3-S7SSLネゴシエーションクライアント部400は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部200に送る。なお、SSLネゴシエーションクライアント部400は、フラグメモリを見て、リバースのSSL/TLSネゴシエーションを実行するマークがあれば、このClientKeyExchangeメッセージ、及び、Finishedメッセージのデータ部MACを含むには、正しい値を設定しなくてもよい。乱数や固定値等ダミーデータでも構わない。図3-S8データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図3-S9この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図4-S8データ受信部310は、クライアント1が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置110を介して受信する。データ受信部310は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理するSSLネゴシエーションサーバ部510に送る。図4-S9SSLネゴシエーションサーバ部510は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理する。但し、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付いているので、ClientKeyExchangeのEncryptedPreMasterSecretは少なくとも処理しない。つまり秘密鍵による公開鍵暗号処理は実施しない。また、Finishedメッセージのデータチェックも行わない。その他のデータも処理せずに、廃棄してよい。これにより、クライアント1は不必要な処理を省略できる。図4-S10SSLネゴシエーションサーバ部510は、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。但し、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付いているので、Finishedメッセージのデータ部MACを含むには、乱数や固定値等ダミーデータを設定する。なお、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付いているので、SSLネゴシエーションサーバ部510は、公開鍵暗号における秘密鍵による復号処理を行う共通鍵暗号復号部710ではなく、SSLネゴシエーションクライアント部410を呼び出す。そしてSSLネゴシエーションサーバ部510は、これ以降のメッセージの送受信をSSLネゴシエーションクライアント部410に任せる。図4-S11データ送信部210は、ネットワーク制御装置110を介して、クライアント1に対して、ChangeCipherSpec/Finishedメッセージを送信する。図4-S12その後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。なおここでメッセージ受信待ちになるのは、SSLネゴシエーションクライアント部410である。図3-S9クライアント1のデータ受信部300は、サーバ2が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部300は、ChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを処理するSSLネゴシエーションクライアント部400に送る。図3-S10SSLネゴシエーションクライアント部400は、ChangeCipherSpec/Finishedメッセージを処理する。但し、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付いているので、少なくともFinishedメッセージのデータチェックは行わない。その他のデータも処理せずに、廃棄してよい。これにより、クライアント1は不必要な処理を省略できる。以上のように、ここまでのSSL/TLSネゴシエーションは、ダミーのSSL/TLSネゴシエーションとなる。すなわち、ファイヤーウォールに引っかからないために形式的にSSLネゴシエーションの手順プロトコル通りに処理が行われたが、鍵交換等の通常のSSLネゴシエーションで行われる処理は行われていない。なお、ダミーのSSL/TLSネゴシエーション終了後は、次のSSL/TLSネゴシエーションが終了するまでは、サーバ2は、中間者攻撃を防御するためデータ受信をしない。サーバ2はデータ受信した場合には、このデータを破棄し、通信を遮断する。これにより、安全性を高めることができる。次に、SSLネゴシエーションクライアント部400は、フラグメモリに、リバースのSSL/TLSネゴシエーションを実行するマークが付けられているので、共通鍵暗号復号部700、若しくは通信データ生成部800ではなく、SSLネゴシエーションサーバ部500を呼び出す。そして、SSLネゴシエーションクライアント部400はこれ以降のメッセージの送受信をSSLネゴシエーションサーバ部500に任せる。なお、図2では、フラグメモリを利用して、リバースのSSL/TLSネゴシエーションを実行するか否かを示すようにしているが、この実現方法はこれに限られるものではなく、様々な方法が可能である。図3-S11SSLネゴシエーションサーバ部500は、ClientHellorequestメッセージを生成し、これをデータ送信部200に送る。図3-S12データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHellorequestメッセージを送信する。図3-S13この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。なおここでメッセージ受信待ちになるのは、SSLネゴシエーションサーバ部500である。図4-S12データ受信部310は、クライアント1が送信したClientHellorequestメッセージを、ネットワーク制御装置110を介して受信する。データ受信部310は、このClientHellorequestメッセージを、ClientHellorequestメッセージを処理するSSLネゴシエーションクライアント部410に送る。図4-S13SSLネゴシエーションクライアント部410は、ClientHellorequestメッセージを処理する。具体的には、ClientHelloメッセージの生成を開始する。図4-S14SSLネゴシエーションクライアント部410がClientHelloメッセージを生成し、これをデータ送信部210に送る。なお、このClientHelloメッセージでは、TLS_NULL_WITH_NULL_NULLの暗号スイートは指定しないものとする。図4-S15データ送信部210は、ネットワーク制御装置110を介して、クライアント1に対して、このClientHelloメッセージを送信する。図4-S16この後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図3-S13データ受信部300は、サーバ2が送信したClientHelloメッセージを、ネットワーク制御装置100を介して受信する。データ受信部300は、このClientHelloメッセージを、ClientHelloメッセージを処理するSSLネゴシエーションサーバ部500に送る。図3-S14SSLネゴシエーションサーバ部500は、ClientHelloメッセージを処理する。図3-S15SSLネゴシエーションサーバ部500は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを生成し、これをデータ送信部200に送る。なお、暗号スイートしては、リバースのSSL/TLSネゴシエーションの合図であるTLS_NULL_WITH_NULL_NULLを指定しないものとする。なお、ServerCertificateは、クライアント1が保持する公開鍵Nと公開鍵Eの情報を含む。図3-S16データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信する。図3-S17その後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図4-S16サーバ2のデータ受信部310は、クライアント1が送信したServerHello/ServerCertificate/ServerHelloDoneメッセージを、ネットワーク制御装置110を介して受信する。データ受信部310は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理するSSLネゴシエーションクライアント部410に送る。図4-S17SSLネゴシエーションクライアント部410は、ServerHello/ServerCertificate/ServerHelloDoneメッセージを処理する。なお、SSLネゴシエーションクライアント部410はServerCertificateから、クライアント1が保持する公開鍵Nと公開鍵Eの情報を読み出す。図4-S18SSLネゴシエーションクライアント部410は、乱数生成部810にプリマスターシークレットpremastersecretとなる乱数を生成させる。図4-S19共通鍵生成部760は、乱数から共通鍵暗号方式で用いる共通鍵MAC鍵を含むを生成する。図4-S20公開鍵暗号部610は、公開鍵Nと公開鍵Eを用いて乱数を暗号化し、EncryptedPreMasterSecretを生成する。図4-S21SSLネゴシエーションクライアント部410は、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部210に送る。なおこのFinishedメッセージのデータ部MACを含むは共通鍵で暗号化される。図4-S22データ送信部210は、ネットワーク制御装置110を介して、クライアント1に対して、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを送信する。図4-S23この後、サーバ2はクライアント1からのメッセージ受信待ち状態になる。図3-S17データ受信部300は、サーバ2が送信したClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部300は、このClientKeyExchange/ChangeCipherSpec/Finishedメッセージを、ClientKeyExchange/ChangeCipherSpec/Finishedメッセージを処理するSSLネゴシエーションサーバ部500に送る。図3-S18SSLネゴシエーションサーバ部500は、ClientKeyExchangeを処理する。なお、EncryptedPreMasterSecretは公開鍵復号部600に送る。図3-S19公開鍵復号部600は、クライアント1が保持する公開鍵Nと秘密鍵Dを用いて、EncryptedPreMasterSecretを復号化し、乱数を取得する。図3-S20共通鍵生成部750は、乱数から共通鍵暗号方式で用いる共通鍵MAC鍵を含むを生成する。図3-S21SSLネゴシエーションサーバ部500は、ChangeCipherSpec/Finishedメッセージを処理する。なおこのFinishedメッセージのデータ部MACを含むは共通鍵で復号化され処理される。図3-S22SSLネゴシエーションサーバ部500は、ChangeCipherSpec/Finishedメッセージを生成し、これをデータ送信部200に送る。なおこのFinishedメッセージのデータ部MACを含むは共通鍵で暗号化される。図3-S23データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、このChangeCipherSpec/Finishedメッセージを送信する。図3-S24SSLネゴシエーションサーバ部500は、通信データ生成部800を呼び出す。通信データ生成部800は通信データを生成する。図3-S25共通鍵暗号復号部700は、共通鍵を用いて、通信データを暗号化し、暗号データMACを含むを生成する。そして、共通鍵暗号復号部700はこの暗号データMACを含むをデータ送信部200に送る。図3-S26データ送信部200は、ネットワーク制御装置100を介して、サーバ2に対して、この暗号データMACを含むを送信する。図4-S23データ受信部310は、クライアント1が送信したChangeCipherSpec/Finishedメッセージを、ネットワーク制御装置110を介して受信する。データ受信部310は、このChangeCipherSpec/Finishedメッセージを、ChangeCipherSpec/Finishedメッセージを解釈するSSLネゴシエーションクライアント部410に送る。図4-S24SSLネゴシエーションクライアント部410は、ChangeCipherSpec/Finishedメッセージを処理する。なおこのFinishedメッセージのデータ部MACを含むは共通鍵で復号化され処理される。図4-S25この後、サーバ2はクライアント1からのデータ受信待ち状態になる。なおここでデータ受信待ちになるのは、共通鍵暗号復号部710である。図4-S25データ受信部310は、クライアント1が送信した暗号データMACを含むを、ネットワーク制御装置110を介して受信する。データ受信部310は、この暗号データMACを含むを、暗号データMACを含むを処理する共通鍵暗号復号部710に送る。図4-S26共通鍵暗号復号部710は、共通鍵を用いて、暗号データMACを含むを復号化し、通信データを取得する。これ以降、クライアントサーバ間では正しくSSL/TLS暗号通信の共通鍵暗号が行われる。なお、SSL/TLS暗号通信の仕様に従えば、ダミーのSSL/TLSネゴシエーション中のFinishedメッセージ処理から、各メッセージのデータ部はすべて暗号化しなければならないが、実際は暗号化しなくても問題ない。しかし、難読化を目的に、各メッセージのデータ部を、SSL/TLSネゴシエーションで送受信した乱数や固定値を共通鍵として、暗号化スクランブル化しても構わない。このような難読化は、ファイヤーウォールが厳密に各メッセージのデータ部をチェックしている場合に有効な手法となる。なお、ファイヤーウォールが厳密にSSL/TLSの再ネゴシエーションで送受信されるhandshakeのパケット数をカウントしている場合には、ダミーのhandshakeのパケットを送受信し、何度かSSL/TLSネゴシエーションが実行されているように見せかけてもよい。また、ダミーのSSL/TLSネゴシエーション以降の各メッセージChangeCipherSpecを含むを、暗号化されたデータ通信であるように見せかけてもよい。つまり、各メッセージを、データ通信、即ちapplication_dataのデータ部として送受信する。つまり、各メッセージChangeCipherSpecを含むに、application_dataヘッダとダミーのMACを付与する。また、ここで上述した図1~4、6について補足の説明を行う。図示していないが、クライアント1が有する公開鍵復号部600をサーバ2も同様に有する。これにより、サーバ2も公開鍵暗号された信号を復号することができる。また、本実施の形態において、SSLネゴシエーションサーバ部500とSSLネゴシエーションクライアント部400とは他の通信装置クライアント1とハンドシェイクを行うサーバ2側の認証処理部に相当し、さらにこのサーバ2側の認証処理部は鍵復号化部である公開鍵復号部と鍵暗号化部である公開鍵暗号部610を含んでもよい。同様に、SSLネゴシエーションサーバ部510とSSLネゴシエーションクライアント部410とはクライアント1側の認証処理部に相当する。なお、第1の鍵とは、サーバ2またはクライアント1で生成される共通鍵のことであり、この共通鍵を生成するための乱数等も含む。第2の鍵とは、第1の鍵の暗号化する公開鍵である。なお、サーバ部2に処理能力検知サーバ部を設けてもよい。これにより、サーバ2はサーバ2の処理能力とクライアント1の処理能力とに基づいて例えば、それぞれの処理能力を比較して、リバースSSLを行うかどうかを決定することができる。なお、リバースSSLを行うかどうかの判断は、クライアント1が行っても、サーバが行ってもよい。クライアント1またはサーバ2は、サーバ2のCPU使用率、クライアント1のCPU使用率、サーバ2の最大処理能力、クライアント1の最大処理能力、等に基づいてリバースSSLを行うかどうかを決定すればよい。図5は、図2のハードウェア構成図の一例である。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、書き換え不可の不揮発性メモリであるROM30とネットワークのデータ送受信を実行するMACMediaAccessControl/PHY40で構成されている。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM31とネットワークのデータ送受信を実行するMAC/PHY41で構成されている。また、クライアント1とサーバ2はMAC/PHY40とMAC/PHY41を介してネットワークで接続されている。はじめにクライアント1のハード構成に関して説明を行う。図3に示したクライアント1の各処理部は、CPU10、及びRAM20で実行される。共通鍵生成部750が生成した共通鍵、クライアントのCPUの使用率状況を示すCPU使用率情報、及び、リバースのSSL/TLSネゴシエーションを実行するか否かを示すフラグメモリは、RAM20に保存される。処理能力情報、公開鍵N、公開鍵E、秘密鍵Dは、ROM30に保存する。この内、処理能力情報、公開鍵N、及び、公開鍵EはRAM20に移動させて利用してもよいが、秘密鍵Dは耐タンパ装置の不揮発性メモリで利用するのが望ましい。MAC/PHY40は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次にサーバ2のハード構成に関して説明を行う。図3に示したサーバ2の各処理部は、CPU11、及びRAM21で実行される。共通鍵生成部760が生成した共通鍵、クライアント1から取得した公開鍵Nと公開鍵E、サーバのCPUの使用率状況を示すCPU使用率情報、及び、リバースのSSL/TLSネゴシエーションを実行するか否かを示すフラグメモリは、RAM21に保存される。処理能力の閾値の情報は、通常固定値なのでROM30に保存する。しかしサーバの負荷に応じて動的に閾値を変更させる等、RAM20に移動させて利用してもよい。MAC/PHY41は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置110を実現するものである。"