JP5184627B2 - コミュニケーション装置、認証システム及び方法、並びにキャリア媒体 - Google Patents

Description

一般に本発明はコミュニケーションシステムにおける識別又はパスワード認証に関する。特に本発明は１つまたはそれ以上のユーザー装置とコミュニケーションシステムとを有するシステムに関する。該コミュニケーションシステムは、サービスを提供するサーバーを含むことができる。そのようなシステムにおいてクライアント装置は、パスワードと他の安全手段とを用いて、該コミュニケーションシステムと共に認証を実行する。本発明は、トランザクションが個人対個人である他のサービスのユーザーを認証するのにも使用できる。企業間の適用もまた想定される。

トランザクションやコミュニケーションネットワーク上のその他のコミュニケーションを含め多くの目的で、当面、パスワードは最も広く一般に認められた認証方法を提供するだろう。パスワードベースの認証は、ネットワークや装置技術に依存せず、容易に利用可能である。

パスワードは、認証機械又は人への伝送時の傍受（「スヌーピング」として知られる）に対して脆弱なことがある。もしパスワードが、電気信号として、ユーザーのアクセスポイントとパスワードデータベースをコントロールする中央システムとの間の安全でない物理的な配線上で運ばれたら、通信傍受方法によるスヌーピングにさらされる。もしそれがインターネット上で運ばれるとしたら、ログオン情報を含むパケットを見ることのできる誰でもがスヌープピングできるし、察知される可能性は極めて低い。ケーブルモデムは、ＤＳＬやダイアルアップ接続より、スヌーピングに対して脆弱である。イーサーネットは、特にネットワークのハードウェア及び配線の選択に依存して、スヌーピングできたり、できなかったりである。ある組織では、ユーザーがケーブルインターネット接続を利用し始めてから、盗難パスワードの大幅な増加に注意してきた。

インターネット上送られるパスワードの傍受の危険性は、多くのインタネートブラウザに組み込まれているトランスポート層セキュリティ（ＴＬＳ、以前はＳＳＬと呼ばれていた）機構によって軽減されうる。多くのブラウザは、ＴＬＳ使用時に、閉じた鍵のアイコンを表示する。

不幸なことに、保存されたハッシュ化パスワードとハッシュベースのチャレンジ・レスポンス認証との間には対立がある；後者はクライアントに対し、彼が共有秘密（パスワード）が何であるかを知っていることをサーバーへ向けて証明するよう要求し、これをするために、サーバー側は保存された形から該共有秘密を得ることができる必要がある。遠隔認証をするＵｎｉｘ（登録商標）型のシステムでは、共有秘密はハッシュ形式となり、パスワードがオフライン推測攻撃にさらされるという深刻な欠点がある。

パスワードを伝えるよりむしろ、パスワード認証鍵合意システムはゼロ知識パスワード証明を行いうる。それはパスワードを露呈することなくパスワードについての知識を証明する。さらに一歩進んで、パスワード認証鍵合意のための拡張されたシステム（例えば、ＡＭＰ、Ｂ−ＳＰＥＫＥ、ＰＡＫ−Ｚ、ＳＲＰ−６）は、ハッシュベース方式の該対立及び欠点をさける。ある拡張されたシステムは、クライアントがパスワードについての知識をサーバーに対して証明するのを許す。ここで、そのサーバーはハッシュ化されたパスワード（又は必ずしもハッシュ化されているわけではないパスワード）を知っているだけであり、ハッシュ化されていないパスワードがアクセスするのに必要とされる。

二要素認証（ＴＦＡ）は、アイデンティティと特権とを立証するための２つの独立した手段を必要とする認証技術である。これは、システムへのアクセスを得るために単に１つの「要素」（例えば、固定パスワードについての情報）のみを必要とする従来のパスワード認証とは対照的である。

上記二「要素」とは、一般的に次の２つである。
・「あなたが知るもの」 例えば、パスワードやＰＩＮなど。
・「あなたが持つもの」 例えば、クレジットカードやハードウェアトークンなど。
従来、二要素認証はハードウェアトークンを必要とし、これは配布するのに費用が高い。

特許文献１は、安全な情報伝達のための方法及びシステムを開示している。クライアントはサーバーに対し、要求、少なくとも一つのユニークな識別子、及び、暗号化キーを送る。サーバーはその要求に対する返事を生成し、その返事を送る先の携帯装置を（該少なくとも一つのユニークな識別子に基づいて）識別する。その返事は、上記暗号化キーを使用して暗号化される。その暗号化された返事は、サーバーから識別されたクライアント装置へ送られる。上記の要求は、ＯＴＰに関する要求であることができる。

特許文献２は、認証サービスを開示し、コミュニケーションシステムにおける効果的パスワード配達を提供することを目的としている。開示された技術は、少なくとも一つのパスワードを計算するための鍵情報をコミュニケーションネットワークシステムから安全なチャンネルを通じてユーザー設備によって受け取ることと、少なくとも一つのパスワードを該鍵情報に基づいてユーザー装備にて生成することと、該少なくとも一つのパスワードを用いてユーザー装備とコミュニケーションネットワークシステムとの間で認証を行うこととを含む。モバイルネットワークにおける新しいサービスを開始するに向けて認証がボトルネックになることなしに、パスワードセキュリティと管理とを最大可能なユーザー基盤を達成できるように改良することが意図である。最近モバイルオペレーターのＷＬＡＮ（ワイヤレスローカルエリアネットワーク）及びｘＤＳＬ（デジタルサブスクライバーライン）認証、ＩＭＳ（ＩＰマルチメディアサブシステム）とＰｏＣ（携帯電話によるプッシュ・ツー・トーク）サービスのアクセス独立使用では、認証、アクセスネットワーク及び端末技術の間の強い結合がある。従来のｈｔｔｐのダイジェストパスワード配信が引き起こすＳＭＳ（ショートメッセージサービス）負荷を最小にするために、シードとハッシュの方法が使われる。コミュニケーションネットワークシステムにおける統一体（例えば端末管理サーバーを供えたオペレーター自身のサービス管理システム）はシード及び場合によっては（新たな）秘密鍵を作り、それ／それらをユーザー装備又は端末へＳＭＳを通じて送る。生成されたパスワードの数が設定可能な閾値に到達した後又は時間切れ後に、該サービス管理システムは、新しいシード（及び秘密鍵）を生成し、端末へ送る。ハッシュ関数の適用前に契約者にＰＩＮコードの入力を要求することは、この機構の安全性を高める。異なるシード、秘密鍵、及び／又は、ハッシュ関数を適用することにより、複数のパスワードドメインを生み出すことができる。

特許文献３は、オンライントランザクションに対して認証又は承認を与えるのにＰＳＴＮを使用するシステム及び方法を開示している。ユーザーのアイデンティティを立証するために、２つの異なるネットワーク上の事実上同時の伝送を使用する。特許文献４は、ランダムに生成された認証秘密と個人秘密との結合に基づくユーザー認証を開示している。

特許文献５は、ユーザー認証を開示している。このユーザー認証では、ユーザー式の形式で鍵を作成し、変数の用意（各変数に数値が割り当てられる）をユーザーに提供し、その数値をユーザー公式における適合する変数に適用し、第一の計算結果を得る。もし、この第一の結果が別個独立にユーザー式によって計算された第二の計算結果と一致すれば、このユーザーは認証される。

特許文献６は、秘密鍵と公開鍵との非対称な鍵のペアにおける公開鍵を、モバイルステーションから鍵管理コンピューターへ配布する方法を開示している。この方法は、共有の秘密を提供するために、安全なチャンネルによってＯＴＰを鍵管理コンピューターからモバイルステーションへ伝えること、第一のコードと第二のコードとがそれぞれ、モバイルステーションと鍵管理コンピューターとによって計算されること、第一のコードと公開鍵とを鍵管理コンピューターに伝えること、第一のコードと第二のコードとを比較することによってユーザーの権限が確認されることを含む。

特許文献７は、ユーザーのアイデンティティの認証について開示しており、それは、コミュニケーションネットワークやモバイルコミュニケーションチャンネル等の、２つの別々のコミュニケーションチャンネル使用する。特許文献８は、１）ユーザーが知るもの、２）ユーザーが持つもの、３）ユーザーの身体特性 のうちの２つ又は３つを通じたユーザー認証を開示している。

特許文献９は、ワイヤレスコミュニケーションネットワークにおける認証を開示している。携帯装置と本部装置との間で秘密が共有される。携帯装置と本部装置とに同時にチャレンジを送り、その結果を比較することによって、携帯装置が遠隔装置に接続できるかどうかを遠隔装置が判定する。

トランザクション認証ナンバー（ＴＡＮ）は、金融取引を許可する一回使用のパスワードという形で、いくつかのオンライン銀行サービスにより利用されている。ＴＡＮは、従来の単独パスワード認証に加えられる第２のセキュリティ層である。

以下はＴＡＮが機能する様態の概要である：
１． 銀行はユーザーのためにユニークなＴＡＮの１セットを作成する。典型的には、５０個のＴＡＮ（各文字列長さは８）がリストに印刷される。それは、通常のユーザーなら十分半年もつ。
２． ユーザーは最も近い銀行の支店からそのリストを受け取る。ユーザーは典型的には、パスポート、ＩＤカード、又は同類の書類を提示して、彼／彼女を証明する。
３． 数日後、ユーザーは５桁のパスワードを、ユーザーの自宅住所宛ての手紙によって受け取る。ユーザーはパスワードを暗記し、その通知を破棄し、ＴＡＮリストをＰＣ付近の安全な場所に保管することを求められる。
４． 彼／彼女のアカウントにログオンするために、ユーザーはユーザー名とパスワードを入力しなければならない。これによりアカウント情報にアクセスすることができるが、トランザクションを進行する能力は無効になっている。
５． トランザクションを行うために、ユーザーはその要求を入力し、未使用のＴＡＮを入力することでそのトランザクションに「サイン」する。銀行は、提出されたそのＴＡＮを、ユーザーに対して発行したＴＡＮリストに照らして確かめる。もし一致していれば、そのトランザクションは進行される。もし一致していなければ、そのトランザクションは拒絶される。
６． 該ＴＡＮは最早消費されたとして、如何なる更なるトランザクションに対しても認識されない。
７．もしＴＡＮリストが危険にさらされたならば、ユーザーは銀行に通知することにより、それをキャンセルできる。

ＴＡＮは、二要素認証として作用するが故に、追加のセキュリティを提供するものと考えられている。もしＴＡＮを含む物理的な書類が盗まれても、それはパスワード無しでは殆ど役に立たない。一方、もしハッカーがユーザーのパスワードを解読したとしても、彼らはＴＡＮ無しではトランザクションを進められない。

米国特許出願公開第２００３／０２０４７２６号 米国特許出願公開第２００６／００５９３４４号 米国特許出願公開第２００５／０２４５２５７号 米国特許出願公開第２００６／００３６８５７号 米国特許出願公開第２００５／０１１４６７５号 米国特許出願公開第２００５／００６９１３７号 米国特許出願公開第２００３／０１７２２７２号 米国特許出願公開第２００５／０２６８１０７号 米国特許出願公開第２００６／００９４４０１号

本発明は、ユーザー装置を有するユーザーに対してトランザクションを行う許可を与えるための認証システムを提供する。このシステムは、上記ユーザーと関連付けられたユーザー識別コードを保存する手段と；上記ユーザー識別コードを含むユーザーによる少なくとも１つの入力に基づいてパスコードを作成する複数の関数を生成する手段と；少なくとも１つの関数を保存し、その関数をユーザーに関連付ける手段と；上記ユーザー装置上で上記少なくとも１つの関数を実行するためのアプリケーションを生成する手段と；上記アプリケーションを上記ユーザー装置に供給する手段と；上記トランザクションと関連付けられたトランザクションコードを生成し、そのトランザクションコードを上記アプリケーションへ供給する手段と；上記ユーザー装置から上記トランザクションのためのパスコードを受け取り、その受け取ったパスコード、上記ユーザーと関連付けられた上記関数、上記ユーザー識別コード、及び、上記トランザクションと関連付けられた上記トランザクションコードに基づいて上記トランザクションを認証する手段とを含むことを特徴とする。一実施形態においては、ユニークなＯＴＰ関数がユーザーごとに使用され、その結果、極めて安全な認証手続となる。もしハッカーがＯＴＰ関数を傍受し解読できても、それは１ユーザーに影響を与えるにすぎない。たとえこれが起こったとしても、ユーザーのアカウントは尚も安全である。なぜなら、ユーザー識別コードなしでは、該関数は役に立たないからである。

一実施形態では、上記複数の関数は、少なくとも１つの入力が残りの入力、該関数、及び、出力の情報から導くことができる対称的又は可逆な関数である。上記複数の関数のうち少なくとも２つが、機能的にユニークであってよい。該少なくとも２つの関数が異なるユーザーと関連付けられていてもよい。

上記アプリケーションが、１つを超える上記関数を実行するためのものであることができる。上記システムは、上記関数のうちの１つを選択するために、上記アプリケーションへコントロールコードを送るように構成されることができる。上記ユーザー識別コード及び上記トランザクションコードは、上記関数への入力として使うことができる。
上記トランザクションコードは、上記トランザクションのために実行される上記関数のうちの１つを選択するために、使用されてもよい。

前記複数の関数を生成する手段が、関数成分のライブラリーと、前記関数成分からランダムに選択して複合関数を提供する手段とを含むことができる。上記関数成分は、数学関数、数学演算、文字列処理、日付計算、ビット操作、コンピューター論理命令、コンピューター論理フロー、コンピューター論理条件、埋め込まれハードコードされた値、及び、データ構造処理からなる群より選ばれた成分を含むことができる。

上記複数の関数を生成する手段は、該関数を検証する手段を含むことができる。該関数を検証する手段は、前に生成された関数の所定の選集との比較を行い、所定の重複レベルを超えていたら、当該生成された関数を拒絶することをできてもよい。一実施形態では、一束の関数における各関数がユニークである。

上記少なくとも１つの関数を実行するための上記アプリケーションは、ユーザーインターフェースを提供することができる。

上記アプリケーションを上記ユーザー装置に供給する上記手段が、上記ユーザー装置に電子メッセージを送る手段を含み、該メッセージがアドレスを含んで、そのアドレスから上記アプリケーションがダウンロードできる、ということが可能である。

本発明はまた認証方法も提供する。該認証方法は、ユーザーと関連付けられたユーザー識別コードを保存し；上記ユーザー識別コードを含むユーザーによる少なくとも１つの入力に基づいてパスコードを作成する複数の関数を生成し；少なくとも１つの関数を保存し、その関数をユーザーに関連付け；上記ユーザー装置上で上記少なくとも１つの関数を実行するためのアプリケーションを生成し；上記アプリケーションを上記ユーザー装置に供給し；トランザクションと関連付けられたトランザクションコードを生成し、そのトランザクションコードを上記アプリケーションへ供給し；上記ユーザー装置から上記トランザクションのためのパスコードを受け取り、その受け取ったパスコード、上記ユーザーと関連付けられた上記関数、上記ユーザー識別コード、及び、上記トランザクションと関連付けられた上記トランザクションコードに基づいて上記トランザクションを認証することを含むことを特徴とする。

従来、二要素認証はハードウェアトークンを必要とし、ハードウェアトークンは配布するのに費用が高い。本発明においては、二要素認証プロセスの第二の要素（「あなたが持つもの」要素）は、ワンタイムパスワード（ＯＴＰ）を生み出すソフトウェアソリューションである。その名が示す通り、ＯＴＰは１つのトランザクション又は１セットを構成するトランザクションの組合せに対して有効なパスワードであり、次のトランザクションは別のＯＴＰを必要とする。

本発明の実施は如何なる便利な形態によってもよく、例えば、専用ハードウェア、又は、専用ハードウェアとソフトウェアとの混合を使ってもよい。本発明は特に、サーバー、ワークステーション又はラップトップコンピューターによって実行されるコンピューターソフトウェアとしての実施に適している。本発明は更にネットワークを含むことができ、それには任意のローカルエリアネットワーク又は広域ネットワーク、従来の地上波又はワイヤレスのコミュニケーションネットワークを含む。該システムは、汎用コンピューター、個人用デジタル補助装置（ＰＤＡ）、携帯電話（例えばＷＡＰ又は３Ｇ準拠の電話）などの適切にプログラム可能な装置を含むことができる。本発明の様態は、プログラム可能な装置において実施可能なコンピューターソフトウェアを含む。該コンピューターソフトウェアは、従来の如何なるキャリア媒体を使用して該プログラム可能な装置に提供されてもよい。該キャリア媒体は、コンピューターコードを運ぶ、電気的、光学的、マイクロ波の、音の、又は無線周波の信号等の一時的キャリア媒体を含むことができる。そのような一時的媒体の一例は、インターネットなどのＩＰネットワーク上コンピューターコードを運ぶＴＣＰ／ＩＰ信号である。該キャリア媒体はまた、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ ＲＯＭ、磁気テープ装置、又は固体記憶装置などの、プロセッサーが読むことのできるコードを保存するための記憶媒体を含むことができる。

ここで本発明は、より詳細に、そして、ほんの一例として添付された図面を参照して記述される。

ＯＴＰの生成を表す流れ図である。 登録プロセスにおいて実行されるＰＩＮ決定ステップを表す流れ図である。 本発明の一実施形態の登録プロセスを表す流れ図である。 本発明のトランザクションプロセスを表す流れ図である。 本発明の一実施形態に従って稼動するシステムのボックス図である。 本発明の一実施形態のＯＴＰアプリケーションジェネレーターの要素を示すボックス図である。 本発明の認証プロセスを示すボックス図である。

図１から図４は、本発明の実施形態による認証方法のプロセスを表している。

図１に示されているように、ワンタイムパスワード（ＯＴＰ）は、秘密鍵の一例であるＰＩＮと、トランザクション特定コードの一例であるトランザクションナンバーとに基づいて、ＯＴＰ関数によって生成される。トランザクションナンバーは、そのＯＴＰがユーザー認証に使われるトランザクションを特定する。典型的には、例えば、特定のサービス又はインターネットサイトにアクセスするためにユーザーによって要求されたときに、トランザクションナンバーが、ユーザー又はユーザー装置に提供される。

一実施形態では、ユーザー装置は少なくともＳＭＳ機能を有するタイプの携帯電話である。ユーザー装置は、下記の認証システムによって提供されるコンピュータープログラムを走らせることができる。コンピュータープログラム（ここでは、ＯＴＰアプリケーションと呼ぶ）は、どんな適切な方法でユーザーに提供してもよい。ＯＴＰアプリケーションは、ユーザー装置の購入前にユーザー装置にプリインストールされていてもよいし、要求によりユーザー装置に提供されてもよい。認証システムによってコントロールされているコミュニケーションシステム上の安全な場所からＯＴＰアプリケーションをダウンロードするのは、便利な方法である。

ユーザー装置にＯＴＰアプリケーションがプレインストールされる場合には、該ＯＴＰアプリケーションが認証サーバーに登録される必要があってもよい。登録は、購入時にユーザー装置についてくる登録セキュリティコードを使って、便利に行うことができる。該セキュリティコードは、該ＯＴＰアプリケーション（故に、単数または複数のＯＴＰ関数）とその新しいユーザーとを関連付けるために、ユーザー識別の細目とともに、認証サーバーに供給されてもよい。

ユーザー装置は、どんなコミュニケーション装置であってもよい。単独のコミュニケーションチャンネルを有するものでもよいが、現代的な装置は２以上のコミュニケーションチャンネルを有する傾向がある。同一装置上の複数のコミュニケーションチャンネルを許す。また、複数のコミュニケーションチャンネルが、認証プロセスのための何らかの情報を転送するための別の装置を用いることにより提供されてもよい。携帯電話の送受話器上で走ることができるＪａｖａ（登録商標）アプリケーションを使って、本発明の実施形態が実施されうる。しかし、それは事実上いかなるコンピューターベースのプラットフォーム（ＰＤＡ、セットトップボックス等）においても使用可能である。本発明のいくつかの実施形態では、インターネットユーザーの大多数が既に所有しているハードウェア装置である携帯電話を用いる。これは単に実行費用を大幅に下げるだけではなく、ユーザーが慣れている装置を使えるようにすることで、ユーザー体験を良くする。しかし、ユーザー装置には、適切なＯＴＰアプリケーションプログラムを走らすことができ、認証システムから必要なトランザクションコードを受け取ることができる、いかなるコミュニケーション装置も含めることができる。

この実施形態において、ユーザーは、秘密鍵の一例であるユーザー識別コードを割り当てられるか、又は、選択する。典型的には、ユーザー識別コードは（例えば、４桁の数字の）個人識別番号（ＰＩＮ）である。安全性を向上するため、ＰＩＮは登録の際にユーザーによって定義され、任意の長さであることができる。さらに、簡単のためにはＰＩＮは実際の数字であるが、この技術分野においてよく知られているように、英数字列を含む如何なるパスコードでも使用することができる。認証プロセスは、別の更なる認証ステップの一部として、又は、ＯＴＰ関数への更なる入力として、１つを超える秘密鍵を使用することができる。秘密鍵は、登録プロセスの際、認証サーバーに伝達される。１つを超える秘密鍵があるときには、それらは異なった時に、異なったチャンネルを通じて認証サーバーに伝達されてもよい。例えば、ＯＴＰアプリケーションが携帯電話などの新しいユーザー装置にインストールされている場合には、ユーザー情報が、例えば、その電話を購入した店舗の端末から認証サーバーに伝達される。ＰＩＮ又は他のユーザー識別コードは、続く登録プロセスの際に、ユーザーによって選択されうる。

本発明の登録プロセスの一実施形態において、認証サーバーはユーザー装置からＯＴＰを受け取り、ＯＴＰ関数の逆を実行して、ユーザーによって選択されたＰＩＮを決定する（図２）。そのＰＩＮは、他のユーザー情報と共に保存され、特に当該ユーザーと関連づけられる。ユーザー情報は、例えば安全なサーバー上に、安全に保存されることが好ましい。その安全なサーバーは、認証サーバーであってもよい。

この実施形態において、トランザクションコード又はトランザクションナンバーは、各トランザクションに対して生成される。この実施形態のトランザクションナンバーは、サーバー上に生成された乱数又は擬似乱数である。既知の乱数ジェネレーターは十分な乱数度で数を生成することができ、事実上、次に生成される数を予測することは不可能である。それゆえ、トランザクションナンバーは、暗号のように安全である。乱数ジェネレーターはハードウェアに組み込んでもよい。ハードウェアの乱数ジェネレーターは、物理的プロセスにより乱数を生成する機器である。そのような装置は、典型的には、熱雑音、光電効果、又は、その他の量子現象のような微細な現象に基づいている。量子ベースのハードウェア乱数ジェネレーターは、典型的には、該物理的プロセスの出力を巨視的な領域へ持ち込むための増幅器と、その出力をデジタル信号に変換する変換器とを有する。

ＰＩＮとトランザクションナンバーとは、ＯＴＰ関数への入力である（図１を参照）。ＯＴＰ関数はランダムに生成された複合関数であり、該複合関数は、一実施形態においては、数学関数などの多くの部分関数を含む。ＯＴＰ関数の出力は、下記のようにＰＩＮとトランザクションナンバーとをＯＴＰアプリケーションへの２つの入力として使用し、各トランザクション対しユニークなＯＴＰである。２つの入力は、ＯＴＰアプリケーションへの最小の入力である。

ＯＴＰアプリケーションの或る使用においては、１以上の入力が該関数又はアルゴリズムに入れられる。更なるユーザー情報（例えば、日付、社員若しくはアカウントナンバー、又は他項目のユーザー識別情報）を含む更なる入力があってもよい。また、別の実施形態においては、更なるコードが認証システムによってＯＴＰ関数に供給されてもよい。単に、単独のトランザクションコードが要るに過ぎないときでも、下記のようにＯＴＰ関数の振る舞いを変化させるために、更なるコードが供給されてもよい。

ユーザーがトランザクションナンバーとＯＴＰとに基づいて選択したＰＩＮを決定するために、登録（図３）の際、ユーザーと関連付けられたＯＴＰ関数の逆が使用される。先行技術においては、パスワード生成の安全性は、暗号化及び一方向性ハッシュ関数の使用によって具備されるが、この実施形態は代わりに、計算負荷の少ない可逆または対称的関数を使用する。安全性は、各ユーザーに対してユニークなＯＴＰ関数を供給することで備わる。この発明の実施形態は、トランザクションごとに、新しいＯＴＰ関数を許す。もちろん、この技術分野でよく知られているように、暗号化は安全性を向上させるために使用できる。

一般に、各ユーザーに、ユニークなＯＴＰ関数が割り当てられる。これにより、例え、ハッカーがＯＴＰ関数を傍受し解読しても、それは単に１ユーザーにのみ影響するだけである。各トランザクション又はトランザクションの群ごとに、ユニークなＯＴＰ関数を生成することにより、安全性を更に向上させることができる。安全性と処理能力のバランスにより必要ならば、ＯＴＰ関数は複数のユーザー又はユーザー装置に割り当ててもよい。ユーザー装置への分配のために、ユニークな関数が導出されるということが本発明の特徴である。本発明のシステムは、膨大な数のユニークな対称的関数を計算することができ、それらの有効性及びユニークネスが試験される。理論的には、該システムで使用されるそれぞれの関数はそれぞれ異なることができる。もちろん、要求される安全性のレベルに依存して、許容可能な量の関数の再使用があってもよい。例えば、もしユーザーの数が大変多いならば、関数の再使用のリスクが、許容できないほど安全性のレベルに影響することはない。さらに、もし関数が長い間使用されていないならば、特にもしそれが該システムにおいて現在使用されていないならば（つまり、すでにユーザーに割り当てられていないならば）、そのような関数は該システムによって拒絶される必要はないし、ユーザーへの供給のために、ＯＴＰアプリケーションに組み込まれてもよい。

ユニークなＯＴＰ関数は、認証サーバーによって提供される「関数ジェネレーター」モジュールによって、一括処理で生成されてもよい。この実施形態では、関数ジェネレーターが、ＯＴＰ関数、該関数の逆、及び、ＰＩＮの入力及び該関数の表示のためのユーザーインターフェースを該関数に与えるコンピュータープログラム（ＯＴＰアプリケーション）を生成する。表示されたＯＴＰは、（場合によっては別の装置を使って）登録又はトランザクションプロセスで使用することができ、あるいは、例えば銀行において、人対人のトランザクションにおいて使用できる。また、認証サーバーによる認証のために、ＯＴＰ関数はユーザー又はクライアントデバイスから直接に、コミュニケーションシステムへと提供されてもよい。一括処理で生成されるＯＴＰ関数の数は、顧客の要求に合わせて調整することができる（認証システムが第３者へのサービスとして提供されている場合）。あるいは、最近のトランザクションのレベルに基づいて、自動調整するように設定できる。もし、該システムがその日に利用可能なＯＴＰ関数を使い果たしたら、特別に生成することができる。ＯＴＰアプリケーションのタイプは、そのソリューションが実装されようとしているプラットフォームに依存するだろう。携帯電話をベースとした実施では、例えば、コンピュータープログラムは、最近のどんな携帯送受話器での使用にも適しているＪａｖａ（登録商標）アプリケーションの形式であることができる。Ｊａｖａ（登録商標）非対応のユーザー装置については、他の適切なプログラム言語が使用できる。

登録プロセス
登録プロセスの目的は、ユーザーにユニークなＯＴＰアプリケーションを供給することと、彼らから彼らの選択したＰＩＮを得ることである。一実施形態においては、登録プロセスは次のステップを含む：
・ユーザーが、トランザクションを開始するために、コミュニケーションネットワーク又はクライアントサーバーに接触する。
・ユーザーは、トランザクションを進めるために、認証プロセスへの登録を求められる。
・ユーザーは、ＯＴＰ関数を含むＯＴＰアプリケーションを供給される。
・トランザクションナンバーが、認証システムによってＯＴＰアプリケーションに供給される。
・ユーザーがＰＩＮを選択し、それをＯＴＰアプリケーションに入れる。
・ＯＴＰアプリケーションは、ＰＩＮとトランザクションナンバーとをＯＴＰ関数への入力として使用し、ユーザー又は直接に認証システムへ供給することができるＯＴＰを生成する。
・ＯＴＰが認証システムに供給される。
・認証システムが、ユーザーと関連付けられたＯＴＰ関数の逆を用いて、トランザクションナンバーとユーザーによって供給されたＯＴＰとを使用し、ユーザーのＰＩＮを確立する。
・サーバーが、ユーザーのＰＩＮを安全に保存する。これが、ＰＩＮが保存される唯一の場所であるということに注意せよ。ＰＩＮは、ＯＴＰアプリケーションによって保存されないし、いちどＯＴＰ関数が走ってＯＴＰを生成したら、ユーザー装置のメモリーに留まらない。

ＯＴＰは、ＯＴＰアプリケーションやトランザクションナンバーを送るのに使用されたものとは異なる別のコミュニケーションチャンネルを通じて、認証システムに供給されてもよい。例えば、携帯電話ベースの実施においては、ＯＴＰアプリケーションはインターネートのウェブサイト又はＷＡＰサイトから得ることができ、トランザクションナンバーはＳＭＳを通じてユーザーに送ることができる。一実施形態においては、ユーザーは、インターネットを通じて（場合によってはＰＣ等の別の装置を使って）ＯＴＰを提出する。別のコミュニケーションチャンネルの使用は、事実上いちどに両方が危険にさらされることは有り得ないため、極めて安全である。

複数のコミュニケーションチャンネルの使用は、ハッカーが同時に複数を侵害することが事実上不可能であるため、安全性を高める。たとえ、該プロセスの１つの要素がハッカーによって傍受され、解読され、又は奪われることがありえても、全ての要素が無くては、該システムは危険にさらされない。例えば、ワンタイムパスワードアプリケーションへのアクセスを得たハッカー（例えば、該アプリケーションが保存された携帯装置を入手するなどして）は、ユーザー識別コード無しには、該アプリケーションを使用できない。

トランザクションプロセス
トランザクションプロセスの目的は、ユーザーが彼らのアカウントと関連付けられたＰＩＮを知っているかを確かめることによって、ユーザーの認証を成すことであり、また、それによって、そのトランザクションをユーザーに認めることである。一実施形態においては、基本的なトランザクションプロセスは、次のステップ（図４を参照）を含むことができる。
・トランザクション開始ステップに応じて、ＯＴＰアプリケーションにトランザクションコードが供給される。例えば、ユーザーは製品又はサービスをクライアントウェブサイトからオンラインで購入する。
・ＯＴＰアプリケーションはユーザーにＰＩＮなどの秘密鍵の入力を要求する。
・ユーザーはＰＩＮをＯＴＰアプリケーションに入力する。
・ＯＴＰアプリケーションは、ＰＩＮとトランザクションコードとをＯＴＰを生成するために使用する。ＯＴＰは、ユーザー又は直接に認証サーバー若しくはクライアントウェブサイトなどのコミュニケーションネットワークの要素に供給される。
・ ＯＴＰは認証サーバーに供給される。これがトランザクションナンバーをユーザーに送ったのと同じコミュニケーションチャンネルによって送られるか否かは、要求される安全性のレベルに依存して実施ごとに設定可能である。例えば、携帯電話ベースの実施においては、トランザクションナンバーとＯＴＰは両方ともＳＭＳを通じて伝達される。あるいは、（場合によっては別の装置を使って）インターネットを通じてＯＴＰを提出するようにユーザーに要求してもよい。
・認証サーバーは、このユーザーと関連付けられたＯＴＰ関数を使用し、登録時に保存されたＰＩＮと、このトランザクションに関してユーザー装置に送られたトランザクションナンバーとを使って、ＯＴＰを生成する。あるいは、サーバーは、逆ＯＴＰ関数、受け取ったＯＴＰ、及びトランザクションナンバーを使用し、ＰＩＮを比較する。または、保存したＰＩＮと受け取ったＯＴＰとを逆ＯＴＰ関数において使用し、結果のトランザクションナンバーと、そのトランザクションに関連付けられたトランザクションナンバーとを比較して、認証が達せられる。
・サーバーは、このＯＴＰと、ユーザーによって供給されたものとを比較する。もし一致すれば、該トランザクションが完了することを許す。

ＯＴＰが正しくないために、認証サーバーがユーザーを認めることができない場合には、該サーバーはエラーメッセージを促し、認証における更なる試みができるように新しいトランザクションコードが該アプリケーションに送られる。しかし、認証失敗を処理する他の仕組みが知られており、選択されるプロセスは、トランザクションのタイプ、実装プラットフォーム、及びその他の要因を含む状況に依存するだろう。ユーザーが自分のＰＩＮを忘れた場合や、ＯＴＰアプリケーションが入っている自分のユーザー装置を失った場合には、システムがまた提供されうる。

ＯＴＰアプリケーションは、他のタスクを行うルーチンを含むことができる。特に、いちどＯＴＰ関数スクリプトが実行されたら、ＯＴＰアプリケーションは、単数または複数のトランザクションコード、ユーザー識別コード、及び、他の秘密鍵といった全ての痕跡の記憶を消去してもよい。

認証システム
図５は、本発明の一実施形態での、認証システムの機能的要素を示すブロック図である。該図は、本発明を理解するために必要な要素のみを概略的に示しており、限定しているわけではない。

ここで図５を参照すると、ユーザー装置１（この場合では、携帯電話などのＷＡＰ使用可能な携帯コミュニケーション装置）がネットワーク接続により、クライアントサイト２に接続されている。クライアントサイトは、典型的には、安全なアクセスを要求するウェブサイトである。なぜなら、例えば、そのコンテンツは会費によって支えられ、又は、そのサイトは商品又は役務のための支払い取引に使われるからである。そのクライアントサイトは、安全及びユーザー認証が特に重要な、銀行又は他の金融機関に所属していてもよい。そのクライアントサイトは単独のウェブページであってもよいし、あるいは、普通は、単独サーバー又はインターネットによって接続された多くのサーバー上にある、一連のリンクされたページである。破線３は、ネットワーク接続を表す。この実施形態におけるネットワーク接続はインターネットによるものだが、類似のいかなるネットワークでもよいし、また、ピアツーピア接続であってもよい。

例えば、銀行のウェブサイトは、取引額が£５００を超える場合には、ＯＴＰの使用を要求することができる。

クライアントサイト２は、認証サーバー４を使用して、該サイトへのアクセスを許可する前、又は、商品若しくはサービスの購入など一定の取引が起こる前に、クライアントサイト２のユーザーを認証する。クライアントサイト２は、セキュリティプロセスの一部として、そのトランザクションに固有のパスワード又はパスコードである、ユーザーからのＯＴＰを要求する。この「トランザクション」という言葉は、金融取引に限定することを意図しておらず、許可を与える前に第２の者が第１の者のアイデンティティを確認したいと思う、２者間の如何なる目的の如何なるトランザクションをも意図している。

ＯＴＰは、単に、複数のステップを含み、ユーザーへの様々なチャレンジを含みうるセキュリティプロセスの一部であってもよいことを注記する。特に、商用ウェブサイトのユーザーが、ウェブサイトにログオンするために、ユーザーネームやパスワード（固定パスワード）を入力することは一般的である。特定のトランザクションのためのＯＴＰの要求は、ユーザーとクライアントサイト２との間の個々のトランザクションに対する、単に追加的なセキュリティステップであってもよい。

図５において、認証サーバー４は単独の統一体として示されているが、認証システムの要素の全てが同じ場所にあることや、同じコンピューターにあることを必要としているわけではない。分散されたソリューションが想像される。簡単のために、認証システムは概略的に示されており、図５では単独の認証サーバー４上にある。
大抵の場合は、認証プロセスを進める以前に、ユーザーがユーザー装置１を認証サーバー４に登録する必要がある。登録されたユーザーの場合、認証システム４はユーザー識別情報をメモリー５に保存する。ユーザー識別情報は、名前や住所などの通常の細目を含むことができ、クライアントサイトにログオンするのに使われる固定パスワードを含むことができる。特に、認証システムは、ユーザー装置１のユーザーに知られた１つ又は複数のプライベート鍵を利用できる。単数又は複数のプライベート鍵が、上記のように、クライアント装置１上でのＯＴＰの生成において用いられる。

認証システムは、トランザクションコードジェネレーター６と、トランザクションコードディストリビューター７とを含む。トランザクションコードを要求するタイプのトランザクションが開始されるときは、コントローラー又はＣＰＵ８が、クライアントサイト２からの要求を受けて、ユーザー装置に提供するために、トランザクションコードを該ディストリビューターに提供するようにトランザクションコードジェネレーターに指示をする。トランザクションコードは、ＳＭＳメッセージを通じて、又は、如何なる便利なコミュニケーションチャンネルを通じても、ユーザー装置に提供することができる。一般に、トランザクションコードは、直接にＯＴＰアプリケーションに提供されて、ユーザーには提示されない。少なくとも登録プロセスにおいては（そして、新たなアプリケーションがユーザーに発行される他のトランザクションにおいては）、アプリケーションがユーザーに提供される前に、トランザクションコードが該アプリケーションに提供されてもよい。しかし、より優れた安全性が要求される場合には、トランザクションコードとＯＴＰアプリケーションとは、異なるコミュニケーションチャンネルで提供される。この実施形態においては、トランザクションコードはＳＭＳメッセージによって提供され、ＯＴＰアプリケーションは下記のようにＷＡＰプッシュによって提供される。

この実施形態においては、ＯＴＰアプリケーションは、ＷＡＰプッシュによってユーザー装置に提供される。それは事実上、ヘッダーにＷＡＰアドレスへのリンクが含まれる単純なＳＭＳである。ＷＡＰプッシュを受け取った際には、ユーザー装置１は自動的にユーザーにＯＴＰサイト９へのアクセスオプションを与える。こうして、ＷＡＰプッシュはエンドユーザーを、そのユーザーのためのＯＴＰアプリケーションが送受話器へのダウンロードのために保存されているＷＡＰアドレスへ仕向ける。ＳＭＳメッセージの使用は、ＧＳＭネットワーク上でのそのようなメッセージに限定されるわけではなく、３Ｇネットワークや、ＳｋｙＭａｉｌ（ＲＴＭ）及びＮＴＴＤｏｃｏｍｏ（登録商標）のショートメール等の代替手段をも含む全ての類似のコミュニケーションチャンネルを含むことを意図している。ＮＴＴＤｏｃｏｍｏのｉモード（登録商標）やＲＩＭＢｌａｃｋＢｅｒｒｙ（ＲＴＭ）などの携帯電話のＥメールメッセージも、ＴＣＰ／ＩＰ上のＳＭＴＰなどの典型的な標準的メールプロトコルを使用している。本発明は選択されたシステムにおいて利用可能などんなコミュニケーションチャンネルによっても実施できる。

ＯＴＰアプリケーションは、１つ又は複数のＯＴＰスクリプトを含む。ＯＴＰスクリプトは、ユーザー装置１上でＯＴＰ関数を実行するために、ＯＴＰ関数から導出されたコンパイルされたコードである。下記で詳述するように、ＯＴＰ関数はＯＴＰ関数ジェネレーター１０によって生成される。特定のＯＴＰアプリケーションのための単数又は複数の関数がメモリー５に保存され、ユーザー装置１のユーザーと関連付けられる。それゆえ、どのトランザクションに対しても、コントローラー８がトランザクションコード、秘密鍵、及びＯＴＰ関数をメモリー５から利用しやすい。トランザクションの認証は、上記のように、ユーザー装置１によってクライアントサイト２に提供されたＯＴＰと、そのトランザクションと関連付けられた情報に基づいてコントローラー８によって生成されたＯＴＰとの比較によってなすことができる。認証は、その後、クライアントサイト２へ伝達することができる。

ＯＴＰアプリケーションジェネレーター１１は、ＯＴＰ関数を実行するためのＯＴＰスクリプトを、ＯＴＰアプリケーションに埋め込む。ＯＴＰアプリケーションは、上記のように、ＯＴＰアプリケーションディストリビューター１２によってユーザー装置へ供給される。ＯＴＰ関数及びアプリケーションは、以下で詳細に論じる。

ＯＴＰ関数
ここでは、関数ジェネレーター１０及びアプリケーションジェネレーター１１を含むＯＴＰアプリケーションエンジンの機能的要素を示す図６を参照する。
関数ジェネレーターは、事前定義モジュール１３、関数複合モジュール１４、及び評価／検証モジュール１５を含む。

この実施形態において、ＯＴＰ関数は複合関数である。ＯＴＰ関数は、ランダムに選択された数学演算を使って結合された数学関数等、ランダムに選択された事前定義された関数からなるアルゴリズムである。

例えば、ＯＴＰ関数は、関数f(x)=√(x)や関数g(x)=x²-5xを含むことができる。該演算は、加減乗除及びそれらの定義域を含むことができる。ユニークな関数に十分な可能性があるように、多数の選択できる関数があることが好ましい。しかし、ユニークなＯＴＰ関数の数は制限されない。なぜならば、アーギュメントの数（すなわち、関数のストリングの長さ）は固定されないからである。

ＯＴＰ関数は、単にアーギュメントの数においてだけでなく、計算結果の数、関数の種族、及び、入力や出力の範囲においても、異なっていてよい。

ＯＴＰ関数は、次のうちの幾つか又は全部を含むことができる：
ａ） 数学関数及び数学演算
ｂ） 文字列処理
ｃ） 日付計算
ｄ） ビット操作（シフト、ローテート、その他）
ｅ） コンピューター論理命令、フロー、及び条件（ループ、ＩＦ記述、その他）
ｆ） 埋め込まれハードコードされた値
ｇ） データ構造処理
当業者は、このほかの可能性を想到できる。

上記の可能性の幾つか又は全てを含む関数成分のライブラリーは、事前関数定義プロセスの結果である。関数複合モジュール１４は、該関数成分のライブラリーからランダムに選択して、一連の複合関数を生成する。各複合関数は、評価／検証モジュール１５で試験されて、その関数が種々の要求を満たしていることが保証される。例えば、評価／検証モジュール１５は、新しい複合関数が、あるパラメータの範囲内にあり、ユニークであり、所望の安全度を与えるほど十分複雑であることを判定し、異なる２つの関数が同じ入力を与えられた時に同じＯＴＰを生成するかどうかを判定する。さらに、関数によって生成された単数又は複数の値は、有効であらねばならない。検証モジュールは、各関数が可逆（すなわち、対称的関数であること）を保証する。

本発明の一実施形態においては、検証モジュールは、各関数がユニークであること、及び、どのＯＴＰアプリケーションにも現在使用されていないことを保証する。つまり、検証モジュールは、システムにおける全てのユーザーに現在関連付けられている全ての関数を入手することができ、全ての関数のデータベースと、当該ランダムに生成された複合関数とを比較する。あるいは、検証モジュール１５は、かつてそのアプリケーションジェネレーター１１によって発行された全ての関数と当該関数とを比較することによって、当該関数が真にユニークであることを保証してもよい。安全性要求があまり厳しくない場合には、検証モジュールは、所定レベルのＯＴＰ関数の再使用を許すように設定できる。他の実施形態においては、検証モジュールは単に、各束の複合関数がユニークであることを保証する。アプリケーションジェネレーター１１が異なる顧客たちのためにＯＴＰアプリケーションを生成する場合（所有されたシステムでない場合）、検証モジュールは単に、ＯＴＰ関数の各束がユニークな関数たちを含むことを保証する。関数のランダム生成は、一束の関数についての情報が、別の束の関数を解明する上で役に立たないことを保証する。

検証された関数のライブラリーは、その後、データベース１６に保存される。新しいＯＴＰアプリケーションが、アプリケーションジェネレーター１１によって生成されるとき、関数選択モジュール１７は、データベース１６に保存されている関数のライブラリーから、（例えばランダムに）関数を選択する。ＯＴＰアプリケーションビルダー１８は、その複合関数を受け取る。その複合関数は、ＯＴＰアプリケーションに埋め込まれるＯＴＰ関数であり、そのＯＴＰアプリケーションが提供されるユーザーに関連付けられる。アプリケーションビルダー１８は、該複合関数を構文解析して、アプリケーションコンパイラーによるコンパイルのためのプログラムスクリプトを作る。アプリケーションコンパイラーは、基礎アプリケーションを取り、ＯＴＰ関数スクリプトを該基礎プログラムに埋め込んで、ＯＴＰアプリケーションを形成する。コンパイルされたＯＴＰアプリケーションは、続くアプリケーションディストリビューター１２への供給のために、メモリー１９に保存される。

上記の実施形態においては、単独のＯＴＰ関数がＯＴＰアプリケーションに埋め込まれ、ユーザー装置に提供される。別の実施形態では、ユーザー装置に提供されるＯＴＰアプリケーションは複数の異なるＯＴＰ関数を有し、ＯＴＰアプリケーションに埋め込むことのできる関数の数は、ユーザー装置のメモリーや処理能力が関数の数に関して実際的又は商業的限界を置く場合を除き、制限はない。この場合、ユーザー装置に送られるトランザクションコードは、埋め込まれたＯＴＰ関数の一つを選択してそのトランザクションのためのＯＴＰ関数とするために、ＯＴＰアプリケーションによって使用されるコードであることができる。この場合、ＯＴＰ関数への入力はただ一つ（ユーザー識別コード）であってもよい。もちろん、ＯＴＰ関数はユーザーから更なる秘密鍵を受け取ってもよい。さらに、トランザクションコードはＯＴＰ関数を選択するために使用してもいいのだが、これが唯一の可能性というわけではない。ＯＴＰ関数が単独である実施形態や、別のコードがＯＴＰ関数の１つを選択するために認証サーバーにより提供される実施形態など、トランザクションコードは、ＯＴＰ関数への入力として使用することができる。
こうして、本発明においては、各ユーザー装置又は各ユーザーに対してユニークなＯＴＰ関数を有するだけでなく、新たなＯＴＰアプリケーションをインストールせずに、トランザクションごとに新たなＯＴＰ関数を選択することを含め、ＯＴＰ関数を定期的に変えることもできる。ＯＴＰアプリケーションに単独のＯＴＰ関数が埋め込まれている場合であっても、ＯＴＰ関数への入力としてサーバーにより送られるコントロールコードによってＯＴＰ関数の振る舞いを（例えばトランザクションごとに）変化させることができる。

二方向認証
相互認証としても知られ、２者が互いに認証することを指す。言い換えると、両者が他者のアイデンティティを確信できるやり方で、クライアント又はユーザーがサーバーに対して彼ら自身を証明し、そのサーバーはそのクライアント又はユーザーに対してそれ自身を証明する。

二方向認証は、アクティブな（直接的な）「ファーミング」または「フィッシング」に対抗するのに特に役に立つ。それは、ユーザーが、サーバーからの応答が本物であるということを検証できる仕組みである。

下記のこの実施形態の二方向プロトコルは、ここで述べる他の技術と結合して使用することができる。この実施形態において、上記のＯＴＰプロトコルは二方向認証を実施するのに使われる。二方向認証の際、ユーザー登録及び認証（トランザクションプロセス）が上記のように行われ、例えば図３及び４と関連する。

図７は、二方向認証におけるサーバーの認証を説明するのに役立つボックス図である。完全な二方向認証プロセスを示すものではなく、図３、図４、及び、ユーザーの登録及び認証に関連する上述の説明を合わせて考慮しなければならない。

図７ではユーザーが既に登録されていることを仮定している。サーバーは既にユーザーの秘密鍵を有している。この場合、ＰＩＮをラベルしている。このサーバーはトランザクションコードを生成し、ユーザーのＰＩＮ及び新しいトランザクションナンバーに基づいて、ユーザーと関連付けられたＯＴＰ関数を使ってＯＴＰを算出する。トランザクションナンバーはユーザーに供給される。ＯＴＰもまた、ユーザー又はユーザー装置に供給される。或る実施形態におけるＯＴＰとトランザクションナンバーは、異なるチャンネルを通じて供給される。

ＯＴＰアプリケーションはユーザーからＰＩＮを要求し、トランザクションコードとユーザーのＰＩＮとに基づいて、ＯＴＰ関数を使ってＯＴＰを生成する。ＯＴＰアプリケーション又は他のアプリケーションは、ユーザーに対してサーバーを証明するために、ユーザー装置によって生成されたＯＴＰと、サーバーによって供給されたＯＴＰとの比較を行う。

一実施形態では、ユーザー装置上のサーバーの認証は次を含む：
・サーバーは１つ又は複数のトランザクションナンバーを生成し、ユーザーのＯＴＰ関数と単数又は複数の秘密鍵とに基づいて、ＯＴＰを計算する。
・サーバーはＯＴＰとトランザクションナンバーとをユーザー又はユーザー装置に送る。
・ＯＴＰの計算がそのユーザー装置で繰り返される
・ユーザー装置は同一のＯＴＰが計算されたかを比較し、もしそのＯＴＰが一致していればサーバーを認証する。

上記の実施形態においては、トランザクションナンバーはサーバー側で生成されるが、別の実施形態では、クライアント装置がトランザクションナンバーを生成し、これをＯＴＰの計算のためにサーバーに供給するようにプログラムされてもよい。さらに、サーバーとユーザーとの間のＯＴＰ比較の多重検証があってもよい。各検証に対して、新しいトランザクションコードがあるだろう。認証プロセスは対称的なプロセスである。つまり、サーバー側においてと同じようにして、クライアント側において適用される。こうして、単に一方向の多重検証（ユーザーからサーバー、又はサーバーからユーザー）だけでなく、両方向の認証もまた、１回またはそれ以上可能である。

異なるチャンネル上の１を超える部分で、例えば、ウェブサイトに表示されて、テキストメッセージで送信されて、ＯＴＰはまたユーザーへ返すことができる（その逆も）。
上記の実施形態において、ユーザー装置は自動的にＯＴＰを比較し、サーバーを認証するように設定されているが、この認証は、ＯＴＰをユーザーに表示することにより手動ですることができる。サーバー生成のＯＴＰは、例えばウェブサイト上で、（全部又は一部が）表示されてもよいし、テキストによってユーザーに送られてもよい。本発明の範囲を離れずに、当業者は様々な比較のための技術を想到できる。

本発明の技術の実施において、システムの安全レベルは変更できる。例えば、認証成立のためにユーザーによって問われるチャレンジの数は変更できるし、又、ユーザーに対してなされるチャレンジは定期的に変更されうる。例えば、最初のログオンの際、ユーザーはＰＩＮ及び郵便コード（Ｚｉｐコード）を問われ、二回目のログオンの際には、ユーザーはＰＩＮ及び誕生日を問われる、ということが可能である。チャレンジ、質問の数は時間とともにランダムに変化してもよい。これは、ユーザーが許可を与えられる前に入力する必要があるチャレンジの数を定義するメタデータ表の使用によって達成される。

図５に示された実施形態において、ユーザーは、ＯＴＰアプリケーションを有するその同じ装置を用いて、クライアントウェブサイトと交信している。現代の電気通信装置では、同じ装置が２又はそれ以上のコミュニケーションチャンネルを提供できる。しかし、本発明がコミュニケーションチャンネルを分けて使用されうることが想到される。例えば、携帯電話がＯＴＰ関数を有するユーザー装置であるが、しかし、トランザクションは人によって（例えば銀行で）、又は、別の機械（例えばＰＣや店頭端末）で行われる、というように。トランザクションを試みる人は、要求されたＯＴＰを得ることができるように、電話を有していなければならない。権限のない人が携帯電話を手にすることができたり、又は、ユーザーＰＣへのアクセスができても、彼らがＰＣにアクセスできて、かつ、携帯電話を入手できて、かつ、ユーザーＰＩＮを入手できるということは、まず起こらない。

それゆえ、ＯＴＰアプリケーションは、通常安全な二要素認証で必要とされるハードトークンと等価なソフトトークンである。しかし、同一のＯＴＰアプリケーションが異なった安全鍵をサポートするのに使われうる。例えば、二人の人が携帯電話を共有し、異なるＰＩＮナンバーを使用して彼らを証明することができる。

ある実施形態では、複数のユーザーそれぞれがＯＴＰアプリケーションを有する、ジョイントアカウントシステムが想定される。トランザクションを認証し又は権限を与えるために、このアカウントに関連しているユーザーの全てが彼らの正しいＯＴＰを供給する必要がある。

該プロセスは機械、及び、人によって用いられる。例えば、Ｂ２Ｂトランザクションを認証するためのソリューションを、二つのサーバーが使用する。

あまり厳しくない安全レベル方針につき、例えば我々は、ユーザーがＯＴＰナンバーを異なるチャンネルを通じてサーバーに返さなければならない「クールオフ期間」をもつよう決めてもよい。例えば、ＯＴＰアプリケーションを持つものとは別の装置を通じて。クールオフ期間は、タイムリミット又トランザクションの量に基づいて計算される。

該ソリューションは、異なるタイプの安全レベルをサポートするのに十分なほど柔軟である。例えば、銀行は、電子銀行業務（ｅＢａｎｋｉｎｇ）のためのウェブサイトを経てのみ、ＯＴＰアプリケーションによって生成されたＯＴＰが認証サーバーに送り返されることを決めることができる。すなわち、例えば、ＯＴＰアプリケーションは携帯電話上にあって、トランザクションコードがＳＭＳを通じて受け取られ、ＯＴＰが異なるコミュニケーションチャンネル（つまり、インターネット）で返される。

前に述べたように、本発明はセキュリティシステムの単に一部であることができ、どんな特定のトランザクションに対しても単に認証プロセスの一部を形成するだけであることができる。この発明は、制限なしに、他の安全機構と共に使用することができる。例えば、ユーザー装置は、ＧＰＲＳシステム、又は、そのユーザー装置の場所を示すことのできる別のシステムの一部であることができる。それゆえ、認証プロセスは、ユーザー装置の場所のチェックを含むことができる。
明確のために別々の実施形態で述べられた本発明の種々の特徴は、組み合わされて、単独の実施形態において備えられることもできる。逆に、簡潔のために単独の実施形態で述べられた本発明の種々の特徴は、別々に又は適切に部分結合して、備えられることもできる。

上記の実施形態のアルゴリズムエンジンは、他の適用においても役に立つ。該アルゴリズムエンジンの基礎は、多数の新しいＯＴＰ関数を生成するために種々の方法で組み合わされる、数多くのストックされた関数や演算の使用である。ＯＴＰアプリケーションエンジンの実施形態は、図６に示される。ＯＴＰ関数とアプリケーションは、次のように、特定の応用で使用できる：
現在、ソフトウェアパッケージは一般にユーザーにライセンスされる。ソフトウェアのコピーごとにセキュリティコード又はナンバーを生成するのに、本質的に、一般には単独のアルゴリズムが使われる。場合によっては総当り攻撃で、いちどアルゴリズムが解読されたら、その製品の偽者のコピーが、検証サーバーによって受け入れられる「有効な」セキュリティコードを伴って作られる。ソフトウェアの正規のコピーを無効にせずに、アルゴリズムを変えることはできない。

代替案は、異なったアルゴリズムを有する、異なった領域を持つことである。つまり、アルゴリズムは無効化されるが、それは単に当該同一の領域にある正規のコピーにのみ影響を与えるだけである。

本発明は、本発明によるＯＴＰアプリケーションを各パッケージに提供することにより、ソフトウェアパッケージごとにユニークなアルゴリズムを提供するのに用いられる。ＯＴＰ関数の一例を含むＯＴＰアプリケーションは、トランザクションコードと関連付けられる。ＯＴＰ関数は、ソフトウェアパッケージごとにユニークであるか、又は、１つの領域においてソフトウェアパッケージごとにユニークである。それにより、アルゴリズムのハッキング行為は無益なものとなる。なぜなら、ＯＴＰアプリケーションのハッキングは、単にそのＯＴＰアプリケーションの一例に影響を与えるに過ぎないからである。

本発明のこの適用において、ＯＴＰアプリケーションは別のＰＩＮを必要としない。秘密鍵又は識別コードが、固定されているか、又は、重複すると考えることができる。

この適用は、ソフトウェアパッケージとして述べられたけれども、製品のアイデンティティが認証されていることは、許諾ＯＴＰアプリケーションとは関係がなく、オンライン又は非オンラインの投票や、ユーザーアクセスなど、この技術は如何なる製品又は認証／検証シナリオに対しても適用できる。とくに、ＯＴＰアプリケーションはメディアファイルに添付され、コンピューターネットワークなどの電子手段によって配布されるそのようなファイルを安全にする。

本発明はソフトウェアソリューションに限定されない。ＯＴＰアルゴリズムエンジンによって生成されるＯＴＰ関数は、メモリーカード又はＩＣカードなどのカード、トークン、チケット等に埋め込むことができる。そのような物理的識別手段には入力がなく、そのユニーク又はほとんどユニークなアルゴリズムが、認証システムによって、ユーザーと関連付けられる。そのようなシステムは、例えば、銀行又は投票シナリオにおいて人を識別するのに使われる。

本発明のＯＴＰアプリケーションは、バイオメトリック装置がインターネット等のネットワーク上で認証のために使用されるのを許す。バイオメトリック装置ごとに、別のＯＴＰアプリケーションが与えられ、ＯＴＰアプリケーションのための識別コードは入力バイオメトリックデータである。これは、ＯＴＰ関数のために必要とされる秘密鍵又は識別コードを入力する代替手段の一例である。

先行技術においては、バイオメトリック装置からの出力は、比較的固定された値である。つまり、バイオメトリック装置はユーザー側で検証する。本発明の使用は、非ユーザー側における（例えば認証サーバーによる）ユーザーの認証を許します。バイオメトリック装置と関連付けられたＯＴＰアプリケーションの情報によって、及び、認証サーバーに便利に事前登録されたバイオメトリック情報に基づいて、認証サーバーはユーザーを認証することができます。この実施形態において、トランザクションコードは、この実施形態に対して別に供給される必要はない。例えば、バイオメトリックシステム自身の中で生成されてもよい。しかし、本発明の認証技術のより一般的な実施形態に従って、バイオメトリック装置は、ＯＴＰアプリケーションサーバーと結合して使われることができる。その場合、トランザクションコードの供給のための種々の選択肢が同等にこの実施形態に適用できる。

さらに、ＯＴＰアプリケーションは、ユーザーのＰＩＮ等の一つまたはそれ以上の更なる入力を受け入れることができる。

本発明の実施形態は例として記述されたけれども、当業者は、添付された請求の範囲により定義される本発明の範囲から外れずに、変更されたもの及び同等物を想到しうる。

Claims (11)

1. 認証アプリケーションを含むコミュニケーション装置であって、前記認証アプリケーションには複数のパスコード関数が埋め込まれ、該アプリケーションが、特定のトランザクションのために生成され、前記トランザクションと関連付けられたトランザクションコードと、認証のために人又はもののうちの１つを特定する識別コードとに基づいて、該パスコード関数を用いて、パスコードを生成するように構成されており、
   該パスコード関数が複数の部分関数から得られる複合関数であり、
   該アプリケーションが、認証サーバーから受け取った前記トランザクションコードに基づいて、前記パスコードを生成するために使用されるパスコード関数を選択するように構成されていることを特徴とするコミュニケーション装置。
2. 前記認証アプリケーションが、トランザクションに関連する第三者によって生成されたパスコードを受け取り、その第三者を認証するために、その受け取ったパスコードと前記コミュニケーション装置上で該アプリケーションによって生成されたパスコードとを比較する認証アプリケーションであることを特徴とする請求項１記載のコミュニケーション装置。
3. ユーザー装置を有するユーザーに対してトランザクションを行う許可を与えるための認証システムであって、前記システムは、
   前記ユーザーと関連付けられたユーザー識別コードを保存する手段と；
   複数の部分関数から得られる複合関数であって、前記ユーザー識別コードを含むユーザーによる少なくとも１つの入力に基づいてパスコードを作成するパスコード関数を複数生成する手段と；
   前記複数のパスコード関数を保存し、そのパスコード関数をユーザーに関連付ける手段と；
   前記ユーザー装置上で前記パスコード関数を実行できるアプリケーションを生成する手段と；
   前記アプリケーションを前記ユーザー装置に供給する手段と；
   前記トランザクションと関連付けられ、前記パスコードを生成するために使用されるパスコード関数を選択するために使用されるトランザクションコードを生成し、そのトランザクションコードを前記アプリケーションへ供給する手段と；
   前記ユーザー装置から前記トランザクションのためのパスコードを受け取り、その受け取ったパスコード、前記ユーザーと関連付けられた前記パスコード関数、前記ユーザー識別コード、及び前記トランザクションと関連付けられた前記トランザクションコードに基づいて前記トランザクションを認証する手段とを含むことを特徴とする認証システム。
4. 前記ユーザー識別コード及び前記トランザクションコードが、前記パスコード関数への入力として使われることを特徴とする請求項３記載の認証システム。
5. 前記複数のパスコード関数を生成する手段が、部分関数のライブラリーと、前記複合パスコード関数を提供するために該部分関数の中からランダムに選択する手段とを含むことを特徴とする請求項３または請求項４記載の認証システム。
6. 前記複数のパスコード関数を生成する手段が、該パスコード関数を検証する手段を含み、
   該パスコード関数を検証する手段が、前に生成されたパスコード関数の所定の選集との比較を行い、所定の重複レベルを超えていたら、当該生成されたパスコード関数を拒絶することを特徴とする請求項３、請求項４、または請求項５記載の認証システム。
7. 前記識別コードがバイオメトリックデータから導出されることを特徴とする請求項３〜６のうちいずれか一項記載の認証システム。
8. ユーザーと関連付けられたユーザー識別コードを保存し；
   複数の部分関数から得られる複合関数であって、前記ユーザー識別コードを含むユーザーによる少なくとも１つの入力に基づいてパスコードを作成するパスコード関数を複数生成し；
   前記複数のパスコード関数を保存して、そのパスコード関数をユーザーに関連付け；
   ユーザー装置上で前記パスコード関数を実行できるアプリケーションを生成し；
   前記アプリケーションを前記ユーザー装置に供給し；
   トランザクションと関連付けられ、前記パスコードを生成するために使用されるパスコード関数を選択するために使用されるトランザクションコードを生成し、そのトランザクションコードを前記アプリケーションへ供給し；
   前記ユーザー装置から前記トランザクションのためのパスコードを受け取り、その受け取ったパスコード、前記ユーザーと関連付けられた前記パスコード関数、前記ユーザー識別コード、及び前記トランザクションと関連付けられた前記トランザクションコードに基づいて前記トランザクションを認証することを特徴とする認証方法。
9. プログラムスクリプトをアプリケーションへコンパイルして前記少なくとも一つの複合パスコード関数を前記アプリケーションに埋め込むことを含む請求項８記載の認証方法。
10. 請求項８又請求項９の方法を実行するためにコンピューターをコントロールするためのコンピューター可読コードを運ぶ一時的キャリア媒体。
11. 請求項８又請求項９の方法を実行するためにコンピューターをコントロールするためのコンピューター可読コードを保存する記録媒体。

Images