JP5845393B2 - 暗号通信装置および暗号通信システム - Google Patents
暗号通信装置および暗号通信システム Download PDFInfo
- Publication number
- JP5845393B2 JP5845393B2 JP2011101076A JP2011101076A JP5845393B2 JP 5845393 B2 JP5845393 B2 JP 5845393B2 JP 2011101076 A JP2011101076 A JP 2011101076A JP 2011101076 A JP2011101076 A JP 2011101076A JP 5845393 B2 JP5845393 B2 JP 5845393B2
- Authority
- JP
- Japan
- Prior art keywords
- random number
- encryption
- unit
- client
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
- H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
Description
本発明は、鍵交換処理と共に認証処理を行う暗号通信装置および暗号通信システムであって、特に、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）暗号通信と共にパスワード相互認証プロトコル（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ、以下ＰＡＫＥ認証と称する）を行う暗号通信装置および暗号通信システムに関する。
近年、通信を安全に行う方法として、ＳＳＬ／ＴＬＳ暗号通信が普及している。ＳＳＬ／ＴＬＳ暗号通信は、非常に簡単に利用できる上、暗号通信で最も危険な中間者攻撃に対しても防御方法があり、安全性も非常に高い。
しかし中間者攻撃への対処には、サーバ証明書やクライアント証明書の利用したＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の仕組みが必要であり、普通のパスワード認証に比べ、運用が煩雑な上、運用費も嵩む。
この欠点を補う手段として最近、ＰＡＫＥ認証の研究が進んでいる。ＰＡＫＥ認証は従来のパスワード認証とは異なり、公開鍵暗号方式とパスワード認証を融合させた新たな認証方式である。ＰＡＫＥ認証を利用すれば、高価で煩雑なＰＫＩではなく、安価で簡単なパスワードを利用して、中間者攻撃を抑制できる。
しかしながら、ＰＡＫＥ認証だけで、暗号通信と認証を同時に実現するのは理論的に可能であっても、実際の運用はかなり難しい。このため、ファイヤーウォール等様々な通信機器やブラウザ等ツールが、ＳＳＬ／ＴＬＳ暗号通信に対応し、広く普及しているＳＳＬ／ＴＬＳ暗号通信の仕組みをそのまま利用してＰＡＫＥ認証を行う技術が提案されている。クライアントとサーバとでＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）を行った後に、ＰＡＫＥ認証を行うことで中間者攻撃の被害を抑制することができる（特許文献１参照）。
しかしながら、ＳＳＬ／ＴＬＳ暗号通信にそのままＰＡＫＥ認証を利用すると、共通鍵を交換にコンピュータにとって負荷の大きい公開鍵暗号を少なくとも２回以上利用する必要があった。即ち、ＳＳＬ／ＴＬＳのハンドシェイク処理において公開鍵暗号を行い、更にこのハンドシェイク処理後にＰＡＫＥ認証を行うためにもう１度公開鍵暗号を行っていた。
また、特にサーバ側は公開鍵暗号における秘密鍵を利用した復号を行うため、ＣＰＵに非常に重い負荷が生じた。一般的にサーバは複数のクライアントを相手にするので、常時、多量の公開鍵暗号を実行しなければならない。そのため、多くのＳＳＬ／ＴＬＳサーバは、高価なＣＰＵやＳＳＬ／ＴＬＳアクセラレータボードを搭載している。このように公開鍵暗号を実行するのに要する費用は非常に大きく、コンピュータ購入費の半分以上のコストに相当するという見解もある。従って、公開鍵暗号の回数が倍以上になる影響は深刻であった。
また、ＳＳＬ／ＴＬＳ暗号通信は、各種攻撃に対する防御ノウハウが蓄積されていて信頼性が高いのに対し、ＰＡＫＥ認証による暗号通信は、攻撃に対する知見が少なく、信頼性に欠ける。
本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、普及しているＳＳＬ／ＴＬＳ暗号通信で、ＰＡＫＥ認証を用いて中間者攻撃を安価でかつ簡単に抑制しつつも、ＣＰＵの負荷を低減することである。
上述の課題を解決するために、本発明の暗号通信装置は、パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、第１の乱数および第２の乱数を生成する乱数生成部と、前記他の暗号通信装置の公開鍵を用いて前記第１の乱数に基づく情報を暗号化する第１の暗号化部と、前記第１の暗号化部によって暗号化された前記第１の乱数に基づく情報を、前記パスワードを用いて暗号化する第２の暗号化部と、前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、前記第２の暗号化部によって暗号化された前記第１の乱数に基づく情報を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記他の暗号通信装置に送信する送信部と、を備える。
本発明の暗号通信装置によれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。
また、本発明の暗号通信装置は、前記送信部は、前記第１の信号と前記第２の信号とを連続的に前記他の暗号通信装置に送信するように構成される。
本発明の暗号通信装置のこの構成によれば、第２の乱数を用いて他の暗号通信装置の認証を行うことができる。
本発明の暗号通信装置のこの構成によれば、既知のデータを第２の乱数で暗号化しているため、他の暗号通信装置からの計算結果を待たずして、第１の乱数を送信する第１の信号と、認証を行うための第２の信号を同時に送ることができる。即ち、他の暗号通信装置とのパスワード認証を短縮して行うことができる。
また、本発明の暗号通信装置は、前記第３の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第１の乱数および前記第２の乱数を用いて暗号化するように構成される。
本発明の暗号通信装置のこの構成によれば、他の暗号通信装置が既知データおよび第１の乱数から第２の乱数を算出した場合、他の暗号通信装置の認証を行うことができる。
また、本発明の暗号通信装置は、前記他の暗号通信装置からの信号を受信する受信部を更に有し、前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、前記送信部は前記第２の乱数を前記他の暗号通信装置に送信するように構成される。
本発明の暗号通信装置のこの構成によれば、第２の乱数を保持していることを他の暗号通信装置に通知できるため、他の暗号通信装置に自装置のパスワード認証をさせることができる。
また、本発明の暗号通信装置は、前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴であるように構成される。
本発明の暗号通信装置のこの構成によれば、他の暗号通信装置は自装置との通信履歴から自らこの通信履歴を算出することができる。このため、他の暗号通信装置は、例えば、悪意の第３者によって暗号方式の付け替えが行われたかどうかを確認できる。
また、本発明の暗号通信装置は、前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を前記第２の乱数の検証信号として送信するように構成される。
本発明の暗号通信装置のこの構成によれば、ＳＳＬハンドシェイクのプロトコルを通過させるファイヤーウォールのチェックにかからずに第１の信号および第２の信号を他の暗号通信装置に送信することができる。即ち、ＳＳＬハンドシェイクに基づいて他の暗号通信装置のパスワード認証を安価に行うことができる。
また、本発明の暗号通信システムは、パスワードを共有する第１の暗号通信装置と第２の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、前記第１の暗号通信装置は、第１の乱数および第２の乱数を生成する乱数生成部と、前記第２の暗号通信装置の公開鍵を用いて前記第１の乱数を暗号化する第１の暗号化部と、前記第１の暗号化部によって暗号化された前記第１の乱数を前記パスワードを用いて暗号化する第２の暗号化部と、前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、前記第２の暗号化部によって暗号化された前記第１の乱数を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記第２の暗号通信装置に送信する送信部と、を有し、前記第２の暗号通信装置は、前記第１の信号および前記第２の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第２の暗号化部によって暗号化された前記第１の乱数を復号化し、前記第１の乱数を取得する復号化部と、前記復号化部が取得した前記第１の乱数を用いて、前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報から前記第２の乱数を算出する認証データ取得部と、を有する。
本発明の暗号通信システムによれば、鍵交換処理中にパスワードを用いて他の暗号通信装置の認証を行うことができる。このように鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による装置の負荷を低減することができる。
また、本発明の暗号通信システムは、クライアントがサーバに対して、公開鍵とパスワードで暗号化した乱数Ａを送信する、クライアント・サーバ（秘密鍵を保持する側をサーバと呼ぶ）間のＰＡＫＥ認証であって、クライアントは乱数生成手段、および共通鍵暗号化手段を有し、クライアントは乱数生成手段を用いて乱数Ｂを生成し、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、乱数Ａ（乱数Ａから生成されるデータを含む）を、前記共通鍵暗号化手段を用いて暗号化し、サーバがパスワードを保持することを確認する前に、この乱数Ｂによって暗号化された乱数Ａをサーバに対して渡すものとし、クライアントは、サーバがパスワードを保持することを確認できたら、乱数Ｂ（乱数Ｂから生成されるデータを含む）をサーバに対して提示し、クライアントが乱数Ａ、即ちパスワードを理解していることをサーバに対して伝達する、つまりクライアント認証を行うものとした。
これによると、任意の値である乱数Ｂを用いて、クライアント認証を行うことが可能となる。なおこの乱数Ｂは、ワンタイムパスワードとして利用可能である。
またこのような提示方法は、ＳＳＬ／ＴＬＳネゴシエーションと親和性がよい。ＳＳＬ／ＴＬＳネゴシエーションでは、クライアントは、公開鍵暗号で暗号したデータ（Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と共に、その検証データ（Ｆｉｎｉｓｈｅｄ）も同時に送る。その時点ではクライアントは、まだサーバの検証データ（Ｆｉｎｉｓｈｅｄ）を入手していない。そのため、ＳＳＬ／ＴＬＳネゴシエーションと同時にＰＡＫＥ認証を行うと、オフライン攻撃が成立してしまう。
しかし本発明の暗号通信システムによれば、クライアントが送信する検証データ（Ｆｉｎｉｓｈｅｄ）は乱数Ｂで暗号化されているので、その危険性は少ない。従ってＳＳＬ／ＴＬＳネゴシエーションの中でパスワード認証（例えば、ＰＡＫＥ認証）を実施できるようになる。
これにより、１回の公開鍵暗号でＳＳＬ／ＴＬＳネゴシエーションとＰＡＫＥ認証を行えるようになるので、サーバのＣＰＵの負荷を小さくでき、サーバ費用を大幅に削減できる。
なお、このようにＳＳＬ／ＴＬＳネゴシエーションでＰＡＫＥ認証を行えば、ファイヤーウォール等の通信機器によって通信を遮断される危険性も減少する。
このような課題を解決するために、本発明の暗号通信システムでは、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク）の中で、クライアントがサーバに対して乱数Ｂを提示するものとした。
これによると、ＳＳＬ／ＴＬＳ暗号通信処理を、アプリケーションプログラムではなく、ＯｐｅｎＳＳＬのようなＳＳＬ／ＴＬＳ暗号通信モジュールが行っている場合に、アプリケーションプログラムのつくりをより簡略にすることができる。アプリケーションプログラムが一端ＳＳＬ／ＴＬＳ暗号通信モジュールにパスワードを渡せば、後はＳＳＬ／ＴＬＳ暗号通信モジュールがすべての処理を行える。
また、本発明の暗号通信システムは、ＳＳＬ／ＴＬＳの再接続を行うネゴシエーションの中で、クライアントがサーバに対して乱数Ｂを提示するものとした。
これによると、１回の公開鍵暗号でＳＳＬ／ＴＬＳネゴシエーションとＰＡＫＥ認証を行えるようになるので、サーバのＣＰＵの負荷を小さくでき、サーバ費用を大幅に削減できる。
また、本発明の暗号通信システムは、サーバは、クライアントから渡された前記共通鍵暗号化手段で暗号化された乱数Ａ（乱数Ａから生成されるデータを含む）と、乱数Ａ（乱数Ａから生成されるデータを含む）から、乱数Ｂ（乱数Ｂから生成されるデータを含む）を割り出すものとし、この割り出した乱数Ｂ（乱数Ｂから生成されるデータを含む）とクライアントから渡された乱数Ｂ（乱数Ｂから生成されるデータを含む）とを照合することで、クライアント認証を行うものとした。
これによると、サーバは認証データである乱数Ｂだけを記憶しておけばよいので、サーバ側のＳＳＬ／ＴＬＳ暗号通信モジュールのつくりを簡単にできる。
また、本発明の暗号通信システムは、前記共通鍵暗号化手段がＸＯＲ処理であるものとした。
これによると、サーバ側のＳＳＬ／ＴＬＳ暗号通信モジュールが、非常に簡単、かつ迅速に乱数Ｂの割り出しを行えるようになる。
また、本発明の暗号通信システムは、クライアントがサーバに乱数Ｂを提示するのに、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、この自ら暗号化した情報と、クライアントが暗号化した情報とを比較することで、クライアントが乱数Ｂを理解していることを確認するものとした。
これによると、クライアントがサーバに既知の情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、ＰＡＫＥ認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第３者に分かるような既知の情報は埋め込めこめない。しかし、ＳＳＬ／ＴＬＳネゴシエーションでは、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ ｒｏｌｌｂａｃｋ ａｔｔａｃｋｓ）を抑制するために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。
そこで、本発明の暗号通信システムのように、バージョン情報等の既知の情報は、乱数Ｂで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、ＰＡＫＥ認証とＳＳＬ／ＴＬＳネゴシエーションを両立させることが可能となる。乱数Ｂの値を知らない悪意の第３者は、乱数Ｂで暗号化した偽バージョン情報を作成できないので、悪意の第３者は、クライアント・サーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃（Ｖｅｒｓｉｏｎ ｒｏｌｌｂａｃｋ ａｔｔａｃｋｓ）を行うことは不可能である。
また、本発明の暗号通信システムは、クライアントがサーバに乱数Ｂを提示するのに、この乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、サーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて暗号化し、サーバに渡すものとし、サーバもクライアントと等価な共通鍵暗号化手段を有し、サーバはこの乱数Ｂ（乱数Ｂから生成されるデータを含む）を共通鍵として、暗号化されたサーバが保持、若しくは生成できる情報を、前記共通鍵暗号化手段を用いて復号化し、この自ら保持、若しくは生成できる情報と、復号化した情報とを比較することで、クライアントが乱数Ｂを理解していることを確認するものとした。
これによると、クライアントがサーバに特定情報を、改ざんを受けずに知らせることが可能となる。以下の実施の形態で詳細に説明を行うが、ＰＡＫＥ認証では、オフライン攻撃のため、公開鍵で暗号化する乱数には、第３者に分かるような既知の情報は埋め込めこめない。しかし、ＳＳＬ／ＴＬＳネゴシエーションでは、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ ｒｏｌｌｂａｃｋ ａｔｔａｃｋｓ）を防ぐために、公開鍵で暗号化する乱数には、バージョン情報等の既知の情報を埋め込まなくてはならない。
そこで、本発明のように、バージョン情報等の既知の情報は、乱数Ｂで暗号化して伝達するものとすれば、公開鍵で暗号化する乱数には既知の情報を埋め込む必要がなくなるので、ＰＡＫＥ認証とＳＳＬ／ＴＬＳネゴシエーションを両立させることが可能となる。乱数Ｂの値を知らない悪意の第３者は、乱数Ｂで暗号化した偽バージョン情報を作成できないので、悪意の第３者は、クライアント・サーバに知られることなく、バージョン情報を偽バージョン情報に改ざんする、つまりバージョンロールバック攻撃（Ｖｅｒｓｉｏｎ ｒｏｌｌｂａｃｋ ａｔｔａｃｋｓ）を行うことは不可能である。
鍵交換処理中にパスワード認証を組み合わせて行うため、鍵交換処理とパスワード認証処理とで重複する公開鍵暗号の秘密鍵による復号の処理による負荷を低減することができる。
（実施の形態１）
以下、本発明の実施の形態１を、図面を参照しながら説明する。
以下、本発明の実施の形態１を、図面を参照しながら説明する。
図１は、本発明の実施の形態１におけるＰＡＫＥ認証を示すシーケンス図である。ここでは、クライアント１とサーバ２とは、ＳＳＬ／ＴＬＳネゴシエーション（ＳＳＬ／ＴＬＳハンドシェイク、ＳＳＬネゴシエーション、ＳＳＬハンドシェイクとも称する）中に、ＰＡＫＥ認証も行う。なお説明を簡単にするために、ここで用いる公開鍵暗号はＲＳＡ（Ｒｉｖｅｓｔ Ｓｈａｍｉｒ Ａｄｌｅｍａｎ）暗号として説明を行う。また、クライアント１とサーバ２の構成については、図２、図５等を用いて詳細に説明する。なお、クライアント１およびサーバ２は暗号通信装置の一例である。
クライアント１がサーバ２に対してＣｌｉｅｎｔ Ｈｅｌｌｏを生成し、送信する（ステップＳ１）。サーバ２はこのＣｌｉｅｎｔ Ｈｅｌｌｏを受信し、処理する（ステップＳ２）。そして、サーバ２はクライアント１に対してＳｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ（公開鍵の情報を含む）、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを生成し、送信する（ステップＳ３）。クライアント１はこれらを受信し、処理する。なお、クライアント１は、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅから公開鍵を取得する（ステップＳ４）。
クライアント１はＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを生成するため、乱数Ａ（第１の乱数）を生成する。なお、乱数Ａのデータ長は、ＲＳＡ暗号におけるモジュラス（ｍｏｄｕｌｕｓ）のデータ長に等しい（ステップＳ５）。
クライアント１は、乱数Ａから共通鍵を生成する。詳細に説明すると、クライアント１は乱数Ａの内、最後の４８バイトをプリマスターシークレット（ｐｒｅｍａｓｔｅｒ ｓｅｃｒｅｔ）として扱う。なお、乱数Ａの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるために、最後の４８バイトをプリマスターシークレットとする。
次に、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）を生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する（ステップＳ６）。なおここで共通鍵とは、例えば、以下の鍵の総称であり、以下の同様である。
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ＭＡＣ＿ｓｅｃｒｅｔ
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＭＡＣ＿ｓｅｃｒｅｔ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ｋｅｙ
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ｋｅｙ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
次に、乱数Ａをサーバ２から伝送された公開鍵で暗号化する（ステップＳ７）。なお、本実施の形態では乱数Ａを公開鍵で暗号するが、乱数Ａそのものではなく、サーバ２が乱数Ａを算出できる情報であればよい。
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＭＡＣ＿ｓｅｃｒｅｔ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ｋｅｙ
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ｋｅｙ
ｃｌｉｅｎｔ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
ｓｅｒｖｅｒ＿ｗｒｉｔｅ＿ＩＶ（ブロック暗号利用時のみ必要）
次に、乱数Ａをサーバ２から伝送された公開鍵で暗号化する（ステップＳ７）。なお、本実施の形態では乱数Ａを公開鍵で暗号するが、乱数Ａそのものではなく、サーバ２が乱数Ａを算出できる情報であればよい。
なおこの暗号化の手順は、通常のＳＳＬ／ＴＬＳ暗号通信の仕様とは異なるので、以下、差異を説明する。
バージョン３．０以降のＳＳＬ／ＴＬＳ暗号通信では、プリマスターシークレットは以下のように、２バイトのバージョン情報と４６バイトの乱数Ｄで構成されている。
ｓｔｒｕｃｔ ｛
ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ ｃｌｉｅｎｔ＿ｖｅｒｓｉｏｎ;
← バージョン情報（ ２バイト）
ｏｐａｑｕｅ ｒａｎｄｏｍ［４６］; ← 乱数Ｄ （４６バイト）
｝ ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ; ← プリマスターシークレット
従って、乱数Ａから生成されたプリマスターシークレットには、バージョン情報が設定されていない。ここはＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ ｃｌｉｅｎｔ＿ｖｅｒｓｉｏｎ;
← バージョン情報（ ２バイト）
ｏｐａｑｕｅ ｒａｎｄｏｍ［４６］; ← 乱数Ｄ （４６バイト）
｝ ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ; ← プリマスターシークレット
従って、乱数Ａから生成されたプリマスターシークレットには、バージョン情報が設定されていない。ここはＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
次に、ＳＳＬ／ＴＬＳ暗号通信では、このプリマスターシークレットは、以下のように、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）で整形される。
００ || ０２ || パディング文字列（００を含まない乱数Ｅ） || ００ || ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ
ここで、|| の記号は単なるデータの連結を意味する。
ここで、|| の記号は単なるデータの連結を意味する。
なおこの全データ長は、ＲＳＡ暗号におけるモジュラス（ｍｏｄｕｌｕｓ）のデータ長に等しいので、乱数Ｅのデータ長は以下のようになる。
乱数Ｅのデータ長 ＝ モジュラス（ｍｏｄｕｌｕｓ）のデータ長 − ３ − ４８
ＳＳＬ／ＴＬＳ暗号通信では、この暗号ブロックフォーマット化されたプリマスターシークレットは公開鍵で暗号化される。
ＳＳＬ／ＴＬＳ暗号通信では、この暗号ブロックフォーマット化されたプリマスターシークレットは公開鍵で暗号化される。
一方、乱数Ａはモジュラス（ｍｏｄｕｌｕｓ）のデータ長と等しく、乱数Ａの構造は以下の通りである。
乱数Ａ ＝ （乱数Ｃ || ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ）
なお乱数Ｃのデータ長は、モジュラス（ｍｏｄｕｌｕｓ）のデータ長より、ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔのデータ長、つまり４８バイト分少ない。
なお乱数Ｃのデータ長は、モジュラス（ｍｏｄｕｌｕｓ）のデータ長より、ＰｒｅＭａｓｔｅｒＳｅｃｒｅｔのデータ長、つまり４８バイト分少ない。
このように、「００ || ０２ || パディング文字列（００を含まない乱数Ｅ） || ００」の部分を「乱数Ｃ」に置き換えているところも、ＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
つまり、乱数Ａには、ＳＳＬ／ＴＬＳ暗号通信の仕様で定義されているプリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）によるデータ整形がなされていない。
なお、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）で整形しない。
しかしこのようにすると、悪意の第３者がクライアントになりすまし、０とか１のような特殊なＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをサーバ２に渡し、サーバ２が返すＦｉｎｉｓｈｅｄを見て、パスワードを類推するかもしれない。これを避けるには、サーバ２は、０とか１のような単純なＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをエラーとして処理するか、若しくはパスワードの暗号方法を工夫すればよい。つまり、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔが０や１であっても、パスワードで復号した場合に複雑な値が出現するようなものであれば問題ない。
また、乱数Ａに、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）によるデータ整形を行わない理由は、オフライン攻撃を抑制するためである。
悪意の第３者が正規サーバになりすます（即ち、悪意の第３者がサーバ２として動作する）場合、悪意の第３者は、自らが保持する秘密鍵と対となる公開鍵をクライアントに渡せる。従って、悪意の第３者は公開鍵暗号における復号化が可能である。
一方パスワードの方も、オフラインであれば、パスワードは一般的に記憶できる程度の長さにするため、暗号鍵に比べビット長が短く、悪意の第３者にとっては、パスワードが取りうるすべての組合せを総当りで調べるのは難しくない。
悪意の第３者は正規サーバになりすまし、クライアント１から２重暗号された乱数Ａを取得する。そして、仮パスワードを設定し、２重暗号された乱数Ａをこの仮パスワードと自らが保持する秘密鍵で復号化する。乱数Ａにバージョン情報やフォーマットがあれば、これが出現するか否かで、想定したパスワードが正しいかを判定できる。
悪意の第３者は、オフラインで仮パスワードを次々に設定すれば、いずれかの時点で、乱数Ａにバージョン情報やフォーマットが出現するパスワードを探し当てることが可能である（オフライン攻撃）。
以上説明したように、このオフライン攻撃を避けるため、乱数Ａにはバージョン情報設定やフォーマット化を行わない。
次に、公開鍵で暗号化された乱数Ａを、更にパスワードで暗号化し、２重暗号化された乱数Ａを求める（ステップＳ８）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
そして、この２重暗号された乱数Ａを、ＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔとして、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを生成する。ここで、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅは第１の信号の一例であり、サーバ２に乱数Ａを送信するための鍵交換信号でもある。
Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを生成し（ステップＳ９）、Ｆｉｎｉｓｈｅｄの平分のデータ部を生成する（ステップＳ１０）。ここで、Ｆｉｎｉｓｈｅｄは、第２の信号の一例であり、検証データを送信するための検証信号でもある。
クライアント１は乱数Ｂ（第２の乱数）を生成し、少なくともＦｉｎｉｓｈｅｄのデータ部で、共通鍵で暗号化する部分（ＭＡＣを含む）を、乱数Ｂで暗号化する。乱数Ｂによる暗号化はここではＸＯＲ処理とする（ステップＳ１１）。この乱数Ｂによる暗号化処理手続きも、ＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
ここで、Ｆｉｎｉｓｈｅｄのデータ部を乱数Ｂで暗号化するのは、これも上述したオフライン攻撃を抑制するためである。仮に乱数Ｂで暗号化されていないＦｉｎｉｓｈｅｄをクライアント１がサーバ２に送信すると、悪意の第３者が正規サーバになりすました場合に、オフライン攻撃が成立する可能性がある。
悪意の第３者は、オフラインで仮パスワードを次々に設定し、Ｆｉｎｉｓｈｅｄを自ら計算すれば、クライアント１から受信したＦｉｎｉｓｈｅｄと比較することで、いずれかの時点で、正しいパスワードを探し当てることが可能である。
乱数Ｂで暗号化したデータ部を、更に共通鍵で暗号化し、データ部を２重暗号化する（ステップＳ１２）。ここでは、ファイヤーウォールのチェックにひっかからないためにＳＳＬ／ＴＬＳ暗号通信の仕様に従う。即ち、この共通鍵による暗号はなくてもよいが、クライアント１はＳＳＬ／ＴＬＳ暗号通信の仕様に基づいて共通鍵による暗号を行う。
クライアント１はサーバ２に対して、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを送信する（ステップＳ１３）。
サーバ２はクライアント１から、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを受信する（ステップＳ１４）。
サーバ２は、Ｃｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅのＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔにセットされた２重暗号化された乱数Ａをパスワードで復号化し、公開鍵で暗号化された乱数Ａを求める（ステップＳ１５）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
サーバ２は、公開鍵で暗号化された乱数Ａを秘密鍵で復号化する（ステップＳ１６）。
サーバ２は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱う。なお、乱数Ａの内、どの部分をプリマスターシークレットとして扱うかは、本質的な問題ではなく、他の部分をプリマスターシークレットとしてもよい。ここでは、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるために、最後の４８バイトをプリマスターシークレットとする。
次に、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）を生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。
なお上述したように、乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないので、サーバ２はこのチェックを行わない。ここもＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
サーバ２は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを処理し（ステップＳ１８）、２重暗号化されたＦｉｎｉｓｈｅｄのデータ部を共通鍵で復号化する（ステップＳ１９）。
そしてサーバ２は、クライアント１が生成したＦｉｎｉｓｈｅｄのデータ部を、独自に計算する。
サーバ２は、乱数Ｂで暗号化されたＦｉｎｉｓｈｅｄのデータ部と、自ら計算して求めたＦｉｎｉｓｈｅｄのデータ部を比較して、乱数Ｂを求める。これもＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる（ステップＳ２１）。
なお、クライアント１がサーバ２に対して乱数Ｂを提示できれば、クライアント１がサーバに提示したＦｉｎｉｓｈｅｄが正しいと証明できるので、この乱数Ｂは、クライアントが正規クライアントか否かを確かめる、つまりクライアント認証のための認証データとして扱える。
サーバ２は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、クライアント１に対してこれを送信する。なお、このＦｉｎｉｓｈｅｄの生成は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従う（ステップＳ２２）。
クライアント１はサーバ２から、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを受信し、これを処理する。そして、Ｆｉｎｉｓｈｅｄを処理することで、クライアント１はサーバ２を認証できたことになる（ステップＳ２３）。ここで、ＳＳＬハンドシェイクは確立されたことになる。つまり、これ以降でのクライアント１とサーバ２との間の通信では共通鍵暗号が使用される。
クライアント１は、乱数Ｂを共通鍵で暗号化し（ステップＳ２４）、サーバ２に対して、暗号化された乱数Ｂを送信する（ステップＳ２５）。ここの暗号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣの生成、および暗号化を行う。
なお、乱数Ｂは平分で送信しても危険でなく、暗号化の必要はないが、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるものとする。
サーバ２はクライアント１から、暗号化された乱数Ｂを受信し（ステップＳ２６）、暗号化された乱数Ｂを、共通鍵で復号化する（ステップＳ２７）。なおここの復号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣのチェックも行う。
サーバ２は、自ら算出した乱数Ｂと、復号した乱数Ｂとを比較（照合）し、クライアント１がパスワードを知っている正規クライアントか否かを判断する。
なお、乱数Ｂによる暗号がＸＯＲ処理でない場合は、サーバ２は、ステップＳ１９で復号化したデータとステップＳ２０で生成したデータとを保存しておき、この乱数Ｂを取得した時点で、ステップＳ２０で生成したデータに対して乱数Ｂで暗号化を行い、そして、この乱数Ｂで暗号したデータとステップＳ１９で復号化したデータとを比較すればよい。
なお、Ｆｉｎｉｓｈｅｄのデータ部に対する暗号化の順番は、ここでは乱数Ｂを先に、共通鍵を後として説明したが、逆に行うことも可能である。但し、処理が少し面倒になるので、好ましくない。また、先に説明したように、Ｆｉｎｉｓｈｅｄのデータ部を２重暗号化せずに、乱数Ｂのみで暗号するものとしてもよい。
なお、乱数Ｂはそのものでも、データ整形されたものであってもよい。乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないため、サーバ２はプリマスターシークレットを求めた際に、受信したデータに欠損があるかや、バージョンロールバック攻撃（Ｖｅｒｓｉｏｎ ｒｏｌｌｂａｃｋ ａｔｔａｃｋｓ）を受けているかを知ることができない。
そこでバージョン情報や暗号ブロックフォーマットデータを、乱数Ｂを共通鍵として、適当な共通鍵暗号化方式を用いて暗号化し、これを新たな認証データとするとよい。この部分の具体的な手続について図７を用いて後述する。
以上説明したように本実施の形態では、ＳＳＬ／ＴＬＳ暗号通信の仕様を一部改変するだけで、ＰＡＫＥ認証を行うことができる。
また、本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第３者から見ればＳＳＬ／ＴＬＳ暗号通信の仕様に従っているので（図１のＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、図１のクライアント１が送信するＦｉｎｉｓｈｅｄはＳＳＬ／ＴＬＳ暗号通信に従っていないが、暗号化データのため、第３者には、ＳＳＬ／ＴＬＳ暗号通信に従っているか否かは判断できない）、図１は、第３者から見れば、通常のＳＳＬ／ＴＬＳネゴシエーションに見える。
従って、ＳＳＬ／ＴＬＳ暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、ＰＡＫＥ認証を行うことが可能である。
しかも、ＳＳＬ／ＴＬＳ暗号通信でＰＡＫＥ認証を行いながらも、公開鍵暗号の実施回数は１回のみなので、装置にかかる負荷は小さい。
なお図１では、ＳＳＬ／ＴＬＳネゴシエーション後、直ちにクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバが合図をし、それを受けてクライアント認証を行うものとしてもよい。
従って、乱数Ｂをワンタイムパスワードとして利用することも可能である。逆に言えば、図１のＳＳＬ／ＴＬＳネゴシエーションを、ワンタイムパスワード生成手段として扱うことも可能である。
なお、このＳＳＬ／ＴＬＳネゴシエーションをワンタイムパスワード生成手段としてのみ扱い、暗号通信を行わない場合は、プリマスターキーやマスターキーを乱数Ｂの代りにワンタイムパスワードとして扱うことも可能であるが、ＳＳＬ／ＴＬＳネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。
また、上述したＦｉｎｉｓｈｅｄのデータ部とは、通常のＳＳＬハンドシェイクの処理と同様に、クライアント１とサーバ２との間でのＳＳＬハンドシェイクでのこれまでのやり取りのデータ（以下、ＳＳＬハンドシェイクデータと称する）に関する情報である。即ち、Ｆｉｎｉｓｈｅｄのデータ部が生成されるステップＳ１０より前のＳＳＬハンドシェイクデータとは、Ｃｌｉｅｎｔ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅであるので、これらの信号に基づいてクライアント１はＦｉｎｉｓｈｅｄのデータ部を生成する。
一方、サーバ２にとっても、Ｃｌｉｅｎｔ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅはすでにクライアント１との間で通信した情報であるため、クライアント１から生成されるＦｉｎｉｓｈｅｄのデータ部を自ら算出することができる。即ち、Ｆｉｎｉｓｈｅｄのデータ部とは、サーバ２にとっても既知のデータである。これにより、既知のデータであるＦｉｎｉｓｈｅｄのデータ部を用いて乱数Ｂを算出することができる。
そして、Ｆｉｎｉｓｈｅｄ（第２の信号）は一般的なＳＳＬハンドシェイクでは検証信号として使用される。つまり、サーバ２は共通鍵を用いて復号したＦｉｎｉｓｈｅｄのデータ部と、自ら生成したデータ部とを照合することで、正しくＳＳＬハンドシェイク行えたかどうかを検証できる。例えば、ＳＳＬハンドシェイクの途中で悪意の第３者によってＳＳＬ暗号通信で行う暗号方式を勝手に変更されていた場合、Ｆｉｎｉｓｈｅｄを受信することで気づくことができる。
また、ステップＳ７において、乱数Ａを公開鍵で暗号化したが、乱数Ａに基づく情報であればよい。即ち、乱数Ａから生成される共通鍵を算出できる情報であればよく、特に限定するものではない。
また、ステップＳ１１においては、乱数Ｂに基づく情報を共通鍵で暗号化すればよい。乱数Ｂに基づく情報とは、乱数Ｂそのものでもよく、ハッシュ化した乱数Ｂでもよく、本実施の形態のように乱数Ｂによって暗号化されたデータ部でもよい。
また、ステップＳ２２において、サーバ２がＦｉｎｉｓｈｅｄを生成し、クライアント１にこれを送信するということは、乱数Ｂを算出できたことを意味する。即ち、ステップ２３において、クライアント１はＦｉｎｉｓｈｅｄを受信することにより、サーバ２がパスワードを有する正規のサーバであることを認証することができる。なお、サーバ２がパスワードを有することを証明する方法としてはこの限りではなく、クライアント１が乱数Ｂを算出できる情報をサーバ２がクライアント１に送信してもよい。以上より、クライアント１は乱数Ｂに基づいてサーバ２を認証できる。
また、本実施の形態では、鍵交換信号であるＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅと乱数Ｂおよび検証データを送る信号であるＦｉｎｉｓｈｅｄとはＳＳＬの仕様に従って連続的に送信する。すなわち、クライアント１はＣｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅとＦｉｎｉｓｈｅｄとの間にサーバ２からの信号を受信しない。つまり、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを送信後、サーバ２からの返答を待たずして、検証データであるＦｉｎｉｓｈｅｄを送信している。このため、クライアント１はサーバ２とのパスワード認証を短縮して行うことができる。なお、Ｃｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅとＦｉｎｉｓｈｅｄとを同時に、あるいは１つの信号として送信してもよい。
図２は、本発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第１例を示す図である。また図３は、本発明の実施の形態１におけるクライアント側のフローチャートの一例を示す図、図４は、本発明の実施の形態１におけるサーバ側のフローチャートの一例を示す図である。次に、この図２、図３、図４を用いて説明を行う。また、以下の説明において図１を用いて説明したステップＳ１〜Ｓ２８に対応させている。
クライアント１は、ネットワークを介してサーバ２とＳＳＬ／ＴＬＳ暗号通信、および、ＰＡＫＥ認証を行う。
（図３−（１））はじめに、ＳＳＬネゴシエーション部４００がＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを生成し、これをデータ送信部３００に送る（ステップＳ１）。
（図３−（２））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを送信する（ステップＳ１）。
（図３−（３））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
（図４−（１））サーバ２は、クライアント１からのメッセージ受信待ち状態で始まる。データ受信部２１０は、クライアント１が送信したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、ネットワーク制御装置１１０を介して受信する。データ受信部２１０は、このＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを解釈（処理）するＳＳＬネゴシエーション部４１０に送る。
（図４−（２））ＳＳＬネゴシエーション部４１０は、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを処理する（ステップＳ２）。
（図４−（３））ＳＳＬネゴシエーション部４１０は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ（公開鍵の情報を含む）、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを生成し、これをデータ送信部３１０に送る（ステップＳ３）。
（図４−（４））データ送信部３１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｓｅｒｖｅｒ Ｈｅｌｌｏ／Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ／Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する（ステップＳ３）。
（図４−（５））その後、サーバ２は再びクライアント１からのメッセージ受信待ち状態になる。
（図３−（３））クライアント１のデータ受信部２００は、サーバ２が送信したＳｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを解釈（処理）するＳＳＬネゴシエーション部４００に送る。
（図３−（４））ＳＳＬネゴシエーション部４００は、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを処理し、公開鍵Ｅと公開鍵Ｎ（モジュラス）を取得する（ステップＳ４）。なお、サーバ証明書のチェックは行っても行わなくてもどちらでも構わない。
（図３−（５））ＳＳＬネゴシエーション部４００は乱数生成部５００に指示して、乱数Ａを生成させる（ステップＳ５）。なお、乱数Ａのデータ長は、公開鍵Ｎ（モジュラス）のデータ長に等しい。
（図３−（６））共通鍵生成部８００は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレット（ｍａｓｔｅｒ ｓｅｃｒｅｔ）を生成する。そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部８００は、この共通鍵を、暗号・復号化、およびＭＡＣ処理を行う共通鍵暗号・復号部８５０に渡す（ステップＳ６）。
（図３−（７））公開鍵暗号部６００は、乱数Ａを公開鍵Ｅと公開鍵Ｎで暗号化する（ステップＳ７）。
（図３−（８））パスワード暗号部７００は、公開鍵で暗号化された乱数Ａを、パスワードで暗号化し、２重暗号された乱数Ａを求める（ステップＳ８）。この手続きは、ＳＳＬ／ＴＬＳ暗号通信にはなく、ＰＡＫＥ認証のための処理である。
なおフローチャートには示していないが、このパスワードはユーザが、パスワードを入力する入力部７５０を介して、クライアント１に記憶させたパスワードとすることもできる。なおこの場合、パスワードを入力するタイミングは、事前、若しくはパスワードが必要になった時点とする。
（図３−（９））ＳＳＬネゴシエーション部４００は、２重暗号された乱数ＡをＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔとして、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅを生成する。
（図３−（１０））続いてＳＳＬネゴシエーション部４００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃを生成する（ステップＳ９）。
（図３−（１１））続いてＳＳＬネゴシエーション部４００は、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含まない）を生成する（ステップＳ１０）。
（図３−（１２））ＳＳＬネゴシエーション部４００は乱数生成部５００（乱数生成手段）に指示して、乱数Ｂを生成させる。乱数Ｂは、共通鍵暗号・復号部８５０（共通鍵暗号化手段）に渡される（ステップＳ１１）。
（図３−（１３））共通鍵暗号・復号部８５０（共通鍵暗号化手段）は、ＳＳＬネゴシエーション部４００から渡されたＦｉｎｉｓｈｅｄメッセージのデータ部のＭＡＣを求め、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）と乱数ＢとのＸＯＲ処理を行い、Ｆｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を暗号化する（ステップＳ１１）。また、共通鍵暗号・復号部８５０は、この暗号化されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を、共通鍵で暗号化し、２重暗号されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）を求める（ステップＳ１２）。
（図３−（１４））ＳＳＬネゴシエーション部４００は、２重暗号されたＦｉｎｉｓｈｅｄメッセージのデータ部（ＭＡＣを含む）からＦｉｎｉｓｈｅｄメッセージを生成する。そして、ＳＳＬネゴシエーション部４００は生成したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージをデータ送信部３００に送る。
（図３−（１５））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを送信する（ステップＳ１３）。
（図３−（１６））この後、クライアント１はサーバ２からのメッセージ受信待ち状態になる。
（図４−（５））データ受信部２１０は、クライアント１が送信したＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１１０を介して受信する（ステップＳ１４）。データ受信部２１０は、このＣｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを解釈するＳＳＬネゴシエーション部４１０に送る。
（図４−（６））ＳＳＬネゴシエーション部４１０は、Ｃｌｉｅｎｔ Ｋｅｙ ＥｘｃｈａｎｇｅメッセージからＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、つまり２重暗号された乱数Ａを読み出す。
（図４−（７））パスワード復号部７１０は、２重暗号された乱数Ａをパスワードで復号化することによって、公開鍵Ｅと公開鍵Ｎで暗号化された乱数Ａを求める（ステップＳ１５）。
（図４−（８））公開鍵復号部６１０は、公開鍵Ｅと公開鍵Ｎで暗号化された乱数Ａを、公開鍵Ｅと対となる秘密鍵Ｄと公開鍵Ｎで復号化し、乱数Ａを求める（ステップＳ１６）。
（図４−（９））共通鍵生成部８１０は、乱数Ａの内、最後の４８バイトをプリマスターシークレットとして扱い、プリマスターシークレットからマスターシークレットを生成して、そしてマスターシークレットから共通鍵暗号方式で用いる共通鍵を生成する。そして共通鍵生成部８１０は、この共通鍵を、暗号・復号化、およびＭＡＣ処理を行う共通鍵暗号・復号部８６０に渡す（ステップＳ１７）。
なお先に説明したように、乱数Ａは、プリマスターシークレットにおけるバージョン情報の設定、および、「ＰＫＣＳ ＃１ ｖｅｒｓｉｏｎ １．５」の暗号ブロックフォーマット（Ｅｎｃｒｙｐｔｉｏｎ−ｂｌｏｃｋ ｆｏｒｍａｔｔｉｎｇ）によるデータ整形が行われていないので、ＳＳＬネゴシエーション部４１０はこのチェックは行わない。ここはＳＳＬ／ＴＬＳ暗号通信の仕様とは異なる。
（図４−（１０））ＳＳＬネゴシエーション部４１０は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃメッセージを処理する（ステップＳ１８）。
（図４−（１１））ＳＳＬネゴシエーション部４１０は、Ｆｉｎｉｓｈｅｄメッセージから２重暗号されたデータ部（ＭＡＣを含む）を読み出す。そしてこの２重暗号されたデータ部（ＭＡＣを含む）を共通鍵暗号・復号部８６０に渡す。
（図４−（１２））共通鍵暗号・復号部８６０は、２重暗号されたデータ部（ＭＡＣを含む）を共通鍵で復号化し、乱数Ｂで暗号化されたデータ部（ＭＡＣを含む）を求める（ステップＳ１９）。
（図４−（１３））ＳＳＬネゴシエーション部４１０は、クライアントが生成すべきＦｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）を、自ら計算する（ステップＳ２０）。また図示していないが、ＳＳＬネゴシエーション部４１０は、このＦｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）を共通鍵暗号・復号部８６０に渡し、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含まない）のＭＡＣを計算し、Ｆｉｎｉｓｈｅｄのデータ部（ＭＡＣを含む）を取得するものとする。
（図４−（１４））認証データ取得部９１０は、乱数Ｂで暗号化（ＸＯＲ処理）されたＦｉｎｉｓｈｅｄのデータ部と、ＳＳＬネゴシエーション部４１０が計算して求めたＦｉｎｉｓｈｅｄのデータ部とのＸＯＲ処理を行い、乱数Ｂを求める（ステップＳ２１）。
（図４−（１５））ＳＳＬネゴシエーション部４１０は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを生成し、これをデータ送信部３１０に送る（ステップＳ２２）。
（図４−（１６））データ送信部３１０は、ネットワーク制御装置１１０を介して、クライアント１に対して、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを送信する（ステップＳ２２）。
（図４−（１７））その後、サーバ２は再びクライアント１からのメッセージ受信待ち状態になる。
（図３−（１６））クライアント１のデータ受信部２００は、サーバ２が送信したＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、ネットワーク制御装置１００を介して受信する。データ受信部２００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄメッセージを解釈するＳＳＬネゴシエーション部４００に送る（ステップＳ２３）。
（図３−（１７））ＳＳＬネゴシエーション部４００は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃメッセージを処理する。
（図３−（１８））ＳＳＬネゴシエーション部４００は、Ｆｉｎｉｓｈｅｄメッセージを処理する。なお、このＦｉｎｉｓｈｅｄメッセージを処理することで、クライアント１はサーバ２を認証できたことになる（ステップＳ２３）。
（図３−（１９））共通鍵暗号・復号部８５０は、乱数Ｂを共通鍵で暗号化し、これをデータ送信部３００に送る（ステップＳ２４）。
（図３−（２０））データ送信部３００は、ネットワーク制御装置１００を介して、サーバ２に対して、この共通鍵で暗号化された乱数Ｂを送信する（ステップＳ２５）。なおここの暗号化は、ＳＳＬ／ＴＬＳ暗号通信の仕様に従うので、ＭＡＣの生成、および暗号化も行う。なお、乱数Ｂは平分で送信しても危険でなく、暗号化の必要はないが、ＳＳＬ／ＴＬＳ暗号通信の仕様に合わせるものとする。
（図４−（１７））データ受信部２１０は、クライアント１が送信した共通鍵で暗号化された乱数Ｂを、ネットワーク制御装置１１０を介して受信する。データ受信部２１０は、この共通鍵で暗号化された乱数Ｂを、共通鍵暗号・復号部８６０に送る（ステップＳ２６）。
（図４−（１８））共通鍵暗号・復号部８６０は、暗号化された乱数Ｂを共通鍵で復号化し、乱数Ｂを求める（ステップＳ２７）。
（図４−（１９））認証部９２０は、自ら計算し求めた乱数Ｂと、復号した乱数Ｂとを比較（照合）し、クライアントがパスワードを知っている正規クライアントか否かを判断する（ステップＳ２８）。
次に、図７を用いてクライアント１およびサーバ２の構成の他の例について説明する。図７は、発明の実施の形態１におけるクライアントおよびサーバの機能ブロックの第２例を示す図である。
ここでは乱数Ｂを共通鍵としてバージョン情報を暗号化し、これを乱数Ｂの代わりの認証データとしている。
クライアント１は、共通鍵で暗号した乱数Ｂの代りに、共通鍵暗号・復号部８５０（共通鍵暗号化手段）で、乱数Ｂを共通鍵として暗号化したバージョン情報をサーバ２に渡している。
サーバ２は、乱数Ｂで暗号化されたバージョン情報を、共通鍵暗号・復号部８６０（共通鍵暗号化手段）で計算して求めた乱数Ｂを共通鍵として復号し、この求めたバージョン情報とあるべきバージョン情報とを、認証部９２０で照合している。なおこの共通鍵暗号はＸＯＲ処理等のような単純な暗号化ではなく、第３者が逆算できないような複雑な共通鍵暗号とした方が好ましい。なお、図２および図７において、説明をわかりやすくするために、暗号および（または）復号を行う機能ブロックを複数に分けて説明したが、勿論、１つの機能ブロックが複数の暗号処理および（または）復号処理を行ってもよい。
次に、図５を用いてクライアント１およびサーバ２のハードウェアの構成について説明する。図５は、本発明の実施の形態１におけるクライアントおよびサーバのハードウェア構成の一例を示す図である。
クライアント１は、プログラム処理を実行するＣＰＵ１０、一時的な記憶メモリであるＲＡＭ２０、キーボード等の入力装置５０とネットワークのデータ送受信を実行するＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）／ＰＨＹ４０を備える。
一方、サーバ２は、プログラム処理を実行するＣＰＵ１１、一時的な記憶メモリであるＲＡＭ２１、書き換え不可の不揮発性メモリであるＲＯＭ３１、ネットワークのデータ送受信を実行するＭＡＣ／ＰＨＹ４１を備える。
また、クライアント１とサーバ２はＭＡＣ／ＰＨＹ４０とＭＡＣ／ＰＨＹ４１を介してネットワークで接続されている。
はじめにクライアント１のハードウェア構成に関して説明を行う。図３に示したクライアント１の各処理部は、ＣＰＵ１０、およびＲＡＭ２０で実行される。但し、入力部７５０は、入力装置５０を外部インターフェースとして動作させ、ユーザが入力したパスワードを取得する。
乱数生成部５００（乱数生成手段）が生成した乱数Ａと乱数Ｂ、および、共通鍵生成部８００が生成した共通鍵は、ＲＡＭ２０に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。
また、サーバ２からＳＳＬネゴシエーション部４００が取得した公開鍵Ｅと公開鍵ＮもＲＡＭ２０に保存されるが、公開鍵は新たな公開鍵を取得した際に上書きするものとすればよく、不必要になった時点で直ちに消去する必要はない。
ＭＡＣ／ＰＨＹ４０は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１００を実現するものである。
次に、サーバ２のハードウェア構成に関して説明を行う。図３に示したサーバ２の各処理部は、ＣＰＵ１１、およびＲＡＭ２１で実行される。
クライアント１から取得した乱数Ａと乱数Ｂ、および、共通鍵生成部８１０が生成した共通鍵は、ＲＡＭ２１に保存される。なお、安全上、不必要になった時点で直ちに消去するのが好ましい。
次に、秘密鍵Ｄと公開鍵Ｎ、および、パスワードはＲＯＭ３１に保存されるが、利用時にＲＡＭ２１に移動されてもよい。なお安全上は、秘密鍵Ｄは耐タンパ装置等、セキュリティの高いメモリに保存するのが好ましい。
ＭＡＣ／ＰＨＹ４１は、ネットワーク通信を制御するハードウェアであり、ネットワーク制御装置１１０を実現するものである。
（実施の形態２）
以下、図６を用いて実施の形態２について説明する。図６は、本発明の実施の形態２におけるＰＡＫＥ認証を示すシーケンス図である。具体的には、ステップＳ２５以降の処理が異なる。実施の形態１では、クライアントはサーバに対して、乱数Ｂをデータとして提示しているが、本実施の形態では、クライアント１はサーバ２に対して、ＳＳＬ／ＴＬＳネゴシエーションの中で乱数Ｂを提示している。以下、本実施の形態では、ステップＳ２５以降の処理をステップＳ３０〜Ｓ３６として説明する。
以下、図６を用いて実施の形態２について説明する。図６は、本発明の実施の形態２におけるＰＡＫＥ認証を示すシーケンス図である。具体的には、ステップＳ２５以降の処理が異なる。実施の形態１では、クライアントはサーバに対して、乱数Ｂをデータとして提示しているが、本実施の形態では、クライアント１はサーバ２に対して、ＳＳＬ／ＴＬＳネゴシエーションの中で乱数Ｂを提示している。以下、本実施の形態では、ステップＳ２５以降の処理をステップＳ３０〜Ｓ３６として説明する。
クライアント１がサーバ２に対して、ＳＳＬの再接続を行う。具体的には、クライアント１はＳｅｓｓｉｏｎ ＩＤに、ステップＳ４で受信したＳｅｒｖｅｒ Ｈｅｌｌｏで指定されたＳｅｓｓｉｏｎ ＩＤを設定し、かつ、Ｒａｎｄｏｍ Ｂｙｔｅｓに乱数Ｂを設定したＣｌｉｅｎｔ Ｈｅｌｌｏを生成し、これをサーバ２に送信する（ステップ３０）。なお、ＳＳＬ／ＴＬＳの再接続なので、共通鍵生成には、すでに生成したマスターシークレットが利用される。
また、ＳＳＬの再接続を行う前に、一端ＴＣＰポートをクローズしない場合は、これ以降のＳＳＬ／ＴＬＳネゴシエーションでは、メッセージのデータ部は共通鍵で暗号化されるが、説明を簡単にするため、ここではメッセージのデータ部は非暗号であるものとして説明を行う。
なおここでは、乱数ＢをＲａｎｄｏｍ Ｂｙｔｅｓに設定したが、乱数Ｂの設定箇所はこれに限られるものではなく、例えば、Ｃｌｉｅｎｔ Ｈｅｌｌｏの拡張データ（ｅｘｔｒａ ｄａｔａ）等、ＳＳＬ／ＴＬＳネゴシエーションで利用する各メッセージの他の部分に挿入してもよい。
サーバ２はクライアント１から送信されたＣｌｉｅｎｔ Ｈｅｌｌｏを受信し、処理する（ステップＳ３１）。
サーバ２は自らが計算して保持する乱数Ｂと、Ｃｌｉｅｎｔ Ｈｅｌｌｏから取得した乱数Ｂとを比較（照合）する。ここで一致すれば、クライアント１はパスワードを知る正しいクライアントであると判断できる。これにより、クライアント認証が実施される（ステップＳ３２）。
そして、サーバ２はクライアント１に対してＳｅｒｖｅｒ Ｈｅｌｌｏ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、送信する（ステップＳ３３）。
クライアント１はこれらを受信し、処理する（ステップＳ３４）。そして、クライアント１はサーバ２に対してＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを生成し、送信する（ステップＳ３５）。サーバ２はこれらを受信し、処理する（ステップＳ３６）。
なお本実施の形態では、ＳＳＬ／ＴＬＳネゴシエーション後、直ちにＳＳＬ／ＴＬＳの再接続、即ちクライアント認証を行っているが、これはいつ行っても構わない。クライアント認証が必要になった時点で、サーバ２がＨｅｌｌｏ Ｒｅａｕｅｓｔ等で合図をし、それを受けてクライアント認証を行うものとしてもよい。
なおこの図６に示す一連のＳＳＬ／ＴＬＳネゴシエーションは乱数Ｂの設定、および、クライアント認証を除けば、すべてＳＳＬ／ＴＬＳ暗号通信の仕様に従っている。
本実施の形態においてもネットワーク上で送受信されるデータフォーマットは、第３者から見ればＳＳＬ／ＴＬＳ暗号通信の仕様に従っているので（図６のＥｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔ、クライアント１が送信するＦｉｎｉｓｈｅｄはＳＳＬ／ＴＬＳ暗号通信に従っていないが、暗号化データのため、第３者には、ＳＳＬ／ＴＬＳ暗号通信に従っているか否かは判断できない）、本実施の形態も同様に、第３者から見れば、通常のＳＳＬ／ＴＬＳネゴシエーションに見える。
従って、ＳＳＬ／ＴＬＳ暗号通信に対応したファイヤーウォールであれば、通信が遮断されることなく、ＰＡＫＥ認証を行うことが可能である。
しかも、ＳＳＬ／ＴＬＳ暗号通信でＰＡＫＥ認証を行いながらも、公開鍵暗号の実施回数は１回のみなので、装置にかかる負荷は小さい。
本実施の形態は実施の形態１と比較して、更に利点がある。
通常、ＳＳＬ／ＴＬＳ暗号通信を行うアプリケーションプログラムは、ＳＳＬ／ＴＬＳ暗号通信機能を、アプリケーションプログラムとは別のＯｐｅｎＳＳＬのようなＳＳＬ／ＴＬＳ暗号通信モジュールを利用することで実現している。
本実施の形態では、乱数Ｂ、つまり認証データの提示を、すべてＳＳＬ／ＴＬＳネゴシエーションの中で行っている。従って、アプリケーションプログラムがＳＳＬ／ＴＬＳ暗号通信モジュールに対して一度パスワードを与えれば、後はＳＳＬ／ＴＬＳ暗号通信モジュールがすべて実行できる。そのため、アプリケーションプログラムのつくりが複雑にならない。
なお本実施の形態では、ＳＳＬ／ＴＬＳの再接続で乱数Ｂを提示したが、もう一度、通常のＳＳＬ／ＴＬＳネゴシエーションをやり直し、その中で乱数Ｂを提示してもよい。但し、この方法の場合、公開鍵暗号は２度実行しなければならず、装置にかかる負荷が大きくなる。また、通常のＳＳＬ／ＴＬＳネゴシエーションをやり直す場合は、乱数Ｂの代りに、前回のＳＳＬ／ＴＬＳネゴシエーションで生成したプリマスターシークレットやマスターシークレットを提示することも可能である。但し、前回のＳＳＬ／ＴＬＳネゴシエーション中のメッセージ改ざんをチェックできないので好ましくない。
なおここでは、ＳＳＬ／ＴＬＳの再接続を行っているが、ＳＳＬ／ＴＬＳの再接続の負荷は公開鍵暗号に比べれば非常に小さいので、パフォーマンス的には問題にならない。
本発明にかかるＰＡＫＥ認証は、ＳＳＬ／ＴＬＳネゴシエーション中に実施できるので、ファイヤーウォール等の通信機器との親和性がよく、しかも公開鍵暗号の回数を１回に制限できるため、サーバ費用の低減を図れる等有用である。
１ クライアント
２ サーバ
１０ ＣＰＵ（クライアント側）
１１ ＣＰＵ（サーバ側）
２０ ＲＡＭ（クライアント側）
２１ ＲＡＭ（サーバ側）
３１ ＲＯＭ（サーバ側）
４０ ＭＡＣ／ＰＨＹ（クライアント側）
４１ ＭＡＣ／ＰＨＹ（サーバ側）
５０ 入力装置
１００ ネットワーク制御装置（クライアント側）
１１０ ネットワーク制御装置（サーバ側）
２００ データ受信部（クライアント側）
２１０ データ受信部（サーバ側）
３００ データ送信部（クライアント側）
３１０ データ送信部（サーバ側）
４００ ＳＳＬネゴシエーション部（クライアント側）
４１０ ＳＳＬネゴシエーション部（サーバ側）
５００ 乱数生成部
６００ 公開鍵暗号部（クライアント側）
６１０ 公開鍵復号部（サーバ側）
７００ パスワード暗号部（クライアント側）
７１０ パスワード復号部（サーバ側）
７５０ 入力部
８００ 共通鍵生成部（クライアント側）
８１０ 共通鍵生成部（サーバ側）
８５０ 共通鍵暗号・復号部（クライアント側）
８６０ 共通鍵暗号・復号部（サーバ側）
９１０ 認証データ取得部
９２０ 認証部
２ サーバ
１０ ＣＰＵ（クライアント側）
１１ ＣＰＵ（サーバ側）
２０ ＲＡＭ（クライアント側）
２１ ＲＡＭ（サーバ側）
３１ ＲＯＭ（サーバ側）
４０ ＭＡＣ／ＰＨＹ（クライアント側）
４１ ＭＡＣ／ＰＨＹ（サーバ側）
５０ 入力装置
１００ ネットワーク制御装置（クライアント側）
１１０ ネットワーク制御装置（サーバ側）
２００ データ受信部（クライアント側）
２１０ データ受信部（サーバ側）
３００ データ送信部（クライアント側）
３１０ データ送信部（サーバ側）
４００ ＳＳＬネゴシエーション部（クライアント側）
４１０ ＳＳＬネゴシエーション部（サーバ側）
５００ 乱数生成部
６００ 公開鍵暗号部（クライアント側）
６１０ 公開鍵復号部（サーバ側）
７００ パスワード暗号部（クライアント側）
７１０ パスワード復号部（サーバ側）
７５０ 入力部
８００ 共通鍵生成部（クライアント側）
８１０ 共通鍵生成部（サーバ側）
８５０ 共通鍵暗号・復号部（クライアント側）
８６０ 共通鍵暗号・復号部（サーバ側）
９１０ 認証データ取得部
９２０ 認証部
Claims (6)
- パスワードを共有する他の暗号通信装置と鍵交換処理を行う暗号通信装置であって、
第１の乱数および第２の乱数を生成する乱数生成部と、
前記他の暗号通信装置の公開鍵を用いて前記第１の乱数に基づく情報を暗号化する第１の暗号化部と、
前記第１の暗号化部によって暗号化された前記第１の乱数に基づく情報を、前記パスワードを用いて暗号化する第２の暗号化部と、
前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、
前記第２の暗号化部によって暗号化された前記第１の乱数に基づく情報を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記他の暗号通信装置に送信する送信部と、を備え、
前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を検証信号として送信する、暗号通信装置。 - 請求項１記載の暗号通信装置であって、
前記送信部は、前記第１の信号と前記第２の信号とを連続的に前記他の暗号通信装置に送信する、暗号通信装置。 - 請求項１または２記載の暗号通信装置であって、
前記第３の暗号化部は、前記他の暗号通信装置にとって既知のデータを前記第１の乱数および前記第２の乱数を用いて暗号化する、暗号通信装置。 - 請求項２記載の暗号通信装置であって、
前記他の暗号通信装置からの信号を受信する受信部を更に有し、
前記受信部が、前記他の暗号通信装置から前記パスワードを有することを証明する信号を受信する場合、
前記送信部は前記第２の乱数を前記他の暗号通信装置に送信する、暗号通信装置。 - 請求項３記載の暗号通信装置であって、
前記既知のデータは、前記他の暗号通信装置との鍵交換処理における通信履歴である、暗号通信装置。 - パスワードを共有する第１の暗号通信装置と第２の暗号通信装置との間で、鍵交換処理を行う暗号通信システムであって、
前記第１の暗号通信装置は、
第１の乱数および第２の乱数を生成する乱数生成部と、
前記第２の暗号通信装置の公開鍵を用いて前記第１の乱数を暗号化する第１の暗号化部と、
前記第１の暗号化部によって暗号化された前記第１の乱数を前記パスワードを用いて暗号化する第２の暗号化部と、
前記第２の乱数に基づく情報を前記第１の乱数を用いて暗号化する第３の暗号化部と、
前記第２の暗号化部によって暗号化された前記第１の乱数を含む第１の信号、および前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報を含む第２の信号を前記第２の暗号通信装置に送信する送信部と、を有し、
前記第２の暗号通信装置は、
前記第１の信号および前記第２の信号を受信する受信部と、前記公開鍵の対となる秘密鍵および前記パスワードを用いて前記第２の暗号化部によって暗号化された前記第１の乱数を復号化し、前記第１の乱数を取得する復号化部と、
前記復号化部が取得した前記第１の乱数を用いて、前記第３の暗号化部によって暗号化された前記第２の乱数に基づく情報から前記第２の乱数を算出する認証データ取得部と、
を有し、
前記送信部は、ＳＳＬハンドシェイクに基づいて前記第１の信号を鍵交換信号として送信すると共に、ＳＳＬハンドシェイクに基づいて前記第２の信号を検証信号として送信する、暗号通信システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011101076A JP5845393B2 (ja) | 2011-04-28 | 2011-04-28 | 暗号通信装置および暗号通信システム |
| US13/455,992 US8577039B2 (en) | 2011-04-28 | 2012-04-25 | Cryptographic communication apparatus and cryptographic communication system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011101076A JP5845393B2 (ja) | 2011-04-28 | 2011-04-28 | 暗号通信装置および暗号通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2012235214A JP2012235214A (ja) | 2012-11-29 |
| JP5845393B2 true JP5845393B2 (ja) | 2016-01-20 |
Family
ID=47067898
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011101076A Active JP5845393B2 (ja) | 2011-04-28 | 2011-04-28 | 暗号通信装置および暗号通信システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8577039B2 (ja) |
| JP (1) | JP5845393B2 (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5981761B2 (ja) * | 2012-05-01 | 2016-08-31 | キヤノン株式会社 | 通信装置、制御方法、プログラム |
| US9449167B2 (en) * | 2012-09-12 | 2016-09-20 | Infosys Limited | Method and system for securely accessing different services based on single sign on |
| US8713311B1 (en) * | 2012-11-07 | 2014-04-29 | Google Inc. | Encryption using alternate authentication key |
| KR101508859B1 (ko) * | 2013-12-30 | 2015-04-07 | 삼성에스디에스 주식회사 | 클라이언트와 서버 간 보안 세션을 수립하기 위한 방법 및 장치 |
| JP6226197B2 (ja) * | 2014-05-23 | 2017-11-08 | パナソニックＩｐマネジメント株式会社 | 証明書発行システム、クライアント端末、サーバ装置、証明書取得方法、及び証明書発行方法 |
| EP2955871B1 (en) * | 2014-06-12 | 2017-01-11 | Nagravision S.A. | Cryptographic method for securely exchanging messages and device and system for implementing this method |
| CN105635039B (zh) * | 2014-10-27 | 2019-01-04 | 阿里巴巴集团控股有限公司 | 一种网络安全通信方法及通信装置 |
| CN105491076B (zh) * | 2016-01-28 | 2019-06-07 | 西安电子科技大学 | 一种面向空天信息网的异构网络端到端认证密钥交换方法 |
| WO2019212579A1 (en) | 2018-04-30 | 2019-11-07 | Google Llc | Managing enclave creation through a uniform enclave interface |
| WO2019212581A1 (en) | 2018-04-30 | 2019-11-07 | Google Llc | Secure collaboration between processors and processing accelerators in enclaves |
| US11509643B2 (en) * | 2018-04-30 | 2022-11-22 | Google Llc | Enclave interactions |
| CN110708282B (zh) * | 2019-08-21 | 2023-06-02 | 苏州科技大学 | 一种针对双随机偏振编码加密系统的加密密钥获取方法 |
| CN111131455B (zh) * | 2019-12-24 | 2021-06-04 | 深信服科技股份有限公司 | 数据代理方法、装置、设备及存储介质 |
| CN111263328B (zh) * | 2020-01-17 | 2023-05-02 | 南京英锐创电子科技有限公司 | 车辆信息获取方法和车载设备 |
| JP7400744B2 (ja) * | 2021-01-14 | 2023-12-19 | トヨタ自動車株式会社 | 車両制御システム |
| CN113326530B (zh) * | 2021-06-29 | 2024-02-02 | 北京计算机技术及应用研究所 | 一种适用于通信双方秘钥共享的秘钥协商方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4029396B2 (ja) * | 2003-02-25 | 2008-01-09 | 日本電信電話株式会社 | 通信制御システムと通信制御方法およびプログラム |
| JP2009296190A (ja) | 2008-06-04 | 2009-12-17 | Panasonic Corp | 秘匿通信方法 |
-
2011
- 2011-04-28 JP JP2011101076A patent/JP5845393B2/ja active Active
-
2012
- 2012-04-25 US US13/455,992 patent/US8577039B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2012235214A (ja) | 2012-11-29 |
| US20120275601A1 (en) | 2012-11-01 |
| US8577039B2 (en) | 2013-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5845393B2 (ja) | 暗号通信装置および暗号通信システム | |
| US8130961B2 (en) | Method and system for client-server mutual authentication using event-based OTP | |
| WO2020087805A1 (zh) | 基于双密值和混沌加密的可信测控网络认证方法 | |
| CN109728909B (zh) | 基于USBKey的身份认证方法和系统 | |
| US11533297B2 (en) | Secure communication channel with token renewal mechanism | |
| US8670563B2 (en) | System and method for designing secure client-server communication protocols based on certificateless public key infrastructure | |
| US8291231B2 (en) | Common key setting method, relay apparatus, and program | |
| JP2018522500A (ja) | 量子鍵配布プロセスのための認証方法、デバイス及びシステム | |
| CN103763356A (zh) | 一种安全套接层连接的建立方法、装置及系统 | |
| US20050076216A1 (en) | Method for securing a communication | |
| CN110020524B (zh) | 一种基于智能卡的双向认证方法 | |
| KR20170076742A (ko) | 보안 접속 및 관련 서비스를 위한 효율적인 개시 | |
| JP2009503934A (ja) | 展性攻撃に対して改良された安全性を有する技術（これに限定されない）を含む非ワンタイムパッド暗号で暗号化した署名鍵を用いた、暗号認証、及び／又は共有暗号鍵の設定 | |
| US20110179478A1 (en) | Method for secure transmission of sensitive data utilizing network communications and for one time passcode and multi-factor authentication | |
| CN108599926B (zh) | 一种基于对称密钥池的HTTP-Digest改进型AKA身份认证系统和方法 | |
| US11399019B2 (en) | Failure recovery mechanism to re-establish secured communications | |
| KR20170035665A (ko) | 키 교환 장치 및 방법 | |
| CN110635901B (zh) | 用于物联网设备的本地蓝牙动态认证方法和系统 | |
| CN104901935A (zh) | 一种基于cpk的双向认证及数据交互安全保护方法 | |
| CN112713995A (zh) | 一种用于物联网终端的动态通信密钥分发方法及装置 | |
| JP2016522637A (ja) | 共有秘密を含意するセキュア化されたデータチャネル認証 | |
| CN108551391B (zh) | 一种基于USB-key的认证方法 | |
| US20240113885A1 (en) | Hub-based token generation and endpoint selection for secure channel establishment | |
| CN112787990B (zh) | 一种电力终端可信接入认证方法和系统 | |
| EP3185504A1 (en) | Security management system for securing a communication between a remote server and an electronic device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20140409 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20140513 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20141007 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20141118 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20141125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150123 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150602 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150615 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 5845393 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |