(57)【要約】【課題】サーバの中には、ＳＳＬ／ＴＬＳ暗号通信の仕様に従わずに、サーバ側で暗号スイートの優先順位付けを行うものが存在する。【解決手段】本発明の通信装置は、前記他の通信装置の使用可能な暗号方式の第１の情報を取得する暗号方式取得部と、前記第１の情報に基づいて、前記複数の暗号方式から前記他の通信装置との間の通信で使用する暗号方式を選択する暗号方式選択部と、前記暗号方式選択部が選択した暗号方式を前記他の通信装置に送信する送信部と、を備える。【選択図】図１
2014116641.tif 000002
【特許請求の範囲】
【請求項１】
複数の暗号方式から選択した暗号方式を使用して他の通信装置との間で暗号通信を行う通信装置であって、
前記他の通信装置の使用可能な暗号方式の第１の情報を取得する暗号方式取得部と、
前記第１の情報に基づいて、前記複数の暗号方式から前記他の通信装置との間の通信で使用する暗号方式を選択する暗号方式選択部と、
前記暗号方式選択部が選択した暗号方式を前記他の通信装置に送信する送信部と、を備える通信装置。
【請求項２】
請求項１記載の通信装置であって、
前記暗号方式取得部は、前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第１の情報を取得する通信装置。
【請求項３】
請求項２記載の通信装置であって、
前記他の通信装置との通信における前記複数の暗号方式の優先順位情報をさらに有し、
前記暗号方式取得部は、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信する通信装置。
【請求項４】
請求項３記載の通信装置であって、
前記優先順位情報は、他の通信装置に応じてそれぞれ異なる通信装置。
【請求項５】
請求項２記載の通信装置であって、
前記暗号方式取得部は、前記応答結果に基づいて前記他の通信装置が使用できない暗号方式の第２の情報を取得する通信装置。
【請求項６】
請求項１記載の通信装置であって、
前記暗号方式取得部は、前記複数の暗号方式から選択した複数の暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第１の情報を取得する通信装置。
【請求項７】
第１の通信装置と第２の通信装置とを備える通信システムであって、
前記第１の通信装置は、複数の暗号方式を使用可能であり、使用可能な暗号方式を前記第２の通信装置に送信し、
前記第２の通信装置は、前記第１の通信装置から送信された暗号方式の使用可否の情報を前記第１の通信装置に送信する通信システム。
【請求項８】
請求項６記載の通信システムであって、
前記第１の通信装置は、前記第２の通信装置から送信された前記使用可否の情報に基づいて、前記複数の暗号方式から前記第２の通信装置との間の通信で使用する暗号方式を選択する通信システム。
【請求項９】
請求項６記載の通信システムであって、
前記第１の通信装置は、前記第２の通信装置における前記複数の暗号方式の優先順位情報を有し、
前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記第２の通信装置に送信する通信装置。
【請求項１０】
請求項８記載の通信システムであって、
前記第１の通信装置と通信可能な第３の通信装置をさらに有し、
前記第１の通信装置は、前記第３の通信装置における前記複数の暗号方式の優先順位情報を有する通信システム。
【請求項１１】
請求項６記載の通信システムであって、
前記第１の通信装置は、前記複数の暗号方式から選択した複数の暗号方式を前記第２の通信装置に送信し、
前記第２の通信装置は、前記第１の通信装置から送信された各暗号方式の使用可否の情報を前記第１の通信装置に送信する通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）暗号通信に関するもので、特にＳＳＬ／ＴＬＳ通信のハンドシェイクに関し、例えば、ＳＳＬ／ＴＬＳ通信で使用する暗号スイートを決定する方法などに適用される。
【背景技術】
【０００２】
従来、通信を安全に行う方法の１つとして、ＳＳＬ／ＴＬＳ暗号通信がある。ＳＳＬ／ＴＬＳ暗号通信は、強力な暗号通信であるにも関わらず、非常に簡単に設定できるという特徴を備えている。この利便性故、ＳＳＬ／ＴＬＳ暗号通信は、近年、急速に普及し、安価な組込み機器においても搭載が普通になりつつある。
【０００３】
しかし、安価な組込み機器は一般的なパーソナルコンピュータに比べ、ＣＰＵが脆弱で、負荷の重い暗号処理の実行には適していない。それ故、安価な組込み機器では、ＳＳＬ／ＴＬＳ暗号通信を実行させる場合に、パフォーマンスのよい暗号スイートを選択するものが多い。あえて脆弱な組込み機器で重い暗号スイートを実行させれば、利便性を著しく損なうことになりかねない。
【０００４】
なお、認証などセキュリティレベルが求められる通信では、パフォーマンスよりも安全性を重視した暗号スイートの選択が求められるが、このような場合であっても、負荷の重い暗号スイートは限定的に利用するのが望ましい。
【０００５】
また、パフォーマンスの観点から、安価な組込み機器の多くは、ＳＳＬ／ＴＬＳ暗号通信のクライアント機能のみを実装するものが多い。
【０００６】
その理由の１つは、ＳＳＬ／ＴＬＳ暗号通信の公開鍵暗号方式にある。ＳＳＬ／ＴＬＳ暗号通信で利用される公開鍵暗号方式は、一般的にＲＳＡ（Ｒｉｖｅｓｔ  Ｓｈａｍｉｒ  Ａｄｌｅｍａｎ）暗号である。ＲＳＡ暗号では、サーバに比べ、クライアント側の処理は非常に軽くて済む。
【０００７】
もう１つの理由は、ＳＳＬ／ＴＬＳ暗号通信の仕様（非特許文献１、２、３参照）にある。クライアント・サーバ間で利用する暗号スイートは、クライアントが提示した複数の暗号スイートの中から、サーバが暗号スイートを選択するが、クライアントが暗号スイートを提示するにあたっては、並べた暗号スイートの順番で、自らの優先順位を提示できるようになっており、サーバはその優先順位のなるだけ高い暗号スイートを選択する仕組みになっている。つまり、利用する暗号スイートの優先順位づけは、クライントで行われる。
【０００８】
この仕様によって、クライアント、即ち、安価な組込み機器は、処理の軽い暗号スイートを利用することが可能となっている。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】Ｔ．Ｄｉｅｒｋｓ、Ｃ．Ａｌｌｅｎ、”Ｔｈｅ  ＴＬＳ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．０”、ＲＦＣ  ２２４６、［online］、１９９９年１月、［平成２３年３月２９日検索］ 、インターネット＜http://www.ietf.org/rfc/rfc2246.txt＞
【非特許文献２】Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、”Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ  （ＴＬＳ）  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．１”、ＲＦＣ  ４３４６、［online］、２００６年４月、［平成２３年３月２９日検索］、インターネット＜http://www.ietf.org/rfc/rfc4346.txt＞
【非特許文献３】Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、”Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ  （ＴＬＳ）  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．２”、ＲＦＣ  ５２４６、［online］、２００８年８月、［平成２３年３月２９日検索］、インターネット＜http://www.ietf.org/rfc/rfc5246.txt＞
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、サーバの中には、クライアントが提示する優先順位の高い暗号スイートをサポートしているにも関わらず、優先順位を無視して、提示された暗号スイートの中から、サーバが希望する暗号スイートを選択するものが存在する。つまり、サーバの中には、ＳＳＬ／ＴＬＳ暗号通信の仕様に従わずに、サーバ側で暗号スイートの優先順位付けを行うものが存在する。
【００１１】
本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、ＳＳＬ／ＴＬＳ暗号通信のクライアントとして動作している安価な組込み機器に、本来のＳＳＬ／ＴＬＳ暗号通信の仕様（非特許文献１、２、３参照）通りに、暗号スイートの優先順位付けの権利を与えることを目的としている。これにより、安価な組込み機器でも、パフォーマンス良くＳＳＬ暗号通信を利用できるようにするものである。
【課題を解決するための手段】
【００１２】
上述の課題を解決するために、本発明の通信装置は、複数の暗号方式から選択した暗号方式を使用して他の通信装置との間で暗号通信を行う通信装置であって、前記他の通信装置の使用可能な暗号方式の第１の情報を取得する暗号方式取得部と、前記第１の情報に基づいて、前記複数の暗号方式から前記他の通信装置との間の通信で使用する暗号方式を選択する暗号方式選択部と、前記暗号方式選択部が選択した暗号方式を前記他の通信装置に送信する送信部と、を備えるように構成とした。
【００１３】
また、本発明の通信装置は、前記暗号方式取得部は、前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第１の情報を取得するように構成した。
【００１４】
また、本発明の通信装置は、前記他の通信装置との通信における前記複数の暗号方式の優先順位情報をさらに有し、前記暗号方式取得部は、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記他の通信装置に送信するように構成した。
【００１５】
また、本発明の通信装置は、前記優先順位情報は、他の通信装置に応じてそれぞれ異なるように構成した。
【００１６】
また、本発明の通信装置は、前記暗号方式取得部は、前記応答結果に基づいて前記他の通信装置が使用できない暗号方式の第２の情報を取得するように構成した。
【００１７】
また、本発明の通信装置は、前記暗号方式取得部は、前記複数の暗号方式から選択した複数の暗号方式を前記他の通信装置に送信し、前記他の通信装置の応答結果に基づいて前記第１の情報を取得するように構成した。
【００１８】
また、本発明の通信システムは、第１の通信装置と第２の通信装置とを備える通信システムであって、前記第１の通信装置は、複数の暗号方式を使用可能であり、使用可能な暗号方式を前記第２の通信装置に送信し、前記第２の通信装置は、前記第１の通信装置から送信された暗号方式の使用可否の情報を前記第１の通信装置に送信するように構成した。
【００１９】
また、本発明の通信システムは、前記第１の通信装置は、前記第２の通信装置から送信された前記使用可否の情報に基づいて、前記複数の暗号方式から前記第２の通信装置との間の通信で使用する暗号方式を選択するように構成した。
【００２０】
また、本発明の通信システムは、前記第１の通信装置は、前記第２の通信装置における前記複数の暗号方式の優先順位情報を有し、前記優先順位情報に基づいて前記複数の暗号方式から選択した暗号方式を前記第２の通信装置に送信するように構成した。
【００２１】
また、本発明の通信システムは、前記第１の通信装置と通信可能な第３の通信装置をさらに有し、前記第１の通信装置は、前記第３の通信装置における前記複数の暗号方式の優先順位情報を有するように構成した。
【００２２】
また、本発明の通信システムは、前記第１の通信装置は、前記複数の暗号方式から選択した複数の暗号方式を前記第２の通信装置に送信し、前記第２の通信装置は、前記第１の通信装置から送信された各暗号方式の使用可否の情報を前記第１の通信装置に送信するように構成した。
【００２３】
また、本発明の通信装置は、クライアントにおける暗号スイートの優先順位情報に従って、利用する暗号スイートを選択するクライアントであって、前記クライアントはサーバの暗号スイートの搭載状況を調査する暗号スイート調査手段を備え、前記クライアントはこの前記暗号スイート調査手段を用いて、少なくとも１度は事前にサーバにおける暗号スイートの搭載情報を取得するものとし、ＳＳＬ／ＴＬＳ暗号通信で利用する暗号スイートの選択において、取得した暗号スイートの搭載情報を用いて、最適な暗号スイートを指定するように構成した。
【００２４】
ここで、暗号スイート調査手段というのは、例えば、別のコンピュータが調査した搭載情報を、そのコンピュータから取得するものであってもよいし、また自ら対象のサーバを調査し、搭載情報を取得するものであってもよい。
【００２５】
これによると、たとえ、相手が利用する暗号スイートの優先順位づけを行うサーバであっても、クライアントが主導的に利用する暗号スイートの優先順位付けを行うことが可能となり、安価な組込み機器のクライアントでも、パフォーマンス良くＳＳＬ暗号通信を利用できるようなる。
【００２６】
また、本発明の通信装置は、クライアントにおける暗号スイートの優先順位情報に従って、利用する暗号スイートを選択するクライアントであって、前記クライアントはサーバの暗号スイートの搭載状況を調査する暗号スイート調査手段を備え、前記クライアントはこの前記暗号スイート調査手段を用いて、少なくとも１度は事前にサーバにおける暗号スイートの搭載情報を取得するものとし、ＳＳＬ／ＴＬＳ暗号通信で利用する暗号スイートの選択において、前記クライアントは、前記サーバにおける暗号スイートの搭載情報と前記クライアントにおける暗号スイートの優先順位情報とから、前記サーバで利用可能な、クライアントにとって最も優先順位の高い暗号スイートを選択し、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）で、前記クライアントが前記サーバに利用する暗号スイートを指定するにあたっては、前記クライアントが選択した前記暗号スイートを少なくとも含み、かつ、選択した前記暗号スイートよりも前記サーバで優先順位の高い暗号スイートを含まない暗号スイートを指定するように構成した。
【００２７】
これによると、たとえ、相手が利用する暗号スイートの優先順位づけを行うサーバであっても、クライアントが主導的に利用する暗号スイートの優先順位付けを行うことが可能となり、安価な組込み機器のクライアントでも、パフォーマンス良くＳＳＬ暗号通信を利用できるようなる。
【００２８】
また、本発明の通信装置は、前記暗号スイート調査手段は、調査したい暗号スイートを指定してＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行い、前記サーバの応答結果を得ることで、その指定した暗号スイートが、前記サーバで搭載されているか否かを判断するように構成した。
【００２９】
これによると、クライアントは、サーバにおける暗号スイートの搭載情報を簡単、かつ迅速に取得できるようになる。
【００３０】
また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントが搭載していない暗号スイートも調査するように構成した。
【００３１】
これによると、暗号スイートの追加が図れるクライアントにおいては、あらかじめ追加される暗号スイートも含めてサーバにおける搭載状況を調査し、その搭載情報を保存しておけば、暗号スイート追加時に再調査の必要がなく、迅速な処理が可能となる。
【００３２】
また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントが搭載している暗号スイートのみを調査するように構成した。
【００３３】
これによると、サーバにおける暗号スイートの搭載状況の調査を迅速に行うことができる。暗号スイートの追加がない、若しくは稀にしかないクライアントでは、暗号スイート追加時の再調査を考慮するより、最初の搭載状況の調査時間を短縮させる方が望ましい。
【００３４】
また、本発明の通信装置は、前記暗号スイート調査手段は、前記クライアントにおける暗号スイートの優先順位順に、前記サーバにおける暗号スイートの搭載状況を調査し、かつ前記サーバがアラートを返信するか、若しくは調査する暗号スイートがなくなるまで、前記サーバにおける暗号スイートの搭載状況を調査するように構成した。
【００３５】
これによると、クライアントが搭載する暗号スイートに関して、サーバが搭載するか否かを調査することになるので、この搭載情報を保存すれば、クライアント側で暗号スイートの優先順位付けが変更になる際に、再調査の必要がなくなる。クライアントにおける暗号スイートの優先順位付けをユーザ設定にしていて、頻繁に暗号スイートの優先順位付けが変更される場合に効果が大きい。
【００３６】
また、本発明の通信装置は、前記クライアントは、調査したい複数の暗号スイートを複数同時に指定してＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行い、前記サーバの応答結果を得ることで、その指定した少なくとも１つ以上の暗号スイートが、前記サーバで搭載されているか否かを判断するものとし、前記応答結果が、前記サーバからの暗号スイートの指定であった場合には、先に指定した複数の暗号スイートから、この前記サーバが指定した暗号スイートを除去した１つ以上の暗号スイートを指定して、再度、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行い、前記サーバの応答結果から、この新たに指定した少なくとも１つ以上の暗号スイートが、前記サーバで搭載されているか否かの判断を行うように構成した。
【００３７】
これによると、クライアントが搭載する暗号スイートに関して、サーバが搭載するか否かを調査する場合、その調査時間を短縮できる。
【００３８】
クライアントが搭載する暗号スイートをサーバが搭載するか否かを１つ１つ調査する場合は、暗号スイートの数だけ調査しなければならず時間を要する。一方この方法では、クライアントが、サーバが搭載する暗号スイートを少なくとも１つでも含む暗号スイートを提示している間は、１つ１つ調査する場合と手間は変わらないが、最後に、サーバが搭載しない複数の暗号スイートを提示した場合に、一回の調査で済み、手間を省ける。
【００３９】
なおこの方法では、サーバが暗号スイートの優先順位付けを行うサーバの場合、サーバが搭載する暗号スイートだけでなく、サーバが選択した暗号スイートの順番を見ることで、サーバにおける暗号スイートの優先順位付けをも知ることが可能である。
【００４０】
また、本発明の通信装置は、前記暗号スイート調査手段は、サーバにおける暗号スイートの優先順位も合わせて調査するように構成した。
【００４１】
これによると、サーバにおける暗号スイートの優先順位付けと、クライアントにおける暗号スイートの優先順位付けが同じであれば、クライアントはＳＳＬ／ＴＬＳネゴシエーションを通常の方法で実行できる。クライアントで搭載情報を記憶できない装置の場合、毎回、サーバにおける暗号スイートの搭載状況を調査する必要がなくなる。つまり、ＳＳＬ／ＴＬＳネゴシエーション処理の迅速化が図れてよい。
【００４２】
また、本発明の通信装置は、前記暗号スイート調査手段は、複数のＴＣＰポートを用意し、それぞれのポートで、各々に調査したい暗号スイートを指定して、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行うように構成した。
【００４３】
これによると、クライアントはサーバにおける暗号スイートの搭載状況を迅速に調査することが可能となる。同じＴＣＰポートを利用して調査する場合は、一回一回、サーバの応答を待たなくてはならないが、この方法を利用すれば、その必要がなくなる。
【００４４】
また、本発明の通信装置は、前記暗号スイート調査手段は、ＳＳＬ／ＴＬＳ暗号通信で利用するＴＣＰポートとは別のＴＣＰポートを利用して調査するように構成した。
【００４５】
これによると、ＳＳＬ／ＴＬＳ暗号通信を行うのに、ＳＳＬ／ＴＬＳ暗号通信を行う主体であるアプリケーションと、ＳＳＬ／ＴＬＳ暗号通信を実現するＳＳＬ／ＴＬＳ暗号モジュールが分離され実装されている場合に、ＳＳＬ／ＴＬＳ暗号モジュールは、アプリケーションがＳＳＬ／ＴＬＳ暗号通信に利用するとしてＳＳＬ／ＴＬＳ暗号モジュールに指定したＴＣＰポートを利用せずに、別のＴＣＰポートを利用してサーバにおける暗号スイートの搭載状況を調査できる。
【００４６】
調査に利用するＴＣＰポートは閉じらる場合があるが、この方法であれば、アプリケーションがＳＳＬ／ＴＬＳ暗号通信に利用するとしてＳＳＬ／ＴＬＳ暗号モジュールに指定したＴＣＰポートは調査には利用されないので、閉じられない。これにより、アプリケーションのつくりを非常に簡単にできる。
【００４７】
また、本発明の通信装置は、前記クライアントは、前記サーバにおける暗号スイートの搭載情報の記憶、及び、読出しを行う搭載状況記憶手段を備え、前記クライアントはこの前記搭載状況記憶手段を用いて、前記サーバにおける暗号スイートの搭載情報を記憶し、ＳＳＬ／ＴＬＳ暗号通信において、この前記搭載状況記憶手段を用いて、記憶した前記サーバにおける暗号スイートの搭載情報を読出すように構成した。
【００４８】
これによると、サーバにおける暗号スイートの搭載状況調査を再度実行する必要がないので、ＳＳＬ／ＴＬＳネゴシエーションを迅速に行うことができる。
【００４９】
また、本発明の通信装置は、前記サーバにおける暗号スイートの搭載情報と前記クライアントにおける暗号スイートの優先順位情報とを別々に記憶するように構成した。
【００５０】
これによると、接続するサーバや通信目的によってクライアントにおける暗号スイートの優先順位付けが異なる場合に、記憶容量を減らせると共に、記憶方法を簡略化することが可能となる。
【００５１】
また、本発明の通信装置は、前記サーバにおける暗号スイートの搭載情報と、前記クライアントにおける暗号スイートの優先順位情報とを、合わせて記憶するように構成した。
【００５２】
これによると、接続するサーバが決まっている場合などに、記憶容量を減らすことができる。
【００５３】
また、本発明の通信装置は、通信内容やクライントの負荷状況など、前記クライントの都合によって、利用する暗号スイートの優先順位付けが異なる前記クライアントであって、前記クライアントがＳＳＬ／ＴＬＳ暗号通信中に通信内容を変更する場合に、ＳＳＬ／ＴＬＳの再ネゴシエーションを行うように構成した。
【００５４】
これによると、たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、通信目的やクライントの負荷状況に応じて、クライアントが主導的に暗号スイートを選択できる。
【００５５】
例えば、クライアントは、認証ではセキュリティの高い暗号スイートを選択し、負荷状況が高い多量のデータの受け渡しにおいては、パフォーマンスのよい暗号スイートを選択することが可能である。
【００５６】
また、本発明の通信装置は、複数のサーバと通信する前記クライアントであって、通信するサーバに合わせて、利用する暗号スイートの優先順位情報を変更するように構成した。
【００５７】
これによると、様々な種類のサーバに対してもクライアント主導で暗号スイートを選択して通信できるようになる。
【００５８】
また、本発明の通信装置は、前記クライアントにおける暗号スイートの優先順位情報をユーザが変更できる優先順位変更手段を備え、この前記優先順位変更手段を用いて、前記クライアントにおける暗号スイートの優先順位情報を変更するように構成した。
【００５９】
これによると、ユーザのセキュリティポリシーや考え方を、ＳＳＬ／ＴＬＳ暗号通信に反映できる。
【００６０】
また、本発明の通信装置は、前記クライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する調査判断手段を備え、前記クライアントが、前記調査判断手段を用いて、前記サーバにおける暗号スイートの搭載情報を調査するか否かの判断を行うように構成した。
【００６１】
これによると、暗号スイート優先順位付けを行わないサーバや、暗号スイートの優先付けを行っていてもクライアントにとって影響の小さいサーバに対してまでも、クライアントがサーバにおける暗号スイートの搭載状況を調査する必要がなくなり、手間が省けてよい。
【００６２】
また、本発明の通信装置は、前記調査判断手段は、サーバが搭載する少なくとも２つ以上の暗号スイートを同時に指定したＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行い、前記サーバが、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで先頭に記述した暗号スイートを選択するか否かで、サーバが暗号スイートの優先付けを行っているか否かを判断するものであって、サーバがＣｌｉｅｎｔ  Ｈｅｌｌｏで先頭に記述した暗号スイートを選択しない場合は、サーバが暗号スイートの優先付けを行わないと判断するように構成した。
【００６３】
これによると、簡単にサーバが暗号スイートの優先順位付けを行っているか否かを、自動的に調査可能となる。
【００６４】
また、本発明の通信装置は、前記調査判断手段は、サーバがサポートする少なくとも２つの暗号スイート内、１つの暗号スイートを選択し、これをＣｌｉｅｎｔ  Ｈｅｌｌｏで先頭に記述暗号スイートとして、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行い、次に、別の暗号スイートを選択し、これをＣｌｉｅｎｔ  Ｈｅｌｌｏで先頭に記述暗号スイートとして、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行うことで、サーバが暗号スイートの優先付けを行っているか否かを判断するように構成した。
【００６５】
これによると、クライアントは、確実、かつ、迅速に、暗号スイートの優先順位付けを行っているか否かを、自動的に調査可能となる。
【発明の効果】
【００６６】
本発明によれば、通信装置の負荷を他の通信装置に分散することができる。すなわち、通信装置の負荷を低減することができる。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第１例を示すシーケンス図
【図２】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第１例を示すシーケンス図
【図３】本発明の実施の形態における機能ブロックの第１例を示す図
【図４】本発明の実施の形態におけるクライアント側のフローチャートの第１例を示す図
【図５】本発明の実施の形態におけるサーバ側のフローチャートの第１例を示す図
【図６】本発明の実施の形態におけるハードウェア構成の第１例を示す図
【図７】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第２例を示すシーケンス図
【図８】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第３例を示すシーケンス図
【図９】本発明の実施の形態における機能ブロックの第２例を示す図
【図１０】本発明の実施の形態におけるクライアント側のフローチャートの第２例を示す図
【図１１】本発明の実施の形態におけるサーバ側のフローチャートの第２例を示す図
【図１２】本発明の実施の形態におけるハードウェア構成の第２例を示す図
【図１３】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第２例を示すシーケンス図
【図１４】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第４例を示すシーケンス図
【図１５】本発明の実施の形態における機能ブロックの第３例を示す図
【図１６】本発明の実施の形態におけるクライアント側のフローチャートの第３例を示す図
【図１７】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第３例を示すシーケンス図
【図１８】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第５例を示すシーケンス図
【図１９】本発明の実施の形態における機能ブロックの第４例を示す図
【図２０】本発明の実施の形態におけるクライアント側のフローチャートの第４例を示す図
【図２１】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第４例を示すシーケンス図
【図２２】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第６例を示すシーケンス図
【図２３】本発明の実施の形態における機能ブロックの第５例を示す図
【図２４】本発明の実施の形態におけるクライアント側のフローチャートの第５例を示す図
【図２５】本発明の実施の形態におけるハードウェア構成の第３例を示す図
【図２６】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第７例を示すシーケンス図
【図２７】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第８例を示すシーケンス図
【図２８】本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第９例を示すシーケンス図
【図２９】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第５例を示すシーケンス図
【図３０】本発明の実施の形態における機能ブロックの第６例を示す図
【図３１】本発明の実施の形態におけるクライアント側のフローチャートの第６例の一方を示す図
【図３２】本発明の実施の形態におけるクライアント側のフローチャートの第６例の他方を示す図
【図３３】本発明の実施の形態におけるサーバ側のフローチャートの第３例を示す図
【図３４】本発明の実施の形態におけるハードウェア構成の第４例を示す図
【図３５】本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第１例を示す図
【図３６】本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第２例を示す図
【図３７】本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合の「クライアントがサポートする暗号スイートの優先順位情報」の実装方法のの第１例を示す図
【図３８】本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合の「クライアントがサポートする暗号スイートの優先順位情報」の実装方法の第２例を示す図
【図３９】本発明の実施の形態における「クライアントがサポートする暗号スイートの優先順位情報」をユーザが変更する方法の第１例を示す図
【図４０】本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第１例を示す図
【図４１】本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第２例を示す図
【図４２】本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第６例を示すシーケンス図
【発明を実施するための形態】
【００６８】
以下、本発明の実施の形態を、図面を参照しながら説明する。
【００６９】
なお説明を簡単にするため、クライアント、サーバはそれぞれ下記の暗号スイートを保持するものと仮定して説明を行う。なお、暗号スイートとは、例えば、暗号化アルゴリズムと圧縮アルゴリズムであり、鍵交換方式や、暗号方式等を含む。実際の実装においては、搭載される（すなわち、使用可能な）暗号スイートはどのようなものであっても構わない。
クライアント：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
サーバ：      ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
また、特別に説明がない場合は、クライアントにおける暗号スイートの優先順位付けは下記の設定になっているものとして説明を行う。これも実際の実装においては、どのような優先順位づけを行ってもよい。なお、この優先順位の情報はサーバまたはクライアントに格納されてもよいし、外部の記憶装置等に格納されてもよい。外部の記憶装置に格納される場合、サーバまたはクライアントがネットワーク等を介して優先順位の情報を取得すればよい。また、ＣＰＵ等の制御部で、優先順位を都度算出してもよい。
１：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
２：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
３：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
４：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
優先順位は１が最も高く、２、３、４という順番で優先順位が低くなるものとする。なお説明を簡単にするために、同じ優先順位の暗号スイートはないようにしているが、実際の実装においては同じ優先順位の暗号スイートが複数存在してもよい。
【００７０】
図１は、本発明によるＳＳＬ／ＴＬＳ暗号通信の一例を示すシーケンス図である。
【００７１】
（図１−（Ｓ１））クライアントは、サーバがサポートする暗号スイートの搭載状況（使用可能な暗号スイートの情報）を調査することで、クライアントがサポートする暗号スイートの内、以下の暗号スイートをサーバがサポートしないことを知る。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
（図１−（Ｓ２））クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当すれば、次に優先順位の高い暗号スイートを選択する。
【００７２】
クライアントの優先順位１、２の暗号スイートは、上記暗号スイートに該当するので、クライアントは下記に記述する、優先順位３の暗号スイートを選択する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
なお本図を含めてすべての図で、同じ優先順位の暗号スイートは１つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで１つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。すなわち、本実施の形態において、ここでの選択とはすべて暗号スイート選択する場合も含む。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するＣｌｉｅｎｔ  Ｈｅｌｌｏを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは１つしかないものとする。
【００７３】
（図１−（Ｓ３））クライアントがこの選択した暗号スイートを指定して、サーバにＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（４）サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにＳｅｒｖｅｒ  Ｈｅｌｌｏを送信する。図示していないが、この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【００７４】
たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、本発明に従えば、このように、クライアントが主導的に暗号スイートを選択できるメリットがある。パフォーマンスのよい暗号スイートをクライアント主導で選択できるため、特に、脆弱なＣＰＵを搭載しているような組込み機器の場合にこの効果は大きい。
【００７５】
なお、ここでは、クライアントが１つのサーバを相手にするケースで説明を行っているが、複数のサーバを相手にするケースでは、「クライントがサポートする暗号スイートの優先順位情報」はサーバ毎に異なっていてもよい。例えば、銀行や証券など金融系サーバに対しては、セキュリティを重視した暗号スイートの優先順位を高くし、大量にデータを受信するインターネットテレビなどコンテンツ系サーバに対しては、パフォーマンスを重視した暗号スイートの優先順位を高くするなどの設定を行うとよい。
【００７６】
図２は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第１例を示すシーケンス図であり、図１の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の一例を示すシーケンス図でもある。
【００７７】
ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを１つ指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその暗号スイートを保持していないと判断する。
【００７８】
（図２−（Ｓ１））クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位１の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２−（Ｓ２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバがＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないことを知る。（図２−（Ｓ３））そして通信を切断する。通信の切断はサーバ側から行われるのが一般的であるが、サーバが切断しない場合は、クライアント側から通信を切断する。これ以降のすべての図の説明において、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）後の通信の切断は同様であり、説明を割愛する。なお、通信の切断は例えば、ネットワーク制御部１００で行われる。
【００７９】
（図２−（Ｓ４））優先順位１の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサーバがサポートしていないので、クライアントは次に優先順位２の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。（図２−(Ｓ６)そして通信を切断する。なお、ここまでの処理が、結果として、クライアントがサーバの暗号スイートの搭載情報を調査するものになる。つまり、クライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしないという「サーバがサポートしない暗号スイートの情報」を取得したことになる。
【００８０】
なお、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【００８１】
なお、クライアントは、「サーバがサポートしない暗号スイートの情報」を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、「サーバがサポートしない暗号スイートの情報」を利用して、直ちに、次の(７)の処理に進むことが可能となる。
【００８２】
（図２−（Ｓ７））優先順位２の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサーバがサポートしていないので、クライアントは次に優先順位３の暗号スイートを選択する。結果として、これが利用する暗号スイートを選択したことになる。（図２−(Ｓ８)）そして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。結果として、これが利用する暗号スイートを伝達したことになる。（図２−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【００８３】
この方法は、優先順位の高い暗号スイートから順に、サーバがその暗号スイートをサポートするか否かを逐次確かめるものである。そして、サーバが指定した暗号スイートをサポートしていれば、通信を切断することなく、そのままＳＳＬ／ＴＬＳ暗号通信を行うものである。
【００８４】
なお上記の説明では、説明を簡便にするため、暗号スイートの優先順位順に逐次調査すると説明したが、必ずしも暗号スイートの優先順位順に調査しなければならないものではない。複数のポート番号を利用可能な場合は、複数のチャネルで接続し、同時に複数のＣｌｉｅｎｔ  Ｈｅｌｌｏを送信することが可能である。図２で言えば、サーバの暗号スイートの搭載状況を調べるＣｌｉｅｎｔ  Ｈｅｌｌｏと利用する暗号スイートを伝達するＣｌｉｅｎｔ  Ｈｅｌｌｏ、つまり１、４、８（どれが先に送信されてもよい）を同時に送信し、その後、２、５、９を得て、その結果から、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択することが可能である。そしてこの暗号スイートの通信でそのままＳＳＬ／ＴＬＳ暗号通信を行う。
【００８５】
この後の図の説明でも、このような複数ポート番号を利用する方法はあるが、特に必要がなければ、説明を簡単にするため、この説明は割愛する。
【００８６】
図３は、本発明の実施の形態における機能ブロックの第１例を示す図であり、図２の機能ブロック図の一例でもある。また図４は、本発明の実施の形態におけるクライアント側のフローチャートの第１例を示す図であり、図３のクライアント１のフローチャートでもある。また、図５は、本発明の実施の形態におけるサーバ側のフローチャートの第１例を示す図であり、本発明の実施の形態におけるサーバ側のフローチャートの第１例を示す図でもある。次にこの図３、図４、図５を用いて説明を行う。
【００８７】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１は「クライアントがサポートする暗号スイートの優先順位情報」で、利用したい暗号スイートの優先順位づけを行っており、現在、どの優先順位の暗号スイートが選択されているかを「現在の優先順位を示すカウンタ」７００に番号として記憶する仕組みになっている。「現在の優先順位を示すカウンタ」７００の初期値は１である。
【００８８】
（図４−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在の優先順位を示すカウンタ」７００から暗号スイートの情報を読み出す。はじめは、「現在の優先順位を示すカウンタ」７００の値が１なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」という情報が読み出される。
【００８９】
（図４−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【００９０】
（図４−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【００９１】
（図４−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【００９２】
（図５−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【００９３】
（図５−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【００９４】
（図５−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【００９５】
（図５−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【００９６】
（図５−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのメッセージ受信待ち状態になる
（図４−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【００９７】
（図４−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【００９８】
（図４−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを受け取ったので、通信を切断する。なおサーバ側が通信を切断しない場合でも、通信の切断を行う。そしてＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在の優先順位を示すカウンタ」７００に１を加算して、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。「現在の優先順位を示すカウンタ」７００に１を加算したことで、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を搭載しないことの調査結果を得たことになる。
【００９９】
（図４−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在の優先順位を示すカウンタ」７００から暗号スイートの情報を読み出す。「現在の優先順位を示すカウンタ」７００の値が２なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」という情報が読み出される。
【０１００】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、（図４−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在の優先順位を示すカウンタ」７００に１を加算して、再びＣｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す。「現在の優先順位を示すカウンタ」７００に１を加算したことで、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を搭載しないことの調査結果を得たことになる。
【０１０１】
（図４−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在の優先順位を示すカウンタ」７００から暗号スイートの情報を読み出す。「現在の優先順位を示すカウンタ」７００の値が３なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。なお、サーバ２は「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、ここでクライアント１は結果的に、利用する暗号スイートを選択したことになる。
【０１０２】
（図４−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。つまり、ここでクライアント１は結果的に、利用する暗号スイートを伝達したことになる。
【０１０３】
（図４−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０１０４】
（図４−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０１０５】
（図５−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０１０６】
（図５−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０１０７】
（図５−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０１０８】
（図５−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０１０９】
（図５−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０１１０】
（図５−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０１１１】
（図４−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０１１２】
（図４−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０１１３】
（図４−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、これをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０１１４】
（図４−（Ｓ７））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０１１５】
（図４−（Ｓ８））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０１１６】
（図４−（Ｓ９））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる
（図５−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０１１７】
（図５−（Ｓ１０））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０１１８】
（図５−（Ｓ１１））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０１１９】
機能ブロック図には図示していないが、この後は、サーバ２は作成した共通鍵を使ってクライアント１と暗号通信を行う。なお、暗号通信とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０１２０】
（図４−（Ｓ９））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０１２１】
（図４−（Ｓ１０））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０１２２】
以上の説明により、暗号方式（暗号スイート）取得部は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）とＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）とに相当する。また、暗号方式取得部が取得した情報に基づいて、サーバ２に送信する暗号スイートを選択するＣｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は暗号方式選択部でもある。なお、暗号方式取得部または暗号方式選択部が優先順位を算出してもよい。
【０１２３】
機能ブロック図には図示していないが、この後は、クライアント１は作成した共通鍵を使ってサーバ２と暗号通信を行う。
【０１２４】
図６は、本発明の実施の形態におけるハードウェア構成の第１例を示す図であり、図３のハードウェア構成図の一例でもある。クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、書き換え可能な不揮発性メモリであるＨＤＤ（ハードディスク）３０、書き換え不可の不揮発性メモリであるＲＯＭ４０とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５０で構成されている。一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ４１とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５１で構成されている。また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ５０とＭＡＣ／ＰＨＹ５１を介してネットワークで接続されている。
【０１２５】
はじめにクライアント１のハード構成に関して説明を行う。図３に示したクライアント１の各処理部は、ＣＰＵ１０、及びＲＡＭ２０で実行される。
【０１２６】
「現在の優先順位を示すカウンタ」７００は、一時的な記憶メモリであるＲＡＭ２０に配置しているが、書き換え可能なメモリであれば良く、ＨＤＤ（ハードディスク）３０やフラッシュＲＯＭなどに配置してもよい。
【０１２７】
次に「クライアントがサポートする暗号スイートの優先順位情報」であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてＨＤＤ（ハードディスク）３０を利用しているが、フラッシュＲＯＭなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。「クライアントがサポートする暗号スイートの優先順位情報」を一時的な記憶メモリであるＲＡＭ２０に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。
【０１２８】
なお、「クライアントがサポートする暗号スイートの優先順位情報」が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるＲＯＭ４０などに配置してもよい。
【０１２９】
「クライアントがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント１の機能ブロック図には、「クライアントがサポートする暗号スイート」を示していないが、サーバ２の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、「クライアントがサポートする暗号スイート」をＲＯＭ４０に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、ＲＡＭ２０のような揮発性メモリに配置することも可能である。
【０１３０】
ＭＡＣ／ＰＨＹ５０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
【０１３１】
次にサーバ２のハード構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、及びＲＡＭ２１で実行される。
【０１３２】
「サーバがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、「サーバがサポートする暗号スイート」をＲＯＭ４１に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、ＲＡＭ２１のような揮発性メモリに配置することも可能である。
【０１３３】
ＭＡＣ／ＰＨＹ５１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置２００を実現するものである。
【０１３４】
図７は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第２例を示すシーケンス図であり、図１の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の別の一例を示すシーケンス図でもある。図２とほぼ同じシーケンスでもある。図２との違いは、（図７−（Ｓ７））、（図７−（Ｓ８））、（図７−（Ｓ９））に示すように、クライアントがサーバに対して、優先順位３の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信し、サーバがＳｅｒｖｅｒ  Ｈｅｌｌｏを返信した際に、連続してＳＳＬ／ＴＬＳネゴシエーションを実行せず、一端通信を切断していることである。これにより、「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズが明確に分離することが可能となる。
【０１３５】
「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズを分離すれば、事前に、「サーバの暗号スイートの搭載情報を調査する」ことが可能となるので、ＳＳＬ／ＴＬＳネゴシエーションを実行する際に、再度、調査する必要がなくなり、迅速なＳＳＬ／ＴＬＳネゴシエーションを実現できるようになる。
【０１３６】
例えば、クライアント装置でユーザが接続するサーバ装置を指定できる場合、その設定時に、サーバ装置の暗号スイートの搭載情報を調査して記憶するようなことが可能となる。
【０１３７】
なお、この図７の機能ブロック図、フローチャートは、ほぼ図３、図４、図５、図６とほぼ同様なので説明を割愛する。大きな違いは、（図４−（Ｓ５））でＳｅｒｖｅｒ  Ｈｅｌｌｏを受信した場合に、（図４−（Ｓ７））に進まず、通信を切断するところである。詳細に関しては、次の図８以降で説明を行う。
【０１３８】
図８は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第３例を示すシーケンス図であり、図１の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の別の一例を示すシーケンス図でもある。図７とほぼ同じシーケンスである。これも「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズを明確に分離するものである。
【０１３９】
図７では、クライアントがサポートする優先順位の高い暗号スイートをサーバがサポートするか否かを調査しているが、図８では、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるものの「クライアントがサポートする暗号スイートの優先順位情報」が変更になった場合に、再度調査する必要がなくなる。例えば、クライアント装置でユーザが「クライアントがサポートする暗号スイートの優先順位情報」を変更する場合に都合がよい。
【０１４０】
また、今までの図の説明では、「クライアントがサポートする暗号スイートの優先順位情報」は１つしか存在しないケースで説明を行っているが、これが複数ある場合にも、図８の手法が適している。例えば、同じサーバに接続する場合であっても、認証にはより強力な処理の重い暗号スイートを優先し、通常の通信にはパフォーマンスのよい軽い暗号スイートを優先させたい場合がある。このような場合でも、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを一度調査すれば、それぞれの場合で、選択すべき暗号スイートが分かるので手間が省けてよい。
【０１４１】
なお、ここではクライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で暗号スイートの優先順位付けをする場合に、どのような場合であっても利用されない暗号スイートがある場合は、これを除外するのは合理的である。またどのような場合であっても、優先順位が高い暗号スイートがあり、接続するサーバがこの暗号スイートを必ずサポートする場合は、この暗号スイートより優先順位が高い暗号スイートだけを調査すればよい。
【０１４２】
次に図８の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを１つ指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその暗号スイートを保持していないと判断する。
【０１４３】
（図８−（Ｓ１））クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位１の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図８−（Ｓ２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバがＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておく。（図８−（Ｓ３））そして通信を切断する。
【０１４４】
（図８−（Ｓ４））次にクライアントは、優先順位２の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図８−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておく。（図８−(Ｓ６)）そして通信を切断する。
【０１４５】
（図８−（Ｓ７））次にクライアントは、優先順位３の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
【０１４６】
（図８−（Ｓ８））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（図８−（Ｓ９）)そして通信を切断する。
【０１４７】
なお、ここでは（図８−（Ｓ９））で通信を切断しているが、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信されてきた場合は、ＳＳＬ／ＴＬＳネゴシエーションを完了してから、通信の切断を行ってもよい。また、ＳＳＬ／ＴＬＳネゴシエーションを完了した場合は、通信を切断せずに、次の（図８−（Ｓ１０））のＣｌｉｅｎｔ  Ｈｅｌｌｏで再ネゴシエーションを行ってもよい。これ以降の図の説明でも、Ｓｅｒｖｅｒ  Ｈｅｌｌｏが返信されてきた場合には、同様の処理が可能である。以降の図ではこの説明は割愛する。
【０１４８】
但し、ＳＳＬ／ＴＬＳネゴシエーションを完了すると公開鍵暗号処理で時間を要するので、好ましくない。
【０１４９】
（図８−（Ｓ１０））次にクライアントは、優先順位４の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図８−（Ｓ１１））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（図８−（Ｓ１２）)そして通信を切断する。
【０１５０】
以上の手順によって、クライアントは、自らがサポートする暗号スイートの内、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサーバがサポートしないという「サーバがサポートしない暗号スイートの情報」を少なくとも記憶する。
【０１５１】
なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。
【０１５２】
なお、図２、図７と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【０１５３】
またクライアントは、「サーバがサポートしない暗号スイートの情報」を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、「サーバがサポートしない暗号スイートの情報」を利用して、直ちに、次の（図８−（Ｓ１３）)の処理に進むことが可能となる。
【０１５４】
（図８−（（Ｓ１３））次に、クライアントはサーバと実際にＳＳＬ／ＴＬＳ暗号通信を行うため、利用する暗号スイートの選択を行う。優先順位１と２の暗号スイートをサーバがサポートしていないので、クライアントは優先順位３の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０１５５】
（図８−（Ｓ１４）)そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図８−（Ｓ１５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０１５６】
なお、サーバの暗号スイートの搭載状況を十分調査し、サーバが、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」より「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を優先しているという情報を得るか、またはサーバはクライアントの優先順位に従う、つまり上位に記載された暗号スイートを選択するという情報を得ている場合には、クライアントは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信してもよい。但しこのような方法は時間を要すので好ましくない。この後の図でもこれは同じなので、これ以降の図では、この説明は割愛する。
【０１５７】
図９は、本発明の実施の形態における機能ブロックの第２例を示す図であり、図８の機能ブロック図の一例でもある。また図１０は、本発明の実施の形態におけるクライアント側のフローチャートの第２例を示す図であり、図９のクライアント１のフローチャートでもある。また、図１１は、本発明の実施の形態におけるサーバ側のフローチャートの第２例を示す図であり、図９のサーバ２のフローチャートでもある。次にこの図９、図１０、図１１を用いて説明を行う。なお、この図９、図１０、図１１は、一部、図７の詳細説明にもなっている。
【０１５８】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１は「クライアントがサポートする暗号スイートの優先順位情報」で、利用したい暗号スイートの優先順位付けを行っており、搭載情報８００（搭載状況記憶手段または暗号方式格納部）で、その各々の暗号スイートに対して、サーバ２でサポートされていない暗号スイートをチェックする仕組みになっている。なお、サポートされている暗号スイートは、サポートされるものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされない暗号スイートのみをチェックするものとする。またここでは、搭載情報８００（搭載状況記憶手段）は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。
【０１５９】
なおここでは、搭載情報８００（搭載状況記憶手段）で、サーバの暗号スイートの搭載情報を記憶するようにしているが、このような記憶領域を特別に設けずに、「クライアントがサポートする暗号スイートの優先順位情報」に、サーバの暗号スイートの搭載情報も記憶するとすることも可能である。しかし説明を簡単にするために、これ以降の図でも、搭載情報８００（搭載状況記憶手段）で、サーバの暗号スイートの搭載情報を記憶するものとする。但し、図３７、図３８では、「クライアントがサポートする暗号スイートの優先順位情報」に、サーバの暗号スイートの搭載情報を記憶する方法を説明する。
【０１６０】
また、クライアント１には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す「現在のカウンタ」７１０が設けてある。「現在のカウンタ」７１０には暗号スイートの優先順位の番号を入力するようになっており、クライアント１は、「現在のカウンタ」７１０に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。
【０１６１】
「現在のカウンタ」７１０に０が代入された場合には、クライアント１はサーバの暗号スイートの搭載状況を調査せず、通常のＳＳＬ／ＴＬＳネゴシエーションを行い、ＳＳＬ／ＴＬＳ暗号通信を行うようになっている。なおここでは、「現在のカウンタ」７１０の初期値は１とする。
【０１６２】
（図１０−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。はじめは、「現在のカウンタ」７１０の値が１なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」という情報が読み出される。
【０１６３】
（図１０−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０１６４】
（図１０−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０１６５】
（図１０−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０１６６】
（図１１−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０１６７】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０１６８】
（図１１−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【０１６９】
（図１１−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【０１７０】
（図１１−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージの受信待ち状態になる。
【０１７１】
（図１０−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０１７２】
（図１０−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０１７３】
（図１０−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを受け取ったので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしないことを記憶する。
【０１７４】
（図１０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０１７５】
（図１０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４）＋１
か否かをチェックする。ここで「現在のカウンタ」７１０の値は２なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
【０１７６】
（図１０−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が２なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」という情報が読み出される。
【０１７７】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、（図１０−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしないことを記憶する。
【０１７８】
（図１０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０１７９】
（図１０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は３なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１０−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が３なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。
【０１８０】
（図１０−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０１８１】
（図１０−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０１８２】
（図１０−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０１８３】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０１８４】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０１８５】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０１８６】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０１８７】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０１８８】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０１８９】
（図１０−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０１９０】
（図１０−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０１９１】
（図１０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０１９２】
（図１０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は４なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１１−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０１９３】
（図１０−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が４なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。
【０１９４】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートするので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０１９５】
（図１０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０１９６】
（図１０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。
【０１９７】
（図１０−（Ｓ９））ここで「現在のカウンタ」７１０の値は５なので、（つまり、上記等式が成り立つので）Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０に０を設定し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す（つまり（Ａ）に進む）。
（図１０−（Ｓ１０））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、「現在のカウンタ」７１０が０の場合、搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。具体的には以下のように選定する。（１）Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位１の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」がサポートされていないことを知る。（２）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位２の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」がサポートされていないことを知る。（３）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位３の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」がサポートされていることを知る。そこで、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択する。
【０１９８】
なおここでは、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、チェックされている１つ前の暗号スイートを選択するとしてもよい。このように、搭載情報８００（搭載状況記憶手段）から暗号スイートの選択方法する方法は様々な手段が存在する。
【０１９９】
（図１０−（Ｓ１１））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０２００】
（図１０−（Ｓ１２））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０２０１】
（図１０−（Ｓ１３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０２０２】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０２０３】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０２０４】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０２０５】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０２０６】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０２０７】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０２０８】
（図１０−（Ｓ１３））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０２０９】
（図１０−（Ｓ１４））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０が０の場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０２１０】
（図１０−（Ｓ１５））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０２１１】
（図１０−（Ｓ１６））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０２１２】
（図１０−（Ｓ１７））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる
（図１１−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０２１３】
（図１１−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０２１４】
（図１１−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０２１５】
機能ブロック図には図示していないが、この後は、サーバ２は作成した共通鍵を使ってクライアント１と暗号通信を行う。なお、暗号通信とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０２１６】
（図１０−（Ｓ１７））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０２１７】
（図１０−（Ｓ１８））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０２１８】
機能ブロック図には図示していないが、この後は、クライアント１は作成した共通鍵を使ってサーバ２と暗号通信を行う。
【０２１９】
図１２は、本発明の実施の形態におけるハードウェア構成の第２例を示す図であり、図９のハードウェア構成図の一例でもある。クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、書き換え可能な不揮発性メモリであるＨＤＤ（ハードディスク）３０、書き換え不可の不揮発性メモリであるＲＯＭ４０とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５０で構成されている。一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ４１とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５１で構成されている。また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ５０とＭＡＣ／ＰＨＹ５１を介してネットワークで接続されている。
【０２２０】
はじめにクライアント１のハード構成に関して説明を行う。図３に示したクライアント１の各処理部は、ＣＰＵ１０、及びＲＡＭ２０で実行される。
【０２２１】
「現在のカウンタ」７１０、及び搭載情報８００（搭載状況記憶手段）は、一時的な記憶メモリであるＲＡＭ２０に配置しているが、書き換え可能なメモリであれば良く、ＨＤＤ（ハードディスク）３０やフラッシュＲＯＭなどに配置してもよい。
【０２２２】
次に「クライアントがサポートする暗号スイートの優先順位情報」であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてＨＤＤ（ハードディスク）３０を利用しているが、フラッシュＲＯＭなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。「クライアントがサポートする暗号スイートの優先順位情報」を一時的な記憶メモリであるＲＡＭ２０に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。
【０２２３】
なお、「クライアントがサポートする暗号スイートの優先順位情報」が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるＲＯＭ４０などに配置してもよい。
【０２２４】
「クライアントがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント１の機能ブロック図には、「クライアントがサポートする暗号スイート」を示していないが、サーバ２の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、「クライアントがサポートする暗号スイート」をＲＯＭ４０に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、ＲＡＭ２０のような揮発性メモリに配置することも可能である。
【０２２５】
ＭＡＣ／ＰＨＹ５０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
【０２２６】
次にサーバ２のハード構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、及びＲＡＭ２１で実行される。
【０２２７】
「サーバがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、「サーバがサポートする暗号スイート」をＲＯＭ４１に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、ＲＡＭ２１のような揮発性メモリに配置することも可能である。
【０２２８】
ＭＡＣ／ＰＨＹ５１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置２００を実現するものである。
【０２２９】
図１３は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第２例を示すシーケンス図である。
【０２３０】
（Ｓ１３−（Ｓ１））クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、クライアントがサポートする暗号スイートの内、以下の暗号スイートをサーバがサポートすることを知る。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（Ｓ１３−（Ｓ２））クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当しないものは選択せず、該当するものが出現するまで優先順位を下げる。
【０２３１】
クライアントの優先順位１、２の暗号スイートは、上記暗号スイートに該当しないので選択されない。クライアントは下記に記述する、優先順位３の暗号スイートを選択する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
なお図１で説明したように、同じ優先順位の暗号スイートは１つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで１つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するＣｌｉｅｎｔ  Ｈｅｌｌｏを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは１つしかないものとする。
【０２３２】
（Ｓ１３−（Ｓ３））クライアントがこの選択した暗号スイートを指定して、サーバにＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（４）サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにＳｅｒｖｅｒ  Ｈｅｌｌｏを送信する。図示していないが、この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０２３３】
図１４は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第４例を示すシーケンス図であり、図１３の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の一例を示すシーケンス図でもある。図８とほぼ同じシーケンスである。これも「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズを明確に分離するものである。
【０２３４】
図８では、クライアントがサポートする暗号スイート内、サーバがサポートしない暗号スイートを調査しているが、図１４では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるものの「クライアントがサポートする暗号スイートの優先順位情報」が変更になった場合に、再度調査する必要がなくなる。例えば、クライアント装置でユーザが「クライアントがサポートする暗号スイートの優先順位情報」を変更する場合に都合がよい。
【０２３５】
また、「クライアントがサポートする暗号スイートの優先順位情報」が複数ある場合にも、図１４の手法が適している。例えば、同じサーバに接続する場合であっても、認証にはより強力な処理の重い暗号スイートを優先し、通常の通信にはパフォーマンスのよい軽い暗号スイートを優先させたい場合がある。このような場合でも、クライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを一度調査すれば、それぞれの場合で、選択すべき暗号スイートが分かるので手間が省けてよい。
【０２３６】
なお、ここではクライアントがサポートするすべての暗号スイートをサーバがサポートするか否かを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で暗号スイートの優先順位付けをする場合に、どのような場合であっても利用されない暗号スイートがある場合は、これを除外するのは合理的である。またどのような場合であっても、優先順位が高い暗号スイートがあり、接続するサーバがこの暗号スイートを必ずサポートする場合は、この暗号スイートより優先順位が高い暗号スイートだけを調査すればよい。
【０２３７】
次に図１４の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを１つ指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその暗号スイートを保持していないと判断する。
【０２３８】
（図１４−（Ｓ１））クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位１の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１４−（Ｓ２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバがＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（Ｓ１３−（Ｓ３））そして通信を切断する。
【０２３９】
（図１４−（Ｓ４））次にクライアントは、優先順位２の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１４−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（Ｓ１３−（Ｓ６）)そして通信を切断する。
【０２４０】
（Ｓ１３−（Ｓ７））次にクライアントは、優先順位３の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
【０２４１】
（Ｓ１３−（Ｓ８））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。
【０２４２】
（Ｓ１３−（Ｓ９）)そして通信を切断する。
【０２４３】
（Ｓ１３−（Ｓ１０））次にクライアントは、優先順位４の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
【０２４４】
（Ｓ１３−（Ｓ１１））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。
【０２４５】
（Ｓ１３−（Ｓ１２））そして通信を切断する。
【０２４６】
以上の手順によって、クライアントは、自らがサポートする暗号スイートの内、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサーバがサポートするという「サーバとクライアントが共にサポートする暗号スイートの情報」を少なくとも記憶する。
【０２４７】
なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。
【０２４８】
なお、図２、図７、図８と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【０２４９】
またクライアントは、「サーバとクライアントが共にサポートする暗号スイートの情報」を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、「サーバとクライアントが共にサポートする暗号スイートの情報」を利用して、直ちに、次の（Ｓ１３−（Ｓ１３）)の処理に進むことが可能となる。
【０２５０】
（Ｓ１３−（Ｓ１３））次に、クライアントはサーバと実際にＳＳＬ／ＴＬＳ暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０２５１】
（Ｓ１３−（Ｓ１４）)そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（Ｓ１３−（Ｓ１５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０２５２】
図１５は、本発明の実施の形態における機能ブロックの第３例を示す図であり、図１４の機能ブロック図の一例でもある。また図１６は、本発明の実施の形態におけるクライアント側のフローチャートの第３例を示す図であり、図１５のクライアント１のフローチャートでもある。なお、図１５のサーバ２のフローチャートは図１１と同様である。次にこの図１５、図１６、図１１を用いて説明を行う。
【０２５３】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１は「クライアントがサポートする暗号スイートの優先順位情報」で、利用したい暗号スイートの優先順位付けを行っており、搭載情報８００（搭載状況記憶手段）で、その各々の暗号スイートに対して、サーバ２でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。またここでは、搭載情報８００（搭載状況記憶手段）は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。
【０２５４】
また、クライアント１には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す「現在のカウンタ」７１０が設けてある。「現在のカウンタ」７１０には暗号スイートの優先順位の番号を入力するようになっており、クライアント１は、「現在のカウンタ」７１０に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。
【０２５５】
「現在のカウンタ」７１０に０が代入された場合には、クライアント１はサーバの暗号スイートの搭載状況を調査せず、通常のＳＳＬ／ＴＬＳネゴシエーションを行い、ＳＳＬ／ＴＬＳ暗号通信を行うようになっている。なおここでは、「現在のカウンタ」７１０の初期値は１とする。
【０２５６】
（図１６−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。はじめは、「現在のカウンタ」７１０の値が１なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」という情報が読み出される。
【０２５７】
（図１６−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０２５８】
（図１６−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０２５９】
（図１６−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０２６０】
（図１１−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０２６１】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０２６２】
（図１１−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【０２６３】
（図１１−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【０２６４】
（図１１−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージの受信待ち状態になる。
【０２６５】
（図１６−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０２６６】
（図１６−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージなので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０２６７】
（図１６−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０２６８】
（図１６−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は２なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１６−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が２なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」という情報が読み出される。
【０２６９】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０２７０】
（図１６−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０２７１】
（図１６−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は３なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１６−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が３なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。
【０２７２】
（図１６−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０２７３】
（図１６−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０２７４】
（図１６−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０２７５】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０２７６】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０２７７】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０２７８】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０２７９】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０２８０】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０２８１】
（図１６−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０２８２】
（図１６−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０２８３】
（図１６−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。
【０２８４】
（図１６−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０２８５】
（図１６−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は４なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１１−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０２８６】
（図１６−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が４なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。
【０２８７】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートするので、（図１０−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。
【０２８８】
（図１６−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０２８９】
（図１６−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。
【０２９０】
（図１６−（Ｓ９））ここで「現在のカウンタ」７１０の値は５なので、（つまり、上記等式が成り立つので）Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０に０を設定し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す（つまり（Ａ）に進む）。
（図１６−（Ｓ１０））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、「現在のカウンタ」７１０が０の場合、搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。具体的には以下のように選定する。（１）Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位１の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」がサポートされていないことを知る。（２）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位２の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」がサポートされていないことを知る。（３）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位３の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」がサポートされていることを知る。そこで、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択する。
【０２９１】
なおここでは、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、最後にチェックされている暗号スイートを選択するとしてもよい。このように、搭載情報８００（搭載状況記憶手段）から暗号スイートの選択方法する方法は様々な手段が存在する。
【０２９２】
（図１６−（Ｓ１１））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０２９３】
（図１６−（Ｓ１２））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０２９４】
（図１６−（Ｓ１３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０２９５】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０２９６】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０２９７】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０２９８】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０２９９】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０３００】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０３０１】
（図１６−（Ｓ１３））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０３０２】
（図１６−（Ｓ１４））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０が０の場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０３０３】
（図１６−（Ｓ１５））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０３０４】
（図１６−（Ｓ１６））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０３０５】
（図１６−（Ｓ１７））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる
（図１１−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０３０６】
（図１１−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０３０７】
（図１１−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０３０８】
機能ブロック図には図示していないが、この後は、サーバ２は作成した共通鍵を使ってクライアント１と暗号通信を行う。なお、暗号通信とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０３０９】
（図１６−（Ｓ１７））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０３１０】
（図１６−（Ｓ１８））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０３１１】
機能ブロック図には図示していないが、この後は、クライアント１は作成した共通鍵を使ってサーバ２と暗号通信を行う。
【０３１２】
なお、図１２は、図９と同様、図１５のハードウェア構成図の一例を示している。説明は同じなので割愛する。
【０３１３】
図１７は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第３例を示すシーケンス図である。
【０３１４】
（図１７−（Ｓ１））クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートが以下であることを知る。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
（図１７−（Ｓ２））クライアントは、暗号スイートの選択において、上記暗号スイートを選択する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
なお図１で説明したように、同じ優先順位の暗号スイートは１つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで１つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するＣｌｉｅｎｔ  Ｈｅｌｌｏを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは１つしかないものとする。
【０３１５】
（図１７−（Ｓ３））クライアントがこの選択した暗号スイートを指定して、サーバにＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１７−（Ｓ４））サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにＳｅｒｖｅｒ  Ｈｅｌｌｏを送信する。図示していないが、この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０３１６】
図１８は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第５例を示すシーケンス図であり、図１７の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の一例を示すシーケンス図である。図８や図１４とほぼ同じシーケンスでもある。これも「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズを明確に分離するものである。
【０３１７】
図１４では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査しているが、図１８では、サーバがサポートする暗号スイート内、クライアントで最も優先順位の高い暗号スイートを調査している。すべての暗号スイートを調査しないので、調査時間が短縮できる。
【０３１８】
次に図１８の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを１つ指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその暗号スイートを保持していないと判断する。
【０３１９】
（図１８−（Ｓ１））クライアントは自らが保持する暗号スイートの優先順位情報を見て、優先順位１の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１８−（Ｓ２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバがＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないことを知る。（図１８−（Ｓ３））そして通信を切断する。
【０３２０】
（図１８−（Ｓ４））次にクライアントは、優先順位２の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１８−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。（図１８−（Ｓ６））そして通信を切断する。
【０３２１】
（図１８−（Ｓ７））次にクライアントは、優先順位３の暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
【０３２２】
（図１８−（Ｓ８））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。そして、この暗号スイートを、「サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートの情報」として記憶しておく。
【０３２３】
（図１８−（Ｓ９））そして通信を切断する。
【０３２４】
なお、ここでは説明を簡単に行うため、優先順位の高い順に暗号スイートを調査するように説明しているが、実際はどのような順番で調査しても構わない。例えば、優先順位の低い方から調査する場合は、サーバがアラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返送するまで調べ、直前のＳｅｒｖｅｒ  Ｈｅｌｌｏを返した暗号スイートを記憶すればよい。
【０３２５】
なお、図２、図７、図８、図１４と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【０３２６】
またクライアントは、「サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートの情報」を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、「サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートの情報」を利用して、直ちに、次の（図１８−（Ｓ１３））の処理に進むことが可能となる。
【０３２７】
（図１８−（Ｓ１０））次に、クライアントはサーバと実際にＳＳＬ／ＴＬＳ暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０３２８】
（図１８−（Ｓ１１））そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図１８−（Ｓ１２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０３２９】
図１９は、本発明の実施の形態における機能ブロックの第４例を示す図の一例であり、図１８の機能ブロック図の一例でもある。また図２０は、本発明の実施の形態におけるクライアント側のフローチャートの第４例を示す図であり、図１９のクライアント１のフローチャートでもある。なお、図１９のサーバ２のフローチャートは図１１と同様である。次にこの図１９、図２０、図１１を用いて説明を行う。
【０３３０】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１は「クライアントがサポートする暗号スイートの優先順位情報」で、利用したい暗号スイートの優先順位付けを行っており、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートを、搭載情報８００（搭載状況記憶手段）で記憶する仕組みになっている。ここでは、搭載情報８００（搭載状況記憶手段）はクライアントがサポートする各々の暗号スイートに対応する記憶領域であり、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートをチェックする仕組みとして説明しているが、この記憶手段はこれに限られるものではない。搭載情報８００（搭載状況記憶手段）は、サーバがサポートする暗号スイートの中で、クライアントの優先順位が最も高い暗号スイートの番号を、単に記憶するものであっても良く、その記憶手段は様々である。
【０３３１】
また、クライアント１には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す「現在のカウンタ」７１０が設けてある。「現在のカウンタ」７１０には暗号スイートの優先順位の番号を入力するようになっており、クライアント１は、「現在のカウンタ」７１０に設定された番号を優先順位とする暗号スイートを調査する仕組みとなっている。
【０３３２】
「現在のカウンタ」７１０に０が代入された場合には、クライアント１はサーバの暗号スイートの搭載状況を調査せず、通常のＳＳＬ／ＴＬＳネゴシエーションを行い、ＳＳＬ／ＴＬＳ暗号通信を行うようになっている。なおここでは、「現在のカウンタ」７１０の初期値は１とする。
【０３３３】
（図２０−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。はじめは、「現在のカウンタ」７１０の値が１なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」という情報が読み出される。
【０３３４】
（図２０−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０３３５】
（図２０−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０３３６】
（図２０−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０３３７】
（図１１−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０３３８】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０３３９】
（図１１−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【０３４０】
（図１１−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【０３４１】
（図１１−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージの受信待ち状態になる。
【０３４２】
（図２０−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０３４３】
（図２０−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージなので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０３４４】
（図２０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０３４５】
（図２０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は２なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図２０−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が２なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」という情報が読み出される。
【０３４６】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０３４７】
（図２０−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０３４８】
（図２０−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、暗号スイートの優先順位の数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ（この図では４） ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は３なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図２０−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイートの優先順位情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値が３なので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」という情報が読み出される。
【０３４９】
（図２０−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０３５０】
（図２０−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０３５１】
（図２０−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０３５２】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０３５３】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０３５４】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０３５５】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０３５６】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０３５７】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０３５８】
（図２０−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０３５９】
（図２０−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０３６０】
（図２０−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。なおこれが、サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートということになる。そして、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断する。
【０３６１】
（図１１−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０３６２】
（図２０−（Ｓ９））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０に０を設定し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す（つまり（Ａ）に進む）。
（図２０−（Ｓ１０））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、「現在のカウンタ」７１０が０の場合、搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。搭載情報８００（搭載状況記憶手段）にチェックされている暗号スイートは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」なので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択する。
【０３６３】
（図２０−（Ｓ１１））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０３６４】
（図２０−（Ｓ１２））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０３６５】
（図２０−（Ｓ１３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０３６６】
（図１１−（Ｓ１１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０３６７】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０３６８】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０３６９】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０３７０】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０３７１】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０３７２】
（図２０−（Ｓ１３））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０３７３】
（図２０−（Ｓ１４））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０が０の場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０３７４】
（図２０−（Ｓ１５））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０３７５】
（図２０−（Ｓ１６））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０３７６】
（図２０−（Ｓ１７））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる
（図１１−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０３７７】
（図１１−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０３７８】
（図１１−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０３７９】
機能ブロック図には図示していないが、この後は、サーバ２は作成した共通鍵を使ってクライアント１と暗号通信を行う。なお、暗号通信とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０３８０】
（図２０−（Ｓ１７））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０３８１】
（図２０−（Ｓ１８））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０３８２】
機能ブロック図には図示していないが、この後は、クライアント１は作成した共通鍵を使ってサーバ２と暗号通信を行う。
【０３８３】
なお、図１２は、図９、図１５と同様、図１９のハードウェア構成図の一例を示している。説明は同じなので割愛する。
【０３８４】
図２１は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第４例を示すシーケンス図である。
【０３８５】
（図２１−（Ｓ１））クライアントは、サーバがサポートする暗号スイートの搭載状況を調査することで、サーバが以下の暗号スイートをサーバがサポートすることを知る。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２１−（Ｓ２））クライアントは、暗号スイートの選択において、自らが保持する暗号スイートの内、優先順位の高い暗号スイートを選択しようとするが、その際、上記暗号スイートに該当しないものは選択せず、該当するものが出現するまで優先順位を下げる。
【０３８６】
クライアントの優先順位１、２の暗号スイートは、上記暗号スイートに該当しないので選択されない。クライアントは下記に記述する、優先順位３の暗号スイートを選択する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
なお図１で説明したように、同じ優先順位の暗号スイートは１つしかないケースで説明を行っているが、本図を含めてすべての図で、同じ優先順位の暗号スイートはいくつあっても構わない。サーバがサポートする同じ優先順位の暗号スイートが複数あれば、好みで１つに絞ってもよいし、複数、またはすべての暗号スイートを選択してもよい。複数の暗号スイートを選択する場合は、複数の暗号スイートを指定するＣｌｉｅｎｔ  Ｈｅｌｌｏを送信することになる。説明を簡単にするために、ここでは、同じ優先順位の暗号スイートは１つしかないものとする。
【０３８７】
（図２１−（Ｓ３））クライアントがこの選択した暗号スイートを指定して、サーバにＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２１−（Ｓ４））サーバはこの指定された暗号スイートを保持するので、この指定された暗号スイートでクライアントにＳｅｒｖｅｒ  Ｈｅｌｌｏを送信する。図示していないが、この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０３８８】
図２２は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第６例を示すシーケンス図であり、図２１の「サーバがサポートする暗号スイートの搭載状況を調査する」方法の一例を示すシーケンス図でもある。図８、図１４、図１８とほぼ同じシーケンスである。これも「サーバの暗号スイートの搭載情報を調査する」フェーズと「利用する暗号スイートを選択する」フェーズを明確に分離するものである。
【０３８９】
図１４では、クライアントがサポートする暗号スイート内、サーバがサポートする暗号スイートを調査しているが、図２２では、クライアントがサポートする暗号スイートに関係なく、サーバがサポートする暗号スイートを調査している。すべての暗号スイートを調査すると、時間を要する欠点はあるものの、クライアントがサポートする暗号スイートが追加された場合に、再度調査する必要がなくなる。例えば、クライアント装置がソフトウェアダウンロードなどで暗号スイートを追加できる仕組みがある場合に都合がよい。
【０３９０】
なお、ここではサーバがサポートするすべての暗号スイートを調査するとしているが、一部の暗号スイートを調査するとしてもよい。クライアント装置で将来に渡って絶対に利用しない暗号スイートが明らかである場合は、このような暗号スイートを除外するのは合理的である。例えば、現在、セキュリティ的に弱くて利用できない暗号スイートなどは除外した方が好ましい。
【０３９１】
なお、これまでの説明で分かるように、サーバがサポートする暗号スイートを調査するのを、逆にサーバがサポートしない暗号スイートを調査することに置き換えてもよい。これは同じことになるので、詳細の説明は割愛する。
【０３９２】
次に図２２の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、暗号スイートを１つ指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその暗号スイートを保持していないと判断する。
【０３９３】
また、クライアントは「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を保持している。この情報は、基本的にはＳＳＬ／ＴＬＳ仕様で定義されているすべて暗号スイートの情報であるが、先に説明したように、将来に渡ってクライアントが使用しないと分かっている暗号スイートは除去してもよい。
【０３９４】
（図２２−（Ｓ１））クライアントは「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を見て、それに掲載されている暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２２−（Ｓ２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバがＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（図２２−（Ｓ３））そして通信を切断する。
【０３９５】
（図２２−（Ｓ４））次にクライアントは、「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を見て、それに掲載されている暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２２−（Ｓ５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。なお、この暗号スイートはサポートされていないものとして記憶しておいてもよいが、ここの説明では記憶しないものとする。（図２２−（Ｓ６））そして通信を切断する。
【０３９６】
（図２２−（Ｓ７））次にクライアントは、「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を見て、それに掲載されている暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２２−（Ｓ８））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。なお、この暗号スイートはサポートされているものとして記憶しておく。（図２２−（Ｓ９））そして通信を切断する。
【０３９７】
このようにして、クライアントは、「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を見て、それに掲載されている暗号スイートをサーバが搭載しているか否かを順々に、調査する。
【０３９８】
以上の手順によって、クライアントは、サーバが、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサーバがサポートするという「サーバがサポートする暗号スイートの情報」を少なくとも記憶する。
【０３９９】
なお、ここでは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」、・・・という順番で調査しているが、実際はどのような順番で調査しても構わない。
【０４００】
なお、図２、図７、図８、図１４、図１８と同様に、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【０４０１】
またクライアントは、「サーバがサポートする暗号スイートの情報」を記憶しておけば、次回からはサーバの暗号スイートの搭載情報を調査せずとも、「サーバがサポートする暗号スイートの情報」を利用して、直ちに、次の（図２２−（Ｓ１０））の処理に進むことが可能となる。
【０４０２】
（図２２−（Ｓ１０））次に、クライアントはサーバと実際にＳＳＬ／ＴＬＳ暗号通信を行うため、利用する暗号スイートの選択を行う。サーバがサポートする暗号スイートの内、クライアントで最も優先順位の高い暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０４０３】
（図２２−（Ｓ１１））そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２２−（Ｓ１２））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。
【０４０４】
図２３は、本発明の実施の形態における機能ブロックの第５例を示す図であり、図２２の機能ブロック図の一例でもある。また図２４は、本発明の実施の形態におけるクライアント側のフローチャートの第５例を示す図であり、図２３のクライアント１のフローチャートである。なお、図２３のサーバ２のフローチャートは図１１と同様である。次にこの図２３、図２４、図１１を用いて説明を行う。
【０４０５】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１は「クライアントがサポートする暗号スイートの優先順位情報」で、利用したい暗号スイートの優先順位付けを行っており、搭載情報８００（搭載状況記憶手段）で、その各々の暗号スイートに対して、サーバ２でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。
【０４０６】
また、クライアントはサーバがサポートする暗号スイートを調査するのに、先に説明した「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」を保持している。この情報は、基本的にはＳＳＬ／ＴＬＳ仕様で定義されているすべて暗号スイートの情報であるが、先に説明したように、将来に渡ってクライアントが使用しないと分かっている暗号スイートは除去してもよい。ここでは、搭載情報８００（搭載状況記憶手段）は、「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」に掲載されている各々の暗号スイートが、サポートされているか否かを記憶する仕組みとしている。なお、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。
【０４０７】
また、クライアント１には、サーバの暗号スイートの搭載状況を調査するにあたって、どの暗号スイートを調査するかを示す「現在のカウンタ」７１０が設けてある。「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」には、暗号スイートの情報だけでなく、その各々の暗号スイートを調査する順番も定義されており、「現在のカウンタ」７１０に、この順番を入力すれば、クライアント１は、その順番の暗号スイートを調査する仕組みとなっている。
【０４０８】
「現在のカウンタ」７１０に０が代入された場合には、クライアント１はサーバの暗号スイートの搭載状況を調査せず、通常のＳＳＬ／ＴＬＳネゴシエーションを行い、ＳＳＬ／ＴＬＳ暗号通信を行うようになっている。なおここでは、「現在のカウンタ」７１０の初期値は１とする。
【０４０９】
（図２４−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。はじめは、「現在のカウンタ」７１０の値が１であるが、これが「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」では「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」に該当するものとして説明する。
【０４１０】
（図２４−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０４１１】
（図２４−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０４１２】
（図２４−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０４１３】
（図１１−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０４１４】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０４１５】
（図１１−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【０４１６】
（図１１−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【０４１７】
（図１１−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージの受信待ち状態になる。
【０４１８】
（図２４−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０４１９】
（図２４−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージなので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０４２０】
（図２４−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０４２１】
（図２４−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、調査する暗号スイートの数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は２なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図２４−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値は２であるが、これが「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」では「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」に該当するものとして説明する。
【０４２２】
この後は、クライアント１、サーバ２共、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」の場合と同様のフローとなる。サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０４２３】
（図２４−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０４２４】
（図２４−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、調査する暗号スイートの数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は３なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図２４−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。「現在のカウンタ」７１０の値は３であるが、これが「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」では「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」に該当するものとして説明する。
【０４２５】
（図２４−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０４２６】
（図２４−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０４２７】
（図２４−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０４２８】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０４２９】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０４３０】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０４３１】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０４３２】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０４３３】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０４３４】
（図２４−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０４３５】
（図１６−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０４３６】
（図２４−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。
【０４３７】
（図２４−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、「現在のカウンタ」７１０に１を加算する。
【０４３８】
（図２４−（Ｓ８））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０の値が、調査する暗号スイートの数＝ＭＡＸ値を超えているか、つまり、
「現在のカウンタ」７１０の値 ＝ ＭＡＸ ＋ １
か否かをチェックする。ここで「現在のカウンタ」７１０の値は４なので、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０には何も処理せずに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図１１−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０４３９】
（図２４−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」と「現在のカウンタ」７１０から暗号スイートの情報を読み出す。
このような手順でクライアント１は「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」に掲載されている暗号スイートを順々に調査していく。そして、すべての調査を終了した時点で、（図２４−（Ｓ９））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０に０を設定し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す（つまり（Ａ）に進む）。
調査を終了した時点で、クライント１は、サーバ２が以下の暗号スイートをサポートしていることを、搭載情報８００（搭載状況記憶手段）にチェックしている。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２４−（Ｓ１０））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、「現在のカウンタ」７１０が０の場合、搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。具体的には以下のように選定する。（１）Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位１の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」がサポートされていないことを知る。（２）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位２の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」がサポートされていないことを知る。（３）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位３の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」がサポートされていることを知る。そこで、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択する。
【０４４０】
なおここでは、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）の情報を優先順位の高い方から選択するとして説明したが、暗号スイートの選択方法はこれに限られるものではない。逆に優先順位の低い方から順番に見て、最後にチェックされている暗号スイートを選択するとしてもよい。このように、搭載情報８００（搭載状況記憶手段）から暗号スイートの選択方法する方法は様々な手段が存在する。
【０４４１】
（図２４−（Ｓ１１））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０４４２】
（図２４−（Ｓ１２））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０４４３】
（図２４−（Ｓ１３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０４４４】
（図１１−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０４４５】
（図１１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０４４６】
（図１１−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０４４７】
（図１１−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０４４８】
（図１１−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０４４９】
（図１１−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０４５０】
（図２４−（Ｓ１３））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０４５１】
（図２４−（Ｓ１４））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、「現在のカウンタ」７１０が０の場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０４５２】
（図２４−（Ｓ１５））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０４５３】
（図２４−（Ｓ１６））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０４５４】
（図２４−（Ｓ１７））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる
（図１１−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０４５５】
（図１１−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０４５６】
（図１１−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０４５７】
機能ブロック図には図示していないが、この後は、サーバ２は作成した共通鍵を使ってクライアント１と暗号通信を行う。なお、暗号通信とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０４５８】
（図２４−（Ｓ１７））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０４５９】
（図２４−（Ｓ１８））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０４６０】
機能ブロック図には図示していないが、この後は、クライアント１は作成した共通鍵を使ってサーバ２と暗号通信を行う。
【０４６１】
図２５は、本発明の実施の形態におけるハードウェア構成の第３例を示す図であり、図２３のハードウェア構成図の一例でもある。クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、書き換え可能な不揮発性メモリであるＨＤＤ（ハードディスク）３０、書き換え不可の不揮発性メモリであるＲＯＭ４０とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５０で構成されている。一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ４１とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５１で構成されている。また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ５０とＭＡＣ／ＰＨＹ５１を介してネットワークで接続されている。
【０４６２】
はじめにクライアント１のハード構成に関して説明を行う。図２３に示したクライアント１の各処理部は、ＣＰＵ１０、及びＲＡＭ２０で実行される。
【０４６３】
「現在のカウンタ」７１０、及び搭載情報８００（搭載状況記憶手段）は、一時的な記憶メモリであるＲＡＭ２０に配置しているが、書き換え可能なメモリであれば良く、ＨＤＤ（ハードディスク）３０やフラッシュＲＯＭなどに配置してもよい。
【０４６４】
次に「クライアントがサポートする暗号スイートの優先順位情報」であるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてＨＤＤ（ハードディスク）３０を利用しているが、フラッシュＲＯＭなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。「クライアントがサポートする暗号スイートの優先順位情報」を一時的な記憶メモリであるＲＡＭ２０に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。
【０４６５】
なお、「クライアントがサポートする暗号スイートの優先順位情報」が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるＲＯＭ４０などに配置してもよい。
【０４６６】
「クライアントがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント１の機能ブロック図には、「クライアントがサポートする暗号スイート」を示していないが、サーバ２の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、「クライアントがサポートする暗号スイート」をＲＯＭ４０に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、ＲＡＭ２０のような揮発性メモリに配置することも可能である。
【０４６７】
次に「ＳＳＬ／ＴＬＳ仕様で定義されている暗号スイートの情報」であるが、基本的には書き換えしないものなので、ＲＯＭ４０など不揮発性メモリに配置するのがよい。しかし、長期間に渡り利用される機器などでは、その間に、セキュリティレベルが下がった暗号スイートを除外したい場合も出てくるので、ＨＤＤ３０やＲＡＭ２０など、書き換え可能なメモリに配置した方がよいケースもある。
【０４６８】
ＭＡＣ／ＰＨＹ５０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
【０４６９】
次にサーバ２のハード構成に関して説明を行う。図２３に示したサーバ２の各処理部は、ＣＰＵ１１、及びＲＡＭ２１で実行される。
【０４７０】
「サーバがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、「サーバがサポートする暗号スイート」をＲＯＭ４１に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、ＲＡＭ２１のような揮発性メモリに配置することも可能である。
【０４７１】
ＭＡＣ／ＰＨＹ５１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置２００を実現するものである。
【０４７２】
図２６は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第７例を示すシーケンス図であり、図８で示した「サーバがサポートする暗号スイートの搭載状況を調査する」方法の別の一例を示すシーケンス図でもある。図２６では図８と同様に、クライアントがサポートする暗号スイートの内、サーバがサポートしない暗号スイートを調査している。
【０４７３】
しかし図２６では図８と異なり、サーバがサポートする暗号スイートの調査するのに、暗号スイートを１つ１つ調査することはせず、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで複数の暗号スイートを提示する手段を用いている。
【０４７４】
次に図２６の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。
【０４７５】
（図２６−（Ｓ１））クライアントは自らがサポートするすべての暗号スイートを指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２６−（Ｓ２））暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。ここでは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択したものとして説明を行う。サーバは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定した、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。
【０４７６】
クライアントは、このＳｅｒｖｅｒ  Ｈｅｌｌｏにより、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。ここではこれを記憶するように図示していないが、これを記憶しておいてもよい。（図２６−（Ｓ３））そして通信を切断する。
【０４７７】
（図２６−（Ｓ４））次にクライアントは、最初にサーバに指定した暗号スイートから、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を除外した、以下の暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２６−（Ｓ５））サーバは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定した、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。
【０４７８】
クライアントは、このＳｅｒｖｅｒ  Ｈｅｌｌｏにより、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。ここではこれを記憶するように図示していないが、これを記憶しておいてもよい。（図２６−（Ｓ６））そして通信を切断する。
【０４７９】
（図２６−（Ｓ７））次にクライアントは、２番目にサーバに指定した暗号スイートから、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を除外した、以下の暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
（図２６−（Ｓ８））サーバは、上記暗号スイートをサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。クライアントは、この暗号スイートはサポートされていないものとして記憶する。（図２６−（Ｓ９））そして通信を切断する。
【０４８０】
後の手順は図８と同様である。この図２６と図８を比較して分かるように、サーバの暗号スイートの搭載状況を調査するのに、図２６の方が、工数が少ない。これにより迅速な調査が可能となる。
【０４８１】
この方法によれば、暗号スイートの優先順位を自ら決めるサーバの場合に対して、そのサーバで決められている優先順位を知ることも可能となる。
【０４８２】
図２７は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第８例を示すシーケンス図であり、図１８で示した「サーバがサポートする暗号スイートの搭載状況を調査する」方法の別の一例を示すシーケンス図でもある。図２７では図１８と同様に、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートを調査している。
【０４８３】
しかし図２７では図１８と異なり、サーバがサポートする暗号スイートの調査するのに、暗号スイートを１つ１つ調査することはせず、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで複数の暗号スイートを提示する手段を用いている。
【０４８４】
次に図２７の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。
【０４８５】
（図２７−（Ｓ１））クライアントは自らがサポートするすべての暗号スイートを指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２７−（Ｓ２））暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。ここでは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択したものとして説明を行う。サーバは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定した、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。
【０４８６】
クライアントは、このＳｅｒｖｅｒ  Ｈｅｌｌｏにより、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。クライアントは、これは記憶しておく。（図２７−（Ｓ３））そして通信を切断する。
【０４８７】
（図２７−（Ｓ４））次にクライアントは、最初にサーバに指定した暗号スイートから、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と、これより優先順位の低いすべての暗号スイートを除外したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
【０４８８】
「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」より優先順位の低い暗号スイートは、この例では、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」の１つだけである。従って、この例では、以下の暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
（図２７−（Ｓ５））サーバは、上記暗号スイートをサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。これによって、クライアントは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」が、サーバがサポートする暗号スイートの中でクライアントの優先順位が最も高い暗号スイートであることを知る。（図２７−（Ｓ９））そして通信を切断する。
【０４８９】
なお、この例では「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」の後は、サーバはアラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す例になっているが、例えば、サーバがこの後に「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」でＳｅｒｖｅｒ  Ｈｅｌｌｏを返信してくるケースでは、クライアントは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」に代えて、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」を記憶することになる。
【０４９０】
後の手順は図１８と同様である。この図２７と図１８を比較して分かるように、サーバの暗号スイートの搭載状況を調査するのに、図２６の方が、工数が少ない。これにより迅速な調査が可能となる。
【０４９１】
なお、図２６、図２７の手順は、図８、図１８の別の調査方法を例示したものであるが、この手順は、他の図でも応用可能である。
【０４９２】
図２８は、本発明の実施の形態における「サーバがサポートする暗号スイートの搭載状況を調査する」方法の第９例を示すシーケンス図であり、図８で示した「サーバがサポートする暗号スイートの搭載状況を調査する」方法の別の一例を示すシーケンス図でもある。図２８では図８と同様に、クライアントがサポートする暗号スイートの内、サーバがサポートしない暗号スイートを調査している。
【０４９３】
しかし図２８では図８と異なり、サーバがサポートする暗号スイートの調査するのに利用するＴＣＰポート番号と、実際にＳＳＬ／ＴＬＳ暗号通信を行うＴＣＰポート番号が異なる。
【０４９４】
図２８では、クライアント側はアプリ（アプリケーション）とＳＳＬ（ＳＳＬ／ＴＬＳ）モジュール／ＳＳＬ（ＳＳＬ／ＴＬＳ）タスクで構成されている。図２８のように、利用するＴＣＰポート番号と、実際にＳＳＬ／ＴＬＳ暗号通信を行うＴＣＰポート番号を分ければ、アプリ側がＳＳＬ／ＴＬＳ暗号通信に指定したＴＣＰポート番号を、サーバがサポートする暗号スイートの調査に利用しなくて済むようになる。
【０４９５】
アプリ側がＳＳＬ／ＴＬＳ暗号通信に指定したＴＣＰポート番号を、サーバがサポートする暗号スイートの調査に利用すれば、通信切断の度に、アプリ側で再度ＴＣＰポート番号を取得しなくてはならなくなり、プログラミングを難しくしてしまう。図２８のように、サーバがサポートする暗号スイートの調査に利用するＴＣＰポート番号を、ＳＳＬ（ＳＳＬ／ＴＬＳ）モジュール／ＳＳＬ（ＳＳＬ／ＴＬＳ）タスクが別に用意するようにすれば、アプリ側がＳＳＬ／ＴＬＳ暗号通信に指定したＴＣＰポート番号は切断されることがなくなり、アプリ側から見た場合に、プログラミングが非常に簡単になる。
【０４９６】
なお、サーバがサポートする暗号スイートの調査に利用するＴＣＰポート番号と実際にＳＳＬ／ＴＬＳ暗号通信を行うＴＣＰポート番号が異なることを除けば、手順は図８と同じなので、詳細の説明は割愛する。
【０４９７】
なお、この手順は他の図でも応用可能である。
【０４９８】
図２９は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第５例を示すシーケンス図である。図２９は図１４と同様に、サーバとクライアントが共にサポートする暗号スイートを調査している。但し、その調査方法は図２６、図２７と同様の手法を利用している。図１４と全く同じ手法を利用してもよいが、図２６、図２７の説明で、機能ブロック図やフローチャートの説明を省いたので、これらの説明を兼ねるため、本質的な問題ではないが、あえてここでは、この手法を利用する。
【０４９９】
また図２９では、実際のＳＳＬ／ＴＬＳ暗号通信で、暗号スイートの切り替えを行っている。この図の本質はここにある。はじめ、認証を行うために、クライアントは自らがサポートする暗号スイートの内、最もセキュリティレベルの高い暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択し、利用している。
【０５００】
そして、通信用（普通の通信データの受け渡し）には、クライアントは自らがサポートする暗号スイートの内、最も高速処理可能な暗号スイートである「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」を選択し、利用している。
【０５０１】
たとえ、相手が利用する暗号スイートの優先順位付けを行うサーバであっても、本発明に従えば、このように目的に応じて、クライアントが主導的に暗号スイートを選択できるメリットがある。特に、脆弱なＣＰＵを搭載しているような組込み機器がクライアントの場合にこの効果は大きい。このような組込み機器の場合でもセキュリティとパフォーマンスを両立することが可能である。
【０５０２】
次に図２９の詳細な説明を行う。ここでは、クライアントはサーバの暗号スイートの搭載状況を調査するのに、クライアントがサポートする複数の暗号スイート指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信している。アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）が返ってくれば、サーバはその複数の暗号スイートを保持していないと判断する。
【０５０３】
（図２９−（Ｓ１））クライアントは自らがサポートするすべての暗号スイートを指定してＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。なおここではすべての暗号スイートを指定しているが、一部の暗号スイートであってもよい。ここでは下記の暗号スイートを指定したものとして説明を行う。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２９−（Ｓ２））暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。ここでは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択したものとして説明を行う。サーバは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定した、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。
【０５０４】
クライアントは、このＳｅｒｖｅｒ  Ｈｅｌｌｏにより、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。クライアントはこれを記憶する。（図２９−（Ｓ３））そして通信を切断する。
【０５０５】
（図２９−（Ｓ４））次にクライアントは、最初にサーバに指定した暗号スイートから、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を除外した、以下の暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図２９−（Ｓ５））サーバは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定した、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。
【０５０６】
クライアントは、このＳｅｒｖｅｒ  Ｈｅｌｌｏにより、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。クライアントはこれを記憶する。（図２９（Ｓ６））そして通信を切断する。
【０５０７】
（図２９−（Ｓ７））次にクライアントは、２番目にサーバに指定した暗号スイートから、この「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を除外した、以下の暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
（図２９−（Ｓ８））サーバは、上記暗号スイートをサポートしていないので、アラート（ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅ）を返す。これによってクライアントは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」をサポートしていないことを知る。クライアントは、この暗号スイートはサポートされていないものとして記憶してもよい。ここまでの手順で、クライアントは、サーバとクライアントが共に、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしていることを知る。（図２９−（Ｓ９））そして通信を切断する。
【０５０８】
なお、これ以降の処理が連続して処理されるように図示しているが、ここで一端処理を止め、実際に暗号通信を行う場合に、これ以降の処理を行うとしてもよい。ここでは説明を簡単にするため、これ以降の処理も連続して行うものとする。
【０５０９】
（図２９−（Ｓ１３））次に、クライアントはサーバと実際にＳＳＬ／ＴＬＳ暗号通信を行うため、利用する暗号スイートの選択を行う。
【０５１０】
図２９には図示していないが、図３０に図示しているように、クライアントには、認証用（認証データの受け渡し）と通信用（通信データの受け渡し）で、それぞれ「暗号スイートの優先順位情報」が存在する。ここでははじめに、クライアントがサーバに対して認証を行うものとして説明を行う。
【０５１１】
クライアントは「暗号スイートの優先順位情報（認証用）」と、「サーバとクライアントが共にサポートする暗号スイートの情報」から「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０５１２】
（図２９−（Ｓ１４））そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２９−（Ｓ１５））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。そして、クライアントとサーバ間で認証データの受け渡しが行われる。
【０５１３】
（図２９−（Ｓ１６））次にクライアントはサーバに対して通信を行うものとする。クライアントは「暗号スイートの優先順位情報（通信用）」と、「サーバとクライアントが共にサポートする暗号スイートの情報」から「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を利用する暗号スイートとして選択する。
【０５１４】
（図２９−（Ｓ１７））そしてクライアントはサーバに対して利用する暗号スイートを伝達するため、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏを送信する。（図２９−（Ｓ１８））サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定してＳｅｒｖｅｒ  Ｈｅｌｌｏを返す。これによってクライアントは、サーバと「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」でＳＳＬ／ＴＬＳネゴシエーションを行う。この後はＳＳＬ／ＴＬＳネゴシエーションが正しく実行され、ＳＳＬ／ＴＬＳ暗号通信における共通鍵暗号の通信が開始される。そして、クライアントとサーバ間で通信データの受け渡しが行われる。
【０５１５】
なお、このＳＳＬ／ＴＬＳネゴシエーションは再ネゴシエーションなので、通常、このＳＳＬ／ＴＬＳネゴシエーションは先の暗号通信の中で実行される。このケースでは、このＳＳＬ／ＴＬＳネゴシエーションは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」で暗号化されて行われる。このＳＳＬ／ＴＬＳネゴシエーションが完了した時点から、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」で暗号化が始まる。
【０５１６】
図３０は、本発明の実施の形態における機能ブロックの第６例を示す図であり、図２９の機能ブロック図の一例でもある。また、図３１、及び図３２は、本発明の実施の形態におけるクライアント側のフローチャートの第６例を示す図であり、図３０のクライアント１のフローチャートでもある。図３３は、本発明の実施の形態におけるサーバ側のフローチャートの第３例を示す図であり、図３０のサーバのフローチャートでもある。次にこの図３０、図３１、図３２、図３３を用いて説明を行う。
【０５１７】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信を開始する。クライアント１では、サポートする暗号スイートを、「クライアントがサポートする暗号スイート情報」で把握できるようになっている。また、搭載情報８００（搭載状況記憶手段）で、その各々の暗号スイートに対して、サーバ２でサポートされている暗号スイートをチェックする仕組みになっている。なお、サポートされていない暗号スイートは、サポートされていないものとしてチェックしても構わないが、ここでは説明を簡単にするため、サポートされる暗号スイートのみをチェックするものとする。またここでは、搭載情報８００（搭載状況記憶手段）は、各々の暗号スイート毎に記憶する仕組みとしているが、記憶手段はこれに限られるものではなく、サポートされない暗号スイートの番号を覚えるなど、その記憶手段には様々な方法がある。
【０５１８】
またクライアント１には、認証用（認証データの受け渡し）と通信用（通信データの受け渡し）で、それぞれ「暗号スイートの優先順位情報」が存在する。このように目的によって利用する暗号スイートの優先順位付けを行っている。
【０５１９】
また、クライアント１には、サーバ２の暗号スイートの搭載状況を調査するか否かを示すフラグ７２０が設けてある。このフラグがＴＲＵＥの場合のみ、クライアント１はサーバ２の暗号スイートの搭載状況を調査する仕組みとなっている。このフラグ７２０には最初、ＴＲＵＥが設定されているものとする。
【０５２０】
（図３１−（Ｓ１））はじめに、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイート情報」と搭載情報８００（搭載状況記憶手段）から暗号スイートの情報を読み出す。はじめは搭載情報８００（搭載状況記憶手段）にチェックされている暗号スイートはないので、「クライアントがサポートする暗号スイート情報」に掲載されているすべての暗号スイートが読み出す。このケースでは以下の暗号スイートが読み出される。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図３１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、上記暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０５２１】
（図３１−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０５２２】
（図３１−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５２３】
（図３３−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０５２４】
（図３３−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０５２５】
暗号スイートの優先順位を決めないサーバの場合、自らがサポートする暗号スイートの内、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で最も上位に記述された暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。暗号スイートの優先順位を自ら決めるサーバの場合、Ｃｌｉｅｎｔ  Ｈｅｌｌｏで指定された暗号スイートの中で、サーバにとって最も優先順位の高い暗号スイートを選択し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏを返信する。ここでは、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択したものとして説明を行う。
【０５２６】
（図３３−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０５２７】
（図３３−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０５２８】
（図３３−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０５２９】
（図３３−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０５３０】
（図３１−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０５３１】
（図３１−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０５３２】
（図３１−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。
【０５３３】
（図３１−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図３３−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０５３４】
（図３１−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイート情報」と搭載情報８００（搭載状況記憶手段）から暗号スイートの情報を読み出す。この時点で搭載情報８００（搭載状況記憶手段）には、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」がチェックされているいるので、「クライアントがサポートする暗号スイート情報」に掲載されているすべての暗号スイートの中から、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を除外した暗号スイートを読み出す。このケースでは以下の暗号スイートが読み出される。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
（図３１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、上記暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０５３５】
（図３１−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０５３６】
（図３１−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５３７】
（図３３−（Ｓ５））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０５３８】
（図３３−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０５３９】
（図３３−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０５４０】
（図３３−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０５４１】
（図３３−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０５４２】
（図３３−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０５４３】
（図３１−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０５４４】
（図３１−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。
【０５４５】
（図３１−（Ｓ６））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージでないので、搭載情報８００（搭載状況記憶手段）に、サーバ２が「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートすることを記憶する。
【０５４６】
（図３１−（Ｓ７））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）を呼び出す（つまり（Ａ）に進む）。
（図３３−（Ｓ９））なお、サーバ２はクライアント１からのメッセージ受信待ち状態であったが、クライアント１から通信を切断されたので、このメッセージ受信待ち状態を抜け、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの受信待ち状態になる。また、図１１のフローチャートでは分かりやすいのように（Ｓ９）と（Ｓ１０）を分けて図示しているが、実際は、（Ｓ９）のメッセージ受信処理の中で、（Ｓ１０）の通信の切断処理が実行される。
【０５４７】
（図３１−（Ｓ１））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は自らが保持する「クライアントがサポートする暗号スイート情報」と搭載情報８００（搭載状況記憶手段）から暗号スイートの情報を読み出す。この時点で搭載情報８００（搭載状況記憶手段）には、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」がチェックされているいるので、「クライアントがサポートする暗号スイート情報」に掲載されているすべての暗号スイートの中から、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を除外した暗号スイートを読み出す。このケースでは以下の暗号スイートが読み出される。
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５
ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
（図３１−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（暗号スイート調査手段の一部）は、上記暗号スイートを指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０５４８】
（図３１−（Ｓ３））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０５４９】
（図３１−（Ｓ４））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５５０】
（図３３−（Ｓ１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０５５１】
（図３３−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０５５２】
（図３３−（Ｓ３））Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージには暗号スイートして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」、及び「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」が指定されているが、これをサーバ２はサポートしていないので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０がｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを生成し、これをデータ送信部２１０に送る。
【０５５３】
（図３３−（Ｓ４））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを送信する。
【０５５４】
（図３３−（Ｓ５））その後、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、クライアント１との通信を切断し、サーバ２は再びクライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージの受信待ち状態になる。
【０５５５】
（図３１−（Ｓ４））クライアント１のデータ受信部１２０は、サーバ２が送信したｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０５５６】
（図３１−（Ｓ５））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージか否かをチェックする。Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、受け取ったメッセージがｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージなので、搭載情報８００（搭載状況記憶手段）には何も処理しない。
【０５５７】
（図３１−（Ｓ８））次に、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は通信を切断し、フラグ７２０をＦＡＬＳＥに設定する。そしてＣｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００を呼び出す（つまり（Ａ）に進む）。
（図３１−（Ｓ９））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、フラグ７２０がＦＡＬＳＥの場合、「暗号スイートの優先順位」と情報搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。はじめクライアント１はサーバ２に対して、認証を行うので、「暗号スイートの優先順位」は認証用を利用する。具体的には以下のように選定する。（１）Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位１の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」がサポートされていることを知る。そこで、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を選択する。
【０５５８】
（図３１−（Ｓ１０））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０５５９】
（図３１−（Ｓ１１））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０５６０】
（図３１−（Ｓ１２））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５６１】
（図３３−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０５６２】
（図３３−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０５６３】
（図３３−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０５６４】
（図３３−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０５６５】
（図３３−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０５６６】
（図３３−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０５６７】
（図３１−（Ｓ１２））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０５６８】
（図３１−（Ｓ１３））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、フラグ７２０がＦＡＬＳＥの場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０５６９】
（図３１−（Ｓ１４））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０５７０】
（図３１−（Ｓ１５））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０５７１】
（図３１−（Ｓ１６））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５７２】
（図３３−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０５７３】
（図３３−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０５７４】
（図３３−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０５７５】
（図３３−（Ｓ１３））その後、サーバ２はクライアント１からのデータ（認証データ）受信待ち状態になる。
【０５７６】
（図３１−（Ｓ１６））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０５７７】
（図３１−（Ｓ１７））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０５７８】
（図３１−（Ｓ１８））この後通信部９００が、作成した共通鍵を使って、認証データの暗号化を行い、この暗号化された認証データをデータ送信部１１０に送る。データ送信部１１０は、この暗号化された認証データを、ネットワーク制御装置１００を介して、サーバ２に対して送信する。
【０５７９】
なお、暗号化とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０５８０】
（図３３−（Ｓ１３））サーバ２のデータ受信部２２０は、クライアント１が送信した暗号化された認証データを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、この暗号化された認証データを、通信部９１０に送る。
【０５８１】
（図３３−（Ｓ１４））通信部９１０は、暗号化された認証データを復号化する。データが認証データなので、通信部９１０は、この認証データを認証部９２０に送る。なお、認証部９２０が通信部９１０に認証結果がＯＫであったことを通知しない間は、通信部９１０は、データが通信データであれば、これを破棄し処理しない仕組みになっている。
【０５８２】
（図３３−（Ｓ１５））認証部９２０は、認証データを検査する。ここでは認証データが正しい場合で以下説明を行う。認証部９２０は通信部９１０に認証結果がＯＫであることを通知する。
【０５８３】
なお図３３のフローチャートでは、（図３３−（Ｓ１５））の後、スタートに戻っているが、これは実際にはデータ受信待ち状態である。この後、クライアント１からのＣｌｉｅｎｔ  Ｈｅｌｌｏを受信することになるが、そこで実際にはスタートに戻る。
【０５８４】
（図３１−（Ｓ１３））次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、フラグ７２０がＦＡＬＳＥで、かつ認証データ送信後の場合、「暗号スイートの優先順位」と情報搭載情報８００（搭載状況記憶手段）より、利用する暗号スイートを選択する。クライアント１はサーバ２に対して、通信データの送信を行うので、「暗号スイートの優先順位」は通信用を利用する。具体的には以下のように選定する。（１）Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位１の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＭＤ５」がサポートされていないことを知る。（２）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位２の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ」がサポートされていないことを知る。（３）次に、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、搭載情報８００（搭載状況記憶手段）より、優先順位３の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」がサポートされていることを知る。そこで、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を選択する。
【０５８５】
（図３１−（Ｓ２０））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００は、暗号スイートとして「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部１１０に送る。
【０５８６】
なお、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージに始まるＳＳＬ／ＴＬＳネゴシエーションは再ネゴシエーションなので、通常、このＳＳＬ／ＴＬＳネゴシエーションは先の暗号通信の中で実行される。このケースでは、このＳＳＬ／ＴＬＳネゴシエーションは、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」で暗号化されて行われる。従って実際は、通信部９００と通信部９１０の暗号、復号処理が介在する。説明が煩雑になるので、この処理は省略して以下説明を行う。
【０５８７】
（図３１−（Ｓ２１））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する。
【０５８８】
（図３１−（Ｓ２２））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０５８９】
（図３３−（Ｓ１））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理（解釈）するＣｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０に送る。
【０５９０】
（図３３−（Ｓ２））Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージで指定された暗号スイートが、自らがサポートする暗号スイートに存在するか否かをチェックする。
【０５９１】
（図３３−（Ｓ６））サーバ２は、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」をサポートしているので、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部４１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理し、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０を呼び出す。
【０５９２】
（図３３−（Ｓ７））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部５１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを生成し、これをデータ送信部２１０に送る。
【０５９３】
（図３３−（Ｓ８））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。
【０５９４】
（図３３−（Ｓ９））その後、サーバ２はクライアント１からのメッセージ受信待ち状態になる。
【０５９５】
（図３１−（Ｓ２２））クライアント１のデータ受信部１２０は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部１２０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ｈａｎｄｓｈａｋｅ＿ｆａｉｌｕｒｅメッセージを処理（解釈）するＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）に送る。
【０５９６】
（図３１−（Ｓ２３））Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（暗号スイート調査手段の一部）は、フラグ７２０がＦＡＬＳＥの場合、受け取ったメッセージをＳＳＬネゴシエーション処理部６００に送る（つまり（Ｂ）に進む）。なお、ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０５９７】
（図３１−（Ｓ２４））ＳＳＬネゴシエーション処理部６００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ ／ Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ ／ Ｓｅｒｖｅｒ  Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、共通鍵を生成する。そして次に、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部１１０に送る。
【０５９８】
（図３１−（Ｓ２５））データ送信部１１０は、ネットワーク制御装置１００を介して、サーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０５９９】
（図３１−（Ｓ２６））その後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０６００】
（図３３−（Ｓ９））サーバ２のデータ受信部２２０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６１０に送る。なお、ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージ処理以降のＳＳＬ／ＴＬＳ暗号通信におけるネゴシエーション処理を行う。
【０６０１】
（図３３−（Ｓ１１））ＳＳＬネゴシエーション処理部６１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ ／ Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理し、共通鍵を生成する。そして次に、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部２１０に送る。
【０６０２】
（図３３−（Ｓ１２））データ送信部２１０は、ネットワーク制御装置２００を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを送信する。
【０６０３】
（図３３−（Ｓ１３））その後、サーバ２はクライアント１からのデータ（認証データ）受信待ち状態になる。
【０６０４】
（図３１−（Ｓ２６））クライアント１のデータ受信部１２０は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２２０は、このＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理（解釈）するＳＳＬネゴシエーション処理部６００に送る。
【０６０５】
（図３１−（Ｓ２７））ＳＳＬネゴシエーション処理部６００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ ／ Ｆｉｎｉｓｈｅｄメッセージを処理する。
【０６０６】
（図３１−（Ｓ１８））この後通信部９００が、作成した共通鍵を使って、通信データの暗号化を行い、この暗号化された通信データをデータ送信部１１０に送る。データ送信部１１０は、この暗号化された認証データを、ネットワーク制御装置１００を介して、サーバ２に対して送信する。
【０６０７】
なお、暗号化とはＳＳＬ／ＴＬＳ暗号通信で規定されている共通鍵暗号処理のことであり、暗号処理と同時にハッシュ処理も行う。従ってここで共通鍵とは、暗号処理とハッシュ処理それぞれで利用される鍵を意味する。
【０６０８】
（図３３−（Ｓ１３））サーバ２のデータ受信部２２０は、クライアント１が送信した暗号化された通信データを、ネットワーク制御装置２００を介して受信する。データ受信部２２０は、この暗号化された通信データを、通信部９１０に送る。
【０６０９】
（図３３−（Ｓ１６））通信部９１０は、暗号化された通信データを復号化する。通信部９１０は先に認証部９２０より認証結果がＯＫである通知を受けているので、この通信データを処理する。
【０６１０】
なお、図３１のフローチャートの（図３１−（Ｓ２８））、図３３のフローチャートの（図３３−（Ｓ１６））の後は、クライアント１とサーバ２の間で、ＳＳＬ／ＴＬＳ暗号通信が続く。
【０６１１】
図３４は、本発明の実施の形態におけるハードウェア構成の第４例を示す図であり、図３０のハードウェア構成図の一例でもある。クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、書き換え可能な不揮発性メモリであるＨＤＤ（ハードディスク）３０、書き換え不可の不揮発性メモリであるＲＯＭ４０とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５０で構成されている。一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ４１とネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ５１で構成されている。また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ５０とＭＡＣ／ＰＨＹ５１を介してネットワークで接続されている。
【０６１２】
はじめにクライアント１のハード構成に関して説明を行う。図３４に示したクライアント１の各処理部は、ＣＰＵ１０、及びＲＡＭ２０で実行される。
【０６１３】
フラグ７２０、及び搭載情報８００（搭載状況記憶手段）は、一時的な記憶メモリであるＲＡＭ２０に配置しているが、書き換え可能なメモリであれば良く、ＨＤＤ（ハードディスク）３０やフラッシュＲＯＭなどに配置してもよい。
【０６１４】
次に「クライアントがサポートする暗号スイートの優先順位情報（認証用）」と「クライアントがサポートする暗号スイートの優先順位情報（通信用）」とであるが、これは書き換え可能な不揮発性メモリに配置するのが好ましい。本図では書き換え可能な不揮発性メモリとしてＨＤＤ（ハードディスク）３０を利用しているが、フラッシュＲＯＭなど書き換え可能な不揮発性メモリであれば、種類は何であっても構わない。「クライアントがサポートする暗号スイートの優先順位情報（認証用）」と「クライアントがサポートする暗号スイートの優先順位情報（通信用）」を一時的な記憶メモリであるＲＡＭ２０に配置しても動作はするものの、毎回、優先順位を登録する手間を要するので好ましくない。
【０６１５】
なお、「クライアントがサポートする暗号スイートの優先順位情報（認証用）」と「クライアントがサポートする暗号スイートの優先順位情報（通信用）」が実装時に決定され、実装後は優先順位の変更をしない場合は、書き換え不可の不揮発性メモリであるＲＯＭ４０などに配置してもよい。
【０６１６】
「クライアントがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。説明が紛らしなるのを避けるため、クライアント１の機能ブロック図には、「クライアントがサポートする暗号スイート」を示していないが、サーバ２の機能ブロック図には図示しているように、実際の暗号通信では必要となるものである。なおここでは、「クライアントがサポートする暗号スイート」をＲＯＭ４０に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回サーバからダウンロードして利用する場合は、ＲＡＭ２０のような揮発性メモリに配置することも可能である。
【０６１７】
ＭＡＣ／ＰＨＹ５０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
【０６１８】
次にサーバ２のハード構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、及びＲＡＭ２１で実行される。
【０６１９】
「サーバがサポートする暗号スイート」とは実際の暗号スイートのプログラムであり、通常は不揮発性メモリに配置するものである。なおここでは、「サーバがサポートする暗号スイート」をＲＯＭ４１に配置しているがこれに限られるものではない。暗号スイートのプログラムを毎回他のサーバからダウンロードして利用する場合は、ＲＡＭ２１のような揮発性メモリに配置することも可能である。
【０６２０】
ＭＡＣ／ＰＨＹ５１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置２００を実現するものである。
【０６２１】
図３５は、本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第１例を示す図である。ここでは、サーバはサーバＡ、サーバＢ、サーバＣと３種類あるものとして説明を行う。
【０６２２】
クライアントの搭載情報は、暗号スイート毎に、サーバがその暗号スイートをサポートしているか否かを記憶した情報となっている。サーバＡ、サーバＢ、サーバＣと複数のサーバがある場合は、搭載情報は、暗号スイート毎に、それぞれのサーバがその暗号スイートをサポートしているか否かを記憶する仕組みとなっている。
【０６２３】
図３６は、本発明の実施の形態における接続するサーバが複数ある場合の搭載情報の実装方法の第２例を示す図である。
【０６２４】
クライアントの搭載情報は、サーバ毎に、サーバがどの暗号スイートをサポートしているか否かを記憶した情報となっている。
【０６２５】
図３７は、本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合の「クライアントがサポートする暗号スイートの優先順位情報」の実装方法のの第１例を示す図である。
【０６２６】
ここでは、サーバはサーバＡとサーバＢと２種類あり、サーバＡとサーバＢとで、クライアントおける暗号スイートの優先順位付けが異なるものとして説明を行う。また、サーバＡと通信する場合は、認証と通信で、クライアントおける暗号スイートの優先順位付けが異なるものとする。
【０６２７】
「クライアントがサポートする暗号スイートの優先順位情報」は、暗号スイート毎に、優先順位づけが行われる仕組みとなっている。
【０６２８】
このケースでは、暗号スイート毎に、サーバＡの認証、サーバＡの通信、サーバＢが相手の場合の優先順位を記憶する仕組みとなっている。
【０６２９】
図では（１）が、優先順位が一番高く、以下、（２）、（３）と優先順位が下がる。
【０６３０】
なお、図では優先順位が記述されていない空欄が存在するが、これはそのサーバがその暗号スイートをサポートしていないことを示している。暗号スイートの搭載状況は搭載情報で記憶するが、このように「クライアントがサポートする暗号スイートの優先順位情報」に、搭載情報を合体させて記憶させてもよい。
【０６３１】
図３８は、本発明の実施の形態における接続するサーバが複数あり、サーバ別、目的別に優先順位が異なる場合の「クライアントがサポートする暗号スイートの優先順位情報」の実装方法の第２例を示す図である。
【０６３２】
ここでも、サーバはサーバＡとサーバＢと２種類あり、サーバＡとサーバＢとで、クライアントおける暗号スイートの優先順位付けが異なるものとして説明を行う。また、サーバＡと通信する場合は、認証と通信で、クライアントおける暗号スイートの優先順位付けが異なるものとする。
【０６３３】
「クライアントがサポートする暗号スイートの優先順位情報」は、サーバ、目的別毎に、優先順位づけが行われる仕組みとなっている。
【０６３４】
このケースでは、サーバＡの認証、サーバＡの通信、サーバＢ毎に、暗号スイートの優先順位を記憶する仕組みとなっている。
【０６３５】
図では（１）が、優先順位が一番高く、以下、（２）、（３）と優先順位が下がる。
【０６３６】
なお、図では優先順位が記述されていない空欄が存在するが、これはそのサーバがその暗号スイートをサポートしていないことを示している。暗号スイートの搭載状況は搭載情報で記憶するが、このように「クライアントがサポートする暗号スイートの優先順位情報」に、搭載情報を合体させて記憶させてもよい。
【０６３７】
図３９は、本発明の実施の形態における「クライアントがサポートする暗号スイートの優先順位情報」をユーザが変更する方法の第１例を示す図である。ここでは、ユーザはクライアント１の優先順位入力部９５０（優先順位変更手段）を使用して暗号スイートの優先順位を変更する仕組みになっている。優先順位入力部９５０（優先順位変更手段）は、例えば、モニタ、及びキーボードで構成される装置とすることができる。図３９に記載した入力画面（例）をモニタに表示し、サーバのアドレス（ＩＰアドレスなど）や各暗号スイートの優先順位の数字（ここでは１が一番高い優先順位で、２、３と低くなるものとする）を、ユーザにキーボードで入力させることなどで、暗号スイートの優先順位を変更させることが可能である。
【０６３８】
図４０は、本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第１例を示す図である。
【０６３９】
この図は、ほぼ図９と同じである。違いは図４０に調査フラグ７３０（調査判断手段の一部）が存在するところである。ここではＣｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（調査判断手段の一部）が、サーバにおける暗号スイートの搭載情報を調査する前に、調査フラグ７３０を見て、これがＴＲＵＥになっていたら、サーバにおける暗号スイートの搭載情報を調査する仕組みになっている。この調査フラグ７３０の値をＦＡＬＳＥにすれば、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部４００（調査判断手段の一部）は、通常のＳＳＬ／ＴＬＳ暗号通信を行う。
【０６４０】
これにより、クライアント１は必要な場合だけ、サーバ２における暗号スイートの搭載情報を調査するようになるため、無駄な手間を削減できる。多くのサーバ２は暗号スイートの優先順位付けを行っていないので、この機能は重要である。
【０６４１】
この調査フラグ７３０（調査判断手段の一部）は、ユーザ設定としてもよい。その場合、ユーザが接続するサーバ毎に設定できるのが望ましい。あるサーバとＳＳＬ／ＴＬＳ暗号通信を利用してみてパフォーマンスが悪ければ、この調査フラグ７３０（調査判断手段の一部）をＴＲＵＥに設定することで、パフォーマンスの改善を試みることが可能となる。
【０６４２】
なおここでは図示していないが、調査フラグ７３０（調査判断手段の一部）は、接続するサーバが複数ある場合には、サーバ毎に記憶するとよい。また調査フラグ７３０（調査判断手段の一部）は、搭載情報８００や、暗号スイートの優先順位情報と共に記憶するものであってもよい。
【０６４３】
図４１は、本発明の実施の形態におけるクライアントが、前記サーバにおける暗号スイートの搭載情報を調査するか否かを判断する方法の第２例を示す図である。
【０６４４】
はじめにクライアントは、手順（図４１−（Ｓ１））〜（図４１−（Ｓ１２））に記載しているように、サーバが搭載している少なくとも２つ以上の暗号スイートを探す。
【０６４５】
そして、（図４１−（Ｓ１３））次にサーバが搭載していると分かった少なくとも２つ以上の暗号スイートを同時に指定したＣｌｉｅｎｔ  Ｈｅｌｌｏをサーバに送信する。
【０６４６】
この例では、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」と「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を同時に指定したＣｌｉｅｎｔ  Ｈｅｌｌｏをサーバに送信している。なお、ここでは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」より先に記載しているが、その順番は逆でも構わない。
【０６４７】
（図４１−（Ｓ１４））ここでは、サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信したとする。もしここで、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信すれば、この時点で、サーバが暗号スイートの優先順位付けを行っていることが分かる。サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信した場合は、この時点では、サーバがクライアントの優先順位を尊重しているのか、または暗号スイートの優先順位付けを行っているのかは判別できない。
【０６４８】
（図４１−（Ｓ１５））通信を切断する。なおここでは一回一回調査するように記載しているが、（図４１−（Ｓ１６））以下の調査は、違うＴＣＰポート利用するなどして（図４１−（Ｓ１３））と同時に行っても構わない。
【０６４９】
（図４１−（Ｓ１６））次にまた、サーバが搭載していると分かった少なくとも２つ以上の暗号スイートを同時に指定したＣｌｉｅｎｔ  Ｈｅｌｌｏをサーバに送信する。
【０６５０】
但し、先ほどとは逆の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」の順で記載した暗号スイートのＣｌｉｅｎｔ  Ｈｅｌｌｏをサーバに送信している。
【０６５１】
なお、先に「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」の順で指定したのであれば、ここでは逆の「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」、「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」の順で指定する。
【０６５２】
（図４１−（Ｓ１４））ここでは、サーバは「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信したとする。もしここで、サーバが「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信すれば、サーバがクライアントの優先順位を尊重していることが分かる。
【０６５３】
サーバがこの図のように「ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ」を指定したＳｅｒｖｅｒ  Ｈｅｌｌｏを返信すれば、サーバが暗号スイートの優先順位付けを行っているのが分かる。
【０６５４】
このブロック図はほぼ図４０と同じになる。Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部（調査判断手段の一部）とＳｅｒｖｅｒ  Ｈｅｌｌｏ受信部５００（調査判断手段の一部）との間で、サーバが優先順位付けを行っているか否かを判断できる。なお、判断結果は調査フラグ７３０（調査判断手段の一部）に反映してもしなくてもどちらでもよい。調査フラグ７３０（調査判断手段の一部）に反映すれば、再度調査する必要がなくなるので手間は省ける。
【０６５５】
図４２は、本発明の実施の形態におけるＳＳＬ／ＴＬＳ暗号通信の第６例を示すシーケンス図である。図２とほぼ同じシーケンスであるが、大きな違いは、利用する暗号スイートを選択する際、複数の暗号スイートを選択しているところにある。
【０６５６】
これは、サーバの暗号スイートの搭載状況調査で、サーバからｈａｎｄｓｈａｋｅ  ｆａｉｌｕｒｅが連続で返信され、クライントが、クライント・サーバが共にサポートする暗号スイートを見つけられないままに時間が経過した場合の処理方法を示している。
【０６５７】
このような場合、図４２に示したように、クライアントは許容できる時間が経過した段階で、サーバの暗号スイートの搭載状況調査を終え、それまでの情報によって、暗号スイートを選択すればよい。
【産業上の利用可能性】
【０６５８】
本発明にかかる通信装置は、主導的に暗号スイートの選択が行えるので、脆弱な組込み機器のクライアントでも、セキュリティバランスに配慮した上で、パフォーマンス良く通信を行え、有用である。
【符号の説明】
【０６５９】
１    クライアント
２    サーバ
１０    ＣＰＵ（クライアント側）
１１    ＣＰＵ（サーバ側）
２０    ＲＡＭ（クライアント側）
２１    ＲＡＭ（サーバ側）
３０    ＨＤＤ（ハードディスク）
４０    ＲＯＭ（クライアント側）
４１    ＲＯＭ（サーバ側）
５０    ＭＡＣ／ＰＨＹ（クライアント側）
５１    ＭＡＣ／ＰＨＹ（サーバ側）
１００    ネットワーク制御装置（クライアント側）
１１０    データ送信部（クライアント側）
１２０    データ受信部（クライアント側）
２００    ネットワーク制御装置（サーバ側）
２１０    データ送信部（サーバ側）
２２０    データ受信部（サーバ側）
４００    Ｃｌｉｅｎｔ  Ｈｅｌｌｏ生成部
４１０    Ｃｌｉｅｎｔ  Ｈｅｌｌｏ受信部
５００    Ｓｅｒｖｅｒ  Ｈｅｌｌｏ受信部
５１０    Ｓｅｒｖｅｒ  Ｈｅｌｌｏ生成部
６００    ＳＳＬネゴシエーション処理部（クライアント側）
６１０    ＳＳＬネゴシエーション処理部（サーバ側）
７００    現在の優先順位を示すカウンタ
７１０    現在のカウンタ
７２０    フラグ
７３０    調査フラグ
８００    搭載情報
９００    通信部（クライアント側）
９１０    通信部（サーバ側）
９２０    認証部
９５０    優先順位入力部
【図１】
2014116641.tif 000003
【図２】
2014116641.tif 000004
【図３】
2014116641.tif 000005
【図４】
2014116641.tif 000006
【図５】
2014116641.tif 000007
【図６】
2014116641.tif 000008
【図７】
2014116641.tif 000009
【図８】
2014116641.tif 000010
【図９】
2014116641.tif 000011
【図１０】
2014116641.tif 000012
【図１１】
2014116641.tif 000013
【図１２】
2014116641.tif 000014
【図１３】
2014116641.tif 000015
【図１４】
2014116641.tif 000016
【図１５】
2014116641.tif 000017
【図１６】
2014116641.tif 000018
【図１７】
2014116641.tif 000019
【図１８】
2014116641.tif 000020
【図１９】
2014116641.tif 000021
【図２０】
2014116641.tif 000022
【図２１】
2014116641.tif 000023
【図２２】
2014116641.tif 000024
【図２３】
2014116641.tif 000025
【図２４】
2014116641.tif 000026
【図２５】
2014116641.tif 000027
【図２６】
2014116641.tif 000028
【図２７】
2014116641.tif 000029
【図２８】
2014116641.tif 000030
【図２９】
2014116641.tif 000031
【図３０】
2014116641.tif 000032
【図３１】
2014116641.tif 000033
【図３２】
2014116641.tif 000034
【図３３】
2014116641.tif 000035
【図３４】
2014116641.tif 000036
【図３５】
2014116641.tif 000037
【図３６】
2014116641.tif 000038
【図３７】
2014116641.tif 000039
【図３８】
2014116641.tif 000040
【図３９】
2014116641.tif 000041
【図４０】
2014116641.tif 000042
【図４１】
2014116641.tif 000043
【図４２】
2014116641.tif 000044