(57)【特許請求の範囲】
【請求項１】
パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、
第１の乱数および第２の乱数を生成する乱数生成部と、
前記他の暗号通信装置の公開鍵を用いて前記第１の乱数に基づく情報を暗号化する第１の暗号化部と、
前記第１の暗号化部によって暗号化された前記第１の乱数に基づく情報を、前記パスワードを用いて暗号化する第２の暗号化部と、
前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、
前記第２の暗号化部によって暗号化された前記第１の乱数に基づく情報を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記他の暗号通信装置に送信する送信部と、を備え、
前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を検証信号として送信する、暗号通信装置。
【請求項２】
請求項１記載の暗号通信装置であって、
前記送信部は、前記第１の信号と前記第２の信号とを連続的に前記他の暗号通信装置に送信する、暗号通信装置。
【請求項３】
請求項１または２記載の暗号通信装置であって、
前記第３の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第１の乱数および前記第２の乱数を用いて暗号化する、暗号通信装置。
【請求項４】
請求項２記載の暗号通信装置であって、
前記他の暗号通信装置からの信号を受信する受信部を更に有し、
前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、
前記送信部は前記第２の乱数を前記他の暗号通信装置に送信する、暗号通信装置。
【請求項５】
請求項３記載の暗号通信装置であって、
前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴である、暗号通信装置。
【請求項６】
パスワードを共有する第１の暗号通信装置と第２の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、
前記第１の暗号通信装置は、
第１の乱数および第２の乱数を生成する乱数生成部と、
前記第２の暗号通信装置の公開鍵を用いて前記第１の乱数を暗号化する第１の暗号化部と、
前記第１の暗号化部によって暗号化された前記第１の乱数を前記パスワードを用いて暗号化する第２の暗号化部と、
前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、
前記第２の暗号化部によって暗号化された前記第１の乱数を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記第２の暗号通信装置に送信する送信部と、を有し、
前記第２の暗号通信装置は、
前記第１の信号および前記第２の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第２の暗号化部によって暗号化された前記第１の乱数を復号化し、前記第１の乱数を取得する復号化部と、
前記復号化部が取得した前記第１の乱数を用いて、前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報から前記第２の乱数を算出する認証データ取得部と、
を有し、
前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を検証信号として送信する、暗号通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、鍵交換処理と共に認証処理を行う暗号通信装置および暗号通信システムであって、特に、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）暗号通信と共にパスワード相互認証プロトコル（Ｐａｓｓｗｏｒｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、以下ＰＡＫＥ認証と称する）を行う暗号通信装置および暗号通信システムに関する。
【背景技術】
【０００２】
近年、通信を安全に行う方法として、ＳＳＬ／ＴＬＳ暗号通信が普及している。ＳＳＬ／ＴＬＳ暗号通信は、非常に簡単に利用できる上、暗号通信で最も危険な中間者攻撃に対しても防御方法があり、安全性も非常に高い。
【０００３】
しかし中間者攻撃への対処には、サーバ証明書やクライアント証明書の利用したＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の仕組みが必要であり、普通のパスワード認証に比べ、運用が煩雑な上、運用費も嵩む。
【０００４】
この欠点を補う手段として最近、ＰＡＫＥ認証の研究が進んでいる。ＰＡＫＥ認証は従来のパスワード認証とは異なり、公開鍵暗号方式とパスワード認証を融合させた新たな認証方式である。ＰＡＫＥ認証を利用すれば、高価で煩雑なＰＫＩではなく、安価で簡単なパスワードを利用して、中間者攻撃を抑制できる。
【０００５】
しかしながら、ＰＡＫＥ認証だけで、暗号通信と認証を同時に実現するのは理論的に可能であっても、実際の運用はかなり難しい。このため、ファイヤーウォール等様々な通信機器やブラウザ等ツールが、ＳＳＬ／ＴＬＳ暗号通信に対応し、広く普及しているＳＳＬ／ＴＬＳ暗号通信の仕組みをそのまま利用してＰＡＫＥ認証を行う技術が提案されている。クライアントとサーバとでＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行った後に、ＰＡＫＥ認証を行うことで中間者攻撃の被害を抑制することができる（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−２９６１９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、ＳＳＬ／ＴＬＳ暗号通信にそのままＰＡＫＥ認証を利用すると、共通鍵を交換にコンピュータにとって負荷の大きい公開鍵暗号を少なくとも２回以上利用する必要があった。即ち、ＳＳＬ／ＴＬＳのハンドシェイク処理において公開鍵暗号を行い、更にこのハンドシェイク処理後にＰＡＫＥ認証を行うためにもう１度公開鍵暗号を行っていた。
【０００８】
また、特にサーバ側は公開鍵暗号における秘密鍵を利用した復号を行うため、ＣＰＵに非常に重い負荷が生じた。一般的にサーバは複数のクライアントを相手にするので、常時、多量の公開鍵暗号を実行しなければならない。そのため、多くのＳＳＬ／ＴＬＳサーバは、高価なＣＰＵやＳＳＬ／ＴＬＳアクセラレータボードを搭載している。このように公開鍵暗号を実行するのに要する費用は非常に大きく、コンピュータ購入費の半分以上のコストに相当するという見解もある。従って、公開鍵暗号の回数が倍以上になる影響は深刻であった。
【０００９】
また、ＳＳＬ／ＴＬＳ暗号通信は、各種攻撃に対する防御ノウハウが蓄積されていて信頼性が高いのに対し、ＰＡＫＥ認証による暗号通信は、攻撃に対する知見が少なく、信頼性に欠ける。
【００１０】
本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、普及しているＳＳＬ／ＴＬＳ暗号通信で、ＰＡＫＥ認証を用いて中間者攻撃を安価でかつ簡単に抑制しつつも、ＣＰＵの負荷を低減することである。
【課題を解決するための手段】
【００１１】
上述の課題を解決するために、本発明の暗号通信装置は、パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、第１の乱数および第２の乱数を生成する乱数生成部と、前記他の暗号通信装置の公開鍵を用いて前記第１の乱数に基づく情報を暗号化する第１の暗号化部と、前記第１の暗号化部によって暗号化された前記第１の乱数に基づく情報を、前記パスワードを用いて暗号化する第２の暗号化部と、前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、前記第２の暗号化部によって暗号化された前記第１の乱数に基づく情報を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記他の暗号通信装置に送信する送信部と、を備える。
【００１２】
本発明の暗号通信装置によれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。
【００１３】
また、本発明の暗号通信装置は、前記送信部は、前記第１の信号と前記第２の信号とを連続的に前記他の暗号通信装置に送信するように構成される。
【００１４】
本発明の暗号通信装置のこの構成によれば、第２の乱数を用いて他の暗号通信装置の認証を行うことができる。
【００１５】
本発明の暗号通信装置のこの構成によれば、既知のデータを第２の乱数で暗号化しているため、他の暗号通信装置からの計算結果を待たずして、第１の乱数を送信する第１の信号と、認証を行うための第２の信号を同時に送ることができる。即ち、他の暗号通信装置とのパスワード認証を短縮して行うことができる。
【００１６】
また、本発明の暗号通信装置は、前記第３の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第１の乱数および前記第２の乱数を用いて暗号化するように構成される。
【００１７】
本発明の暗号通信装置のこの構成によれば、他の暗号通信装置が既知データおよび第１の乱数から第２の乱数を算出した場合、他の暗号通信装置の認証を行うことができる。
【００１８】
また、本発明の暗号通信装置は、前記他の暗号通信装置からの信号を受信する受信部を更に有し、前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、前記送信部は前記第２の乱数を前記他の暗号通信装置に送信するように構成される。
【００１９】
本発明の暗号通信装置のこの構成によれば、第２の乱数を保持していることを他の暗号通信装置に通知できるため、他の暗号通信装置に自装置のパスワード認証をさせることができる。
【００２０】
また、本発明の暗号通信装置は、前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴であるように構成される。
【００２１】
本発明の暗号通信装置のこの構成によれば、他の暗号通信装置は自装置との通信履歴から自らこの通信履歴を算出することができる。このため、他の暗号通信装置は、例えば、悪意の第３者によって暗号方式の付け替えが行われたかどうかを確認できる。
【００２２】
また、本発明の暗号通信装置は、前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を前記第２の乱数の検証信号として送信するように構成される。
【００２３】
本発明の暗号通信装置のこの構成によれば、ＳＳＬハンドシェイクのプロトコルを通過させるファイヤーウォールのチェックにかからずに第１の信号および第２の信号を他の暗号通信装置に送信することができる。即ち、ＳＳＬハンドシェイクに基づいて他の暗号通信装置のパスワード認証を安価に行うことができる。
【００２４】
また、本発明の暗号通信システムは、パスワードを共有する第１の暗号通信装置と第２の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、前記第１の暗号通信装置は、第１の乱数および第２の乱数を生成する乱数生成部と、前記第２の暗号通信装置の公開鍵を用いて前記第１の乱数を暗号化する第１の暗号化部と、前記第１の暗号化部によって暗号化された前記第１の乱数を前記パスワードを用いて暗号化する第２の暗号化部と、前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、前記第２の暗号化部によって暗号化された前記第１の乱数を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記第２の暗号通信装置に送信する送信部と、を有し、前記第２の暗号通信装置は、前記第１の信号および前記第２の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第２の暗号化部によって暗号化された前記第１の乱数を復号化し、前記第１の乱数を取得する復号化部と、前記復号化部が取得した前記第１の乱数を用いて、前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報から前記第２の乱数を算出する認証データ取得部と、を有する。
【００２５】
本発明の暗号通信システムによれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。
【００２６】
また、本発明の暗号通信システムは、クライアントがサーバに対して、公開鍵とパスワードで暗号化した乱数Ａを送信する、クライアント・サーバ（秘密鍵を保持する側をサーバと呼ぶ）間のＰＡＫＥ認証であって、クライアントは乱数生成手段、および共通鍵暗号化手段を有し、クライアントは乱数生成手段を用いて乱数Ｂを生成し、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、乱数Ａ（乱数Ａから生成されるデータを含む）を、前記共通鍵暗号化手段を用いて暗号化し、サーバがパスワードを保持することを確認する前に、この乱数Ｂによって暗号化された乱数Ａをサーバに対して渡すものとし、クライアントは、サーバがパスワードを保持することを確認できたら、乱数Ｂ（乱数Ｂから生成されるデータを含む）をサーバに対して提示し、クライアントが乱数Ａ、即ちパスワードを理解していることをサーバに対して伝達する、つまりクライアント認証を行うものとした。
【００２７】
これによると、任意の値である乱数Ｂを用いて、クライアント認証を行うことが可能となる。なおこの乱数Ｂは、ワンタイムパスワードとして利用可能である。
【００２８】
またこのような提示方法は、ＳＳＬ／ＴＬＳネゴシエーションと親和性がよい。ＳＳＬ／ＴＬＳネゴシエーションでは、クライアントは、公開鍵暗号で暗号したデータ（Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）と共に、その検証データ（Ｆｉｎｉｓｈｅｄ）も同時に送る。その時点ではクライアントは、まだサーバの検証データ（Ｆｉｎｉｓｈｅｄ）を入手していない。そのため、ＳＳＬ／ＴＬＳネゴシエーションと同時にＰＡＫＥ認証を行うと、オフライン攻撃が成立してしまう。
【００２９】
しかし本発明の暗号通信システムによれば、クライアントが送信する検証データ（Ｆｉｎｉｓｈｅｄ）は乱数Ｂで暗号化されているので、その危険性は少ない。従ってＳＳＬ／ＴＬＳネゴシエーションの中でパスワード認証（例えば、ＰＡＫＥ認証）を実施できるようになる。
【００３０】
これにより、１回の公開鍵暗号でＳＳＬ／ＴＬＳネゴシエーションとＰＡＫＥ認証を行えるようになるので、サーバのＣＰＵの負荷を小さくでき、サーバ費用を大幅に削減できる。
【００３１】
なお、このようにＳＳＬ／ＴＬＳネゴシエーションでＰＡＫＥ認証を行えば、ファイヤーウォール等の通信機器によって通信を遮断される危険性も減少する。
【００３２】
このような課題を解決するために、本発明の暗号通信システムでは、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）の中で、クライアントがサーバに対して乱数Ｂを提示するものとした。
【００３３】
これによると、ＳＳＬ／ＴＬＳ暗号通信処理を、アプリケーションプログラムではなく、ＯｐｅｎＳＳＬのようなＳＳＬ／ＴＬＳ暗号通信モジュールが行っている場合に、アプリケーションプログラムのつくりをより簡略にすることができる。アプリケーションプログラムが一端ＳＳＬ／ＴＬＳ暗号通信モジュールにパスワードを渡せば、後はＳＳＬ／ＴＬＳ暗号通信モジュールがすべての処理を行える。
【００３４】
また、本発明の暗号通信システムは、ＳＳＬ／ＴＬＳの再接続を行うネゴシエーションの中で、クライアントがサーバに対して乱数Ｂを提示するものとした。
【００３５】
これによると、１回の公開鍵暗号でＳＳＬ／ＴＬＳネゴシエーションとＰＡＫＥ認証を行えるようになるので、サーバのＣＰＵの負荷を小さくでき、サーバ費用を大幅に削減できる。
【００３６】
また、本発明の暗号通信システムは、サーバは、クライアントから渡された前記共通鍵暗号化手段で暗号化された乱数Ａ（乱数Ａから生成されるデータを含む）と、乱数Ａ（乱数Ａから生成されるデータを含む）から、乱数Ｂ（乱数Ｂから生成されるデータを含む）を割り出すものとし、この割り出した乱数Ｂ（乱数Ｂから生成されるデータを含む）とクライアントから渡された乱数Ｂ（乱数Ｂから生成されるデータを含む）とを照合することで、クライアント認証を行うものとした。
【００３７】
これによると、サーバは認証データである乱数Ｂだけを記憶しておけばよいので、サーバ側のＳＳＬ／ＴＬＳ暗号通信モジュールのつくりを簡単にできる。
【００３８】
また、本発明の暗号通信システムは、前記共通鍵暗号化手段がＸＯＲ処理であるものとした。
【００３９】
これによると、サーバ側のＳＳＬ／ＴＬＳ暗号通信モジュールが、非常に簡単、かつ迅速に乱数Ｂの割り出しを行えるようになる。
【００４０】
また、本発明の暗号通信システムは、クライアントがサーバに乱数Ｂを提示するのに、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、この自ら暗号化した情報と、クライアントが暗号化した情報とを比較することで、クライアントが乱数Ｂを理解していることを確認するものとした。
【００４１】
これによると、クライアントがサーバに既知の情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、ＰＡＫＥ認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第３者に分かるような既知の情報は埋め込めこめない。しかし、ＳＳＬ／ＴＬＳネゴシエーションでは、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ  ｒｏｌｌｂａｃｋ  ａｔｔａｃｋｓ）を抑制するために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。
【００４２】
そこで、本発明の暗号通信システムのように、バージョン情報等の既知の情報は、乱数Ｂで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、ＰＡＫＥ認証とＳＳＬ／ＴＬＳネゴシエーションを両立させることが可能となる。乱数Ｂの値を知らない悪意の第３者は、乱数Ｂで暗号化した偽バージョン情報を作成できないので、悪意の第３者は、クライアント・サーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃（Ｖｅｒｓｉｏｎ  ｒｏｌｌｂａｃｋ  ａｔｔａｃｋｓ）を行うことは不可能である。
【００４３】
また、本発明の暗号通信システムは、クライアントがサーバに乱数Ｂを提示するのに、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、暗号化されたサーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて復号化し、この自ら保持、若しくは生成できる情報と、復号化した情報とを比較することで、クライアントが乱数Ｂを理解していることを確認するものとした。
【００４４】
これによると、クライアントがサーバに特定情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、ＰＡＫＥ認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第３者に分かるような既知の情報は埋め込めこめない。しかし、ＳＳＬ／ＴＬＳネゴシエーションでは、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ  ｒｏｌｌｂａｃｋ  ａｔｔａｃｋｓ）を防ぐために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。
【００４５】
そこで、本発明のように、バージョン情報等の既知の情報は、乱数Ｂで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、ＰＡＫＥ認証とＳＳＬ／ＴＬＳネゴシエーションを両立させることが可能となる。乱数Ｂの値を知らない悪意の第３者は、乱数Ｂで暗号化した偽バージョン情報を作成できないので、悪意の第３者は、クライアント・サーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃（Ｖｅｒｓｉｏｎ  ｒｏｌｌｂａｃｋ  ａｔｔａｃｋｓ）を行うことは不可能である。
【発明の効果】
【００４６】
鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による負荷を低減することができる。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施の形態１におけるＰＡＫＥ認証を示すシーケンス図
【図２】本発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第１例を示す図
【図３】本発明の実施の形態１におけるクライアント側のフローチャートの一例を示す図
【図４】本発明の実施の形態１におけるサーバ側のフローチャートの一例を示す図
【図５】本発明の実施の形態１におけるクライアントおよびサーバのハードウェア構成の一例を示す図
【図６】本発明の実施の形態２におけるＰＡＫＥ認証を示すシーケンス図
【図７】本発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第２例を示す図
【発明を実施するための形態】
【００４８】
（実施の形態１）
以下、本発明の実施の形態１を、図面を参照しながら説明する。
【００４９】
図１は、本発明の実施の形態１におけるＰＡＫＥ認証を示すシーケンス図である。ここでは、クライアント１とサーバ２とは、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク、ＳＳＬネゴシエーション、ＳＳＬハンドシェイクとも称する）中に、ＰＡＫＥ認証も行う。なお説明を簡単にするために、ここで用いる公開鍵暗号はＲＳＡ（Ｒｉｖｅｓｔ  Ｓｈａｍｉｒ  Ａｄｌｅｍａｎ）暗号として説明を行う。また、クライアント１とサーバ２の構成については、図２、図５等を用いて詳細に説明する。なお、クライアント１およびサーバ２は暗号通信装置の一例である。
【００５０】
クライアント１がサーバ２に対してＣｌｉｅｎｔ  Ｈｅｌｌｏを生成し、送信する（ステップＳ１）。サーバ２はこのＣｌｉｅｎｔ  Ｈｅｌｌｏを受信し、処理する（ステップＳ２）。そして、サーバ２はクライアント１に対してＳｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ（公開鍵の情報を含む）、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅを生成し、送信する（ステップＳ３）。クライアント１はこれらを受信し、処理する。なお、クライアント１は、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅから公開鍵を取得する（ステップＳ４）。
【００５１】
クライアント１はＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅを生成するため、乱数Ａ（第１の乱数）を生成する。なお、乱数Ａのデータ長は、ＲＳＡ暗号におけるモジュラス（ｍｏｄｕｌｕｓ）のデータ長に等しい（ステップＳ５）。
【００５２】
クライアント１は、乱数Ａから共通鍵を生成する。詳細に説明すると、クライアント１は乱数Ａの内、最後の４８バイトをプリマスターシークレット（ｐｒｅｍａｓｔｅｒ  ｓｅｃｒｅｔ）として扱う。なお、乱数Ａの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるために、最後の４８バイトをプリマスターシークレットとする。
【００５３】
次に、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ  ｓｅｃｒｅｔ）を生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する（ステップＳ６）。なおここで共通鍵とは、例えば、以下の鍵の総称であり、以下の同様である。
【００５４】
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ＭＡＣ＿ｓｅｃｒｅｔ
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＭＡＣ＿ｓｅｃｒｅｔ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ｋｅｙ
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ｋｅｙ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
次に、乱数Ａをサーバ２から伝送された公開鍵で暗号化する（ステップＳ７）。なお、本実施の形態では乱数Ａを公開鍵で暗号するが、乱数Ａそのものではなく、サーバ２が乱数Ａを算出できる情報であればよい。
【００５５】
なおこの暗号化の手順は、通常のＳＳＬ／ＴＬＳ暗号通信の仕様とは異なるので、以下、差異を説明する。
【００５６】
バージョン３．０以降のＳＳＬ／ＴＬＳ暗号通信では、プリマスターシークレットは以下のように、２バイトのバージョン情報と４６バイトの乱数Ｄで構成されている。
【００５７】
ｓｔｒｕｃｔ ｛
ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ ｃｌｉｅｎｔ＿ｖｅｒｓｉｏｎ; 
←  バージョン情報（  ２バイト）
ｏｐａｑｕｅ ｒａｎｄｏｍ［４６］;    ←  乱数Ｄ        （４６バイト）
｝ ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ;          ←  プリマスターシークレット
従って、乱数Ａから生成されたプリマスターシークレットには、バージョン情報が設定されていない。ここはＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
【００５８】
次に、ＳＳＬ／ＴＬＳ暗号通信では、このプリマスターシークレットは、以下のように、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）で整形される。
【００５９】
００ || ０２ || パディング文字列（００を含まない乱数Ｅ） || ００ || ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ
ここで、|| の記号は単なるデータの連結を意味する。
【００６０】
なおこの全データ長は、ＲＳＡ暗号におけるモジュラス（ｍｏｄｕｌｕｓ）のデータ長に等しいので、乱数Ｅのデータ長は以下のようになる。
【００６１】
乱数Ｅのデータ長 ＝ モジュラス（ｍｏｄｕｌｕｓ）のデータ長 − ３ − ４８
ＳＳＬ／ＴＬＳ暗号通信では、この暗号ブロックフォーマット化されたプリマスターシークレットは公開鍵で暗号化される。
【００６２】
一方、乱数Ａはモジュラス（ｍｏｄｕｌｕｓ）のデータ長と等しく、乱数Ａの構造は以下の通りである。
【００６３】
乱数Ａ ＝ （乱数Ｃ || ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ）
なお乱数Ｃのデータ長は、モジュラス（ｍｏｄｕｌｕｓ）のデータ長より、ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔのデータ長、つまり４８バイト分少ない。
【００６４】
このように、「００ || ０２ || パディング文字列（００を含まない乱数Ｅ） || ００」の部分を「乱数Ｃ」に置き換えているところも、ＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
【００６５】
つまり、乱数Ａには、ＳＳＬ／ＴＬＳ暗号通信の仕様で定義されているプリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）によるデータ整形がなされていない。
【００６６】
なお、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）で整形しない。
【００６７】
しかしこのようにすると、悪意の第３者がクライアントになりすまし、０とか１のような特殊なＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをサーバ２に渡し、サーバ２が返すＦｉｎｉｓｈｅｄを見て、パスワードを類推するかもしれない。これを避けるには、サーバ２は、０とか１のような単純なＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをエラーとして処理するか、若しくはパスワードの暗号方法を工夫すればよい。つまり、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔが０や１であっても、パスワードで復号した場合に複雑な値が出現するようなものであれば問題ない。
【００６８】
また、乱数Ａに、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）によるデータ整形を行わない理由は、オフライン攻撃を抑制するためである。
【００６９】
悪意の第３者が正規サーバになりすます（即ち、悪意の第３者がサーバ２として動作する）場合、悪意の第３者は、自らが保持する秘密鍵と対となる公開鍵をクライアントに渡せる。従って、悪意の第３者は公開鍵暗号における復号化が可能である。
【００７０】
一方パスワードの方も、オフラインであれば、パスワードは一般的に記憶できる程度の長さにするため、暗号鍵に比べビット長が短く、悪意の第３者にとっては、パスワードが取りうるすべての組合せを総当りで調べるのは難しくない。
【００７１】
悪意の第３者は正規サーバになりすまし、クライアント１から２重暗号された乱数Ａを取得する。そして、仮パスワードを設定し、２重暗号された乱数Ａをこの仮パスワードと自らが保持する秘密鍵で復号化する。乱数Ａにバージョン情報やフォーマットがあれば、これが出現するか否かで、想定したパスワードが正しいかを判定できる。
【００７２】
悪意の第３者は、オフラインで仮パスワードを次々に設定すれば、いずれかの時点で、乱数Ａにバージョン情報やフォーマットが出現するパスワードを探し当てることが可能である（オフライン攻撃）。
【００７３】
以上説明したように、このオフライン攻撃を避けるため、乱数Ａにはバージョン情報設定やフォーマット化を行わない。
【００７４】
次に、公開鍵で暗号化された乱数Ａを、更にパスワードで暗号化し、２重暗号化された乱数Ａを求める（ステップＳ８）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
【００７５】
そして、この２重暗号された乱数Ａを、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔとして、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅを生成する。ここで、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅは第１の信号の一例であり、サーバ２に乱数Ａを送信するための鍵交換信号でもある。
【００７６】
Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃを生成し（ステップＳ９）、Ｆｉｎｉｓｈｅｄの平分のデータ部を生成する（ステップＳ１０）。ここで、Ｆｉｎｉｓｈｅｄは、第２の信号の一例であり、検証データを送信するための検証信号でもある。
【００７７】
クライアント１は乱数Ｂ（第２の乱数）を生成し、少なくともＦｉｎｉｓｈｅｄのデータ部で、共通鍵で暗号化する部分（ＭＡＣを含む）を、乱数Ｂで暗号化する。乱数Ｂによる暗号化はここではＸＯＲ処理とする（ステップＳ１１）。この乱数Ｂによる暗号化処理手続きも、ＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
【００７８】
ここで、Ｆｉｎｉｓｈｅｄのデータ部を乱数Ｂで暗号化するのは、これも上述したオフライン攻撃を抑制するためである。仮に乱数Ｂで暗号化されていないＦｉｎｉｓｈｅｄをクライアント１がサーバ２に送信すると、悪意の第３者が正規サーバになりすました場合に、オフライン攻撃が成立する可能性がある。
【００７９】
悪意の第３者は、オフラインで仮パスワードを次々に設定し、Ｆｉｎｉｓｈｅｄを自ら計算すれば、クライアント１から受信したＦｉｎｉｓｈｅｄと比較することで、いずれかの時点で、正しいパスワードを探し当てることが可能である。
【００８０】
乱数Ｂで暗号化したデータ部を、更に共通鍵で暗号化し、データ部を２重暗号化する（ステップＳ１２）。ここでは、ファイヤーウォールのチェックにひっかからないためにＳＳＬ／ＴＬＳ暗号通信の仕様に従う。即ち、この共通鍵による暗号はなくてもよいが、クライアント１はＳＳＬ／ＴＬＳ暗号通信の仕様に基づいて共通鍵による暗号を行う。
【００８１】
クライアント１はサーバ２に対して、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを送信する（ステップＳ１３）。
【００８２】
サーバ２はクライアント１から、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを受信する（ステップＳ１４）。
【００８３】
サーバ２は、Ｃｌｉｅｎｔ  Ｋｅｙ  ＥｘｃｈａｎｇｅのＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔにセットされた２重暗号化された乱数Ａをパスワードで復号化し、公開鍵で暗号化された乱数Ａを求める（ステップＳ１５）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
【００８４】
サーバ２は、公開鍵で暗号化された乱数Ａを秘密鍵で復号化する（ステップＳ１６）。
【００８５】
サーバ２は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱う。なお、乱数Ａの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるために、最後の４８バイトをプリマスターシークレットとする。
【００８６】
次に、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ  ｓｅｃｒｅｔ）を生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。
【００８７】
なお上述したように、乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないので、サーバ２はこのチェックを行わない。ここもＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
【００８８】
サーバ２は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃを処理し（ステップＳ１８）、２重暗号化されたＦｉｎｉｓｈｅｄのデータ部を共通鍵で復号化する（ステップＳ１９）。
【００８９】
そしてサーバ２は、クライアント１が生成したＦｉｎｉｓｈｅｄのデータ部を、独自に計算する。
【００９０】
サーバ２は、乱数Ｂで暗号化されたＦｉｎｉｓｈｅｄのデータ部と、自ら計算して求めたＦｉｎｉｓｈｅｄのデータ部を比較して、乱数Ｂを求める。これもＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる（ステップＳ２１）。
【００９１】
なお、クライアント１がサーバ２に対して乱数Ｂを提示できれば、クライアント１がサーバに提示したＦｉｎｉｓｈｅｄが正しいと証明できるので、この乱数Ｂは、クライアントが正規クライアントか否かを確かめる、つまりクライアント認証のための認証データとして扱える。
【００９２】
サーバ２は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、クライアント１に対してこれを送信する。なお、このＦｉｎｉｓｈｅｄの生成は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従う（ステップＳ２２）。
【００９３】
クライアント１はサーバ２から、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを受信し、これを処理する。そして、Ｆｉｎｉｓｈｅｄを処理することで、クライアント１はサーバ２を認証できたことになる（ステップＳ２３）。ここで、ＳＳＬハンドシェイクは確立されたことになる。つまり、これ以降でのクライアント１とサーバ２との間の通信では共通鍵暗号が使用される。
【００９４】
クライアント１は、乱数Ｂを共通鍵で暗号化し（ステップＳ２４）、サーバ２に対して、暗号化された乱数Ｂを送信する（ステップＳ２５）。ここの暗号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣの生成、および暗号化を行う。
【００９５】
なお、乱数Ｂは平分で送信しても危険でなく、暗号化の必要はないが、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるものとする。
【００９６】
サーバ２はクライアント１から、暗号化された乱数Ｂを受信し（ステップＳ２６）、暗号化された乱数Ｂを、共通鍵で復号化する（ステップＳ２７）。なおここの復号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣのチェックも行う。
【００９７】
サーバ２は、自ら算出した乱数Ｂと、復号した乱数Ｂとを比較（照合）し、クライアント１がパスワードを知っている正規クライアントか否かを判断する。
【００９８】
なお、乱数Ｂによる暗号がＸＯＲ処理でない場合は、サーバ２は、ステップＳ１９で復号化したデータとステップＳ２０で生成したデータとを保存しておき、この乱数Ｂを取得した時点で、ステップＳ２０で生成したデータに対して乱数Ｂで暗号化を行い、そして、この乱数Ｂで暗号したデータとステップＳ１９で復号化したデータとを比較すればよい。
【００９９】
なお、Ｆｉｎｉｓｈｅｄのデータ部に対する暗号化の順番は、ここでは乱数Ｂを先に、共通鍵を後として説明したが、逆に行うことも可能である。但し、処理が少し面倒になるので、好ましくない。また、先に説明したように、Ｆｉｎｉｓｈｅｄのデータ部を２重暗号化せずに、乱数Ｂのみで暗号するものとしてもよい。
【０１００】
なお、乱数Ｂはそのものでも、データ整形されたものであってもよい。乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないため、サーバ２はプリマスターシークレットを求めた際に、受信したデータに欠損があるかや、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ  ｒｏｌｌｂａｃｋ  ａｔｔａｃｋｓ）を受けているかを知ることができない。
【０１０１】
そこでバージョン情報や暗号ブロックフォーマットデータを、乱数Ｂを共通鍵として、適当な共通鍵暗号化方式を用いて暗号化し、これを新たな認証データとするとよい。この部分の具体的な手続について図７を用いて後述する。
【０１０２】
以上説明したように本実施の形態では、ＳＳＬ／ＴＬＳ暗号通信の仕様を一部改変するだけで、ＰＡＫＥ認証を行うことができる。
【０１０３】
また、本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第３者から見ればＳＳＬ／ＴＬＳ暗号通信の仕様に従っているので（図１のＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、図１のクライアント１が送信するＦｉｎｉｓｈｅｄはＳＳＬ／ＴＬＳ暗号通信に従っていないが、暗号化データのため、第３者には、ＳＳＬ／ＴＬＳ暗号通信に従っているか否かは判断できない）、図１は、第３者から見れば、通常のＳＳＬ／ＴＬＳネゴシエーションに見える。
【０１０４】
従って、ＳＳＬ／ＴＬＳ暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、ＰＡＫＥ認証を行うことが可能である。
【０１０５】
しかも、ＳＳＬ／ＴＬＳ暗号通信でＰＡＫＥ認証を行いながらも、公開鍵暗号の実施回数は１回のみなので、装置にかかる負荷は小さい。
【０１０６】
なお図１では、ＳＳＬ／ＴＬＳネゴシエーション後、直ちにクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバが合図をし、それを受けてクライアント認証を行うものとしてもよい。
【０１０７】
従って、乱数Ｂをワンタイムパスワードとして利用することも可能である。逆に言えば、図１のＳＳＬ／ＴＬＳネゴシエーションを、ワンタイムパスワード生成手段として扱うことも可能である。
【０１０８】
なお、このＳＳＬ／ＴＬＳネゴシエーションをワンタイムパスワード生成手段としてのみ扱い、暗号通信を行わない場合は、プリマスターキーやマスターキーを乱数Ｂの代りにワンタイムパスワードとして扱うことも可能であるが、ＳＳＬ／ＴＬＳネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。
【０１０９】
また、上述したＦｉｎｉｓｈｅｄのデータ部とは、通常のＳＳＬハンドシェイクの処理と同様に、クライアント１とサーバ２との間でのＳＳＬハンドシェイクでのこれまでのやり取りのデータ（以下、ＳＳＬハンドシェイクデータと称する）に関する情報である。即ち、Ｆｉｎｉｓｈｅｄのデータ部が生成されるステップＳ１０より前のＳＳＬハンドシェイクデータとは、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅであるので、これらの信号に基づいてクライアント１はＦｉｎｉｓｈｅｄのデータ部を生成する。
【０１１０】
一方、サーバ２にとっても、Ｃｌｉｅｎｔ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅはすでにクライアント１との間で通信した情報であるため、クライアント１から生成されるＦｉｎｉｓｈｅｄのデータ部を自ら算出することができる。即ち、Ｆｉｎｉｓｈｅｄのデータ部とは、サーバ２にとっても既知のデータである。これにより、既知のデータであるＦｉｎｉｓｈｅｄのデータ部を用いて乱数Ｂを算出することができる。
【０１１１】
そして、Ｆｉｎｉｓｈｅｄ（第２の信号）は一般的なＳＳＬハンドシェイクでは検証信号として使用される。つまり、サーバ２は共通鍵を用いて復号したＦｉｎｉｓｈｅｄのデータ部と、自ら生成したデータ部とを照合することで、正しくＳＳＬハンドシェイク行えたかどうかを検証できる。例えば、ＳＳＬハンドシェイクの途中で悪意の第３者によってＳＳＬ暗号通信で行う暗号方式を勝手に変更されていた場合、Ｆｉｎｉｓｈｅｄを受信することで気づくことができる。
【０１１２】
また、ステップＳ７において、乱数Ａを公開鍵で暗号化したが、乱数Ａに基づく情報であればよい。即ち、乱数Ａから生成される共通鍵を算出できる情報であればよく、特に限定するものではない。
【０１１３】
また、ステップＳ１１においては、乱数Ｂに基づく情報を共通鍵で暗号化すればよい。乱数Ｂに基づく情報とは、乱数Ｂそのものでもよく、ハッシュ化した乱数Ｂでもよく、本実施の形態のように乱数Ｂによって暗号化されたデータ部でもよい。
【０１１４】
また、ステップＳ２２において、サーバ２がＦｉｎｉｓｈｅｄを生成し、クライアント１にこれを送信するということは、乱数Ｂを算出できたことを意味する。即ち、ステップ２３において、クライアント１はＦｉｎｉｓｈｅｄを受信することにより、サーバ２がパスワードを有する正規のサーバであることを認証することができる。なお、サーバ２がパスワードを有することを証明する方法としてはこの限りではなく、クライアント１が乱数Ｂを算出できる情報をサーバ２がクライアント１に送信してもよい。以上より、クライアント１は乱数Ｂに基づいてサーバ２を認証できる。
【０１１５】
また、本実施の形態では、鍵交換信号であるＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅと乱数Ｂおよび検証データを送る信号であるＦｉｎｉｓｈｅｄとはＳＳＬの仕様に従って連続的に送信する。すなわち、クライアント１はＣｌｉｅｎｔ  Ｋｅｙ  ＥｘｃｈａｎｇｅとＦｉｎｉｓｈｅｄとの間にサーバ２からの信号を受信しない。つまり、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅを送信後、サーバ２からの返答を待たずして、検証データであるＦｉｎｉｓｈｅｄを送信している。このため、クライアント１はサーバ２とのパスワード認証を短縮して行うことができる。なお、Ｃｌｉｅｎｔ  Ｋｅｙ  ＥｘｃｈａｎｇｅとＦｉｎｉｓｈｅｄとを同時に、あるいは１つの信号として送信してもよい。
【０１１６】
図２は、本発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第１例を示す図である。また図３は、本発明の実施の形態１におけるクライアント側のフローチャートの一例を示す図、図４は、本発明の実施の形態１におけるサーバ側のフローチャートの一例を示す図である。次に、この図２、図３、図４を用いて説明を行う。また、以下の説明において図１を用いて説明したステップＳ１〜Ｓ２８に対応させている。
【０１１７】
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信、および、ＰＡＫＥ認証を行う。
【０１１８】
（図３−（１））はじめに、ＳＳＬネゴシエーション部４００がＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを生成し、これをデータ送信部３００に送る（ステップＳ１）。
【０１１９】
（図３−（２））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを送信する（ステップＳ１）。
【０１２０】
（図３−（３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０１２１】
（図４−（１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２１０は、クライアント１が送信したＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部２１０は、このＣｌｉｅｎｔ  Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを解釈（処理）するＳＳＬネゴシエーション部４１０に送る。
【０１２２】
（図４−（２））ＳＳＬネゴシエーション部４１０は、Ｃｌｉｅｎｔ  Ｈｅｌｌｏメッセージを処理する（ステップＳ２）。
【０１２３】
（図４−（３））ＳＳＬネゴシエーション部４１０は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ（公開鍵の情報を含む）、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅを生成し、これをデータ送信部３１０に送る（ステップＳ３）。
【０１２４】
（図４−（４））データ送信部３１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ／Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅメッセージを送信する（ステップＳ３）。
【０１２５】
（図４−（５））その後、サーバ２は再びクライアント１からのメッセージ受信待ち状態になる。
【０１２６】
（図３−（３））クライアント１のデータ受信部２００は、サーバ２が送信したＳｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅメッセージを、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅメッセージを解釈（処理）するＳＳＬネゴシエーション部４００に送る。
【０１２７】
（図３−（４））ＳＳＬネゴシエーション部４００は、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ、Ｓｅｒｖｅｒ  Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ  Ｈｅｌｌｏ  Ｄｏｎｅメッセージを処理し、公開鍵Ｅと公開鍵Ｎ（モジュラス）を取得する（ステップＳ４）。なお、サーバ証明書のチェックは行っても行わなくてもどちらでも構わない。
【０１２８】
（図３−（５））ＳＳＬネゴシエーション部４００は乱数生成部５００に指示して、乱数Ａを生成させる（ステップＳ５）。なお、乱数Ａのデータ長は、公開鍵Ｎ（モジュラス）のデータ長に等しい。
【０１２９】
（図３−（６））共通鍵生成部８００は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ  ｓｅｃｒｅｔ）を生成する。そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部８００は、この共通鍵を、暗号・復号化、およびＭＡＣ処理を行う共通鍵暗号・復号部８５０に渡す（ステップＳ６）。
【０１３０】
（図３−（７））公開鍵暗号部６００は、乱数Ａを公開鍵Ｅと公開鍵Ｎで暗号化する（ステップＳ７）。
【０１３１】
（図３−（８））パスワード暗号部７００は、公開鍵で暗号化された乱数Ａを、パスワードで暗号化し、２重暗号された乱数Ａを求める（ステップＳ８）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
【０１３２】
なおフローチャートには示していないが、このパスワードはユーザが、パスワードを入力する入力部７５０を介して、クライアント１に記憶させたパスワードとすることもできる。なおこの場合、パスワードを入力するタイミングは、事前、若しくはパスワードが必要になった時点とする。
【０１３３】
（図３−（９））ＳＳＬネゴシエーション部４００は、２重暗号された乱数ＡをＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔとして、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅを生成する。
【０１３４】
（図３−（１０））続いてＳＳＬネゴシエーション部４００は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃを生成する（ステップＳ９）。
【０１３５】
（図３−（１１））続いてＳＳＬネゴシエーション部４００は、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含まない）を生成する（ステップＳ１０）。
【０１３６】
（図３−（１２））ＳＳＬネゴシエーション部４００は乱数生成部５００（乱数生成手段）に指示して、乱数Ｂを生成させる。乱数Ｂは、共通鍵暗号・復号部８５０（共通鍵暗号化手段）に渡される（ステップＳ１１）。
【０１３７】
（図３−（１３））共通鍵暗号・復号部８５０（共通鍵暗号化手段）は、ＳＳＬネゴシエーション部４００から渡されたＦｉｎｉｓｈｅｄメッセージのデータ部のＭＡＣを求め、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）と乱数ＢとのＸＯＲ処理を行い、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を暗号化する（ステップＳ１１）。また、共通鍵暗号・復号部８５０は、この暗号化されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を、共通鍵で暗号化し、２重暗号されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を求める（ステップＳ１２）。
【０１３８】
（図３−（１４））ＳＳＬネゴシエーション部４００は、２重暗号されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）からＦｉｎｉｓｈｅｄメッセージを生成する。そして、ＳＳＬネゴシエーション部４００は生成したＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージをデータ送信部３００に送る。
【０１３９】
（図３−（１５））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを送信する（ステップＳ１３）。
【０１４０】
（図３−（１６））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
【０１４１】
（図４−（５））データ受信部２１０は、クライアント１が送信したＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１１０を介して受信する（ステップＳ１４）。データ受信部２１０は、このＣｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを解釈するＳＳＬネゴシエーション部４１０に送る。
【０１４２】
（図４−（６））ＳＳＬネゴシエーション部４１０は、Ｃｌｉｅｎｔ  Ｋｅｙ  ＥｘｃｈａｎｇｅメッセージからＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、つまり２重暗号された乱数Ａを読み出す。
【０１４３】
（図４−（７））パスワード復号部７１０は、２重暗号された乱数Ａをパスワードで復号化することによって、公開鍵Ｅと公開鍵Ｎで暗号化された乱数Ａを求める（ステップＳ１５）。
【０１４４】
（図４−（８））公開鍵復号部６１０は、公開鍵Ｅと公開鍵Ｎで暗号化された乱数Ａを、公開鍵Ｅと対となる秘密鍵Ｄと公開鍵Ｎで復号化し、乱数Ａを求める（ステップＳ１６）。
【０１４５】
（図４−（９））共通鍵生成部８１０は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレットを生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部８１０は、この共通鍵を、暗号・復号化、およびＭＡＣ処理を行う共通鍵暗号・復号部８６０に渡す（ステップＳ１７）。
【０１４６】
なお先に説明したように、乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ  ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないので、ＳＳＬネゴシエーション部４１０はこのチェックは行わない。ここはＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
【０１４７】
（図４−（１０））ＳＳＬネゴシエーション部４１０は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃメッセージを処理する（ステップＳ１８）。
【０１４８】
（図４−（１１））ＳＳＬネゴシエーション部４１０は、Ｆｉｎｉｓｈｅｄメッセージから２重暗号されたデータ部（ＭＡＣを含む）を読み出す。そしてこの２重暗号されたデータ部（ＭＡＣを含む）を共通鍵暗号・復号部８６０に渡す。
【０１４９】
（図４−（１２））共通鍵暗号・復号部８６０は、２重暗号されたデータ部（ＭＡＣを含む）を共通鍵で復号化し、乱数Ｂで暗号化されたデータ部（ＭＡＣを含む）を求める（ステップＳ１９）。
【０１５０】
（図４−（１３））ＳＳＬネゴシエーション部４１０は、クライアントが生成すべきＦｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）を、自ら計算する（ステップＳ２０）。また図示していないが、ＳＳＬネゴシエーション部４１０は、このＦｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）を共通鍵暗号・復号部８６０に渡し、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）のＭＡＣを計算し、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）を取得するものとする。
【０１５１】
（図４−（１４））認証データ取得部９１０は、乱数Ｂで暗号化（ＸＯＲ処理）されたＦｉｎｉｓｈｅｄのデータ部と、ＳＳＬネゴシエーション部４１０が計算して求めたＦｉｎｉｓｈｅｄのデータ部とのＸＯＲ処理を行い、乱数Ｂを求める（ステップＳ２１）。
【０１５２】
（図４−（１５））ＳＳＬネゴシエーション部４１０は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部３１０に送る（ステップＳ２２）。
【０１５３】
（図４−（１６））データ送信部３１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを送信する（ステップＳ２２）。
【０１５４】
（図４−（１７））その後、サーバ２は再びクライアント１からのメッセージ受信待ち状態になる。
【０１５５】
（図３−（１６））クライアント１のデータ受信部２００は、サーバ２が送信したＣｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２００は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを解釈するＳＳＬネゴシエーション部４００に送る（ステップＳ２３）。
【０１５６】
（図３−（１７））ＳＳＬネゴシエーション部４００は、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃメッセージを処理する。
【０１５７】
（図３−（１８））ＳＳＬネゴシエーション部４００は、Ｆｉｎｉｓｈｅｄメッセージを処理する。なお、このＦｉｎｉｓｈｅｄメッセージを処理することで、クライアント１はサーバ２を認証できたことになる（ステップＳ２３）。
【０１５８】
（図３−（１９））共通鍵暗号・復号部８５０は、乱数Ｂを共通鍵で暗号化し、これをデータ送信部３００に送る（ステップＳ２４）。
【０１５９】
（図３−（２０））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、この共通鍵で暗号化された乱数Ｂを送信する（ステップＳ２５）。なおここの暗号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣの生成、および暗号化も行う。なお、乱数Ｂは平分で送信しても危険でなく、暗号化の必要はないが、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるものとする。
【０１６０】
（図４−（１７））データ受信部２１０は、クライアント１が送信した共通鍵で暗号化された乱数Ｂを、ネットワーク制御装置１１０を介して受信する。データ受信部２１０は、この共通鍵で暗号化された乱数Ｂを、共通鍵暗号・復号部８６０に送る（ステップＳ２６）。
【０１６１】
（図４−（１８））共通鍵暗号・復号部８６０は、暗号化された乱数Ｂを共通鍵で復号化し、乱数Ｂを求める（ステップＳ２７）。
【０１６２】
（図４−（１９））認証部９２０は、自ら計算し求めた乱数Ｂと、復号した乱数Ｂとを比較（照合）し、クライアントがパスワードを知っている正規クライアントか否かを判断する（ステップＳ２８）。
【０１６３】
次に、図７を用いてクライアント１およびサーバ２の構成の他の例について説明する。図７は、発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第２例を示す図である。
【０１６４】
ここでは乱数Ｂを共通鍵としてバージョン情報を暗号化し、これを乱数Ｂの代わりの認証データとしている。
【０１６５】
クライアント１は、共通鍵で暗号した乱数Ｂの代りに、共通鍵暗号・復号部８５０（共通鍵暗号化手段）で、乱数Ｂを共通鍵として暗号化したバージョン情報をサーバ２に渡している。
【０１６６】
サーバ２は、乱数Ｂで暗号化されたバージョン情報を、共通鍵暗号・復号部８６０（共通鍵暗号化手段）で計算して求めた乱数Ｂを共通鍵として復号し、この求めたバージョン情報とあるべきバージョン情報とを、認証部９２０で照合している。なおこの共通鍵暗号はＸＯＲ処理等のような単純な暗号化ではなく、第３者が逆算できないような複雑な共通鍵暗号とした方が好ましい。なお、図２および図７において、説明をわかりやすくするために、暗号および（または）復号を行う機能ブロックを複数に分けて説明したが、勿論、１つの機能ブロックが複数の暗号処理および（または）復号処理を行ってもよい。
【０１６７】
次に、図５を用いてクライアント１およびサーバ２のハードウェアの構成について説明する。図５は、本発明の実施の形態１におけるクライアントおよびサーバのハードウェア構成の一例を示す図である。
【０１６８】
クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、キーボード等の入力装置５０とネットワークのデータ送受信を実行するＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）／ＰＨＹ４０を備える。
【０１６９】
一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ３１、ネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ４１を備える。
【０１７０】
また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ４０とＭＡＣ／ＰＨＹ４１を介してネットワークで接続されている。
【０１７１】
はじめにクライアント１のハードウェア構成に関して説明を行う。図３に示したクライアント１の各処理部は、ＣＰＵ１０、およびＲＡＭ２０で実行される。但し、入力部７５０は、入力装置５０を外部インターフェースとして動作させ、ユーザが入力したパスワードを取得する。
【０１７２】
乱数生成部５００（乱数生成手段）が生成した乱数Ａと乱数Ｂ、および、共通鍵生成部８００が生成した共通鍵は、ＲＡＭ２０に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。
【０１７３】
また、サーバ２からＳＳＬネゴシエーション部４００が取得した公開鍵Ｅと公開鍵ＮもＲＡＭ２０に保存されるが、公開鍵は新たな公開鍵を取得した際に上書きするものとすればよく、不必要になった時点で直ちに消去する必要はない。
【０１７４】
ＭＡＣ／ＰＨＹ４０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
【０１７５】
次に、サーバ２のハードウェア構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、およびＲＡＭ２１で実行される。
【０１７６】
クライアント１から取得した乱数Ａと乱数Ｂ、および、共通鍵生成部８１０が生成した共通鍵は、ＲＡＭ２１に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。
【０１７７】
次に、秘密鍵Ｄと公開鍵Ｎ、および、パスワードはＲＯＭ３１に保存されるが、利用時にＲＡＭ２１に移動されてもよい。なお安全上は、秘密鍵Ｄは耐タンパ装置等、セキュリティの高いメモリに保存するのが好ましい。
【０１７８】
ＭＡＣ／ＰＨＹ４１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１１０を実現するものである。
【０１７９】
（実施の形態２）
以下、図６を用いて実施の形態２について説明する。図６は、本発明の実施の形態２におけるＰＡＫＥ認証を示すシーケンス図である。具体的には、ステップＳ２５以降の処理が異なる。実施の形態１では、クライアントはサーバに対して、乱数Ｂをデータとして提示しているが、本実施の形態では、クライアント１はサーバ２に対して、ＳＳＬ／ＴＬＳネゴシエーションの中で乱数Ｂを提示している。以下、本実施の形態では、ステップＳ２５以降の処理をステップＳ３０〜Ｓ３６として説明する。
【０１８０】
クライアント１がサーバ２に対して、ＳＳＬの再接続を行う。具体的には、クライアント１はＳｅｓｓｉｏｎ  ＩＤに、ステップＳ４で受信したＳｅｒｖｅｒ  Ｈｅｌｌｏで指定されたＳｅｓｓｉｏｎ  ＩＤを設定し、かつ、Ｒａｎｄｏｍ  Ｂｙｔｅｓに乱数Ｂを設定したＣｌｉｅｎｔ  Ｈｅｌｌｏを生成し、これをサーバ２に送信する（ステップ３０）。なお、ＳＳＬ／ＴＬＳの再接続なので、共通鍵生成には、すでに生成したマスターシークレットが利用される。
【０１８１】
また、ＳＳＬの再接続を行う前に、一端ＴＣＰポートをクローズしない場合は、これ以降のＳＳＬ／ＴＬＳネゴシエーションでは、メッセージのデータ部は共通鍵で暗号化されるが、説明を簡単にするため、ここではメッセージのデータ部は非暗号であるものとして説明を行う。
【０１８２】
なおここでは、乱数ＢをＲａｎｄｏｍ  Ｂｙｔｅｓに設定したが、乱数Ｂの設定箇所はこれに限られるものではなく、例えば、Ｃｌｉｅｎｔ  Ｈｅｌｌｏの拡張データ（ｅｘｔｒａ  ｄａｔａ）等、ＳＳＬ／ＴＬＳネゴシエーションで利用する各メッセージの他の部分に挿入してもよい。
【０１８３】
サーバ２はクライアント１から送信されたＣｌｉｅｎｔ  Ｈｅｌｌｏを受信し、処理する（ステップＳ３１）。
【０１８４】
サーバ２は自らが計算して保持する乱数Ｂと、Ｃｌｉｅｎｔ  Ｈｅｌｌｏから取得した乱数Ｂとを比較（照合）する。ここで一致すれば、クライアント１はパスワードを知る正しいクライアントであると判断できる。これにより、クライアント認証が実施される（ステップＳ３２）。
【０１８５】
そして、サーバ２はクライアント１に対してＳｅｒｖｅｒ  Ｈｅｌｌｏ、Ｃｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、送信する（ステップＳ３３）。
【０１８６】
クライアント１はこれらを受信し、処理する（ステップＳ３４）。そして、クライアント１はサーバ２に対してＣｈａｎｇｅ  Ｃｉｐｈｅｒ  Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、送信する（ステップＳ３５）。サーバ２はこれらを受信し、処理する（ステップＳ３６）。
【０１８７】
なお本実施の形態では、ＳＳＬ／ＴＬＳネゴシエーション後、直ちにＳＳＬ／ＴＬＳの再接続、即ちクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバ２がＨｅｌｌｏ  Ｒｅａｕｅｓｔ等で合図をし、それを受けてクライアント認証を行うものとしてもよい。
【０１８８】
なおこの図６に示す一連のＳＳＬ／ＴＬＳネゴシエーションは乱数Ｂの設定、および、クライアント認証を除けば、すべてＳＳＬ／ＴＬＳ暗号通信の仕様に従っている。
【０１８９】
本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第３者から見ればＳＳＬ／ＴＬＳ暗号通信の仕様に従っているので（図６のＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、クライアント１が送信するＦｉｎｉｓｈｅｄはＳＳＬ／ＴＬＳ暗号通信に従っていないが、暗号化データのため、第３者には、ＳＳＬ／ＴＬＳ暗号通信に従っているか否かは判断できない）、本実施の形態も同様に、第３者から見れば、通常のＳＳＬ／ＴＬＳネゴシエーションに見える。
【０１９０】
従って、ＳＳＬ／ＴＬＳ暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、ＰＡＫＥ認証を行うことが可能である。
【０１９１】
しかも、ＳＳＬ／ＴＬＳ暗号通信でＰＡＫＥ認証を行いながらも、公開鍵暗号の実施回数は１回のみなので、装置にかかる負荷は小さい。
【０１９２】
本実施の形態は実施の形態１と比較して、更に利点がある。
【０１９３】
通常、ＳＳＬ／ＴＬＳ暗号通信を行うアプリケーションプログラムは、ＳＳＬ／ＴＬＳ暗号通信機能を、アプリケーションプログラムとは別のＯｐｅｎＳＳＬのようなＳＳＬ／ＴＬＳ暗号通信モジュールを利用することで実現している。
【０１９４】
本実施の形態では、乱数Ｂ、つまり認証データの提示を、すべてＳＳＬ／ＴＬＳネゴシエーションの中で行っている。従って、アプリケーションプログラムがＳＳＬ／ＴＬＳ暗号通信モジュールに対して一度パスワードを与えれば、後はＳＳＬ／ＴＬＳ暗号通信モジュールがすべて実行できる。そのため、アプリケーションプログラムのつくりが複雑にならない。
【０１９５】
なお本実施の形態では、ＳＳＬ／ＴＬＳの再接続で乱数Ｂを提示したが、もう一度、通常のＳＳＬ／ＴＬＳネゴシエーションをやり直し、その中で乱数Ｂを提示してもよい。但し、この方法の場合、公開鍵暗号は２度実行しなければならず、装置にかかる負荷が大きくなる。また、通常のＳＳＬ／ＴＬＳネゴシエーションをやり直す場合は、乱数Ｂの代りに、前回のＳＳＬ／ＴＬＳネゴシエーションで生成したプリマスターシークレットやマスターシークレットを提示することも可能である。但し、前回のＳＳＬ／ＴＬＳネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。
【０１９６】
なおここでは、ＳＳＬ／ＴＬＳの再接続を行っているが、ＳＳＬ／ＴＬＳの再接続の負荷は公開鍵暗号に比べれば非常に小さいので、パフォーマンス的には問題にならない。
【産業上の利用可能性】
【０１９７】
本発明にかかるＰＡＫＥ認証は、ＳＳＬ／ＴＬＳネゴシエーション中に実施できるので、ファイヤーウォール等の通信機器との親和性がよく、しかも公開鍵暗号の回数を１回に制限できるため、サーバ費用の低減を図れる等有用である。
【符号の説明】
【０１９８】
１    クライアント
２    サーバ
１０    ＣＰＵ（クライアント側）
１１    ＣＰＵ（サーバ側）
２０    ＲＡＭ（クライアント側）
２１    ＲＡＭ（サーバ側）
３１    ＲＯＭ（サーバ側）
４０    ＭＡＣ／ＰＨＹ（クライアント側）
４１    ＭＡＣ／ＰＨＹ（サーバ側）
５０    入力装置
１００    ネットワーク制御装置（クライアント側）
１１０    ネットワーク制御装置（サーバ側）
２００    データ受信部（クライアント側）
２１０    データ受信部（サーバ側）
３００    データ送信部（クライアント側）
３１０    データ送信部（サーバ側）
４００    ＳＳＬネゴシエーション部（クライアント側）
４１０    ＳＳＬネゴシエーション部（サーバ側）
５００    乱数生成部
６００    公開鍵暗号部（クライアント側）
６１０    公開鍵復号部（サーバ側）
７００    パスワード暗号部（クライアント側）
７１０    パスワード復号部（サーバ側）
７５０    入力部
８００    共通鍵生成部（クライアント側）
８１０    共通鍵生成部（サーバ側）
８５０    共通鍵暗号・復号部（クライアント側）
８６０    共通鍵暗号・復号部（サーバ側）
９１０    認証データ取得部
９２０    認証部
【図１】
0005845393.tif 000002
【図２】
0005845393.tif 000003
【図３】
0005845393.tif 000004
【図４】
0005845393.tif 000005
【図５】
0005845393.tif 000006
【図６】
0005845393.tif 000007
【図７】
0005845393.tif 000008