JP2007523431A - トークン認証システムおよび方法 - Google Patents

Abstract

ワン・タイム・パスワードを計算する方法に関する。シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーでもよく、或いは共有されたシークレット対称キーでもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、認証サーバにおけるワン・タイム・パスワードの各計算により単調に増加する。ＯＴＰは連結されたシークレットとカウントをハッシュすることによって計算されることができる。その結果は切捨てることができる。
【選択図】 図１

Description

本発明は、認証に関し、特にハードウエア装置を使用する認証に関する。

ネットワーク中においてデータまたはサービスにアクセスするリクエストを許可するか否かを決定する通常のステップはリクエストしているユーザを識別して認証することである。認証はユーザのアイデンティティを確認するプロセスを含んでいる。既知の識別および認証システムはユーザ識別子（“ユーザｉｄ”）とユーザに対するシークレット（“パスワード”）との関係を含んでいる。パスワードはユーザと認証サービス機関との間で共有されているシークレットである。ユーザは自己のユーザｉｄとパスワードを認証サービス機関に提示し、その認証サービス機関はそれらをそのサービス機関に記憶されているユーザｉｄおよび関連するパスワードと比較する。それらが整合している場合には、ユーザは認証されたとされる。整合しない場合には、ユーザは認証されないとされる。

トークンはユーザを認証するために使用されることのできる装置である。それは１以上のシークレットを含むことができ、それらのシークレットの幾つかは確認センターと共有されることができる。例えば、トークンはワン・タイム・パスワード（ＯＴＰ）を計算するベースとして使用されることのできるシークレットキーを記憶することができる。ＯＴＰはかって生成され、その後は再使用されていない番号（またはアルファベット列）であってもよい。トークンはＯＴＰを発生してそれを特有のトークン通し番号と共に認証サーバへ送る。認証サーバは受信された通し番号によりそのトークンに対するそのシークレットキーのコピーを使用してＯＴＰを計算することができる。ＯＴＰが整合する場合には、ユーザは認証されるべきであるとされる。ユーザからトークンへのリンクをさらに強力にするために、ユーザはトークンのロックを解除することにより入力されなければならないトークンと共有されたシークレット個人識別番号（ＰＩＮ）を設定することができる。その代りにＰＩＮはユーザと、トークンと、認証サーバとの間で共有されることができ、ＯＴＰを生成するための他のファクターと共に使用されることができる。トークンは典型的に許可されていない開示からそのシークレットを保護するために盗用に対する抵抗力の高い手段を具えている。

本発明の目的は、ワン・タイム・パスワードを計算する方法を提供することである。

シークレットはカウントと連結され、シークレットは特有にトークンに割当てられる。シークレットは私設キーであってもよく、或いは共有されたシークレット対称キーであってもよい。カウントはトークンにおいて単調に増加する数であり、トークンにおいて発生さたれたワン・タイム・パスワードの番号を有している。そのカウントはまた認証サーバにおいて追跡され、それにおいて認証サーバにおけるワン・タイム・パスワードの各計算と共に単調に増加する。ＯＴＰは連結されたシークレットとカウントとをハッシュすることによって計算されることができる。その結果は切捨てることができる。

本発明の１実施形態では、ハードウエア装置においてワン・タイム・パスワード（ＯＴＰ）を発生するためのプロトコルを含んでおり、それはユーザを認証するために使用される。ＯＴＰはトークンにより発生され、そのトークンは、それが含まれているソフトウエアおよび情報の許可されない変更や、開放を阻止して、その適切な機能を確保するためのメカニズムを含んでいる物理的な装置であることができる。

このプロトコルの１実施形態は、シーケンスベースであることができ、２ファクター、例えばユーザの知識（個人識別番号、ユーザと認証サービス機関との間で共有されるシークレットのようなもの）およびユーザがへ所有している例えばトークンのような特別の特性を有する物理的装置（例えば私設キーまたは共有された対称キーのような特有のシークレットキー）である。

ＯＴＰを発生するためのプロトコルはカウンタに基づくことが可能であり、例えばＯＴＰがトークンからリクエストされる回数に基づいた単調に増加する数である。ＯＴＰの値はトークン上に表示されることができ、例えばネットワークに結合されているコンピュータに結合されているキーボードを介してユーザにより容易に読取られ、入力されることができる。ＯＴＰはＲＡＤＩＵＳシステムによって転送されることができる。

本発明によるプロトコルの１実施形態は、増加するカウンタ値と、トークンおよび認証サービス機関（“強力な認証”サービス）に対してのみ知られている静的対称キーとに基づくことができる。ＯＴＰ値はＲＦＣ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 はユーザ名に基づいて記録を探してＰＩＮを認証し、その後プロセスの残りに対しては図１に示されているのと同じ手順にしたかって処理が行われる。

本発明の１実施形態による認証手順のフロー図。 本発明の別の実施形態による認証手順のフロー図。

Claims (9)

1. カウントとシークレットとを連結し、前記シークレットは特有にトークンに割当てられてトークンと認証サーバとの間で共有され、前記カウントはトークンにおいて発生されたワン・タイム・パスワードの番号を有し、トークンにおいて単調に増加し、ワン・タイム・パスワードの認証サーバにおける各計算により認証サーバにおいて単調に増加する数であり、
   前記連結されたシークレットとカウントに基づいてハッシュを計算し、
   そのハッシュの結果を切捨ててワン・タイム・パスワードを得るステップを含んでいるワン・タイム・パスワードの計算方法。
2. リソースへアクセスするためのリクエストを認証する方法において、
   トークンに特有に関係する通し番号と、ユーザに関する個人識別番号と、トークンにおいて発生されるワン・タイム・パスワードとを含んでいる認証に対するリクエストを認証サーバにおいて受信し、ワン・タイム・パスワードはトークンにおけるカウントの値と、トークンと認証サーバとの間で共有されるシークレットとに基づいており、
   通し番号に基づいてトークンに対応するカウントの値を認証サーバにおいて検索し、
   通し番号に基づいてトークンに対応するシークレットを認証サーバにおいて検索し、
   カウントの値の検索およびトークンに対応するシークレットに基づいてワン・タイム・パスワードの値を認証サーバにおいて計算し、
   この計算されたワン・タイム・パスワードを受信されたワン・タイム・パスワードと比較し、
   計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードに対応している場合には、そのリクエストは認証されるべきものであると決定され，
   計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードに対応していない場合には、認証サーバにおけるカウントの値をインクリメントして、そのインクリメントされたカウントとシークレットとに基づいてワン・タイム・パスワードが再計算され、その再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと比較され、
   再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応しない場合にはカウント値のインクリメントとワン・タイム・パスワードの再計算とが繰返されされ、再計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応するまで繰返されるステップを含んでいる認証方法。
3. ハッシュ関数はＳＨＡ−１である請求項２記載の方法。
4. シークレットは対称暗号キーである請求項２記載の方法。
5. カウントのインクリメントおよびワン・タイム・パスワードの再計算は予め定められた回数反復され、予め定められた回数の反復の終了したとき再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応しない場合には、そのリクエストは認証されないものと決定される請求項２記載の方法。
6. リソースへアクセスするためのリクエストを認証する方法において、
   ユーザに関する特有のユーザ名と、ユーザに関する個人識別番号と、トークンにおいて発生されるワン・タイム・パスワードとを含んでいる認証に対するリクエストを認証サーバにおいて受信し、ワン・タイム・パスワードはトークンにおけるカウントの値と、トークンと認証サーバとの間で共有されるシークレットとに基づいており、
   ユーザ名に基づいてトークンに対応するカウントの値を認証サーバにおいて検索し、
   ユーザ名に基づいてトークンに対応するシークレットを認証サーバにおいて検索し、
   カウントの値の検索およびトークンに対応するシークレットに基づいてワン・タイム・パスワードの値を認証サーバにおいて計算し、
   その計算されたワン・タイム・パスワードを受信されたワン・タイム・パスワードと比較し、
   計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードに対応している場合には、そのリクエストは認証されるべきものであると決定され，
   計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードに対応していない場合には、認証サーバにおけるカウントの値をインクリメントして、そのインクリメントされたカウントおよびシークレットに基づいてワン・タイム・パスワードが再計算され、その再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと比較され、
   再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応しない場合にはカウント値のインクリメントとワン・タイム・パスワードの再計算とが繰返されされ、再計算されたワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応するまで繰返されるステップを含んでいる認証方法。
7. ハッシュ関数はＳＨＡ−１である請求項６記載の方法。
8. シークレットは対称暗号キーである請求項６記載の方法。
9. カウントのインクリメントおよびワン・タイム・パスワードの再計算は予め定められた回数反復され、予め定められた回数の反復の終了したとき再計算されたてワン・タイム・パスワードが受信されたワン・タイム・パスワードと対応しない場合には、そのリクエストは認証されないものと決定される請求項６記載の方法。

Images