(57)【要約】  ＳＳＬ暗号通信では、中間者攻撃の脅威を防ぐために、サーバ証明書を用いているものの、その運用は簡単ではなく、中間者攻撃を十分に防げるものではない。クライアント、サーバ間でパスワードを共有しているＳＳＬ暗号通信において、クライアントは、乱数データとパスワード、それぞれを公開鍵で暗号化し、暗号データに対してパスワードの暗号データを加工した値を求めてサーバに渡す。サーバは、この値からパスワードの暗号データを除去し、次に逆算した乱数データを復号化してクライアントが生成した乱数データを取得し、この乱数データのハッシュ値をクライアントに提示する。
2011040023.tif 000002
【特許請求の範囲】
【請求項１】
第１の公開鍵を復号化装置から受信する受信部と、
パスワードの少なくとも一部を含む被除数データを被除数とし、前記第１の公開鍵を除数とし、剰余を算出する暗号化部と、
前記剰余を暗号データとして前記復号化装置に送信する送信部とを備え、
前記暗号化部は、前記被除数データとして、所定値に前記パスワードの少なくとも一部を加算または減算することを特徴とする暗号化装置。
【請求項２】
前記受信部は、第２の公開鍵を受信し、
前記暗号化部は、前記第２の公開鍵を所定データの指数として所定値を算出することを特徴とする請求項１記載の暗号化装置。
【請求項３】
前記第１の公開鍵および前記第２の公開鍵は、ＲＳＡ暗号を用いた公開鍵であることを特徴とする請求項２記載の暗号化装置。
【請求項４】
前記受信部は、第２の公開鍵を受信し、
前記暗号化部は、乱数を前記第２の公開鍵の指数として前記所定値を算出することを特徴とする請求項１記載の暗号化装置。
【請求項５】
前記第１の公開鍵および前記第２の公開鍵は、ＥｌＧａｍａｌ暗号を用いた公開鍵であることを特徴とする請求項４記載の暗号化装置。
【請求項６】
更に、前記パスワードを受け付けるパスワード入力部を備えることを特徴とする請求項１記載の暗号化装置。
【請求項７】
前記公開鍵は一方向性関数の性質を有することを特徴とする請求項１記載の暗号化装置。
【請求項８】
暗号データを暗号化装置から受信する受信部と、
前記暗号データにパスワードの少なくとも一部を加算または減算し、算出結果を秘密鍵で復号する復号化部とを備えることを特徴とする復号化装置。
【請求項９】
第１の公開鍵を暗号化装置から受信するステップと、
パスワードの少なくとも一部を含む被除数データを被除数とし、前記第１の公開鍵を除数とし、剰余を算出するステップと、
前記剰余を暗号データとして復号化装置に送信するステップとを備え、
前記暗号化部は、前記被除数データとして、所定値に前記パスワードを加算または減算することを特徴とする暗号化方法。
【請求項１０】
暗号データを暗号化装置から受信するステップと、
前記暗号データにパスワードの少なくとも一部を加算または減算し、算出結果を秘密鍵で復号するステップとを備えることを特徴とする復号化方法。
【請求項１１】
暗号化処理を実行する暗号化装置と、
復号化処理を実行する復号化装置とを備え、
前記暗号化装置は、
公開鍵を前記復号化装置から受信する受信部と、
パスワードの少なくとも一部を含む被除数データを被除数とし、前記公開鍵を除数とし、剰余を算出する暗号化部と、
前記剰余を暗号データとして前記復号化装置に送信する送信部とを有し、
前記暗号化部は、前記被除数データとして、所定値に前記パスワードの少なくとも一部を加算または減算し、
前記復号化装置は、
前記暗号データを前記暗号化装置から受信する受信部と、
前記暗号データに前記パスワードの少なくとも一部を加算または減算し、算出結果を秘密鍵で復号する復号化部とを有することを特徴とする暗号化復号化システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２点間で通信を安全に行う暗号化装置、復号化装置、暗号化方法、復号化方法、および暗号化復号化システムに関するものである。
【背景技術】
【０００２】
近年、インターネットを介する通信では、フィッシングなどのように、中間者攻撃の脅威が増加しており、暗号通信だけでは、通信を安全に行えなくなっており、この中間者攻撃対策が望まれている。【０００３】
従来、通信を安全に行う方法の１つとして、ＳＳＬ暗号通信がある。ＳＳＬ暗号通信では、すでに中間者攻撃を軽減するしくみが備えられている。ＳＳＬ暗号通信では、サーバ証明書を確認することで、正しい相手との通信であるか否かを判別する方法が取られている。【０００４】
しかし、サーバ証明書の確認は基本が目視のため、手間を要する。また、攻撃者が本物のサーバ証明書に似せたサーバ証明書を用意すると判断が難しい。この課題を解決するため、通常のＨＴＴＰブラウザは、サーバ証明書に問題がある場合に、自動で警告表示する。しかし、これはあらかじめ登録されている認証機関によって、サーバ証明書が認証されているか、又は有効期限やデジタル署名などサーバ証明書の形式に問題がないかなどをチェックしているだけである。そのため、攻撃者が正式なサーバ証明書を保持している場合や、攻撃者がウィルスソフト等を利用して、攻撃者のサーバ証明書を信頼するようにＨＴＴＰブラウザに登録した場合には要をなさない。【０００５】
最近はこの自動チェックを強化するため、ＥＶ証明書という更に強化されたサーバ証明書も登場している。しかし、攻撃が多少困難になるだけで、本質的な課題は変わらない。【０００６】
またサーバ証明書を強化すればするほど費用を要し、一般での利用が困難となる。【０００７】
このように、互いに知らない２点間での暗号通信では、中間者攻撃を防ぐ、真に有効で、かつ安価な手段が実現されていない。【０００８】
そこで、２点間でパスワードのような秘密の情報を共有している場合だけでも、中間者攻撃を防御できないかというのが、テーマとなる。このような制限を設けたとしても、その意義は大きい。【０００９】
例えば、オンラインバンキングやネットワークカメラの視聴のような、パスワードによってユーザが特定されるインターネット通信では、ユーザに一定の権利行使権があるので、攻撃者にとって、攻撃を行う魅力がある。逆にいえば、通信者が不特定の場合は、情報価値が低いので、攻撃者にとっては、攻撃を行う魅力に欠ける。従って、２点間でパスワードを共有している場合だけでも、中間者攻撃を防御できれば、被害の大きさからいって、意義は非常に大きい。【００１０】
もし２点間で、暗号学的に安全と判断される程度にビット長が長いパスワードを、秘密裏に保持していれば、これを共通鍵として利用することで、暗号通信は安全に行える。しかし、これを一般の人が記憶することは困難である。【００１１】
そこで、人が記憶可能なパスワード、つまり暗号学的に安全と判断される程度のビット長がない秘密の情報によっても、中間者攻撃を防御できることが望まれる。【００１２】
このような方法として、ＥＫＥ（Ｅｎｃｒｙｐｔｅｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）が知られている（非特許文献１参照）。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】Ｓ．Ｂｅｌｌｏｖｉｎ  ａｎｄ  Ｍ．Ｍｅｒｒｉｔｔ．  Ｅｎｃｒｙｐｔｅｄ  ｋｅｙ  ｅｘｃｈａｎｇｅ：  Ｐａｓｓｗｏｒｄ−ｂａｓｅｄ  ｐｒｏｔｏｃｏｌｓ  ｓｅｃｕｒｅ  ａｇａｉｎｓｔ  ｄｉｃｔｉｏｎａｒｙ  ａｔｔａｃｋｓ．  Ｉｎ  Ｐｒｏｃ．  ＩＥＥＥ  Ｃｏｍｐｕｔｅｒ  Ｓｏｃｉｅｔｙ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｒｅｓｅａｒｃｈｉｎ  Ｓｅｃｕｒｉｔｙ  ａｎｄ  Ｐｒｉｖａｃｙ，  ｐｐ．７２−８４．  （１９９２）
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかしながら、前記従来の技術では、何がしかの攻撃方法が存在して、安全とはいえなかった。【００１５】
一般のユーザが利用する暗号通信としては、公開鍵暗号方式としてＲＳＡ暗号（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ  Ｓｃｈｅｍｅ）を用いたＳＳＬ(Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ)暗号通信が最もポピュラーであり、普及している。【００１６】
従って、このＲＳＡ暗号型のＳＳＬ暗号通信に適した、パスワードを用いた、安全な中間者攻撃に対する防御が望まれる。【００１７】
本発明は、このような従来技術の問題点を解消するべく案出されたものであり、その主な目的は、ＳＳＬ暗号通信、公開鍵暗号等を利用している場合に、パスワードを用いて、中間者攻撃の被害を低減させる、暗号化装置、復号化装置、暗号化方法、復号化方法、および暗号化復号化システムを提供することを目的としている。
【課題を解決するための手段】
【００１８】
このような課題を解決するために、本願の第１の発明では、第１の公開鍵を復号化装置から受信する受信部と、パスワードの少なくとも一部を含む被除数データを被除数とし、前記第１の公開鍵を除数とし、剰余を算出する暗号化部と、前記剰余を暗号データとして前記復号化装置に送信する送信部とを備え、前記暗号化部は、前記被除数データとして、所定値に前記パスワードの少なくとも一部を加算または減算することを特徴とする暗号化装置である。
【発明の効果】
【００１９】
このように本発明によれば、所定値から、パスワードの少なくとも一部をずらして被除数データを生成するので、たとえ攻撃者が総当り的にパスワードを調べたとしても、パスワードの候補を容易に絞り込むことができない。これにより、第三者からの攻撃を気にすることなく、安全に情報を伝達することができる。
【図面の簡単な説明】
【００２０】
【図１】本発明に係る実施例１のデータ交換手順を示す図
【図２】本発明に係る実施例１のブロック図
【図３】本発明に係る実施例２のデータ交換手順を示す図
【図４】本発明に係る実施例２のブロック図
【図５】本発明に係る実施例３のデータ交換手順を示す図
【図６】本発明に係る実施例３のブロック図
【図７】本発明に係る実施例４のデータ交換手順を示す図
【図８】本発明に係る実施例４のブロック図
【図９】本発明を用いたネットワークＰＢＸ（Ｎｅｔｗｏｒｋ  Ｐｒｉｖａｔｅ  Ｂｒａｎｃｈ  ｅＸｃｈａｎｇｅ）を示す構成図
【図１０】本発明を用いたネットワークＰＢＸのブロック図
【図１１】暗号化復号化システムに係る実施例５のハードウェア構成図
【発明を実施するための形態】
【００２１】
以下、本発明の実施の形態を、図面を参照しながら説明する。
【実施例１】
【００２２】
図１は、本発明に係る実施例１のデータ交換手順を示す図である。この実施例１では、クライアントが、サーバに送信したい秘密のデータＲを公開鍵で暗号化し、この暗号データをパスワードでずらしたデータを生成し、このデータを送信することによって、中間者攻撃を受けない、安全な秘匿通信を行う。クライアントは、暗号化装置の一例であり、サーバは復号化装置の一例である。クライアントおよびサーバにより、暗号化復号化システムが構成される。【００２３】
なお、図１以降、公開鍵暗号方式としては、ＲＳＡ暗号方式を利用した場合の例で説明を行う。【００２４】
クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバの公開鍵Ｅ（指数）と公開鍵Ｎ（モジュラス）が渡る。なお、説明を簡略化するために、ここではＳＳＬネゴシエーションを行うとしているが、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しでも送ることもできる。この公開鍵の受け渡しに関しては、どのような手段を用いても良い。この事は、他の図でも同様であり、他の図ではこの説明は割愛する。【００２５】
また、ＳＳＬサーバ側が本発明でいうところのサーバと勘違いしてはならない。ＳＳＬクライアントが公開鍵・秘密鍵のペアを自ら所有していれば、これを用いて、ＳＳＬサーバがＳＳＬクライアントに対して、実施例１の手順に従ってデータＲを送信することができる。この場合には、ＳＳＬネゴシエーションにおけるＳＳＬクライアント及びＳＳＬサーバの関係が、図１に示すクライアント及びサーバの関係と反対になる。例えば、ＳＳＬネゴシエーションのクライアント認証でサーバに渡った公開鍵・秘密鍵を利用することもでき、この場合、ＳＳＬサーバはこの図１でのクライアント、ＳＳＬクライアントがこの図１でのサーバということになる。この事は、他の実施例における手順でも同様であり、他の図ではこの説明は割愛する。【００２６】
図１において、クライアントにおいては、１．サーバに送信したい秘密のデータＲを生成する。但しデータＲのビット長は、オフライン攻撃を受けないために、暗号学的に安全な程度に長いものが望ましい。２．データＲを公開鍵で暗号化して、［ＲE  ｍｏｄ  Ｎ］を求め、３．［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余である、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を求める。ここではパスワードＭを加算しているが、減算するとしても良い。すなわち、パスワードＭを含む被除数データ（ＲE＋Ｍ）を被除数とし、公開鍵Ｅ及びＮのうち公開鍵Ｎを除数とし、剰余（（ＲE＋Ｍ）ｍｏｄ  Ｎ）を算出する。この場合、被除数データ（ＲＥ＋Ｍ）として、ＲＥにパスワードＭを加算する。なお、被除数データは、必ずしも全てのパスワードＭを含む必要はなく、パスワードＭの一部が含めてもよい。【００２７】
このようにパスワードＭを加算、若しくは減算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なおパスワードＭは、オンライン攻撃を受けないように、極端に短いビット長は避けた方が良い。４．そして［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をサーバに送信する。【００２８】
なお、図１を含めて、すべての図において同じであるが、すべての式は、モジュラスＮの倍数を加算した値であっても良い。例えば、［ＲE  ｍｏｄ  Ｎ］であれば、［（ＲE＋ＸＮ）ｍｏｄ  Ｎ］（Ｘ＝１，２，・・・）でも構わない。【００２９】
一方、図１において、サーバにおいては、５．この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をクライアントから受信する。６．そして、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］から、パスワードＭを減算し（クライアントで減算した場合、ここでは加算する）、モジュラスＮの剰余である、［ＲE  ｍｏｄ  Ｎ］を求め、７．［ＲE  ｍｏｄ  Ｎ］をサーバ自らが所有する秘密鍵Ｄと公開鍵Ｎで復号化して、データＲを求める。【００３０】
もし、ここで攻撃者がサーバのふりをできたとしても、パスワードＭを知らないので、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］から［ＲE  ｍｏｄ  Ｎ］を計算できない。【００３１】
なおクライアントがサーバに送信するデータＲが、コマンドなど意味あるデータである場合、攻撃者はサーバのふりをしてクライアントからの送信データを受信し、パスワードＭに対して総当たり攻撃（オフライン攻撃）をかけて、意味あるデータが出現するか否かをチェックするかもしれない。これを避けるには、クライアントは正規のパスワードでない値Ｍ’を設定して［（ＲE＋Ｍ’）ｍｏｄ  Ｎ］を計算し、これをサーバに送信すると良い。サーバはこれを同じ手順で処理していくと、意味のないデータＲ’を得るが、サーバは意味のないデータを無視すれば良い。【００３２】
このようなダミー通信を多く行い、その中に正規の通信を紛れ込ませれば、攻撃者がオフライン攻撃を行うことが困難となる。本発明は、剰余算をモジュラスＮ周期の波と捉えた時、波をパスワードＭで位相変調しているようなものであるが、これは各位相に意味あるデータを乗せて通信するようなものである。こうすると、盗聴者はどの位相で正規クライアントと正規サーバとが通信しているか分からなくなる。この事は次の図２でも同様である。【００３３】
なおここで、サーバがどのようにしてクライアントのパスワードＭを特定したかを記述していないが、例えば、通常のパスワード認証のように、パスワードＭを指定するＩＤを、クライアントが送信することによって、特定したものとすることができる。他にも、パスワードＭをクライアントの通信先情報に関連づけて記憶しているとすることも可能である。この事は、他の図でも同様であり、他の図ではこの説明は割愛する。【００３４】
ここで、「一方が公開鍵だけで暗号化したものを、他方がこの公開鍵と、この公開鍵とペアとなる秘密鍵とを用いて復号可能な公開鍵暗号化方式」というのは、例えば、ＲＳＡ暗号やＥｌＧａｍａｌ暗号などである。【００３５】
但し、ＲＳＡ暗号やＥｌＧａｍａｌ暗号などでも、片方のみが秘密鍵を保持する場合と、異なる公開鍵・秘密鍵のペアがあり、両者がそれぞれ異なる秘密鍵（それぞれ相手には、その秘密鍵とペアとなる公開鍵が渡る）を保持する場合とがあるので、「片方のみが秘密鍵を保持する」という限定をしているわけではないことに注意しなくてはならない。【００３６】
なお、ここで公開鍵と称しているものは、公開情報を含む。例えば、ＲＳＡ暗号ではモジュラス（Ｎ）は、サーバによって異なる値を保持するので、公開鍵と呼ばれるが、ＥｌＧａｍａｌ暗号のモジュラスは、全てのサーバで共通の値を利用できるので、公開情報と呼ばれる。本出願においては、どちらも公開鍵という呼称に統一している。【００３７】
またここで、クライアント、サーバとしているものは、単に、公開鍵暗号化方式における公開鍵だけを用いる方をクライアント、公開鍵・秘密鍵を用いる方をサーバと便宜上、呼んでいるものである。暗号学で良く用いられているボブやアリスといった呼び方に代えても良い。【００３８】
本願に係るすべての発明において、この事は注意を要する。ＳＳＬ暗号通信を行っている場合、ＳＳＬサーバが、本発明でいうところのサーバと勘違いしてはならない。例えば、ＳＳＬクライアントがＳＳＬサーバとは異なる公開鍵・秘密鍵のペアを保持している場合に、ＳＳＬサーバが、このＳＳＬクライアントの公開鍵を用いて、本発明の手順でデータＲをＳＳＬクライアントに対して送信するのであれば、この場合、ＳＳＬクライアントが本発明でいうこところのサーバに該当する。従って、互いに相手先の公開鍵を利用してデータＲの暗号化を行う場合は、両者がサーバ・クライアントということになる。【００３９】
なお、サーバは公開鍵・秘密鍵を内部に保持しているとは限らず、サーバに接続されたＩＣカードのような外部機器にあるとする構成も可能である。また、秘密鍵を用いた演算処理自体も外部機器で行うとすることが可能である。同様に、クライアントにおける公開鍵もクライアントに接続された外部機器にあるとできるし、公開鍵を用いた演算処理も、外部機器で行うとしても構わない。この場合、外部機器を含めて、クライアント・サーバという構成になる。これも全請求項において同じである。【００４０】
従って、一人の人間が、クライアントに、自らが所持する公開鍵・秘密鍵を保持するＩＣカードを接続して、クライアントに、本発明の手順に従ってデータＲをサーバに対して送信させ、そして同じ人間がサーバの所まで行き、今度は同じＩＣカードをサーバに接続して、サーバに、本発明の手順に従ってデータＲを取得させることも可能である。サーバがプリンタの場合などにこのような利用方法がある。公開鍵・秘密鍵を保持する同じＩＣカードをクライアント・サーバ両方に接続するのであれば、パスワードは必要ないように思われるかもしれないが、ＩＣカードを接続しても、ウィルスソフトなどによる、不正な鍵の差し替えは起こりうるので、それなりに効果がある。【００４１】
また、ＳＳＬ暗号通信など公開鍵暗号を利用している場合に、このしくみをそのまま利用して、パフォーマンスを落とすことなく、しかも中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に情報を伝達することが可能となる。【００４２】
これはメール通信においても非常に有益である。Ｓ／ＭＩＭＥのようにデジタル証明書を用いずとも、この方式であれば、パスワード交換しておくことで、中間者攻撃を簡単に防御できる。【００４３】
ここで、攻撃者が単純にサーバのふりをして、正規クライアントとの通信を行い、自らの公開鍵を正規クライアントに渡せたとしても、データＲを公開鍵暗号方式で暗号化したデータは、パスワードＭで加算、若しくは減算されているので、パスワードＭを知らない限り、攻撃者は暗号化されたデータＲを正しく復号化することはできない。【００４４】
このようにサーバのふりをできないので、攻撃者は、正規クライアントと正規サーバとの間に介在し、正規クライアントに対しては、サーバのふりをして、自らの公開鍵を渡し、正規サーバに対しては、クライアントのふりをして、バケツリレー攻撃（ｂｕｃｋｅｔ  ｂｒｉｇａｄｅ  ａｔｔａｃｋ）をオンライン（オンライン攻撃）で行うこともできない。【００４５】
また攻撃者が、正規クライアント、正規サーバ間に入り込んで、単純にやりとりされるデータをスルーさせたとしても、中間者攻撃は成立しない。これでは正規クライアントに正規サーバの公開鍵が渡ってしまう。データＲをこの公開鍵で暗号化されてしまうと、公開鍵暗号方式の安全性から、あらゆる攻撃が困難となる。【００４６】
しかも、ＥＫＥとは異なり、次のようなパスワードを攻撃者が想定するオフライン攻撃（以降、パスワード想定攻撃と呼ぶ）にも強い。【００４７】
［ＭＲE  ｍｏｄ  Ｎ］の場合、攻撃者は、クライアント・サーバ間でやりとりされるこの［ＭＲE  ｍｏｄ  Ｎ］をオンラインで盗聴し、そして、次のようなオフライン攻撃を行える。【００４８】
パスワード情報を含むデータＭを、Ｍ1，Ｍ2，・・・と仮に想定し、盗聴した［ＭＲE  ｍｏｄ  Ｎ］に対して、［Ｍ1-1ＭＲE  ｍｏｄ  Ｎ］，［Ｍ2-1ＭＲE  ｍｏｄ  Ｎ］，・・・を計算する。そして、［ＲE  ｍｏｄ  Ｎ］が値を持つか否かを調べる。［ＲE  ｍｏｄ  Ｎ］が値を持たなければ、想定した仮のパスワードは正しくないので、パスワード候補から除外する。［ＭＲE  ｍｏｄ  Ｎ］をたくさん収集し、総当たりでＭを調べれば、正しいパスワード候補をかなり絞り込む事ができる。【００４９】
具体例で説明する。例えば、Ｎ＝１５で、クライアントが、［ＭＲE  ｍｏｄ  Ｎ］＝１を生成したとする。ここで攻撃者がＭ＝３とした場合を想定したとしよう。［３×ＲE  ｍｏｄ  １５］＝１の等式を成立させる［ＲE  ｍｏｄ  Ｎ］は存在しない（［ＲE  ｍｏｄ  Ｎ］＝１，２，・・・，１４と順に代入して計算してみても、等式は成立しない）ので、このＭ＝３は、真のパスワードでない事が分かる。これをＭ＝１，２，・・・と順に計算して行けば、パスワード候補を絞り込める。【００５０】
通常、パスワードのビット長は、オンライン攻撃に耐性を持つ程度の長さを十分保持しているが、攻撃者が、このオフライン攻撃によって、パスワード候補を事前に十分絞り込めば、最終はオンライン攻撃でどのパスワードが正しいかを確かめることが容易となる。【００５１】
この攻撃は、［ＭＲE  ｍｏｄ  Ｎ］だけでなく、データＲを共通鍵として［ＲE  ｍｏｄ  Ｎ］を暗号化した方式にも有効である。【００５２】
しかし、本発明の場合、攻撃者が同様のオフライン攻撃を用いて、パスワード情報を含むデータＭを、Ｍ1，Ｍ2，・・・と仮に想定し、［（（ＲE＋Ｍ）−Ｍ1）ｍｏｄ  Ｎ］，［（（ＲE＋Ｍ）−Ｍ2）ｍｏｄ  Ｎ］，・・・と計算したとしても、［ＲE  ｍｏｄ  Ｎ］は必ず何らかの値を持つので、手がかりを得られない。この攻撃は、ＥＫＥのような従来の方法では防ぐことが非常に困難であるため、効果が高い。【００５３】
剰余算をモジュラスＮ周期の波と捉えた時、ＥＫＥは波をデータＭで振幅変調しているようなものであるのに対して、本発明は波をデータＭで位相変調しているような違いがあり、その方式の違いがこのような効果を生み出している。【００５４】
なお、パスワードそのものをデータＭとして利用しても構わないが、クライアント・サーバで交換した乱数データや、アドレス情報などクライアント・サーバの固有情報をパスワードに混ぜ合せる工夫を行うと、リトライ攻撃等の防御にもなり、セキュリティ上望ましい。また、攻撃者がサーバから直接パスワードを盗み見するかもしれないので、パスワードを一方向性関数など複雑な関数で処理したデータをＭとして利用し、サーバにはこのＭを記憶すると良い。【００５５】
但し、パスワードに対してデータ加工を行う場合は、クライアント・サーバ両者で、データＭに対して、たとえ計算順序は違ったとしても、最終は同じ計算処理を施した値を取得するものとする。これは本願のすべての発明において同じである。【００５６】
なおここでは、サーバが多人数のユーザの中から、どうやって該当のパスワードを選択するかを明示していないが、普通のパスワード認証で用いられるように、ＩＤを利用するとするのが最も簡単な方法である。【００５７】
また、本願のすべての発明において、クライアント・サーバで受け渡されるデータは、ＳＳＬ暗号通信における共通鍵暗号など、様々なデータ加工を施して受け渡すことが可能である。【００５８】
なお、本願のすべての発明で同じであるが、データＲのビット長は、パスワードのビット長よりも非常に長く、オフラインでの総当たり攻撃に対して安全であるものを利用するのが望ましい。【００５９】
なお、公開鍵暗号・復号化手段１と公開鍵暗号・復号化手段２は、計算手段（計算式）としては等価である場合がある。例えば公開鍵暗号方式がＲＳＡ暗号であれば、公開鍵暗号・復号化手段１は、例えば、任意のデータＸに対して［ＸE  ｍｏｄ  Ｎ］を計算する手段で、公開鍵暗号・復号化手段２は、任意のデータＸに対して［ＸD  ｍｏｄ  Ｎ］を計算する手段であるが、どちらも「べき乗の剰余計算」で、利用する「指数の値」は異なるものの、計算手段（計算式）は同じである。これは本願のすべての発明で同じである。【００６０】
なお、「この暗号データと、パスワード（パスワードの一部、または全てを加工したデータを含む）の少なくとも一部の情報を含むデータＭとの和の公開鍵（ＲＳＡ暗号なら先のＮ）の剰余、若しくは差の公開鍵（ＲＳＡ暗号なら先のＮ）の剰余を計算し（ＲＳＡ暗号なら、例えば［（ＲE＋Ｍ）ｍｏｄ  Ｎ］や［（ＲE−Ｍ）ｍｏｄ  Ｎ］）」と記述しているように、この計算は、例えば［（Ｍ−ＲE）ｍｏｄ  Ｎ］）という方法でも構わない。逆算する場合は、Ｍを減算してＲEを正の値に戻すようにデータ加工すれば良い。【００６１】
また、「公開鍵（ＲＳＡ暗号なら先のＮ）の剰余を計算」するのは、公開鍵未満の値にすると限定しているものではない。一定のビット長（公開鍵より大きな値）以下になったところで剰余計算を中断しても良い。これはデータＲを暗号化する場合も同様である。すべての請求項において、これは同様である。なお、ここで公開鍵とは、ＲＳＡ暗号なら先のモジュラスＮであるが、ＥｌＧａｍａｌ暗号なら次に示すＰである。【００６２】
なお、参考のため、ＥｌＧａｍａｌ暗号での利用方法も示す。【００６３】
（１）通常のＥｌＧａｍａｌ暗号公開鍵（厳密には公開情報）を、Ｐ（素数）、Ｇ（原始元）とする。【００６４】
秘密鍵をＸとした場合、サーバはＡ＝［ＧX  ｍｏｄ  Ｐ］を公開鍵とする。【００６５】
クライアントが用意する乱数をＶとする。
クライアントはサーバに対して以下のデータを送信する。【００６６】
Ｂ＝［ＧV  ｍｏｄ  Ｐ］
Ｃ＝［ＡVＲ  ｍｏｄ  Ｐ］（Ｒは平文のデータ）
サーバは以下の計算を行い、平文を取得する。【００６７】
Ｒ＝［Ｃ／ＢX ｍｏｄ  Ｐ］
（２）本方式のＥｌＧａｍａｌ暗号
公開鍵（厳密には公開情報）を、Ｐ（素数）、Ｇ（原始元）とする。【００６８】
クライアントはサーバに対して以下のデータを送信する。【００６９】
Ｂ’＝［（ＧV＋Ｍ）ｍｏｄ  Ｐ］
Ｃ’＝［（ＡVＲ＋Ｍ）ｍｏｄ  Ｐ］
サーバは以下の計算を行い、平文を取得する。【００７０】
Ｒ＝［（Ｃ’−Ｍ）／（Ｂ’−Ｍ）X ｍｏｄ  Ｐ］
なお、Ｂ’，Ｃ’の一方はＢ，Ｃでも構わない。【００７１】
図２は、本発明の実施例１のブロック図である。クライアント１は、パスワード入力部５２０を用いて、パスワードＭをユーザから取得し、あらかじめパスワードＭを記憶保持しているサーバ２と秘匿通信を行うようになっている。【００７２】
なお、クライアント１もサーバ２と同様に、パスワードＭをあらかじめ記憶保持しているとすることも可能である。またサーバ２がプリンタであるケースなど、ユーザが使用時にサーバ２に出向いて利用するものや、クライアント・サーバ型の会議システムなど、サーバ側の端末もユーザが利用する場合（サーバ側ユーザは、クライアント側ユーザとは別人）には、サーバ２のパスワードＭもユーザが入力するとして良い。【００７３】
はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２の公開鍵Ｅと公開鍵Ｎが渡る。図１でも説明したようにクライアント１がＳＳＬクライアントで、サーバ２がＳＳＬサーバとは限らない。ＳＳＬネゴシエーションのクライアント認証で、ＳＳＬクライアントがＳＳＬサーバに公開鍵Ｅと公開鍵Ｎを送り、これを用いる場合、クライアント１はＳＳＬサーバで、サーバ２はＳＳＬクライアントということになる。このことは、他のブロック図でも同様であり、他のブロック図の説明ではこの説明は割愛する。【００７４】
公開鍵の受け渡し方法は本発明には関係ないので、実際の公開鍵の受け渡しはＳＳＬネゴシエーションでなくても良い。手作業で受け渡しても良い。しかし説明を簡略化するために、ここではＳＳＬネゴシエーションを行うものとする。また、ＳＳＬネゴシエーションは既知の技術なので、その手順を改めて示すことはしない。ここでは、発明に関係する部分から説明を行う。つまり、ＳＳＬネゴシエーションの結果、クライアント２に公開鍵が渡るが、これを前提に話を進める。この事は、他の図でも同様であり、他の図ではこの説明は割愛する。【００７５】
ＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部５２０を用いて求める。【００７６】
ユーザが、パスワード入力部５２０を用いてパスワードＭを入力する。【００７７】
また、ＳＳＬネゴシエーション、パスワード入力とは非同期に、データ生成部３００は、サーバ２に送信したい秘密のデータＲを用意する。【００７８】
公開鍵暗号・復号部Ａ４００は、公開鍵Ｅ，Ｎを用いて、データＲの暗号化を行い、［ＲE  ｍｏｄ  Ｎ］を計算する。【００７９】
次に、パスワード加算部５００は、［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余、即ち［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を得る。このようにパスワードＭを加算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃に対しても防御が可能となる。【００８０】
なお図１でも同様であるが、Ｍはパスワードそのものとは限らない。Ｍはパスワードをデータ加工した値であっても良い。実際は、クライアント・サーバ間で取り交わした乱数データやアドレス情報等の固有値情報を用いてデータ加工するのが、セキュリティ強度が向上し望ましい。このことは、他の図でも同様であり、他の図ではこの説明は割愛する。【００８１】
クライアント１側のデータ送信部１１０は、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を、ネットワーク制御部１００を通してサーバ２に送信する。【００８２】
サーバ２側のデータ受信部２１１は、ネットワーク制御部２００を通して、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を受信する。【００８３】
パスワード減算部５１０は、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算し、モジュラスＮの剰余、即ち［ＲE  ｍｏｄ  Ｎ］を求める。【００８４】
なお、（［（ＲE＋Ｍ）ｍｏｄ  Ｎ］＜Ｍ）の場合、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算した結果は「負」になるが、これは剰余算であるので、Ｎ（Ｎの倍数）を加えれば、「正」の値になる。【００８５】
公開鍵暗号・復号部Ｂ４１０は、サーバ２が自ら所有する秘密鍵Ｄと公開鍵Ｎを用いて、［ＲE  ｍｏｄ  Ｎ］を復号化して、データＲを求める。【００８６】
なお、データＲが意味あるデータであれば、サーバ２はクライアント１が送信したデータＲの解釈を行う。しかしこの部分は、本発明の趣旨ではないので、説明を割愛する。
【実施例２】
【００８７】
図３は、本発明の実施例２のデータ交換手順を示す図である。この実施例２では、クライアントが、サーバに秘密のデータＲを送信し、サーバがクライアントにその秘密のデータＲを提示できるか否かで、サーバがパスワードＭを保持する正規サーバである事を確認し、安全な秘匿通信を行うものである。【００８８】
なお本発明は、クライアントが、サーバが正規サーバであるか否かの確認する方法に関するものであるが、図３では、サーバ２も、クライアント１が正規クライアントであるか否かを確認するところまで説明している。それは、双方向の確認によって、真に中間者の介在を排除した安全な秘匿通信を行うことが可能であるからである。【００８９】
しかし、本質は、本発明である正規サーバの確認方法にある。正規サーバを先に確認できれば、それに続く正規クライアントの確認は難しくない。実際、様々な確認方法を用いることが可能である。正規クライアントの確認方法に関しては、図３ではその一例を示す。【００９０】
クライアント１、サーバ２間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２の公開鍵Ｅと公開鍵Ｎが渡る。但し、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しで送ることもできる。この公開鍵の受け渡しに関しては、どのような手段を用いても良い。【００９１】
図３において、クライアントにおいては、１．データＲを生成する。データＲはサーバさえ知らない、第三者には秘密のデータであるが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。【００９２】
また、乱数のビット長は、オフライン攻撃を受けないために、暗号学的に安全な程度に長いものが望ましい。２．データＲを公開鍵で暗号化して、［ＲE  ｍｏｄ  Ｎ］を求め、３．［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余である、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を求める。ここではパスワードＭを加算しているが、減算するとしても良い。【００９３】
このようにパスワードＭを加算、若しくは減算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なおパスワードＭは、オンライン攻撃を受けないように、極端に短いビット長は避けた方が良い。４．そして［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をサーバに送信する。【００９４】
一方、サーバにおいては、５．この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をクライアントから受信する。６．そして、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］から、パスワードＭを減算し（クライアントで減算した場合、ここでは加算する）、モジュラスＮの剰余である、［ＲE  ｍｏｄ  Ｎ］  を求め、７．［ＲE  ｍｏｄ  Ｎ］をサーバ自らが所有する秘密鍵Ｄと公開鍵Ｎで復号化して、データＲを求める。【００９５】
そして、８．データＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、９．更に、［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算し、１０．この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］をクライアントに送信する。【００９６】
サーバがクライアントに対して、データＲそのものを提示すると、攻撃者が送受信データを盗聴できた場合に、データＲを用いたオフライン攻撃を行うことが可能となる。そこで、ここではデータＲを一方向性関数で処理し、データＲそのものを逆算できなくしている。【００９７】
また、ハッシュ計算を二回行っている理由は、クライアントがサーバに正規クライアントであることを証明するのに、データＲのハッシュ値を示すようにしているからであって、もしクライアントが正規クライアントである証明を他の方法で行うのであれば、サーバでのハッシュ計算は一回だけでも構わない。ハッシュ計算を何度行うかは本質的な問題ではない。また、ここではデータＲそのものをハッシュ計算しているが、データＲから生成される別のデータをハッシュ計算するようにしても良い。【００９８】
次にクライアントにおいては、１１．［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を受信する。１２．クライアントは自らが用意したデータＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、１３．更に、［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。【００９９】
なお１２、及び１３の計算は、１１．の受信を待たずに、事前に行っても良い。１４．サーバから受け取った［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］と、自らが計算して得た［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］とを比較し、同じと判断されれば、サーバがパスワードＭを保持する正規サーバと判定する。なお正規サーバでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０１００】
そして、１５．自らが計算して得た［Ｈａｓｈ（Ｒ）］をサーバに送信する。なおクライアントはここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。ここでは、クライアントはサーバに対して、正規クライアントであることを［Ｈａｓｈ（Ｒ）］を提示して証明するものとしているが、この提示方法は様々な方法を選択することが可能である。【０１０１】
この時点ではサーバは正規サーバであることが判明しているので、クライアントに渡された公開鍵は信頼できるものである。従って、この公開鍵（ハイブリッド暗号を含む）を利用してデータＲやパスワードＭを暗号化し提示しても良い。例えば、このＳＳＬの共通鍵でデータＲやパスワードＭを暗号化し提示することも可能である。またデータＲを共通鍵としてパスワードＭを暗号化し提示することもできる。【０１０２】
次に、サーバにおいては、１６．［Ｈａｓｈ（Ｒ）］を受信する。１７．クライアントから受け取った［Ｈａｓｈ（Ｒ）］と、自らが計算して得た［Ｈａｓｈ（Ｒ）］とを比較し、同じと判断されれば、クライアントがパスワードＭを保持する正規クライアントと判定する。なおサーバはここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。また正規クライアントでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。クライアント・サーバ共に、互いが正規クライアント・正規サーバであることを確認したことで、中間者が介在しない安全な秘匿通信の環境が構築できたことになる。【０１０３】
次に、１８．クライアント・サーバ共に、ＳＳＬで作成したＫＥＹを用いて共通鍵暗号通信を行う。なお、共通鍵暗号通信を行うとしているのは、パフォーマンス向上のためであり、暗号通信を引き続き、公開鍵暗号で行っても構わない。また、ここでは鍵の一例としてＳＳＬで作成したＫＥＹを用いると説明しているが、データＲ、若しくはデータＲから生成される別のデータをＫＥＹとして共通鍵暗号を行うことも可能であり、共通鍵はＳＳＬのＫＥＹに限定されるものではない。また図３では共通鍵暗号方式の一例としてＡＥＳ暗号方式を図示しているが、ＤＥＳや他の暗号方式を用いても構わない。【０１０４】
ここで、以下の説明において、「逆算が非常に困難な逆計算困難型計算処理」とは、ハッシュや２乗など、一方向性関数を含むが、それだけに限られるものではない。攻撃者が逆算できないものであれば、その手法は限定されない。【０１０５】
例えば、通信する両者で、本願第１の発明に係る方法を用いて、データＲ１を、クライアントからサーバに渡し、次に、データＲ１を受信した方がクライアント、データＲ１を送信した方がサーバというように、クライアントとサーバを入れ替え、今度は請求項１の方法を用いてデータＲ２をクライアントからサーバに渡せば、［Ｒ１×Ｒ２  ｍｏｄ  Ｎ］なども「逆算が非常に困難な逆計算困難型計算処理」といえる。【０１０６】
但し、暗号学的に安全強度の強い逆計算困難型計算処理手段を用いれば、攻撃者から、逆計算困難型計算処理手段を用いてデータ加工されたデータＲから、データＲを逆算するような攻撃は一切受けなくなるので、安全強度の強い手段を選択すべきである。【０１０７】
なお、逆計算困難型計算処理は１回の計算に限られるものではない。逆算が非常に困難な逆計算困難型計算処理を二度、三度といったように、複数回行っても良い。また、逆計算困難型計算処理とは、１種類の計算処理という限定をしているものではない。異なる逆計算困難型計算処理を複数回行う場合を含む。あるハッシュ計算が将来破られた場合のリスクを勘案して、データに対して異なる種類のハッシュ計算処理を行うことは、暗号の世界では普通の事であり、このようにすることは望ましい。但し、クライアント・サーバ両者で、データＲに対して、たとえ計算順序は違ったとしても、最終は同じ計算処理を施した結果を取得するものとする。【０１０８】
なお、「データＲ（データＲの一部、または全てを加工したデータを含む）の少なくとも一部の情報を含むデータを逆計算困難型計算処理する」としているものは、この記述の通り、データＲそのものを逆計算困難型計算処理すると限定しているものではない。データＲを共通鍵としてある値Ｋを暗号化し、この暗号データを、サーバからクライアントに渡すのであれば、サーバは、データＫ（その一部を含む）に対して逆計算困難型計算処理を行い、データＫの少なくとも一部をクライアントに提示するとしても良い。これはデータＲをデータ加工して、データＫを生成したものといえる。【０１０９】
またデータＲをデータ加工する場合、このデータ加工はサーバのみで閉じて行われるとは限らない。クライアントがサーバに対して、データＲを共通鍵としてある値Ｋを暗号化したデータを送信するのであれば、サーバは、データＲを用いてその暗号データを復号化して、データＫを取得し、そしてデータＫ（その一部を含む）に対して逆計算困難型計算処理を行い、データＫの少なくとも一部をクライアントに提示するとしても良い。これもデータＲをデータ加工して、データＫを生成したものといえる。【０１１０】
本発明に係る方法によると、正規クライアントは、サーバがパスワードを保持しているかを確かめることで、正規サーバなのか不正なサーバなのかを明確に見分けることが可能となる。従って、以降の通信を止めるか否かの判断を行うことができる。つまり、中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に秘匿通信を行える基盤を構築できる。【０１１１】
但し、中間者を完全に排除するためには、攻撃者が正規サーバのふりだけでなく、正規クライアントのふりもできなくすることが重要である。そのためには、サーバが、クライアントが正規クライアントであるか否かを確かめることが望ましい。【０１１２】
本発明による方法で、サーバが正規サーバと確認できた後は、クライアントに渡された公開鍵は正規サーバの所有物であることが分かるので、クライアントは、この公開鍵を用いて（ハイブリッド暗号を含む）、パスワードを暗号化したデータをサーバに送信することで正規クライアントであることをサーバに対して証明できる。【０１１３】
また、クライアントがサーバとは異なる自らの公開鍵・秘密鍵を所有しているのであれば、同様（本願第２の発明）の手順を逆に行うことで、サーバが、クライアントが正規クライアントであるか否かを確認できる（つまり、サーバといっていたものをクライアントに、クライアントといっていたものをサーバに取り替えて同じ手順を行う）。また、クライアントが、サーバとは別の逆計算困難型計算処理手段を用いてデータＲを加工しサーバに送信することでも、サーバはクライアントが正規クライアントであることを確認可能である。【０１１４】
最も簡単なのは、サーバが、逆計算困難型計算処理手段を用いてデータＲをデータ加工し、更に逆計算困難型計算処理手段を用いてデータ加工し（例えば、データＲのハッシュ値の更にハッシュ値を求める）、この値をクライアントに送信し、クライアントは同じ逆計算困難型計算処理手段を用いてデータＲをデータ加工し（例えば、データＲのハッシュ値を求める）、この値をサーバに送信して、クライアント・サーバそれぞれで、相手の値をチェックする方法である。但し、オフライン攻撃を避けるために、本発明に示したように、サーバ側が先にデータ加工されたデータＲを提示しなければならない。【０１１５】
このように、本発明による方法で、サーバが正規サーバと確認できた後は、クライアントの確認方法は雑多の方法が存在する。このようにクライアントが正規クライアントであるかの確認も行えば、攻撃者は正規クライアントのふりもできなくなる。【０１１６】
そこで、攻撃者は正規クライアントのふりをして、例えばＲＳＡ暗号で、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］の代わりに、自分が知っている数Ａを公開鍵Ｅ、Ｎで暗号化したデータ、即ち、［ＡE  ｍｏｄ  Ｎ］をサーバに送り、サーバから送り返されるデータ、例えば、［Ｈａｓｈ（Ｒ）］を取得して、オフライン攻撃を行うかもしれない。【０１１７】
しかし正規サーバではビット長が非常に長い秘密鍵Ｄを用いて、例えば、［（ＡE−Ｍ）D  ｍｏｄ  Ｎ］のようなＤ乗の二項展開を行うので、攻撃者はデータＲ（＝［（ＡE−Ｍ）D  ｍｏｄ  Ｎ］）を総当たりで調べることは暗号学的に困難である。【０１１８】
なお、サーバ、クライアント共に、相手がパスワードを保持するか否かを確認した結果を通知する必要はない。むしろ攻撃者が、パスワードが当るまでパスワードを変えてチャレンジするような自動プログラムを使用している場合、その結果通知が利用されかねない。また同様の理由で、不正な通信相手と判断しても、直ぐに通信を遮断しない方が良い。一定の間、適当なダミー通信を行うと良い。【０１１９】
なお、「データＲは第三者に知られていない値」としているが、データＲは、正規サーバにさえも予想しえない値とするのが望ましい。但し、これはデータＲが必ずしも乱数であることを意味していない。データＲが正規サーバにとって意味あるデータであったとしても、正規サーバにさえ、そのデータがいつ送信されるのか分からなければ、攻撃者はデータＲを予想することも計算することもできず安全である。しかし、セキュリティ強度向上には、データＲを乱数とするのが望ましい。特に暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）の使用が望ましい。【０１２０】
このような課題を解決するために、本発明では、本願第３の発明の通り、クライアント、サーバ共に、共通鍵暗号・復号を行う共通鍵暗号化手段を有し、前記データＲの少なくとも一部から生成した共通鍵（前記データＲの少なくとも一部を元鍵として生成した共通鍵を含む）を、前記共通鍵暗号化手段に用いることよって、クライアント、サーバ間で暗号通信を行うものとした。【０１２１】
ここで、共通鍵暗号化手段としているものは、公開鍵暗号方式でないという意味であり、用いられる暗号手法は様々である。またデータＲは、共通鍵生成において、何らかの形で関与すれば良く、例えば、ＳＳＬ暗号通信を行っているのであれば、これにより生成した共通鍵と、このデータＲを掛け合わせて、共通鍵を生成することもできる。【０１２２】
図４は、本発明の実施例２のブロック図である。クライアント１は、パスワード入力部５２０を用いて、パスワードＭをユーザから取得し、あらかじめパスワードＭを記憶保持しているサーバ２と秘匿通信を行うようになっている。【０１２３】
なお、クライアント１もサーバ２と同様に、パスワードＭをあらかじめ記憶保持しているとすることも可能である。またサーバ２がプリンタであるケースなど、ユーザが使用時にサーバ２に出向いて利用するものや、クライアント・サーバ型の会議システムなど、サーバ側の端末もユーザが利用する場合（サーバ側ユーザは、クライアント側ユーザとは別人）には、サーバ２のパスワードＭもユーザが入力するとして良い。【０１２４】
はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２の公開鍵Ｅと公開鍵Ｎが渡る。【０１２５】
ＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部５２０を用いて求める。【０１２６】
ユーザが、パスワード入力部５２０を用いてパスワードＭを入力する。【０１２７】
また、ＳＳＬネゴシエーション、パスワード入力とは非同期に、データ生成部３００は、データＲを生成する。データＲはサーバさえ知らない、第三者には秘密のデータであれば良いが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。また、乱数のビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。【０１２８】
公開鍵暗号・復号部Ａ４００は、公開鍵Ｅ，Ｎを用いて、データＲの暗号化を行い、［ＲE  ｍｏｄ  Ｎ］を計算する。【０１２９】
次に、パスワード加算部５００は、［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余、即ち［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を得る。このようにパスワードＭを加算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃に対しても防御が可能となる。【０１３０】
なお図３でも同様であるが、Ｍはパスワードそのものとは限らない。Ｍはパスワードをデータ加工した値であっても良い。実際は、クライアント・サーバ間で取り交わした乱数データやアドレス情報等の固有値情報を用いてデータ加工するのが、セキュリティ強度が向上し望ましい。【０１３１】
データ送信部１１０は、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を、ネットワーク制御部１００を通してサーバ２に送信する。データ受信部２１１は、ネットワーク制御部２００を通して、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を受信する。【０１３２】
パスワード減算部５１０は、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算し、モジュラスＮの剰余、即ち［ＲE  ｍｏｄ  Ｎ］を求める。【０１３３】
なお、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］＜Ｍの場合、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算した結果は「負」になるが、これは剰余算であるので、Ｎ（Ｎの倍数）を加えれば、「正」の値になる。【０１３４】
公開鍵暗号・復号部Ｂ４１０は、サーバ２が自ら所有する秘密鍵Ｄと公開鍵Ｎを用いて、［ＲE  ｍｏｄ  Ｎ］を復号化して、データＲを求める。【０１３５】
ハッシュ計算部７１０は、データＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、ハッシュ計算部７１０は、更に［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。【０１３６】
サーバ２がクライアント１に対して、データＲそのものを提示すると、攻撃者が送受信データを盗聴できた場合に、データＲを用いたオフライン攻撃をかけることが可能である。そこで、ここではデータＲを一方向性関数で処理し、データＲそのものを逆算できなくしている。また、ハッシュ計算を二回行っている理由は、クライアント１がサーバ２に正規クライアントであることを証明するのに、データＲのハッシュ値を示すようにしているからであって、もし他の方法でこれを行うのであれば、サーバ２でのハッシュ計算は一回だけでも構わない。ハッシュ計算を何度行うかは本質的な問題ではない。【０１３７】
データ送信部２１０は、この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を、ネットワーク制御部２００を通してクライアント１に送信する。データ受信部１１１は、ネットワーク制御部１００を通して、この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を受信する。【０１３８】
ハッシュ計算部７００は、データ生成部３００で生成したデータＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、ハッシュ計算部７００は、更に、［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。なおこの計算は、先の［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］の受信を待たずに、事前に行っても良い。【０１３９】
次にデータ比較部６００は、サーバ２から受け取った［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］と、ハッシュ計算部７００で得た［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］とを比較し、同じと判断されれば、サーバ２がパスワードＭを保持する正規サーバと判定する。なお正規サーバでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０１４０】
そして、データ比較部６００は、ハッシュ計算部７００で得た［Ｈａｓｈ（Ｒ）］をデータ送信部１１０に送る。【０１４１】
ここでは、クライアント１はサーバ２に対して、正規クライアントであることを［Ｈａｓｈ（Ｒ）］を提示して証明するものとしているが、この提示方法は様々な方法を選択することが可能である。この時点ではサーバ２は正規サーバであることが判明しているので、クライアント１に渡された公開鍵は信頼できるものである。【０１４２】
従って、この公開鍵（ハイブリッド暗号を含む）を利用してデータＲやパスワードＭを暗号化し提示しても良い。例えば、このＳＳＬの共通鍵でデータＲやパスワードＭを暗号化し提示することも可能である。またデータＲを共通鍵としてパスワードＭを暗号化し提示することもできる。【０１４３】
データ送信部１１０は、この［Ｈａｓｈ（Ｒ）］を、ネットワーク制御部１００を通してサーバ２に送信する。【０１４４】
データ受信部２１１は、ネットワーク制御部２００を通して、この［Ｈａｓｈ（Ｒ）］を受信する。【０１４５】
次に、データ比較部６１０は、クライアント１から受け取った［Ｈａｓｈ（Ｒ）］と、ハッシュ計算部７１０で得た［Ｈａｓｈ（Ｒ）］とを比較し、同じと判断されれば、クライアント１はパスワードＭを保持する正規クライアントであると判定する。なおハッシュ計算部７１０はここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。また正規クライアントでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０１４６】
クライアント１・サーバ２共に、互いが正規クライアント・正規サーバであることを確認したことで、中間者が介在しない安全な秘匿通信の環境が構築できたことになる。【０１４７】
通信データ生成部８００は、サーバ２に送信したい通信データを生成する。なお、通信データ生成部８００はデータ生成部３００と同じものであっても良い（データ生成部３００が乱数データを生成する機能であった場合は、通信データ生成部８００とは違うものになる。）。【０１４８】
また図４では通信データ生成部８００は、サーバ２から送信ＯＫのトリガを受けずに、通信データの生成・送信を行っているが、通信データの送信はいつ行っても構わない。【０１４９】
但し、クライアント１・サーバ２が共に、正規クライアント・正規サーバを確認し合う前では、中間者の介在を受けている可能性があるので、クライアント１・サーバ２間で、秘密の通信データを共通鍵暗号で受け渡すことはできない。従って、クライアント１がサーバ２に秘密の通信データを送信できるタイミングは、クライアント１のデータ比較部６００で、サーバ２が正規サーバであると確認できた時点となる。【０１５０】
しかし、サーバ２はこの時点では、クライアント１が正規クライアントであるかを確認できておらず、サーバ２にとってはクライアント１からの通信データは信頼できるものではないので、サーバ２はクライアント１からの通信データを保持しなければならなくなる可能性がある。従って、クライアント１が［Ｈａｓｈ（Ｒ）］をサーバ２に送信した後で、通信データ生成部８００が通信データを生成するのが望ましい。【０１５１】
また、サーバ２が送信ＯＫのトリガをクライアント１に送り、これを合図に通信を開始するとしても良い。【０１５２】
共通鍵暗号部９００は、ＳＳＬで作成した共通鍵（図３の「ＫＥＹ」）を用いて、通信データの暗号化を行い、暗号データを生成する。【０１５３】
データ送信部１１０は、この暗号データを、ネットワーク制御部１００を通してサーバ２に送信する。【０１５４】
データ受信部２１１は、ネットワーク制御部２００を通して、この暗号データを受信する。【０１５５】
次に、共通鍵暗号部９１０は、ＳＳＬで作成した共通鍵（図３の「ＫＥＹ」）を用いて、暗号データの復号化を行い、通信データを取得する。なお、ここで共通鍵暗号通信を行うとしているのは、パフォーマンス向上のためであり、暗号通信を引き続き、公開鍵暗号で行っても構わない。【０１５６】
またここでは、共通鍵はＳＳＬで作成したＫＥＹを用いると説明しているが、データＲ、若しくはデータＲから生成される別のデータを共通鍵とすることも可能であり、共通鍵はＳＳＬで作成した共通鍵に限定されるものではない。【０１５７】
なお、図４では、クライアント１から共通鍵暗号通信を開始しているが、逆であっても構わない。その場合、クライアント１の場合と同様に、いつサーバ２は共通暗号通信を開始しても構わないが、先と同じ理由で、クライアント１が正規クライアントであることを確認した後で、通信を開始するとするのが望ましい。
【実施例３】
【０１５８】
図５は、本発明の実施例３のデータ交換手順を示す図である。この実施例３では、クライアントが、サーバに秘密のデータＲを送信し、サーバ・クライアント間でその秘密のデータＲを共通鍵として利用し、共通鍵暗号を行うことで、安全な秘匿通信を行うものである。【０１５９】
クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバの公開鍵Ｅと公開鍵Ｎが渡る。但し、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しで送ることもできる。この公開鍵の受け渡しに関しては、どのような手段を用いても良い。【０１６０】
図５において、クライアントにおいては、１．データＲを生成する。データＲはサーバさえ知らない、第三者には秘密のデータであるが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。また、乱数のビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。【０１６１】
次に、２．データＲを公開鍵で暗号化して、［ＲE  ｍｏｄ  Ｎ］を求め、３．［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余である、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を求める。ここではパスワードＭを加算しているが、減算するとしても良い。このようにパスワードＭを加算、若しくは減算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なおパスワードＭは、オンライン攻撃を受けないように、極端に短いビット長は避けた方が良い。そして４．［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をサーバに送信する。【０１６２】
一方、サーバにおいては、この５．［（ＲE＋Ｍ）ｍｏｄ  Ｎ］をクライアントから受信する。そして、６．この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］から、パスワードＭを減算し（クライアントで減算した場合、ここでは加算する）、モジュラスＮの剰余である［ＲE  ｍｏｄ  Ｎ］を求め、７．［ＲE  ｍｏｄ  Ｎ］をサーバ自らが所有する秘密鍵Ｄと公開鍵Ｎで復号化して、データＲを求める。【０１６３】
次に、８．クライアント・サーバ共に、データＲを共通鍵として共通鍵暗号通信を行う。なお、データＲではなく、データＲから生成する別のデータを共通鍵としても良い。また図５では共通鍵暗号方式の一例としてＡＥＳ暗号方式を図示しているが、ＤＥＳや他の暗号方式を用いても構わない。【０１６４】
なお、中間者が介在しない真に安全な秘匿通信を行うには、クライアントはサーバが正規サーバであることを確認した方が良い。例えば、クライアントが乱数データＫを用意して、このデータＫを、データＲを共通鍵とする共通鍵で暗号化して送信し、サーバがこのデータＫをクライアントに提示できるか否かを確かめると良い。【０１６５】
但し、攻撃者が送受信データを盗聴してデータＫを入手できる場合、オフライン攻撃を行うことが可能なので、サーバがクライアントにデータＫそのものを提示してはならない。安全な提示方法は様々であるが、例えば、データＫのハッシュ値を提示すれば良い。【０１６６】
そして、続いて、サーバはクライアントが正規クライアントであることを確認した方が良い。この方法も様々であるが、例えば、上記とは逆に、サーバが乱数データＬを用意して、このデータＬを、データＲを共通鍵とする共通鍵で暗号化して送信し、クライアントがこのデータＬをサーバに提示できるか否かを確かめると良い。なおこれもオフライン攻撃を受けないように、例えば、データＬのハッシュ値を提示すると良い。【０１６７】
または、図３、図４で示した方法で相互確認しても良い。いずれにしても、相互確認を行えば、より安全に秘匿通信を行うことが可能となる。但し、この相互確認は必ずしも必須というわけではない。クライアント・サーバのどちらかが攻撃者であれば、共通鍵が正しくなく、通信が成立しなくなる。だが相互確認を行えば、セキュリティ強度が向上するので更に良い。【０１６８】
本発明の方法によると、正規クライアントが送信したデータＲは、正規サーバにしか伝わらないので、これを共通鍵として暗号通信を行えば、中間者の介在を受けずに、正規クライアント、正規サーバ間で安全に秘匿通信を行える基盤を構築できる。【０１６９】
但し、実際のデータ通信を行う前に、クライアント・サーバ間で、認証データをこの共通鍵で暗号化して相互に受け渡し、相互に通信相手が正規なクライアント・サーバであるか否かを確かめた方が、安全度が高まり良い。若しくは、先に本願第２の発明で説明した方法で、クライアント・サーバが、相互に通信相手が正規なクライアント・サーバであるか否かを確かめた後で、このデータＲを利用した共通鍵暗号を行うとしても良い。【０１７０】
なお、選択した共通鍵暗号方式や生成した共通鍵がセキュリティ的に甘いと、ここを攻撃されるかもしれないので、十分強度の強い共通鍵暗号方式と共通鍵生成方法を採用するのが望ましい。例えば、共通鍵生成に関しては、クライアント・サーバ間で交換した乱数データやアドレス情報等を、データＲに混ぜ合せて共通鍵生成を行うなどの工夫があると良い。【０１７１】
なおここでも、「データＲは第三者に知られていない値」としているように、データＲは、正規サーバにさえも予想しえない値とするのが望ましい。但し、これはデータＲが必ずしも乱数であることを意味していない。データＲが正規サーバにとって意味あるデータであったとしても、正規サーバにさえ、そのデータがいつ送信されるのか分からなければ、攻撃者はデータＲを予想することも計算することもできず安全である。しかし、セキュリティ強度向上には、データＲを乱数とするのが望ましい。特に暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）の使用が望ましい。【０１７２】
このような課題を解決するために、本願第４の発明では、サーバも、クライアントと同様に前記公開鍵暗号・復号化手段１を有し、クライアント・サーバ共に、前記公開鍵暗号・復号化手段１を用いて、パスワード（パスワードの一部、または全てを加工したデータを含む）の少なくとも一部の情報を含むデータの暗号化を行い、この暗号データ（暗号データの一部、または全てを加工したデータを含む）の少なくとも一部の情報を含むデータを、前記データＭとするものとした。【０１７３】
これによると、攻撃者が特殊なオフライン攻撃を行うことも困難となる。【０１７４】
例えばＥＫＥのような、例えば［ＭＲE  ｍｏｄ  Ｎ］に対しては、“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”と呼ばれるオフライン攻撃方法が知られているが、本方式に対しては有効な攻撃方法とはならない。【０１７５】
“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”とは、攻撃者がサーバのふりをして、例えばＲＳＡ暗号の場合、Ｅ乗のモジュラスＮの剰余が特定の値に偏る（一様分布しない）ような、不正な公開鍵ＥとＮ（ｇｃｄ（Ｅ，φ（Ｎ）≠１））を渡して行う攻撃である。正規クライアントは、この不正な公開鍵を用いてデータＲを暗号化し、これにパスワードを乗じたデータを生成するが、攻撃者はこのデータを入手してオフライン攻撃を行うことが可能である。【０１７６】
攻撃者は入手したデータに対して、仮のデータＭを想定し、この仮のデータＭを除去したデータ、即ち、データＲを公開鍵で暗号化した仮データを逆算し、この仮データが特定の値になっているか否かで、仮パスワードが正しいか否かを推測するものである。もし逆算した仮データが特定の値になっていなければ、想定したデータＭは正しくないと判断でき、正しいデータＭの候補から除外できる。攻撃者は、これをデータＭ、つまりパスワードが取りうるすべての値でチェックして行き、正規パスワードの候補をオフラインで絞り込むことができる。これを何度か繰り返せば、かなりのパスワードの絞込みが可能である。【０１７７】
通常、パスワードのビット長は、オンライン攻撃に耐性を持つ程度の長さを十分保持しているが、攻撃者が、このオフライン攻撃によって、パスワード候補を事前に十分絞り込めば、最終はオンライン攻撃でどのパスワードが正しいかを確かめることが容易となる。【０１７８】
しかしながら、パスワードの情報を含むデータＭも公開鍵で暗号化されると、先のような不正な公開鍵を渡した場合は、同時にデータＭも特定の値に偏る（一様分布しない）ようになるので、攻撃者はパスワードに対して先のような攻撃を仕掛けることが不可能となる。【０１７９】
一見、ＥＫＥでもデータＭを公開鍵で暗号化すれば良いように思われるかもしれないが、例えば、［ＭＲE  ｍｏｄ  Ｎ］を［ＭEＲE  ｍｏｄ  Ｎ］とすると、攻撃者は、正規クライアントと正規サーバとの間に介在し、正規クライアントに対しては、サーバのふりをして、自らの公開鍵を渡し、正規サーバに対しては、クライアントのふりをして、バケツリレー攻撃（ｂｕｃｋｅｔ  ｂｒｉｇａｄｅ  ａｔｔａｃｋ）をオンライン（オンライン攻撃）で行うことが可能となる。【０１８０】
なぜなら、攻撃者は自らが所有するＥ，Ｎ，Ｄを用いて［（ＭEＲE）D  ｍｏｄ  Ｎ］＝［（ＭＲ）ｍｏｄ  Ｎ］を計算できるので、正規サーバの所有するＥ’，Ｎ’を用いて［（ＭＲ）ｍｏｄ  Ｎ］から［（ＭE’ＲE’）ｍｏｄ  Ｎ’］を計算し、正規サーバにこれを渡すことができる。これでは、中間者が入ったことを正規のクライアント・サーバとも検知することができない上、中間者は暗号されたデータを復号化できることになる。（なお同じ理由で、本発明と異なる［（Ｍ＋Ｒ）E  ｍｏｄ  Ｎ］や［（Ｍ−Ｒ）E  ｍｏｄ  Ｎ］といった形式のものも中間者攻撃を受ける。）  またこれを嫌い、［ＭＲE  ｍｏｄ  Ｎ］を［ＭEＲEE  ｍｏｄ  Ｎ］にしたとしても、攻撃者はＥの二乗のモジュラスＮの剰余が特定の値に偏る（一様分布しない）ような、不正な公開鍵ＥとＮを渡すことで攻撃は依然可能である。【０１８１】
本発明では、正規クライアントがサーバに対して、例えば、［（ＲE＋ＭE）ｍｏｄ  Ｎ］を渡す場合、攻撃者がサーバのふりをして、自らの正規の公開鍵を渡し、自らが所有するＤを用いて［（ＲE＋ＭE）D  ｍｏｄ  Ｎ］のような計算を行えたとしても、ＲEとＭEの二項展開の係数を含むため、これを正規サーバの公開鍵Ｅ’，Ｎ’を用いた［（ＲE’＋ＭE’）ｍｏｄ  Ｎ’］を計算することは暗号学的に困難である。【０１８２】
従って、攻撃者は、正規クライアントと正規サーバとの間に介在し、正規クライアントに対しては、サーバのふりをして、自らの公開鍵を渡し、正規サーバに対しては、クライアントのふりをして、バケツリレー攻撃（ｂｕｃｋｅｔ  ｂｒｉｇａｄｅ  ａｔｔａｃｋ）をオンライン（オンライン攻撃）で行うことができない。つまり、データＭがデータＭE’に変わっても、他の請求項と同様、この攻撃は成立しない。【０１８３】
また単なるサーバのふりをしたとしても、データＭ（ＭE’）を知らないので、正しい返答値をクライアントに返すことができない。データＭがデータＭE’に変わっても、この攻撃も他の発明と同様、成立しない。【０１８４】
また、攻撃者が正規クライアントのふりをして、例えば、［（ＲE＋ＭE）ｍｏｄ  Ｎ］の代わりに、自分が知っている数Ａを公開鍵Ｅ、Ｎで暗号化したデータ、即ち、［ＡE  ｍｏｄ  Ｎ］をサーバに送り、サーバから送り返されるデータ、例えば、［Ｈａｓｈ（Ｒ）］を取得して、オフライン攻撃を行うかもしれない。【０１８５】
しかし、正規サーバではビット長が非常に長い秘密鍵Ｄを用いて、例えば、［（ＡE−ＭE）D  ｍｏｄ  Ｎ］のような二項展開を行うので、前記第２の発明と同様、攻撃者はデータＲ（＝［（ＡE−ＭE）D  ｍｏｄ  Ｎ］）を総当たりで調べることは暗号学的に困難である。【０１８６】
このようにＥＫＥとは異なり、本発明は、パスワードの情報を含むデータＭを、データＲと同様に公開鍵で暗号化できるので、特殊なオフライン攻撃に対しても防御可能となるのである。【０１８７】
また、攻撃者はサーバのふりをして、正規クライアントに対して、次のような攻撃を仕掛けることも可能である。【０１８８】
例えば、ＥＫＥの場合、
（Ａ）攻撃者はクライアントに対して、公開鍵Ｅ＝Ｐ−１，公開鍵Ｎ＝Ｐ（但し、Ｐは素数）を渡す。【０１８９】
（Ｂ）正規クライアントはこのデータを受けて、［ＭＲE  ｍｏｄ  Ｎ］＝［ＭＲ(P-1)ｍｏｄ  Ｐ］を攻撃者に渡す。【０１９０】
ここで、データＲとデータＰの最大公約数が１の場合、フェルマーの小定理より、［Ｒ(P-1)ｍｏｄ  Ｐ］＝１が成立するので、［ＭＲ(P-1) ｍｏｄ  Ｐ］＝Ｍとなり、攻撃者はデータＭを入手できる。【０１９１】
一方、本発明の場合、
（Ａ）攻撃者はクライアントに対して、公開鍵Ｅ＝Ｐ−１，公開鍵Ｎ＝Ｐ（但し、Ｐは素数）を渡す。【０１９２】
（Ｂ）正規クライアントはこのデータを受けて、［（ＲE−ＭE）ｍｏｄ  Ｎ］＝［（Ｒ(P-1)−Ｍ(P-1)）ｍｏｄ  Ｐ］を攻撃者に渡す。【０１９３】
ここで、データＲとデータＰの最大公約数が１の場合、フェルマーの小定理より、［Ｒ(P-1)ｍｏｄ  Ｐ］＝１、［Ｍ(P-1)ｍｏｄ  Ｐ］＝１が成立するので、［（Ｒ(P-1)＋Ｍ(P-1)）ｍｏｄ  Ｐ］＝２となり、攻撃者はデータＭを入手できない。【０１９４】
これも同様であるが、ＥＫＥとは大きく異なり、本発明では、パスワードの情報を含むデータＭを、データＲと同様に公開鍵で暗号化できるので、このような特殊なオフライン攻撃に対しても耐性を持つことができる。つまり、公開鍵ＥとＮに如何なる細工を施してみても、データＲと同様にデータＭも特異な値に変化してしまうため、データＲを手がかりとするオフライン攻撃が成立しない。【０１９５】
“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”を含めて、このような特殊なオフライン攻撃は、ＥＫＥのような従来の方法では防ぐことが非常に困難であるため、効果が高い。【０１９６】
また単なるサーバのふりをしたとしても、データＭ（ＭE’）を知らないので、正しい返答値をクライアントに返すことができない。データＭがデータＭE’に変わっても、この攻撃も他の発明と同様、成立しない。【０１９７】
また、攻撃者が正規クライアントのふりをして、例えば、［（ＲE＋ＭE）ｍｏｄ  Ｎ］の代わりに、自分が知っている数Ａを公開鍵Ｅ、Ｎで暗号化したデータ、即ち、［ＡE  ｍｏｄ  Ｎ］をサーバに送り、サーバから送り返されるデータ、例えば、［Ｈａｓｈ（Ｒ）］を取得して、オフライン攻撃を行うかもしれない。【０１９８】
しかし、正規サーバではビット長が非常に長い秘密鍵Ｄを用いて、例えば、［（ＡE−ＭE）D  ｍｏｄ  Ｎ］のような二項展開を行うので、前記第２の発明と同様、攻撃者はデータＲ（＝［（ＡE−ＭE）D  ｍｏｄ  Ｎ］）を総当たりで調べることは暗号学的に困難である。【０１９９】
このようにＥＫＥとは異なり、本発明は、パスワードの情報を含むデータＭを、データＲと同様に公開鍵で暗号化できるので、特殊なオフライン攻撃に対しても防御可能となるのである。【０２００】
また、攻撃者はサーバのふりをして、正規クライアントに対して、次のような攻撃を仕掛けることも可能である。【０２０１】
例えば、ＥＫＥの場合、
（Ａ）攻撃者はクライアントに対して、公開鍵Ｅ＝Ｐ−１，公開鍵Ｎ＝Ｐ（但し、Ｐは素数）を渡す。【０２０２】
（Ｂ）正規クライアントはこのデータを受けて、［ＭＲE  ｍｏｄ  Ｎ］＝［ＭＲ(P-1)ｍｏｄ  Ｐ］を攻撃者に渡す。【０２０３】
ここで、データＲとデータＰの最大公約数が１の場合、フェルマーの小定理より、［Ｒ(P-1)ｍｏｄ  Ｐ］＝１が成立するので、［ＭＲ(P-1) ｍｏｄ  Ｐ］＝Ｍとなり、攻撃者はデータＭを入手できる。【０２０４】
一方、本発明の場合、
（Ａ）攻撃者はクライアントに対して、公開鍵Ｅ＝Ｐ−１，公開鍵Ｎ＝Ｐ（但し、Ｐは素数）を渡す。【０２０５】
（Ｂ）正規クライアントはこのデータを受けて、［（ＲE−ＭE）ｍｏｄ  Ｎ］＝［（Ｒ(P-1)−Ｍ(P-1)）ｍｏｄ  Ｐ］を攻撃者に渡す。【０２０６】
ここで、データＲとデータＰの最大公約数が１の場合、フェルマーの小定理より、［Ｒ(P-1)ｍｏｄ  Ｐ］＝１、［Ｍ(P-1)ｍｏｄ  Ｐ］＝１が成立するので、［（Ｒ(P-1)＋Ｍ(P-1)）ｍｏｄ  Ｐ］＝２となり、攻撃者はデータＭを入手できない。【０２０７】
これも同様であるが、ＥＫＥとは大きく異なり、本発明では、パスワードの情報を含むデータＭを、データＲと同様に公開鍵で暗号化できるので、このような特殊なオフライン攻撃に対しても耐性を持つことができる。つまり、公開鍵ＥとＮに如何なる細工を施してみても、データＲと同様にデータＭも特異な値に変化してしまうため、データＲを手がかりとするオフライン攻撃が成立しない。【０２０８】
“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”を含めて、このような特殊なオフライン攻撃は、ＥＫＥのような従来の方法では防ぐことが非常に困難であるため、効果が高い。【０２０９】
図６は、本発明の実施例３のブロック図である。クライアント１は、パスワード入力部５２０を用いて、パスワードＭをユーザから取得し、あらかじめパスワードＭを記憶保持しているサーバ２と秘匿通信を行うようになっている。なお、クライアント１もサーバ２と同様に、パスワードＭをあらかじめ記憶保持しているとすることも可能である。またサーバ２がプリンタであるケースなど、ユーザが使用時にサーバ２に出向いて利用するものや、クライアント・サーバ型の会議システムなど、サーバ側の端末もユーザが利用する場合（サーバ側ユーザは、クライン側ユーザとは別人）には、サーバ２のパスワードＭもユーザによって入力されるものとすることが可能である。【０２１０】
はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２の公開鍵Ｅと公開鍵Ｎが渡る。【０２１１】
ＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部５２０を用いて求める。【０２１２】
ユーザが、パスワード入力部５２０を用いてパスワードＭを入力する。【０２１３】
また、ＳＳＬネゴシエーション、パスワード入力とは非同期に、データ生成部３００は、データＲを生成する。データＲはサーバ２さえ知らない、第三者には秘密のデータであれば良いが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。また、乱数のビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。【０２１４】
公開鍵暗号・復号部Ａ４００は、公開鍵Ｅ，Ｎを用いて、データＲの暗号化を行い、［ＲE  ｍｏｄ  Ｎ］を計算する。パスワード加算部５００は、［ＲE  ｍｏｄ  Ｎ］にパスワードＭを加算し、モジュラスＮの剰余、即ち［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を得る。【０２１５】
このようにパスワードＭを加算すれば、オンライン攻撃や通常のオフライン攻撃に加え、”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なお図５でも同様であるが、Ｍはパスワードそのものとは限らない。Ｍはパスワードをデータ加工した値であっても良い。実際は、クライアント１・サーバ２間で取り交わした乱数データやアドレス情報等の固有値情報を用いてデータ加工するのが、セキュリティ強度が向上し望ましい。【０２１６】
データ送信部１１０は、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を、ネットワーク制御部１００を通してサーバ２に送信する。【０２１７】
データ受信部２１１は、ネットワーク制御部２００を通して、この［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を受信する。【０２１８】
パスワード減算部５１０は、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算し、モジュラスＮの剰余、即ち［ＲE  ｍｏｄ  Ｎ］を求める。【０２１９】
なお、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］＜Ｍの場合、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］からパスワードＭを減算した結果は「負」になるが、これは剰余算であるので、Ｎ（Ｎの倍数）を加えれば、「正」の値になる。【０２２０】
公開鍵暗号・復号部Ｂ４１０は、サーバ２が、自らが所有する秘密鍵Ｄと公開鍵Ｎを用いて、［ＲE  ｍｏｄ  Ｎ］を復号化して、データＲを求める。【０２２１】
通信データ生成部８００は、サーバ２に送信したい通信データを生成する。なお、通信データ生成部８００はデータ生成部３００と同じものであっても良い（データ生成部３００が乱数データを生成する機能であった場合は、通信データ生成部８００とは違うものになる。）。【０２２２】
なお、クライアントはいつ通信データを作成しても構わないが、［（ＲE＋Ｍ）ｍｏｄ  Ｎ］を送信した後とすると、クライアント１・サーバ２共に、共通鍵暗号通信を行う準備ができているので良い。【０２２３】
共通鍵暗号部９００は、データＲを共通鍵として、通信データの暗号化を行い、暗号データを生成する。データ送信部１１０は、この暗号データを、ネットワーク制御部１００を通してサーバ２に送信する。データ受信部２１１は、ネットワーク制御部２００を通して、この暗号データを受信する。【０２２４】
次に、共通鍵暗号部９１０は、データＲを共通鍵として、暗号データの復号化を行い、通信データを取得する。なお、データＲではなく、データＲから生成する別のデータを共通鍵としても良い。また図６では、クライアント１から共通鍵暗号通信を開始しているが、逆であっても構わない。
【実施例４】
【０２２５】
図７は、本発明の実施例４のデータ交換手順を示す図である。この実施例４では、クライアントが、サーバに秘密のデータＲを送信し、サーバがクライアントにその秘密のデータＲを提示できるか否かで、サーバがパスワードＭを保持する正規サーバである事を確認し、安全な秘匿通信を行うものである。【０２２６】
なお本発明は、クライアントが、サーバが正規サーバであるか否かの確認する方法に関するものであるが、図７では、サーバも、クライアントが正規クライアントであるか否かを確認するところまで説明している。それは、双方向の確認によって、真に中間者の介在を排除した安全な秘匿通信を行うことが可能であるからである。しかし、本質は、本発明である正規サーバの確認方法にある。正規サーバを先に確認できれば、それに続く正規クライアントの確認は難しくない。実際、様々な確認方法手法を用いることが可能である。正規クライアントの確認方法に関しては、図７ではその一例を示す。【０２２７】
クライアント、サーバ間で通常のＳＳＬネゴシエーションを行う。この時点で、クライアントには、サーバの公開鍵Ｅと公開鍵Ｎが渡る。但し、公開鍵の受け渡しは、ＳＳＬ通信に限定されるものでなく、メールや手渡しで送ることもできる。この公開鍵の受け渡しに関しては、どのような手段を用いても良い。【０２２８】
図７において、クライアントにおいては、１．データＲを生成する。データＲはサーバさえ知らない、第三者には秘密のデータであるが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。また、乱数のビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。２．データＲを公開鍵で暗号化して、［ＲE  ｍｏｄ  Ｎ］を求める。３．［ＲE  ｍｏｄ  Ｎ］の計算とは非同期に、パスワードＭを公開鍵で暗号化して、［ＭE  ｍｏｄ  Ｎ］を求める。【０２２９】
なお、パスワードＭをクライアント装置内で記憶している場合には、この［ＭE  ｍｏｄ  Ｎ］をクライアント装置内に記憶しておき、［ＭE  ｍｏｄ  Ｎ］の計算を省略することができる。４．［ＲE  ｍｏｄ  Ｎ］にデータＭEを加算し、モジュラスＮの剰余である、［（ＲE＋ＭE）ｍｏｄ  Ｎ］を求める。ここではＭEを加算しているが、減算するとしても良い。【０２３０】
このようにデータＲと同様にパスワードＭも同じ公開鍵で暗号化し、これを加算、若しくは減算すれば、オンライン攻撃や通常のオフライン攻撃に加え、“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”や”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なおパスワードＭは、オンライン攻撃を受けないように、極端に短いビット長は避けた方が良い。５．そして［（ＲE＋ＭE）ｍｏｄ  Ｎ］をサーバに送信する。【０２３１】
一方、サーバにおいては、６．この［（ＲE＋ＭE）ｍｏｄ  Ｎ］をクライアントから受信する。７．［ＲE  ｍｏｄ  Ｎ］の受信とは非同期に、パスワードＭを公開鍵で暗号化して、［ＭE  ｍｏｄ  Ｎ］を求める。なおパスワードＭをサーバ装置内で記憶している場合には、この［ＭE  ｍｏｄ  Ｎ］をサーバ装置内に記憶しておき、［ＭE  ｍｏｄ  Ｎ］の計算を省略することができる。なお、［ＭE  ｍｏｄ  Ｎ］を保存する方が、生のパスワードデータをサーバ装置内に保存するのに比べ、多少セキュリティ度が高い。そして、８．この［（ＲE＋ＭE）ｍｏｄ  Ｎ］から、データＭEを減算し（クライアントで減算した場合、ここでは加算する）、モジュラスＮの剰余である、［ＲE  ｍｏｄ  Ｎ］を求め、９．［ＲE  ｍｏｄ  Ｎ］をサーバ自らが所有する秘密鍵Ｄと公開鍵Ｎで復号化して、データＲを求める。そして、１０．データＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、更に、１１．［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算し、１２．この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］をクライアントに送信する。【０２３２】
サーバがクライアントに対して、データＲそのものを提示すると、攻撃者が送受信データを盗聴できた場合に、データＲを用いたオフライン攻撃を行うことが可能となる。そこでここではデータＲを一方向性関数で処理し、データＲそのものを逆算できなくしている。【０２３３】
また、ハッシュ計算を二回行っている理由は、クライアントがサーバに正規クライアントであることを証明するのに、データＲのハッシュ値を示すようにしているからであって、もしクライアントが正規クライントである証明を他の方法で行うのであれば、サーバでのハッシュ計算は一回だけでも構わない。ハッシュ計算を何度行うかは本質的な問題ではない。また、ここではデータＲそのものをハッシュ計算しているが、データＲから生成される別のデータをハッシュ計算するようにしても良い。【０２３４】
次に、クライアントにおいては、１３．［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を受信する。１４．クライアントは自らが用意したデータＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、更に、１５．［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。なおこの計算は、１３の受信を待たずに、事前に行っても良い。１６．サーバから受け取った［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］と、自らが計算して得た［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］とを比較し、同じと判断されれば、サーバがパスワードＭを保持する正規サーバと判定する。【０２３５】
なお正規サーバでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。そして、１７．自らが計算して得た［Ｈａｓｈ（Ｒ）］をサーバに送信する。なおクライアントはここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。【０２３６】
ここでは、クライアントはサーバに対して、正規クライアントであることを［Ｈａｓｈ（Ｒ）］を提示して証明するものとしているが、この提示方法は様々な方法を選択することが可能である。この時点ではサーバは正規サーバであることが判明しているので、クライアントに渡された公開鍵は信頼できるものである。従って、この公開鍵（ハイブリッド暗号を含む）を利用してデータＲやパスワードＭを暗号化し提示しても良い。【０２３７】
例えば、このＳＳＬの共通鍵でデータＲやパスワードＭを暗号化し提示することも可能である。またデータＲを共通鍵としてパスワードＭを暗号化し提示することもできる。【０２３８】
次に、サーバにおいては、１８．［Ｈａｓｈ（Ｒ）］を受信する。１９．クライアントから受け取った［Ｈａｓｈ（Ｒ）］と、自らが計算して得た［Ｈａｓｈ（Ｒ）］とを比較し、同じと判断されれば、クライアントがパスワードＭを保持する正規クライアントと判定する。なおサーバはここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。また正規クライアントでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０２３９】
クライアント・サーバ共に、互いが正規クライアント・正規サーバであることを確認したことで、中間者が介在しない安全な秘匿通信の環境が構築できたことになる。２０．クライアント・サーバ共に、ＳＳＬで作成したＫＥＹを用いて共通鍵暗号通信を行う。【０２４０】
なお、共通鍵暗号通信を行うとしているのは、パフォーマンス向上のためであり、暗号通信を引き続き、公開鍵暗号で行っても構わない。また、ここでは鍵の一例としてＳＳＬで作成したＫＥＹを用いると説明しているが、データＲ、若しくはデータＲから生成される別のデータをＫＥＹとして共通鍵暗号を行うことも可能であり、共通鍵はＳＳＬのＫＥＹに限定されるものではない。また図７では共通鍵暗号方式の一例としてＡＥＳ暗号方式を図示しているが、ＤＥＳや他の暗号方式を用いても構わない。【０２４１】
図８は、図７の本発明の実施例４のブロック図である。クライアント１は、パスワード入力部５２０を用いて、パスワードＭをユーザから取得し、あらかじめパスワードＭを記憶保持しているサーバ２と秘匿通信を行うようになっている。なお、クライアント１もサーバ２と同様に、パスワードＭをあらかじめ記憶保持しているとすることも可能である。またサーバ２がプリンタであるケースなど、ユーザが使用時にサーバ２に出向いて利用するものや、クライアント・サーバ型の会議システムなど、サーバ側の端末もユーザが利用する場合（サーバ側ユーザは、クライアント側ユーザとは別人）には、サーバ２のパスワードＭもユーザが入力するとしても良い。【０２４２】
はじめに、クライアント１がサーバ２に接続を開始し、ＳＳＬネゴシエーションを行う。この時点で、クライアント１には、サーバ２の公開鍵Ｅと公開鍵Ｎが渡る。【０２４３】
ＳＳＬネゴシエーションの前後で、クライアント１は、ユーザに対して、パスワード入力を、パスワード入力部５２０を用いて求める。【０２４４】
ユーザが、パスワード入力部５２０を用いてパスワードＭを入力する。【０２４５】
また、ＳＳＬネゴシエーション、パスワード入力とは非同期に、データ生成部３００は、データＲを生成する。データＲはサーバ２さえ知らない、第三者には秘密のデータであれば良いが、暗号学的に安全な乱数（つまり、すでに発生した乱数列から次の乱数を予想できない乱数）とするのが、セキュリティ強度が向上し望ましい。また、乱数のビット長は、オフライン攻撃を受けないために、暗号的に安全な程度に長いものが望ましい。【０２４６】
公開鍵暗号・復号部Ａ４００は、公開鍵Ｅ，Ｎを用いて、データＲの暗号化を行い、［ＲE  ｍｏｄ  Ｎ］を計算する。またこれとは非同期に公開鍵暗号・復号部Ａ４００は、公開鍵Ｅ，Ｎを用いて、パスワードＭの暗号化を行い、［ＭE  ｍｏｄ  Ｎ］を計算する。なおパスワードＭをクライアント装置内で記憶している場合には、この［ＭE  ｍｏｄ  Ｎ］をクライアント１内に記憶しておき、［ＭE  ｍｏｄ  Ｎ］の計算を省略することができる。【０２４７】
パスワード加算部５００は、［ＲE  ｍｏｄ  Ｎ］にデータＭEを加算し、モジュラスＮの剰余、即ち［（ＲE＋ＭE）ｍｏｄ  Ｎ］を得る。このようにデータＲと同様にパスワードＭも同じ公開鍵で暗号化し、これを加算すれば、オンライン攻撃や通常のオフライン攻撃に加え、“ｅ−Ｒｅｓｉｄｕｅ  Ａｔｔａｃｋｓ”や”パスワード想定攻撃“といった特殊なオフライン攻撃にも防御が可能となる。なお図７でも同様であるが、Ｍはパスワードそのものとは限らない。Ｍはパスワードをデータ加工した値であっても良い。実際は、クライアント１・サーバ２間で取り交わした乱数データやアドレス情報等の固有値情報を用いてデータ加工するのが、セキュリティ強度が向上し望ましい。【０２４８】
データ送信部１１０は、この［（ＲE＋ＭE）ｍｏｄ  Ｎ］を、ネットワーク制御部１００を通してサーバ２に送信する。【０２４９】
データ受信部２１１は、ネットワーク制御部２００を通して、この［（ＲE＋ＭE）ｍｏｄ  Ｎ］を受信する。公開鍵暗号・復号部Ａ４２０は、公開鍵Ｅ，Ｎを用いて、パスワードＭの暗号化を行い、［ＭE  ｍｏｄ  Ｎ］を計算する。なおここで公開鍵暗号・復号部Ａ４２０は、公開鍵暗号・復号部Ａ４００と等価である。なお、この計算はいつ行っても良い。またサーバ２が［ＭE  ｍｏｄ  Ｎ］を記憶すれば、この計算は省略できる。【０２５０】
パスワード減算部５１０は、［（ＲE＋ＭE）ｍｏｄ  Ｎ］からデータＭEを減算し、モジュラスＮの剰余、即ち［ＲE  ｍｏｄ  Ｎ］を求める。【０２５１】
なお、［（ＲE＋ＭE）ｍｏｄ  Ｎ］＜Ｍの場合、［（ＲE＋ＭE）ｍｏｄ  Ｎ］からデータＭEを減算した結果は「負」になるが、これは剰余算であるので、Ｎ（Ｎの倍数）を加えれば、「正」の値になる。【０２５２】
公開鍵暗号・復号部Ｂ４１０は、サーバ２が、自らが所有する秘密鍵Ｄと公開鍵Ｎを用いて、［ＲE  ｍｏｄ  Ｎ］を復号化して、データＲを求める。【０２５３】
ハッシュ計算部７１０は、データＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、ハッシュ計算部７１０は、更に、［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。【０２５４】
サーバ２がクライアント１に対して、データＲそのものを提示すると、攻撃者が送受信データを盗聴できた場合に、データＲを用いたオフライン攻撃をかけることが可能である。そこで、ここではデータＲを一方向性関数で処理し、データＲそのものを逆算できなくしている。【０２５５】
また、ハッシュ計算を二回行っている理由は、クライアント１がサーバ２に正規クライアントであることを証明するのに、データＲのハッシュ値を示すようにしているからであって、もし他の方法でこれを行うのであれば、サーバ２でのハッシュ計算は一回だけでも構わない。ハッシュ計算を何度行うかは本質的な問題ではない。【０２５６】
データ送信部２１０は、この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を、ネットワーク制御部２００を通してクライアント１に送信する。【０２５７】
データ受信部１１１は、ネットワーク制御部１００を通して、この［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を受信する。【０２５８】
ハッシュ計算部７００は、データ生成部３００で生成したデータＲのハッシュ値、即ち［Ｈａｓｈ（Ｒ）］を計算し、ハッシュ計算部７００は、更に、［Ｈａｓｈ（Ｒ）］のハッシュ値、即ち［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］を計算する。なおこの計算は、先の［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］の受信を待たずに、事前に行っても良い。【０２５９】
次に、データ比較部６００は、サーバ２から受け取った［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］と、ハッシュ計算部７００で得た［Ｈａｓｈ（Ｈａｓｈ（Ｒ））］とを比較し、同じと判断されれば、サーバ２がパスワードＭを保持する正規サーバと判定する。なお正規サーバでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０２６０】
そして、データ比較部６００は、ハッシュ計算部７００で得た［Ｈａｓｈ（Ｒ）］をデータ送信部１１０に送る。【０２６１】
ここでは、クライアント１はサーバ２に対して、正規クライアントであることを［Ｈａｓｈ（Ｒ）］を提示して証明するものとしているが、この提示方法は様々な方法を選択することが可能である。この時点ではサーバ２は正規サーバであることが判明しているので、クライアントに渡された公開鍵は信頼できるものである。【０２６２】
従って、この公開鍵（ハイブリッド暗号を含む）を利用してデータＲやパスワードＭを暗号化し提示しても良い。例えば、このＳＳＬの共通鍵でデータＲやパスワードＭを暗号化し提示することも可能である。またデータＲを共通鍵としてパスワードＭを暗号化し提示することもできる。データ送信部１１０は、この［Ｈａｓｈ（Ｒ）］を、ネットワーク制御部１００を通してサーバ２に送信する。データ受信部２１１は、ネットワーク制御部２００を通して、この［Ｈａｓｈ（Ｒ）］を受信する。【０２６３】
次に、データ比較部６１０は、クライアントから受け取った［Ｈａｓｈ（Ｒ）］と、ハッシュ計算部７１０で得た［Ｈａｓｈ（Ｒ）］とを比較し、同じと判断されれば、クライアントがパスワードＭを保持する正規クライアントと判定する。なおハッシュ計算部７１０はここで改めて［Ｈａｓｈ（Ｒ）］を計算し直しても良い。また正規クライアントでないと認識した場合は、直ちにエラーを返すか、または通信を遮断しても構わない。しかし安全上は、一定の間、適当なダミー通信を行うのが良い。【０２６４】
クライアント１・サーバ２共に、互いが正規クライアント・正規サーバであることを確認したことで、中間者が介在しない安全な秘匿通信の環境が構築できたことになる。【０２６５】
通信データ生成部８００は、サーバ２に送信したい通信データを生成する。なお、通信データ生成部８００はデータ生成部３００と同じものであっても良い（データ生成部３００が乱数データを生成する機能であった場合は、通信データ生成部８００とは違うものになる。）。【０２６６】
また図８では通信データ生成部８００は、サーバ２から送信ＯＫのトリガを受けずに、通信データの生成・送信を行っているが、通信データの送信はいつ行っても構わない。【０２６７】
但し、クライアント１・サーバ２が共に、正規クライアント・正規サーバを確認し合う前では、中間者の介在を受けている可能性があるので、クライアント１・サーバ２間で、秘密の通信データを共通鍵暗号で受け渡しできない。従って、クライアント１がサーバ２に秘密の通信データを送信できるタイミングは、クライアントのデータ比較部６００で、サーバ２が正規サーバであると確認できた時点となる。【０２６８】
しかし、サーバ２はこの時点では、クライアント１が正規クライアントであるかを確認できておらず、サーバ２にとってはクライアント１からの通信データは信頼できるものではないので、サーバ２はクライアント１からの通信データを保持しなければならなくなる可能性がある。従って、クライアント１が［Ｈａｓｈ（Ｒ）］をサーバ２に送信した後で、通信データ生成部８００が通信データを生成するのが望ましい。【０２６９】
また、サーバ２が送信ＯＫのトリガをクライアント１に送り、これを合図に通信を開始するとすることもできる。【０２７０】
共通鍵暗号部９００は、ＳＳＬで作成した共通鍵（図７の「ＫＥＹ」）を用いて、通信データの暗号化を行い、暗号データを生成する。データ送信部１１０は、この暗号データを、ネットワーク制御部１００を通してサーバ２に送信する。データ受信部２１１は、ネットワーク制御部２００を通して、この暗号データを受信する。【０２７１】
次に、共通鍵暗号部９１０は、ＳＳＬで作成した共通鍵（図７の「ＫＥＹ」）を用いて、暗号データの復号化を行い、通信データを取得する。なお、ここで共通鍵暗号通信を行うとしているのは、パフォーマンス向上のためであり、暗号通信を引き続き、公開鍵暗号で行っても構わない。またここでは共通鍵は、ＳＳＬで作成した共通鍵を用いると説明しているが、データＲ、若しくはデータＲから生成される別のデータを共通鍵とすることも可能であり、ＳＳＬで作成した共通鍵に限定されるものではない。【０２７２】
なおこの図では、クライアント１から共通鍵暗号通信を開始しているが、逆であっても構わない。その場合、クライント１の場合と同様に、いつサーバ２は共通暗号通信を開始しても構わないが、先と同じ理由で、クライアントが正規クライアントであることを確認した後に、通信を開始するとするのが望ましい。【０２７３】
図９は、本発明を用いたネットワークＰＢＸ（Ｎｅｔｗｏｒｋ  Ｐｒｉｖａｔｅ  Ｂｒａｎｃｈ  ｅＸｃｈａｎｇｅ）を示す構成図である。【０２７４】
図９において、４０はネットワークケーブル、１０はネットワークＰＢＸ、２０はＨＵＢ、３０はＰＢＸの子端末（電話）である。そして、通話元の子端末（電話）３０、及び通話先の子端末（電話）９０は、それぞれ３１、９１の表示部、３２、９２の受話器、３３、９３のテンキー（入力部）で構成されている。【０２７５】
図１０は、本発明に係る秘匿通信方法を用いたに係るネットワークＰＢＸのブロック図である。図１０において、図９と同様、４０はネットワークケーブル、１０はネットワークＰＢＸ、２０はＨＵＢ、３０はＰＢＸの子端末（電話）で、３１はパスワード入力を促す画面、及び通話先番号入力を促す画面を表示する表示部、３２は会話を行うための受話器、３３はユーザがパスワード、及び通話先番号を入力するテンキー（入力部）である。【０２７６】
子端末（電話）３０とネットワークＰＢＸ１０は、ＨＵＢ２０を通して、ネットワークケーブル４０でつながっており、ネットワーク制御部１００とネットワーク制御部２００とでネットワーク通信を行い、データの送受信を行う。子端末（電話）３０とネットワークＰＢＸ１０との間のデータ送受信すべてにおいて、ネットワーク制御部１００、２００がネットワークへのデータ送信、及びネットワークからのデータ受信の役割を果たすが、説明を簡潔に行うために、以下の説明では、ネットワーク制御部１００、２００の説明は割愛する。なお、ネットワーク制御部１００、２００は、図８におけるネットワーク制御部１００、２００に相当する。【０２７７】
はじめに表示制御部４１は、図１０に示したように、表示部３１にパスワード入力を促す画面を表示しておく。【０２７８】
電話をかけたいユーザは、テンキー３３を用いて、自らのＩＤ（例えば、０〜９の数字、８桁程度のＩＤ、最後は“＊”を入力）を入力し、続けて自らのパスワード（例えば、０〜９の数字、８桁程度のパスワード、最後は“＃”を入力）を入力する。【０２７９】
テンキー制御部４３は、“＊”以前に入力された数字をＩＤとして、“＃”以前に入力された数字をパスワードとして認識し、両方をパスワード記憶部５０に保存する。続いてテンキー制御部４３は、表示制御部４１に対して、ＩＤ，パスワード入力の完了通知を行う。【０２８０】
表示制御部４１は、通話先番号入力を促す画面を表示部３１に表示する。【０２８１】
電話をかけたいユーザは、通話先番号入力を促す画面を見て、次にテンキー３３を用いて、通話先番号を入力する。【０２８２】
テンキー制御部４３は、通話先番号が入力されたのを検知したら、通話先番号を通話先番号記憶部５２に保存し、ＳＳＬクライアント制御部６０に対して、通話先番号入力の完了通知を行う。【０２８３】
ＳＳＬクライアント制御部６０は、ＳＳＬサーバ制御部６１とＳＳＬネゴシエーションを行う（ＳＳＬクライアント制御部６０から通信を開始する。）。ＳＳＬクライアント制御部６０は、このＳＳＬネゴシエーションの際、ＳＳＬサーバ制御部６１から受信した公開鍵（ＲＳＡ暗号の場合、公開鍵Ｅと公開鍵Ｎ）を公開鍵記憶部６２に保存する。なお、ＳＳＬサーバ制御部６１は、秘密鍵記憶部６３から読み出した秘密鍵（ＲＳＡ暗号の場合、秘密鍵Ｄと公開鍵Ｎ）を用いてＳＳＬネゴシエーションを行う。なお、ＳＳＬサーバ制御部６１がＳＳＬクライアント制御部６０に対して渡す公開鍵も、秘密鍵記憶部６３に保存されているものとし、ＳＳＬネゴシエーションにおいて、ＳＳＬサーバ制御部６１は、秘密鍵記憶部６３より公開鍵ＥとＮを読み出し、これらをＳＳＬクライアント制御部６０に渡すものとする。【０２８４】
ＳＳＬネゴシエーションの最終段階で、ＳＳＬクライアント制御部６０とＳＳＬサーバ制御部６１の両方で、それぞれ独立に、共通鍵暗号部７１と共通鍵暗号部８１で用いる共通鍵が作成される（ＳＳＬ仕様で自明な通り、この共通鍵はＳＳＬクライアント制御部６０とＳＳＬサーバ制御部６１で同じものになる。）。【０２８５】
そして、ＳＳＬネゴシエーションが終了したら、ＳＳＬクライアント制御部６０は、認証制御部７０に対して、ＳＳＬネゴシエーションの完了通知を行う。なお、このＳＳＬネゴシエーションが成功すると、子端末（電話）３０とネットワークＰＢＸ１０とがＳＳＬセッション（仮想的な暗号通信経路）でつながる。【０２８６】
但し、この時点ではまだ中間攻撃者が、子端末（電話）３０とネットワークＰＢＸ１０との間に介在し、子端末（電話）３０とネットワークＰＢＸ１０と個別にＳＳＬネゴシエーションを行い、バケツリレー攻撃（ｂｕｃｋｅｔ  ｂｒｉｇａｄｅ  ａｔｔａｃｋ）を行っている恐れがあり、ＳＳＬセッションで暗号通信を行っていても安全とはいえない。【０２８７】
認証制御部７０は認証制御部８０との間で、図７、及び図８で説明した要領に従って、相互に相手がパスワードを保持する正当な正規サーバ、及び正規クライアントであるか否かを確認する。具体的には、以下の通りである。【０２８８】
（１）認証制御部７０は、パスワード記憶部５１から読み出したパスワード（Ｍ）と公開鍵記憶部６２から読み出した公開鍵（ＲＳＡ暗号の場合、公開鍵Ｅと公開鍵Ｎ）、及びデータ生成部５３で発生させた乱数（データＲ）とで、［（ＲE＋ＭE）ｍｏｄ  Ｎ］を生成し、ネットワークＰＢＸ１０に送信する。【０２８９】
（２）認証制御部８０は、パスワード記憶部５１から読み出したパスワード（Ｍ）と秘密鍵記憶部６３から読み出した秘密鍵と公開鍵（ＲＳＡ暗号の場合、秘密鍵Ｄ、公開鍵Ｅ，公開鍵Ｎ）、及び認証制御部７０から受け取った［（ＲE＋ＭE）ｍｏｄ  Ｎ］とで、データＲを逆算し、次にこのハッシュ値の更にハッシュ値（Ｈａｓｈ（Ｈａｓｈ（Ｒ）））を計算し、子端末（電話）３０に送信する。【０２９０】
（３）認証制御部７０は、データ生成部５３で発生させたＲのハッシュ値の更にハッシュ値を計算し、認証制御部８０から受け取ったＨａｓｈ（Ｈａｓｈ（データ））と比較する。同じ値であれば、サーバはパスワードを保持する正当な正規サーバと認識する。次に、データＲのハッシュ値（Ｈａｓｈ（Ｒ））をネットワークＰＢＸ１０に送信する。【０２９１】
（４）認証制御部８０は、自ら計算して求めたＨａｓｈ（Ｒ）と認証制御部７０から受け取ったＨａｓｈ（Ｒ）を比較する。同じ値であれば、クライアントはパスワードを保持する正当な正規サーバと認識する。次に、認証制御部７０に対して、データ送信開始の指示を行う。【０２９２】
この際、認証制御部８０は、パスワード記憶部５１に保存されている多くのパスワードの内、どのユーザのパスワードを用いて計算すれば良いのかを特定できなくてはならないが、これには例えば、パスワードと共に入力したＩＤを利用すれば良い。パスワード記憶部５１では、ＩＤとパスワードとを紐付けして記憶しておき、認証制御部７０が認証制御部８０に対して送信するデータにＩＤを付与することで、認証制御部８０ではＩＤから利用するパスワードを特定する。また電話番号とパスワードを紐付けしておくことでも、パスワードの特定は可能である。この場合、ユーザはわざわざ子端末（電話）３０においてＩＤを入力する手間がなくなるので良い。子端末（電話）３０が、ユーザ個人毎に所有する携帯電話（共有して利用しない電話）である場合に適した方法といえる。【０２９３】
認証制御部７０は、認証制御部８０からデータ送信開始の指示を受けたら、図８の通信データ生成部８００に相当する呼制御部７２に対して呼制御の開始を指示する。なお、認証制御部７０で正規サーバでないと判断された場合、及び認証制御部８０において、正規クライアントでないと判断された場合は、現在つながっているＳＳＬセッションは切断される。【０２９４】
互いに正規サーバ、及び正規クライアントであることを確認できたら、子端末（電話）３０には、中間攻撃者の公開鍵ではなく、ネットワークＰＢＸ１０の公開鍵が渡っていることになるので、通信を安全に行うことができる。たとえ中間攻撃者が、子端末（電話）３０とネットワークＰＢＸ１０との間に介在したとしても、ＳＳＬセッション（暗号通信）で通信を行う限り、中間攻撃者は送受信されているデータの中身を解読できない。【０２９５】
呼制御部７２は、通話先番号記憶部５２から通話先番号を読み出し、図８の通信データ生成部８００に相当する呼制御部８２との間で、例えばＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）に準拠した呼制御作業を行う。但し、この呼制御で送受信するデータはすべて、図８の共通鍵暗号部９００に相当する共通鍵暗号部７１、及び図８の共通鍵暗号部９１０に相当する共通鍵暗号部８１を通して、暗号化・復号化される。つまりＳＳＬセッション（暗号通信）で安全に通信される。【０２９６】
呼制御部７２と呼制御部８２との間で呼制御作業が終了したら、呼制御部７２は、図８のこれまた通信データ生成部８００に相当する通話制御部７３に呼制御の完了通知を行う。同様に、呼制御部７２と呼制御部８２との間で呼制御作業が終了したら、呼制御部８２は、通話制御部８３に呼制御の完了通知を行う。【０２９７】
通話制御部７３と通話制御部８３とで音声データの送受信が行われる。これも呼制御と同様に、送受信するデータはすべて、共通鍵暗号部７１、及び共通鍵暗号部８１を通して、暗号化・復号化される。つまりＳＳＬセッション（暗号通信）で安全に通信される。通話制御部７３は音声データを受信したら音声制御部４２を通して、受話器３２に音声を流し、逆に、受話器３２から音声が流れてきたら、これを、音声制御部４２を通して音声データとして受信し、この音声データを通話制御部８３に送信する。【０２９８】
なお、この図１０では、これから先、通話先の電話９０とネットワークＰＢＸ１０との接続方法を示していないが、通話先の電話９０とネットワークＰＢＸ１０との接続は、子端末（電話）３０とネットワークＰＢＸ１０の接続方法と同様である。【０２９９】
但し、２つの相違点がある。１点目は、ネットワークＰＢＸ１０が通話先の電話に対して、通信開始の合図を送ることである。これを受けて通話先の電話はベルを鳴らし、子端末（電話）３０と同様に、表示部９１にパスワード入力を促す画面を表示する。なお、この合図は、ＳＳＬネゴシエーションではない。２点目は、通話先の電話９０でユーザが自らのＩＤとパスワードを入力したら、直ちにＳＳＬネゴシエーションが始まることである。当然であるが、通話先の電話９０とネットワークＰＢＸ１０との間では、通話先番号は不要であるので、通話先の電話９０でユーザが通話先番号を入力する必要はない。【０３００】
以上、子端末（電話）３０とネットワークＰＢＸ１０、及び通話先の電話９０とネットワークＰＢＸ１０との間の一連のＳＳＬネゴシエーション、認証、呼制御、通話制御が終了した時点で、子端末（電話）３０と通話先の電話９０との間で通話が可能となる。なお、通話制御は、子端末（電話）３０と通話先の電話９０との間の通話が可能となった状態で行うとしても良い。【０３０１】
従来、ネットワークＰＢＸ１０で、中間者攻撃を防御する（安全な通信を実現する）方法としては、子端末（電話）３０にクライアント証明書を配布する手法が知られているが、実装費用が高く、有効期限など非常に面倒な管理が必要であるといった課題があった。しかし、この方法なら、実装費用は安く、管理も簡単な上、安全性も低下しない。【０３０２】
また、子端末（電話）３０が、ユーザ個人毎に所有する携帯電話である場合には、携帯電話の紛失の際に、不正利用を防ぐ効果もある。（利用には正しいパスワードの入力が必要である。しかもそのパスワードは携帯電話内には一切保存されていないので、携帯電話内部を解析されても安全性が損なわれない。）
【実施例５】
【０３０３】
図１１は、暗号化復号化システムのハードウェア構成図である。図１１は、実施例１ないし４に適用可能である。暗号化復号化システムは、クライアント１およびサーバ２を有している。クライアント１およびサーバ２は、コネクタ（ＲＪ４５）１７、２７を介してインターネットなどのネットワークで接続されている。【０３０４】
クライアント１では、バス線１９に、ＣＰＵ１１、Ｆｌａｓｈ  ＲＯＭ１２、ＳＤ  ＲＯＭ１３、ネットワークコントローラＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）１５、およびＵＳＢコントローラＩＣ１６が接続されている。それぞれは集積回路で構成されている。ＣＰＵ１１は、機能ブロックとして、データ生成部３００、暗号復号部４３０、パスワード加算部５００、およびデータ送信部１１０を有している。Ｆｌａｓｈ  ＲＯＭ１２には、公開鍵Ｅ、Ｎが格納されている。ネットワークコントローラＩＣ１５には、機能ブロックとして、ネットワーク制御部１００を有しており、ネットワーク制御部１００は、ＰＨＹ（物理レイヤー）ブロック１５Ａ、およびＭＡＣ（メディアアクセスコントロールレイヤー）ブロック１５Ｂで構成される。ＵＳＢコントローラＩＣ１６には、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓが接続自在なＵＳＢ  Ｉ／Ｆ１８が接続されている。【０３０５】
サーバ２では、バス線２９に、ＣＰＵ２１、Ｆｌａｓｈ  ＲＯＭ２２、ＳＤ  ＲＯＭ２３、およびネットワークコントローラＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）２５が接続されている。それぞれは集積回路で構成されている。ＣＰＵ２１は、機能ブロックとして、暗号復号部４４０、パスワード減算部５１０、およびデータ受信部２１１を有している。Ｆｌａｓｈ  ＲＯＭ２２には、公開鍵Ｎおよび秘密鍵Ｄが格納されている。ネットワークコントローラＩＣ２５には、機能ブロックとして、ネットワーク制御部２００を有しており、ネットワーク制御部２００は、ＰＨＹ（物理レイヤー）ブロック２５Ａ、およびＭＡＣ（メディアアクセスコントロールレイヤー）ブロック２５Ｂで構成される。ＵＳＢコントローラＩＣ１６には、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓが接続自在なＵＳＢ  Ｉ／Ｆが接続されている。【０３０６】
本出願は、２００９年９月２９日出願の日本特許出願（特願２００９−２２３９９１）に基づくものであり、その内容はここに参照として取り込まれる。
【産業上の利用可能性】
【０３０７】
本発明に係る暗号化装置、復号化装置、暗号化方法、復号化方法、および暗号化複合化システムは、暗号的に脆弱な、ビット長の短いパスワードを用いながら、ＳＳＬのような公開鍵暗号通信において、中間者を排除した安全な秘匿通信を、簡単かつ軽量に行え、有用である。
【符号の説明】
【０３０８】
１    クライアント
２    サーバ
１００    ネットワーク制御部
１１０    データ送信部
１１１    データ受信部
２００    ネットワーク制御部
２１０    データ送信部
２１１    データ受信部
３００    データ生成部
４００    公開鍵暗号・復号部Ａ
４１０    公開鍵暗号・復号部Ｂ
４２０    公開鍵暗号・復号部Ａ
【図１】
2011040023.tif 000003
【図２】
2011040023.tif 000004
【図３】
2011040023.tif 000005
【図４】
2011040023.tif 000006
【図５】
2011040023.tif 000007
【図６】
2011040023.tif 000008
【図７】
2011040023.tif 000009
【図８】
2011040023.tif 000010
【図９】
2011040023.tif 000011
【図１０】
2011040023.tif 000012
【図１１】
2011040023.tif 000013
【国際調査報告】
2011040023.tif 000014
2011040023.tif 000015
2011040023.tif 000016
2011040023.tif 000017