JP2009296190A - 秘匿通信方法 - Google Patents

Abstract

【課題】ＳＳＬ暗号通信では、中間者攻撃の脅威を防ぐために、サーバ証明書を用いているものの、その運用は簡単ではなく、中間者攻撃を十分に防げるものではない。
【解決手段】クライアント、サーバ間でパスワードを共有しているＳＳＬ暗号通信において、クライアントで、乱数データを発生させ、これを公開鍵、及びパスワードで暗号化して、サーバに渡すことで、クライアント、サーバ間で、パスワードよりビット長の長い乱数データを安全に共有し、この乱数データを用いて、安全な暗号通信を行うか、またはこの乱数データのハッシュ値を互いに提示し合うことで、中間者を排除した、安全な暗号通信を行う。
【選択図】図９

Description

本発明は、２点間で通信を安全に行う秘匿通信方法に関するものである。

近年、インターネットを介する通信では、フィッシングなどのように、中間者攻撃の脅威が増加しており、暗号通信だけでは、通信を安全に行えなくなっており、この中間者攻撃対策が望まれている。

従来、通信を安全に行う方法の１つとして、ＳＳＬ暗号通信がある。ＲＳＡ型のＳＳＬ暗号通信では、すでに中間者攻撃を軽減するしくみが備えられている。ここでは、サーバ証明書を確認することで、正しい相手との通信であるか否かを判別する方法が取られている。

しかし、サーバ証明書の確認は基本が目視のため、手間を要する。また、攻撃者が本物のサーバ証明書に似せたサーバ証明書を用意すると判断が難しい。この課題を解決するため、ＨＴＴＰブラウザは、サーバ証明書に問題がある場合に、自動で警告を表示するつくりになっている。しかし、これは予め登録されている認証機関によって、サーバ証明書が認証されているか、有効期限やデジタル署名などサーバ証明書の形式に問題がないかなどをチェックしているだけであって、攻撃者が正式なサーバ証明書を保持している場合や、攻撃者がウィルス等を利用して、攻撃者のサーバ証明書を信頼するように登録した場合には要をなさない。

最近はこの自動チェックを強化するため、ＥＶ証明書という更に強化されたサーバ証明書も登場しているが、攻撃が多少困難になるだけで、本質的な課題は変わらない。

このように、互いに知らない２点間での暗号通信では、中間者攻撃を防ぐ、真に有効な手段は現在のところ知られていない。

そこで、２点間でパスワードのような秘密の情報を共有している場合だけでも、中間者攻撃を防御できないかというのが、テーマとなる。このような制限を設けたとしても、その意義は大きい。

例えば、オンラインバンキングやネットワークカメラの視聴のような、パスワードによってユーザが特定されるインターネット通信では、ユーザに一定の権利行使権があるので、攻撃者にとって、攻撃を行う魅力がある。逆に言えば、通信者が不特定の場合は、情報価値が低いので、攻撃者にとっては、攻撃を行う魅力に欠ける。従って、２点間でパスワードを共有している場合だけでも、中間者攻撃を防御できれば、被害の大きさから言って、意義は非常に大きい。

もし２点間で、暗号的に安全と判断される程度にビット長が長いパスワードを、秘密裏に保持していれば、これを共通鍵として利用することで、暗号通信は安全に行える。しかし、これを一般の人が記憶することは困難である。

そこで、人が記憶可能なパスワード、つまり暗号的に安全と判断される程度のビット長がない秘密の情報によっても、中間者攻撃を防御できることが望まれる。

このような方法として、ＰＡＫＥ（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ−Ｅｓｔａｂｌｉｓｈｍｅｎｔ）が知られている（非特許文献１参照）。
Ｓ．Ｂｅｌｌｏｖｉｎ ａｎｄ Ｍ．Ｍｅｒｒｉｔｔ．Ｅｎｃｒｙｐｔｅｄ ｋｅｙ ｅｘｃｈａｎｇｅ： Ｐａｓｓｗｏｒｄ−ｂａｓｅｄ ｐｒｏｔｏｃｏｌｓ ｓｅｃｕｒｅ ａｇａｉｎｓｔ ｄｉｃｔｉｏｎａｒｙ ａｔｔａｃｋｓ．Ｉｎ Ｐｒｏｃ．ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈｉｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ， ７２−８４．１９９２．

しかしながら、前記従来の技術では、サーバのみならず、クライアントにおいても負荷の重い計算処理を行わなくてはならない。またＳＳＬ暗号通信を行っている場合、ここで行うＲＳＡ暗号処理とは別に、異なる暗号処理を実行しなくてはならないので、サーバにおいても負荷が大きくなる。しかも、実装メモリも増加する。

また、サーバ、クライアント間でのネゴシエーションに要する手順が増加するので、ネゴシエーション完了までの時間も延びる。

そのため、クライアントのＣＰＵ処理機能が低い場合や、サーバがＳＳＬ暗号通信において大量のクライアントと通信を行っている場合に、クライアント、サーバにおいて、パフォーマンスが低下するという問題を有している。

一般のユーザが利用する暗号通信としては、非対称な公開鍵暗号方式であるＲＳＡ型のＳＳＬ暗号通信が最もポピュラーであり、すでに広く実装され、普及している。

従って、このＲＳＡ型のＳＳＬ暗号通信に適した、パスワードを用いた、安全な中間者攻撃防御が望まれる。

本発明は、このような従来の技術の問題点を解消するべく案出されたものであり、その主な目的は、ＲＳＡのような非対称な公開鍵暗号方式において、パスワードを用いて、中間者攻撃の被害を低減させることを目的としている。

このような課題を解決するために、本願発明の第１の発明に係る秘匿通信方法では、パスワードを共有しているクライアント、サーバ間での非対称な公開鍵暗号化方式の通信で、クライアントが、公開鍵を用いた公開鍵暗号化方式による暗号化手段である公開鍵暗号化方式型暗号化手段、及び、パスワードを利用した暗号化手段であるパスワード暗号化手段、及び、乱数データを生成、若しくは他の装置から取得する乱数データ発生手段とを有し、一方サーバが、公開鍵暗号化方式型暗号化手段によって暗号化されたデータを復号する、公開鍵暗号化方式型復号化手段、及び、パスワード暗号化手段によって暗号化されたデータを復号する、パスワード復号化手段を有するものであって、クライアントは、乱数データ発生手段を用いて、乱数データを発生させ、この乱数データの暗号化を、公開鍵暗号化方式型暗号化手段を用いて行い、更にこの公開鍵暗号化方式型暗号化手段を用いて暗号化された乱数データの暗号化を、パスワード暗号化手段を用いて行い、サーバは、公開鍵暗号化方式型暗号化手段とパスワード暗号化手段によって暗号化された乱数データの復号を、公開鍵暗号化方式型復号化手段とパスワード復号化手段を用いて行うものとし、クライアント、サーバ共に、共通鍵暗号・復号を行う、パスワード暗号化手段と等価、あるいはこれとは別の共通鍵暗号化手段を有し、乱数データの少なくとも一部から生成した共通鍵、若しくは、乱数データの少なくとも一部を元鍵として生成した共通鍵を、共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うものとした。

これによると、非対称な公開鍵暗号化方式であるＲＳＡ型のＳＳＬ暗号通信を行っている場合に、このしくみをそのまま利用して、パフォーマンスを落とすことなく、しかも中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に通信を行える基盤を構築できる。尚、これはメール通信においても非常に有益である。Ｓ／ＭＩＭＥのようにデジタル証明書を用いずとも、この方式であれば、パスワード交換しておくことで、中間者攻撃を簡単に防御できる。

ここで、攻撃者が正規サーバのふりをして、正規クライアントと通信を行っても、乱数データがパスワードによって暗号化されているため、攻撃者は、公開鍵暗号方式における秘密鍵を保持しているにもかかわらず、クライアントが送信しようとしている乱数データを知ることができない。乱数データのビット長を十分に長くすれば、オフライン攻撃さえも、ほぼ不可能である。

但し、本願に示した暗号化の順番とは逆に、乱数データをパスワードで暗号化し、それを公開鍵で暗号すると、中間者攻撃が成立する。攻撃者が、正規クライアントに対して、攻撃者の公開鍵を渡せれば、正規クライアントは攻撃者から渡された公開鍵とパスワードで暗号化を行うため、攻撃者は、自らの秘密鍵を用いて、パスワードで暗号化された乱数データを算出できる。パスワードはビット長が短いので、攻撃者は、パスワードを手がかりに、オフライン攻撃を行うことができる。

尚、攻撃者が、正規クライアント、正規サーバ間に入り込んで、クライアントがサーバを認証する間は、やりとりされるデータをスルーさせたとしても、中間者攻撃は成立しない。これではクライアントに正規サーバの公開鍵が渡るので、攻撃者は盗聴できなくなる。

逆に、攻撃者が正規クライアントのふりをして、正規サーバとの通信を行ったとしても、公開鍵暗号化方式における秘密鍵を知らないので、自らが送信したデータを逆算して、パスワードを抽出することは、離散対数問題であるため、非常に難しい。オフライン攻撃さえも、ほぼ不可能である。

尚、サーバは多人数で利用されるので、サーバは各ユーザのパスワードを保持している。ここでは、サーバがどうやって該当のパスワードを選択するかを明示していないが、これはパスワード認証で用いられるように、ＩＤを利用するとするのが最も簡単である。しかし、ＩＤを用いずに、サーバが、暗号通信で自らが理解できるコマンドが出てくるまで、順に各パスワードを呼出し、計算するとすることも可能である。

尚、ここで、公開鍵暗号化方式型暗号化手段と公開鍵暗号化方式型復号化手段は、鍵が異なるだけで、データ処理方法としては、同じものでも良い。また、公開鍵暗号化方式とは、共通鍵を公開鍵暗号方式で暗号化し、この共通鍵を用いてデータを暗号するという、ハイブリッド暗号を含む。

また、ここで、パスワード暗号化手段としているものは、パスワードを鍵とする暗号であり、ＤＥＳやＡＥＳのようなよく知られた共通鍵暗号手法でも、パスワードをデータに対して掛け合わせるとするような手法でも良く、その手法は限定されない。

また、ここで、乱数データとしているものは、第三者に推測されないデータであれば良く、真の乱数であることを限定しているものではない。従って、乱数データ発生手段とは、そのようなデータを発生させるものであって、必ずしも、世の中で知られている乱数アルゴリズムに従った処理でなくても良い。

尚、乱数データというのは、データすべてがランダムというものでなく、既知のデータがいくつかあり、この並びをランダムにしたデータや、一部のデータ部分がランダムなデータというものであっても良い。但し、乱数の乱雑さも、安全性を確保する上で重要なので、実装にあたっては、十分な乱雑さを確保しなくてはならない。

また、ここで、クライアント、サーバと呼んでいるものは、単に、非対称の公開鍵暗号化方式における公開鍵だけを持つ方をクライアント、非対称の公開鍵暗号化方式における秘密鍵を持つ方をサーバと呼んでいるだけのものである。

もし、どちらも、異なる非対称の公開鍵暗号化方式の秘密鍵を、それぞれ保持するのであれば、どちらもクライアント、サーバという構成になる。

また、ここで、共通鍵暗号方式というのは、公開鍵暗号方式でないというだけのことであり、その暗号手法は様々である。また用いる共通鍵も、何らかの形で乱数データが関与していればよく、乱数データそのものである必要はない。例えば、ＳＳＬ暗号通信を行っているのであれば、これにより生成した共通鍵と、この乱数データを掛け合わせて、新しい共通鍵を生成することもできる。

また、ここで、乱数データを共通鍵としているが、これを使って、更に新たな共通鍵を交換することができるが、時間や手間を要するだけ良くない。

このような課題を解決するために、本願発明の第２の発明に係る秘匿通信方法では、請求項２に示すとおり、少なくとも、クライアントがサーバに対して、乱数データそのものや、公開鍵暗号化方式型暗号化手段とパスワード暗号化手段を用いて暗号化された先の乱数データとは異なる、乱数データの手がかりを与える別のデータや、パスワードそのものや、パスワードの手がかりを与えるデータを与える前までには、サーバがパスワードを保持するか否かの確認を、クライアントが行うものとした。

これによると、クライアントは、明確に中間者攻撃の可能性を検知できるので良い。尚、このサーバ認証は、乱数データから生成した共通鍵を用いた暗号通信を開始する前に行うとするのが安全上、望ましい。

しかし、乱数データのビット長が十分に長ければ、クライアントがサーバを認証しなくても、乱数データから生成した共通鍵を用いた暗号通信で、十分安全である。たとえ、攻撃者が、サーバのふりをして、正規クライアントとの間で通信していたとしても、暗号通信が成立しないだけで、通信内容やパスワードが攻撃者に漏れることはない。

尚、システム上の都合で、クライアントがサーバ間に対して、パスワードや乱数データを示す必要がある場合には、少なくとも、その前には、クライアントは必ずサーバを認証しておかなければならない。

また、クライアントは、サーバがパスワードを保持することの確認を行った後、これをサーバに通知することは必ずしも必要ではない。問題がなければ、この後、クライアントからアクセスをすれば良い。

本願発明に係る第３の発明に係る秘匿通信方法においては、クライアントが、任意の認証データを用意して、共通鍵暗号化手段を用いて暗号化を行い、そしてこの暗号化された認証データを、サーバに送信し、サーバが、これを、共通鍵暗号化手段を用いて復号化を行うものであって、クライアント、サーバ共に、逆算が非常に困難な逆計算困難型計算処理手段を有し、サーバは、認証データの少なくとも一部を、逆計算困難型計算処理手段によってデータ加工を行い、クライアントに対してこのデータ加工された認証データを提示するものとし、クライアントは、認証データを、サーバと同じく、逆計算困難型計算処理手段によってデータ加工を行い、このデータ加工された認証データと、サーバから受け取ったデータ加工された認証データとを比較し、一致するか否かで、サーバがパスワードを保持するか否かの判定を行うものとした。

これによると、より安全にサーバの認証を行えるようになる。但し、これはクライアントが乱数データを公開鍵で暗号化しているために、安全なのであって、この乱数データを公開鍵で暗号化せず、単にパスワードで暗号化するのみの場合、中間者攻撃が成立する。攻撃者は、パスワードを順次変えて行き、正規サーバが提示した認証データに合致するパスワードを見つけることができる。

ここで任意の認証データとは、例えば、新たな乱数データとすることができる。

また、ここで、逆計算が困難である計算処理と言っているものは、ハッシュや２乗など、一方向性関数だけに限られるものではない。例えば、ある特定ビットだけを抜き出したものとすることや、乱数データを除数、この認証データを被除数として計算した剰余を提示することなどによっても行うことがでる。これも逆計算が困難な計算処理の１つである。このように攻撃者が逆算できないものであれば、その手法は限定されない。

尚、上記方法を使えば、この認証データを新たな共通鍵として暗号化に用いることで、更に新たな認証データを送受信して認証を行うとする構成も可能である。これは何段にも渡って行えるが、計算、及びネゴシエーションに時間を要するので、好ましくない。

本願発明の第４の発明に係る秘匿通信方法では、サーバがパスワードを保持することの確認を、クライアントが行った後に、クライアントがパスワードを保持するか否かの確認を、サーバが行うものとした。

これによると、クライアント、サーバ間で相互認証を行うので、請求項１の共通鍵を用いずとも、安全に通信を行えるようになる。例えば、ＳＳＬ暗号通信を行っているのであれば、これで生成した共通鍵を用いても、安全に通信を行えるようになる。従って、ＳＳＬ暗号通信のような既存の暗号通信に手を入れる必要がなくなる。

尚、サーバがクライアントを認証する方法は、クライアントがサーバを認証するのに用いる方法を流用できる。例えば、サーバが乱数データのハッシュ値を提示するのであれば、クライアントは、乱数データの２乗や別のハッシュ値を提示するとすることが可能である。

しかし、クライアントがパスワードを保持するか否かを、サーバが確認する時点においては、クラインによるサーバ認証は終わっているので、他の手段を活用することもできる。例えば、クライアントは、乱数データそのものやパスワードそのものを、公開鍵暗号方式で暗号化し、サーバに送信することで、認証を受けることが可能である。しかし、パスワードは当然として、乱数データそのものも、平分で送信してはならない。先に送信した暗号化された乱数データと、平分の乱数データがあれば、簡単にパスワードを逆算されてしまう。

尚、サーバの認証より先に、クライアント認証を行ってはならない。攻撃者がサーバのふりをしていると、パスワードを知らない時点では、サーバ認証を成功させることには失敗するものの、クライアント認証の際に提示されたデータと、暗号化された乱数データを用いて、オフライン攻撃を行うことができる。

尚、サーバは、クライアントがパスワードを保持することの確認を行ったことを、クライアントに通知する必要はない。むしろ、攻撃者が自動プログラムを使って、オンライン攻撃をしかけてくる可能性もあるので、認証結果は知らせない方が良い。同様に、認証結果が悪くても、通信を切断しない方が良い。この場合は、適当なダミー通信すると良い。

本願発明に係る第５の秘匿通信方法においては、クライアント、サーバ共に、共通鍵暗号・復号を行う、パスワード暗号化手段、若しくは共通鍵暗号化手段と等価、若しくはこれとは別の共通鍵暗号化手段を有し、サーバとクライアントが、公開鍵暗号化方式型暗号化手段と公開鍵暗号化方式型復号化手段、若しくはパスワード暗号化手段とパスワード復号化手段、若しくは共通鍵暗号化手段、若しくはサーバからクライアントに対する、パスワードを利用した暗号通信を用いて交換した、乱数データとは別の交換データの少なくとも一部から生成した共通鍵、若しくは、交換データの少なくとも一部を元鍵として生成した共通鍵を、共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うものとした。

これによると、非対称な公開鍵暗号化方式であるＲＳＡ型のＳＳＬ暗号通信を行っている場合に、このしくみをそのまま利用して、パフォーマンスを落とすことなく、しかも中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に通信を行える基盤を構築できる。

尚、ここで、交換データとは、例えば、新たな乱数データとすることができる。例えば、ＳＳＬ暗号通信を行っているのであれば、これで生成した共通鍵が、ここで言う交換データに当たる。クライアント、サーバ間で相互認証を行うので、乱数データを共通鍵として用いずとも、例えば、ＳＳＬ暗号通信を行っているのであれば、これで生成した共通鍵を用いるだけで、安全に通信を行えるようになる。

尚、交換データの交換は、サーバ認証やクライアント認証とは関係なく、いつ行っても構わない。同様に、交換データを共通鍵とする暗号通信も、サーバ認証やクライアント認証とは関係なく、いつ行っても構わない。しかし、クライアント認証前に行った通信は中間者攻撃によって盗聴されている危険があるので、盗聴されても構わない通信に限らないといけない。

本願発明に係る第６の秘匿通信方法においては、パスワードを共有しているクライアント、サーバ間での非対称な公開鍵暗号化方式の通信で、クライアントが、公開鍵を用いた公開鍵暗号化方式による暗号化手段である公開鍵暗号化方式型暗号化手段、及び、パスワードを利用した暗号化手段であるパスワード暗号化手段、及び、乱数データを生成、若しくは他の装置から取得する乱数データ発生手段とを有し、一方サーバが、公開鍵暗号化方式型暗号化手段によって暗号化されたデータを復号する、公開鍵暗号化方式型復号化手段、及び、パスワード暗号化手段によって暗号化されたデータを復号する、パスワード復号化手段を有するものであって、クライアントは、乱数データ発生手段を用いて、乱数データを発生させ、この乱数データの暗号化を、公開鍵暗号化方式型暗号化手段を用いて行い、更にこの公開鍵暗号化方式型暗号化手段を用いて暗号化された乱数データの暗号化を、パスワード暗号化手段を用いて行い、サーバは、公開鍵暗号化方式型暗号化手段とパスワード暗号化手段によって暗号化された乱数データの復号を、公開鍵暗号化方式型復号化手段とパスワード復号化手段を用いて行うものとし、クライアント、サーバ共に、共通鍵暗号・復号を行う、パスワード暗号化手段と等価、あるいはこれとは別の共通鍵暗号化手段を有し、少なくともクライアントがサーバに対して、乱数データそのものや、公開鍵暗号化方式型暗号化手段とパスワード暗号化手段を用いて暗号化された先の乱数データとは異なる、乱数データの手がかりを与える別のデータや、パスワードそのものやパスワードの手がかりを与えるデータを与える前までには、サーバがパスワードを保持することの確認を、クライアントが行い、この後に、クライアントがパスワードを保持することの確認を、サーバが行い、サーバとクライアントが、公開鍵暗号化方式型暗号化手段と公開鍵暗号化方式型復号化手段、若しくはパスワード暗号化手段とパスワード復号化手段、若しくはサーバからクライアントに対する、パスワードを利用した暗号通信を用いて交換した、乱数データとは別の交換データの少なくとも一部から生成した共通鍵、若しくは、交換データの少なくとも一部を元鍵として生成した共通鍵を、共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うものとした。

これによると、非対称な公開鍵暗号化方式であるＲＳＡ型のＳＳＬ暗号通信を行っている場合に、このしくみをそのまま利用して、パフォーマンスを落とすことなく、しかも中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に通信を行える基盤を構築できる。

尚、ここで、交換データとは、例えば、新たな乱数データとすることができる。尚、クライアント、サーバ間で相互認証を行えば、乱数データを共通鍵として用いずとも、例えば、ＳＳＬ暗号通信を行っているのであれば、これで生成した共通鍵を用いるだけで、安全に通信を行えるようになる。従って、ＳＳＬ暗号通信で生成した共通鍵を、ここで言う交換データとすることができる。こうすれば、ＳＳＬ暗号通信のような既存の暗号通信に手を入れる必要がなくなる。

尚、交換データの交換は、サーバ認証やクライアント認証とは関係なく、いつ行っても構わない。同様に、交換データを共通鍵とする暗号通信も、サーバ認証やクライアント認証とは関係なく、いつ行っても構わない。しかし、クライアント認証前に行った通信は中間者攻撃によって盗聴されている危険があるので、盗聴されても構わない通信に限らないといけない。

尚、サーバがパスワードを保持することの確認を行った後に、直ちにクライアントがパスワードを保持することの確認を行えるので、クライアントは、サーバがパスワードを保持することの確認を行ったことを、サーバに通知する必要はない。

また、サーバも、クライアントがパスワードを保持することの確認を行ったことを、クライアントに通知する必要はない。むしろ、攻撃者が自動プログラムを使って、オンライン攻撃をしかけてくる可能性もあるので、認証結果は知らせない方が良い。同様に、認証結果が悪くても、通信を切断しない方が良い。この場合は、適当にダミー通信すると良い。

本願発明に係る第７の秘匿通信方法においては、クライアント、サーバ共に、逆算が非常に困難な逆計算困難型計算処理手段を有し、サーバは、乱数データ、若しくは、乱数データと同様の方法で新たに取り交わした乱数データの少なくとも一部を、逆計算困難型計算処理手段によってデータ加工を行い、クライアントに対してこのデータ加工された乱数データを提示するものとし、クライアントは、乱数データを、サーバと同じく、逆計算困難型計算処理手段によってデータ加工を行い、このデータ加工された乱数データと、サーバから受け取ったデータ加工された乱数データとを比較し、一致するか否かで、サーバがパスワードを保持するか否かの判定を行うものとした。

これによると、より安全にサーバの認証を行えるようになる。但し、これはクライアントが乱数データを公開鍵で暗号化しているために、安全なのであって、請求項１とは異なり、この乱数データを公開鍵で暗号化せず、単にパスワードで暗号化するのみの場合、中間者攻撃が成立する。攻撃者は、正規クライアントが送信した、パスワードで暗号化された乱数データと、正規サーバが提示したデータとを使って、オフライン攻撃を行える。

また、サーバがクライアントに対して、乱数データそのものを提示したとした場合にも、中間者攻撃が成立する。攻撃者が、正規クライアントに対して、攻撃者の公開鍵を渡せれば、正規クライアントは、攻撃者から渡された公開鍵とパスワードで暗号化を行うので、攻撃者が、これをそのまま正規サーバに転送し、サーバから提示された乱数データを、サーバの公開鍵と攻撃者の秘密鍵で復号化すれば、攻撃者は、乱数データそのものを得ることができる。

また、ここで、逆計算が困難である計算処理と言っているものは、ハッシュや２乗など、一方向性関数だけに限られるものではない。例えば、ある特定ビットだけを抜き出したものとすることもできる。攻撃者が逆算できないものであれば、その手法は限定されない。

本願発明に係る第８の秘匿通信方法においては、クライアント、サーバ共に、乱数データを記憶装置に記憶し、かつ記憶装置から記憶した乱数データを呼出す、乱数データ記憶手段を有し、クライアント、サーバ共に、乱数データを取得した後に、乱数データ記憶手段を用いて、乱数データを記憶装置に記憶し、クライアント、サーバ間での次回接続時に、クライアント、サーバ共に、乱数データ記憶手段を用いて、記憶装置から乱数データを呼出すものとした。

これによると、通信再開時に、簡単、かつ安全に再接続を行うことができる。尚ここで乱数データを、ワンタイムパスワードとして利用することも可能である。

本願発明に係る第９の秘匿通信方法においては、サーバがパスワードを保持することの確認を、クライアントが行う場合において、暗号通信を用いて、サーバが、自らの通信先情報をクライアントに対して知らせ、クライアントは自らが通信しているサーバの通信先情報と、受け取った通信先情報とから、クライアント、サーバ間に中間者が介在しないことを確認するものとした。

ここで、通信先情報というのは、例えばＩＰアドレスを利用することができる。

これによると、中間者の介在が完全に排除されるので、クライアントが、同じ接続先に再接続する際には、ＳＳＬなど通常の暗号通信を行うだけで、安全な通信を行うことができる。

但し、通信の切断から再接続までの時間が長い場合は、サーバのＩＰアドレスは、攻撃者によって付け替えられている可能性があるので、注意が必要である。

本願発明に係る第１０の秘匿通信方法においては、クライアントがパスワードを保持することの確認を、サーバが行う場合において、暗号通信を用いて、クライアントが、自らの通信先情報をサーバに対して知らせ、サーバは自らが通信しているサーバの通信先情報と、受け取った通信先情報とから、クライアント、サーバ間に中間者が介在しないことを確認するものとした。

これによると、中間者の介在が完全に排除されるので、クライアントが、再接続する際には、ＳＳＬなど通常の暗号通信を行うだけで、安全な通信を行うことができる。

但し、通信の切断から再接続までの時間が長い場合は、サーバのＩＰアドレスは、攻撃者によって付け替えられている可能性があるので、注意が必要である。

このように本発明によれば、暗号的に脆弱な、ビット長の短いパスワードを用いながら、ＳＳＬのような非対称の公開鍵暗号通信において、中間者を排除した安全な通信を、簡単かつ軽量に行える効果を得られる。

以下、本発明の実施の形態を、図面を参照しながら説明する。

図１は、本発明に係る秘匿通信方法の一例を示すフローチャートである。この秘匿通信では、クライアント、サーバ間で取り交わした乱数データを、共通鍵として用いることで、安全な暗号通信を行うことができる。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ通信で用いる公開鍵（以降、ＳＳＬ公開鍵と呼ぶ）が渡る。但し、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しで送ることもできる。この公開鍵の受け渡しに関しては、どのような手段を用いても良い。

クライアントにおいては、（１）乱数データを生成し、（２）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（３）そのＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、暗号化する。尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（４）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。

一方、サーバにおいては、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、クライアントから受信する。そして、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。尚ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（７）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ通信で用いる秘密鍵（以降、ＳＳＬ秘密鍵と呼ぶ）で復号化して、乱数データを取得する。

クライアントは、（８）送信データを準備し、（９）この送信データを、乱数データを共通鍵として、暗号化する。そして、（１０）この乱数データで暗号化された送信データを、サーバに送信する。

サーバは、（１１）この乱数データで暗号化された送信データを、クライアントから受信する。そして、（１２）この乱数データで暗号化された送信データを、乱数データを共通鍵として、復号化を行い、送信データを取得する。尚、図１では共通暗号方式として、ＤＥＳを例として掲示しているが、これはＡＥＳなどでも良く、安全な暗号方式であれれば、その方式は何でも構わない。

これにより、パスワードを保持しない中間者を排除して、安全な暗号通信を行える。尚、ここでは、クライアントが先に送信データを準備しているが、サーバが先に送信データを準備するとすることもできる。また、クライアントが最初に送信データを送る場合には、送信データは乱数データの送信と、同期する必要はなく、いつ送信しても構わない。但し、サーバが最初に送信データを送る場合には、サーバは、乱数データを取得した後に、送信データの暗号化を行うので、同期が必要である。

図２は、図１のブロック図である。クライアントは、パスワード入力部１７０を用いて、パスワードをユーザから取得し、予めパスワードを記憶保持しているサーバと秘匿通信を行うようになっている。尚、クライアントもサーバと同様に、パスワードを予め記憶保持しているとすることも可能である。

はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２のＳＳＬ公開鍵が渡る。そして、そのＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部１７０を用いて求める。

ユーザが、パスワード入力部１７０を用いてパスワードを入力する。これとは非同期に、乱数生成部１８０が乱数データを生成する。これを、公開鍵暗号部１３０がＳＳＬ公開鍵を用いて暗号化を行う。そして、ユーザのパスワード入力を待って、このＳＳＬ公開鍵で暗号された乱数データを、パスワード暗号部１４０が、パスワードを用いて、更に暗号化し、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ送信部１１０を通して、サーバ２に送信する。

パスワード復号部２４０は、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ受信部２１１を通して受信し、予め登録されているパスワードを用いて、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。

次に、公開鍵復号部２３０は、ＳＳＬ秘密鍵を用いて、このＳＳＬ公開鍵で暗号化された乱数データを復号化し、乱数データを取得する。ここで、ＳＳＬ秘密鍵は、先のＳＳＬ公開鍵と対となる鍵である。

通信部１２０は、送信したい送信データを用意し、これを共通暗号通信部１５０に送る。共通暗号通信部１５０では、乱数データを共通鍵として、この送信データを暗号化して、これを、データ送信部１１０を通してサーバ２に送信する。

共通暗号通信部２５０は、この共通鍵で暗号化された乱数データを、データ受信部２１１を通して受信し、乱数データを共通鍵として、この共通鍵で暗号化された送信データを復号化して、この乱数データを通信部２２０に送る。通信部２２０では、クライアントから送られてきた送信データを解釈する。

図３は、本発明に係る秘匿通信方法の一例を示すフローチャートである。この秘匿通信では、クライアントがサーバを認証することで、攻撃者がサーバのふりをしていないかを確認するものである。

図１との相違点は、サーバが乱数データを取得した後、乱数データを、クライアントに提示することで、サーバ認証を行っているところである。
（７）までは、図１と説明は同じである。サーバにおいては、（８）取得した乱数データを、特定のビットパターンでマスク化し、（９）マスク化された乱数データをクライアントに送信する。ここでは、取得した乱数データを、特定のビットパターンでマスク化しているが、これは第三者に気づかれないようにデータ加工できれば、どのような手法でも構わない。例えば、これをハッシュ関数など一方向性関数によって処理するとするのは、望ましいデータ加工の１つである。尚、ここで、乱数データそのものや、乱数データをパスワードで暗号化したものを提示するのは、中間者攻撃を受ける可能性があり、危険である。

クライアントにおいては、（１０）このマスク化された乱数データを受信する。（１１）クライアントもサーバと同様のマスク化を、自らが発生させた乱数データに対して
行い、（１２）この結果と、サーバから取得したマスク化された乱数データとを比較する。つまりサーバ認証を行う。これが一致すれば、サーバがパスワードを保持していることになる。もし、不一致であれば、サーバがにせものであることが判明する。尚、ユーザがパスワードを入力し間違った可能性もあるが、何度再入力しても結果が悪ければ、中間者攻撃を受けている可能性が高いことになる。

この後は、図１の（８）以降のように、乱数データを共通鍵として共通鍵暗号を行うことができる。

図４は、本発明に係る秘匿通信方法の一例を示すブロック図である。このサーバ認証では、クライアントが、乱数データとは異なる認証データを別途用意し、これをサーバに送信して、サーバがこの認証データをクライアントに対して提示できるか否かで、判定を行うようになっている。

はじめに、クライアント１がサーバに接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２のＳＳＬ公開鍵が渡る。そして、このＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部１７０を用いて求める。

ユーザが、パスワード入力部１７０を用いてパスワードを入力する。これとは非同期に、乱数生成部１８０が乱数データ１（共通鍵）を生成する。これを、公開鍵暗号部１３０がＳＳＬ公開鍵を用いて暗号化を行う。そして、ユーザのパスワード入力を待って、パスワード暗号部１４０が、このＳＳＬ公開鍵で暗号された乱数データ１を、パスワードを用いて、更に暗号化し、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データ１を、データ送信部１１０を通して、サーバに送信する。

パスワード復号部２４０は、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データ１を、データ受信部２１１を通して受信し、予め登録されているパスワードを用いて、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データ１を、復号化して、ＳＳＬ公開鍵で暗号化された乱数データ１を取得する。

次に、ＳＳＬ秘密鍵を用いて、このＳＳＬ公開鍵で暗号化された乱数データ１を、公開鍵復号部２３０において復号化し、乱数データ１（共通鍵）を取得する。ここで、ＳＳＬ秘密鍵は、先のＳＳＬ公開鍵と対となる鍵である。

そして、乱数生成部１８０は、乱数データ２（認証データ）を生成する。共通鍵暗号通信部１５０は、乱数データ１を共通鍵として、乱数データ２を暗号化し、この暗号化された乱数データ２を、データ送信部１１０を通してサーバ２に送信する。尚、この乱数データ２の生成は、乱数データ１の生成と同期を取る必要はない。また、乱数データ２の暗号化の時点では、共通鍵である乱数データ１が必要であるが、乱数データ２の送信は、乱数データ１の送信と同時に行っても良い。

共通鍵暗号通信部２５０は、この暗号化された乱数データ２を、データ受信部２１１を通して受信し、乱数データ１を共通鍵として、この暗号化された乱数データ２を復号化し、乱数データ２を取得する。

次に、ハッシュ処理部２６０が、この乱数データ２のハッシュ値を計算して、この乱数データ２のハッシュ値を、データ送信部２１０を通して、クライアントに送信する。ここで例え攻撃者が、この乱数データ２のハッシュ値を入手できたとしても、これを逆算できないので、乱数データ２を知ることはできない。従って、乱数データ１やパスワードを逆算することもできない。尚ここで、ハッシュ化する方法としては、ＭＤ５やＳＨＡ１などを用いることができる。またここでは、ハッシュ値を暗号化していないが、より安全に通信を行うために、これを乱数データ１で暗号化するものとしても良い。その際は、クライアントで復号化が必要となる。

次に、サーバ認証部１９０は、この乱数データ２のハッシュ値を、データ受信部１１１を通して受信し、これと、自らがハッシュ処理部１６０を用いて行った、乱数データ２のハッシュ値との比較を行う。つまりサーバ認証を行う。これが一致すれば、サーバがパスワードを保持していることなる。もし、不一致であれば、サーバがにせものであることが判明する。尚、ユーザがパスワードを入力し間違った可能性もあるが、何度再入力しても結果が悪ければ、中間者攻撃を受けている可能性が高いことになる。

尚、ここでは、サーバ認証を行うのに、共通鍵である乱数データ１とは異なる乱数データ２を用いているが、乱数データ１を、乱数データ２と同じ方法で提示することでも、サーバ認証を行うことができる。従って、乱数データ２は、必ずしも認証を行うのに必要なものではない。

図５は、本発明に係る秘匿通信方法の一例を示すブロック図である。この秘匿通信では、サーバ認証だけでなく、クライアント認証も行うので、攻撃者がクライアント、及びサーバのふりをしていないかを確認することができる。

サーバが乱数データ２をクライアントに提示するところまでは、図４と同じである。この後、クライアントがサーバに乱数データ２を提示して、クライアント認証を行う。

サーバ認証部１９０が、サーバの認証を行うところまでは、図４と説明は同じである。次に、サーバ認証部１９０でサーバ認証を終えたら、これを受けて、ハッシュ処理部１６０が、乱数データ２のハッシュ値を計算して、この乱数データ２のハッシュ値を、サーバ２に送信する。尚、ここで用いたハッシュ計算方法は、図４のサーバ認証で用いたハッシュ計算とは異なるものでなければならない。例えば、サーバ認証ではＭＤ５を用い、クライアント認証ではＳＨＡ１を用いるとするなど、異なるハッシュアルゴリズムを用いることもできれば、同じハッシュアルゴリズムを、違う初期値で計算することもできる。

クライアント認証部２９０は、この乱数データ２のハッシュ値を、データ受信部２１１を通して取得し、これと、自らがハッシュ処理部２６０を利用して計算した、乱数データ２のハッシュ値とを比較する。これが一致すれば、クライアントがパスワードを保持していることなる。もし、不一致であれば、クライアントはにせものであることが判明する。

尚ここでも、図４と同様に、クライアント認証に、乱数データ１ではなく、乱数データ２を用いているが、図４の説明と同様で、乱数データ１を、乱数データ２と同じ方法で提示することでも、クライアント認証を行うことができる。

最後に、クライアント認証部２９０は、認証結果を、データ送信部２１０を通して、サーバに通知する。通信部１２０は、この認証結果を、データ受信部１１１を通して、受信し、クライアント認証が終了したことを知る。

但し、クライアントは、この認証結果とは非同期に、この後データを送信することが可能なので、この認証結果の通知は必ずしも必要ではない。むしろ、攻撃者が自動プログラムを使って、オンライン攻撃をしかけてくる可能性もあるので、認証結果は知らせない方が良い。但し、認証結果ではなく、認証終了を通知するだけなら、問題はない。

図６は、本発明に係る秘匿通信方法の一例を示すフローチャートである。ここでは、クライアント、サーバの相互認証によって、中間者を排除し、その後に、ＳＳＬ通信の共通鍵だけで、安全に暗号通信を行う方法例を示している。

サーバが乱数データ２をクライアントに提示するところまでは、図４のフローチャート説明になっており、クライアントが乱数データ２をサーバに提示するところまでは、図５のフローチャー説明にもなっている。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。またこの時、このＳＳＬ暗号通信で用いる共通鍵暗号化方式が決定される。図６では、これをＤＥＳとして説明しているが、この共通鍵暗号化方式に制限はない。

クライアントにおいては、（１）乱数データを生成し、（２）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（３）このＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、更に暗号化する。尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（４）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。

一方、サーバにおいては、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを受信する。そして、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（７）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ秘密鍵で復号化して、乱数データを取得する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。

クライアントは、（８）認証データ（別の乱数データ）を生成し、（９）この認証データを、乱数データで暗号化する。そして（１０）この乱数データで暗号化された認証データをサーバに送信する。

サーバは、（１１）この乱数で暗号化された認証データを受信し、（１２）この乱数データで暗号化された認証データを、乱数データで復号化し、認証データを取得する。次に、（１３）この認証データのハッシュ値を計算し、（１４）この認証データのハッシュ値を、クライアントに送信する。

クライアントでは、（１５）この認証データのハッシュ値を受信する。そして、（１６）自らも、サーバと同様の方法で、認証データに対してハッシュ計算を行い、認証データのハッシュ値を取得する。そして、（１７）サーバから受け取った認証データのハッシュ値と、自らが計算した認証データのハッシュ値を比較する。これが一致すれば、サーバは、パスワードを保持するものと判断する。つまりサーバ認証を行う。

続いて、（１８）先に計算したハッシュ計算とは異なる方法で、認証データのハッシュ計算を行い、（１９）この認証データのハッシュ値を、サーバに送信する。

サーバでは、（２０）この認証データのハッシュ値を受信する。そして、（２１）自らも、サーバと同様の方法で、認証データに対してハッシュ計算を行い、認証データのハッシュ値を取得する。そして、（２２）サーバから受け取った認証データのハッシュ値と、自らが計算した認証データのハッシュ値を比較する。これが一致すれば、クライアントは、パスワードを保持するものと判断する。つまりクライアント認証を行う。

この後、（２３）サーバはクライアントに対して、認証終了を通知する。そして、（２４）クライアントはこの通知を受信する。

これ以降は、先にＳＳＬ通信で生成した共通鍵（以降ＳＳＬ共通鍵と呼ぶ）で暗号通信を行う。これまでに、クライアント、サーバ共に互いに認証を行っているので、ＳＳＬ共通鍵だけの暗号通信でも安全に通信を行うことができる。

図７は、図６のブロック図である。従って、サーバがクライアント認証の結果通知を行うところまでは、図５と同じである。

次に、通信部１２０は、送信データを準備する。そして、共通鍵暗号通信部１５０は、この送信データを、ＳＳＬ通信共通鍵で暗号化して、データ送信部１１０を通して、サーバ２に送信する。

共通暗号通信部２５０は、このＳＳＬ通信共通鍵で暗号化された送信データを、データ受信部２１１を通して受信し、このＳＳＬ通信共通鍵で暗号化された送信データを、ＳＳＬ共通鍵で復号化し、これを通信部２２０に送る。

通信部２２０は送信データの解釈を行う。この後は、通常のＳＳＬ通信を行う。ここでは、クライアント１からデータ送信を開始しているが、これをサーバ２からとすることもできる。

図８は、本発明に係る秘匿通信方法の一例を示すフローチャートである。ここでも、クライアント、サーバの相互認証によって、中間者を排除し、ＳＳＬ通信の共通鍵だけで、暗号通信を安全に行う方法例を示している。

但し、図６とは異なり、乱数データを共通鍵としては用いていない。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。またこの時、このＳＳＬ暗号通信で用いる共通鍵暗号化方式が決定される。図８では、これをＤＥＳとして説明しているが、この共通鍵暗号化方式に制限はない。

クライアントにおいては、（１）乱数データを生成し、（２）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（３）そのＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、更に暗号化する。尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（４）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。

一方、サーバにおいては、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを受信する。そして、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（７）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ秘密鍵で復号化して、乱数データを取得する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。

次に、（８）この乱数データのハッシュ値を計算し、（９）この乱数データのハッシュ値を、クライアントに送信する。

クライアントでは、（１０）この乱数データのハッシュ値を受信する。そして、（１１）自らも、サーバと同様の方法で、乱数データに対してハッシュ計算を行い、乱数データのハッシュ値を取得する。（１２）サーバから受け取った乱数データのハッシュ値と、自らが計算した乱数データのハッシュ値を比較して、これが一致すれば、サーバは、パスワードを保持するものと判断する。つまりサーバ認証を行う。

続いて、（１３）乱数データを、ＳＳＬ共通鍵で暗号化し、（１４）このＳＳＬ共通鍵で暗号化された乱数データをサーバに送信する。

サーバでは、（１５）このＳＳＬ共通鍵で暗号化された乱数データを受信する。そして、（１６）このＳＳＬ共通鍵で暗号化された乱数データを、ＳＳＬ共通鍵で復号し、（１７）復号した乱数データと、先に取得した乱数データとを比較する。これが一致すれば、クライアントは、パスワードを保持するものと判断する。つまりクライアント認証を行う。

この後、（１８）サーバはクライアントに対して、認証終了を通知する。そして、（１９）クライアントはこの通知を受信する。

これ以降は、ＳＳＬ共通鍵で、暗号通信を安全に行うことができる。

図９は、図８のブロック図である。

はじめに、クライアントがサーバに接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。またＳＳＬネゴシエーション後には、ＳＳＬ共通鍵が生成されている。

ユーザが、パスワード入力部１７０を用いてパスワードを入力する。これとは非同期に、乱数生成部１８０が乱数データを生成する。これを、公開鍵暗号部１３０がＳＳＬ公開鍵を用いて暗号化を行う。そして、ユーザのパスワード入力を待って、パスワード暗号部１４０が、このＳＳＬ公開鍵で暗号された乱数データを、パスワードを用いて、更に暗号化し、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ送信部１１０を通して、サーバ２に送信する。

パスワード復号部２４０は、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ受信部２１１を通して受信し、予め登録されているパスワードを用いて、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。

次に、ＳＳＬ秘密鍵を用いて、このＳＳＬ公開鍵で暗号化された乱数データを、公開鍵復号部２３０において復号化し、乱数データを取得する。ここで、ＳＳＬ秘密鍵は、先のＳＳＬ公開鍵と対となる鍵である。

次に、ハッシュ処理部２６０が、この乱数データのハッシュ値を計算して、この乱数データのハッシュ値を、データ送信部２１０を通して、クライアント１に送信する。ここで例え攻撃者が、この乱数データのハッシュ値を入手できたとしても、これを逆算できないので、乱数データを知ることはできない。従って、パスワードを逆算することもできない。尚ここで、ハッシュ化する方法としては、ＭＤ５やＳＨＡ１などを用いることができる。またここでは、ハッシュ値を暗号化していないが、より安全に通信を行うために、これをＳＳＬ共通鍵で暗号化するものとしても良い。その際は、クライアント１で復号化が必要となる。

次に、サーバ認証部１９０は、この乱数データのハッシュ値を、データ受信部１１１を通して受信し、これと、自らがハッシュ処理部１６０を用いて行った、乱数データのハッシュ値との比較を行う。つまりサーバ認証を行う。これが一致すれば、サーバ２がパスワードを保持していることになる。もし、不一致であれば、サーバ２はにせものであることが判明する。尚、ユーザがパスワードを入力し間違った可能性もあるが、何度再入力しても結果が悪ければ、中間者攻撃を受けている可能性が高いことになる。

次に、サーバ認証部１９０で認証が終了したら、これを受けて、共通鍵暗号通信部１５０が、乱数データを、ＳＳＬ共通鍵で暗号化して、このＳＳＬ共通鍵で暗号化乱された乱数データを、サーバ２に送信する。尚ここでは、乱数データそのものをサーバ２に提示するために、ＳＳＬ共通鍵で暗号化を行っているが、この乱数データに対して、サーバ認証で用いたハッシュ計算とは異なる、ハッシュ計算を行い、これを提示するものとすれば、暗号化を行う必要はない。またこの時点では、サーバ認証は終了しているので、正規クライアント１は、ＳＳＬ共通鍵で暗号化した乱数データをサーバ２に渡しても、通信の安全が脅かされることはない。

共通鍵暗号通信部２５０は、このＳＳＬ共通鍵で暗号化された乱数データを、データ受信部２１１を通して取得し、これを、ＳＳＬ共通鍵を用いて復号化して、乱数データを取得する。

そして、クライアント認証部２９０は、先に取得した乱数データと、今取得した乱数データとを比較する。これが一致すれば、クライアントがパスワードを保持していることになる。もし、不一致であれば、クライアントはにせものであることが判明する。

次に、クライアント認証部２９０は、認証終了を、データ送信部２１０を通して、クライアント１に通知する。通信部１２０は、この認証結果を、データ受信部１１１を通して、受信し、クライアント認証が終了したことを知る。

但し、クライアントは、この認証終了通知とは非同期に、送信データを送信することが可能なので、この認証終了通知は必ずしも必要ではない。むしろ、攻撃者が自動プログラムを使って、オンライン攻撃をしかけてくる可能性もあるので、認証結果は知らせない方が良い。但し、認証終了を通知するだけなら、問題はない。

この通知を受けて、通信部１２０は、送信したいデータを準備する。そして、共通鍵暗号通信部１５０は、この送信データを、ＳＳＬ通信共通鍵で暗号化して、データ送信部１１０を通して、サーバに送信する。

共通暗号通信部２２０は、このＳＳＬ通信共通鍵で暗号化された送信データを、データ受信部２１１を通して受信し、このＳＳＬ通信共通鍵で暗号化された送信データを、ＳＳＬ共通鍵で復号化し、これを通信部２２０に送る。

最後に、通信部２２０は送信データの解釈を行う。この後は、通常のＳＳＬ通信を行う。尚ここでは、クライアントからデータ送信を開始しているが、これをサーバからとすることもできる。

図１０は、本発明に係る秘匿通信方法の一例を示すフローチャートである。この秘匿通信では、クライアント、サーバ間で乱数データを取り交わした後、一旦通信を切断し、その後、先に取り交わした乱数データを用いて、通信を再開する。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。但し、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しで送ることもできる。公開鍵の受け渡しに関しては、どのような手段を用いても良い。

クライアントにおいては、（１）乱数データを生成し、（２）この乱数データをＨＤＤなど不揮発メモリに記憶し、（３）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（４）そのＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、更に暗号化する。

尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。尚ここで、乱数データの不揮発メモリへの記憶は、通信切断とは非同期に行える。乱数データの不揮発メモリへの記憶は、少なくとも、クライアントの電源が落とされる前までに行えば良い。但し、通信切断で、揮発性メモリにある乱数データが消去されるのであれば、通信切断前に、不揮発性メモリに記憶しなければならない。

一方、サーバにおいては、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、クライアントから受信する。この後、（７）クライアント、サーバ間の通信が切断される。そしてサーバは、（８）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（９）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ秘密鍵で復号化して、乱数データを取得し、（１０）この乱数データＨＤＤなど不揮発メモリに記憶する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。尚、ここで通信切断を（７）としたが、これは、（１０）の後でも良い。また、クライアントと同様で、乱数データの不揮発メモリへの記憶は、通信切断とは非同期に行える。少なくとも、サーバの電源が落とされる前までに行えば良い。但し、通信切断で、揮発性メモリにある乱数データが消去されるのであれば、通信切断前に、不揮発性メモリに記憶しなければならない。

そして、クライアントが通信を再開する。尚ここで、サーバが該当する乱数データの呼出す方法は、クライアントがサーバに再度ＩＤを指定する方法でも、サーバがクライアントの通信先情報から記憶している乱数データを呼出す方法でも良く、特に制限はない。

このようにして、クライアント、サーバ共に乱数データを不揮発性メモリから呼出し、クライアントは、（１１）送信データを準備し、（１２）この送信データを、乱数データを共通鍵として、暗号化する。そして、（１３）この乱数データで暗号化された送信データを、サーバに送信する。

サーバは、（１４）この乱数データで暗号化された送信データを受信する。そして、（１５）この乱数データで暗号化された送信データを、乱数データを共通鍵として、復号化を行い、送信データを取得する。尚、図１では共通暗号方式として、ＤＥＳを例として掲示しているが、これはＡＥＳなどでも良く、安全な暗号方式であれれば、その方式は何でも構わない。

尚ここでは、クライアントから先に送信データを送信しているが、これをサーバから先に送信データを送信することもできる。

図１１は、図１０のブロック図である。

はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２のＳＳＬ公開鍵が渡る。

ユーザが、パスワード入力部１７０を用いてパスワードを入力する。これとは非同期に、乱数生成部１８０が乱数データを生成する。この乱数データは、乱数記憶部１８１によって記憶される。また、この乱数データを、公開鍵暗号部１３０がＳＳＬ公開鍵を用いて暗号化を行う。そして、ユーザのパスワード入力を待って、パスワード暗号部１４０が、このＳＳＬ公開鍵で暗号された乱数データを、パスワードを用いて、更に暗号化し、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ送信部１１０を通して、サーバ２に送信する。

パスワード復号部２４０は、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、データ受信部２１１を通して受信し、予め登録されているパスワードを用いて、このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。

次に、ＳＳＬ秘密鍵を用いて、このＳＳＬ公開鍵で暗号化された乱数データを、公開鍵復号部２３０において復号化し、乱数データを取得し、この乱数データを、乱数記憶部２８１に記憶する。ここで、ＳＳＬ秘密鍵は、先のＳＳＬ公開鍵と対となる鍵である。

クライアント１が、パスワードとＳＳＬ公開鍵とで暗号化された乱数データをサーバ２に渡した後のいずれの時点で、クライアント１、サーバ２間の通信が一旦切断される。そして、クライアント１は、通信を再開する。尚ここで、サーバ２が該当する乱数データの呼出す方法は、クライアントがサーバに再度ＩＤを指定する方法でも、サーバがクライアントの通信先情報から記憶している乱数データを呼出す方法でも良く、特に制限はない。

通信部１２０は送信データを生成し、共通鍵暗号通信部１５０が、この送信データを、乱数データを共通鍵として暗号し、この乱数データで暗号化された送信データを、データ送信部１１０を通して、サーバに送信する。

共通鍵暗号通信部２５０は、この乱数データで暗号化された送信データを、データ受信部２１１を通して受信し、この乱数データで暗号化された送信データを、乱数データを共通鍵として復号する。通信部２２０はこの送信データを解釈する。

尚ここでは、クライアント１が先に送信データを送信しているが、これをサーバ２が先に送信データを送信することもできる。

図１２は、本発明に係る秘匿通信方法の一例を示すフローチャートである。これは図１０と、（１０）乱数データを記憶するところまでは、同じである。この後、呼出した乱数データを利用して、サーバ認証、クライアント認証を行い、通常のＳＳＬ暗号通信を行うものである。

次に、クライアントは、通信を再開するため、ＳＳＬネゴシエーションを行う。この時、このＳＳＬ通信で用いる共通鍵暗号化方式が決定される。図８では、これをＤＥＳとして説明しているが、この共通鍵暗号化方式に制限はない。

また、ここで、サーバが該当する乱数データを呼出す方法は、クライアントがサーバに再度ＩＤを指定する方法でも、サーバがクライアントの通信先情報から記憶している乱数データを呼出す方法でも良く、特に制限はない。また、乱数データの呼出しは、ＳＳＬネゴシエーションの前であっても良い。

このようにして、クライアント、サーバ共に乱数データを不揮発性メモリから呼出し、サーバは、（１１）乱数データのハッシュ値を計算し、（１２）この乱数データのハッシュ値を、クライアントに送信する。

クライアントでは、（１３）この乱数データのハッシュ値を受信する。そして、（１４）自らも、サーバと同様の方法で、乱数データに対してハッシュ計算を行い、乱数データのハッシュ値を取得する。（１５）サーバから受け取った乱数データのハッシュ値と、自らが計算した乱数データのハッシュ値を比較する。これが一致すれば、サーバは、パスワードを保持するものと判断する。つまりサーバ認証を行う。

続いて、（１６）乱数データを、ＳＳＬ共通鍵で暗号化し、（１７）このＳＳＬ共通鍵で暗号化された乱数データをサーバに送信する。

サーバでは、（１８）このＳＳＬ共通鍵で暗号化された乱数データを受信する。そして、（１９）このＳＳＬ共通鍵で暗号化された乱数データを、ＳＳＬ共通鍵で復号し、（２０）復号した乱数データと、先に取得した乱数データとを比較する。これが一致すれば、クライアントは、パスワードを保持するものと判断する。つまりクライアント認証を行う。

この後、（２１）サーバはクライアントに対して、認証終了を通知する。そして、（２２）クライアントはこの通知を受信する。

これ以降は、先にＳＳＬ通信で生成した共通鍵（以降ＳＳＬ共通鍵と呼ぶ）で暗号通信を行う。

図１３は、図１２のブロック図である。従って、図１１と、乱数データを記憶するところまでは、同じである。この後、呼出した乱数データを利用して、サーバ認証、クライアント認証を行い、通常のＳＳＬ暗号通信を行うものである。

次に、クライアント１は、通信を再開するため、ＳＳＬネゴシエーションを行う。

また、ここで、サーバ２が該当する乱数データの呼出す方法は、クライアント１がサーバ２に再度ＩＤを指定する方法でも、サーバがクライアントの通信先情報から記憶している乱数データを呼出す方法でも良く、特に制限はない。また、乱数データの呼出しは、ＳＳＬネゴシエーションの前であっても良い。

次に、乱数記憶部２８１が乱数データを呼出す。次に、ハッシュ処理部２６０が、この乱数データのハッシュ値を計算して、この乱数データのハッシュ値を、データ送信部２１０を通して、クライアント１に送信する。ここで例え攻撃者が、この乱数データのハッシュ値を入手できたとしても、これを逆算できないので、乱数データを知ることはできない。従って、パスワードを逆算することもできない。

尚、ここで、ハッシュ化する方法としては、ＭＤ５やＳＨＡ１などを用いることができる。またここでは、ハッシュ値を暗号化していないが、より安全に通信を行うために、これをＳＳＬ共通鍵で暗号化するものとしても良い。その際は、クライアントで復号化が必要となる。

次に、サーバ認証部１９０は、この乱数データのハッシュ値を、データ受信部１１１を通して受信し、これと、自らがハッシュ処理部１６０を用いて行った、乱数データのハッシュ値との比較を行う。つまりサーバ認証を行う。これが一致すれば、サーバがパスワードを保持していることになる。もし、不一致であれば、サーバがにせものであることが判明する。尚、ユーザがパスワードを入力し間違った可能性もあるが、何度再入力しても結果が悪ければ、中間者攻撃を受けている可能性が高いことになる。

次に、サーバ認証部１９０で、認証が終了したら、これを受けて、共通鍵暗号通信部１５０が、乱数データを、ＳＳＬ共通鍵で暗号化して、このＳＳＬ共通鍵で暗号化された乱数データを、サーバ２に送信する。

尚、ここでは、乱数データそのものをサーバ２に提示するために、ＳＳＬ共通鍵で暗号化を行っているが、この乱数データに対して、サーバ認証で用いたハッシュ計算とは異なる、ハッシュ計算を行い、これを提示するものとすれば、暗号化を行う必要はない。またこの時点では、サーバ認証は終了しているので、正規クライアントは、ＳＳＬ共通鍵で暗号化した乱数データをサーバ２に渡しても、通信の安全が脅かされることはない。

共通鍵暗号通信部２５０は、このＳＳＬ共通鍵で暗号化された乱数データを、データ受信部２１１を通して取得し、これを、ＳＳＬ共通鍵を用いて復号化して、乱数データを取得する。

そして、クライアント認証部２９０は、先に呼出した乱数データと、今取得した乱数データとを比較する。これが一致すれば、クライアントがパスワードを保持していることになる。もし、不一致であれば、クライアントはにせものであることが判明する。

次に、クライアント認証部２９０は、この認証終了を、データ送信部２１０を通して、クライアント１に通知する。通信部１２０は、この認証終了を、データ受信部１１１を通して、受信し、クライアント認証が終了したことを知る。

但し、この認証終了通知は必ずしも必要ではない。

この認証終了通知を受けて、通信部１２０は、送信データを準備する。そして、共通鍵暗号通信部１５０は、この送信データを、ＳＳＬ通信共通鍵で暗号化して、データ送信部１１０を通して、サーバ２に送信する。

共通暗号通信部２５０は、このＳＳＬ通信共通鍵で暗号化された送信データを、データ受信部２１１を通して受信し、このＳＳＬ通信共通鍵で暗号化された送信データを、ＳＳＬ共通鍵で復号化し、これを通信部２２０に送る。

通信部２２０は送信データの解釈を行う。この後は、通常のＳＳＬ通信を行う。ここでは、クライアントからデータ送信を開始しているが、これをサーバからとすることもできる。

図１４は、本発明に係る秘匿通信方法の一例を示すフローチャートである。ここでは、クライアント、サーバの相互認証によって、中間者攻撃を排除するだけでなく、サーバが自らの通信先情報をクライアントに送ることで、中間者を経由した通信をも排除するものである。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。またこの時、このＳＳＬ通信で用いる共通鍵暗号化方式が決定される。図１４では、これをＤＥＳとして説明しているが、この共通鍵暗号化方式に制限はない。

クライアントにおいては、（１）乱数データを生成し、（２）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（３）そのＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、暗号化する。尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（４）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。

一方、サーバにおいては、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、クライアントから受信する。そして、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（７）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ秘密鍵で復号化して、乱数データを取得する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。

次に、（８）この乱数データのハッシュ値を計算し、更に（９）サーバの通信先情報を、ＳＳＬ共通鍵で暗号化する。ここで通信先情報としてはＩＰアドレスなどを利用すると良い。尚ここで、サーバの通信先情報を、ＳＳＬ共通鍵で暗号化しているところを、乱数データで暗号化するとするのは望ましくない。このような決まりきったデータを乱数データで暗号化すると、オフライン攻撃が可能となる。またこれを暗号化しないというのも良くない。攻撃者が中間にいた場合、攻撃者はこれを自らの通信先情報に付け替えることができてしまう。但し、このような値が決まりきったデータを、ＳＳＬ共通鍵で暗号するのも、ＳＳＬ共通鍵を推測する手がかりを与えかねないので、望ましいとは言えない。そこで、新たな乱数データをかけてデータを拡散させ、その乱数データと拡散した通信先情報をＳＳＬ共通鍵で暗号化するような工夫を行うと良い。

尚、ここで、通信先情報を暗号化している理由は、内容を秘匿するためでなく、データを改ざんさせないためのものである。

そして、（１０）この乱数データのハッシュ値とＳＳＬ共通鍵で暗号化されたサーバの通信先情報とを共に、クライアントに送信する。

クライアントでは、（１１）この乱数データのハッシュ値とサーバの通信先情報を共に受信する。そして、（１２）自らも、サーバと同様の方法で、乱数データに対してハッシュ計算を行う。（１３）サーバから受け取った乱数データのハッシュ値と、自らが計算した乱数データのハッシュ値とを比較して、これが一致すれば、サーバは、パスワードを保持するものと判断する。つまりサーバ認証を行う。

同時に、（１４）ＳＳＬ共通鍵で暗号化されたサーバの通信先情報をＳＳＬ共通鍵で復号化し、（１５）自らが通信しているサーバの通信先情報と、復号化した通信先情報とを比較し、中間者を経由することなく、通信を行っていることを確認する。

これにより、この後、通信を遮断、再開する場合に、通常のＳＳＬ通信だけで安全な通信を行うことが可能となる。但し、再開までの時間が長い場合は、その間に、攻撃者が正規サーバの通信先情報を変更している可能性があるので、注意を要する。インターネットバンキングのように、攻撃者が正規サーバにアクセスできない環境であれば、その心配はほとんどない。

続いて、クライアントは、（１６）乱数データを、ＳＳＬ共通鍵で暗号化し、（１７）このＳＳＬ共通鍵で暗号化された乱数データをサーバに送信する。

サーバでは、（１８）このＳＳＬ共通鍵で暗号化された乱数データを受信する。そして、（１９）このＳＳＬ共通鍵で暗号化された乱数データを、ＳＳＬ共通鍵で復号し、（２０）復号した乱数データと、先に取得した乱数データとを比較する。これが一致すれば、クライアントは、パスワードを保持するものと判断する。つまりクライアント認証を行う。

この後、（２１）サーバはクライアントに対して、認証終了を通知する。そして、（２２）クライアントはこの通知を受信する。

これ以降は、ＳＳＬ共通鍵で暗号通信を行う。尚、このように、クライアント、サーバ間で相互認証を行う場合は、この後に、サーバがクライアントに対して、通信先情報を知らせるとするのが、安全上、望ましい。

図１５は、本発明に係る秘匿通信方法の一例を示すフローチャートである。ここでも、クライアント、サーバの相互認証によって、中間者攻撃を排除するだけでなく、サーバが自らの通信先情報をクライアントに送ることで、中間者を経由した通信をも排除するものである。図１４との違いは、クライアントの方が、サーバに対して、自らの通信先情報を知らせているところである。尚、双方が、互いの通信先情報を知らせるとするのが、安全上は望ましい。

クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバのＳＳＬ公開鍵が渡る。またこの時、このＳＳＬ暗号通信で用いる共通鍵暗号化方式が決定される。図１５では、これをＤＥＳとして説明しているが、この共通鍵暗号化方式に制限はない。

クライアントにおいては、（１）乱数データを生成し、（２）これをＳＳＬ公開鍵で暗号化する。ここで、乱数データのビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。そして、（３）そのＳＳＬ公開鍵で暗号化された乱数データを、パスワードを用いて、暗号化する。尚、パスワードのビット長は極端に短くなければ、中間者攻撃は困難であり、安全である。但し、暗号化の順番を変えると、中間者攻撃が可能となるので、正しく順番を守る必要がある。そして、（４）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、サーバに送信する。

一方、サーバにおいては、（５）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、クライアントから受信する。そして、（６）このパスワードとＳＳＬ公開鍵とで暗号化された乱数データを、まずパスワードを用いて復号化して、ＳＳＬ公開鍵で暗号化された乱数データを取得する。尚ここで、サーバがどのようにしてクライアントのパスワードを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。

次に、（７）このＳＳＬ公開鍵で暗号化された乱数データを、サーバのＳＳＬ秘密鍵で復号化して、乱数データを取得する。もし、ここで攻撃者がサーバのふりをできたとしても、パスワードを知らないので、乱数データの復号はできない。また、暗号化された乱数データ以外に、他に手がかりもないので、オフライン攻撃も困難である。

次に、（８）この乱数データのハッシュ値を計算し、（９）この乱数データのハッシュ値をクライアントに送信する。

クライアントでは、（１０）この乱数データのハッシュ値を受信する。そして、（１１）自らも、サーバと同様の方法で、乱数データに対してハッシュ計算を行う。（１２）サーバから受け取った乱数データのハッシュ値と、自らが計算した乱数データのハッシュ値とを比較して、これが一致すれば、サーバは、パスワードを保持するものと判断する。つまりサーバ認証を行う。

続いて、（１３）乱数データをＳＳＬ共通鍵で暗号化し、更に（１４）クライアントの通信先情報を、ＳＳＬ共通鍵で暗号化する。ここで通信先情報としてはＩＰアドレスなどを利用すると良い。尚、ここではクライアントの通信先情報を、ＳＳＬ共通鍵で暗号化している部分を、乱数データで暗号化するのは望ましくない。このような決まりきったデータを乱数データで暗号化すると、オフライン攻撃が可能となる。またこれを暗号化しないというのも良くない。攻撃者が中間にいた場合、攻撃者はこれを自らの通信先情報に付け替えることができてしまう。

但し、このような値の決まりきったデータを、ＳＳＬ共通鍵で暗号するのも、ＳＳＬ共通鍵を推測する手がかりを与えかねないので、望ましいとは言えない。そこで、新たな乱数データをかけてデータを拡散させ、その乱数データと拡散した通信先情報をＳＳＬ共通鍵で暗号化するような工夫を行うと良い。

尚、ここで通信先情報を暗号化している理由は、内容を秘匿するためでなく、データを改ざんさせないためのものである。

続いて、クライアントは、（１５）このＳＳＬ共通鍵で暗号化された乱数データと、同じくＳＳＬ共通鍵で暗号化されたクライアントの通信先情報とをサーバに送信する。

サーバでは、（１６）このＳＳＬ共通鍵で暗号化された乱数データと、同じくＳＳＬ共通鍵で暗号化されたクライアントの通信先情報とを受信する。そして、（１７）このＳＳＬ共通鍵で暗号化された乱数データを、ＳＳＬ共通鍵で復号し、（１８）復号した乱数データと、先に取得した乱数データとを比較して、これが一致すれば、クライアントは、パスワードを保持するものと判断する。つまりクライアント認証を行う。

乱数データの処理と同時に、（１９）ＳＳＬ共通鍵で暗号化されたクライアントの通信先情報をＳＳＬ共通鍵で復号化し、（２０）自らが通信しているクライアントの通信先情報と、復号化した通信先情報とを比較し、中間者を経由することなく、通信を行っていることを確認する。

これにより、この後、通信を遮断、再開する場合に、通常のＳＳＬ通信だけで安全な通信を行うことが可能となる。但し、再開までの時間が長い場合は、その間に、攻撃者が正規クライアントの通信先情報を変更している可能性があるので、注意を要する。

その後、（２１）サーバはクライアントに対して、認証終了を通知する。そして、（２２）クライアントはこの通知を受信する。

これ以降は、先にＳＳＬ通信で生成した共通鍵（以降ＳＳＬ共通鍵と呼ぶ）で暗号通信を行う。

本発明に係る秘匿通信は、暗号的に脆弱な、ビット長の短いパスワードを用いながら、ＳＳＬのような非対称の公開鍵暗号通信において、中間者を排除した安全な通信を、簡単かつ軽量に行える。特に、ＳＳＬ機能を搭載した機器に対しては、実装を非常に簡単に行うことができて、有用である。

本発明に係る秘匿通信方法の一例を示すフローチャート 図１のブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 本発明に係る秘匿通信方法の一例を示すブロック図 本発明に係る秘匿通信方法の一例を示すブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 図６のブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 図８のブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 図１０のブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 図１２のブロック図 本発明に係る秘匿通信方法の一例を示すフローチャート 本発明に係る秘匿通信方法の一例を示すフローチャート

符号の説明

１ クライアント
２ サーバ
１００ ネットワーク制御部（クライアント側）
１１０ データ送信部（クライアント側）
１１１ データ受信部（クライアント側）
１２０ 通信部（クライアント側）
１３０ 公開鍵暗号部（公開鍵暗号方式型暗号化手段）
１４０ パスワード暗号部（パスワード暗号化手段）
１５０ 共通鍵暗号通信部（共通鍵暗号化手段、共通鍵暗号化手段１、共通鍵暗号化手段２）
１６０ ハッシュ処理部（逆計算困難型計算処理手段）
１７０ パスワード入力部
１８０ 乱数生成部（乱数データ発生手段）
１８１ 乱数記憶部（乱数データ記憶手段）
１９０ サーバ認証部
２００ ネットワーク制御部（サーバ側）
２１０ データ送信部（サーバ側）
２１１ データ受信部（サーバ側）
２２０ 通信部（サーバ側）
２３０ 公開鍵復号部（公開鍵暗号方式型復号化手段）
２４０ パスワード復号部（パスワード復号化手段）
２５０ 共通鍵暗号通信部（共通鍵暗号化手段、共通鍵暗号化手段１、共通鍵暗号化手段２）
２６０ ハッシュ処理部（逆計算困難型計算処理手段）
２８１ 乱数記憶部（乱数データ記憶手段）
２９０ クライアント認証部

Claims (10)

1. パスワードを共有しているクライアント、サーバ間での非対称な公開鍵暗号化方式の通信で、
   クライアントが、公開鍵を用いた公開鍵暗号化方式による暗号化手段である公開鍵暗号化方式型暗号化手段、及び、前記パスワードを利用した暗号化手段であるパスワード暗号化手段、及び、乱数データを生成、若しくは他の装置から取得する乱数データ発生手段とを有し、
   一方サーバが、前記公開鍵暗号化方式型暗号化手段によって暗号化されたデータを復号する、公開鍵暗号化方式型復号化手段、及び、前記パスワード暗号化手段によって暗号化されたデータを復号する、パスワード復号化手段を有するものであって、
   クライアントは、前記乱数データ発生手段を用いて、乱数データを発生させ、この前記乱数データの暗号化を、前記公開鍵暗号化方式型暗号化手段を用いて行い、更にこの前記公開鍵暗号化方式型暗号化手段を用いて暗号化された前記乱数データの暗号化を、前記パスワード暗号化手段を用いて行い、
   サーバは、前記公開鍵暗号化方式型暗号化手段と前記パスワード暗号化手段によって暗号化された前記乱数データの復号を、前記公開鍵暗号化方式型復号化手段と前記パスワード復号化手段を用いて行うものとし、
   クライアント、サーバ共に、共通鍵暗号・復号を行う、前記パスワード暗号化手段と等価、あるいはこれとは別の共通鍵暗号化手段を有し、前記乱数データの少なくとも一部から生成した共通鍵、若しくは、前記乱数データの少なくとも一部を元鍵として生成した共通鍵を、前記共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うことを特徴とする秘匿通信。
2. 少なくとも、クライアントがサーバに対して、前記乱数データそのものや、前記公開鍵暗号化方式型暗号化手段と前記パスワード暗号化手段を用いて暗号化された先の前記乱数データとは異なる、前記乱数データの手がかりを与える別のデータや、前記パスワードそのものや、前記パスワードの手がかりを与えるデータを与える前までには、
   サーバが前記パスワードを保持するか否かの確認を、クライアントが行うことを特徴とする請求項１に記載の秘匿通信。
3. クライアントが、任意の認証データを用意して、前記共通鍵暗号化手段１を用いて暗号化を行い、そしてこの暗号化された前記認証データを、サーバに送信し、サーバが、これを、前記共通鍵暗号化手段を用いて復号化を行うものであって、
   クライアント、サーバ共に、逆算が非常に困難な逆計算困難型計算処理手段を有し、
   サーバは、前記認証データの少なくとも一部を、前記逆計算困難型計算処理手段によってデータ加工を行い、クライアントに対してこのデータ加工された前記認証データを提示するものとし、
   クライアントは、前記認証データを、サーバと同じく、前記逆計算困難型計算処理手段によってデータ加工を行い、このデータ加工された前記認証データと、サーバから受け取ったデータ加工された前記認証データとを比較し、一致するか否かで、サーバが前記パスワードを保持するか否かの判定を行うことを特徴とする請求項２に記載の秘匿通信。
4. サーバが前記パスワードを保持することの確認を、クライアントが行った後に、クライアントが前記パスワードを保持するか否かの確認を、サーバが行うことを特徴とする請求項２に記載の秘匿通信。
5. クライアント、サーバ共に、共通鍵暗号・復号を行う、前記パスワード暗号化手段、若しくは前記共通鍵暗号化手段と等価、若しくはこれとは別の共通鍵暗号化手段２を有し、
   サーバとクライアントが、前記公開鍵暗号化方式型暗号化手段と前記公開鍵暗号化方式型復号化手段、若しくは前記パスワード暗号化手段と前記パスワード復号化手段、若しくは前記共通鍵暗号化手段、若しくはサーバからクライアントに対する、パスワードを利用した暗号通信を用いて交換した、前記乱数データとは別の交換データの少なくとも一部から生成した共通鍵、若しくは、前記交換データの少なくとも一部を元鍵として生成した共通鍵を、前記共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うことを特徴とする請求項４に記載の秘匿通信。
6. パスワードを共有しているクライアント、サーバ間での非対称な公開鍵暗号化方式の通信で、
   クライアントが、公開鍵を用いた公開鍵暗号化方式による暗号化手段である公開鍵暗号化方式型暗号化手段、及び、前記パスワードを利用した暗号化手段であるパスワード暗号化手段、及び、乱数データを生成、若しくは他の装置から取得する乱数データ発生手段とを有し、
   一方サーバが、前記公開鍵暗号化方式型暗号化手段によって暗号化されたデータを復号する、公開鍵暗号化方式型復号化手段、及び、前記パスワード暗号化手段によって暗号化されたデータを復号する、パスワード復号化手段を有するものであって、
   クライアントは、前記乱数データ発生手段を用いて、乱数データを発生させ、この前記乱数データの暗号化を、前記公開鍵暗号化方式型暗号化手段を用いて行い、更にこの前記公開鍵暗号化方式型暗号化手段を用いて暗号化された前記乱数データの暗号化を、前記パスワード暗号化手段を用いて行い、
   サーバは、前記公開鍵暗号化方式型暗号化手段と前記パスワード暗号化手段によって暗号化された前記乱数データの復号を、前記公開鍵暗号化方式型復号化手段と前記パスワード復号化手段を用いて行うものとし、
   クライアント、サーバ共に、共通鍵暗号・復号を行う、前記パスワード暗号化手段と等価、あるいはこれとは別の共通鍵暗号化手段を有し、
   少なくともクライアントがサーバに対して、前記乱数データそのものや、前記公開鍵暗号化方式型暗号化手段と前記パスワード暗号化手段を用いて暗号化された先の前記乱数データとは異なる、前記乱数データの手がかりを与える別のデータや、前記パスワードそのものや前記パスワードの手がかりを与えるデータを与える前までには、サーバが前記パスワードを保持することの確認を、クライアントが行い、この後に、クライアントが前記パスワードを保持することの確認を、サーバが行い、
   サーバとクライアントが、前記公開鍵暗号化方式型暗号化手段と前記公開鍵暗号化方式型復号化手段、若しくは前記パスワード暗号化手段と前記パスワード復号化手段、若しくはサーバからクライアントに対する、パスワードを利用した暗号通信を用いて交換した、乱数データとは別の交換データの少なくとも一部から生成した共通鍵、若しくは、前記交換データの少なくとも一部を元鍵として生成した共通鍵を、前記共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うことを特徴とする秘匿通信。
7. クライアント、サーバ共に、逆算が非常に困難な逆計算困難型計算処理手段を有し、
   サーバは、前記乱数データ、若しくは、前記乱数データと同様の方法で新たに取り交わした乱数データの少なくとも一部を、前記逆計算困難型計算処理手段によってデータ加工を行い、クライアントに対してこのデータ加工された前記乱数データを提示するものとし、
   クライアントは、前記乱数データを、サーバと同じく、前記逆計算困難型計算処理手段によってデータ加工を行い、このデータ加工された前記乱数データと、サーバから受け取ったデータ加工された前記乱数データとを比較し、一致するか否かで、サーバが前記パスワードを保持するか否かの判定を行うことを特徴とする請求項２、及び６に記載の秘匿通信。
8. クライアント、サーバ共に、乱数データを記憶装置に記憶し、かつ記憶装置から記憶した乱数データを呼出す、乱数データ記憶手段を有し、
   クライアント、サーバ共に、乱数データを取得した後に、前記乱数データ記憶手段を用いて、乱数データを記憶装置に記憶し、
   クライアント、サーバ間での次回接続時に、クライアント、サーバ共に、前記乱数データ記憶手段を用いて、記憶装置から乱数データを呼出すことを特徴とする請求項１及び６に記載の秘匿通信。
9. サーバが前記パスワードを保持することの確認を、クライアントが行う場合において、前記暗号通信を用いて、サーバが、自らの通信先情報をクライアントに対して知らせ、クライアントは自らが通信しているサーバの通信先情報と、受け取った通信先情報とから、クライアント、サーバ間に中間者が介在しないことを確認することを特徴とする請求項２、及び６に記載の秘匿通信。
10. クライアントが前記パスワードを保持することの確認を、サーバが行う場合において、前記暗号通信を用いて、クライアントが、自らの通信先情報をサーバに対して知らせ、サーバは自らが通信しているサーバの通信先情報と、受け取った通信先情報とから、クライアント、サーバ間に中間者が介在しないことを確認することを特徴とする請求項４、及び６に記載の秘匿通信。

Images