ワンタイムパスワード
トークンは、キーＫおよびカウンタ値Ｃに基づいて、ＨＭＡＣ−ＳＨＡ−１値を発生させ、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、ワンタイムパスワードを計算する。ここで、Digitはワンタイムパスワードの数字の数である。Ｋおよびバリデーションサーバ自体のカウンタ値Ｃ’を使用して、それ自体のバージョンのパスワードを計算するバリデーションサーバによって、ワンタイムパスワードを確認することができる。最初の不整合があった場合に、バリデーションサーバは、ルックアヘッドウィンドウ内でカウンタＣとＣ’との間の同期化の欠如を補償する。ルックアヘッドウィンドウのサイズは、パラメータｓによって設定可能である。
【発明の詳細な説明】
【発明の分野】
【０００１】
本発明の分野は、コンピュータの安全性である。さらに詳細に述べると、ワンタイムパスワードによる認証である。
【発明の背景】
【０００２】
現在、２要素認証の展開は、範囲およびスケールが非常に限定されたままである。脅威および攻撃のレベルが一層より高くなってきているにもかかわらず、大部分のインターネットアプリケーションは、ユーザアクセスを取り締まるための軟弱な認証スキームに依然として依存している。ハードウェアおよびソフトウェア技術ベンダ間の相互運用性の欠如が、２要素認証技術の採用における制約要因である。特に、ハードウェアおよびソフトウェアのコンポーネントは、知的所有権下にある技術を通して緻密に結合されていることが多く、結果的に、解決に高コストとなり、採用が少なく、および革新が限定的となる。
【０００３】
過去２年間における、ネットワーク脅威の急速な増加は、インターネット上の認証の主要手段としての静的パスワードの不完全さを明らかにした。同時に、ネットワークに対する認証のみに使用される高価な単機能型のデバイスをエンドユーザが所持することを要求する現在のアプローチは、明らかに適切な対応策でない。２要素認証をインターネット上で普及するために、広範囲なアプリケーションにわたって機能可能な、より柔軟性あるデバイスに２要素認証を埋め込まなければならない。
【０００４】
ワンタイムパスワードは、確かに、ネットワークアクセスを安全にするための最も簡単で最も普及している２要素認証の形態のうちの１つである。例えば、大企業では、仮想私設ネットワークアクセスは、リモートユーザの認証のために、ワンタイムパスワードのトークンの使用を要求することが多い。エアギャップデバイスは、任意のクライアントのデスクトップソフトウェアのユーザマシーンへのインストールを必要としないので、ワンタイムパスワードは、ＰＫＩまたは生体測定のような、より強力な認証の形態を好むことが多い。したがって、これにより、ホームコンピュータ、キオスクおよびパーソナルデジタルアシスタントを含む複数のマシーンにわたってローミングすることができるようになる。
【発明の概要】
【０００５】
本発明の実施形態にしたがうと、何らかのハードウェア製造業者またはソフトウェアデベロッパによって、ワンタイムパスワードアルゴリズムを実現して、相互運用性のある認証デバイスおよびソフトウェアエージェントを生成することができる。Ｊａｖａ（登録商標）スマートカード、ＵＳＢドングルおよびＧＳＭのＳＩＭカードのような高容量デバイスにアルゴリズムを埋め込むことができるように、アルゴリズムはイベントベースであってもよい。インターネット技術標準化委員会（ＩＥＴＦ）の取引条件のもとで、アルゴリズムは、デベロッパコミュニティにとって自由に利用可能になる。
【詳細な説明】
【０００６】
本発明の実施形態にしたがうと、アルゴリズムは、シーケンスまたはカウンタベースとすることが可能であり、そして、バッテリ、ボタン数、計算馬力およびディスプレイのサイズに関する必要条件を最小限にすることによって、ハードウェアで効率的に実現することができる。アルゴリズムは、何らかの数入力をサポートしないトークンを使用して動作させることができるが、安全なＰＩＮパッドのような、より高性能化したデバイスで使用することも可能である。
【０００７】
トークン上で表示される値は、ユーザによって容易に読み取られ、パーソナルコンピュータ、携帯電話機、現金自動預払機または他の何らかの適切なデバイスのような別のデバイスに入力される。このことにより、ワンタイムパスワード（ＯＴＰ）値が、適度な長さのものであるように要求される。多くのケースにおいて、ＯＴＰ値は、安全性の理由から少なくとも６数字の値であるべきである。電話機のような単純なキーパッドを備えたデバイス上にＯＴＰ値を容易に入力できるように、ＯＴＰ値は数字のみであると便利である。
【０００８】
カウンタを再同期化するのに利用可能なユーザフレンドリなメカニズムがある。アルゴリズムには、強力な共有シークレットが使用されるべきである。このために、共有シークレットの長さは、１２８ビット、または、より長いビットである。
【０００９】
以下の表記法およびシンボルを使用して、本発明にしたがったアルゴリズムの実施形態を説明する。
【００１０】
ストリングはバイナリストリングを意味しており、バイナリストリングは、０および１のシーケンスを意味している。
【００１１】
ｓがストリングである場合、｜ｓ｜はストリングの長さを示す。
【００１２】
ｎが数字である場合、｜ｎ｜は絶対値を示す。
【００１３】
ｓがストリングである場合、ｓ[ｉ]はストリングのｉ番目のビットを示す。ビットは、０からビットの番号が振られているので、ｓ＝ｓ[０]ｓ[１]...ｓ[ｎ−１]となる。ここで、ｎ＝｜ｓ｜はｓの長さである。
【００１４】
（ストリングを数にする）ＳｔＴｏＮｕｍは、バイナリの入力ストリングｓの１０進法の表示を返す関数を示す。例えば、ＳｔＴｏＮｕｍ（１１０）＝６である。
【００１５】
以下の表記法をシンボルに使用する。
Ｃは、８バイトのカウンタ値、ムービング係数である。このカウンタは、ＯＴＰ発生器（例えば、クライアント）とＯＴＰバリデイター（例えば、サーバ）との間を同期化させることができる。
Ｋは、クライアントとサーバとの間の共有シークレットである。各ＯＴＰ発生器は、異なった一意的なシークレットＫを有することができる。
Ｔは、スロットルパラメータである。サーバは、Ｔ回の認証試行の不成功の後にユーザからの接続を拒否できる、でなければ、所定の源からの過剰な数の妥当性確認試行を示すスロットル信号を受け取り人に送ることができる。
ｓは、再同期化パラメータである。サーバは、ｓ個の連続的なカウンタ値にわたって、受け取った認証符号の確認を試みることができる。
Digitは、ＯＴＰ値の数字の数であり、この数字数はシステムパラメータであってもよい。
本発明にしたがったＯＴＰアルゴリズムは、トークンおよびバリデーションサービスのみに知られている、増加するカウンタ値および静的対称キーに基づくことができる。ＯＴＰ値を生成するために、１９９７年２月にM. Bellare氏, R.Canetti氏、およびH. Krawczyk氏によって出されたIETF Network Working GroupのRFC 2104の“HMAC: Keyed−Hashing for Message Authentication”において規定されているように、ＨＭＭＡＣ−ＳＨＡ−１アルゴリズムを使用できる。
【００１６】
ＨＭＡＣ−ＳＨＡ１の計算の出力は１６０ビットであり、これは、ユーザによって容易に入力できるサイズに打ち切ることができる値である。したがって、
ＨＯＴＰ（Ｋ,Ｃ）＝Ｔｒｕｎｃａｔｅ(ＨＭＡＣ−ＳＨＡ−１(Ｋ,Ｃ))となる。
ここで、Ｔｒｕｎｃａｔｅは、ＨＭＡＣ−ＳＨＡ−１値をＨＭＡＣ−ＳＨＡ−１ ＯＴＰ(ＨＯＴＰ)値に変換する関数を示している。キー（Ｋ）、カウンタ（Ｃ）およびデータ値は、最初に上位バイトをハッシュすることができる。ＨＯＴＰ発生器によって発生されたＨＯＴＰ値をビッグエンディアンとして取り扱うことができる。
【００１７】
３つの異なるステップでＨＯＴＰ値を発生させることができる。
ステップ１：ＨＭＡＣ−ＳＨＡ−１値を発生させる。
ＨＳ＝ＨＭＡＣ−ＳＨＡ−１(Ｋ，Ｃ)とする。ここで、ＨＳは、２０バイトストリングとすることができる。
ステップ２：４バイトストリング（Ｄｙｎａｍｉｃ Ｔｒｕｎｃａｔｉｏｎ）を発生させる。
Ｓｂｉｔｓ＝ＤＴ（ＨＳ）とし、これは３１ビットストリングを返すことができる。
Ｄｙｎａｍｉｃ ＴｒｕｎｃａｔｉｏｎＤＴ（Ｓｔｒｉｎｇ）は、Ｓｔｒｉｎｇ＝Ｓｔｒｉｎｇ［０］... Ｓｔｒｉｎｇ［１９］で、以下のように動作することができる。
ＯｆｆｓｅｔＢｉｔをＳｔｒｉｎｇ［１９］の下位４ビットとする。
Ｏｆｆｓｅｔ＝ＳｔＴｏＮｕｍ(ＯｆｆＳｅｔＢｉｔｓ)であり、ここで、０＜＝ＯｆｆＳｅｔ＜＝１５である。
Ｐ＝Ｓｔｒｉｎｇ［ＯｆｆＳｅｔ］... Ｓｔｒｉｎｇ［ＯｆｆＳｅｔ＋３］とする。
Ｐの最後の３１ビットを返す。
【００１８】
Ｐの最上位のビットをマスキングすることによって、有符号および無符号モジュロ計算間の混乱を回避することができる。異なるプロセッサがこれらの演算を別々に行い、有符号ビットをマスキングアウトすることによって、あいまい性を解消できる。
【００１９】
ステップ３：ＨＯＴＰ値を計算する。
Ｓｎｕｍ＝ＳｔＴｏＮｕｍ（ｓ）とする。すなわち、Ｓを０...２＾｛３１｝−１の数に変換する。
Ｄ=Ｓｎｕｍ ｍｏｄ１０＾Digitを返す。ここで、Ｄは、０...１０＾｛Digit｝−１の範囲の数である。
【００２０】
Ｔｒｕｎｃａｔｅ関数は、ステップ２およびステップ３、すなわち、動的な打ち切りをし、そして１０＾Digitを法とした還元を行なう。動的オフセット打ち切り技術の目的は、１６０ビット（２０バイト）ＨＭＡＣ−ＳＨＡ１の結果から、４バイトの動的なバイナリコードを取り出すことである。
【００２１】
インプリメンテーションは、少なくとも６数字のコードを取り出すべきである。安全性の要求次第で、より長いＨＯＴＰ値を取り出すためにDigit＝７またはより多くのものを考えなければならない。
【００２２】
下記は、Digit＝６に対してこの技術を使用している例である。すなわち、６数字のＨＯＴＰ値が、ＨＭＡＣ値から計算される。このコードの例は、ｈｍａｃ＿ｒｅｓｕｌｔがＨＭＡＣ−ＳＨＡ１の結果によるバイトアレイであることを仮定して、動的バイナリコードの取り出しを説明している。
【数１】
【００２３】
* 最後のバイト（バイト１９）は、１６進値０ｘ５ａを持つ。
* 下位の４つのビットの値は、０ｘａ（オフセット値）である。
* オフセット値は、バイト１０（０ｘａ）である。
* バイト１０で始まる４バイトの値は０ｘ５０ｅｆ７ｆ１９であり、これは、動的バイナリコードＤＢＣ１である。
* ＤＢＣ１のＭＳＢは０ｘ５０であるので、ＤＢＣ２＝ＤＢＣ１＝０ｘ５０ｅｆ７ｆ１９である。
* ＨＯＴＰ＝１０＾６を法としたＤＢＣ２＝８７２９２１である。
３１ビット、無符号のビッグエンディアン整数として動的バイナリコードを取り扱う。つまり、最初のバイトは０ｘ７ｆでマスキングされる。１，０００，０００(１０＾６）を法としたこの数を用いて、６数字のＨＯＴＰ値である十進法の８７２９２１を発生させる。
【００２４】
あらゆるワンタイムパスワードアルゴリズムは、ワンタイムパスワードアルゴリズムを実現するアプリケーションおよび認証プロトコルと同じ程度の安全性であるにすぎない。パラメータＴおよびｓは、安全性に対して重大な影響を与えることがある。ＨＭＡＣ−ＳＨＡ−１値をより短い値に打ち切ることは、総当り攻撃を可能にする。それゆえ、認証サーバは、総当り攻撃を検出して阻止すべきである。ワンタイムパスワードの妥当性確認の実行可能な試行の最大数を規定するスロットルパラメータＴは、適切な小さい数に設定すべきである。バリデーションサーバは、何らかの失敗した試行に気付くために、ＨＯＴＰデバイス毎に個々のカウンタを管理できる。特に、サーバ上で使用される再同期化の方法がウィンドウベースである場合に、そして、ウィンドウサイズが大きい場合に、Ｔを大きすぎるものとすべきではない。Ｔは、ユーザビリティにあまり悪影響を及ばさない限り、できるだけ低く設定すべきである。
【００２５】
別のオプションは、総攻撃を回避するために遅延スキームを実現することである。それぞれ失敗したＡ回の試行の後に、認証サーバは、増加したＴ*Ａ秒数待つ。例えば、Ｔ＝５とすると、１回の試行の後、サーバは５秒間待つ。２回目の失敗した試行では、サーバは５*２＝１０秒待つ等である。
【００２６】
遅延またはロックアウトスキームは、ログインセッションにわたって行なわれ、複数の並列推測技術に基づく、攻撃を回避すべきである。
【００２７】
証明者と検証者との間の認証方法としてＨＯＴＰを実現するためのプロトコルＰは、安全性のためにある性質がなければならない。Ｐは、２要素、すなわち、ユーザが知っているもの（パスワード、パスフレーズ、ＰＩＮコード等のようなシークレットコード）、およびユーザが持つもの（トークン）である。シークレットコードは、ユーザのみに知られており、認証（２要素認証）する目的で、ワンタイムパスワード値で入力できるものとすべきである。
【００２８】
Ｐは、総当り攻撃に対して弱いものであってはならない。このことは、スロットル／ロックアウトスキームが、例えば、バリデーションサーバ側で実現されることを意味する。
【００２９】
公衆ネットワークに対して機密扱いのデータを送信することに関係する通常の攻撃およびリスク（プライバシー、リプレイ攻撃、等）を回避するために、Ｐは、安全性の面で最新の技術に対して実現されるべきである。
【００３０】
ＨＯＴＰクライアント（ハードウェアまたはソフトウェアトークン）は、そのカウンタを増加させて、次のＨＯＴＰ値、“ＨＯＴＰクライアント”を計算する。認証サーバによって受け取られた値が、クライアントによって計算された値と整合した場合に、ＨＯＴＰ値が有効化される。このケースでは、サーバが、カウンタ値を１だけ増加させる。
【００３１】
サーバにより受け取られた値がクライアントによって計算された値と整合しない場合に、サーバが別のパスを要求する前に、サーバが、（例えば、ルックアヘッドウィンドウを使用して）再同期化（“ｒｅｓｙｎｃｈ”）プロトコルを開始する。
【００３２】
“ｒｅｓｙｎｃｈ”が失敗した場合に、認証された試行が最大数に達するまで、サーバは、プロトコルの別の認証パスを生じさせるように要求することができる。
【００３３】
認証された試行が最大数に達した場合に、サーバは、アカウントをロックアウトして、失敗した試行の数がアカウントへのアクセスを生じさせたことをユーザに知らせる手順を開始することができる。
【００３４】
ＨＯＴＰクライアントは、共有シークレットを知っている本物のエンティティであることを主張しているバリデーションサーバを認証するためにも使用できる。ＨＯＴＰクライアントおよびサーバは同期化され、同じシークレット（またはそれを再計算する方法）を共有するので、簡単な３パスのプロトコルが適したものとすることができる。例えば、
１−エンドユーザが、ＴｏｋｅｎＩＤおよび第１のＯＴＰ値、ＯＴＰ１を入力できる。
２−サーバが、ＯＴＰ１をチェックでき、ＯＴＰ１が正しい場合に、ＯＴＰ２を返信できる。
３−エンドユーザが、ユーザのＨＯＴＰデバイスを使用して、ＯＴＰ２をチェックすることができ、ＯＴＰ２が正しい場合に、サーバが認証され、エンドユーザがウェブサイトを使用する。
以前に示したように、明らかに、すべてのＯＴＰ通信は、安全な（例えば、ＳＳＬ）接続を通して行われるべきである。
【００３５】
サーバのカウンタ値はＨＯＴＰ認証の成功の後のみに増加されるが、トークン上のカウンタは、新しいＨＯＴＰがユーザによって要求されるごとに増加される。このために、サーバ上およびトークン上のカウンタ値は、同期が外れているかもしれない。
【００３６】
ルックアヘッドパラメータｓは、サーバ上で設定することができ、ルックアヘッドウィンドウのサイズを規定する。サーバは、次のs個のＨＯＴＰサーバ値を再計算し、受け取ったＨＯＴＰクライアントに対して、再計算されたＨＯＴＰ値をチェックすることができる。このシナリオにおけるカウンタの同期化は、単に、次のＨＯＴＰ値をサーバが計算して、整合があるか否かを決定することを要求する。連続的なＨＯＴＰ値のシーケンスを偽造することは、単一のＨＯＴＰ値を推測することより、はるかに困難であるので、システムは、再同期化の目的で、ＨＯＴＰ値のシーケンス（例えば、２、３）を送ることをユーザに要求できる。
【００３７】
パラメータｓによって設定された上限は、ＨＯＴＰ値のチェックをサーバが永遠に続けないことを確実にし（サービス攻撃の拒絶を生じさせる）、ＨＯＴＰ値を生成しようとする攻撃者に対して、可能性ある解法の余地も制限する。ユーザビリティが悪すぎる影響を確実に受けないようにしながら、ｓを可能な限り低く設定すべきである。 ＯＴＰ値を発生させて確認するために使用される共有シークレットを扱う動作は、機密扱いの情報の何らかのリークのリスクを減らすために、安全に行なわれなければならない。バリデーションシステムにおいて、共有シークレットを安全に発生させて、記憶させる２つの異なった方法を考える。
【００３８】
１）決定論的発生：シークレットは、プロビジョニングおよび確認の双方の段階でマスターシードから取り出され、要求されたときいつでも実行中に発生される。
２）ランダム発生：シークレットは、プロビジョニング段階でランダムに発生されると、すぐに記憶され、そのライフサイクル中、安全が保たれなければならない。
【００３９】
決定論的発生
可能性ある方策は、マスターシークレットから共有シークレットを取り出すことである。マスターシークレットは、サーバのみで記憶することが可能である。耐不正変更デバイスを使用して、マスターキーを記憶し、マスターキーおよび何らかの公開情報から共有シークレットを取り出すべきである。共有シークレットは、プロビジョニングおよび妥当性確認時間において必要なときに要求に応じて発生させることが可能であるので、主な利益は、共有シークレットの露呈をいつも回避でき、さらに、記憶に関する特別な要求も避けられることである。
【００４０】
２つの異なるケースを考える。
【００４１】
１）単一のマスターキーＭＫを使用して、共有シークレットを取り出す。各ＨＯＴＰデバイスは、異なるシークレット、すなわち、Ｋ＿ｉ＝ＳＨＡ−１（ＭＫ，ｉ）を持つ。ここで、ｉは、シリアル番号、トークンＩＤ等のような、ＨＯＴＰデバイスを一意的に識別する情報の公開部分を表す。このことは、アプリケーションまたはサービスの状況下でありうる。異なるアプリケーションまたはサービスプロバイダは、異なるシークレットおよび設定を持つことがある。
２）いくつかのマスターキーＭＫ＿ｉが使用され、各ＨＯＴＰデバイスは、１組の取り出された異なるシークレット、｛Ｋ＿ｉ，ｊ＝ＳＨＡ−１（ＭＫ＿ｉ，ｊ）｝を記憶する。ここで、ｊは、デバイスを識別する情報の公開部分を表す。１９７９年１１月にAdi Shamir氏によって出されたシークレットの共有の仕方、第２２巻、第１１号の６１２〜６１３ページ中のCommunication of the ACMで開示されているような、シークレット共有方法を使用すると、アクティブマスターキーは、ＨＳＭの際に、バリデーションサーバでのみ記憶され、安全な場所で保持することが可能である。このケースでは、マスターシークレットＭＫ＿ｉが損なわれた場合に、すべてのデバイスを取り替えなくても別のシークレットに切り替えることが可能である。
【００４２】
決定論的ケースにおける欠点は、マスターシークレットの露呈によって、明らかに、攻撃者が正しい公開情報に基づいて何らかの共有シークレットを再生できる事実を含む。複数のマスターキーのケースでは、すべてのシークレットの破棄、すなわち、新しい組のシークレットへの切り替えが必要である。
【００４３】
一方、マスターキーを記憶して、共有シークレットを発生させるために使用されるデバイスは、耐不正変更なものであるべきである。さらに、ＨＳＭは、バリデーションシステムの安全な境界線の外にさらされないので、リークのリスクを減少させることができる。
【００４４】
ランダム発生
共有シークレットはランダムに発生させることが可能である。良好で安全なランダム発生源が、これらのシークレットを発生させるために選択されるべきである。（真の）ランダム発生器は、ランダム性を自然に生じさせる発生源を必要とする。実際には、共有シークレットの発生に対して２つの可能性ある方法がある。
【００４５】
１）ハードウェアベース発生器は、物理現象で生じるランダム性を活用することができる。インプリメンテーションは、発振器に基づき、そしてアクティブ攻撃を行なうことがより困難であるような方法で組み込むことが可能である。
２）良好なソフトウェアランダム発生器を設計することは容易なタスクではないが、ソフトウェアベース発生器がある。効率的だが、簡単なインプリメンテーションは、さまざまな源に基づくことができ、サンプル化されたシーケンスにＳＨＡ−１のような一方向関数を適用すべきである。
【００４６】
例えば、記憶の際に、耐不正変更ハードウェア暗号化を使用して共有シークレットを暗号化し、要求されたときのみに共有シークレットを明かすことによって、共有シークレットは、安全に記憶すべきである。例えば、共有シークレットは、ＨＯＴＰ値を確認する必要があるとき解読され、ＲＡＭにおける露呈を短期間に制限するためにすぐに再暗号化される。共有シークレットを保持しているデータ記憶装置は、バリデーションシステムおよびシークレットデータベースに対する直接的な攻撃を回避するために、安全な領域内にあるべきである。
【００４７】
特に、共有シークレットへのアクセスは、バリデーションシステムのみによって要求されるプログラムおよびプロセスに限定されるべきである。共有シークレットの保護は、最重要である。
【００４８】
ＨＯＴＰアルゴリズムの安全性は、以下の数式、
Ｓｅｃ＝ｓｖ／１０＾Digit
によって、概算できる。
【００４９】
ここで、
−Ｓｅｃは、敵対者の成功の確率である。
−ｓは、ルックアヘッド同期化ウィンドウのサイズを表す。
−ｖは、妥当性確認試行の数を表す。
−Digitは、ＨＯＴＰ値の数字の数を表す。
【００５０】
これは、システムユーザビリティを依然として維持しながら望みのレベルの安全性が実現されるまで、ｓ、Ｔ（攻撃者による試行の数を制限するスロットルパラメータ）およびDigitを調整することができる。
【００５１】
共有シークレットＫに付加的な認証要素を含めることが望ましいことがある。これらの付加的な要素は、他のものによって容易に獲得されないがトークンに知られている何らかのデータで構成することが可能である。このようなデータの例は、
* ユーザ入力としてトークンで獲得されたＰＩＮまたはパスワード
* 電話番号
* トークンでプログラム的に利用可能な何らかの一意的な識別子
を含む。
【００５２】
このシナリオでは、複合共有シークレットＫが、１つ以上の付加的な認証要素と組み合わされているランダムシード値から、プロビジョニングプロセス中に作られる。サーバは、複合シークレットを要求に応じて作ること、または記憶することのいずれも可能である。いずれにせよ、インプリメンテーションの選択に基づいて、トークンは、シード値のみを記憶することができる。トークンがＨＯＴＰ計算を行なうとき、トークンは、ローカル的に取り出されたまたは入力された他の認証要素の値、およびシード値からＫを計算することができる。
【００５３】
複合共有シークレットの使用は、トークンに付加的な認証要素を含めることによってＨＯＴＰベースの認証システムを強化することができる。トークンが信頼あるデバイスである限り、このアプローチは、他のデバイスに対する（ユーザ入力のＰＩＮのような）認証要素の露呈を必要としない、さらなる利点を持つ。
【００５４】
以下は、ＨＯＴＰ アルゴリズムの例示的なインプリメンテーションである。
／*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* ＨＯＴＰワンタイムパスワードアルゴリズム
*
*／
／* Copyright(Ｃ)2004,OATH. すべての権利が留保されている。
*
* このソフトウェアまたはこの関数に言及または参照している全マテリアルにおいて
* “OATH HOTP Algorithm”としてこのソフトウェアが識別されていることを
* 条件として、このソフトウェアを複製して使用するライセンスを許可する。
【００５５】
*
* 派生作品に言及または参照する全マテリアルにおいて、
* “OATH HOTPアルゴリズムから派生した”として、
* このような作品が識別されていることを条件として、
* 派生作品を作成して使用するライセンスも許可する。
*
* OATH(Open AuTHentication)およびそのメンバは、
* 何らかの特定の目的のためにこのソフトウェアの販売適性、
* またはこのソフトウェアの適合性のいずれに関しても
* 代表するものではない。
*
* いかなる種類の明示的または黙示的な保証をすることなく、“そのまま”で
* 提供されているものであり、ＯＡＴＨおよびそのメンバは、このソフトウェアに * 関するいかなる種類のいかなる保証または責任も明示的に否認する。
*
* これらの注意書きは、この文書および／またはソフトウェアの
* いかなる部分のいかなる複製においても保持されなければならない。
*／
【数２】
【００５６】
／**
* このクラスは、ＨＭＡＣ−ＳＨＡ１を提供するＪＣＥを使用して、
* ワンタイムパスワード（ＯＴＰ）を計算するために使用される。
* 静的方法を含む。
*
* ＠製作者 Loren Hart
* ＠１．０バージョン
*／
【数３】
【００５７】
／**
* クレジットカードアルゴリズムを使用して、チェックサムを計算。
* このアルゴリズムは、何らかの単一のミスタイプされた数字、
* および隣接する数字の何らかの単一の入れ換えを
* 検出する効果を持つ。
*
* ＠param num チェックサムを計算する数
* ＠param degit 数の有効桁の数
*
* ＠return numのチェックサム
*／
【数４】
【００５８】
／**
* この方法は、ＪＣＥを使用して、
* ＨＭＡＣ−ＳＨＡ１アルゴリズムを提供する。
* ＨＭＡＣは、ハッシュされたメッセージ認証コードを計算し、
* このケースでは、ＳＨＡ１が、使用されるハッシュアルゴリズムである。
*
* ＠param keyBytes ＨＭＡＣ−ＳＨＡ１キーに使用するバイト
* ＠param text 認証されるべきメッセージまたはテキスト
*
* ＠throws NoSuchAlgorithmException プロバイダが
* ＨｍａｃＳＨＡ１またはＨＭＡＣ−ＳＨＡ１
* ダイジェストアルゴリズムのいずれも利用可能にしない場合
* ＠throws InvalidKeyException
* 提供されたシークレットが、有効なＨＭＡＣ−ＳＨＡ１キーでなかった。
*
*／
【数５】
【００５９】
／**
* この方法は、所定の組のパラメータに対して
* ＯＴＰ値を発生させる。
*
* ＠param secret 共有シークレット
* ＠param movingFactor 使用ベースで変化する
* カウンタ、時間、または他の値
* ＠param codeDigit もしあれば、
* チェックサムを含まないＯＴＰの数字の数
* ＠param addCheksum チェックサムの数字をＯＴＰに
* 追加すべきか否かを示すフラグ
* ＠param truncationOffset 打ち切りを開始するために
* ＭＡＣ結果に入れるオフセット
* この値が０．．．１５の範囲外である場合、
* 動的打ち切りが使用される。
* ＭＡＣの最後のバイトの最後の４ビットが
* 開始オフセットを決定するために
* 使用されるときに動的打ち切りである。
* ＠throws NoSuchAlgorithmException プロバイダが、ＨｍａｃＳＨＡ１または
* ＨＭＡＣ−ＳＨ１ダイジェストアルゴリズム
* のいずれも利用可能にしない場合
* ＠throws InvalidKeyException
* 提供されたシークレットが、
* 有効なＨＭＡＣ−ＳＨＡ１キーでなかった。
【００６０】
*
* ＠return ｛＠link codeDigits｝数字プラス、
* 要求された場合にはオプション的なチェックサム数字を含む
* ベース１０のＡ数値ストリング
*／
【数６】
【００６１】
カスタマイズされたインプレメンテーションに使用できるバリエーションとして、ＨＯＴＰアルゴリズムに対していくつかの拡張を行なうことができる。
【００６２】
安全性に関する簡単な拡張は、ＨＭＡＣ−ＳＨＡ１値から、より多い数字を取り出すことである。例えば、１０＾８を法としたＨＯＴＰ値を計算して、８数字のＨＯＴＰ値を作ることは、敵対者の成功の確率をｓｖ／１０＾６からｓｖ／１０＾８に減少させる。このことは、例えば、Ｔおよび／またはｓを増加させることによって、ユーザビリティを向上する好機を与え、一方では依然として全体的により良い安全性を実現することができる。例えば、ｓ＝１０で１０ｖ／１０＾８＝ｖ／１０＾７＜ｖ／１０＾６である。このｖ／１０＾６は、ｓ＝１のときに６数字コードに対して理論上最適である。
【００６３】
別のオプションは、Ａ−Ｚおよび０−９値を使用することである。もっと正確に言えば０、ＯおよびＱとともに、ｌ，１およびＩは非常に類似しており、小型ディスプレイでは同一に見える可能性があるので、文字間の何らかの混乱を回避するために、英数字のアルファベットから抽出した３２個のシンボルのサブセットを使用する。直接的な結果は、安全性が、６数字のＨＯＴＰ値に対するｓｖ／３２＾６、および８数字のＨＯＴＰ値に対するｓｖ／３２＾８のオーダーになることである。３２＾６＞１０＾９であるので、６つの英数字のＨＯＴＰコードの安全性は、９数字のＨＯＴＰ値よりわずかに良く、９数字のＨＯＴＰ値は提案されているアルゴリズムによってサポートされているＨＯＴＰコードの最大の長さである。３２＾８＞１０＾１２であるので、８個の英数字のＨＯＴＰコードの安全性は、９数字のＨＯＴＰ値よりかなり良い。ＨＯＴＰ値を表示して入力するのに使用されるトークン／インターフェイスおよびアプリケーションに依存して、英数字の値を選択することは、低コストで安全性を向上させ、ユーザにインパクトを与える簡単かつ効率的な方法となり得る。
【００６４】
ＨＯＴＰ値のショートシーケンス（例えば、２または３）を入力する再同期化について述べると、これは、プロトコルに対する概念として一般化することが可能である。入力するＨＯＴＰシーケンスの長さを規定するパラメータＬを追加することができる。デフォルトによって、値Ｌは１に設定すべきであるが、安全性を増強させる必要がある場合、ユーザは、（おそらくは、短期間に、または特定の動作で）Ｌ個のＨＯＴＰ値を入力するように要求されるかもしれない。これは、ＨＯＴＰの長さを増加せずに、または英数字値を使用せずに安全性を強化する別の方法となり得る。
【００６５】
システムは、（例えば、毎晩、または週に２回等）定期的に同期化を要求する、また、この目的を実現するために、Ｌ個のＨＯＴＰ値のシーケンスを要求するようにプログラム化することもできる。
【００６６】
クライアントが、アクセスして、ＨＯＴＰ値のみではなく、カウンタ値のような他の情報も送ることができると仮定すると、より効率的で安全な再同期化の方法が可能である。クライントアプリケーションは、ＨＯＴＰ−クライント値、および関連するＣ−クライントカウンタ値を送ることができる。ＨＯＴＰ値は、カウンタのメッセージ認証コードとして機能するものである。
【００６７】
以下がすべて真である場合に、サーバが受け入れる。ここで、Ｃ−サーバは、Ｃ−サーバ自体の現在のカウンタ値である。
【００６８】
１）Ｃ−クラインアト＞＝Ｃ−サーバ
２）Ｃ−クライント−Ｃ−サーバ＜＝ｓ
３）ＨＯＴＰ−クライントが有効なＨＯＴＰ（Ｋ，Ｃ−Ｃｌｉｅｎｔ）であることをチェック。
４）真である場合に、サーバがＣ−クライアント＋１にＣを設定し、クライアントが認証される。
このケースでは、これ以上、ルックアヘッドウィンドウを管理する必要がない。敵対者の成功の確率は、たったｖ／１０＾６、すなわち、およそ１００万分のｖである。副次的な利益は、明らかに、“際限なく”ｓを増加させることができるので、安全性に影響を及ぼさないで、システムのユーザビリティを向上させることができる。この再同期化プロトコルは、クライアントおよびサーバアプリケーションに対する関連する影響が受け入れ可能であると考えられるときにはいつでも使用することができる。
【００６９】
ワンタイムパスワード値、すなわち、ＨＯＴＰ（Ｋ，Ｃ，［Ｄａｔａ］）を発生させるために使用されるデータフィールドの導入を別のオプションとすることができる。ここで、Ｄａｔａは、例えば、Ｄａｔａ＝Ａｄｄｒｅｓｓ｜ＰＩＮのような、識別関連情報のさまざまな部分の連結とすることができるオプション的なフィールドである。
【００７０】
１つは、ムービング係数のみとして、またはＣｏｕｎｔｅｒとの組み合わせのいずれでＴｉｍｅｒも使用できる。このケースでは、例えば、Ｄａｔａ＝Ｔｉｍｅｒであり、ここで、Ｔｉｍｅｒは、例えば、特定の時間ステップを与えるために、いくつかの係数（８、１６、３２等）で除算されたＵＮＩＸ（登録商標）−時間（１９７０年１月１日以来のＧＭＴの秒）であってもよい。ワンタイムパスワードに対する時間ウィンドウは、以前に規定されたような再同期化パラメータで乗算された時間ステップと等しい。例えば、時間ステップとして６４秒をとって、再同期化パラメータに対して７を用いた場合に、＋／−３分の受け入れウィンドウを得る。Ｄａｔａフィールドが明確に指定されることを仮定すると、Ｄａｔａフィールドを使用することによって、アルゴリズムのインプレメンテーションをより柔軟にできる。
【００７１】
メモリに結合されているプロセッサによって、本発明の実施形態を実現できる。プロセッサは、汎用マイクロプロセッサ、またはハードウェアおよび／またはファームウェアで本発明の実施形態にしたがった方法の少なくとも一部を実現する特定用途向け集積回路とすることも可能である。メモリは、ランダムアクセスメモリ、ハードディスク、フラッシュメモリ、およびこれらに類するもののような、デジタル情報を記憶できる任意のデバイスとすることができる。メモリは、プロセッサによって実行され、本発明の実施形態にしたがった方法の少なくとも一部を行なうように適合されている命令を記憶できる。プロセッサは、ネットワークに結合され、（ＯＴＰおよび他のデータのような）認証データを妥当性確認のためにこのネットワークを通して送ることができる。
【００７２】
本発明にしたがった認証システムは、トークンプロセッサおよびトークンメモリを備えたトークンと、サーバプロセッサおよびサーバメモリを備えたバリデーションサーバとを具備していてもよい。トークンプロセッサは、トークンメモリ中に記憶されている命令に基づいてＯＴＰ発生アルゴリズムを実現する。トークンメモリは、共有シークレットＫおよびトークンカウンタ値Ｃを記憶することも可能である。バリデーションサーバプロセッサは、バリデーションサーバメモリに記憶されている命令、ならびにバリデーションサーバメモリに記憶されているバリデーションサーバカウンタ値Ｃ’および共有シークレットＫに基づいて、ＯＴＰバリデーションアルゴリズムを実現できる。バリデーションサーバメモリはスロットルパラメータＴ、ルックアヘッドウィンドウサイズｓ等のような、他のパラメータも記憶することができる。
【００７３】
トークンは、ＫおよびＣに基づいて計算されたそのワンタイムパスワードをバリデーションサーバに送ることができる。バリデーションサーバは、ＫおよびＣ’に基づいて、ワンタイムパスワードを計算することができる。整合しない場合、バリデーションサーバは、ＫおよびＣ’＋ｎに基づいて、次のいくつかのワンタイムパスワードを計算することができる。ここで、ｎは１からｓの整数である。これらの計算されたワンタイムパスワードのいずれもトークンから受け取ったワンタイムパスワードと整合しない場合、バリデーションサーバは妥当性確認試行の失敗を示す信号を送ることができる。計算されたワンタイムパスワードのうちの１つがトークンから受け取ったワンタイムパスワードと整合する場合、バリデーションサーバは妥当性確認の成功を示す信号を送ることができる。バリデーションサーバは、Ｔ回の妥当性確認試行の不成功後にさらなる妥当性確認試行を中止することができ、所定のトークンはいくつかのこのような失敗した試行の源であるという趣旨で、システムアドミニストレータにアラートすることができる。
【００７４】
前述の記述は、例示を意味しており、本発明の範囲を限定することを意味していない。先に記述した実施形態を除いた他の実施形態は、当業者によって発明の範囲内に入ることが見い出される。
【発明の分野】
【０００１】
本発明の分野は、コンピュータの安全性である。さらに詳細に述べると、ワンタイムパスワードによる認証である。
【発明の背景】
【０００２】
現在、２要素認証の展開は、範囲およびスケールが非常に限定されたままである。脅威および攻撃のレベルが一層より高くなってきているにもかかわらず、大部分のインターネットアプリケーションは、ユーザアクセスを取り締まるための軟弱な認証スキームに依然として依存している。ハードウェアおよびソフトウェア技術ベンダ間の相互運用性の欠如が、２要素認証技術の採用における制約要因である。特に、ハードウェアおよびソフトウェアのコンポーネントは、知的所有権下にある技術を通して緻密に結合されていることが多く、結果的に、解決に高コストとなり、採用が少なく、および革新が限定的となる。
【０００３】
過去２年間における、ネットワーク脅威の急速な増加は、インターネット上の認証の主要手段としての静的パスワードの不完全さを明らかにした。同時に、ネットワークに対する認証のみに使用される高価な単機能型のデバイスをエンドユーザが所持することを要求する現在のアプローチは、明らかに適切な対応策でない。２要素認証をインターネット上で普及するために、広範囲なアプリケーションにわたって機能可能な、より柔軟性あるデバイスに２要素認証を埋め込まなければならない。
【０００４】
ワンタイムパスワードは、確かに、ネットワークアクセスを安全にするための最も簡単で最も普及している２要素認証の形態のうちの１つである。例えば、大企業では、仮想私設ネットワークアクセスは、リモートユーザの認証のために、ワンタイムパスワードのトークンの使用を要求することが多い。エアギャップデバイスは、任意のクライアントのデスクトップソフトウェアのユーザマシーンへのインストールを必要としないので、ワンタイムパスワードは、ＰＫＩまたは生体測定のような、より強力な認証の形態を好むことが多い。したがって、これにより、ホームコンピュータ、キオスクおよびパーソナルデジタルアシスタントを含む複数のマシーンにわたってローミングすることができるようになる。
【発明の概要】
【０００５】
本発明の実施形態にしたがうと、何らかのハードウェア製造業者またはソフトウェアデベロッパによって、ワンタイムパスワードアルゴリズムを実現して、相互運用性のある認証デバイスおよびソフトウェアエージェントを生成することができる。Ｊａｖａ（登録商標）スマートカード、ＵＳＢドングルおよびＧＳＭのＳＩＭカードのような高容量デバイスにアルゴリズムを埋め込むことができるように、アルゴリズムはイベントベースであってもよい。インターネット技術標準化委員会（ＩＥＴＦ）の取引条件のもとで、アルゴリズムは、デベロッパコミュニティにとって自由に利用可能になる。
【詳細な説明】
【０００６】
本発明の実施形態にしたがうと、アルゴリズムは、シーケンスまたはカウンタベースとすることが可能であり、そして、バッテリ、ボタン数、計算馬力およびディスプレイのサイズに関する必要条件を最小限にすることによって、ハードウェアで効率的に実現することができる。アルゴリズムは、何らかの数入力をサポートしないトークンを使用して動作させることができるが、安全なＰＩＮパッドのような、より高性能化したデバイスで使用することも可能である。
【０００７】
トークン上で表示される値は、ユーザによって容易に読み取られ、パーソナルコンピュータ、携帯電話機、現金自動預払機または他の何らかの適切なデバイスのような別のデバイスに入力される。このことにより、ワンタイムパスワード（ＯＴＰ）値が、適度な長さのものであるように要求される。多くのケースにおいて、ＯＴＰ値は、安全性の理由から少なくとも６数字の値であるべきである。電話機のような単純なキーパッドを備えたデバイス上にＯＴＰ値を容易に入力できるように、ＯＴＰ値は数字のみであると便利である。
【０００８】
カウンタを再同期化するのに利用可能なユーザフレンドリなメカニズムがある。アルゴリズムには、強力な共有シークレットが使用されるべきである。このために、共有シークレットの長さは、１２８ビット、または、より長いビットである。
【０００９】
以下の表記法およびシンボルを使用して、本発明にしたがったアルゴリズムの実施形態を説明する。
【００１０】
ストリングはバイナリストリングを意味しており、バイナリストリングは、０および１のシーケンスを意味している。
【００１１】
ｓがストリングである場合、｜ｓ｜はストリングの長さを示す。
【００１２】
ｎが数字である場合、｜ｎ｜は絶対値を示す。
【００１３】
ｓがストリングである場合、ｓ[ｉ]はストリングのｉ番目のビットを示す。ビットは、０からビットの番号が振られているので、ｓ＝ｓ[０]ｓ[１]...ｓ[ｎ−１]となる。ここで、ｎ＝｜ｓ｜はｓの長さである。
【００１４】
（ストリングを数にする）ＳｔＴｏＮｕｍは、バイナリの入力ストリングｓの１０進法の表示を返す関数を示す。例えば、ＳｔＴｏＮｕｍ（１１０）＝６である。
【００１５】
以下の表記法をシンボルに使用する。
Ｃは、８バイトのカウンタ値、ムービング係数である。このカウンタは、ＯＴＰ発生器（例えば、クライアント）とＯＴＰバリデイター（例えば、サーバ）との間を同期化させることができる。
Ｋは、クライアントとサーバとの間の共有シークレットである。各ＯＴＰ発生器は、異なった一意的なシークレットＫを有することができる。
Ｔは、スロットルパラメータである。サーバは、Ｔ回の認証試行の不成功の後にユーザからの接続を拒否できる、でなければ、所定の源からの過剰な数の妥当性確認試行を示すスロットル信号を受け取り人に送ることができる。
ｓは、再同期化パラメータである。サーバは、ｓ個の連続的なカウンタ値にわたって、受け取った認証符号の確認を試みることができる。
Digitは、ＯＴＰ値の数字の数であり、この数字数はシステムパラメータであってもよい。
本発明にしたがったＯＴＰアルゴリズムは、トークンおよびバリデーションサービスのみに知られている、増加するカウンタ値および静的対称キーに基づくことができる。ＯＴＰ値を生成するために、１９９７年２月にM. Bellare氏, R.Canetti氏、およびH. Krawczyk氏によって出されたIETF Network Working GroupのRFC 2104の“HMAC: Keyed−Hashing for Message Authentication”において規定されているように、ＨＭＭＡＣ−ＳＨＡ−１アルゴリズムを使用できる。
【００１６】
ＨＭＡＣ−ＳＨＡ１の計算の出力は１６０ビットであり、これは、ユーザによって容易に入力できるサイズに打ち切ることができる値である。したがって、
ＨＯＴＰ（Ｋ,Ｃ）＝Ｔｒｕｎｃａｔｅ(ＨＭＡＣ−ＳＨＡ−１(Ｋ,Ｃ))となる。
ここで、Ｔｒｕｎｃａｔｅは、ＨＭＡＣ−ＳＨＡ−１値をＨＭＡＣ−ＳＨＡ−１ ＯＴＰ(ＨＯＴＰ)値に変換する関数を示している。キー（Ｋ）、カウンタ（Ｃ）およびデータ値は、最初に上位バイトをハッシュすることができる。ＨＯＴＰ発生器によって発生されたＨＯＴＰ値をビッグエンディアンとして取り扱うことができる。
【００１７】
３つの異なるステップでＨＯＴＰ値を発生させることができる。
ステップ１：ＨＭＡＣ−ＳＨＡ−１値を発生させる。
ＨＳ＝ＨＭＡＣ−ＳＨＡ−１(Ｋ，Ｃ)とする。ここで、ＨＳは、２０バイトストリングとすることができる。
ステップ２：４バイトストリング（Ｄｙｎａｍｉｃ Ｔｒｕｎｃａｔｉｏｎ）を発生させる。
Ｓｂｉｔｓ＝ＤＴ（ＨＳ）とし、これは３１ビットストリングを返すことができる。
Ｄｙｎａｍｉｃ ＴｒｕｎｃａｔｉｏｎＤＴ（Ｓｔｒｉｎｇ）は、Ｓｔｒｉｎｇ＝Ｓｔｒｉｎｇ［０］... Ｓｔｒｉｎｇ［１９］で、以下のように動作することができる。
ＯｆｆｓｅｔＢｉｔをＳｔｒｉｎｇ［１９］の下位４ビットとする。
Ｏｆｆｓｅｔ＝ＳｔＴｏＮｕｍ(ＯｆｆＳｅｔＢｉｔｓ)であり、ここで、０＜＝ＯｆｆＳｅｔ＜＝１５である。
Ｐ＝Ｓｔｒｉｎｇ［ＯｆｆＳｅｔ］... Ｓｔｒｉｎｇ［ＯｆｆＳｅｔ＋３］とする。
Ｐの最後の３１ビットを返す。
【００１８】
Ｐの最上位のビットをマスキングすることによって、有符号および無符号モジュロ計算間の混乱を回避することができる。異なるプロセッサがこれらの演算を別々に行い、有符号ビットをマスキングアウトすることによって、あいまい性を解消できる。
【００１９】
ステップ３：ＨＯＴＰ値を計算する。
Ｓｎｕｍ＝ＳｔＴｏＮｕｍ（ｓ）とする。すなわち、Ｓを０...２＾｛３１｝−１の数に変換する。
Ｄ=Ｓｎｕｍ ｍｏｄ１０＾Digitを返す。ここで、Ｄは、０...１０＾｛Digit｝−１の範囲の数である。
【００２０】
Ｔｒｕｎｃａｔｅ関数は、ステップ２およびステップ３、すなわち、動的な打ち切りをし、そして１０＾Digitを法とした還元を行なう。動的オフセット打ち切り技術の目的は、１６０ビット（２０バイト）ＨＭＡＣ−ＳＨＡ１の結果から、４バイトの動的なバイナリコードを取り出すことである。
【００２１】
インプリメンテーションは、少なくとも６数字のコードを取り出すべきである。安全性の要求次第で、より長いＨＯＴＰ値を取り出すためにDigit＝７またはより多くのものを考えなければならない。
【００２２】
下記は、Digit＝６に対してこの技術を使用している例である。すなわち、６数字のＨＯＴＰ値が、ＨＭＡＣ値から計算される。このコードの例は、ｈｍａｃ＿ｒｅｓｕｌｔがＨＭＡＣ−ＳＨＡ１の結果によるバイトアレイであることを仮定して、動的バイナリコードの取り出しを説明している。
【数１】
【００２３】
* 最後のバイト（バイト１９）は、１６進値０ｘ５ａを持つ。
* 下位の４つのビットの値は、０ｘａ（オフセット値）である。
* オフセット値は、バイト１０（０ｘａ）である。
* バイト１０で始まる４バイトの値は０ｘ５０ｅｆ７ｆ１９であり、これは、動的バイナリコードＤＢＣ１である。
* ＤＢＣ１のＭＳＢは０ｘ５０であるので、ＤＢＣ２＝ＤＢＣ１＝０ｘ５０ｅｆ７ｆ１９である。
* ＨＯＴＰ＝１０＾６を法としたＤＢＣ２＝８７２９２１である。
３１ビット、無符号のビッグエンディアン整数として動的バイナリコードを取り扱う。つまり、最初のバイトは０ｘ７ｆでマスキングされる。１，０００，０００(１０＾６）を法としたこの数を用いて、６数字のＨＯＴＰ値である十進法の８７２９２１を発生させる。
【００２４】
あらゆるワンタイムパスワードアルゴリズムは、ワンタイムパスワードアルゴリズムを実現するアプリケーションおよび認証プロトコルと同じ程度の安全性であるにすぎない。パラメータＴおよびｓは、安全性に対して重大な影響を与えることがある。ＨＭＡＣ−ＳＨＡ−１値をより短い値に打ち切ることは、総当り攻撃を可能にする。それゆえ、認証サーバは、総当り攻撃を検出して阻止すべきである。ワンタイムパスワードの妥当性確認の実行可能な試行の最大数を規定するスロットルパラメータＴは、適切な小さい数に設定すべきである。バリデーションサーバは、何らかの失敗した試行に気付くために、ＨＯＴＰデバイス毎に個々のカウンタを管理できる。特に、サーバ上で使用される再同期化の方法がウィンドウベースである場合に、そして、ウィンドウサイズが大きい場合に、Ｔを大きすぎるものとすべきではない。Ｔは、ユーザビリティにあまり悪影響を及ばさない限り、できるだけ低く設定すべきである。
【００２５】
別のオプションは、総攻撃を回避するために遅延スキームを実現することである。それぞれ失敗したＡ回の試行の後に、認証サーバは、増加したＴ*Ａ秒数待つ。例えば、Ｔ＝５とすると、１回の試行の後、サーバは５秒間待つ。２回目の失敗した試行では、サーバは５*２＝１０秒待つ等である。
【００２６】
遅延またはロックアウトスキームは、ログインセッションにわたって行なわれ、複数の並列推測技術に基づく、攻撃を回避すべきである。
【００２７】
証明者と検証者との間の認証方法としてＨＯＴＰを実現するためのプロトコルＰは、安全性のためにある性質がなければならない。Ｐは、２要素、すなわち、ユーザが知っているもの（パスワード、パスフレーズ、ＰＩＮコード等のようなシークレットコード）、およびユーザが持つもの（トークン）である。シークレットコードは、ユーザのみに知られており、認証（２要素認証）する目的で、ワンタイムパスワード値で入力できるものとすべきである。
【００２８】
Ｐは、総当り攻撃に対して弱いものであってはならない。このことは、スロットル／ロックアウトスキームが、例えば、バリデーションサーバ側で実現されることを意味する。
【００２９】
公衆ネットワークに対して機密扱いのデータを送信することに関係する通常の攻撃およびリスク（プライバシー、リプレイ攻撃、等）を回避するために、Ｐは、安全性の面で最新の技術に対して実現されるべきである。
【００３０】
ＨＯＴＰクライアント（ハードウェアまたはソフトウェアトークン）は、そのカウンタを増加させて、次のＨＯＴＰ値、“ＨＯＴＰクライアント”を計算する。認証サーバによって受け取られた値が、クライアントによって計算された値と整合した場合に、ＨＯＴＰ値が有効化される。このケースでは、サーバが、カウンタ値を１だけ増加させる。
【００３１】
サーバにより受け取られた値がクライアントによって計算された値と整合しない場合に、サーバが別のパスを要求する前に、サーバが、（例えば、ルックアヘッドウィンドウを使用して）再同期化（“ｒｅｓｙｎｃｈ”）プロトコルを開始する。
【００３２】
“ｒｅｓｙｎｃｈ”が失敗した場合に、認証された試行が最大数に達するまで、サーバは、プロトコルの別の認証パスを生じさせるように要求することができる。
【００３３】
認証された試行が最大数に達した場合に、サーバは、アカウントをロックアウトして、失敗した試行の数がアカウントへのアクセスを生じさせたことをユーザに知らせる手順を開始することができる。
【００３４】
ＨＯＴＰクライアントは、共有シークレットを知っている本物のエンティティであることを主張しているバリデーションサーバを認証するためにも使用できる。ＨＯＴＰクライアントおよびサーバは同期化され、同じシークレット（またはそれを再計算する方法）を共有するので、簡単な３パスのプロトコルが適したものとすることができる。例えば、
１−エンドユーザが、ＴｏｋｅｎＩＤおよび第１のＯＴＰ値、ＯＴＰ１を入力できる。
２−サーバが、ＯＴＰ１をチェックでき、ＯＴＰ１が正しい場合に、ＯＴＰ２を返信できる。
３−エンドユーザが、ユーザのＨＯＴＰデバイスを使用して、ＯＴＰ２をチェックすることができ、ＯＴＰ２が正しい場合に、サーバが認証され、エンドユーザがウェブサイトを使用する。
以前に示したように、明らかに、すべてのＯＴＰ通信は、安全な（例えば、ＳＳＬ）接続を通して行われるべきである。
【００３５】
サーバのカウンタ値はＨＯＴＰ認証の成功の後のみに増加されるが、トークン上のカウンタは、新しいＨＯＴＰがユーザによって要求されるごとに増加される。このために、サーバ上およびトークン上のカウンタ値は、同期が外れているかもしれない。
【００３６】
ルックアヘッドパラメータｓは、サーバ上で設定することができ、ルックアヘッドウィンドウのサイズを規定する。サーバは、次のs個のＨＯＴＰサーバ値を再計算し、受け取ったＨＯＴＰクライアントに対して、再計算されたＨＯＴＰ値をチェックすることができる。このシナリオにおけるカウンタの同期化は、単に、次のＨＯＴＰ値をサーバが計算して、整合があるか否かを決定することを要求する。連続的なＨＯＴＰ値のシーケンスを偽造することは、単一のＨＯＴＰ値を推測することより、はるかに困難であるので、システムは、再同期化の目的で、ＨＯＴＰ値のシーケンス（例えば、２、３）を送ることをユーザに要求できる。
【００３７】
パラメータｓによって設定された上限は、ＨＯＴＰ値のチェックをサーバが永遠に続けないことを確実にし（サービス攻撃の拒絶を生じさせる）、ＨＯＴＰ値を生成しようとする攻撃者に対して、可能性ある解法の余地も制限する。ユーザビリティが悪すぎる影響を確実に受けないようにしながら、ｓを可能な限り低く設定すべきである。 ＯＴＰ値を発生させて確認するために使用される共有シークレットを扱う動作は、機密扱いの情報の何らかのリークのリスクを減らすために、安全に行なわれなければならない。バリデーションシステムにおいて、共有シークレットを安全に発生させて、記憶させる２つの異なった方法を考える。
【００３８】
１）決定論的発生：シークレットは、プロビジョニングおよび確認の双方の段階でマスターシードから取り出され、要求されたときいつでも実行中に発生される。
２）ランダム発生：シークレットは、プロビジョニング段階でランダムに発生されると、すぐに記憶され、そのライフサイクル中、安全が保たれなければならない。
【００３９】
決定論的発生
可能性ある方策は、マスターシークレットから共有シークレットを取り出すことである。マスターシークレットは、サーバのみで記憶することが可能である。耐不正変更デバイスを使用して、マスターキーを記憶し、マスターキーおよび何らかの公開情報から共有シークレットを取り出すべきである。共有シークレットは、プロビジョニングおよび妥当性確認時間において必要なときに要求に応じて発生させることが可能であるので、主な利益は、共有シークレットの露呈をいつも回避でき、さらに、記憶に関する特別な要求も避けられることである。
【００４０】
２つの異なるケースを考える。
【００４１】
１）単一のマスターキーＭＫを使用して、共有シークレットを取り出す。各ＨＯＴＰデバイスは、異なるシークレット、すなわち、Ｋ＿ｉ＝ＳＨＡ−１（ＭＫ，ｉ）を持つ。ここで、ｉは、シリアル番号、トークンＩＤ等のような、ＨＯＴＰデバイスを一意的に識別する情報の公開部分を表す。このことは、アプリケーションまたはサービスの状況下でありうる。異なるアプリケーションまたはサービスプロバイダは、異なるシークレットおよび設定を持つことがある。
２）いくつかのマスターキーＭＫ＿ｉが使用され、各ＨＯＴＰデバイスは、１組の取り出された異なるシークレット、｛Ｋ＿ｉ，ｊ＝ＳＨＡ−１（ＭＫ＿ｉ，ｊ）｝を記憶する。ここで、ｊは、デバイスを識別する情報の公開部分を表す。１９７９年１１月にAdi Shamir氏によって出されたシークレットの共有の仕方、第２２巻、第１１号の６１２〜６１３ページ中のCommunication of the ACMで開示されているような、シークレット共有方法を使用すると、アクティブマスターキーは、ＨＳＭの際に、バリデーションサーバでのみ記憶され、安全な場所で保持することが可能である。このケースでは、マスターシークレットＭＫ＿ｉが損なわれた場合に、すべてのデバイスを取り替えなくても別のシークレットに切り替えることが可能である。
【００４２】
決定論的ケースにおける欠点は、マスターシークレットの露呈によって、明らかに、攻撃者が正しい公開情報に基づいて何らかの共有シークレットを再生できる事実を含む。複数のマスターキーのケースでは、すべてのシークレットの破棄、すなわち、新しい組のシークレットへの切り替えが必要である。
【００４３】
一方、マスターキーを記憶して、共有シークレットを発生させるために使用されるデバイスは、耐不正変更なものであるべきである。さらに、ＨＳＭは、バリデーションシステムの安全な境界線の外にさらされないので、リークのリスクを減少させることができる。
【００４４】
ランダム発生
共有シークレットはランダムに発生させることが可能である。良好で安全なランダム発生源が、これらのシークレットを発生させるために選択されるべきである。（真の）ランダム発生器は、ランダム性を自然に生じさせる発生源を必要とする。実際には、共有シークレットの発生に対して２つの可能性ある方法がある。
【００４５】
１）ハードウェアベース発生器は、物理現象で生じるランダム性を活用することができる。インプリメンテーションは、発振器に基づき、そしてアクティブ攻撃を行なうことがより困難であるような方法で組み込むことが可能である。
２）良好なソフトウェアランダム発生器を設計することは容易なタスクではないが、ソフトウェアベース発生器がある。効率的だが、簡単なインプリメンテーションは、さまざまな源に基づくことができ、サンプル化されたシーケンスにＳＨＡ−１のような一方向関数を適用すべきである。
【００４６】
例えば、記憶の際に、耐不正変更ハードウェア暗号化を使用して共有シークレットを暗号化し、要求されたときのみに共有シークレットを明かすことによって、共有シークレットは、安全に記憶すべきである。例えば、共有シークレットは、ＨＯＴＰ値を確認する必要があるとき解読され、ＲＡＭにおける露呈を短期間に制限するためにすぐに再暗号化される。共有シークレットを保持しているデータ記憶装置は、バリデーションシステムおよびシークレットデータベースに対する直接的な攻撃を回避するために、安全な領域内にあるべきである。
【００４７】
特に、共有シークレットへのアクセスは、バリデーションシステムのみによって要求されるプログラムおよびプロセスに限定されるべきである。共有シークレットの保護は、最重要である。
【００４８】
ＨＯＴＰアルゴリズムの安全性は、以下の数式、
Ｓｅｃ＝ｓｖ／１０＾Digit
によって、概算できる。
【００４９】
ここで、
−Ｓｅｃは、敵対者の成功の確率である。
−ｓは、ルックアヘッド同期化ウィンドウのサイズを表す。
−ｖは、妥当性確認試行の数を表す。
−Digitは、ＨＯＴＰ値の数字の数を表す。
【００５０】
これは、システムユーザビリティを依然として維持しながら望みのレベルの安全性が実現されるまで、ｓ、Ｔ（攻撃者による試行の数を制限するスロットルパラメータ）およびDigitを調整することができる。
【００５１】
共有シークレットＫに付加的な認証要素を含めることが望ましいことがある。これらの付加的な要素は、他のものによって容易に獲得されないがトークンに知られている何らかのデータで構成することが可能である。このようなデータの例は、
* ユーザ入力としてトークンで獲得されたＰＩＮまたはパスワード
* 電話番号
* トークンでプログラム的に利用可能な何らかの一意的な識別子
を含む。
【００５２】
このシナリオでは、複合共有シークレットＫが、１つ以上の付加的な認証要素と組み合わされているランダムシード値から、プロビジョニングプロセス中に作られる。サーバは、複合シークレットを要求に応じて作ること、または記憶することのいずれも可能である。いずれにせよ、インプリメンテーションの選択に基づいて、トークンは、シード値のみを記憶することができる。トークンがＨＯＴＰ計算を行なうとき、トークンは、ローカル的に取り出されたまたは入力された他の認証要素の値、およびシード値からＫを計算することができる。
【００５３】
複合共有シークレットの使用は、トークンに付加的な認証要素を含めることによってＨＯＴＰベースの認証システムを強化することができる。トークンが信頼あるデバイスである限り、このアプローチは、他のデバイスに対する（ユーザ入力のＰＩＮのような）認証要素の露呈を必要としない、さらなる利点を持つ。
【００５４】
以下は、ＨＯＴＰ アルゴリズムの例示的なインプリメンテーションである。
／*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* ＨＯＴＰワンタイムパスワードアルゴリズム
*
*／
／* Copyright(Ｃ)2004,OATH. すべての権利が留保されている。
*
* このソフトウェアまたはこの関数に言及または参照している全マテリアルにおいて
* “OATH HOTP Algorithm”としてこのソフトウェアが識別されていることを
* 条件として、このソフトウェアを複製して使用するライセンスを許可する。
【００５５】
*
* 派生作品に言及または参照する全マテリアルにおいて、
* “OATH HOTPアルゴリズムから派生した”として、
* このような作品が識別されていることを条件として、
* 派生作品を作成して使用するライセンスも許可する。
*
* OATH(Open AuTHentication)およびそのメンバは、
* 何らかの特定の目的のためにこのソフトウェアの販売適性、
* またはこのソフトウェアの適合性のいずれに関しても
* 代表するものではない。
*
* いかなる種類の明示的または黙示的な保証をすることなく、“そのまま”で
* 提供されているものであり、ＯＡＴＨおよびそのメンバは、このソフトウェアに * 関するいかなる種類のいかなる保証または責任も明示的に否認する。
*
* これらの注意書きは、この文書および／またはソフトウェアの
* いかなる部分のいかなる複製においても保持されなければならない。
*／
【数２】
【００５６】
／**
* このクラスは、ＨＭＡＣ−ＳＨＡ１を提供するＪＣＥを使用して、
* ワンタイムパスワード（ＯＴＰ）を計算するために使用される。
* 静的方法を含む。
*
* ＠製作者 Loren Hart
* ＠１．０バージョン
*／
【数３】
【００５７】
／**
* クレジットカードアルゴリズムを使用して、チェックサムを計算。
* このアルゴリズムは、何らかの単一のミスタイプされた数字、
* および隣接する数字の何らかの単一の入れ換えを
* 検出する効果を持つ。
*
* ＠param num チェックサムを計算する数
* ＠param degit 数の有効桁の数
*
* ＠return numのチェックサム
*／
【数４】
【００５８】
／**
* この方法は、ＪＣＥを使用して、
* ＨＭＡＣ−ＳＨＡ１アルゴリズムを提供する。
* ＨＭＡＣは、ハッシュされたメッセージ認証コードを計算し、
* このケースでは、ＳＨＡ１が、使用されるハッシュアルゴリズムである。
*
* ＠param keyBytes ＨＭＡＣ−ＳＨＡ１キーに使用するバイト
* ＠param text 認証されるべきメッセージまたはテキスト
*
* ＠throws NoSuchAlgorithmException プロバイダが
* ＨｍａｃＳＨＡ１またはＨＭＡＣ−ＳＨＡ１
* ダイジェストアルゴリズムのいずれも利用可能にしない場合
* ＠throws InvalidKeyException
* 提供されたシークレットが、有効なＨＭＡＣ−ＳＨＡ１キーでなかった。
*
*／
【数５】
【００５９】
／**
* この方法は、所定の組のパラメータに対して
* ＯＴＰ値を発生させる。
*
* ＠param secret 共有シークレット
* ＠param movingFactor 使用ベースで変化する
* カウンタ、時間、または他の値
* ＠param codeDigit もしあれば、
* チェックサムを含まないＯＴＰの数字の数
* ＠param addCheksum チェックサムの数字をＯＴＰに
* 追加すべきか否かを示すフラグ
* ＠param truncationOffset 打ち切りを開始するために
* ＭＡＣ結果に入れるオフセット
* この値が０．．．１５の範囲外である場合、
* 動的打ち切りが使用される。
* ＭＡＣの最後のバイトの最後の４ビットが
* 開始オフセットを決定するために
* 使用されるときに動的打ち切りである。
* ＠throws NoSuchAlgorithmException プロバイダが、ＨｍａｃＳＨＡ１または
* ＨＭＡＣ−ＳＨ１ダイジェストアルゴリズム
* のいずれも利用可能にしない場合
* ＠throws InvalidKeyException
* 提供されたシークレットが、
* 有効なＨＭＡＣ−ＳＨＡ１キーでなかった。
【００６０】
*
* ＠return ｛＠link codeDigits｝数字プラス、
* 要求された場合にはオプション的なチェックサム数字を含む
* ベース１０のＡ数値ストリング
*／
【数６】
【００６１】
カスタマイズされたインプレメンテーションに使用できるバリエーションとして、ＨＯＴＰアルゴリズムに対していくつかの拡張を行なうことができる。
【００６２】
安全性に関する簡単な拡張は、ＨＭＡＣ−ＳＨＡ１値から、より多い数字を取り出すことである。例えば、１０＾８を法としたＨＯＴＰ値を計算して、８数字のＨＯＴＰ値を作ることは、敵対者の成功の確率をｓｖ／１０＾６からｓｖ／１０＾８に減少させる。このことは、例えば、Ｔおよび／またはｓを増加させることによって、ユーザビリティを向上する好機を与え、一方では依然として全体的により良い安全性を実現することができる。例えば、ｓ＝１０で１０ｖ／１０＾８＝ｖ／１０＾７＜ｖ／１０＾６である。このｖ／１０＾６は、ｓ＝１のときに６数字コードに対して理論上最適である。
【００６３】
別のオプションは、Ａ−Ｚおよび０−９値を使用することである。もっと正確に言えば０、ＯおよびＱとともに、ｌ，１およびＩは非常に類似しており、小型ディスプレイでは同一に見える可能性があるので、文字間の何らかの混乱を回避するために、英数字のアルファベットから抽出した３２個のシンボルのサブセットを使用する。直接的な結果は、安全性が、６数字のＨＯＴＰ値に対するｓｖ／３２＾６、および８数字のＨＯＴＰ値に対するｓｖ／３２＾８のオーダーになることである。３２＾６＞１０＾９であるので、６つの英数字のＨＯＴＰコードの安全性は、９数字のＨＯＴＰ値よりわずかに良く、９数字のＨＯＴＰ値は提案されているアルゴリズムによってサポートされているＨＯＴＰコードの最大の長さである。３２＾８＞１０＾１２であるので、８個の英数字のＨＯＴＰコードの安全性は、９数字のＨＯＴＰ値よりかなり良い。ＨＯＴＰ値を表示して入力するのに使用されるトークン／インターフェイスおよびアプリケーションに依存して、英数字の値を選択することは、低コストで安全性を向上させ、ユーザにインパクトを与える簡単かつ効率的な方法となり得る。
【００６４】
ＨＯＴＰ値のショートシーケンス（例えば、２または３）を入力する再同期化について述べると、これは、プロトコルに対する概念として一般化することが可能である。入力するＨＯＴＰシーケンスの長さを規定するパラメータＬを追加することができる。デフォルトによって、値Ｌは１に設定すべきであるが、安全性を増強させる必要がある場合、ユーザは、（おそらくは、短期間に、または特定の動作で）Ｌ個のＨＯＴＰ値を入力するように要求されるかもしれない。これは、ＨＯＴＰの長さを増加せずに、または英数字値を使用せずに安全性を強化する別の方法となり得る。
【００６５】
システムは、（例えば、毎晩、または週に２回等）定期的に同期化を要求する、また、この目的を実現するために、Ｌ個のＨＯＴＰ値のシーケンスを要求するようにプログラム化することもできる。
【００６６】
クライアントが、アクセスして、ＨＯＴＰ値のみではなく、カウンタ値のような他の情報も送ることができると仮定すると、より効率的で安全な再同期化の方法が可能である。クライントアプリケーションは、ＨＯＴＰ−クライント値、および関連するＣ−クライントカウンタ値を送ることができる。ＨＯＴＰ値は、カウンタのメッセージ認証コードとして機能するものである。
【００６７】
以下がすべて真である場合に、サーバが受け入れる。ここで、Ｃ−サーバは、Ｃ−サーバ自体の現在のカウンタ値である。
【００６８】
１）Ｃ−クラインアト＞＝Ｃ−サーバ
２）Ｃ−クライント−Ｃ−サーバ＜＝ｓ
３）ＨＯＴＰ−クライントが有効なＨＯＴＰ（Ｋ，Ｃ−Ｃｌｉｅｎｔ）であることをチェック。
４）真である場合に、サーバがＣ−クライアント＋１にＣを設定し、クライアントが認証される。
このケースでは、これ以上、ルックアヘッドウィンドウを管理する必要がない。敵対者の成功の確率は、たったｖ／１０＾６、すなわち、およそ１００万分のｖである。副次的な利益は、明らかに、“際限なく”ｓを増加させることができるので、安全性に影響を及ぼさないで、システムのユーザビリティを向上させることができる。この再同期化プロトコルは、クライアントおよびサーバアプリケーションに対する関連する影響が受け入れ可能であると考えられるときにはいつでも使用することができる。
【００６９】
ワンタイムパスワード値、すなわち、ＨＯＴＰ（Ｋ，Ｃ，［Ｄａｔａ］）を発生させるために使用されるデータフィールドの導入を別のオプションとすることができる。ここで、Ｄａｔａは、例えば、Ｄａｔａ＝Ａｄｄｒｅｓｓ｜ＰＩＮのような、識別関連情報のさまざまな部分の連結とすることができるオプション的なフィールドである。
【００７０】
１つは、ムービング係数のみとして、またはＣｏｕｎｔｅｒとの組み合わせのいずれでＴｉｍｅｒも使用できる。このケースでは、例えば、Ｄａｔａ＝Ｔｉｍｅｒであり、ここで、Ｔｉｍｅｒは、例えば、特定の時間ステップを与えるために、いくつかの係数（８、１６、３２等）で除算されたＵＮＩＸ（登録商標）−時間（１９７０年１月１日以来のＧＭＴの秒）であってもよい。ワンタイムパスワードに対する時間ウィンドウは、以前に規定されたような再同期化パラメータで乗算された時間ステップと等しい。例えば、時間ステップとして６４秒をとって、再同期化パラメータに対して７を用いた場合に、＋／−３分の受け入れウィンドウを得る。Ｄａｔａフィールドが明確に指定されることを仮定すると、Ｄａｔａフィールドを使用することによって、アルゴリズムのインプレメンテーションをより柔軟にできる。
【００７１】
メモリに結合されているプロセッサによって、本発明の実施形態を実現できる。プロセッサは、汎用マイクロプロセッサ、またはハードウェアおよび／またはファームウェアで本発明の実施形態にしたがった方法の少なくとも一部を実現する特定用途向け集積回路とすることも可能である。メモリは、ランダムアクセスメモリ、ハードディスク、フラッシュメモリ、およびこれらに類するもののような、デジタル情報を記憶できる任意のデバイスとすることができる。メモリは、プロセッサによって実行され、本発明の実施形態にしたがった方法の少なくとも一部を行なうように適合されている命令を記憶できる。プロセッサは、ネットワークに結合され、（ＯＴＰおよび他のデータのような）認証データを妥当性確認のためにこのネットワークを通して送ることができる。
【００７２】
本発明にしたがった認証システムは、トークンプロセッサおよびトークンメモリを備えたトークンと、サーバプロセッサおよびサーバメモリを備えたバリデーションサーバとを具備していてもよい。トークンプロセッサは、トークンメモリ中に記憶されている命令に基づいてＯＴＰ発生アルゴリズムを実現する。トークンメモリは、共有シークレットＫおよびトークンカウンタ値Ｃを記憶することも可能である。バリデーションサーバプロセッサは、バリデーションサーバメモリに記憶されている命令、ならびにバリデーションサーバメモリに記憶されているバリデーションサーバカウンタ値Ｃ’および共有シークレットＫに基づいて、ＯＴＰバリデーションアルゴリズムを実現できる。バリデーションサーバメモリはスロットルパラメータＴ、ルックアヘッドウィンドウサイズｓ等のような、他のパラメータも記憶することができる。
【００７３】
トークンは、ＫおよびＣに基づいて計算されたそのワンタイムパスワードをバリデーションサーバに送ることができる。バリデーションサーバは、ＫおよびＣ’に基づいて、ワンタイムパスワードを計算することができる。整合しない場合、バリデーションサーバは、ＫおよびＣ’＋ｎに基づいて、次のいくつかのワンタイムパスワードを計算することができる。ここで、ｎは１からｓの整数である。これらの計算されたワンタイムパスワードのいずれもトークンから受け取ったワンタイムパスワードと整合しない場合、バリデーションサーバは妥当性確認試行の失敗を示す信号を送ることができる。計算されたワンタイムパスワードのうちの１つがトークンから受け取ったワンタイムパスワードと整合する場合、バリデーションサーバは妥当性確認の成功を示す信号を送ることができる。バリデーションサーバは、Ｔ回の妥当性確認試行の不成功後にさらなる妥当性確認試行を中止することができ、所定のトークンはいくつかのこのような失敗した試行の源であるという趣旨で、システムアドミニストレータにアラートすることができる。
【００７４】
前述の記述は、例示を意味しており、本発明の範囲を限定することを意味していない。先に記述した実施形態を除いた他の実施形態は、当業者によって発明の範囲内に入ることが見い出される。
【特許請求の範囲】
【請求項１】
認証システムにおいて、
トークンメモリに結合され、前記トークンメモリは、共有シークレットキーＫとトークンカウンタ値Ｃとを記憶し、前記トークンメモリは、トークンプロセッサによって実行され、ワンタイムパスワードを発生させるように適合されている命令をさらに記憶するトークンプロセッサと、
バリデーションサーバメモリに結合され、前記バリデーションサーバメモリは、共有シークレットキーＫとバリデーションサーバカウンタ値Ｃ’とを記憶するバリデーションサーバとを具備し、
前記トークンプロセッサは、
キーＫおよびカウンタ値Ｃに基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、ワンタイムパスワードを計算し、
妥当性確認のために、ワンタイムパスワードをバリデーションサーバに送る認証システム。
【請求項２】
前記バリデーションサーバメモリは、ルックアヘッドパラメータｓをさらに記憶し、前記バリデーションサーバメモリの命令は、バリデーションサーバプロセッサによって実行され、前記バリデーションサーバによって計算されたワンタイムパスワードが、トークンから受け取ったワンタイムパスワードと整合するまで、すなわち、ｎが１からｓの整数である、ｎ＝ｓとなるまで、ＫおよびＣ’＋ｎに基づいて、ワンタイムパスワードを計算する請求項１記載のシステム。
【請求項３】
受け取ったワンタイムパスワードと計算されたワンタイムパスワードとの間に整合がない場合に、失敗した妥当性確認試行を示す信号を送る請求項２記載のシステム。
【請求項４】
受け取ったワンタイムパスワードと計算されたワンタイムパスワードとの間に整合がある場合に、前記バリデーションサーバプロセッサが妥当性確認の成功を示す信号を送る請求項２記載のシステム。
【請求項５】
前記バリデーションサーバメモリは、スロットルパラメータＴをさらに記憶し、失敗した妥当性確認試行の数がＴと等しい場合にスロットル信号が送られる請求項３記載のシステム。
【請求項６】
前記バリデーションサーバメモリは、スロットルパラメータＴをさらに記憶し、失敗した妥当性確認試行の数がＴと等しい場合にさらなる妥当性確認試行が中止される請求項１記載のシステム。
【請求項７】
バリデーションサーバにおいて、
プロセッサと、
前記プロセッサに結合されているメモリとを具備し、
前記メモリは、
共有シークレットキーＫと、バリデーションサーバカウンタ値Ｃ’と、ルックアヘッドウィンドウパラメータｓと、命令とを記憶し、
前記命令は、
前記プロセッサによって実行され、ワンタイムパスワードをトークンから受け取り、キーＫおよびカウンタ値Ｃ’に基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、ワンタイムパスワードを計算して、計算されたワンタイムパスワードをトークンから受け取ったワンタイムパスワードと比較するように適合されているバリデーションサーバ。
【請求項８】
前記計算されたワンタイムパスワードが前記トークンから受け取ったワンタイムパスワードと整合しない場合に、前記バリデーションサーバは、ｎが１からｓの整数である、カウンタ値Ｃ’＋ｎおよびキーＫに基づいてワンタイムパスワードを計算する請求項７記載のバリデーションサーバ。
【請求項９】
前記受け取ったワンタイムパスワードが前記計算されたワンタイムパスワードと整合しない場合に、失敗した妥当性確認試行を示す信号を送る請求項８記載のバリデーションサーバ。
【請求項１０】
前記受け取ったワンタイムパスワードが前記計算されたワンタイムパスワードと整合しない場合に、妥当性確認の成功を示す信号を送る請求項８記載のバリデーションサーバ。
【請求項１１】
前記メモリは、スロットルパラメータＴを記憶し、Ｔ回失敗した妥当性確認試行の後にトークンからのさらなる妥当性確認試行が中止される請求項８記載のバリデーションサーバ。
【請求項１２】
キーＫおよびカウンタ値Ｃに基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、トークンによって生成されたワンタイムパスワードを確認する方法において、
キーＫおよびカウンタ値Ｃ’に基づいてＨＭＡＣ−ＳＨＡ−１値を発生させることによって、受け取ったワンタイムパスワードと比較するワンタイムパスワードを計算することと、
Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることと、
前記計算されたワンタイムパスワードを前記受け取ったワンタイムパスワードと比較して整合しない場合に、Ｃ’を１だけ増加させ、ワンタイムパスワードを再計算し、それでもなお、整合しない場合に、Ｃ’＝Ｃ’＋ｓとなるまで、Ｃ’を増加させることを続行し、ワンタイムパスワードを再計算して、再計算されたワンタイムパスワードを前記受け取ったワンタイムパスワードと比較し、ｓはルックアヘッドウィンドウパラメータであることとを含む方法。
【請求項１３】
前記計算された、または再計算されたワンタイムパスワードが、前記受け取ったパスワードと整合する場合に、妥当性確認の成功を示す信号を送る請求項１２記載の方法。
【請求項１４】
前記計算された、または再計算されたワンタイムパスワードが、前記受け取ったパスワードと整合する場合に、失敗した妥当性確認試行を示す信号を送る請求項１２記載の方法。
【請求項１５】
失敗した妥当性確認試行がスロットルパラメータＴを超えた場合に、妥当性確認試行を中止することをさらに含む請求項１４記載の方法。
【請求項１】
認証システムにおいて、
トークンメモリに結合され、前記トークンメモリは、共有シークレットキーＫとトークンカウンタ値Ｃとを記憶し、前記トークンメモリは、トークンプロセッサによって実行され、ワンタイムパスワードを発生させるように適合されている命令をさらに記憶するトークンプロセッサと、
バリデーションサーバメモリに結合され、前記バリデーションサーバメモリは、共有シークレットキーＫとバリデーションサーバカウンタ値Ｃ’とを記憶するバリデーションサーバとを具備し、
前記トークンプロセッサは、
キーＫおよびカウンタ値Ｃに基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、ワンタイムパスワードを計算し、
妥当性確認のために、ワンタイムパスワードをバリデーションサーバに送る認証システム。
【請求項２】
前記バリデーションサーバメモリは、ルックアヘッドパラメータｓをさらに記憶し、前記バリデーションサーバメモリの命令は、バリデーションサーバプロセッサによって実行され、前記バリデーションサーバによって計算されたワンタイムパスワードが、トークンから受け取ったワンタイムパスワードと整合するまで、すなわち、ｎが１からｓの整数である、ｎ＝ｓとなるまで、ＫおよびＣ’＋ｎに基づいて、ワンタイムパスワードを計算する請求項１記載のシステム。
【請求項３】
受け取ったワンタイムパスワードと計算されたワンタイムパスワードとの間に整合がない場合に、失敗した妥当性確認試行を示す信号を送る請求項２記載のシステム。
【請求項４】
受け取ったワンタイムパスワードと計算されたワンタイムパスワードとの間に整合がある場合に、前記バリデーションサーバプロセッサが妥当性確認の成功を示す信号を送る請求項２記載のシステム。
【請求項５】
前記バリデーションサーバメモリは、スロットルパラメータＴをさらに記憶し、失敗した妥当性確認試行の数がＴと等しい場合にスロットル信号が送られる請求項３記載のシステム。
【請求項６】
前記バリデーションサーバメモリは、スロットルパラメータＴをさらに記憶し、失敗した妥当性確認試行の数がＴと等しい場合にさらなる妥当性確認試行が中止される請求項１記載のシステム。
【請求項７】
バリデーションサーバにおいて、
プロセッサと、
前記プロセッサに結合されているメモリとを具備し、
前記メモリは、
共有シークレットキーＫと、バリデーションサーバカウンタ値Ｃ’と、ルックアヘッドウィンドウパラメータｓと、命令とを記憶し、
前記命令は、
前記プロセッサによって実行され、ワンタイムパスワードをトークンから受け取り、キーＫおよびカウンタ値Ｃ’に基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、ワンタイムパスワードを計算して、計算されたワンタイムパスワードをトークンから受け取ったワンタイムパスワードと比較するように適合されているバリデーションサーバ。
【請求項８】
前記計算されたワンタイムパスワードが前記トークンから受け取ったワンタイムパスワードと整合しない場合に、前記バリデーションサーバは、ｎが１からｓの整数である、カウンタ値Ｃ’＋ｎおよびキーＫに基づいてワンタイムパスワードを計算する請求項７記載のバリデーションサーバ。
【請求項９】
前記受け取ったワンタイムパスワードが前記計算されたワンタイムパスワードと整合しない場合に、失敗した妥当性確認試行を示す信号を送る請求項８記載のバリデーションサーバ。
【請求項１０】
前記受け取ったワンタイムパスワードが前記計算されたワンタイムパスワードと整合しない場合に、妥当性確認の成功を示す信号を送る請求項８記載のバリデーションサーバ。
【請求項１１】
前記メモリは、スロットルパラメータＴを記憶し、Ｔ回失敗した妥当性確認試行の後にトークンからのさらなる妥当性確認試行が中止される請求項８記載のバリデーションサーバ。
【請求項１２】
キーＫおよびカウンタ値Ｃに基づいてＨＭＡＣ−ＳＨＡ−１値を発生させ、Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることによって、トークンによって生成されたワンタイムパスワードを確認する方法において、
キーＫおよびカウンタ値Ｃ’に基づいてＨＭＡＣ−ＳＨＡ−１値を発生させることによって、受け取ったワンタイムパスワードと比較するワンタイムパスワードを計算することと、
Digitがワンタイムパスワードの数字の数である、１０＾Digitを法として、発生されたＨＭＡＣ−ＳＨＡ−１値を打ち切ることと、
前記計算されたワンタイムパスワードを前記受け取ったワンタイムパスワードと比較して整合しない場合に、Ｃ’を１だけ増加させ、ワンタイムパスワードを再計算し、それでもなお、整合しない場合に、Ｃ’＝Ｃ’＋ｓとなるまで、Ｃ’を増加させることを続行し、ワンタイムパスワードを再計算して、再計算されたワンタイムパスワードを前記受け取ったワンタイムパスワードと比較し、ｓはルックアヘッドウィンドウパラメータであることとを含む方法。
【請求項１３】
前記計算された、または再計算されたワンタイムパスワードが、前記受け取ったパスワードと整合する場合に、妥当性確認の成功を示す信号を送る請求項１２記載の方法。
【請求項１４】
前記計算された、または再計算されたワンタイムパスワードが、前記受け取ったパスワードと整合する場合に、失敗した妥当性確認試行を示す信号を送る請求項１２記載の方法。
【請求項１５】
失敗した妥当性確認試行がスロットルパラメータＴを超えた場合に、妥当性確認試行を中止することをさらに含む請求項１４記載の方法。
【公表番号】特表２００８−５１７３８４（Ｐ２００８−５１７３８４Ａ）
【公表日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願番号】特願２００７−５３６９６３（Ｐ２００７−５３６９６３）
【出願日】平成１７年１０月１７日（２００５．１０．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３７１１３
【国際公開番号】ＷＯ２００６／０４４７１７
【国際公開日】平成１８年４月２７日（２００６．４．２７）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
【公表日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願日】平成１７年１０月１７日（２００５．１０．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３７１１３
【国際公開番号】ＷＯ２００６／０４４７１７
【国際公開日】平成１８年４月２７日（２００６．４．２７）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]