JP2023167724A - オンライン認証技術 - Google Patents

Abstract

【課題】付加的なセキュリティデバイスを用いることなく、パスワードをインターネットに晒さず、フィッシングに強いオンライン認証を構築するためのシステムプロトコル技術を提供する。【解決手段】オンライン認証方法において、ネットワークに接続する第１の電子機器及び第２の電子機器と、第１の電子機器を操る第１のユーザーと、を有する。第１の電子機器は、第１の特殊コードを有し、第２の電子機器は、第２の特殊コードを有する。第１の電子機器は、第１のユーザーから第１の入力を受け取り、第２の電子機器から、第２の入力を受け取り、第１の入力及び第２の入力と第１の特殊コードから、第２の中間コードを生成する。第１の電子機器は、第２の中間コードを、第２の電子機器に送り、第２の電子機器は、第３の関数を用い、第２の特殊コードと、第２の中間コードと、から第１の比較コードを生成する。【選択図】なし

Description

本発明は、サーバーと通信端末の間のオンライン認証の検査を相互に行い、認証情報をサーバーに渡さず局所的に扱うことによってユーザーの利便性とセキュリティ（安全性）の両立を実現し、フィッシング詐欺を防ぐオンライン認証の方法を実現するシステムプロトコル技術に関する。

従来のオンライン認証は、サーバーに認められた正規のユーザーにのみサーバーへのアクセスを許可するための仕組み（ユーザー認証のシステムプロトコル）である。つまり、このシステムプロトコルでは、ユーザーがアクセスを希望するサーバーが認証検査の主体であり、ユーザーまたはユーザーの利用する通信端末は認証検査されるのみである。つまり、一方向認証である。

具体的には、ユーザーの手の内にある通信端末は、有線無線を問わず何等かの通信線によってサーバーと接続されており、該通信線はインターネット（あるいはネットワーク）の一部を構成しており、ユーザーが通信端末を通じてアカウント情報（ユーザーＩＤ等）を入力してサーバーにアクセス許可を要求すると、サーバーは通信端末を通じてユーザーにパスワード等の認証情報（以下簡単にパスワード）の入力を促す。ユーザーは通信端末を通じてパスワードを入力し、通信端末はそのパスワードをサーバーに転送する。サーバーはそのパスワードとユーザーＩＤ等のアカウント情報（以下簡単にユーザーID）を比較し、それが正しければ該ユーザーのサーバーへのアクセスを許可する。ここで、「（ユーザーIDとパスワードが）正しい」とは、入力されたユーザーIDと、サーバーに保管されたユーザーIDが一致しており、さらに、該ユーザーIDに関して入力されたパスワードと、サーバーに保管されたパスワードが一致している、という意味である。

通信端末は物理的存在であるが、複数存在して構わない。ユーザーはどの通信端末を用いても同じようにユーザーＩＤとパスワードを用いて希望するサーバーにアクセス許可を要求することが可能である。つまりサーバーは、ユーザーがアクセス要求に用いた通信端末のＩＰアドレスやＭＡＣアドレスを時刻とともに記録する程度のことはしても、ユーザーＩＤとパスワードさえ正しければ基本的にユーザーのアクセスを許可する。一方、通信端末の役割はユーザーへのインターフェースを提供し、インターネット（あるいはネットワーク）に接続しているなどに限定されている。

しかしながら、これは、隣の部屋にサーバーが存在し、ユーザーがサーバーの所在とLANの接続をいつでも物理的に確認できるインターネット草創期の考え方に基づいている。つまり、部外者と関係者が建屋に混入している状態で関係者のみにサーバーへのアクセスを許可するためものである。

ＷｉＦｉやインターネットが普及した現代、ユーザーがアクセスを試みるサーバーが物理的にどこにあるのかユーザーは知らないし、ほとんどの場合知ろうとも思わない。さらに、そのサーバーと自分の手の内にある通信端末との接続が物理的にどのようになっているのか、ユーザーだけでなくサーバーの管理者も知らないし、ほとんどの場合誰も知ろうとも思わない。つまり現代社会では、多少付加的なセキュリティ技術が追加されたとしても、基本的にはユーザーＩＤとパスワードさえあれば任意のユーザーが、有線無線のインターネット接続（一般にネットワーク）を用いて地球上の任意のところに物理的に所在する任意のサーバーにいつでもアクセスできるという利便性が体現されている。

この利便性によりインターネットの利用は普及し、個人や法人等無数のアカウント（ユーザーID等で認知される）が日常的に複数のサーバーへのアクセスを試みている。その過程で、無数のユーザーＩＤとパスワードがインターネット上に晒されている状態になっている。こうして晒された無数のユーザーＩＤとパスワードを誰がどこで管理しているのかわからないのが現在の状態である。これはセキュリティ（安全性）上の重大な問題を既にもたらしている。

（スマートカード、smartcard）
この問題に対処するため、スマートカード等の外部デバイス（通信端末以外の付加的なセキュリティデバイス）を利用する方法がある。

しかしながら、スマートカードはカードリーダーがなければ機能しない。つまり、ユーザーは通信端末以外にスマートカードとカードリーダーの両方を別途準備しなければならない。インターネットの大部分がモバイルに移行した現代では、多くのユーザーがオフィス以外からインターネットを活用し目的とするサーバーにアクセスする。その場合、ユーザーはスマートカードとカードリーダーを日常的に持ち歩かなければならなくなる。あるいは有効な（規格のあった）カードリーダーが設置されている場所を常に探し出さなければならない。さらに複数のアカウントを扱うユーザーの場合複数のスマートカードを持ち歩かなければならなくなるかもしれない。スマートカードの規格が異なればカードリーダーの規格も異なる。同じ規格でもセキュリティ上の問題が発覚すればスマートカードもカードリーダーもバージョンアップしなければならない。スマートカードをユーザー本人が管理していたとしても自宅やオフィスの外部に設置され自分が管理していないカードリーダーを使う場合スマートカード、カードリーダー、通信端末の管理が常に整合性の取れた状態で保たれている保証はない。

こうしてスマートカードは自宅やオフィスに置きっぱなしになり、定期的管理・使用から見捨てられたカードリーダーのバージョンは古くなる。このような不便さから、一部の高セキュリティを要する仕事に従事するユーザー以外スマートカードの利用は敬遠されるようになる。こうしてスマートカードを前提にしたサービスが細れば、多くのサーバーでスマートカードを前提にした認証を採用しなくなる、あるいはアップグレードしなくなる。

ひところ前までに現代人はクレジットカードを持ち歩くのに慣れた。これはクレジットカードのカードリーダーが多くの店舗で普及した後に出来上がった状態である。スマートカードの不便さは、主に専用のカードリーダーが普及していないことによる。そのためカードリーダーを自分で携帯あるいは管理しながら使うことを強要される。

（２要素認証）
このような不便さを補うための折衷案として２要素認証（Two-Factor Authentication, TFA）が導入された。

具体的には、ユーザーの手の内にある通信端末は、有線無線を問わず何等かの通信線によってサーバーと接続されており、該通信線はインターネットの一部を構成しており、ユーザーが通信端末を通じてアカウント情報（ユーザーＩＤ等）を入力してサーバーにアクセス許可を要求すると、サーバーは、認証検査のため、通信端末を通じてユーザーにパスワード等の認証情報（以下簡単にパスワード）の入力を促す。ユーザーは通信端末を通じてパスワードを入力し、通信端末はそのパスワードをサーバーに転送する。サーバーは、更に第二の認証コード（Authenticator）を通信端末に入力するようユーザーに要求する。ユーザーは、この認証コードを何らかの外部デバイスから取得することが可能である。ここで、認証検査とは、入力されたユーザーIDとサーバーに保管されたユーザーIDが一致しているかどうか、該ユーザーIDに関して入力されたパスワードとサーバーに保管されたパスワードが一致しているかどうか、さらに、該ユーザーIDに関して入力された第二の認証コードとサーバーの内部データとして保管されている第二の認証コードが一致しているかどうか、を調べることである。検査の結果すべて一致しているとみなされた場合アクセスが承認される。

スマートカードの専用カードリーダーと異なり、現代人はスマートフォンを携帯し活用するのに慣れている。スマートフォンにAuthenticator用アプリ（認証アプリ）をダウンロードし、スマートフォンにインストールするのは今や珍しくない。認証アプリは特定の桁数（例えば６桁）の数字（第二の認証コード）をスマートフォンのディスプレーに表示する。つまり、認証アプリをインストールしたスマートフォンが、第二の認証コードを取得するための外部デバイスとなる。ポイントは、ユーザーは既にこの外部デバイスを、付加的不便さを感じずに既に携帯しているところである。認証アプリのインストールは一回作業すれば良く、インストールした後は付加的なセキュリティデバイスを持ち歩く必要はない。この点で既に利便性を損なっていないと言える。

第二の認証コードは所定の認証有効時間（たとえば３分）毎に自動的に変更される。サーバーが通信端末に表示するQRコードをスマートフォンにインストールした認証アプリで読み取ると、認証アプリが表示する第二の認証コードが、サーバーの内部データと同期される。つまり、ユーザーは、この認証有効時間以内にスマートフォンに表示される第二の認証コードを、サーバーからの案内に従って通信端末を通じて入力すれば良い。サーバーは、入力されたユーザーＩＤ、パスワード、第二の認証コードを、あらかじめ保管してあるものとそれぞれ比較し、該ユーザーにアクセスを承認するかどうか判定する。こうして、第二の認証コードもパスワードと同様にインターネット上に晒されることになるが、認証時間を過ぎれば第二の認証コードは変わるので、アカウントを乗っ取られる可能性は低くなる。

こうして、スマートカードとカードリーダーを利用する方法より利便性が高く、かつパスワードのみよりセキュリティを高めた認証方法が実現できると考えられている。２要素認証は、全面的にではないが、スマートカードに比べると既にかなり普及してきている。

（フィッシング）
しかしながら、２要素認証もセキュリティとして万全ではない。フィッシングという方法によって簡単に破られることが知られている。

具体的には、ユーザーの手の内にある通信端末は、有線無線を問わず何等かの通信線によってサーバーと接続されており、該通信線はインターネットの一部を構成しており、ユーザーが通信端末を通じてアカウント情報（ユーザーＩＤ等）を入力してサーバーにアクセス許可を要求すると、サーバーは通信端末を通じてユーザーにパスワード等の認証情報（以下簡単にパスワード）の入力を促す。ユーザーは通信端末を通じてパスワードを入力し、通信端末はそのパスワードをサーバーに転送する。サーバーは、さらに第二の認証コード（Authenticator）を通信端末に入力するようユーザーに要求する。ユーザーは、たとえば、認証アプリをインストールしたスマートフォンから第二の認証コード取得することが可能である。ただし、こうして取得した第二の認証コードには認証有効時間（例えば３分）が設定してある。

ここで問題なのは、上述したように、「ＷｉＦｉやインターネットが普及した今、ユーザーがアクセスを試みるサーバーが物理的にどこにあるのかユーザーは知らないし、ほとんどの場合知ろうとも思わない。さらに、そのサーバーと自分の手の内にある通信端末との接続が物理的にどのようになっているのか、ユーザーだけでなくサーバーの管理者も知らないし、ほとんどの場合誰も知ろうとも思わない」ということである。つまり、サーバーの物理的存在意義は既に希薄になっている。

つまりユーザーは、サーバーと連絡する際手の内にある通信端末に表示された画面のみ見ている。それは、サーバーがユーザーの通信端末に指示して表示させるものであり、ユーザーがその画面上で“ウェブサイト”と認識するものである。つまり、既に物理的存在意義が希薄になっているサーバーとは、ユーザーの視点からすればウェブサイトである。ユーザーにユーザーＩＤの入力を促すのも、ユーザーIDの入力を受け付けるのも、サーバーがユーザーの通信端末に指示して表示させるウェブサイトである。ユーザーＩＤに紐づけされたパスワードの入力をユーザーに促すのも、そのパスワードの入力を受け付けるのも、サーバーがユーザーの通信端末に指示して表示させるウェブサイトである。サーバーがユーザーの通信端末に第二の認証コードの入力を促すのも、第二の認証コードの入力を受け付けるのも、サーバーがユーザーの通信端末に指示して表示させるウェブサイトである。

こうしてユーザーがウェブサイトに入力した認証情報、たとえば、ユーザーID、パスワード、第二の認証コード等は、有線無線のインターネット上に晒され、有線無線のインターネットを通じて、物理的所在があいまいなまま“所定の”サーバーに送付されると信じられている。

漸く問題の本質が浮かび上がってくる。有線無線のインターネットに晒される認証情報（ユーザーID、パスワード、第二の認証コード等）を守るため、第二の認証コードの有効認証時間以外に、VPN、暗号、電子署名、あるいはブロックチェーン等様々なセキュリティ技術が活用できる。しかしながらこうした技術は、すべて、ユーザーが正規のウェブサイトに認証情報を入力することを前提にしている。

つまり、ユーザーの通信端末に表示されているウェブサイトが、該ユーザーが真に意図してアクセスしようとしているサーバーが指示してユーザーの通信端末に表示させたものかどうか、判定するには別の方法が必要になる、ということである。

具体的には、定期メンテナンスなどを装い、ハッカーが偽ウェブサイトのリンクを張り付けた電子メールをユーザー（正規のアカウントホルダー）に送りつける。正規のアカウントホルダーは、電子メールの指示に従ってリンクをクリックし偽ウェブサイトに誘導される。正規のアカウントホルダーは、正規の認証情報（ユーザーID、パスワード、第二の認証コード等）を偽ウェブサイトに入力する。ハッカーは、第二の認証コードの有効認証時間（例えば３分）以内に正規のウェブサイトに入り、正規の認証情報を用いて目的のサーバーに正規のアカウントホルダーを装ってアクセスする。アクセス後すぐにパスワードを変更して正規のアカウントを乗っ取り、自分のスマートフォンにインストールしてある認証アプリンで正規のＱＲコードを読み取って同期化し、その後いつでも正規ユーザーとして目的のサーバーにアクセスする権利を奪うことができる。これをフィッシングという。

このように、たとえ２要素認証を有効にしていたとしても、ユーザーがよほど注意深くなければフィッシングを防ぐことはできない。注意深くするほど利便性は損なわれる。

図１は、セキュリティ（Security）と利便性（Convenience）の相関関係の一例を説明する図面である。パスワードのみのシステムプロトコル（Password）、パスワードと2要素認証を併用するシステムプロトコル（Password & TFA）、さらにスマートカードを併用するシステムプロトコル(Password, TFA & smartcard)の順にセキュリティ（Security）は強化されるが、この順序に従って、利便性（Convenience）は損なわれていく。

さらに一人のユーザーが所有するアカウント数（Accounts #）が増大すると、そのユーザーは複数のパスワードを管理しなければならなくなる。すべてのユーザーが必ずしもすべてのパスワードに常に目が行き届いている訳ではない。この場合パスワードのみのシステムプロトコル（あるいは、単にシステム）であっても、パスワードの定期更新などを考えると、パスワード管理の煩雑さが増すため利便性は損なわれる。また古いパスワードはそもそもセキュリティホールになりやすいため、アカウント数の増大と共にさらにセキュリティも損なわれることになる。仕事やプライベートでインターネットを使ううち使用するアカウントとパスワードは年々増える傾向にある。つまり、便利だと思っていたパスワードのみの認証も実は煩雑で便利ではなくなってしまっている。

問題の本質は、パスワード等の認証情報をインターネットに晒さしてしまうことである。また、２要素認証を用いたとしても、上述したようにフィッシング攻撃に対してはほぼ無力である。

このような状況を鑑み、パスワードによる認証に代わって生体認証などの新たな認証技術を普及させることが考えられている。たとえば、スマートフォンの顔認証や指紋認証などがそれである。スマートフォンは既に普及したインフラであり、この方法は付加的なセキュリティデバイスを持ち歩かなくてよい。パスワードを覚えなくて良ければさらに利便性が高くなる。不用意にどこかに記録しておいたパスワードが流出する心配もない。

具体的には、ユーザーの手の内にある通信端末は、有線無線を問わず何等かの通信線によってサーバーに接続されている。該通信線はインターネットの一部を構成しており、ユーザーは、通信端末（たとえばスマートフォン等）を有し、正規のサーバーの運営者は所定のアプリを配布する。ユーザーが通信端末にこのアプリをインストールし、このアプリ上でアカウントを生成し、サーバーはこのアカウントを登録しておく。このアプリには、あらかじめ公開鍵が含められており、この公開鍵に対応する秘密鍵はサーバーに保管されている。アカウントを登録する際、サーバーは通信端末を通じてユーザーに生体認証の入力を促す。通信端末のアプリは、一例として、通信端末に搭載されているカメラを用いてユーザーの顔から生体認証コードを生成する。あるいは、別の一例として、ユーザーが通信端末のタッチパネルに指で触れることによってユーザーの指紋から生体認証コードを生成する。あるいは、生体認証を生成するために、通信端末とは別に生体認証センサーを通信端末に接続して使用することもできる。こうした生体認証センサーは、ユーザーの生体認証をセンスし生体認証コードを生成するために使われる。生体認証センサーは、ブルートゥース、USB、LAN、WiFi等何らかの通信手段で通信端末と接続し、通信端末に生体認証コードに関する情報を渡すことが可能である。通信端末は、こうして生体認証から生成した生体認証コードを、前記公開鍵を用いて暗号化し、生体暗号コードを生成する。あるいは、生体認証センサーが前記公開鍵を使って生体認証コードから生体暗号コードを生成することも可能である。この場合生体認証センサーから通信端末に生体暗号コードが提供されることになる。いずれにしろ、通信端末は、この生体暗号コードを、インターネットを通じてサーバーに転送する。サーバーは、前記秘密鍵で受け取った生体暗号コードを使って復号し、ユーザーの通信端末で取得した生体認証から生成した生体認証コードを安全に受信し保管することができる。

もし通信端末側に生体認証から生成した生体認証コード等の認証情報を保存しておくとハッキングによって生体認証コードが流出する危険性がある。よってセキュリティリソースの限られた通信端末や生体認証センサーに生体認証コードを保存するのは好ましくない。通信サーバーや生体認証センサーが扱った生体認証に関するあらゆるデータは使用後速やかに消去することが望ましい。

アカウント登録後、ユーザーがこのアプリを開くと、つまり、通信端末を使ってアカウントにサインインすると、通信端末（あるいはアプリ）が自動的にサーバーにアクセス許可を要求する。サーバーは通信端末を通じてユーザーに生体認証の入力を促す。通信端末のアプリは、一例として、通信端末に搭載されているカメラを用いてユーザーの顔から生体認証コードを生成する。あるいは、別の一例として、ユーザーが通信端末のタッチパネルに指で触れることによってユーザーの指紋から生体認証コードを生成する。あるいは、更に別の一例として、生体認証センサーが読み取ったデータから生体認証コードを生成する。通信端末は、こうして生体認証から生成した生体認証コードを、前記公開鍵を用いて暗号化し生体暗号コードを生成する。通信端末は、この生体暗号コードを、インターネットを通じてサーバーに転送する。サーバーは、受け取った生体暗号コードを前記秘密鍵で復号し生体認証コードを受信する。それを保存してあった生体認証コードと比較し、一致していると認められればアクセスを許可する。

確かに生体認証を用いることによって利便性もセキュリティも向上しているように見える。しかしながら、フィッシングによる脆弱性はまだ残っている。

たとえば、ハッカーはフィッシング用のアプリ（ハッキングアプリ）を開発し、インターネット上で配布することができる。ハッカーは、さらにハッキング用のサーバー（ハッキングサーバー）を運営している。ユーザーが通信端末（たとえばスマートフォン）にこのハッキングアプリをインストールし、アプリ上でアカウントを生成する。ハッキングサーバーはこのアカウントを登録しておく。このアプリには、あらかじめ公開鍵が含められており、この公開鍵に対応する秘密鍵はハッキングサーバーに保管されている。アカウントを登録する際、ハッキングサーバーは通信端末を通じてユーザーに生体認証の入力を促す。通信端末のアプリは、一例として、通信端末に搭載されているカメラを用いてユーザーの顔から生体認証コードを生成する。あるいは、別の一例として、ユーザーが通信端末のタッチパネルに指で触れることによってユーザーの指紋から生体認証コードを生成する。あるいは、更に別の一例として、生体認証センサーが読み取ったデータから生体認証コードを生成する。通信端末は、こうして生体認証から生成した生体認証コードを、前記公開鍵を用いて暗号化し生体暗号コードを生成する。通信端末は、この生体暗号コードを、インターネットを通じてハッキングサーバーに転送する。ハッキングサーバーは、受け取った生体暗号コードを前記秘密鍵で復号し、ユーザーの生体認証から生成した生体認証コードを保管する。こうしてハッカーは、正規のユーザーの生体認証コードを盗み取ることができる。

次にハッカーは、通常のフィッシング攻撃を仕掛けて正規のユーザーからアカウント情報（ユーザーＩＤやパスワード等）を盗むことができる。具体的には、ハッカーは、正規サーバーの保守管理者を装い、正規ユーザーに定期メンテナンスを促す電子メールを送付する。電子メールにはハッキングサイトを開くためのリンクが添付してあり、正規ユーザーが注意深くなければ、リンクを開きハッキングサイトに導かれる。そこでの指示に従い、ユーザーアID、パスワード、２要素認証等を入力し、ハッカーにアカウント情報（ユーザーＩＤやパスワード等）を盗み取られる。

さらにハッカーは、正規のサーバーが配布するアプリを自らの通信端末（たとえばスマートフォン等）にインストールし、このアプリ上で正規のユーザーの認証情報（ユーザーＩＤ、パスワード、２要素認証等）と、さらに、上述した方法で盗み取った生体認証コードを用い、正規のユーザーに成りすまして正規のサーバーにアクセスすることができる。

図２は、上述した、従来のオンライン認証（通信認証、あるいは単に認証）の仕組みの基本的構成の一例を説明する図面である。

ユーザー（User）は、通信端末（Communication Terminal）を有しており、ユーザーはこの通信端末のインターフェースを通じてユーザーID（User-ID）、パスワード（Password）、2要素認証（TFA）,生体認証（Biometrics Authentication）等のオンライン認証に関する認証データを通信端末に入力することができる。スマートカードのような付加的なセキュリティデバイス（Add Sec. Dev.）は利便性を損なうので使用しないことが望ましい。そのかわり、2要素認証（TFA）や生体認証（Biometrics Authentication）を用いることが望ましいと信じられている。利便性を考えると、通信端末は、2要素認証や生体認証の機能を有することが望ましい。最近のスマートフォンは既にそのような機能を兼ね備えている。

この通信端末は、インターネットを通じてサーバーに接続し、暗号技術（Encryption）、仮想閉域網（ＶＰＮ）、電子署名（Digital Signature）等の技術を用いて、ユーザーが入力した認証データを安全にサーバーに転送することができると信じられている。

しかしながら、上述したように、実際にユーザーが認証情報（ユーザーID、パスワード、２要素認証、生体認証等）を入力するのは、サーバーが通信端末に指示して通信端末のディスプレー上に表示されたインターフェース（Website）である。もしこのWebsiteが、ハッカーがフィッシング用に設置したハッキングサイトであった場合、たとえ暗号化してあったとしても、たとえVPNで通信を傍受されないようにしていたとしても、たとえ電子署名がついていたとしても、暗号化された認証情報はハッカーの手に渡る。

この暗号化には、通常公開鍵暗号を用いられる。すなわち、通信端末にインストールされるアプリには公開鍵が添付されており、この公開鍵が盗まれない限り、たとえ暗号化された認証コードのみ盗まれたとしても安全であると信じられている。

しかしながら、ハッカーは、上述したように、ハッキングアプリを配布して公開鍵を配布している。この公開鍵を使って暗号化され、ハッカーの手に渡った暗号化された認証情報は、もともとハッカーが所有している秘密鍵を使って復号できる。こうして、ハッカーは平文の状態で認証コードを盗むことが可能である。

フィッシングに対する脆弱性の根本原因は、従来のオンライン認証の基本的な仕組みに依存する。すなわち、従来のオンライン認証では、認証する主体はサーバーであり、認証されるのは通信端末である。パスワード、パスワードと2要素認証の併用、さらにスマートカードの認証や生体認証などを併用し、いかにユーザーと通信端末の間の脆弱性を取り除いたとしても、フィッシング攻撃にはほぼ無力である。

本発明は上記事情を鑑みて成されたものであり、付加的なセキュリティデバイスを用いることなく、パスワードをインターネットに晒さず、フィッシングに強いオンライン認証を構築するためのシステムプロトコル技術、を提供することを目的とする。

本発明は、上記課題を解決するため、以下の手段を採用する。
本発明が提案する解決手段は、

ネットワーク上で互いに接続している第１および第２の電子機器と、前記第１の電子機器を操る第１のユーザーと、を構成要素とし、

前記第１の電子機器は、第１の特殊コードを有し、
前記第１の特殊コードは、前記第１の電子機器に閉じ込められており、

前記第２の電子機器は、第２の特殊コードを有し、
前記第２の特殊コードは、前記第２の電子機器に閉じ込められており、

前記第１の電子機器は、前記第１のユーザーから第１の入力を受け取り、前記第２の電子機器から、第２の入力を受け取り、

前記第１および第２の入力と、前記第１の特殊コードと、から、第２の中間コードを生成し、

前記第１の電子機器は、前記第２の中間コードを、前記第２の電子機器に送り、

前記第２の電子機器は、第３の関数を用い、前記第２の特殊コードと、前記第２の中間コードと、から、第１の比較コードを生成し、

前記第１の電子機器は、前記第１１のユーザーから第１１の入力を受け取り、

前記第１１および第２の入力と、前記第一の特殊コードと、から、第１２の中間コードを生成し、

前記第１の電子機器は、前記第１２の中間コードを、前記第２の電子機器に送り、

前記第２の電子機器は、前記第３の関数を用い、前記第２の特殊コードと、前記第１２の中間コードと、から、第１１の比較コードを生成し、

前記第１１の比較コードと、前記第１の比較コードと、を比較する、


ことを特徴とする。

本発明が提案する解決手段は、更に次の手段を有する。

更に、第２１の電子機器が存在し、

前記第２１の電子機器は、第２１の特殊コードを有し、
前記第２１の特殊コードは、前記第２１の電子機器に閉じ込められており、

前記第２１の電子機器が、前記第１のユーザーから前記第１の入力を受け取り、前記第２の電子機器から、前記第２の入力を受け取り、

前記第１および第２の入力と、前記第２１の特殊コードと、から、第２２の中間コードを生成し、

前記第２１の電子機器は、前記第２２の中間コードを、前記第２の電子機器に送り、

前記第２の電子機器は、前記第３の関数を用い、前記第２の特殊コードと、前記第２２の中間コードと、から、第２１の比較コードを生成し、

前記第２１の比較コードと、前記第１の比較コードと、を比較する、

ことを特徴とする。

本発明が提案する解決手段は、更に次の手段を有する。

第４の関数を用いて、前記第１の入力と、前記第１の特殊コードと、から、第３の中間コードを生成し、

前記第１の電子機器が、前記第３の中間コードを、前記第２の電子機器に送り、

第５の関数を用いて、前記第３の中間コードと、前記第２の特殊コードと、から、第４の中間コードを生成し、

前記第２の電子機器は、前記第４の中間コードを、前記第１の電子機器に送り、

第６の関数を用いて、前記第４の中間コードと、前記第１の特殊コードと、から、第３の比較コードを生成し、

更に、第３１の電子機器が存在し、

前記第３１の電子機器は、第３１の特殊コードを有し、
前記第３１の特殊コードは、前記第３１の電子機器に閉じ込められており、

前記第１の電子機器が、前記第３の中間コードを、前記第３１の電子機器に送り、

前記第５の関数を用いて、前記第３の中間コードと、前記第３１の特殊コードと、から、第５の中間コードを生成し、

前記第３１の電子機器は、前記第５の中間コードを、前記第１の電子機器に送り、

前記第６の関数を用いて、前記第５の中間コードと、前記第１の特殊コードと、から、第３１の比較コードを生成し、

前記第３１の比較コードと、前記第３の比較コードと、を比較する、

ことを特徴とする。

以下、発明を実施するための最良の形態について、具体的に説明する。

上述してきたように、本願では、インターネット（ネットワーク）上に晒さず、ユーザーとユーザーが利用する正規の通信端末（あるいは通信デバイス、あるいは単にデバイス）との間のみで使用する、“局所認証コード”という概念を導入し、それを用いたオンライン認証方法を提案する。さらに通信端末もサーバーを認証する“相互認証”を取り入れることによって、フィッシング耐性を高める工夫を併用する。

以下図面を用いて具体的に説明してゆく。

（インターネット上での通信の３要素）
一般に、インターネット、あるいは、ネットワーク上で、オンライン認証システムは３つの基本要素（ユーザー、通信端末、サーバー）により構成されている。にもかかわらず、従来のオンライン認証方法では、ユーザーと通信端末の間、および、通信端末とサーバーの間、の通信のセキュリティを個別に設計してきた。つまり、ユーザーと通信端末の間のセキュリティは、パスワード、２要素認証、スマートカード等の付加的セキュリティデバイス、生体認証等によって設計されているのに対して、通信端末とサーバーの間のセキュリティは、暗号、VPN、電子署名等が採用されている。両者の間には統合された技術的関連性が希薄である。これは、インターフェースの違いに由来すると考えられる。ユーザーと通信端末の間には、人間と電子機器の相互連関を司るヒューマンインターフェース（カメラ、スピーカー、ディスプレー、タッチパネル、マウス、キーボード、および各種センサー等）が必要であり、それは、互いに電子機器である通信端末とサーバー間のインターフェースとは技術的にかなり異なっている。

（通信デバイスの登録）
図３は、本願のオンライン認証における、通信端末（通信デバイス）の登録方法の一例を説明する図面である。まず、ユーザー（User-1）と、通信デバイス（Device-2）と、サーバー（Server-3）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた（束縛された）特殊コード（DBC2）がある。サーバーには、サーバーに閉じ込められた（束縛された）特殊コード（SBC３）がある。

通信デバイスとサーバーの双方に閉じ込められた特殊コードが存在するのは、本願の特徴である相互認証に必須の条件である。従来例のように、サーバーが通信デバイスを認証するのみであれば、SBC３は特に必要なかった。

ある種のコードを機器内部に閉じ込める（束縛する）には、そのコードが存在する領域を外部I/Oから遮断するか、あるいは、より厳密にはPhysically－Unclonable Function （PUF）を使うことが望ましい。いずれにしろ、特殊コードの盗難には何らかの処置が必要である。その一例を後述する。

ユーザー（User-1）が通信デバイス（Device-2）上のアプリを開くと（Open appli.）、通信デバイスがサーバー（Server-3）に通信デバイスの登録を要求する（Request auth）。サーバーはこの要求に応じてチャレンジ（Challenge）C0を通信デバイスに返す。通信デバイスは、別途パスワード等の認証コードの入力をユーザーに要求する。ユーザーはこの要求に応じて局所認証コード(Local auth code)PL1を通信デバイスに入力する。通信デバイス内部では、C0とPL1から同期コードSC01を生成する。SC01生成後通信デバイスからC0は消去することが望ましい。同期コードとは、ユーザーが使用するほかの通信デバイスと同期可能であるコードのことである。

同期コードを生成するには関数faを用いることができる。前記C0とPL1は引数としてfaに渡され、その関数値が中間コードでもあるSC01となる。よって下記の方程式が成り立つ。

SC01 ＝ fa（C０、PL1）

続いて通信デバイス内部では、関数fbを用いてSC01とDBC2からレスポンスR012を生成する。前記SC01とDBC2は引数としてfbに渡され、その関数値が中間コードでもあるR012である。よって下記の方程式が成り立つ。

R012 ＝ fb（SC01、DBC2）

通信デバイスは、このR012をサーバーに送信し、送信後通信デバイスからR012を消去することが望ましい。サーバー内部では、関数fcを用いてR012とSBC3から比較コードQ0123を生成する。前記R012とSBC3は引数としてfcに渡され、その関数値が比較コードQ0123である。よって下記の方程式が成り立つ。

Q0123 ＝ fc（R012、SBC3）

サーバーは、C0とQ0123をサーバー内部の安全な領域に保存する（Store (C0, Q0123)）。こうして正規のユーザー（user-1）が利用する通信デバイス（Device-2）のサーバー（Server-3）への登録が完了する。ここで、通信デバイス（Device-2）がサーバーに送ったのはR012であり、PL1ではない。つまり、PL1はユーザー（User-1）と通信デバイス（Device-2）の間でのみやり取りされる、局所認証コードである。

（ユーザーの認証）
図４は、本願のオンライン認証における、ユーザーの認証方法の一例を説明する図面である。まず、ユーザー（User-1’）と、通信デバイス（Device-2）と、サーバー（Server-3）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３）がある。特殊コードの説明は登録のときと同様なので以下省略する。

ユーザーが通信デバイス上のアプリを開くと（Open appli.）、通信デバイスがサーバーに通信デバイスの認証を要求する（Request auth）。サーバーはこの要求に応じてチャレンジ（Challenge）C0を通信デバイスに返す。通信デバイスは、別途パスワードの入力をユーザーに要求する(Request Password)。ユーザーはこの要求に応じて局所認証コード（Local auth code）PL1’を通信デバイスに入力する。通信デバイス内部では、通信デバイスの登録時と同じ関数faを用いてC0とPL1’から同期コードSC01’を生成し、生成後C0は通信デバイスから消去することが望ましい。同期コードとは、ユーザーが使用するほかの通信デバイスと同期可能であるコードのことである。前記C0とPL1’は引数としてfaに渡され、その関数値が中間コードでもあるSC01’となる。よって次の方程式が成り立つ。

SC01’ ＝ fa（C０、PL1’）

続いて通信デバイス内部では、通信デバイスの登録時と同じ関数fbを用いてSC01’とDBC2からレスポンスR01’2を生成する。前記SC01’とDBC2は引数としてfbに渡され、その関数値が中間コードでもあるR01’2である。よって下記の方程式が成り立つ。

R01’2 ＝ fb（SC01’、DBC2）

通信デバイスは、このR01’2をサーバーに送し、送信後R01’2を通信デバイスから消去することが望ましい。サーバー内部では、通信デバイスの登録時と同じ関数fcを用いてR01’2とSBC3から比較コードQ01’23を生成する。前記R01’2とSBC3は引数としてfcに渡され、その関数値が比較コードQ01’23である。よって下記の方程式が成り立つ。

Q01’23 ＝ fc（R01’2、SBC3）

こうして生成した比較コードQ01’23を、登録時にサーバー側に保存しておいた比較コードQ0123と比較する（Compare Q01’2 with Q0123）。一致していればこのユーザー（User-1’）は正規のユーザー（User-1）と同一であると認識され、通信デバイス（Device-2）からサーバーへのユーザー（User-1’）のアクセスが許可される(Permitted if Q01’23 = Q0123)。一致していなければ許可されない。ここで、通信デバイス（Device-2）がサーバーに送ったのはR01’2であり、PL1’ではない。つまり、PL1’はユーザー（User-1’）と通信デバイス（Device-2）の間でのみ局所的にやり取りされる、局所認証コード(Local auth code)である。

（通信デバイスの認証）
図５は、本願のオンライン認証における、通信デバイスの認証方法の一例を説明する図面である。まず、ユーザー（User-1）と、通信デバイス（Device-2’）と、サーバー（Server-3）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2’）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３）がある。特殊コードの説明は登録のときと同様なので以下省略する。

ユーザーが通信デバイス上のアプリを開くと（Open appli.）、通信デバイスがサーバーに通信デバイスの認証を要求する（Request auth）。サーバーはこの要求に応じてチャレンジ（Challenge）C0を通信デバイスに返す。通信デバイスは、別途パスワードの入力をユーザーに要求する(Request Password)。ユーザーはこの要求に応じて局所認証コード(Local auth code)PL1を通信デバイスに入力する。通信デバイス内部では、通信デバイスの登録時と同じ関数faを用いてC0とPL1から同期コードSC01を生成し、生成後C0は通信デバイスから消去することが望ましい。同期コードとは、ユーザーが使用するほかの通信デバイスと同期可能であるコードのことである。前記C0とPL1は引数としてfaに渡され、その関数値が中間コードでもあるSC01となる。よって次の方程式が成り立つ。

SC01 ＝ fa（C０、PL1）

続いて通信デバイス内部では、通信デバイスの登録時と同じ関数fbを用いてSC01とDBC2’からレスポンスR012’を生成する。前記SC01とDBC2’は引数としてfbに渡され、その関数値が中間コードでもあるR012’である。よって下記の方程式が成り立つ。

R012’ ＝ fb（SC01、DBC2’）

通信デバイスは、このR012’をサーバーに送信し、送信後通信デバイスからR012’を消去することが望ましい。サーバー内部では、通信デバイスの登録時と同じ関数fcを用いてR012’とSBC3から比較コードQ012’3を生成する。前記R012’とSBC3は引数としてfcに渡され、その関数値が比較コードQ012’3である。よって下記の方程式が成り立つ。

Q012’3 ＝ fc（R012’、SBC3）

こうして生成した比較コードQ012’3を、登録時に保存しておいた比較コードQ0123と比較する(Compare Q012’3 with Q0123)。一致していると認められればこの通信デバイス（Device-2’）は正規の通信デバイス（Device-2）と同一であると認識され、通信デバイス（Device-2）からサーバーへのアクセスが許可される(Permitted if Q012’3 = Q0123)。一致していなければ許可されない。ここで、通信デバイス（Device-2）がサーバーに送ったのはR012’であり、PL1ではない。つまり、PL1はユーザー（User-1）と通信デバイス（Device-2）の間でのみ局所的にやり取りされる、局所認証コード(Local auth code)である。

（ユーザーおよび通信デバイスの認証）
サーバー側では、認証する以前にアクセスを求められても、そのユーザーと通信デバイスのどちらか一方が正規のものであるかどうかわからない場合がある。このような場合、どちらも正規かどうかわからないまま認証作業を行わなければならない。本願ではそのような場合にも十分に対応できる。

図６は、本願のオンライン認証における、ユーザーおよび通信デバイスの認証方法の一例を説明する図面である。まず、ユーザー（User-1’）と、通信デバイス（Device-2’）と、サーバー（Server-3）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2’）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３）がある。特殊コードの説明は登録のときと同様なので以下省略する。

ユーザーが通信デバイス上のアプリを開くと（Open appli.）、通信デバイスがサーバーに通信デバイスの認証を要求する（Request auth）。サーバーはこの要求に応じてチャレンジ（Challenge）C0を通信デバイスに返す。通信デバイスは、別途パスワードの入力をユーザーに要求する（Request Password）。ユーザーはこの要求に応じて局所認証コード(Local auth code)PL1’を通信デバイスに入力する。通信デバイス内部では、通信デバイスの登録時と同じ関数faを用いてC0とPL1’から同期コードSC01’を生成し、生成後C0は通信デバイスから消去することが望ましい。同期コードとは、ユーザーが使用するほかの通信デバイスと同期可能であるコードのことである。前記C0とPL1’は引数としてfaに渡され、その関数値が中間コードでもあるSC01’となる。よって次の方程式が成り立つ。

SC01’ ＝ fa（C０、PL1’）

続いて通信デバイス内部では、通信デバイスの登録時と同じ関数fbを用いてSC01’とDBC2’からレスポンスR01’2’を生成する。前記SC01’とDBC2’は引数としてfbに渡され、その関数値が中間コードでもあるR01’2’である。よって下記の方程式が成り立つ。

R01’2’ ＝ fb（SC01’、DBC2’）

通信デバイスは、このR01’2’をサーバーに送信し、送信後通信デバイスからR01’2’を消去することが望ましい。サーバー内部では、通信デバイスの登録時と同じ関数fcを用いてR01’2’とSBC3から比較コードQ01’2’3を生成する。前記R01’2’とSBC3は引数としてfcに渡され、その関数値が比較コードQ01’2’3である。よって下記の方程式が成り立つ。

Q01’2’3 ＝ fc（R01’2’、SBC3）

こうして生成した比較コードQ01’2’3を、登録時に保存しておいた比較コードQ0123と比較する(Compare Q01’2’3 with Q)。一致していると認められればこのユーザー（User-2’）と通信デバイス（Device-2’）が正規のユーザー（User-2）と通信デバイス（Device-2）と同一であると認識され、通信デバイス（Device-2’）からユーザー（User-1’）のサーバーへのアクセスが許可される(Permitted if Q01’2’3 = Q0123)。一致していなければ許可されない。ここで、通信デバイス（Device-2）がサーバーに送ったのはR01’2’であり、PL1’ではない。つまり、PL1’はユーザー（User-1’）と通信デバイス（Device-2’）の間でのみ局所的にやり取りされる、局所認証コード(Local auth code)である。

（特殊コード）
上述したように、特殊コードの盗難はシステムの脆弱性の要因になりうる。そこでデバイス認証モジュール（Device Identification module）を使って特殊コードの盗難を防ぐ方法について説明する。

図７は、特殊コード盗難防止方法の一例を示す図面である。

デバイス認証モジュールは、入力CXを受け付け、内部コードＤＸを有し、出力RXを出力する装置である。内部コードは、該デバイス認証モジュールを搭載する通信端末（Communication Terminal）、あるいは、サーバー(Server)等の通信用ハードウェアに固有のコードであり、PUFなどで実現することが可能である。たとえば、前記通信端末がDevice-2であれば内部コードはDX2となり、前記サーバーがServer-3であれば内部コードはDX3となり、Device-2とServer-3が異なるハードウェアである限り、たとえ共通の入力CXを受け付けたとしてもDX2とDX３は異なるコードとなる。もちろん、Device-2とServer-3が、それぞれ異なる入力（たとえば互いに異なるCX2とCX3）を受け作ることも可能である。いずれにしろ一般的に、内部コードＤＸと入力ＣＸから、ＲＸを生成する関数ｆｄを考える。すなわち、下記の方程式が成り立つものとする。

ＲＸ ＝ fｄ（ＣＸ、ＤＸ）

ＰＵＦもｆｄの機能を満たす実施形態の一つである。デバイス認証モジュールが通信デバイス（Device-2）に搭載されている場合、入力ＣＸは、デバイス認証モジュールの外部実体（External Entity）から与えられる。一般に、このような外部実体は、通信デバイス（Device-2）と接続可能であればなんでも良い。この接続は、恒久的な接続の場合と一時的な接続の場合のどちらも可能である。たとえば、通信デバイス（Device-2）に搭載されているデバイス認証モジュールの外部実体とは、サーバー（Server-3）、ユーザー（User-1）、通信デバイス（Device-2）の保守管理に関係のあるもの、あるいは、その他第三の実態である。いずれにしろ、出力RXが特殊コードDBC2の役割を担う。そしてRX生成後、通信デバイス（Device-2）側では、受信した入力CXを消去することが望ましい。DXとともにCXがハッカーに奪取されれば特殊コードを通信デバイスに閉じ込める（束縛する）ことができなくなる可能性があるからである。

デバイス認証モジュールがサーバー（Server-3）に搭載されている場合、入力ＣＸは、デバイス認証モジュールの外部実体（External Entity）から与えられる。一般に、このような外部実体は、サーバー（Server-3）と接続可能であればなんでも良い。この接続は、恒久的な接続の場合と一時的な接続の場合のどちらも可能である。たとえば、サーバー（Server-3）に搭載されているデバイス認証モジュールの外部実体とは、通信デバイス（Device-2）、ユーザー（User-1）、サーバー（Server-3）の保守管理に関係のあるもの、あるいは、その他第三の実態である。いずれにしろ、出力RXが特殊コードSBC3の役割を担う。そしてRX生成後、サーバー（Server-3）側では、受信した入力CXを消去することが望ましい。DXとともにCXがハッカーに奪取されれば特殊コードをサーバーに閉じ込める（束縛する）ことができなくなる可能性があるからである。

何らかの方法でハッカーがDXを盗み出すことに成功したとする。この時点で、DXは通信デバイスあるいはサーバーに閉じ込められていないことになる。しかしながら、仮にハッカーがDXの奪取に成功したとしても、DXは特殊コードではない。入力CXを知らなければDXから特殊コードを再生することは不可能である。したがって、運用上この方法によって特殊コードを通信デバイスあるいはサーバーに閉じ込める（束縛する）ことが可能となる。また、CXを換えれば特殊コードを更新することも可能である。つまり、システム管理者の都合により特殊コードを外から更新することが可能である。特殊コードの更新はサーバーのメンテナンスや通信デバイスのソフトウェアアップデートの時などに行うことが望ましい。また、特殊コードを更新する際、通信デバイスやサーバーの登録もやり直すことが望ましい。

（フィッシング対策）
上述したように、フィッシングに対する脆弱性の根本原因は、従来のオンライン認証の基本的な仕組みに存在する。すなわち、従来のオンライン認証では、認証する主体はサーバーであり、認証されるのは通信端末（通信デバイス）あるいはユーザーである。パスワード、パスワードと2要素認証の併用、さらにスマートカードの認証や生体認証などを併用し、いかにユーザーと通信端末の間の脆弱性を取り除いたとしても、フィッシング攻撃にはほぼ無力である。

（サーバーの登録）
本発明は上記事情を鑑みて成されたものであり、サーバーが通信端末（通信デバイス）を認証するのみではなく、通信端末（通信デバイス）もサーバーを認証する、相互認証システムプロトコルを採用する。

本願の相互認証システムでは、通信デバイス(Device-2)がサーバー（Server-3）を認証するため、あらかじめ特殊コードSBC3をサーバーに閉じ込めてある。図８は、本願が採用する相互認証におけるサーバーの登録の一例を説明する図面である。

まず、ユーザー（User-1）と、通信デバイス（Device-2）と、サーバー（Server-3）とから構成されるオンライン相互認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３）がある。

ユーザー（User-1）は、局所認証コード(Local auth code)PL1を送るとともに通信デバイス（Device-2）にサーバー（Server-3）を登録するよう指示を出すことができる（Instruction with “local” password (PL1)）。通信デバイス（Device-2）では、関数feを使用し、受信したPL1と特殊コードDBC2から中間コードC12を生成する。前記PL1とDBC2は引数としてfeに渡され、その関数値がC12となる。よって次の方程式が成り立つ。

C12 ＝ fe（PL1、DBC2）

通信デバイス（Device-2）は、このC12をチャレンジとしてサーバー（Server-3）に送信する。サーバー（Server-3）ではC12を入力として受け取り、特殊コードSBC3と関数ffを用いて、レスポンスR123を生成する。前記C12とSBC3は引数としてffに渡され、その関数値が中間コードでもあるR123となる。よって次の方程式が成り立つ。

R123 ＝ ff（C12、SBC3）

サーバー（Server-3）は、R123をレスポンスとして通信デバイス（Device-2）に返信し、通信デバイス（Device-2）では、このR123と特殊コードDBC2と関数fgを用いて比較コードQ123を生成する。前記R123とDBC2は引数としてfｇに渡され、その関数値が比較コードQ123となる。よって次の方程式が成り立つ。

Ｑ123 ＝ fg（R123、DBC2）

あるいは、システム仕様に応じてDBC2の代わりにC12を引数として利用することも可能である。この場合次の方程式を利用することも可能である。

Ｑ123 ＝ fg（R123、C12）

いずれにしろ、通信デバイス（Device-2）は、このQ123を内部の出来る限り安全な領域に保管する。正規のユーザー（User-1）がアクセスするサーバーとそのアクセスに利用する通信デバイスを一意に決めている場合PL1もC12も通信デバイス（Device-2）の内部に保存する必要はなく、内部での使用が済んだ後消去することが望ましい。Q123を、PL1あるいはC12と共にセットとして保存する場合、同じ通信デバイスを複数のアカウントで利用することが可能である。あるいは、アクセスするサーバーごとに局所認証コード(Local auth code)を変更して複数のサーバーを通信デバイスに登録することが可能である。図８では、PL1とQ123をセットで保管する例である（Store(PL1, Q123)）。つまり、Store(PL1, Q123)をStore(C12, Q123)やStore(Q123)に変更することも可能である。いずれにしろ、少なくともQ123を通信デバイス（Device-2）に保管することに他ならない。

サーバー（Server-3）では、R123を送信後、R123を消去することが望ましい。こうして正規のユーザー（user-1）が利用するサーバー（Server-3）の通信デバイス（Device-2）への登録が完了する。ここで、通信デバイス（Device-2）がサーバーに送ったのはC12のみであり、PL1ではない。つまり、PL1はユーザー（User-1）と通信デバイス（Device-2）の間でのみ局所的にやり取りされる、局所認証コード(Local auth code)である。

（サーバーの認証）
図９は、本願が採用する相互認証におけるサーバーの認証の一例を説明する図面である。

まず、ユーザー（User-1）と、通信デバイス（Device-2）と、認証されるサーバー（Server-3’）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３’）がある。

ユーザー（User-1）は、局所認証コード(Local auth code)PL1を送ることによって通信デバイス（Device-2）にサーバー（Server-3’）の認証検査をするよう指示を出すことができる（Instruction with “local” password (PL1)）。通信デバイス（Device-2）では、サーバー登録時と同じ関数feを使用し、受信したPL1と特殊コードDBC2から中間コードC12を生成する。前記PL1とDBC2は引数としてfeに渡され、その関数値がC12となる。よって次の方程式が成り立つ。

C12 ＝ fe（PL1、DBC2）

通信デバイス（Device-2）は、このC12をチャレンジとしてサーバー（Server-3’）に送信する。サーバー（Server-3’）ではC12を入力として受け取り、特殊コードSBC3’と、サーバー登録時と同じ関数ffを用いて、レスポンスR123’を生成する。前記C12とSBC3’は引数としてffに渡され、その関数値が中間コードでもあるR123’となる。よって次の方程式が成り立つ。

R123’ ＝ ff（C12、SBC3’）

サーバー（Server-3’）は、R123’をレスポンスとして通信デバイス（Device-2）に返信し、通信デバイス（Device-2）では、このR123’と特殊コードDBC2と、サーバー登録時と同じ関数fgを用いて比較コードQ123’を生成する。前記R123’とDBC2は引数としてfｇに渡され、その関数値が比較コードQ123’となる。よって次の方程式が成り立つ。

Ｑ123’ ＝ fg（R123’、DBC2）

あるいは、システム仕様に応じてDBC2の代わりにC12を引数として利用することも可能である。この場合次の方程式を利用することも可能である。

Ｑ123’ ＝ fg（R123’、C12）

いずれにしろ通信デバイス（Device-2）側では、このQ123’を、管理下に保管したQ123と比較し（Compare Q123’ with Q123）、もし一致しているとみなされたらこのサーバー（Server-3’）は正規のサーバー（Server-3）と同一であると認証される（Permitted if Q123’ = Q123）。このとき、ユーザー（User-1）は通信デバイス（Device-2）を通じてサーバー（Server-3）にアクセスすることが許される。Q123’とQ123が一致しなかったら、このサーバー（Server-3’）は正規のサーバーとみなされず、このサーバーへのアクセスは認められない。こうしてユーザー（User-1）をフィッシング攻撃から守ることが可能となる。

（サーバーおよびユーザーの認証）
図１０は、本願が採用する相互認証におけるサーバーの認証の一例を説明する図面である。

まず、ユーザー（User-1’）と、通信デバイス（Device-2）と、認証されるサーバー（Server-3’）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリがインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３’）がある。

ユーザー（User-1’）は、局所認証コード(Local auth code)PL1’を送ることによって通信デバイス（Device-2）にサーバー（Server-3’）の認証検査をするよう指示を出すことができる（Instruction with “local” password (PL1’)）。通信デバイス（Device-2）では、サーバー登録時と同じ関数feを使用し、受信したPL1’と特殊コードDBC2から中間コードC1’2を生成する。前記PL1’とDBC2は引数としてfeに渡され、その関数値が中間コードC1’2となる。よって次の方程式が成り立つ。

C1’2 ＝ fe（PL1’、DBC2）

通信デバイス（Device-2）は、このC1’2をチャレンジとしてサーバー（Server-3’）に送信する。サーバー（Server-3’）ではC1’2を入力として受け取り、特殊コードSBC3’と、サーバー登録時と同じ関数ffを用いて、レスポンスR1’23’を生成する。前記C1’2とSBC3’は引数としてffに渡され、その関数値が中間コードでもあるR1’23’となる。よって次の方程式が成り立つ。

R1’23’ ＝ ff（C1’2、SBC3’）

サーバー（Server-3’）は、R1’23’をレスポンスとして通信デバイス（Device-2）に返信し、通信デバイス（Device-2）では、このR1’23’と特殊コードDBC2と、サーバー登録時と同じ関数fgを用いて比較コードQ1’23’を生成する。前記R1’23’とDBC2は引数としてfｇに渡され、その関数値が比較コードQ1’23’となる。よって次の方程式が成り立つ。

Ｑ1’23’ ＝ fg（R1’23’、DBC2）

あるいは、システム仕様に応じてDBC2の代わりにC1’2を引数として利用することも可能である。よって次の方程式を利用することも可能である。

Ｑ1’23’ ＝ fg（R1’23’、C12）

いずれにしろ通信デバイス（Device-2）側では、このQ1’23’を、管理下に保管したQ123と比較し（Compare Q1’23’ with Q123）、もし一致していたら、このサーバー（Server-3’）は正規のサーバー（Server-3）であり、このユーザー（User-1’）も正規のユーザー（User-1）と同一であると認証される（Permitted if Q1’23’ = Q123）。このとき、ユーザー（User-1’）は通信デバイス（Device-2）を通じてサーバー（Server-3’）にアクセスすることができる。Q1’23’とQ123が一致しなかったら、このサーバー（Server-3’）は正規のサーバーとみなされず、このサーバーへのアクセスは認められない。こうしてフィッシング攻撃を未然に防ぐことが可能となる。

（局所認証用コード）
局所認証コード(Local auth code)は、ユーザーと通信端末の間のみでやりとりされる。したがって、局所認証用コード（Local Auth Code）がパスワードの場合、それは局所パスワードである。あるいは、局所認証用コード（Local Auth Code）は、ユーザーの生体情報（顔、指紋、静脈パターン、迷彩、声紋等）や音声情報を通信端末（Device-2 あるいは Device-2’）で読み取った情報を基にして生成した認証コードであり、ユーザーと通信端末の間のみでやりとりされる。あるいは、局所認証用コード（Local Auth Code）は、生体情報等を取得するためのセンサーを使って外部から取得した何らかの画像情報（バーコード、2次元コード、認証用の画像、認証用の映像等）、音声情報、数値情報等から生成した認証コードであり、前記センサーと通信端末の間のみでやりとりされる。あるいは、局所認証用コード（Local Auth Code）は、あらかじめ外部ストレージやカード等に予め保存して置いた認証用データから生成する認証コードであり、前記外部ストレージやカード等と、通信端末と、の間のみでやりとりされる。局所認証用コード（Local Auth Code）は、図３から図６、および、図８から図１０に示すように、インターネット上に晒さないこととする。

（相互認証）
本願に特徴的な相互認証をするには、まず相互登録が必要である。相互登録は、少なくとも、上述したような局所認証用コード（Local Auth Code）と、通信端末（Device-2）によるサーバー（Server-3）の登録（図８参照）と、サーバー（Server-3）による通信端末（Device-2）の登録（図３参照）と、からなることを特徴とする。図１１は、本願に特徴的な相互登録の一例を説明する図面である。局所認証用コードは２種類（PL1a、PL1b）利用されているが、この二つは同一（PL1a = PL1b）であっても構わない。通信端末（Device-2）に（PL1a、Q123）が保管されているが（Store (PL1a, Q123)）、上述したように、通信端末（Device-2）に保管するのは（C12、Q123）、あるいは、Q123のみでも構わない。その他詳細は、図３の説明および図８の説明から自明であるので省略する。こうして相互登録した後、たとえば図４から図６に示したような方法で、ユーザー（User-1’）や通信端末（Device-2’）の認証検査をすればよい。また、たとえば図１０に示したような方法で、サーバー（Server-3’）の認証検査をすればよい。

（認証装置）
本願の構成を用いれば、2要素認証用を置き換える認証装置（Authenticator）を提案することも可能である。図１２は、本願に特徴的な認証方法の一例を説明する図面である。

接続されるサーバーから見れば、アクセスを求めて来るユーザーも、ユーザーのために接続してくる通信デバイスも、認証検査しなければならない対称物である。

そこで、ユーザー（User-1’）と、通信デバイス（Device-2’）と、認証するサーバー（Server-3）とから構成されるオンライン認証システムを考える。通信デバイスには、事前に必要なアプリ（認証アプリ）がインストールしてあるとする。さらに、通信デバイスには、通信デバイスに閉じ込められた特殊コード（DBC2’）がある。サーバーには、サーバーに閉じ込められた特殊コード（SBC３）がある。ただし、デバイス（Device-2’）には、あらかじめ同期コードSC01’が登録されているものとする。サーバー（Server-3）には、事前に正規の比較コードQ0123が登録されているものとする。

まず、ユーザー(User-1’)が別の通信端末(Terminal、図面省略）を介してサーバー（Server-3）にアクセスの要求をする（Request access via terminal）。これに応じてサーバー（Server-3）は、通信端末（Terminal）を介してユーザーに認証番号（AN）を要求する（Request authentication number (AN) via terminal as Challenge）。ユーザー（User-1’）は、通信デバイス（Device-2’）の認証アプリを開く（Open authenticator）。

通信デバイス（Device-2’）では、関数fhを用いてSC01’とDBC2’からレスポンスR01’2’を生成する。前記SC01’とDBC2’は引数としてfhに渡され、その関数値が中間コードでもあるR01’2’である。よって下記の方程式が成り立つ。

R012 ＝ fh（SC01’、DBC2’）

ユーザー（User-1’）は、この通信デバイス（Device-2’）を通信端末（Terminal）に差し込むことによって、このR01’2’を認証番号（ANとして）サーバー（Server-3）に送信する。つまり、ANを、サーバー（Server-3）からユーザー（User-1‘）へのチャレンジ（Challenge）とみなせば、R01’2’は、ユーザー（User-1’）からサーバー（Server-3）へのレスポンス（Response）とみなせる。

サーバー（Server-3）では、関数fiを用いてこのR01’2’とSBC3から比較コードＱ01’2’3を生成する。前記R01’2’とSBC3は引数としてfiに渡され、その関数値が比較コードQ01’2’3である。よって下記の方程式が成り立つ。

Q01’2’3 ＝ fi（R01’2’、SBC3）

サーバー（Server-3）では、Q01’2’3を、事前に尊くしてあった正規の比較コードQ0123と比較する（Compare Q01’2’3 with Q0123）。もし一致していれば、ユーザー（User-1’）は、サーバー（Server-3）へのアクセスが承認される(Permitted if Q01’2’3 = Q0123)。

また、上述した実施形態では、通信デバイス側で同期コード（SC01、SC01’等）を生成していたが、この同期コードを生成しなくても本願の請求範囲を逸脱することはない。たとえば、局所認証用コード（PL1, PL1’, PL1a, PL1b等）と、チャレンジ（C0等）と、特殊コード（DBC2、DBC2’等）から、関数fjを用いてレスポンス（R012、R01’2、R012’、R01’2’等）を生成すれば良い。この場合、PL（局所認証用コードの総称）と、C（チャレンジの総称）と、DBC（特殊コードの総称）は、引数としてfｊに渡され、その関数値がレスポンス（総称としてR012）である。よって下記の方程式が成り立つ。

R012 ＝ fj（PL、C、DBC）

（特殊コードの利用）
図１３は、本願に関わる特殊コードの一例を説明する図面である。

デバイス（Device-2）は、内部コード（DX2）を有するデバイス認証モジュール（Device Identification module）を内部に搭載している。デバイス（Device-2）は、外部実体（External Entity-1）からチャレンジ（CX1）を受け取り、内部に搭載するデバイス認証モジュールに渡す。デバイス認証モジュールでは、このＤＸ２とＣＸ１から特殊コード（DBC2）を生成する。たとえば、このDX2とCX1を、関数fdに引数として渡し、関数値RX12を得る。デバイス（Device-2）は、このRX12を、DBC2として採用することが可能である。あるいは、このRX12を中間コードとし、適当に変換したコードをDBC2として採用することが可能である。一般に、外部実体（External Entity-1）は、通信デバイス（Device-2）と接続可能であればなんでも良い。この接続は、恒久的な接続の場合と一時的な接続の場合のどちらも可能である。たとえば、外部実体（External Entity-1）は、サーバー（Server-3）、ユーザー（User-1）、通信デバイス（Device-2）の保守管理に関係のあるもの、あるいは、その他第三の実態である。

サーバー（Server-3）は、内部コード（DX3）を有するデバイス認証モジュール（Device Identification module）を内部に搭載している。サーバー（Server-3）は、外部実体（External Entity-４）からチャレンジ（CX４）を受け取り、内部に搭載するデバイス認証モジュールに渡す。デバイス認証モジュールでは、このＤＸ３とＣＸ４から特殊コード（DBC3）を生成することが可能である。たとえば、このDX3とCX4を、関数fdに引数として渡し、関数値RX43を得る。サーバー（Server-3）は、このRX43を、DBC3として採用することが可能である。あるいは、このRX43を中間コードとし、適当に変換したコードをDBC3として採用することが可能である。一般に、外部実体（External Entity-4）は、サーバー（Server-3）と接続可能であればなんでも良い。この接続は、恒久的な接続の場合と一時的な接続の場合のどちらも可能である。たとえば、サーバー（Server-3）に搭載されているデバイス認証モジュールの外部実体とは、通信デバイス（Device-2）、ユーザー（User-1）、サーバー（Server-3）の保守管理に関係のあるもの、あるいは、その他第三の実態である。

前記DX2およびDX3等の内部コードは、デバイス認証モジュールを構成するICチップに起因する物理的乱雑さから生成することが望ましい。この物理的乱雑さはチップ毎に異なり、乱雑さの情報量は十分に大きく、任意の異なる二つのチップが同じ内部コードを有する可能性は非常に小さいことが望ましい。

あるいは、前記DX2およびDX3等の内部コードは、デバイス認証モジュールを構成するICチップに書き込まれたコードである。ただし、任意の異なる二つのチップの内部コードが一致する可能性は非常に小さいことが望ましい。

いずれにしろ、前記DX2およびDX3等の内部コードは、デバイス認証モジュールを構成するICチップ外部からのアクセスによって書き換えることが難しいことが望ましい。

以上、関数fa、fb、fc、fd、fe、ff、fg、fh、fi、fjを用いて説明してきた。この内どの二つの関数が同等であっても構わない。また、前記faからfjまでの関数の引数および出力（関数値）はいずれも中間コードあるいは比較コード等なにがしかのコードであり、例えば、局所認証用コード、チャレンジ、特殊コード、レスポンス、中間コード、入力チャレンジ、入力、出力、内部コード等のうちのどれかである。また、レスポンスが中間コードであることもある。前記関数とは、引数として入力の入力を受け付け、所定の変換後生成されるコードを出力するものであり、ソフトウェアでもハードウェアでも実現できる。

なお、本発明の技術範囲は上記の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲において種々の変更を加えることが可能である。

本願のユーザー認証方法は、スマートカード等の付加的なセキュリティデバイスを追加することなく、パスワード等の認証用コードをユーザーとユーザーが正規に利用する端末デバイスの間に閉じ込めることにより、パスワード等の認証用コードの流出の危険を抑えつつユーザーが使い慣れているインターフェースで安全にサーバーへの接続認証を行い、さらに、ユーザーが正規に利用する端末デバイスが正規に接続するサーバーを認証検査する相互認証を用いるため、フィッシング攻撃に対する耐性を獲得することが可能となる。

セキュリティ（Security）と利便性（Convenience）の相関関係の一例を説明する図。 従来のオンライン認証の一例を説明する図。 本願の通信デバイスの登録方法の一例を説明する図。 本願のユーザーの認証方法の一例を説明する図。 本願の通信デバイスの認証方法の一例を説明する図。 本願のユーザーおよび通信デバイスの認証方法の一例を説明する図。 特殊コード盗難防止方法の一例を説明する図。 本願が採用する相互認証におけるサーバーの登録の一例を説明する図。 本願が採用する相互認証におけるサーバーの認証の一例を説明する図。 本願が採用する相互認証におけるサーバーの認証の一例を説明する図。 本願が採用する相互登録の一例を説明する図。 本願に特徴的な認証装置の一例を説明する図。 本願に関わる特殊コードの一例を説明する図。

Claims (9)

1. ネットワーク上で互いに接続している第１および第２の電子機器と、前記第１の電子機器を操る第１のユーザーと、を構成要素とし、
   
   前記第１の電子機器は、第１の特殊コードを有し、
   前記第１の特殊コードは、前記第１の電子機器に閉じ込められており、
   
   前記第２の電子機器は、第２の特殊コードを有し、
   前記第２の特殊コードは、前記第２の電子機器に閉じ込められており、
   
   前記第１の電子機器は、前記第１のユーザーから第１の入力を受け取り、前記第２の電子機器から、第２の入力を受け取り、
   
   前記第１および第２の入力と、前記第１の特殊コードと、から、第２の中間コードを生成し、
   
   前記第１の電子機器は、前記第２の中間コードを、前記第２の電子機器に送り、
   
   前記第２の電子機器は、第３の関数を用い、前記第２の特殊コードと、前記第２の中間コードと、から、第１の比較コードを生成する、
   
   ことを特徴とするオンライン認証方法。
   
2. 第１の関数を用い、前記第１および第２の入力と、から、第１の中間コードを生成し、
   
   第２の関数を用い、前記第１の中間コードと、前記第１の特殊コードと、から、前記第２の中間コードを、生成する、
   
   ことを特徴とする、請求項１記載のオンライン認証方法。
   
3. 第１１のユーザーが存在し、
   
   前記第１の電子機器は、前記第１１のユーザーから第１１の入力を受け取り、
   
   前記第１１および第２の入力と、前記第一の特殊コードと、から、第１２の中間コードを生成し、
   
   前記第１の電子機器は、前記第１２の中間コードを、前記第２の電子機器に送り、
   
   前記第２の電子機器は、前記第３の関数を用い、前記第２の特殊コードと、前記第１２の中間コードと、から、第１１の比較コードを生成し、
   
   前記第１１の比較コードと、前記第１の比較コードと、を比較する、
   
   ことを特徴とする、請求項１記載のオンライン認証方法。
   
4. 前記第１の関数を用い、前記第１１および第２の入力と、から、第１１の中間コードを生成し、
   
   前記第２の関数を用い、前記第１１の中間コードと、前記第１の特殊コードと、から、前記第１２の中間コードを、生成する、
   
   ことを特徴とする、請求項３記載のオンライン認証方法。
   
5. 前記ネットワーク上に、第２１の電子機器が存在し、
   
   前記第２１の電子機器は、第２１の特殊コードを有し、
   前記第２１の特殊コードは、前記第２１の電子機器に閉じ込められており、
   
   前記第２１の電子機器が、前記第１のユーザーから前記第１の入力を受け取り、前記第２の電子機器から、前記第２の入力を受け取り、
   
   前記第１および第２の入力と、前記第２１の特殊コードと、から、第２２の中間コードを生成し、
   
   前記第２１の電子機器は、前記第２２の中間コードを、前記第２の電子機器に送り、
   
   前記第２の電子機器は、前記第３の関数を用い、前記第２の特殊コードと、前記第２２の中間コードと、から、第２１の比較コードを生成し、
   
   前記第２１の比較コードと、前記第１の比較コードと、を比較する、
   
   ことを特徴とする、請求項１記載のオンライン認証方法。
   
   
6. 前記第１の関数を用い、前記第１および第２の入力と、から、第２１の中間コードを生成し、
   
   前記第２の関数を用い、前記第２１の中間コードと、前記第２１の特殊コードと、から、前記第２２の中間コードを、生成する、
   
   ことを特徴とする、請求項５記載のオンライン認証方法。
   
   
7. 第４の関数を用いて、前記第１の入力と、前記第１の特殊コードと、から、第３の中間コードを生成し、
   
   前記第１の電子機器が、前記第３の中間コードを、前記第２の電子機器に送り、
   
   第５の関数を用いて、前記第３の中間コードと、前記第２の特殊コードと、から、第４の中間コードを生成し、
   
   前記第２の電子機器は、前記第４の中間コードを、前記第１の電子機器に送り、
   
   第６の関数を用いて、前記第４の中間コードと、前記第１の特殊コードと、から、第３の比較コードを生成する、
   
   ことを特徴とする、請求項１記載のオンライン認証方法。
   
8. 前記ネットワーク上に、第３１の電子機器が存在し、
   
   前記第３１の電子機器は、第３１の特殊コードを有し、
   前記第３１の特殊コードは、前記第３１の電子機器に閉じ込められており、
   
   前記第１の電子機器が、前記第３の中間コードを、前記第３１の電子機器に送り、
   
   前記第５の関数を用いて、前記第３の中間コードと、前記第３１の特殊コードと、から、第５の中間コードを生成し、
   
   前記第３１の電子機器は、前記第５の中間コードを、前記第１の電子機器に送り、
   
   前記第６の関数を用いて、前記第５の中間コードと、前記第１の特殊コードと、から、第３１の比較コードを生成し、
   
   前記第３１の比較コードと、前記第３の比較コードと、を比較する、
   
   ことを特徴とする、請求項７記載のオンライン認証方法。
   
9. 前記第１の電子機器は、第１のデバイス認証モジュールを有し、
   前記第１のデバイス認証モジュールは、第１の内部コードを有し、
   
   第１の外部実体が、前記第１のデバイス認証モジュールに、第１のチャレンジを入力し、
   前記第１の特殊コードは、前記第１のチャレンジと、前記第１の内部コードとから、生成され、
   
   前記第２の電子機器は、第２のデバイス認証モジュールを有し、
   前記第２のデバイス認証モジュールは、第２の内部コードを有し、
   
   第２の外部実体が、前記第２のデバイス認証モジュールに、第２のチャレンジを入力し、
   前記第２の特殊コードは、前記第２のチャレンジと、前記第２の内部コードとから、生成される、
   
   ことを特徴とする請求項１記載のオンライン認証方法。
   
   
   

Images