トークン認証システムおよび方法
【課題】ワン・タイム・パスワードを計算する方法を提供すること。
【解決手段】ワン・タイム・パスワードを計算する方法に関する。シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーでもよく、或いは共有されたシークレット対称キーでもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、認証サーバにおけるワン・タイム・パスワードの各計算により単調に増加する。ＯＴＰは連結されたシークレットとカウントをハッシュすることによって計算されることができる。その結果は切捨てることができる。
【解決手段】ワン・タイム・パスワードを計算する方法に関する。シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーでもよく、或いは共有されたシークレット対称キーでもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、認証サーバにおけるワン・タイム・パスワードの各計算により単調に増加する。ＯＴＰは連結されたシークレットとカウントをハッシュすることによって計算されることができる。その結果は切捨てることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証に関し、特にハードウエア装置を使用する認証に関する。
【背景技術】
【０００２】
ネットワーク中においてデータまたはサービスにアクセスするリクエストを許可するか否かを決定する通常のステップはリクエストしているユーザを識別して認証することである。認証はユーザのアイデンティティを確認するプロセスを含んでいる。既知の識別および認証システムはユーザ識別子（“ユーザｉｄ”）とユーザに対するシークレット（“パスワード”）との関係を含んでいる。パスワードはユーザと認証サービス機関との間で共有されているシークレットである。ユーザは自己のユーザｉｄとパスワードを認証サービス機関に提示し、その認証サービス機関はそれらをそのサービス機関に記憶されているユーザｉｄおよび関連するパスワードと比較する。それらが整合している場合には、ユーザは認証されたとされる。整合しない場合には、ユーザは認証されないとされる。
【０００３】
トークンはユーザを認証するために使用されることのできる装置である。それは１以上のシークレットを含むことができ、それらのシークレットの幾つかは確認センターと共有されることができる。例えば、トークンはワン・タイム・パスワード（ＯＴＰ）を計算するベースとして使用されることのできるシークレットキーを記憶することができる。ＯＴＰはかって生成され、その後は再使用されていない番号（またはアルファベット列）であってもよい。トークンはＯＴＰを発生してそれを特有のトークン通し番号と共に認証サーバへ送る。認証サーバは受信された通し番号によりそのトークンに対するそのシークレットキーのコピーを使用してＯＴＰを計算することができる。ＯＴＰが整合する場合には、ユーザは認証されるべきであるとされる。ユーザからトークンへのリンクをさらに強力にするために、ユーザはトークンのロックを解除することにより入力されなければならないトークンと共有されたシークレット個人識別番号（ＰＩＮ）を設定することができる。その代りにＰＩＮはユーザと、トークンと、認証サーバとの間で共有されることができ、ＯＴＰを生成するための他のファクタと共に使用されることができる。トークンは典型的に許可されていない開示からそのシークレットを保護するために盗用に対する抵抗力の高い手段を具えている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、ワン・タイム・パスワードを計算する方法を提供することである。
【課題を解決するための手段】
【０００５】
シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーであってもよく、或いは共有されたシークレット対称キーであってもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、それにおいて認証サーバにおけるワン・タイム・パスワードの各計算と共に単調に増加する。ＯＴＰは連結されたシークレットとカウントとをハッシュすることによって計算されることができる。その結果は切捨てることができる。
【０００６】
本発明の１実施形態では、ハードウエア装置においてワン・タイム・パスワード（ＯＴＰ）を発生するためのプロトコルを含んでおり、それはユーザを認証するために使用される。ＯＴＰはトークンにより発生され、そのトークンは、それが含まれているソフトウエアおよび情報の許可されない変更や、開放を阻止して、その適切な機能を確保するためのメカニズムを含んでいる物理的な装置であることができる。
【０００７】
このプロトコルの１実施形態は、シーケンスベースであることができ、２ファクタ、例えばユーザの知識（個人識別番号、ユーザと認証サービス機関との間で共有されるシークレットのようなもの）およびユーザが所有している例えばトークンのような特別の特性を有する物理的装置（例えば私設キーまたは共有された対称キーのような特有のシークレットキー）である。
【０００８】
ＯＴＰを発生するためのプロトコルはカウンタに基づくことが可能であり、例えばＯＴＰがトークンからリクエストされる回数に基づいた単調に増加する数である。ＯＴＰの値はトークン上に表示されることができ、例えばネットワークに結合されているコンピュータに結合されているキーボードを介してユーザにより容易に読取られ、入力されることができる。ＯＴＰはＲＡＤＩＵＳシステムによって転送されることができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の１実施形態による認証手順のフロー図。
【図２】本発明の別の実施形態による認証手順のフロー図。
【発明を実施するための形態】
【００１０】
本発明によるプロトコルの１実施形態は、増加するカウンタ値と、トークンおよび認証サービス機関（“強力な認証”サービス）に対してのみ知られている静的対称キーとに基づくことができる。ＯＴＰ値はＲＦＣ2104に規定されているようなＨＭＡＣ−ＳＨＡ１アルゴリズムまたは任意の他の適当なハッシュアルゴリズムを使用して生成されることができる。このハッシュされたＭＡＣアルゴリズムはＳＨＡ−１の強度を有しているが、出力の計算中のシークレットの付加を許容する。
【００１１】
ＨＭＡＣ−ＳＨＡ１アルゴリズムによる計算の出力は１６０ビットである。しかしながら、この値はユーザにより容易に入力されることができるような長さに切り捨てられることができる。
ＯＴＰ＝切捨て（ＨＭＡＣ−ＳＨＡ１（カウント，シークレット））
クライアントおよび認証サーバの両者はＯＴＰ値を計算することができる。サーバにより受信された値がそのサーバにより計算された値と一致するならば、ユーザは認証されるべきであるとされる。サーバで認証が生じた場合には、そのサーバはカウンタ値を１だけインクリメントする。
【００１２】
サーバのカウンタ値は成功したＯＴＰ認証後にインクリメントされることができるが、トークンにおけるカウンタはボタンが押される都度インクリメントされることができる。このため、サーバとトークンのカウンタ値はしばしば同期が外れる可能性がある。事実、ユーザ環境与えられたサーバとトークンが常に同期が外れているチャンスがある（例えばユーザが必要がないのにボタンを押すとき、ボタンが偶発的に押されるとき、ユーザがＯＴＰをミスタイプするとき等）。
【００１３】
サーバのカウンタは有効なＯＴＰが与えられたときにのみインクリメントするため、トークンにおけるサーバのカウンタ値はトークンにおけるカウンタ値よりも常に少ないことが予測される。再同期がユーザまたは企業のＩＴ部門のいずれかの負担とならないことが確実にされることを確認することが重要である。
【００１４】
このようなシナリオにおけるカウンタの同期は、次のｎ個のＯＴＰ値をサーバが計算して（ｎは整数）、一致していることを決定することによって達成される。トークンにおけるカウントとサーバおけるカウントとの間の差が５０であると仮定した場合には、強力な認証サーバの構成に応じて、そのサーバは最大で次の５０のＯＴＰ値を計算しなければならない。したがって、例えば正確なＯＴＰがｎ＋１２の値にあることが発見された場合には、サーバはそのユーザを認証し、その後、カウンタを１２だけインクリメントする。
【００１５】
サーバにより容易に計算されることのできるｎに対する値を注意深く選択することが重要である。サーバがＯＴＰ値を永久に検査しないことを確実にして、それにより１０進サービスアタックに屈伏する上限が必要である。
【００１６】
ＨＭＡＣ−ＳＨＡ１値を６文字値に切捨てることによって、特に数字だけが使用されている場合にマウントに対して容易にアタックする強力な力を与える可能性がある。このため、このようなアタックは強力な認証サーバにおいて検出されて停止されることができる。サーバが妥当でないＯＴＰを計算するたびにこれを記録して、例えば幾つかのポイントで同じソースからの確認に対して将来のリクエストを拒否して被害を受けることを阻止する手段を構成する。その代りに、ユーザは確認の試みの間の長時間の待機を強制されることができる。
【００１７】
ユーザがロックアウトされると、そのユーザは、例えばシーケンス中の多数のＯＴＰに入るためにユーザを必要とするウエブインターフェースを提供することによって“自己ロック解除”することができて、それらかトークンを有することが証明される。
【００１８】
共有されたシークレットがカウンタと組合わされると、１６０ビット（２０バイト）のＨＭＡＣ−ＳＨＡ１結果が得られる。１実施形態では、我々のＯＴＰに対してこの情報の最大で４バイトである。ＨＭＡＣＲＦＣ（ＲＦＣ2104-ＨＭＡＣ：メッセージ認証に対するキードハッシング）はさらにセクション５のＨＭＡＣ結果の半分以上を使用しなければならないと警告している。切捨てられた出力は：
ＨＭＡＣのアプリケーションがＨＭＡＣ計算の左側のｔビットを出力することによってＨＭＡＣの出力の切捨てを選択することが可能であり、…出力長ｔはハッシュ出力の長さの半分より小さくないことを推奨しており、…８０ビット（アタッカにより予測されるのに必要なビット数に付いての適当な低い限度）より少なくはない。
【００１９】
したがって、ＨＭＡＣまたはＳＨＡ１のいずれも弱めることのない方法でＨＭＡＣ結果の４バイトまたはさらに少ないバイトだけを選択する別の方法が必要である。
【００２０】
［ダイナミックオフセット切捨て］
この技術の目的は、ＨＭＡＣ−ＳＨＡ１結果から４バイトのダイナミック２進コードを抽出し、その一方でＭＡＣの暗号の強さの大部分を維持することである。
【００２１】
１．最後のバイト（バイト１９）を取り、
２．オフセット値として低いオーダーの４ビットをマスクして除去し、
３．オフセット値を使用してＨＭＡＣ−ＳＨＡ１結果のバイト中へインデックスし、
４．ダイナミック２進コードとして後続する４バイトを戻す。
【００２２】
以下のコード例は、hmac resultはＨＭＡＣ−ＳＨＡ１結果を有するバイトアレイを与えるダイナミック２進コードの抽出を記載したものである。
【００２３】
【数１】
【００２４】
以下はこの技術の使用例である。
【００２５】
【数２】
【００２６】
１．最後のバイト（バイト19）は６値0×5aを有する。
２．下位の４ビットの値は0×aである（オフセット値）。
３．オフセット値はバイト10（10×a)である。
４．バイト10で始まる４バイトの値は0×50ef7f19であり、それはダイナミックに２進コードである。
我々は３１ビットの、符号のない、ビッグエンド（big endian）の整数として２進コードを処理し、その第１のバイトは0×7fでマークされる。
【００２７】
所定のシークレットのためのＯＴＰおよびムービングファクタは、３つのパラメータ、すなわち、エンコードベース、コードデジット、ハズチェックサムに基づいて変化することができる。エンコードベースとして１０、真（TRUE）へセットされたコードデジットおよびバスチェックサムとして７により、上記の例を継続する。
・６値0×50ef7f19を1357872921ベース10に変換する。
・最後の７デジットは7872921である。
・コードデジットのクレジットカードチェックサムは７をチェックサムとして計算する。10-((5+8+5+2+9+2+2)mod10)＝10-(33mod10)＝10-3＝7
・以下のＯＴＰ：78729217が得られる。
【００２８】
以下はこのアプリケーションで使用される用語集である。
チェックサムデジット；コードデジットに対してクレジットカードチェックサムアルゴリズムを適用した結果である。このデジットは随意である。このチェックは任意の単一の順序変更または任意の単一のミスタイプされた文字を捕捉しなければならない。
【００２９】
コードデジット；このパラメータは２進コードから得られるデジットの数である。２進コードをエンコードベースに変換し、少なくともコードデジットである０をパッドし、右側（下位）デジットを採用することにより計算される。エンコードベースとして１０により９を越えないコードデジットが３１ビットの２進コードによりサポートされることができる。
【００３０】
クレジットカードチェックサムアルゴリズム；このチェックサムアルゴリズムは任意の単一のミスタイプされたデジットまたは任意の単一の隣接する２つのデジットの順序変更を捕捉できる利点を有している。これらは最も普通のタイプのユーザエラーである。
【００３１】
エンコードベース；このパラメータはパスワードに使用されるもののベースを示している。ベース１０は数値パッドで入力されることができるので好ましいベースである。
【００３２】
ハズチェックサムデジット；このブールパラメータはチェックサムデジットがＯＴＰを生成するために付加されなければならないか否かを示す。チェックサムデジットが存在しないならば、そのコードデジットがＯＴＰとして使用される。チェックサムデジットが存在すれば、クレジットカードチェックサムアルゴリズムへの入力としてそのコードデジットを使用してそれが計算される。
【００３３】
ＯＴＰ；ワン・タイム・パスワード。この値は、存在するものがあれば、コードデジットの右にチェックサムデジットを付加することにより構成される。チェックサムデジットが存在しなければ、ＯＴＰはコードデジットと同じである。
ワン・タイムの数値はハッシュビット中で第１のシフトを行い、その後同期ビットをシフトし、その後、前の中間値のチェック関数（）の結果をシフトすることにより計算される。
【００３４】
２進値はその後、適当な文字値に変換される。パスワードの３つの類似した文字表示、すなわち１０進数、６進数、アルファベットおよび数字が存在する。
【００３５】
【数３】
【００３６】
１０進数
トークンはダイナミック２進コードを１０進数に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、１０進数トークンは２進コードを１０進数に変換し、最後の６デジットを表示する。
【００３７】
６進数
トークンはダイナミック２進コードを６進数に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、６進数トークンは２進コードを６進数に変換し、最後の６デジットを表示する。
【００３８】
アルファベットおよび数字
トークンはダイナミック２進コードをベース３２に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、ベース３２のトークンは２進コードをベース３２に変換し、最後の６デジットを表示する。
【００３９】
ＰＩＮ
真の２ファクタ認証トークンのために、ＯＴＰの“あなたの有しているもの”の値に“あなたの知っているもの”の値を付加することができる。この値は通常静的なＰＩＮまたはユーザだけに知られているパスワードである。このセクションでは、本発明による静的ＰＩＮを確認するために３つの別のアーキテクチャについて説明する。
クラウド中のＰＩＮ確認
クラウド中のＰＩＮ確認を可能にするために、単一のＰＩＮは単一のトークンに結合されることができる。ＰＩＮは暴露されないことを確実にするためにワイヤ上で保護されなければならない。ＰＩＮの管理（設定、変更）は強力な認証サービスによって行われなければならない。
【００４０】
企業におけるＰＩＮ確認
クラウド中のＰＩＮ確認を可能にすることは単一のトークンに対する多数のＰＩＮ確認を意味している。
ＰＩＮは企業のセキュリティワールドに残されてはならない。ＰＩＮの管理は企業によって行われることができる。
【００４１】
トークンにおけるＰＩＮ確認
この実施形態はトークンにおけるキーパッドを使用して構成されることができる。ＰＩＮは絶対にワイヤで送ってはならず、ＯＴＰアルゴリズムに対するシードとして使用されることができる。ＰＩＮは単にトークンのロックを解除するために使用されることができる。
【００４２】
［データフローの例］
このセクションでは２つのデータフローのシナリオについて説明する。第１のシナリオでは、強力な認証サービスがトークンと関係するユーザ名を知らないと仮定する。このシナリオでは、ＰＩＮの管理動作はそれらのユーザ名の代りにそれらのトークンＳＮを入力するようにユーザに要求すると仮定している。
【００４３】
第２のシナリオは、トークンＳＮの代りにユーザ名が強力な認証サービス中へのキーであることを除いては第１のシナリオに非常によく類似している。この場合について幾つかの論点がある。第１に、ユーザ名はサービス機関に知られており、第２に、ユーザ名からトークンＳＮへの特有のマップを確実に行う方式が得られなければならない。
【００４４】
図１は、本発明の１実施形態による認証手順を示している。それにおいて以下のことが仮定されている。
・トークンＳＮとＳは強力な認証サービスへ分配され、
・カストマアカウントは各トークンに関連され、
・ＰＩＮは特定のトークンに関連され、
・強力な認証サービスはＤＢ中のＰＩＮのＳＨＡ−１ハッシュのみを保存し、
・トークンＳＮは企業におけるユーザアカウントに対する属性として付加され、プラグインによりユーザ名をＳＮへマップする。
【００４５】
強力な認証サーバ110と、企業の認証サーバ120と、クライアント130とは、例えばネットワーク（図示せず）により結合されている。図１に示されているように、クライアント130に位置するユーザは企業のサーバ120に保護されたリソースへアクセスするためのリクエストを送信する。そのサーバはリソースへのアクセスが認証を必要とするか否かを決定する。認証を必要とする場合には、そのサーバ120は“認証を必要とされる”のメッセージをクライアント130に送る。ユーザはユーザ名とパスワードの提示を促される。ユーザはそのユーザのトークンのボタン（図示せず）を押してＯＴＰを得ることができる。ＯＴＰは上述のように、例えばトークンシークレットと、トークンに記憶されているカウントに対する現在の値の組み合わせをハッシュすることによって発生される。その後、ユーザはそのユーザ名と，トークンにより与えられたＯＴＰに連結された個人的識別番号（ＰＩＮ）を入力する。この情報は企業のサーバ120に送られる。企業のサーバ120はユーザ名に基づいてトークンの通し番号を探して、その通し番号とＰＩＮ＋ＯＴＰを認証サーバ110に送る。認証サーバ110は通し番号に基づいて記録を探してＰＩＮのローカルにハッシュされた値とシークレットと目的とされているカウントとを得る。これは、トークンのシークレットが特有に割当てられているトークンと認証サーバ110との間で共有されることができるために可能である。それから、認証サーバ110はトークンに対するシークレットと認証サーバに記憶されているそのトークンに対するカウントの現在値とに基づいてＯＴＰを計算する。計算されたＯＴＰが受信されたＯＴＰと整合していれば、認証サーバ110におけるカウントの値が１だけインクリメントされる。そうでなければ、認証サーバは、トークンに対するカウントをインクリメントし、トークンに対するシークレットと共にそれをハッシュすることによってＯＴＰを計算しようと再度試みる。これは、上述したように、認証サーバ110におけるカウント値がトークンにおけるカウント値とは異なっていてもよい（図示せず）ために行われることができる。この手順は、トークンにおけるカウント値にカウント値が追いつくことが可能な合理的な回数で反復されることができる。１実施形態では、認証サーバにおけるトークンの認証を試みるそのような反復の回数は予め定められた同じ回数、例えば１２回の反復後に終了される。トークンが認証サーバ110によって認証されることが成功できない場合には、認証サーバ110は“認証されず”のメッセージを企業のサーバ120に送る。トークンが認証されることに成功した場合には、認証サーバ110は“認証された”のメッセージを企業のサーバ120に送る。認証サーバ110から得られた結果に基づいて、企業のサーバは、クライアントからのリソースをアクセスするためにリクエストされた許可をそれぞれ拒否または承認する。
【００４６】
図２は、本発明の別の実施形態による認証手順を示している。それにおいて以下のことが仮定されている。
・トークンＳＮとＳは強力な認証サービスへ分配され、
・カストマアカウントは各トークンに関連され、
・ＰＩＮは特定のトークンに関連され、
・強力な認証サービスはＤＢ中のＰＩＮのＳＨＡ−１ハッシュのみを保存し、
・ユーザ名は企業の認証サーバから強力な認証サーバへ転送される。
【００４７】
図２の認証手順は、ユーザ名とＰＩＮ＋ＯＴＰがクライアント130から企業のサーバ120に送られる直後までは図１と同じである。しかしながら、ユーザ名に基づいてトークン通し番号を探すのではなく、企業のサーバ120は認証リクエスト（ユーザ名とＰＩＮ＋ＯＴＰを含んでいる）を認証サーバ110に送信する。認証サーバ110はユーザ名に基づいて記録を探してＰＩＮを認証し、その後プロセスの残りに対しては図１に示されているのと同じ手順にしたかって処理が行われる。
【符号の説明】
【００４８】
１１０ 強力な認証サービス
１２０ 企業の認証サーバ
１３０ クライアント
【技術分野】
【０００１】
本発明は、認証に関し、特にハードウエア装置を使用する認証に関する。
【背景技術】
【０００２】
ネットワーク中においてデータまたはサービスにアクセスするリクエストを許可するか否かを決定する通常のステップはリクエストしているユーザを識別して認証することである。認証はユーザのアイデンティティを確認するプロセスを含んでいる。既知の識別および認証システムはユーザ識別子（“ユーザｉｄ”）とユーザに対するシークレット（“パスワード”）との関係を含んでいる。パスワードはユーザと認証サービス機関との間で共有されているシークレットである。ユーザは自己のユーザｉｄとパスワードを認証サービス機関に提示し、その認証サービス機関はそれらをそのサービス機関に記憶されているユーザｉｄおよび関連するパスワードと比較する。それらが整合している場合には、ユーザは認証されたとされる。整合しない場合には、ユーザは認証されないとされる。
【０００３】
トークンはユーザを認証するために使用されることのできる装置である。それは１以上のシークレットを含むことができ、それらのシークレットの幾つかは確認センターと共有されることができる。例えば、トークンはワン・タイム・パスワード（ＯＴＰ）を計算するベースとして使用されることのできるシークレットキーを記憶することができる。ＯＴＰはかって生成され、その後は再使用されていない番号（またはアルファベット列）であってもよい。トークンはＯＴＰを発生してそれを特有のトークン通し番号と共に認証サーバへ送る。認証サーバは受信された通し番号によりそのトークンに対するそのシークレットキーのコピーを使用してＯＴＰを計算することができる。ＯＴＰが整合する場合には、ユーザは認証されるべきであるとされる。ユーザからトークンへのリンクをさらに強力にするために、ユーザはトークンのロックを解除することにより入力されなければならないトークンと共有されたシークレット個人識別番号（ＰＩＮ）を設定することができる。その代りにＰＩＮはユーザと、トークンと、認証サーバとの間で共有されることができ、ＯＴＰを生成するための他のファクタと共に使用されることができる。トークンは典型的に許可されていない開示からそのシークレットを保護するために盗用に対する抵抗力の高い手段を具えている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、ワン・タイム・パスワードを計算する方法を提供することである。
【課題を解決するための手段】
【０００５】
シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーであってもよく、或いは共有されたシークレット対称キーであってもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、それにおいて認証サーバにおけるワン・タイム・パスワードの各計算と共に単調に増加する。ＯＴＰは連結されたシークレットとカウントとをハッシュすることによって計算されることができる。その結果は切捨てることができる。
【０００６】
本発明の１実施形態では、ハードウエア装置においてワン・タイム・パスワード（ＯＴＰ）を発生するためのプロトコルを含んでおり、それはユーザを認証するために使用される。ＯＴＰはトークンにより発生され、そのトークンは、それが含まれているソフトウエアおよび情報の許可されない変更や、開放を阻止して、その適切な機能を確保するためのメカニズムを含んでいる物理的な装置であることができる。
【０００７】
このプロトコルの１実施形態は、シーケンスベースであることができ、２ファクタ、例えばユーザの知識（個人識別番号、ユーザと認証サービス機関との間で共有されるシークレットのようなもの）およびユーザが所有している例えばトークンのような特別の特性を有する物理的装置（例えば私設キーまたは共有された対称キーのような特有のシークレットキー）である。
【０００８】
ＯＴＰを発生するためのプロトコルはカウンタに基づくことが可能であり、例えばＯＴＰがトークンからリクエストされる回数に基づいた単調に増加する数である。ＯＴＰの値はトークン上に表示されることができ、例えばネットワークに結合されているコンピュータに結合されているキーボードを介してユーザにより容易に読取られ、入力されることができる。ＯＴＰはＲＡＤＩＵＳシステムによって転送されることができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の１実施形態による認証手順のフロー図。
【図２】本発明の別の実施形態による認証手順のフロー図。
【発明を実施するための形態】
【００１０】
本発明によるプロトコルの１実施形態は、増加するカウンタ値と、トークンおよび認証サービス機関（“強力な認証”サービス）に対してのみ知られている静的対称キーとに基づくことができる。ＯＴＰ値はＲＦＣ2104に規定されているようなＨＭＡＣ−ＳＨＡ１アルゴリズムまたは任意の他の適当なハッシュアルゴリズムを使用して生成されることができる。このハッシュされたＭＡＣアルゴリズムはＳＨＡ−１の強度を有しているが、出力の計算中のシークレットの付加を許容する。
【００１１】
ＨＭＡＣ−ＳＨＡ１アルゴリズムによる計算の出力は１６０ビットである。しかしながら、この値はユーザにより容易に入力されることができるような長さに切り捨てられることができる。
ＯＴＰ＝切捨て（ＨＭＡＣ−ＳＨＡ１（カウント，シークレット））
クライアントおよび認証サーバの両者はＯＴＰ値を計算することができる。サーバにより受信された値がそのサーバにより計算された値と一致するならば、ユーザは認証されるべきであるとされる。サーバで認証が生じた場合には、そのサーバはカウンタ値を１だけインクリメントする。
【００１２】
サーバのカウンタ値は成功したＯＴＰ認証後にインクリメントされることができるが、トークンにおけるカウンタはボタンが押される都度インクリメントされることができる。このため、サーバとトークンのカウンタ値はしばしば同期が外れる可能性がある。事実、ユーザ環境与えられたサーバとトークンが常に同期が外れているチャンスがある（例えばユーザが必要がないのにボタンを押すとき、ボタンが偶発的に押されるとき、ユーザがＯＴＰをミスタイプするとき等）。
【００１３】
サーバのカウンタは有効なＯＴＰが与えられたときにのみインクリメントするため、トークンにおけるサーバのカウンタ値はトークンにおけるカウンタ値よりも常に少ないことが予測される。再同期がユーザまたは企業のＩＴ部門のいずれかの負担とならないことが確実にされることを確認することが重要である。
【００１４】
このようなシナリオにおけるカウンタの同期は、次のｎ個のＯＴＰ値をサーバが計算して（ｎは整数）、一致していることを決定することによって達成される。トークンにおけるカウントとサーバおけるカウントとの間の差が５０であると仮定した場合には、強力な認証サーバの構成に応じて、そのサーバは最大で次の５０のＯＴＰ値を計算しなければならない。したがって、例えば正確なＯＴＰがｎ＋１２の値にあることが発見された場合には、サーバはそのユーザを認証し、その後、カウンタを１２だけインクリメントする。
【００１５】
サーバにより容易に計算されることのできるｎに対する値を注意深く選択することが重要である。サーバがＯＴＰ値を永久に検査しないことを確実にして、それにより１０進サービスアタックに屈伏する上限が必要である。
【００１６】
ＨＭＡＣ−ＳＨＡ１値を６文字値に切捨てることによって、特に数字だけが使用されている場合にマウントに対して容易にアタックする強力な力を与える可能性がある。このため、このようなアタックは強力な認証サーバにおいて検出されて停止されることができる。サーバが妥当でないＯＴＰを計算するたびにこれを記録して、例えば幾つかのポイントで同じソースからの確認に対して将来のリクエストを拒否して被害を受けることを阻止する手段を構成する。その代りに、ユーザは確認の試みの間の長時間の待機を強制されることができる。
【００１７】
ユーザがロックアウトされると、そのユーザは、例えばシーケンス中の多数のＯＴＰに入るためにユーザを必要とするウエブインターフェースを提供することによって“自己ロック解除”することができて、それらかトークンを有することが証明される。
【００１８】
共有されたシークレットがカウンタと組合わされると、１６０ビット（２０バイト）のＨＭＡＣ−ＳＨＡ１結果が得られる。１実施形態では、我々のＯＴＰに対してこの情報の最大で４バイトである。ＨＭＡＣＲＦＣ（ＲＦＣ2104-ＨＭＡＣ：メッセージ認証に対するキードハッシング）はさらにセクション５のＨＭＡＣ結果の半分以上を使用しなければならないと警告している。切捨てられた出力は：
ＨＭＡＣのアプリケーションがＨＭＡＣ計算の左側のｔビットを出力することによってＨＭＡＣの出力の切捨てを選択することが可能であり、…出力長ｔはハッシュ出力の長さの半分より小さくないことを推奨しており、…８０ビット（アタッカにより予測されるのに必要なビット数に付いての適当な低い限度）より少なくはない。
【００１９】
したがって、ＨＭＡＣまたはＳＨＡ１のいずれも弱めることのない方法でＨＭＡＣ結果の４バイトまたはさらに少ないバイトだけを選択する別の方法が必要である。
【００２０】
［ダイナミックオフセット切捨て］
この技術の目的は、ＨＭＡＣ−ＳＨＡ１結果から４バイトのダイナミック２進コードを抽出し、その一方でＭＡＣの暗号の強さの大部分を維持することである。
【００２１】
１．最後のバイト（バイト１９）を取り、
２．オフセット値として低いオーダーの４ビットをマスクして除去し、
３．オフセット値を使用してＨＭＡＣ−ＳＨＡ１結果のバイト中へインデックスし、
４．ダイナミック２進コードとして後続する４バイトを戻す。
【００２２】
以下のコード例は、hmac resultはＨＭＡＣ−ＳＨＡ１結果を有するバイトアレイを与えるダイナミック２進コードの抽出を記載したものである。
【００２３】
【数１】
【００２４】
以下はこの技術の使用例である。
【００２５】
【数２】
【００２６】
１．最後のバイト（バイト19）は６値0×5aを有する。
２．下位の４ビットの値は0×aである（オフセット値）。
３．オフセット値はバイト10（10×a)である。
４．バイト10で始まる４バイトの値は0×50ef7f19であり、それはダイナミックに２進コードである。
我々は３１ビットの、符号のない、ビッグエンド（big endian）の整数として２進コードを処理し、その第１のバイトは0×7fでマークされる。
【００２７】
所定のシークレットのためのＯＴＰおよびムービングファクタは、３つのパラメータ、すなわち、エンコードベース、コードデジット、ハズチェックサムに基づいて変化することができる。エンコードベースとして１０、真（TRUE）へセットされたコードデジットおよびバスチェックサムとして７により、上記の例を継続する。
・６値0×50ef7f19を1357872921ベース10に変換する。
・最後の７デジットは7872921である。
・コードデジットのクレジットカードチェックサムは７をチェックサムとして計算する。10-((5+8+5+2+9+2+2)mod10)＝10-(33mod10)＝10-3＝7
・以下のＯＴＰ：78729217が得られる。
【００２８】
以下はこのアプリケーションで使用される用語集である。
チェックサムデジット；コードデジットに対してクレジットカードチェックサムアルゴリズムを適用した結果である。このデジットは随意である。このチェックは任意の単一の順序変更または任意の単一のミスタイプされた文字を捕捉しなければならない。
【００２９】
コードデジット；このパラメータは２進コードから得られるデジットの数である。２進コードをエンコードベースに変換し、少なくともコードデジットである０をパッドし、右側（下位）デジットを採用することにより計算される。エンコードベースとして１０により９を越えないコードデジットが３１ビットの２進コードによりサポートされることができる。
【００３０】
クレジットカードチェックサムアルゴリズム；このチェックサムアルゴリズムは任意の単一のミスタイプされたデジットまたは任意の単一の隣接する２つのデジットの順序変更を捕捉できる利点を有している。これらは最も普通のタイプのユーザエラーである。
【００３１】
エンコードベース；このパラメータはパスワードに使用されるもののベースを示している。ベース１０は数値パッドで入力されることができるので好ましいベースである。
【００３２】
ハズチェックサムデジット；このブールパラメータはチェックサムデジットがＯＴＰを生成するために付加されなければならないか否かを示す。チェックサムデジットが存在しないならば、そのコードデジットがＯＴＰとして使用される。チェックサムデジットが存在すれば、クレジットカードチェックサムアルゴリズムへの入力としてそのコードデジットを使用してそれが計算される。
【００３３】
ＯＴＰ；ワン・タイム・パスワード。この値は、存在するものがあれば、コードデジットの右にチェックサムデジットを付加することにより構成される。チェックサムデジットが存在しなければ、ＯＴＰはコードデジットと同じである。
ワン・タイムの数値はハッシュビット中で第１のシフトを行い、その後同期ビットをシフトし、その後、前の中間値のチェック関数（）の結果をシフトすることにより計算される。
【００３４】
２進値はその後、適当な文字値に変換される。パスワードの３つの類似した文字表示、すなわち１０進数、６進数、アルファベットおよび数字が存在する。
【００３５】
【数３】
【００３６】
１０進数
トークンはダイナミック２進コードを１０進数に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、１０進数トークンは２進コードを１０進数に変換し、最後の６デジットを表示する。
【００３７】
６進数
トークンはダイナミック２進コードを６進数に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、６進数トークンは２進コードを６進数に変換し、最後の６デジットを表示する。
【００３８】
アルファベットおよび数字
トークンはダイナミック２進コードをベース３２に変換し、それから最後のコードデジットプラス随意のチェックサムを表示することができる。例えば、チェックサムがない６デジットに対して、ベース３２のトークンは２進コードをベース３２に変換し、最後の６デジットを表示する。
【００３９】
ＰＩＮ
真の２ファクタ認証トークンのために、ＯＴＰの“あなたの有しているもの”の値に“あなたの知っているもの”の値を付加することができる。この値は通常静的なＰＩＮまたはユーザだけに知られているパスワードである。このセクションでは、本発明による静的ＰＩＮを確認するために３つの別のアーキテクチャについて説明する。
クラウド中のＰＩＮ確認
クラウド中のＰＩＮ確認を可能にするために、単一のＰＩＮは単一のトークンに結合されることができる。ＰＩＮは暴露されないことを確実にするためにワイヤ上で保護されなければならない。ＰＩＮの管理（設定、変更）は強力な認証サービスによって行われなければならない。
【００４０】
企業におけるＰＩＮ確認
クラウド中のＰＩＮ確認を可能にすることは単一のトークンに対する多数のＰＩＮ確認を意味している。
ＰＩＮは企業のセキュリティワールドに残されてはならない。ＰＩＮの管理は企業によって行われることができる。
【００４１】
トークンにおけるＰＩＮ確認
この実施形態はトークンにおけるキーパッドを使用して構成されることができる。ＰＩＮは絶対にワイヤで送ってはならず、ＯＴＰアルゴリズムに対するシードとして使用されることができる。ＰＩＮは単にトークンのロックを解除するために使用されることができる。
【００４２】
［データフローの例］
このセクションでは２つのデータフローのシナリオについて説明する。第１のシナリオでは、強力な認証サービスがトークンと関係するユーザ名を知らないと仮定する。このシナリオでは、ＰＩＮの管理動作はそれらのユーザ名の代りにそれらのトークンＳＮを入力するようにユーザに要求すると仮定している。
【００４３】
第２のシナリオは、トークンＳＮの代りにユーザ名が強力な認証サービス中へのキーであることを除いては第１のシナリオに非常によく類似している。この場合について幾つかの論点がある。第１に、ユーザ名はサービス機関に知られており、第２に、ユーザ名からトークンＳＮへの特有のマップを確実に行う方式が得られなければならない。
【００４４】
図１は、本発明の１実施形態による認証手順を示している。それにおいて以下のことが仮定されている。
・トークンＳＮとＳは強力な認証サービスへ分配され、
・カストマアカウントは各トークンに関連され、
・ＰＩＮは特定のトークンに関連され、
・強力な認証サービスはＤＢ中のＰＩＮのＳＨＡ−１ハッシュのみを保存し、
・トークンＳＮは企業におけるユーザアカウントに対する属性として付加され、プラグインによりユーザ名をＳＮへマップする。
【００４５】
強力な認証サーバ110と、企業の認証サーバ120と、クライアント130とは、例えばネットワーク（図示せず）により結合されている。図１に示されているように、クライアント130に位置するユーザは企業のサーバ120に保護されたリソースへアクセスするためのリクエストを送信する。そのサーバはリソースへのアクセスが認証を必要とするか否かを決定する。認証を必要とする場合には、そのサーバ120は“認証を必要とされる”のメッセージをクライアント130に送る。ユーザはユーザ名とパスワードの提示を促される。ユーザはそのユーザのトークンのボタン（図示せず）を押してＯＴＰを得ることができる。ＯＴＰは上述のように、例えばトークンシークレットと、トークンに記憶されているカウントに対する現在の値の組み合わせをハッシュすることによって発生される。その後、ユーザはそのユーザ名と，トークンにより与えられたＯＴＰに連結された個人的識別番号（ＰＩＮ）を入力する。この情報は企業のサーバ120に送られる。企業のサーバ120はユーザ名に基づいてトークンの通し番号を探して、その通し番号とＰＩＮ＋ＯＴＰを認証サーバ110に送る。認証サーバ110は通し番号に基づいて記録を探してＰＩＮのローカルにハッシュされた値とシークレットと目的とされているカウントとを得る。これは、トークンのシークレットが特有に割当てられているトークンと認証サーバ110との間で共有されることができるために可能である。それから、認証サーバ110はトークンに対するシークレットと認証サーバに記憶されているそのトークンに対するカウントの現在値とに基づいてＯＴＰを計算する。計算されたＯＴＰが受信されたＯＴＰと整合していれば、認証サーバ110におけるカウントの値が１だけインクリメントされる。そうでなければ、認証サーバは、トークンに対するカウントをインクリメントし、トークンに対するシークレットと共にそれをハッシュすることによってＯＴＰを計算しようと再度試みる。これは、上述したように、認証サーバ110におけるカウント値がトークンにおけるカウント値とは異なっていてもよい（図示せず）ために行われることができる。この手順は、トークンにおけるカウント値にカウント値が追いつくことが可能な合理的な回数で反復されることができる。１実施形態では、認証サーバにおけるトークンの認証を試みるそのような反復の回数は予め定められた同じ回数、例えば１２回の反復後に終了される。トークンが認証サーバ110によって認証されることが成功できない場合には、認証サーバ110は“認証されず”のメッセージを企業のサーバ120に送る。トークンが認証されることに成功した場合には、認証サーバ110は“認証された”のメッセージを企業のサーバ120に送る。認証サーバ110から得られた結果に基づいて、企業のサーバは、クライアントからのリソースをアクセスするためにリクエストされた許可をそれぞれ拒否または承認する。
【００４６】
図２は、本発明の別の実施形態による認証手順を示している。それにおいて以下のことが仮定されている。
・トークンＳＮとＳは強力な認証サービスへ分配され、
・カストマアカウントは各トークンに関連され、
・ＰＩＮは特定のトークンに関連され、
・強力な認証サービスはＤＢ中のＰＩＮのＳＨＡ−１ハッシュのみを保存し、
・ユーザ名は企業の認証サーバから強力な認証サーバへ転送される。
【００４７】
図２の認証手順は、ユーザ名とＰＩＮ＋ＯＴＰがクライアント130から企業のサーバ120に送られる直後までは図１と同じである。しかしながら、ユーザ名に基づいてトークン通し番号を探すのではなく、企業のサーバ120は認証リクエスト（ユーザ名とＰＩＮ＋ＯＴＰを含んでいる）を認証サーバ110に送信する。認証サーバ110はユーザ名に基づいて記録を探してＰＩＮを認証し、その後プロセスの残りに対しては図１に示されているのと同じ手順にしたかって処理が行われる。
【符号の説明】
【００４８】
１１０ 強力な認証サービス
１２０ 企業の認証サーバ
１３０ クライアント
【特許請求の範囲】
【請求項１】
エンタープライズ認証サーバに保護されているリソースへクライアントがアクセスするためのリクエストを、内部にカウンタを有するトークンを使用して、前記トークンと対応するように関連付けられているカウンタを有するワン・タイム・パスワードの強力な認証サーバを介して認証する方法において、
クライアントを認証するためのリクエストを前記エンタープライズ認証サーバにおいて受信するステップを具備し、
前記リクエストは、ユーザ名と、前記ユーザに関する個人識別番号と、トークンにより生成される第１ワン・タイム・パスワードと、を含み、
前記第１ワン・タイム・パスワードは、前記トークンにおけるカウンタの値と、前記トークンと前記エンタープライズ認証サーバとの間で共有されているシークレットと、に基づいて生成され、
前記エンタープライズ認証サーバは、該サーバに接続されている記憶装置から前記ユーザ名に基づきトークンの通し番号を検索し、該通し番号と、前記ユーザに関する個人識別番号と、前記トークンにより生成される第１ワン・タイム・パスワードと、を前記強力な認証サーバに送信し、
前記方法はさらに、前記強力な認証サーバにおいて、
前記通し番号に基づいて前記トークンに対応する前記カウンタの値を前記強力な認証サーバに接続されている記憶装置から検索するステップと、
前記通し番号に基づいて前記トークンに対応する前記共有されているシークレットを前記記憶装置から検索するステップと、
検索された前記カウンタの値および前記トークンに対応する前記シークレットに基づいて第２ワン・タイム・パスワードを計算するステップと、
前記第２ワン・タイム・パスワードを第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと同じである場合には、前記クライアントシステムは認証され、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと同じでない場合には、前記強力な認証サーバにおいて、
前記認証サーバにおける前記カウンタの値をインクリメントして、そのインクリメントされたカウンタと前記シークレットとに基づいて第３ワン・タイム・パスワードを計算するステップと、
前記第３ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第３ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致しない場合には、前記カウンタのインクリメントとワン・タイム・パスワードの再計算とが所定の回数、または前記再計算されたワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致するまで繰り返されることを特徴とする認証方法。
【請求項２】
シークレットは対称暗号キーであることを特徴とする請求項１に記載の方法。
【請求項３】
再計算されたワン・タイム・パスワードが、前記所定の回数の終了までに、受信されたワン・タイム・パスワードと一致しない場合には、前記クライアントシステムの認証は否定されることを特徴とする請求項１に記載の方法。
【請求項４】
エンタープライズ認証サーバに保護されているリソースへクライアントがアクセスするためのリクエストを、内部にカウンタを有するトークンを使用して、前記トークンと対応するように関連付けられているカウンタを有するワン・タイム・パスワードの強力な認証サーバを介して認証する方法において、
クライアントを認証するためのリクエストを前記エンタープライズ認証サーバにおいて受信するステップを具備し、
前記リクエストは、ユーザ名と、前記ユーザに関する個人識別番号と、トークンにおいて生成される第１ワン・タイム・パスワードと、を含み、
前記第１ワン・タイム・パスワードは、前記トークンにおけるカウンタの値と、前記トークンと前記エンタープライズ認証サーバとの間で共有されているシークレットと、に基づいて生成され、
前記エンタープライズ認証サーバは、前記受信したリクエストの前記ユーザ名と、前記ユーザに関する個人識別番号と、前記トークンにより生成される第１ワン・タイム・パスワードと、を前記強力な認証サーバに転送し、
前記方法はさらに、前記強力な認証サーバにおいて、
前記ユーザ名に基づいて、前記トークンに対応する前記カウンタの値を前記強力な認証サーバに接続されている記憶装置から検索するステップと、
前記ユーザ名に基づいて、前記トークンに対応する前記シークレットを、前記記憶装置から検索するステップと、
前記検索されたカウンタの値および前記トークンに対応する前記シークレットに基づいて、第２ワン・タイム・パスワードの値を計算するステップと、
前記第２ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードに一致している場合には、前記クライアントが前記リソースへアクセスするためのリクエストは認証され、
前記第２ワン・タイム・パスワードが前記第１パスワードに一致していない場合には、前記強力な認証サーバにおいて、
認証サーバにおける前記カウンタの値をインクリメントするステップと、
前記インクリメントされたカウンタおよび前記シークレットに基づいて第３ワン・タイム・パスワードを計算するステップと、
前記第３ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第３ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致しない場合には、前記カウンタのインクリメントとワン・タイム・パスワードの再計算とが、所定の回数、または前記計算されたワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致するまで繰返されることを特徴とする認証方法。
【請求項５】
シークレットは対称暗号キーであることを特徴とする請求項４に記載の方法。
【請求項６】
前記カウンタのインクリメントおよび前記パスワードの再計算は所定の回数繰り返され、前記所定の回数の終了までに、前記再計算されたパスワードのいずれもが前記第１パスワードと一致しない場合には、前記リソースへアクセスするための前記リクエストは否認されることを特徴とする請求項４に記載の方法。
【請求項１】
エンタープライズ認証サーバに保護されているリソースへクライアントがアクセスするためのリクエストを、内部にカウンタを有するトークンを使用して、前記トークンと対応するように関連付けられているカウンタを有するワン・タイム・パスワードの強力な認証サーバを介して認証する方法において、
クライアントを認証するためのリクエストを前記エンタープライズ認証サーバにおいて受信するステップを具備し、
前記リクエストは、ユーザ名と、前記ユーザに関する個人識別番号と、トークンにより生成される第１ワン・タイム・パスワードと、を含み、
前記第１ワン・タイム・パスワードは、前記トークンにおけるカウンタの値と、前記トークンと前記エンタープライズ認証サーバとの間で共有されているシークレットと、に基づいて生成され、
前記エンタープライズ認証サーバは、該サーバに接続されている記憶装置から前記ユーザ名に基づきトークンの通し番号を検索し、該通し番号と、前記ユーザに関する個人識別番号と、前記トークンにより生成される第１ワン・タイム・パスワードと、を前記強力な認証サーバに送信し、
前記方法はさらに、前記強力な認証サーバにおいて、
前記通し番号に基づいて前記トークンに対応する前記カウンタの値を前記強力な認証サーバに接続されている記憶装置から検索するステップと、
前記通し番号に基づいて前記トークンに対応する前記共有されているシークレットを前記記憶装置から検索するステップと、
検索された前記カウンタの値および前記トークンに対応する前記シークレットに基づいて第２ワン・タイム・パスワードを計算するステップと、
前記第２ワン・タイム・パスワードを第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと同じである場合には、前記クライアントシステムは認証され、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと同じでない場合には、前記強力な認証サーバにおいて、
前記認証サーバにおける前記カウンタの値をインクリメントして、そのインクリメントされたカウンタと前記シークレットとに基づいて第３ワン・タイム・パスワードを計算するステップと、
前記第３ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第３ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致しない場合には、前記カウンタのインクリメントとワン・タイム・パスワードの再計算とが所定の回数、または前記再計算されたワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致するまで繰り返されることを特徴とする認証方法。
【請求項２】
シークレットは対称暗号キーであることを特徴とする請求項１に記載の方法。
【請求項３】
再計算されたワン・タイム・パスワードが、前記所定の回数の終了までに、受信されたワン・タイム・パスワードと一致しない場合には、前記クライアントシステムの認証は否定されることを特徴とする請求項１に記載の方法。
【請求項４】
エンタープライズ認証サーバに保護されているリソースへクライアントがアクセスするためのリクエストを、内部にカウンタを有するトークンを使用して、前記トークンと対応するように関連付けられているカウンタを有するワン・タイム・パスワードの強力な認証サーバを介して認証する方法において、
クライアントを認証するためのリクエストを前記エンタープライズ認証サーバにおいて受信するステップを具備し、
前記リクエストは、ユーザ名と、前記ユーザに関する個人識別番号と、トークンにおいて生成される第１ワン・タイム・パスワードと、を含み、
前記第１ワン・タイム・パスワードは、前記トークンにおけるカウンタの値と、前記トークンと前記エンタープライズ認証サーバとの間で共有されているシークレットと、に基づいて生成され、
前記エンタープライズ認証サーバは、前記受信したリクエストの前記ユーザ名と、前記ユーザに関する個人識別番号と、前記トークンにより生成される第１ワン・タイム・パスワードと、を前記強力な認証サーバに転送し、
前記方法はさらに、前記強力な認証サーバにおいて、
前記ユーザ名に基づいて、前記トークンに対応する前記カウンタの値を前記強力な認証サーバに接続されている記憶装置から検索するステップと、
前記ユーザ名に基づいて、前記トークンに対応する前記シークレットを、前記記憶装置から検索するステップと、
前記検索されたカウンタの値および前記トークンに対応する前記シークレットに基づいて、第２ワン・タイム・パスワードの値を計算するステップと、
前記第２ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第２ワン・タイム・パスワードが前記第１ワン・タイム・パスワードに一致している場合には、前記クライアントが前記リソースへアクセスするためのリクエストは認証され、
前記第２ワン・タイム・パスワードが前記第１パスワードに一致していない場合には、前記強力な認証サーバにおいて、
認証サーバにおける前記カウンタの値をインクリメントするステップと、
前記インクリメントされたカウンタおよび前記シークレットに基づいて第３ワン・タイム・パスワードを計算するステップと、
前記第３ワン・タイム・パスワードを前記第１ワン・タイム・パスワードと比較するステップと、
を具備し、
前記第３ワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致しない場合には、前記カウンタのインクリメントとワン・タイム・パスワードの再計算とが、所定の回数、または前記計算されたワン・タイム・パスワードが前記第１ワン・タイム・パスワードと一致するまで繰返されることを特徴とする認証方法。
【請求項５】
シークレットは対称暗号キーであることを特徴とする請求項４に記載の方法。
【請求項６】
前記カウンタのインクリメントおよび前記パスワードの再計算は所定の回数繰り返され、前記所定の回数の終了までに、前記再計算されたパスワードのいずれもが前記第１パスワードと一致しない場合には、前記リソースへアクセスするための前記リクエストは否認されることを特徴とする請求項４に記載の方法。
【図１】
【図２】
【図２】
【公開番号】特開２０１１−１９２３１０（Ｐ２０１１−１９２３１０Ａ）
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願番号】特願２０１１−１３８１５５（Ｐ２０１１−１３８１５５）
【出願日】平成２３年６月２２日（２０１１．６．２２）
【分割の表示】特願２００７−５００９１３（Ｐ２００７−５００９１３）の分割
【原出願日】平成１７年２月２３日（２００５．２．２３）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願日】平成２３年６月２２日（２０１１．６．２２）
【分割の表示】特願２００７−５００９１３（Ｐ２００７−５００９１３）の分割
【原出願日】平成１７年２月２３日（２００５．２．２３）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]