JPH10322325A

JPH10322325A - 暗号認証方式

Info

Publication number: JPH10322325A
Application number: JP9139334A
Authority: JP
Inventors: Shusuke Yamaji; 秀典山地
Original assignee: Individual
Current assignee: Individual
Priority date: 1997-05-14
Filing date: 1997-05-14
Publication date: 1998-12-04

Abstract

(57)【要約】【課題】データの転送経路上で認証情報の盗難の防止
を図り、模擬サーバーや模擬クライアントに対するセ暗
号キーュリティーを確立することができる暗号認証方式
を提供すること。【解決手段】クライアント側公開暗号キーがクライア
ントからサーバーに送信され、前記クライアント側公開
暗号キーを用いて、前記サーバーから前記クライアント
に質問が発せられる。前記クライアント側公開暗号キー
を用いて、サーバー側公開暗号キーも前記サーバーから
前記クライアントに送信される。前記サーバー側公開暗
号キーを用いて、前記質問の回答が前記クライアントか
ら前記サーバーに送信され、前記クライアントからの前
記回答が正しいと暗号キー、前記サーバーと前記クライ
アント間に認証が確立される。サーバー側公開暗号キー
は、割り符の形で送信されてもよい。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サーバーとクライ
アント間におけるセ暗号キーュリティに関し、特にクラ
イアントとサーバー間での認証の確立に関する。

【０００２】

【従来の技術】インターネット、イントラネットに代表
されるように、通信ネットワークは急速な展開を示して
いる。また、それに伴い、電子取り引暗号キー、電子マ
ネー等の新しい取引形態が発生しようとしている。

【０００３】インターネットは、米国ＤＡＲＰＡから派
生したネットワークで、プロトコルには、ＴＣＰ／ＩＰ
を用いている。特徴として、データ転送にバケツリレー
方式を用いている。つまり、各ノードにおいて、データ
パケットを目的端末に向かって中継している。従って、
データの発信元ノードから宛先ノードの間に位置するノ
ードのおのおのにおいて、データパケットを盗み・改竄
するなどの行為が比較的容易に可能である。

【０００４】また、イントラネットは、基本的にオープ
ンであるインターネットの技術を、閉鎖的、または、部
分的に閉鎖的なネットワークへ導入したものである。

【０００５】クライアントがサーバーにアクセスする
際、サーバーがどのクライアントかを認識するために行
う従来の基本的な認証手順を図３を参照して以下に説明
する。

【０００６】ステップS１０２でクライアントは、サー
バーへアクセスする。ステップS１０４でサーバーは、
クライアントへ識別子（ＩＤ）と識別子保証子（パスワ
ード）を要求する。ステップS１０６で、クライアント
は、サーバーへＩＤとパスワードを送信する。ステップ
S１０８で、サーバーは、クライアントからのＩＤとパ
スワードの組み合わせが正しいか否かを判定する。クラ
イアントからのＩＤとパスワードの組み合わせが正しい
とステップS１０８で判定されると、ステップS１１０
で、サーバーは、クライアントのアクセスを許可する。
同時に、サーバーは、クライアントが何者かを理解す
る。ここで、サーバーは、例えば、銀行、ホストコンピ
ューター、端末コンピューター、パーソナルコンピュー
ターなどであり、クライアントは、例えば人間、端末コ
ンピューターなどである。

【０００７】上記の方法では、IDとパスワードがクライ
アントの認証のために使用されている。しかしながら、
IDとパスワードが送信経路の途中で盗まれた場合には、
その後正しい認証が行われる保証が無い。

【０００８】また、送信データに対して、単純に暗号を
かけたのでは、識別に要するＩＤとパスワードを新たに
作り出しているにすぎなず、データの転送経路上でデー
タを盗めるので、意味をなさない。即ち、暗号化は、
「暗号化されたデータを復元して得られるデータ」が重
要な場合にのみ有効である。認証の場合のように、暗号
化されたデータそのものが重要な場合には暗号化は意味
がない。なぜならば、通信の当事者になりすますのに必
要なものは、暗号化されたデータを解読したその中身で
はなく、その暗号化されたままのデータそのものである
からである。暗号化したデータを盗み、その暗号化した
データをサーバーに送れば、認証が成立してしまう。

【０００９】以上のような問題点を解決するために、ク
ライアントとサーバー間で認証を確立して、データ通信
を安全にする方法として種々のものが提案されているの
で、以下に説明する。

【００１０】一つの方法は、ＤＥＳに代表される共通暗
号キーを用いる暗号方式である。この場合、暗号化と解
読とに同じ共通暗号キーが使用される暗号方式であり、
最も一般的な暗号方式である。しかしながら、この方式
でも共通暗号キーが盗まれたと暗号キーには、正しい認
証が行われる保証が無い。

【００１１】そこで、より安全な暗号認証方式として、
ＲＳＡに代表される公開暗号キーと秘密暗号キーを用い
る暗号方式である。ここで、公開暗号キーとは、暗号化
すると暗号キーの暗号キーであり、秘密暗号キーは、公
開暗号キーで暗号化されたものを解読すると暗号キーに
使う暗号キーである。公開暗号キーから秘密暗号キーを
求めることは、困難であり、ＤＥＳ方式に比べて信用性
が高い。しかしながら、まだ、電子商取引を考える場合
には、十分とは言えない。

【００１２】このように、インターネットやイントラネ
ットなどの全てのネットワークにおいて、あるいはコン
ピューターシステムにおいて、上記のような認証を行う
場合、そのデータの転送経路上で認証に必要な情報を盗
めば、その情報を用いて、他人になりすますことが可能
である。このような場合、認証を確実に行うことがで暗
号キーず、電子商取引を行う上での最大のネックとなっ
ている。

【００１３】

【発明が解決しようとする課題】本発明は、上記事情に
鑑みてなされたものである。したがって、本発明の目的
は、データの転送経路上で認証情報の盗難の防止を図
り、また、もし盗まれたとしても認証の確立にほとんど
影響の無い暗号認証方式を提供することにある。また、
本発明の他の目的は、オープンネットワークなどにおい
て、模擬サーバーや模擬クライアントに対するセキュリ
ティーを確立することができる暗号認証方式を提供する
ことにある。

【００１４】

【課題を解決するための手段】本発明の暗号認証方式で
は、クライアント側公開暗号キーがクライアントからサ
ーバーに送信され、前記クライアント側公開暗号キーを
用いて、前記サーバーから前記クライアントに質問が発
せられる。前記クライアント側公開暗号キーを用いて、
サーバー側公開暗号キーも前記サーバーから前記クライ
アントに送信される。前記サーバー側公開暗号キーを用
いて、前記質問の回答が前記クライアントから前記サー
バーに送信され、前記クライアントからの前記回答が正
しいと暗号キー、前記サーバーと前記クライアント間に
認証が確立される。

【００１５】また、本発明の暗号認証方式では、クライ
アント側公開暗号キーがクライアントからサーバーに送
信される。前記クライアント側公開暗号キーを用いて、
前記サーバーから前記クライアントに質問が発せられ、
また、前記クライアント側公開暗号キーを用いて、サー
バー側公開暗号キーのための第１の割り符が前記サーバ
ーから前記クライアントに送信される。クライアント
は、受信される前記第１の割り符と保持している第２の
割り符から前記サーバー側公開暗号キーを生成し、生成
されたサーバー側公開暗号キーを用いて、前記質問の回
答を前記クライアントから前記サーバーに送信する。前
記クライアントからの前記回答が正しいとき、前記サー
バーと前記クライアント間に認証が確立する。

【００１６】上記の暗号認証方式において、前記クライ
アントは、前記第１と第２の割り符と予め定められたア
ルゴリズムにより前記サーバー側公開暗号キーを生成す
る。

【００１７】上記の暗号認証方式において、前記サーバ
ーは、前記クライアント側の前記第２の割り符に基づい
て前記第１の割り符を動的に発生する。

【００１８】上記の暗号認証方式において、認証確立
後、共通暗号暗号キーが前記サーバーから前記クライア
ントに送信される、その後の通信はこの共通暗号キーを
使用して行われる。

【００１９】上記の暗号認証方式において、前記共通暗
号暗号キーは、前記サーバーが動的に発生する。

【００２０】上記の暗号認証方式において、前記クライ
アント側公開暗号キーは、前記クライアントが動的に発
生する。

【００２１】上記の暗号認証方式において、前記サーバ
ーには、複数の質問が用意されており、前記サーバーは
動的に選択した少なくとも１つの質問を前記クライアン
トに送信する。

【００２２】

【発明の実施の形態】以下に本発明による暗号認証方式
を図面を参照して説明する。

【００２３】上述のように、データに対して、単純に暗
号をかけたのでは、識別に要するＩＤとパスワードを新
たに作り出しているにすぎず、転送経路上でデータを盗
めるので、意味をなさない。そこで、本発明の第１の実
施形態による暗号認証方式は、以下のような手順で実行
される。

【００２４】サーバーとクライアント間で認証を確立す
べきとき、ステップＳ２で、クライアントは、クライア
ント側公開暗号キーを動的にランダムに発生してサーバ
ーに送信する。ステップＳ４で、サーバーは、クライア
ント側公開暗号キーを用いて、クライアントに質問を発
する。「質問」とは、上記のＩＤとパスワードと同じ役
割を果たすものである。従って、質問が従来のＩＤとパ
スワードであってもよい。

【００２５】質問は少なくとも１つ、一般には複数用意
されている。それらの質問のうちから少なくとも１つの
質問がなされる。当然、この場合、質問は１つでもよ
い。人間が操作するクライアントでは、質問が複数ある
と不便であるが、コンピューター同士などでは、複数の
質問うちのいくつかという形で行った方が、セキュリテ
ィーが高まる。更に、複数の質問の中から動的に決定さ
れた数の質問がなされてもよい。動的に決定された数の
動的に選択される質問がなされるならば、更にセキュリ
ティーを高めることができる。

【００２６】ステップＳ４では、サーバーはサーバー側
公開暗号キーもクライアントに送信する。

【００２７】ステップＳ６、クライアントは、サーバー
側公開暗号キーを用いて質問の回答をサーバーに送信す
る。

【００２８】質問に対する回答が正しければ、クライア
ントの認証が確立し、サーバーは、ステップＳ８で、今
後の通信に使用される共通暗号キーを動的に発生し、そ
の共通暗号キーをクライアント側公開暗号キーを用いて
クライアントに送信する。クライアントが共通暗号キー
を受信すると、その後その共通暗号キーを用いてデータ
通信を行うことができる。

【００２９】以上のような手順を踏むことにより、認証
に必要な情報は、暗号化されたデータを解読したデー
タ、つまり、暗号前の情報）になるので、経路上でデー
タを盗まれたとしても、不正利用することができなくな
る。これによって、データ転送経路上でデータを盗まれ
ることがあっても、暗号方式に信頼性がある限り悪用で
きない。

【００３０】また、クライアント側公開暗号キーも動的
に発生されているので、毎回異なる。したがって、更に
信頼性を高めることができる。また、認証の確立後、サ
ーバーから送信される共通暗号キーも動的に発生されて
いるので、信頼性が更に高まる。

【００３１】以上のように本発明の暗号認証方式では、
データ転送経路上のセキュリティーが確立されていない
経路でも、認証が可能となると言う効果がある。また、
認証時には、公開暗号キー・秘密暗号キーを用いて通信
し、認証成立後には、共通暗号キーを用いて通信するの
で、データの通信に要する全体の処理が少なくてすむ。
このため、コンピューターへの負荷が少なくすむとい効
果もある。

【００３２】次に、本発明の第２の実施形態による暗号
認証方式を説明する。

【００３３】上記第１の実施形態では、データ転送経路
上のセキュリティーが確立されていない経路でも、認証
が可能となると言う効果が得られたが、模擬サーバー・
模擬クライアントに対するセキュリティーがまだ確立さ
れていない。通信経路の途中に模擬サーバーを使用すれ
ば、認証に必要な情報をクライアントから入手すること
が可能である。逆も可能である。

【００３４】そこで、第２の実施形態による暗号認証方
式では、模擬サーバー・模擬クライアントに対するセキ
ュリティーを確立するための方式を示す。

【００３５】模擬サーバー・模擬クライアントに対する
セキュリティーの確立のためには、それが模擬であるか
真であるかをチェックするのではなく、真サーバー・真
クライアントでなければ、ならない状況を作り出せば良
い。この場合、第３者サーバーによるクライアント、サ
ーバーを保証するという方法もあるが、転送経路上（特
にサーバーへデータを配送しているときのサーバーの直
前など）に悪者がいる場合、全ての転送データパケット
が悪者の手中に収められるのと同じであるため、決定打
にかける。つまり第３者まで模擬されたら意味がない。

【００３６】そこで使用されるのが、「割り符」方式認
証である。具体的な手順は以下のようになる。

【００３７】サーバーとクライアント間で認証を確立し
たいとき、ステップＳ１２で、クライアントは、クライ
アント側公開暗号キーを動的にランダムに発生してサー
バーに送信する。

【００３８】ステップＳ１４で、サーバーは、クライア
ント側公開暗号キーを用いてクライアントに質問を発す
る。この「質問」は、上記の第１の実施形態における質
問と同様である。また、このとき、サーバーは、クライ
アント側公開暗号キーを用いて、割り符をクライアント
に送信する。

【００３９】ステップＳ１６、クライアントは、サーバ
ーからの割り符からサーバー側公開暗号キーを求める。
例えば、サーバーからの割り符と予めサーバーとの間で
約束して保持している割り符に対してあらかじめ決めら
れたアルゴリズムを適用してサーバー側公開暗号キーを
導出する。クライアントは得られたサーバー側公開暗号
キーを用いて質問の回答をサーバーに送信する。

【００４０】質問に対する回答が正しければ、ステップ
Ｓ１６までで、クライアントの認証が確立する。そのと
き、サーバーは、ステップＳ１８で、今後の通信に使用
される共通暗号キーを動的に発生し、その共通暗号キー
をクライアント側公開暗号キーを用いてクライアントに
送信する。クライアントが共通暗号キーを受信すると、
その後その共通暗号キーを用いて通信を行うことができ
る。

【００４１】以上述べたように、第１の実施形態におけ
る暗号認証方式との相違点は、ステップＳ１４である。
サーバー側の割り符がクライアントへ「質問」と同時に
転送される点である。割り符は、サーバ・クライアント
双方が持っており、それを組み合わせることで、サーバ
ーの質問に対する回答を転送するときに使用される「サ
ーバー側の公開暗号キー」が得られるようにするのであ
る。

【００４２】具体的な例としては、サーバー側割り符を
ＳＳ、クライアント側割り符をＣＳとすると、（サーバー側公開暗号キー）＝ＳＳＸＯＲＣＳが考えられる（ＸＯＲとは、排他論理和）。サーバー側
公開暗号キーを計算するための関数は、ＸＯＲに限らな
い。もっと高度なアルゴリズムが使用されれば、セキュ
リティー度を高めることができる。

【００４３】真サーバーであれば、真クライアントの割
り符を既知であるため、動的に割り符を発生することに
より、導出後のサーバー側公開暗号キーを毎回変更する
ことができる。

【００４４】もし、真サーバー、真クライアントの関係
でなければ、模擬クライアントは、回答時に使用するサ
ーバー側公開暗号キーを得ることができない。即ち、真
クライアントの割り符が不明であるため、サーバー側公
開暗号キーを導出できない。また、模擬サーバーは、真
クライアントの割り符が不明であるため、正しい「回
答」（真クライアントから真サーバーへの回答）を得ら
れない。

【００４５】本発明による暗号認証方式は、種々の認証
に適用可能であるが、以下にインターネット上での銀行
送金を例に取り説明する。サーバーをインターネット上
の銀行、クライアントを家庭や企業の端末とする。ユー
ザーを端末を操作している人間とする。なお、以下の説
明で、認証アプレットは、クライアント側で動作するア
プリケーションである。

【００４６】クライアントは、Ｗｅｂブラウザで、銀行
のホームページへアクセスする。それと同時にＪａｖａ
アプレットやＡｃｔｉｖｅｘコントロールなどで実現さ
れている認証ダイアログが現れる。この認証ダイアログ
を発生させているソフトウェア（以下、認証アプレット
という）は、本発明の暗号認証方式の手順で認証を行
う。認証アプレットが、Ｊａｖａアプレットで、且つ、
ダウンロードされる場合は、ＪＤＫ１．１移行での改竄
確認を行う。

【００４７】ここで、ユーザーが送金を選択すると、認
証アプレットは、真性乱数やユーザー固有のデータなど
からクライアント側公開暗号キーを生成する。ここで
は、より安全性を高めるために認証の度に作成してい
る。認証アプレットは、サーバーへクライアント側公開
暗号キーを送信する。

【００４８】次に、認証アプレットは、ユーザーにユー
ザーの口座番号と暗証番号を要求する。認証アプレット
は、サーバーに割り符を要求する。認証アプレットは、
割り符からサーバー側公開暗号キーを導出する。その
後、認証アプレットは、サーバー側公開暗号キーを用い
て、口座番号と暗証番号をサーバーに送信する。

【００４９】その後、認証アプレットは、サーバーか
ら、共通暗号キーと識別コードを受信すると（以後のサ
ーバー・クライアント間通信には、この共通暗号キーを
用いた暗号通信が行われる）、認証アプレットは、ユー
ザーに、送金先の口座番号と金額などを要求する。その
後、認証アプレットは、サーバーへ送金先の口座番号を
送信する。

【００５０】サーバーから送金先の情報を受信すると、
認証アプレットは、ユーザーに送金先の情報を表示し
て、確認を求める。ユーザーが送金先・金額がＯＫと判
断したら、認証アプレットは、送金先と金額と識別コー
ドをサーバーに送信する。

【００５１】サーバーから確認情報を受信すると、認証
アプレットは、ユーザーに確認情報を表示する。以上に
より、銀行送金処理が完了する。

【００５２】ここでは、広く一般に普及しているＷｅｂ
ブラウザと、サンマイクロシステムズのＪａｖａ、また
は、マイクロソフトのＡｃｔｉｖｅＸコンポーネントで
の実施を想定した例を挙げた。

【００５３】次に、電子マネーを例に取り、本発明の暗
号認証方式について説明する。ここで、サーバーを電子
マネーの発行機関、クライアントをＩＣカード、ユーザ
ーをＩＣカードの所有者とする。この場合、キャッシュ
レジスターは、ノードと見なすことができる。従って、
本発明の暗号認証方式は、このような形態でも適用でき
る。

【００５４】この例では、ＩＣカードと電子マネーの発
行機関との通信の際、キャッシュレジスターを中継す
る。このキャッシュレジスターが、悪者である場合、デ
ータの転送経路であるため、盗用・改竄は可能であり、
不当な額を支払わされる可能性があるが、本発明の暗号
認証方式が適用されれば、このセキュリティーホールを
埋めることができる。当然、第２の実施形態にかかる暗
号認証方式が適用されれば、模擬ＩＣカード、模擬電子
マネー発行機関に対しても、保全が可能である。

【００５５】以上のように、本発明の暗号認証方式は、
コンピューター全般の認証に用いることができるが、特
に以下のような例に適用可能である。

【００５６】商用サーバーにおける、財・サービスの取
引の直接当事者間の確認。この場合、認証の内容は、モ
ールの認証、受発注サーバの認証等となる。想定される
認証局は、第３者機関であり、ネットワーク事業者も含
んでいる。

【００５７】銀行・クレジット系の取引における決済の
際の確認。この場合、認証の内容は、カードホルダーの
認証、加盟店の認証、金融機関の認証等である。想定さ
れる認証局は、銀行、クレジット会社であり、金融機関
からのアウト・ソーシングである第３者機関も含まれ
る。

【００５８】セキュリティーメールにおける電子メール
の相手方の確認。この場合、認証の内容は、個別の認証
である。想定される認証局は、ネットワーク事業者も含
む第３者機関である。

【００５９】グループウェアにおけるグループメンバー
の確認。この場合、認証の内容は、個人の確認であり、
想定される認証局は、企業、団体、及び企業・団体から
のアウト・ソーシングである第３者機関である。

【００６０】公的業務における行政サービスの際の確
認。この場合、認証の内容は、個人の認証、団体の認証
であり、想定される認証局は、公的機関である。

【００６１】

【発明の効果】以上述べたように、本発明によれば、転
送経路上でのセキュリティーが確立されていないネット
ワークでも、保全された認証・通信を行うことが可能で
ある。また、模擬サーバ、模擬クライアントによる認証
情報盗用・なりすましを防止することができる。これに
より、電子ネットワーク社会の発展をさらに加速するこ
とができる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態にかかる暗号認証方式
の手順を説明するためのタイミング図である。

【図２】本発明の第２の実施形態にかかる暗号認証方式
の手順を説明するためのタイミング図である。

【図３】従来の暗号認証方式の手順を説明するためのタ
イミング図である。

Claims

【特許請求の範囲】

【請求項１】クライアント側公開暗号キーをクライア
ントからサーバーに送信することと、前記クライアント側公開暗号キーを用いて、前記サーバ
ーから前記クライアントに質問を発することと、前記クライアント側公開暗号キーを用いて、サーバー側
公開暗号キーを前記サーバーから前記クライアントに送
信することと、前記サーバー側公開暗号キーを用いて、前記質問の回答
を前記クライアントから前記サーバーに送信すること
と、及び前記クライアントからの前記回答が正しいと暗
号キー、前記サーバーと前記クライアント間に認証を確
立することとを具備する暗号認証方式。
【請求項２】クライアント側公開暗号キーをクライア
ントからサーバーに送信することと、前記クライアント側公開暗号キーを用いて、前記サーバ
ーから前記クライアントに質問を発することと、前記クライアント側公開暗号キーを用いて、サーバー側
公開暗号キーのための第１の割り符を前記サーバーから
前記クライアントに送信することと、受信される前記第１の割り符と保持している第２の割り
符から前記サーバー側公開暗号キーを生成し、生成され
たサーバー側公開暗号キーを用いて、前記質問の回答を
前記クライアントから前記サーバーに送信することと、
及び前記クライアントからの前記回答が正しいとき、前
記サーバーと前記クライアント間に認証を確立すること
とを具備する暗号認証方式。
【請求項３】前記クライアントは、前記第１と第２の
割り符と予め定められたアルゴリズムにより前記サーバ
ー側公開暗号キーを生成する請求項２に記載の暗号認証
方式。
【請求項４】前記サーバーは、前記クライアント側の
前記第２の割り符に基づいて前記第１の割り符を動的に
発生することを含む請求項２または３に記載の暗号認証
方式。
【請求項５】認証確立後、その後の通信に使用される
共通暗号暗号キーを前記サーバーから前記クライアント
に送信することを具備する請求項１乃至４のいずれかに
記載の暗号認証方式。
【請求項６】前記共通暗号暗号キーは、前記サーバー
が動的に発生する請求項５に記載の暗号認証方式。
【請求項７】前記クライアント側公開暗号キーは、前
記クライアントが動的に発生する請求項１乃至６のいず
れかに記載の暗号認証方式。
【請求項８】前記サーバーには、複数の質問が用意さ
れており、前記サーバーは動的に選択した少なくとも１
つの質問を前記クライアントに送信する請求項１乃至７
のいずれかに記載の暗号認証方式。