パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、第1の乱数および第2の乱数を生成する乱数生成部と、前記他の暗号通信装置の公開鍵を用いて前記第1の乱数に基づく情報を暗号化する第1の暗号化部と、前記第1の暗号化部によって暗号化された前記第1の乱数に基づく情報を、前記パスワードを用いて暗号化する第2の暗号化部と、前記第2の乱数に基づく情報を前記第1の乱数を用いて暗号化する第3の暗号化部と、前記第2の暗号化部によって暗号化された前記第1の乱数に基づく情報を含む第1の信号、および前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報を含む第2の信号を前記他の暗号通信装置に送信する送信部と、を備える暗号通信装置。請求項1記載の暗号通信装置であって、前記送信部は、前記第1の信号と前記第2の信号とを連続的に前記他の暗号通信装置に送信する、暗号通信装置。請求項1または2記載の暗号通信装置であって、前記第3の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第1の乱数および前記第2の乱数を用いて暗号化する、暗号通信装置。請求項2記載の暗号通信装置であって、前記他の暗号通信装置からの信号を受信する受信部を更に有し、前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、前記送信部は前記第2の乱数を前記他の暗号通信装置に送信する、暗号通信装置。請求項3記載の暗号通信装置であって、前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴である、暗号通信装置。請求項5記載の暗号通信装置であって、前記送信部は、SSLハンドシェイクに基づいて前記第1の信号を鍵交換信号として送信すると共に、SSLハンドシェイクに基づいて前記第2の信号を検証信号として送信する、暗号通信装置。パスワードを共有する第1の暗号通信装置と第2の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、前記第1の暗号通信装置は、第1の乱数および第2の乱数を生成する乱数生成部と、前記第2の暗号通信装置の公開鍵を用いて前記第1の乱数を暗号化する第1の暗号化部と、前記第1の暗号化部によって暗号化された前記第1の乱数を前記パスワードを用いて暗号化する第2の暗号化部と、前記第2の乱数に基づく情報を前記第1の乱数を用いて暗号化する第3の暗号化部と、前記第2の暗号化部によって暗号化された前記第1の乱数を含む第1の信号、および前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報を含む第2の信号を前記第2の暗号通信装置に送信する送信部と、を有し、前記第2の暗号通信装置は、前記第1の信号および前記第2の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第2の暗号化部によって暗号化された前記第1の乱数を復号化し、前記第1の乱数を取得する復号化部と、前記復号化部が取得した前記第1の乱数を用いて、前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報から前記第2の乱数を算出する認証データ取得部と、を有する、暗号通信システム。しかしながら、SSL/TLS暗号通信にそのままPAKE認証を利用すると、共通鍵を交換にコンピュータにとって負荷の大きい公開鍵暗号を少なくとも2回以上利用する必要があった。即ち、SSL/TLSのハンドシェイク処理において公開鍵暗号を行い、更にこのハンドシェイク処理後にPAKE認証を行うためにもう1度公開鍵暗号を行っていた。また、特にサーバ側は公開鍵暗号における秘密鍵を利用した復号を行うため、CPUに非常に重い負荷が生じた。一般的にサーバは複数のクライアントを相手にするので、常時、多量の公開鍵暗号を実行しなければならない。そのため、多くのSSL/TLSサーバは、高価なCPUやSSL/TLSアクセラレータボードを搭載している。このように公開鍵暗号を実行するのに要する費用は非常に大きく、コンピュータ購入費の半分以上のコストに相当するという見解もある。従って、公開鍵暗号の回数が倍以上になる影響は深刻であった。また、SSL/TLS暗号通信は、各種攻撃に対する防御ノウハウが蓄積されていて信頼性が高いのに対し、PAKE認証による暗号通信は、攻撃に対する知見が少なく、信頼性に欠ける。本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、普及しているSSL/TLS暗号通信で、PAKE認証を用いて中間者攻撃を安価でかつ簡単に抑制しつつも、CPUの負荷を低減することである。上述の課題を解決するために、本発明の暗号通信装置は、パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、第1の乱数および第2の乱数を生成する乱数生成部と、前記他の暗号通信装置の公開鍵を用いて前記第1の乱数に基づく情報を暗号化する第1の暗号化部と、前記第1の暗号化部によって暗号化された前記第1の乱数に基づく情報を、前記パスワードを用いて暗号化する第2の暗号化部と、前記第2の乱数に基づく情報を前記第1の乱数を用いて暗号化する第3の暗号化部と、前記第2の暗号化部によって暗号化された前記第1の乱数に基づく情報を含む第1の信号、および前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報を含む第2の信号を前記他の暗号通信装置に送信する送信部と、を備える。本発明の暗号通信装置によれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。また、本発明の暗号通信装置は、前記送信部は、前記第1の信号と前記第2の信号とを連続的に前記他の暗号通信装置に送信するように構成される。本発明の暗号通信装置のこの構成によれば、第2の乱数を用いて他の暗号通信装置の認証を行うことができる。本発明の暗号通信装置のこの構成によれば、既知のデータを第2の乱数で暗号化しているため、他の暗号通信装置からの計算結果を待たずして、第1の乱数を送信する第1の信号と、認証を行うための第2の信号を同時に送ることができる。即ち、他の暗号通信装置とのパスワード認証を短縮して行うことができる。また、本発明の暗号通信装置は、前記第3の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第1の乱数および前記第2の乱数を用いて暗号化するように構成される。本発明の暗号通信装置のこの構成によれば、他の暗号通信装置が既知データおよび第1の乱数から第2の乱数を算出した場合、他の暗号通信装置の認証を行うことができる。また、本発明の暗号通信装置は、前記他の暗号通信装置からの信号を受信する受信部を更に有し、前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、前記送信部は前記第2の乱数を前記他の暗号通信装置に送信するように構成される。本発明の暗号通信装置のこの構成によれば、第2の乱数を保持していることを他の暗号通信装置に通知できるため、他の暗号通信装置に自装置のパスワード認証をさせることができる。また、本発明の暗号通信装置は、前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴であるように構成される。本発明の暗号通信装置のこの構成によれば、他の暗号通信装置は自装置との通信履歴から自らこの通信履歴を算出することができる。このため、他の暗号通信装置は、例えば、悪意の第3者によって暗号方式の付け替えが行われたかどうかを確認できる。また、本発明の暗号通信装置は、前記送信部は、SSLハンドシェイクに基づいて前記第1の信号を鍵交換信号として送信すると共に、SSLハンドシェイクに基づいて前記第2の信号を前記第2の乱数の検証信号として送信するように構成される。本発明の暗号通信装置のこの構成によれば、SSLハンドシェイクのプロトコルを通過させるファイヤーウォールのチェックにかからずに第1の信号および第2の信号を他の暗号通信装置に送信することができる。即ち、SSLハンドシェイクに基づいて他の暗号通信装置のパスワード認証を安価に行うことができる。また、本発明の暗号通信システムは、パスワードを共有する第1の暗号通信装置と第2の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、前記第1の暗号通信装置は、第1の乱数および第2の乱数を生成する乱数生成部と、前記第2の暗号通信装置の公開鍵を用いて前記第1の乱数を暗号化する第1の暗号化部と、前記第1の暗号化部によって暗号化された前記第1の乱数を前記パスワードを用いて暗号化する第2の暗号化部と、前記第2の乱数に基づく情報を前記第1の乱数を用いて暗号化する第3の暗号化部と、前記第2の暗号化部によって暗号化された前記第1の乱数を含む第1の信号、および前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報を含む第2の信号を前記第2の暗号通信装置に送信する送信部と、を有し、前記第2の暗号通信装置は、前記第1の信号および前記第2の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第2の暗号化部によって暗号化された前記第1の乱数を復号化し、前記第1の乱数を取得する復号化部と、前記復号化部が取得した前記第1の乱数を用いて、前記第3の暗号化部によって暗号化された前記第2の乱数に基づく情報から前記第2の乱数を算出する認証データ取得部と、を有する。本発明の暗号通信システムによれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。また、本発明の暗号通信システムは、クライアントがサーバに対して、公開鍵とパスワードで暗号化した乱数Aを送信する、クライアントサーバ秘密鍵を保持する側をサーバと呼ぶ間のPAKE認証であって、クライアントは乱数生成手段、および共通鍵暗号化手段を有し、クライアントは乱数生成手段を用いて乱数Bを生成し、この乱数B乱数Bから生成されるデータを含むを共通鍵として、乱数A乱数Aから生成されるデータを含むを、前記共通鍵暗号化手段を用いて暗号化し、サーバがパスワードを保持することを確認する前に、この乱数Bによって暗号化された乱数Aをサーバに対して渡すものとし、クライアントは、サーバがパスワードを保持することを確認できたら、乱数B乱数Bから生成されるデータを含むをサーバに対して提示し、クライアントが乱数A、即ちパスワードを理解していることをサーバに対して伝達する、つまりクライアント認証を行うものとした。これによると、任意の値である乱数Bを用いて、クライアント認証を行うことが可能となる。なおこの乱数Bは、ワンタイムパスワードとして利用可能である。またこのような提示方法は、SSL/TLSネゴシエーションと親和性がよい。SSL/TLSネゴシエーションでは、クライアントは、公開鍵暗号で暗号したデータClientKeyExchangeと共に、その検証データFinishedも同時に送る。その時点ではクライアントは、まだサーバの検証データFinishedを入手していない。そのため、SSL/TLSネゴシエーションと同時にPAKE認証を行うと、オフライン攻撃が成立してしまう。しかし本発明の暗号通信システムによれば、クライアントが送信する検証データFinishedは乱数Bで暗号化されているので、その危険性は少ない。従ってSSL/TLSネゴシエーションの中でパスワード認証例えば、PAKE認証を実施できるようになる。これにより、1回の公開鍵暗号でSSL/TLSネゴシエーションとPAKE認証を行えるようになるので、サーバのCPUの負荷を小さくでき、サーバ費用を大幅に削減できる。なお、このようにSSL/TLSネゴシエーションでPAKE認証を行えば、ファイヤーウォール等の通信機器によって通信を遮断される危険性も減少する。このような課題を解決するために、本発明の暗号通信システムでは、SSL/TLSネゴシエーションSSL/TLSハンドシェイクの中で、クライアントがサーバに対して乱数Bを提示するものとした。これによると、SSL/TLS暗号通信処理を、アプリケーションプログラムではなく、OpenSSLのようなSSL/TLS暗号通信モジュールが行っている場合に、アプリケーションプログラムのつくりをより簡略にすることができる。アプリケーションプログラムが一端SSL/TLS暗号通信モジュールにパスワードを渡せば、後はSSL/TLS暗号通信モジュールがすべての処理を行える。また、本発明の暗号通信システムは、SSL/TLSの再接続を行うネゴシエーションの中で、クライアントがサーバに対して乱数Bを提示するものとした。これによると、1回の公開鍵暗号でSSL/TLSネゴシエーションとPAKE認証を行えるようになるので、サーバのCPUの負荷を小さくでき、サーバ費用を大幅に削減できる。また、本発明の暗号通信システムは、サーバは、クライアントから渡された前記共通鍵暗号化手段で暗号化された乱数A乱数Aから生成されるデータを含むと、乱数A乱数Aから生成されるデータを含むから、乱数B乱数Bから生成されるデータを含むを割り出すものとし、この割り出した乱数B乱数Bから生成されるデータを含むとクライアントから渡された乱数B乱数Bから生成されるデータを含むとを照合することで、クライアント認証を行うものとした。これによると、サーバは認証データである乱数Bだけを記憶しておけばよいので、サーバ側のSSL/TLS暗号通信モジュールのつくりを簡単にできる。また、本発明の暗号通信システムは、前記共通鍵暗号化手段がXOR処理であるものとした。これによると、サーバ側のSSL/TLS暗号通信モジュールが、非常に簡単、かつ迅速に乱数Bの割り出しを行えるようになる。また、本発明の暗号通信システムは、クライアントがサーバに乱数Bを提示するのに、この乱数B乱数Bから生成されるデータを含むを共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数B乱数Bから生成されるデータを含むを共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、この自ら暗号化した情報と、クライアントが暗号化した情報とを比較することで、クライアントが乱数Bを理解していることを確認するものとした。これによると、クライアントがサーバに既知の情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、PAKE認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第3者に分かるような既知の情報は埋め込めこめない。しかし、SSL/TLSネゴシエーションでは、バージョンロールバック攻撃Versionrollbackattacksを抑制するために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。そこで、本発明の暗号通信システムのように、バージョン情報等の既知の情報は、乱数Bで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、PAKE認証とSSL/TLSネゴシエーションを両立させることが可能となる。乱数Bの値を知らない悪意の第3者は、乱数Bで暗号化した偽バージョン情報を作成できないので、悪意の第3者は、クライアントサーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃Versionrollbackattacksを行うことは不可能である。また、本発明の暗号通信システムは、クライアントがサーバに乱数Bを提示するのに、この乱数B乱数Bから生成されるデータを含むを共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数B乱数Bから生成されるデータを含むを共通鍵として、暗号化されたサーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて復号化し、この自ら保持、若しくは生成できる情報と、復号化した情報とを比較することで、クライアントが乱数Bを理解していることを確認するものとした。これによると、クライアントがサーバに特定情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、PAKE認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第3者に分かるような既知の情報は埋め込めこめない。しかし、SSL/TLSネゴシエーションでは、バージョンロールバック攻撃Versionrollbackattacksを防ぐために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。そこで、本発明のように、バージョン情報等の既知の情報は、乱数Bで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、PAKE認証とSSL/TLSネゴシエーションを両立させることが可能となる。乱数Bの値を知らない悪意の第3者は、乱数Bで暗号化した偽バージョン情報を作成できないので、悪意の第3者は、クライアントサーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃Versionrollbackattacksを行うことは不可能である。鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による負荷を低減することができる。実施の形態1以下、本発明の実施の形態1を、図面を参照しながら説明する。図1は、本発明の実施の形態1におけるPAKE認証を示すシーケンス図である。ここでは、クライアント1とサーバ2とは、SSL/TLSネゴシエーションSSL/TLSハンドシェイク、SSLネゴシエーション、SSLハンドシェイクとも称する中に、PAKE認証も行う。なお説明を簡単にするために、ここで用いる公開鍵暗号はRSARivestShamirAdleman暗号として説明を行う。また、クライアント1とサーバ2の構成については、図2、図5等を用いて詳細に説明する。なお、クライアント1およびサーバ2は暗号通信装置の一例である。クライアント1がサーバ2に対してClientHelloを生成し、送信するステップS1。サーバ2はこのClientHelloを受信し、処理するステップS2。そして、サーバ2はクライアント1に対してServerHello、ServerCertificate公開鍵の情報を含む、ServerHelloDoneを生成し、送信するステップS3。クライアント1はこれらを受信し、処理する。なお、クライアント1は、ServerCertificateから公開鍵を取得するステップS4。クライアント1はClientKeyExchangeを生成するため、乱数A第1の乱数を生成する。なお、乱数Aのデータ長は、RSA暗号におけるモジュラスmodulusのデータ長に等しいステップS5。クライアント1は、乱数Aから共通鍵を生成する。詳細に説明すると、クライアント1は乱数Aの内、最後の48バイトをプリマスターシークレットpremastersecretとして扱う。なお、乱数Aの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、SSL/TLS暗号通信の仕様に合わせるために、最後の48バイトをプリマスターシークレットとする。次に、プリマスターシークレットからマスターシークレットmastersecretを生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成するステップS6。なおここで共通鍵とは、例えば、以下の鍵の総称であり、以下の同様である。client_write_MAC_secretserver_write_MAC_secretclient_write_keyserver_write_keyclient_write_IVブロック暗号利用時のみ必要server_write_IVブロック暗号利用時のみ必要次に、乱数Aをサーバ2から伝送された公開鍵で暗号化するステップS7。なお、本実施の形態では乱数Aを公開鍵で暗号するが、乱数Aそのものではなく、サーバ2が乱数Aを算出できる情報であればよい。なおこの暗号化の手順は、通常のSSL/TLS暗号通信の仕様とは異なるので、以下、差異を説明する。バージョン3.0以降のSSL/TLS暗号通信では、プリマスターシークレットは以下のように、2バイトのバージョン情報と46バイトの乱数Dで構成されている。struct{ProtocolVersionclient_version←バージョン情報2バイトopaquerandom[46]←乱数D46バイト}PreMasterSecret←プリマスターシークレット従って、乱数Aから生成されたプリマスターシークレットには、バージョン情報が設定されていない。ここはSSL/TLS暗号通信の仕様とは異なる。次に、SSL/TLS暗号通信では、このプリマスターシークレットは、以下のように、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingで整形される。0002パディング文字列00を含まない乱数E00PreMasterSecretここで、の記号は単なるデータの連結を意味する。なおこの全データ長は、RSA暗号におけるモジュラスmodulusのデータ長に等しいので、乱数Eのデータ長は以下のようになる。乱数Eのデータ長=モジュラスmodulusのデータ長-3-48SSL/TLS暗号通信では、この暗号ブロックフォーマット化されたプリマスターシークレットは公開鍵で暗号化される。一方、乱数Aはモジュラスmodulusのデータ長と等しく、乱数Aの構造は以下の通りである。乱数A=乱数CPreMasterSecretなお乱数Cのデータ長は、モジュラスmodulusのデータ長より、PreMasterSecretのデータ長、つまり48バイト分少ない。このように、0002パディング文字列00を含まない乱数E00の部分を乱数Cに置き換えているところも、SSL/TLS暗号通信の仕様とは異なる。つまり、乱数Aには、SSL/TLS暗号通信の仕様で定義されているプリマスターシークレットにおけるバージョン情報の設定、および、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingによるデータ整形がなされていない。なお、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingで整形しない。しかしこのようにすると、悪意の第3者がクライアントになりすまし、0とか1のような特殊なEncryptedPreMasterSecretをサーバ2に渡し、サーバ2が返すFinishedを見て、パスワードを類推するかもしれない。これを避けるには、サーバ2は、0とか1のような単純なEncryptedPreMasterSecretをエラーとして処理するか、若しくはパスワードの暗号方法を工夫すればよい。つまり、EncryptedPreMasterSecretが0や1であっても、パスワードで復号した場合に複雑な値が出現するようなものであれば問題ない。また、乱数Aに、プリマスターシークレットにおけるバージョン情報の設定、および、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingによるデータ整形を行わない理由は、オフライン攻撃を抑制するためである。悪意の第3者が正規サーバになりすます即ち、悪意の第3者がサーバ2として動作する場合、悪意の第3者は、自らが保持する秘密鍵と対となる公開鍵をクライアントに渡せる。従って、悪意の第3者は公開鍵暗号における復号化が可能である。一方パスワードの方も、オフラインであれば、パスワードは一般的に記憶できる程度の長さにするため、暗号鍵に比べビット長が短く、悪意の第3者にとっては、パスワードが取りうるすべての組合せを総当りで調べるのは難しくない。悪意の第3者は正規サーバになりすまし、クライアント1から2重暗号された乱数Aを取得する。そして、仮パスワードを設定し、2重暗号された乱数Aをこの仮パスワードと自らが保持する秘密鍵で復号化する。乱数Aにバージョン情報やフォーマットがあれば、これが出現するか否かで、想定したパスワードが正しいかを判定できる。悪意の第3者は、オフラインで仮パスワードを次々に設定すれば、いずれかの時点で、乱数Aにバージョン情報やフォーマットが出現するパスワードを探し当てることが可能であるオフライン攻撃。以上説明したように、このオフライン攻撃を避けるため、乱数Aにはバージョン情報設定やフォーマット化を行わない。次に、公開鍵で暗号化された乱数Aを、更にパスワードで暗号化し、2重暗号化された乱数Aを求めるステップS8。この手続きは、SSL/TLS暗号通信にはなく、PAKE認証のための処理である。そして、この2重暗号された乱数Aを、EncryptedPreMasterSecretとして、ClientKeyExchangeを生成する。ここで、ClientKeyExchangeは第1の信号の一例であり、サーバ2に乱数Aを送信するための鍵交換信号でもある。ChangeCipherSpecを生成しステップS9、Finishedの平分のデータ部を生成するステップS10。ここで、Finishedは、第2の信号の一例であり、検証データを送信するための検証信号でもある。クライアント1は乱数B第2の乱数を生成し、少なくともFinishedのデータ部で、共通鍵で暗号化する部分MACを含むを、乱数Bで暗号化する。乱数Bによる暗号化はここではXOR処理とするステップS11。この乱数Bによる暗号化処理手続きも、SSL/TLS暗号通信の仕様とは異なる。ここで、Finishedのデータ部を乱数Bで暗号化するのは、これも上述したオフライン攻撃を抑制するためである。仮に乱数Bで暗号化されていないFinishedをクライアント1がサーバ2に送信すると、悪意の第3者が正規サーバになりすました場合に、オフライン攻撃が成立する可能性がある。悪意の第3者は、オフラインで仮パスワードを次々に設定し、Finishedを自ら計算すれば、クライアント1から受信したFinishedと比較することで、いずれかの時点で、正しいパスワードを探し当てることが可能である。乱数Bで暗号化したデータ部を、更に共通鍵で暗号化し、データ部を2重暗号化するステップS12。ここでは、ファイヤーウォールのチェックにひっかからないためにSSL/TLS暗号通信の仕様に従う。即ち、この共通鍵による暗号はなくてもよいが、クライアント1はSSL/TLS暗号通信の仕様に基づいて共通鍵による暗号を行う。クライアント1はサーバ2に対して、ClientKeyExchange、ChangeCipherSpec、Finishedを送信するステップS13。サーバ2はクライアント1から、ClientKeyExchange、ChangeCipherSpec、Finishedを受信するステップS14。サーバ2は、ClientKeyExchangeのEncryptedPreMasterSecretにセットされた2重暗号化された乱数Aをパスワードで復号化し、公開鍵で暗号化された乱数Aを求めるステップS15。この手続きは、SSL/TLS暗号通信にはなく、PAKE認証のための処理である。サーバ2は、公開鍵で暗号化された乱数Aを秘密鍵で復号化するステップS16。サーバ2は、乱数Aの内、最後の48バイトをプリマスターシークレットとして扱う。なお、乱数Aの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、SSL/TLS暗号通信の仕様に合わせるために、最後の48バイトをプリマスターシークレットとする。次に、プリマスターシークレットからマスターシークレットmastersecretを生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。なお上述したように、乱数Aは、プリマスターシークレットにおけるバージョン情報の設定、および、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingによるデータ整形が行われていないので、サーバ2はこのチェックを行わない。ここもSSL/TLS暗号通信の仕様とは異なる。サーバ2は、ChangeCipherSpecを処理しステップS18、2重暗号化されたFinishedのデータ部を共通鍵で復号化するステップS19。そしてサーバ2は、クライアント1が生成したFinishedのデータ部を、独自に計算する。サーバ2は、乱数Bで暗号化されたFinishedのデータ部と、自ら計算して求めたFinishedのデータ部を比較して、乱数Bを求める。これもSSL/TLS暗号通信の仕様とは異なるステップS21。なお、クライアント1がサーバ2に対して乱数Bを提示できれば、クライアント1がサーバに提示したFinishedが正しいと証明できるので、この乱数Bは、クライアントが正規クライアントか否かを確かめる、つまりクライアント認証のための認証データとして扱える。サーバ2は、ChangeCipherSpec、Finishedを生成し、クライアント1に対してこれを送信する。なお、このFinishedの生成は、SSL/TLS暗号通信の仕様に従うステップS22。クライアント1はサーバ2から、ChangeCipherSpec、Finishedを受信し、これを処理する。そして、Finishedを処理することで、クライアント1はサーバ2を認証できたことになるステップS23。ここで、SSLハンドシェイクは確立されたことになる。つまり、これ以降でのクライアント1とサーバ2との間の通信では共通鍵暗号が使用される。クライアント1は、乱数Bを共通鍵で暗号化しステップS24、サーバ2に対して、暗号化された乱数Bを送信するステップS25。ここの暗号化は、SSL/TLS暗号通信の仕様に従うので、MACの生成、および暗号化を行う。なお、乱数Bは平分で送信しても危険でなく、暗号化の必要はないが、SSL/TLS暗号通信の仕様に合わせるものとする。サーバ2はクライアント1から、暗号化された乱数Bを受信しステップS26、暗号化された乱数Bを、共通鍵で復号化するステップS27。なおここの復号化は、SSL/TLS暗号通信の仕様に従うので、MACのチェックも行う。サーバ2は、自ら算出した乱数Bと、復号した乱数Bとを比較照合し、クライアント1がパスワードを知っている正規クライアントか否かを判断する。なお、乱数Bによる暗号がXOR処理でない場合は、サーバ2は、ステップS19で復号化したデータとステップS20で生成したデータとを保存しておき、この乱数Bを取得した時点で、ステップS20で生成したデータに対して乱数Bで暗号化を行い、そして、この乱数Bで暗号したデータとステップS19で復号化したデータとを比較すればよい。なお、Finishedのデータ部に対する暗号化の順番は、ここでは乱数Bを先に、共通鍵を後として説明したが、逆に行うことも可能である。但し、処理が少し面倒になるので、好ましくない。また、先に説明したように、Finishedのデータ部を2重暗号化せずに、乱数Bのみで暗号するものとしてもよい。なお、乱数Bはそのものでも、データ整形されたものであってもよい。乱数Aは、プリマスターシークレットにおけるバージョン情報の設定、および、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingによるデータ整形が行われていないため、サーバ2はプリマスターシークレットを求めた際に、受信したデータに欠損があるかや、バージョンロールバック攻撃Versionrollbackattacksを受けているかを知ることができない。そこでバージョン情報や暗号ブロックフォーマットデータを、乱数Bを共通鍵として、適当な共通鍵暗号化方式を用いて暗号化し、これを新たな認証データとするとよい。この部分の具体的な手続について図7を用いて後述する。以上説明したように本実施の形態では、SSL/TLS暗号通信の仕様を一部改変するだけで、PAKE認証を行うことができる。また、本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第3者から見ればSSL/TLS暗号通信の仕様に従っているので図1のEncryptedPreMasterSecret、図1のクライアント1が送信するFinishedはSSL/TLS暗号通信に従っていないが、暗号化データのため、第3者には、SSL/TLS暗号通信に従っているか否かは判断できない、図1は、第3者から見れば、通常のSSL/TLSネゴシエーションに見える。従って、SSL/TLS暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、PAKE認証を行うことが可能である。しかも、SSL/TLS暗号通信でPAKE認証を行いながらも、公開鍵暗号の実施回数は1回のみなので、装置にかかる負荷は小さい。なお図1では、SSL/TLSネゴシエーション後、直ちにクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバが合図をし、それを受けてクライアント認証を行うものとしてもよい。従って、乱数Bをワンタイムパスワードとして利用することも可能である。逆に言えば、図1のSSL/TLSネゴシエーションを、ワンタイムパスワード生成手段として扱うことも可能である。なお、このSSL/TLSネゴシエーションをワンタイムパスワード生成手段としてのみ扱い、暗号通信を行わない場合は、プリマスターキーやマスターキーを乱数Bの代りにワンタイムパスワードとして扱うことも可能であるが、SSL/TLSネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。また、上述したFinishedのデータ部とは、通常のSSLハンドシェイクの処理と同様に、クライアント1とサーバ2との間でのSSLハンドシェイクでのこれまでのやり取りのデータ以下、SSLハンドシェイクデータと称するに関する情報である。即ち、Finishedのデータ部が生成されるステップS10より前のSSLハンドシェイクデータとは、ClientHello、ServerHello、ServerCertificate、ServerHelloDoneであるので、これらの信号に基づいてクライアント1はFinishedのデータ部を生成する。一方、サーバ2にとっても、ClientHello、ServerHello、ServerCertificate、ServerHelloDoneはすでにクライアント1との間で通信した情報であるため、クライアント1から生成されるFinishedのデータ部を自ら算出することができる。即ち、Finishedのデータ部とは、サーバ2にとっても既知のデータである。これにより、既知のデータであるFinishedのデータ部を用いて乱数Bを算出することができる。そして、Finished第2の信号は一般的なSSLハンドシェイクでは検証信号として使用される。つまり、サーバ2は共通鍵を用いて復号したFinishedのデータ部と、自ら生成したデータ部とを照合することで、正しくSSLハンドシェイク行えたかどうかを検証できる。例えば、SSLハンドシェイクの途中で悪意の第3者によってSSL暗号通信で行う暗号方式を勝手に変更されていた場合、Finishedを受信することで気づくことができる。また、ステップS7において、乱数Aを公開鍵で暗号化したが、乱数Aに基づく情報であればよい。即ち、乱数Aから生成される共通鍵を算出できる情報であればよく、特に限定するものではない。また、ステップS11においては、乱数Bに基づく情報を共通鍵で暗号化すればよい。乱数Bに基づく情報とは、乱数Bそのものでもよく、ハッシュ化した乱数Bでもよく、本実施の形態のように乱数Bによって暗号化されたデータ部でもよい。また、ステップS22において、サーバ2がFinishedを生成し、クライアント1にこれを送信するということは、乱数Bを算出できたことを意味する。即ち、ステップ23において、クライアント1はFinishedを受信することにより、サーバ2がパスワードを有する正規のサーバであることを認証することができる。なお、サーバ2がパスワードを有することを証明する方法としてはこの限りではなく、クライアント1が乱数Bを算出できる情報をサーバ2がクライアント1に送信してもよい。以上より、クライアント1は乱数Bに基づいてサーバ2を認証できる。また、本実施の形態では、鍵交換信号であるClientKeyExchangeと乱数Bおよび検証データを送る信号であるFinishedとはSSLの仕様に従って連続的に送信する。すなわち、クライアント1はClientKeyExchangeとFinishedとの間にサーバ2からの信号を受信しない。つまり、ClientKeyExchangeを送信後、サーバ2からの返答を待たずして、検証データであるFinishedを送信している。このため、クライアント1はサーバ2とのパスワード認証を短縮して行うことができる。なお、ClientKeyExchangeとFinishedとを同時に、あるいは1つの信号として送信してもよい。図2は、本発明の実施の形態1におけるクライアントおよびサーバの機能ブロックの第1例を示す図である。また図3は、本発明の実施の形態1におけるクライアント側のフローチャートの一例を示す図、図4は、本発明の実施の形態1におけるサーバ側のフローチャートの一例を示す図である。次に、この図2、図3、図4を用いて説明を行う。また、以下の説明において図1を用いて説明したステップS1~S28に対応させている。クライアント1は、ネットワークを介してサーバ2とSSL/TLS暗号通信、および、PAKE認証を行う。図3-1はじめに、SSLネゴシエーション部400がClientHelloメッセージを生成し、これをデータ送信部300に送るステップS1。図3-2データ送信部300は、ネットワーク制御装置100を介して、サーバ2に対して、このClientHelloメッセージを送信するステップS1。図3-3この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図4-1サーバ2は、クライアント1からのメッセージ受信待ち状態で始まる。データ受信部210は、クライアント1が送信したClientHelloメッセージを、ネットワーク制御装置110を介して受信する。データ受信部210は、このClientHelloメッセージを、ClientHelloメッセージを解釈処理するSSLネゴシエーション部410に送る。図4-2SSLネゴシエーション部410は、ClientHelloメッセージを処理するステップS2。図4-3SSLネゴシエーション部410は、ServerHello、ServerCertificate公開鍵の情報を含む、ServerHelloDoneを生成し、これをデータ送信部310に送るステップS3。図4-4データ送信部310は、ネットワーク制御装置110を介して、クライアント1に対して、ServerHello/ServerCertificate/ServerHelloDoneメッセージを送信するステップS3。図4-5その後、サーバ2は再びクライアント1からのメッセージ受信待ち状態になる。図3-3クライアント1のデータ受信部200は、サーバ2が送信したServerHello、ServerCertificate、ServerHelloDoneメッセージを、ネットワーク制御装置100を介して受信する。データ受信部200は、ServerHello、ServerCertificate、ServerHelloDoneメッセージを、ServerHello、ServerCertificate、ServerHelloDoneメッセージを解釈処理するSSLネゴシエーション部400に送る。図3-4SSLネゴシエーション部400は、ServerHello、ServerCertificate、ServerHelloDoneメッセージを処理し、公開鍵Eと公開鍵Nモジュラスを取得するステップS4。なお、サーバ証明書のチェックは行っても行わなくてもどちらでも構わない。図3-5SSLネゴシエーション部400は乱数生成部500に指示して、乱数Aを生成させるステップS5。なお、乱数Aのデータ長は、公開鍵Nモジュラスのデータ長に等しい。図3-6共通鍵生成部800は、乱数Aの内、最後の48バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレットmastersecretを生成する。そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部800は、この共通鍵を、暗号復号化、およびMAC処理を行う共通鍵暗号復号部850に渡すステップS6。図3-7公開鍵暗号部600は、乱数Aを公開鍵Eと公開鍵Nで暗号化するステップS7。図3-8パスワード暗号部700は、公開鍵で暗号化された乱数Aを、パスワードで暗号化し、2重暗号された乱数Aを求めるステップS8。この手続きは、SSL/TLS暗号通信にはなく、PAKE認証のための処理である。なおフローチャートには示していないが、このパスワードはユーザが、パスワードを入力する入力部750を介して、クライアント1に記憶させたパスワードとすることもできる。なおこの場合、パスワードを入力するタイミングは、事前、若しくはパスワードが必要になった時点とする。図3-9SSLネゴシエーション部400は、2重暗号された乱数AをEncryptedPreMasterSecretとして、ClientKeyExchangeを生成する。図3-10続いてSSLネゴシエーション部400は、ChangeCipherSpecを生成するステップS9。図3-11続いてSSLネゴシエーション部400は、Finishedメッセージのデータ部MACを含まないを生成するステップS10。図3-12SSLネゴシエーション部400は乱数生成部500乱数生成手段に指示して、乱数Bを生成させる。乱数Bは、共通鍵暗号復号部850共通鍵暗号化手段に渡されるステップS11。図3-13共通鍵暗号復号部850共通鍵暗号化手段は、SSLネゴシエーション部400から渡されたFinishedメッセージのデータ部のMACを求め、Finishedメッセージのデータ部MACを含むと乱数BとのXOR処理を行い、Finishedメッセージのデータ部MACを含むを暗号化するステップS11。また、共通鍵暗号復号部850は、この暗号化されたFinishedメッセージのデータ部MACを含むを、共通鍵で暗号化し、2重暗号されたFinishedメッセージのデータ部MACを含むを求めるステップS12。図3-14SSLネゴシエーション部400は、2重暗号されたFinishedメッセージのデータ部MACを含むからFinishedメッセージを生成する。そして、SSLネゴシエーション部400は生成したClientKeyExchange、ChangeCipherSpec、Finishedメッセージをデータ送信部300に送る。図3-15データ送信部300は、ネットワーク制御装置100を介して、サーバ2に対して、このClientKeyExchange、ChangeCipherSpec、Finishedメッセージを送信するステップS13。図3-16この後、クライアント1はサーバ2からのメッセージ受信待ち状態になる。図4-5データ受信部210は、クライアント1が送信したClientKeyExchange、ChangeCipherSpec、Finishedメッセージを、ネットワーク制御装置110を介して受信するステップS14。データ受信部210は、このClientKeyExchange、ChangeCipherSpec、Finishedメッセージを、ClientKeyExchange、ChangeCipherSpec、Finishedメッセージを解釈するSSLネゴシエーション部410に送る。図4-6SSLネゴシエーション部410は、ClientKeyExchangeメッセージからEncryptedPreMasterSecret、つまり2重暗号された乱数Aを読み出す。図4-7パスワード復号部710は、2重暗号された乱数Aをパスワードで復号化することによって、公開鍵Eと公開鍵Nで暗号化された乱数Aを求めるステップS15。図4-8公開鍵復号部610は、公開鍵Eと公開鍵Nで暗号化された乱数Aを、公開鍵Eと対となる秘密鍵Dと公開鍵Nで復号化し、乱数Aを求めるステップS16。図4-9共通鍵生成部810は、乱数Aの内、最後の48バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレットを生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部810は、この共通鍵を、暗号復号化、およびMAC処理を行う共通鍵暗号復号部860に渡すステップS17。なお先に説明したように、乱数Aは、プリマスターシークレットにおけるバージョン情報の設定、および、PKCS1version1.5の暗号ブロックフォーマットEncryption-blockformattingによるデータ整形が行われていないので、SSLネゴシエーション部410はこのチェックは行わない。ここはSSL/TLS暗号通信の仕様とは異なる。図4-10SSLネゴシエーション部410は、ChangeCipherSpecメッセージを処理するステップS18。図4-11SSLネゴシエーション部410は、Finishedメッセージから2重暗号されたデータ部MACを含むを読み出す。そしてこの2重暗号されたデータ部MACを含むを共通鍵暗号復号部860に渡す。図4-12共通鍵暗号復号部860は、2重暗号されたデータ部MACを含むを共通鍵で復号化し、乱数Bで暗号化されたデータ部MACを含むを求めるステップS19。図4-13SSLネゴシエーション部410は、クライアントが生成すべきFinishedのデータ部MACを含まないを、自ら計算するステップS20。また図示していないが、SSLネゴシエーション部410は、このFinishedのデータ部MACを含まないを共通鍵暗号復号部860に渡し、Finishedのデータ部MACを含まないのMACを計算し、Finishedのデータ部MACを含むを取得するものとする。図4-14認証データ取得部910は、乱数Bで暗号化XOR処理されたFinishedのデータ部と、SSLネゴシエーション部410が計算して求めたFinishedのデータ部とのXOR処理を行い、乱数Bを求めるステップS21。図4-15SSLネゴシエーション部410は、ChangeCipherSpec、Finishedメッセージを生成し、これをデータ送信部310に送るステップS22。図4-16データ送信部310は、ネットワーク制御装置110を介して、クライアント1に対して、ChangeCipherSpec、Finishedメッセージを送信するステップS22。図4-17その後、サーバ2は再びクライアント1からのメッセージ受信待ち状態になる。図3-16クライアント1のデータ受信部200は、サーバ2が送信したChangeCipherSpec、Finishedメッセージを、ネットワーク制御装置100を介して受信する。データ受信部200は、ChangeCipherSpec、Finishedメッセージを、ChangeCipherSpec、Finishedメッセージを解釈するSSLネゴシエーション部400に送るステップS23。図3-17SSLネゴシエーション部400は、ChangeCipherSpecメッセージを処理する。図3-18SSLネゴシエーション部400は、Finishedメッセージを処理する。なお、このFinishedメッセージを処理することで、クライアント1はサーバ2を認証できたことになるステップS23。図3-19共通鍵暗号復号部850は、乱数Bを共通鍵で暗号化し、これをデータ送信部300に送るステップS24。図3-20データ送信部300は、ネットワーク制御装置100を介して、サーバ2に対して、この共通鍵で暗号化された乱数Bを送信するステップS25。なおここの暗号化は、SSL/TLS暗号通信の仕様に従うので、MACの生成、および暗号化も行う。なお、乱数Bは平分で送信しても危険でなく、暗号化の必要はないが、SSL/TLS暗号通信の仕様に合わせるものとする。図4-17データ受信部210は、クライアント1が送信した共通鍵で暗号化された乱数Bを、ネットワーク制御装置110を介して受信する。データ受信部210は、この共通鍵で暗号化された乱数Bを、共通鍵暗号復号部860に送るステップS26。図4-18共通鍵暗号復号部860は、暗号化された乱数Bを共通鍵で復号化し、乱数Bを求めるステップS27。図4-19認証部920は、自ら計算し求めた乱数Bと、復号した乱数Bとを比較照合し、クライアントがパスワードを知っている正規クライアントか否かを判断するステップS28。次に、図7を用いてクライアント1およびサーバ2の構成の他の例について説明する。図7は、発明の実施の形態1におけるクライアントおよびサーバの機能ブロックの第2例を示す図である。ここでは乱数Bを共通鍵としてバージョン情報を暗号化し、これを乱数Bの代わりの認証データとしている。クライアント1は、共通鍵で暗号した乱数Bの代りに、共通鍵暗号復号部850共通鍵暗号化手段で、乱数Bを共通鍵として暗号化したバージョン情報をサーバ2に渡している。サーバ2は、乱数Bで暗号化されたバージョン情報を、共通鍵暗号復号部860共通鍵暗号化手段で計算して求めた乱数Bを共通鍵として復号し、この求めたバージョン情報とあるべきバージョン情報とを、認証部920で照合している。なおこの共通鍵暗号はXOR処理等のような単純な暗号化ではなく、第3者が逆算できないような複雑な共通鍵暗号とした方が好ましい。なお、図2および図7において、説明をわかりやすくするために、暗号およびまたは復号を行う機能ブロックを複数に分けて説明したが、勿論、1つの機能ブロックが複数の暗号処理およびまたは復号処理を行ってもよい。次に、図5を用いてクライアント1およびサーバ2のハードウェアの構成について説明する。図5は、本発明の実施の形態1におけるクライアントおよびサーバのハードウェア構成の一例を示す図である。クライアント1は、プログラム処理を実行するCPU10、一時的な記憶メモリであるRAM20、キーボード等の入力装置50とネットワークのデータ送受信を実行するMACMediaAccessControl/PHY40を備える。一方、サーバ2は、プログラム処理を実行するCPU11、一時的な記憶メモリであるRAM21、書き換え不可の不揮発性メモリであるROM31、ネットワークのデータ送受信を実行するMAC/PHY41を備える。また、クライアント1とサーバ2はMAC/PHY40とMAC/PHY41を介してネットワークで接続されている。はじめにクライアント1のハードウェア構成に関して説明を行う。図3に示したクライアント1の各処理部は、CPU10、およびRAM20で実行される。但し、入力部750は、入力装置50を外部インターフェースとして動作させ、ユーザが入力したパスワードを取得する。乱数生成部500乱数生成手段が生成した乱数Aと乱数B、および、共通鍵生成部800が生成した共通鍵は、RAM20に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。また、サーバ2からSSLネゴシエーション部400が取得した公開鍵Eと公開鍵NもRAM20に保存されるが、公開鍵は新たな公開鍵を取得した際に上書きするものとすればよく、不必要になった時点で直ちに消去する必要はない。MAC/PHY40は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置100を実現するものである。次に、サーバ2のハードウェア構成に関して説明を行う。図3に示したサーバ2の各処理部は、CPU11、およびRAM21で実行される。クライアント1から取得した乱数Aと乱数B、および、共通鍵生成部810が生成した共通鍵は、RAM21に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。次に、秘密鍵Dと公開鍵N、および、パスワードはROM31に保存されるが、利用時にRAM21に移動されてもよい。なお安全上は、秘密鍵Dは耐タンパ装置等、セキュリティの高いメモリに保存するのが好ましい。MAC/PHY41は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置110を実現するものである。実施の形態2以下、図6を用いて実施の形態2について説明する。図6は、本発明の実施の形態2におけるPAKE認証を示すシーケンス図である。具体的には、ステップS25以降の処理が異なる。実施の形態1では、クライアントはサーバに対して、乱数Bをデータとして提示しているが、本実施の形態では、クライアント1はサーバ2に対して、SSL/TLSネゴシエーションの中で乱数Bを提示している。以下、本実施の形態では、ステップS25以降の処理をステップS30~S36として説明する。クライアント1がサーバ2に対して、SSLの再接続を行う。具体的には、クライアント1はSessionIDに、ステップS4で受信したServerHelloで指定されたSessionIDを設定し、かつ、RandomBytesに乱数Bを設定したClientHelloを生成し、これをサーバ2に送信するステップ30。なお、SSL/TLSの再接続なので、共通鍵生成には、すでに生成したマスターシークレットが利用される。また、SSLの再接続を行う前に、一端TCPポートをクローズしない場合は、これ以降のSSL/TLSネゴシエーションでは、メッセージのデータ部は共通鍵で暗号化されるが、説明を簡単にするため、ここではメッセージのデータ部は非暗号であるものとして説明を行う。なおここでは、乱数BをRandomBytesに設定したが、乱数Bの設定箇所はこれに限られるものではなく、例えば、ClientHelloの拡張データextradata等、SSL/TLSネゴシエーションで利用する各メッセージの他の部分に挿入してもよい。サーバ2はクライアント1から送信されたClientHelloを受信し、処理するステップS31。サーバ2は自らが計算して保持する乱数Bと、ClientHelloから取得した乱数Bとを比較照合する。ここで一致すれば、クライアント1はパスワードを知る正しいクライアントであると判断できる。これにより、クライアント認証が実施されるステップS32。そして、サーバ2はクライアント1に対してServerHello、ChangeCipherSpec、Finishedを生成し、送信するステップS33。クライアント1はこれらを受信し、処理するステップS34。そして、クライアント1はサーバ2に対してChangeCipherSpec、Finishedを生成し、送信するステップS35。サーバ2はこれらを受信し、処理するステップS36。なお本実施の形態では、SSL/TLSネゴシエーション後、直ちにSSL/TLSの再接続、即ちクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバ2がHelloReauest等で合図をし、それを受けてクライアント認証を行うものとしてもよい。なおこの図6に示す一連のSSL/TLSネゴシエーションは乱数Bの設定、および、クライアント認証を除けば、すべてSSL/TLS暗号通信の仕様に従っている。本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第3者から見ればSSL/TLS暗号通信の仕様に従っているので図6のEncryptedPreMasterSecret、クライアント1が送信するFinishedはSSL/TLS暗号通信に従っていないが、暗号化データのため、第3者には、SSL/TLS暗号通信に従っているか否かは判断できない、本実施の形態も同様に、第3者から見れば、通常のSSL/TLSネゴシエーションに見える。従って、SSL/TLS暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、PAKE認証を行うことが可能である。しかも、SSL/TLS暗号通信でPAKE認証を行いながらも、公開鍵暗号の実施回数は1回のみなので、装置にかかる負荷は小さい。本実施の形態は実施の形態1と比較して、更に利点がある。通常、SSL/TLS暗号通信を行うアプリケーションプログラムは、SSL/TLS暗号通信機能を、アプリケーションプログラムとは別のOpenSSLのようなSSL/TLS暗号通信モジュールを利用することで実現している。本実施の形態では、乱数B、つまり認証データの提示を、すべてSSL/TLSネゴシエーションの中で行っている。従って、アプリケーションプログラムがSSL/TLS暗号通信モジュールに対して一度パスワードを与えれば、後はSSL/TLS暗号通信モジュールがすべて実行できる。そのため、アプリケーションプログラムのつくりが複雑にならない。なお本実施の形態では、SSL/TLSの再接続で乱数Bを提示したが、もう一度、通常のSSL/TLSネゴシエーションをやり直し、その中で乱数Bを提示してもよい。但し、この方法の場合、公開鍵暗号は2度実行しなければならず、装置にかかる負荷が大きくなる。また、通常のSSL/TLSネゴシエーションをやり直す場合は、乱数Bの代りに、前回のSSL/TLSネゴシエーションで生成したプリマスターシークレットやマスターシークレットを提示することも可能である。但し、前回のSSL/TLSネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。なおここでは、SSL/TLSの再接続を行っているが、SSL/TLSの再接続の負荷は公開鍵暗号に比べれば非常に小さいので、パフォーマンス的には問題にならない。