[要約] RFC 6238は、TOTP: Time-Based One-Time Password Algorithmに関する文書で、時間に基づく一度限りのパスワードを生成するためのアルゴリズムを定義しています。このアルゴリズムの目的は、2要素認証などのセキュリティ強化手段として、定期的に変化するパスワードを提供することです。利用場面としては、オンラインバンキング、VPNアクセス、その他のセキュアなログイン要求があります。関連するRFCにはRFC 4226（HOTP: An HMAC-Based One-Time Password Algorithm）があり、TOTPはこのHOTPを時間ベースで拡張したものです。
Internet Engineering Task Force (IETF) D. M'Raihi
Request for Comments: 6238 Verisign, Inc.
Category: Informational S. Machani
ISSN: 2070-1721 Diversinet Corp.
M. Pei
Symantec
J. Rydell
Portwise, Inc.
May 2011
TOTP: Time-Based One-Time Password Algorithm
TOTP：時間ベースのワンタイムパスワードアルゴリズム
Abstract
概要
This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.
このドキュメントでは、RFC 4226で定義されている、時間ベースの移動係数をサポートするための、ワンタイムパスワード（OTP）アルゴリズムの拡張、つまりHMACベースのワンタイムパスワード（HOTP）アルゴリズムについて説明します。 HOTPアルゴリズムは、移動係数がイベントカウンターであるイベントベースのOTPアルゴリズムを指定します。現在の作業では、移動係数は時間値に基づいています。 OTPアルゴリズムの時間ベースのバリアントは、短期間のOTP値を提供します。これは、セキュリティを強化するために望ましいものです。
The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations.
提案されたアルゴリズムは、リモートの仮想プライベートネットワーク（VPN）アクセスやWi-Fiネットワークログオンからトランザクション指向のWebアプリケーションまで、幅広いネットワークアプリケーションで使用できます。著者らは、共通の共有アルゴリズムが、商用およびオープンソース実装間の相互運用性を可能にすることにより、インターネットでの2要素認証の採用を促進すると信じています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6238.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6238で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Background .................................................3
2. Notation and Terminology ........................................3
3. Algorithm Requirements ..........................................3
4. TOTP Algorithm ..................................................4
4.1. Notations ..................................................4
4.2. Description ................................................4
5. Security Considerations .........................................5
5.1. General ....................................................5
5.2. Validation and Time-Step Size ..............................6
6. Resynchronization ...............................................7
7. Acknowledgements ................................................7
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Appendix A. TOTP Algorithm: Reference Implementation ...............9
Appendix B. Test Vectors ..........................................14
This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in [RFC4226], to support the time-based moving factor.
このドキュメントは、時間ベースの移動係数をサポートするための、[RFC4226]で定義されている、ワンタイムパスワード（OTP）アルゴリズム、つまりHMACベースのワンタイムパスワード（HOTP）アルゴリズムの拡張について説明します。
As defined in [RFC4226], the HOTP algorithm is based on the HMAC-SHA-1 algorithm (as specified in [RFC2104]) and applied to an increasing counter value representing the message in the HMAC computation.
[RFC4226]で定義されているように、HOTPアルゴリズムはHMAC-SHA-1アルゴリズム（[RFC2104]で指定）に基づいており、HMAC計算でメッセージを表す増加するカウンター値に適用されます。
Basically, the output of the HMAC-SHA-1 calculation is truncated to obtain user-friendly values:
基本的に、HMAC-SHA-1計算の出力は、ユーザーフレンドリーな値を取得するために切り捨てられます。
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
where Truncate represents the function that can convert an HMAC-SHA-1 value into an HOTP value. K and C represent the shared secret and counter value; see [RFC4226] for detailed definitions.
ここで、Truncateは、HMAC-SHA-1値をHOTP値に変換できる関数を表します。 KとCは、共有される秘密とカウンター値を表します。詳細な定義については[RFC4226]を参照してください。
TOTP is the time-based variant of this algorithm, where a value T, derived from a time reference and a time step, replaces the counter C in the HOTP computation.
TOTPは、このアルゴリズムの時間ベースのバリアントです。この場合、HOTP計算では、時間参照とタイムステップから派生した値TがカウンターCを置き換えます。
TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the HMAC-SHA-1 function that has been specified for the HOTP computation in [RFC4226].
TOTP実装は、SHA-256またはSHA-512 [SHA2]ハッシュ関数に基づいて、HMAC-SHA-256またはHMAC-SHA-512関数を使用する場合があります（MAYでHOTP計算用に指定されているHMAC-SHA-1関数の代わりに） [RFC4226]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section summarizes the requirements taken into account for designing the TOTP algorithm.
このセクションでは、TOTPアルゴリズムを設計するために考慮に入れられる要件を要約します。
R1: The prover (e.g., token, soft token) and verifier (authentication or validation server) MUST know or be able to derive the current Unix time (i.e., the number of seconds elapsed since midnight UTC of January 1, 1970) for OTP generation. See [UT] for a more detailed definition of the commonly known "Unix time". The precision of the time used by the prover affects how often the clock synchronization should be done; see Section 6.
R1：証明者（トークン、ソフトトークンなど）と検証者（認証または検証サーバー）は、OTPの現在のUnix時間（つまり、1970年1月1日の真夜中UTCから経過した秒数）を知っているか、導出できる必要がある世代。一般的に知られている「Unix時間」の詳細な定義については、[UT]を参照してください。証明者が使用する時刻の精度は、クロック同期を実行する頻度に影響します。セクション6を参照してください。
R2: The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret.
R2：証明者と検証者は、共有シークレットを生成するために、同じシークレットまたはシークレット変換の知識を共有する必要があります。
R3: The algorithm MUST use HOTP [RFC4226] as a key building block.
R3：アルゴリズムは、HOTP [RFC4226]を主要なビルディングブロックとして使用する必要があります。
R4: The prover and verifier MUST use the same time-step value X.
R4：証明者と検証者は同じタイムステップ値Xを使用する必要があります。
R5: There MUST be a unique secret (key) for each prover.
R5：各証明者には一意の秘密（鍵）が必要です。
R6: The keys SHOULD be randomly generated or derived using key derivation algorithms.
R6：鍵はランダムに生成するか、鍵導出アルゴリズムを使用して導出する必要があります（SHOULD）。
R7: The keys MAY be stored in a tamper-resistant device and SHOULD be protected against unauthorized access and usage.
R7：鍵は改ざん防止装置に格納される場合があり、不正なアクセスや使用から保護する必要があります。
This variant of the HOTP algorithm specifies the calculation of a one-time password value, based on a representation of the counter as a time factor.
HOTPアルゴリズムのこのバリアントは、時間の要素としてのカウンターの表現に基づいて、ワンタイムパスワード値の計算を指定します。
o X represents the time step in seconds (default value X = 30 seconds) and is a system parameter.
o Xは時間ステップを秒単位で表し（デフォルト値はX = 30秒）、システムパラメータです。
o T0 is the Unix time to start counting time steps (default value is 0, i.e., the Unix epoch) and is also a system parameter.
o T0はタイムステップのカウントを開始するUnix時間（デフォルト値は0、つまりUnixエポック）であり、システムパラメータでもあります。
Basically, we define TOTP as TOTP = HOTP(K, T), where T is an integer and represents the number of time steps between the initial counter time T0 and the current Unix time.
基本的に、TOTPをTOTP = HOTP（K、T）として定義します。Tは整数であり、初期カウンター時間T0と現在のUnix時間の間のタイムステップ数を表します。
More specifically, T = (Current Unix time - T0) / X, where the
default floor function is used in the computation.
For example, with T0 = 0 and Time Step X = 30, T = 1 if the current Unix time is 59 seconds, and T = 2 if the current Unix time is 60 seconds.
たとえば、T0 = 0および時間ステップX = 30の場合、現在のUNIX時間が59秒の場合はT = 1、現在のUNIX時間が60秒の場合はT = 2です。
The implementation of this algorithm MUST support a time value T larger than a 32-bit integer when it is beyond the year 2038. The value of the system parameters X and T0 are pre-established during the provisioning process and communicated between a prover and verifier as part of the provisioning step. The provisioning flow is out of scope of this document; refer to [RFC6030] for such provisioning container specifications.
このアルゴリズムの実装は、2038年を超える場合、32ビット整数より大きい時間値Tをサポートする必要があります。システムパラメータXおよびT0の値は、プロビジョニングプロセス中に事前に確立され、証明者と検証者の間で通信されますプロビジョニング手順の一部として。プロビジョニングフローはこのドキュメントの範囲外です。このようなプロビジョニングコンテナの仕様については、[RFC6030]を参照してください。
The security and strength of this algorithm depend on the properties of the underlying building block HOTP, which is a construction based on HMAC [RFC2104] using SHA-1 as the hash function.
このアルゴリズムのセキュリティと強度は、基盤となるビルディングブロックHOTPのプロパティに依存します。これは、ハッシュ関数としてSHA-1を使用するHMAC [RFC2104]に基づく構築です。
The conclusion of the security analysis detailed in [RFC4226] is that, for all practical purposes, the outputs of the dynamic truncation on distinct inputs are uniformly and independently distributed strings.
[RFC4226]で詳述されているセキュリティ分析の結論は、すべての実際的な目的のために、個別の入力での動的トランケーションの出力は均一かつ独立して分散された文字列であるということです。
The analysis demonstrates that the best possible attack against the HOTP function is the brute force attack.
分析により、HOTP機能に対する最善の攻撃はブルートフォース攻撃であることを示しています。
As indicated in the algorithm requirement section, keys SHOULD be chosen at random or using a cryptographically strong pseudorandom generator properly seeded with a random value.
アルゴリズム要件のセクションで示したように、キーはランダムに選択するか、ランダムな値が適切にシードされた暗号的に強力な疑似ランダムジェネレーターを使用して選択する必要があります。
Keys SHOULD be of the length of the HMAC output to facilitate interoperability.
相互運用性を促進するために、キーはHMAC出力の長さである必要があります。
We RECOMMEND following the recommendations in [RFC4086] for all pseudorandom and random number generations. The pseudorandom numbers used for generating the keys SHOULD successfully pass the randomness test specified in [CN], or a similar well-recognized test.
[RFC4086]の推奨事項に従って、すべての疑似乱数と乱数の生成を推奨します。キーを生成するために使用される疑似乱数は、[CN]で指定されたランダム性テスト、または同様のよく認識されたテストに正常に合格する必要があります（SHOULD）。
All the communications SHOULD take place over a secure channel, e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or IPsec connections [RFC4301].
すべての通信は、セキュアソケットレイヤー/トランスポートレイヤーセキュリティ（SSL / TLS）[RFC5246]またはIPsec接続[RFC4301]などの安全なチャネルを介して行われる必要があります（SHOULD）。
We also RECOMMEND storing the keys securely in the validation system, and, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the key is decrypted when needed to verify an OTP value, and re-encrypted immediately to limit exposure in the RAM to a short period of time.
また、検証システムにキーを安全に保存することを推奨します。具体的には、改ざん防止ハードウェア暗号化を使用してキーを暗号化し、必要な場合にのみ公開します。たとえば、OTP値を検証するために必要なときにキーを復号化し、再すぐに暗号化されて、RAMの露出を短時間に制限します。
The key store MUST be in a secure area, to avoid, as much as possible, direct attack on the validation system and secrets database. Particularly, access to the key material should be limited to programs and processes required by the validation system only.
キーストアは、検証システムとシークレットデータベースへの直接攻撃を可能な限り回避するために、安全な領域に配置する必要があります。特に、キーマテリアルへのアクセスは、検証システムのみが必要とするプログラムとプロセスに限定する必要があります。
An OTP generated within the same time step will be the same. When an OTP is received at a validation system, it doesn't know a client's exact timestamp when an OTP was generated. The validation system may typically use the timestamp when an OTP is received for OTP comparison. Due to network latency, the gap (as measured by T, that is, the number of time steps since T0) between the time that the OTP was generated and the time that the OTP arrives at the receiving system may be large. The receiving time at the validation system and the actual OTP generation may not fall within the same time-step window that produced the same OTP. When an OTP is generated at the end of a time-step window, the receiving time most likely falls into the next time-step window. A validation system SHOULD typically set a policy for an acceptable OTP transmission delay window for validation. The validation system should compare OTPs not only with the receiving timestamp but also the past timestamps that are within the transmission delay. A larger acceptable delay window would expose a larger window for attacks. We RECOMMEND that at most one time step is allowed as the network delay.
同じタイムステップ内で生成されたOTPは同じになります。検証システムでOTPを受信したとき、OTPが生成されたときのクライアントの正確なタイムスタンプはわかりません。検証システムは通常、OTPを比較するためにOTPを受信したときにタイムスタンプを使用します。ネットワークレイテンシが原因で、OTPが生成された時刻とOTPが受信システムに到着する時刻の間のギャップ（T、つまりT0からのタイムステップ数）は大きくなる可能性があります。検証システムでの受信時間と実際のOTP生成は、同じOTPを生成した同じタイムステップウィンドウ内に収まらない場合があります。時間ステップウィンドウの最後にOTPが生成されると、受信時間は次の時間ステップウィンドウに入る可能性が高くなります。検証システムは、通常、検証のために許容できるOTP送信遅延ウィンドウのポリシーを設定する必要があります（SHOULD）。検証システムは、OTPを受信タイムスタンプだけでなく、送信遅延内にある過去のタイムスタンプとも比較する必要があります。許容可能な遅延ウィンドウが大きいと、攻撃に対してより大きなウィンドウが表示されます。ネットワーク遅延として許可されるタイムステップは1つだけにすることをお勧めします。
The time-step size has an impact on both security and usability. A larger time-step size means a larger validity window for an OTP to be accepted by a validation system. There are implications for using a larger time-step size, as follows:
時間ステップサイズは、セキュリティとユーザビリティの両方に影響を与えます。タイムステップサイズが大きいほど、検証システムがOTPを受け入れるための有効期間が長くなります。次のように、より大きなタイムステップサイズを使用することには影響があります。
First, a larger time-step size exposes a larger window to attack. When an OTP is generated and exposed to a third party before it is consumed, the third party can consume the OTP within the time-step window.
まず、タイムステップサイズが大きいほど、攻撃対象のウィンドウが大きくなります。 OTPが生成されて消費される前にサードパーティに公開されると、サードパーティはタイムステップウィンドウ内でOTPを消費できます。
We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability.
デフォルトのタイムステップサイズは30秒をお勧めします。このデフォルト値の30秒は、セキュリティと使いやすさのバランスとして選択されています。
Second, the next different OTP must be generated in the next time-step window. A user must wait until the clock moves to the next time-step window from the last submission. The waiting time may not be exactly the length of the time step, depending on when the last OTP was generated. For example, if the last OTP was generated at the halfway point in a time-step window, the waiting time for the next OTP is half the length of the time step. In general, a larger time-step window means a longer waiting time for a user to get the next valid OTP after the last successful OTP validation. A too-large window (for example, 10 minutes) most probably won't be suitable for typical Internet login use cases; a user may not be able to get the next OTP within 10 minutes and therefore will have to re-login to the same site in 10 minutes.
次に、次の異なるOTPを次のタイムステップウィンドウで生成する必要があります。ユーザーは、時計が最後の送信から次のタイムステップウィンドウに移動するまで待機する必要があります。最後のOTPがいつ生成されたかによっては、待ち時間がタイムステップの長さと正確に一致しない場合があります。たとえば、最後のOTPがタイムステップウィンドウの中間点で生成された場合、次のOTPの待機時間はタイムステップの長さの半分になります。一般に、タイムステップウィンドウが大きいほど、最後に成功したOTP検証の後でユーザーが次の有効なOTPを取得するまでの待機時間が長くなります。大きすぎるウィンドウ（たとえば、10分）は、通常のインターネットログインの使用例にはおそらく適していません。ユーザーは10分以内に次のOTPを取得できない可能性があるため、10分以内に同じサイトに再ログインする必要があります。
Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.
証明者は、指定されたタイムステップウィンドウ内で同じOTPを複数回検証者に送信する場合があることに注意してください。検証者は、最初のOTPに対して検証が正常に発行された後、OTPの2回目の試行を受け入れてはなりません。これにより、OTPの1回限りの使用が保証されます。
Because of possible clock drifts between a client and a validation server, we RECOMMEND that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.
クライアントと検証サーバーの間でクロックがずれる可能性があるため、検証者が拒否される前に検証者が「同期していない」タイムステップの数に特定の制限を設定することをお勧めします。
This limit can be set both forward and backward from the calculated time step on receipt of the OTP value. If the time step is 30 seconds as recommended, and the validator is set to only accept two time steps backward, then the maximum elapsed time drift would be around 89 seconds, i.e., 29 seconds in the calculated time step and 60 seconds for two backward time steps.
この制限は、OTP値の受信時に計算されたタイムステップから前方および後方の両方に設定できます。タイムステップが推奨どおり30秒であり、バリデーターが2つのタイムステップのみを受け入れるように設定されている場合、最大経過時間ドリフトは約89秒、つまり計算されたタイムステップで29秒、2つのバックワードで60秒になります。タイムステップ。
This would mean the validator could perform a validation against the current time and then two further validations for each backward step (for a total of 3 validations). Upon successful validation, the validation server can record the detected clock drift for the token in terms of the number of time steps. When a new OTP is received after this step, the validator can validate the OTP with the current timestamp adjusted with the recorded number of time-step clock drifts for the token.
これは、バリデーターが現在の時間に対して検証を実行し、その後、各後方ステップごとにさらに2つの検証を実行できることを意味します（合計3つの検証）。検証が成功すると、検証サーバーは、タイムステップの数に関して、トークンの検出されたクロックドリフトを記録できます。このステップの後に新しいOTPを受信すると、バリデーターは、トークンのタイムステップクロックドリフトの記録された数で調整された現在のタイムスタンプでOTPを検証できます。
Also, it is important to note that the longer a prover has not sent an OTP to a validation system, the longer (potentially) the accumulated clock drift between the prover and the verifier. In such cases, the automatic resynchronization described above may not work if the drift exceeds the allowed threshold. Additional authentication measures should be used to safely authenticate the prover and explicitly resynchronize the clock drift between the prover and the validator.
また、証明者がOTPを検証システムに送信していない時間が長いほど、証明者と検証者の間の累積クロックドリフトが（潜在的に）長くなることに注意することが重要です。このような場合、ドリフトが許容しきい値を超えると、上記の自動再同期が機能しない場合があります。証明者を安全に認証し、証明者と検証者の間のクロックドリフトを明示的に再同期するには、追加の認証手段を使用する必要があります。
The authors of this document would like to thank the following people for their contributions and support to make this a better specification: Hannes Tschofenig, Jonathan Tuliani, David Dix, Siddharth Bajaj, Stu Veath, Shuh Chang, Oanh Hoang, John Huang, and Siddhartha Mohapatra.
このドキュメントの作成者は、これをより良い仕様にするための貢献とサポートに感謝します：Hannes Tschofenig、Jonathan Tuliani、David Dix、Siddharth Bajaj、Stu Veath、Shuh Chang、Oanh Hoang、John Huang、およびSiddharthaモハパトラ。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Recommendations for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake 3rd、D.、Schiller、J。、およびS. Crocker、「Randomness Recommendations for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[RFC4226] M'Raihi、D.、Bellare、M.、Hoornaert、F.、Naccache、D。、およびO. Ranen、「HOTP：An HMAC-Based One-Time Password Algorithm」、RFC 4226、2005年12月。
[SHA2] NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)", October 2008, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.
[SHA2] NIST、「FIPS PUB 180-3：Secure Hash Standard（SHS）」、2008年10月、<http://csrc.nist.gov/publications/fips/ fips180-3 / fips180-3_final.pdf>。
[CN] Coron, J. and D. Naccache, "An Accurate Evaluation of Maurer's Universal Test", LNCS 1556, February 1999, <http://www.gemplus.com/smart/rd/publications/pdf/ CN99maur.pdf>.
[CN] Coron、J。およびD. Naccache、「An Macurer Evaluation of Maurer's Universal Test」、LNCS 1556、1999年2月、<http://www.gemplus.com/smart/rd/publications/pdf/ CN99maur.pdf >。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[RFC6030] Hoyer、P.、Pei、M。、およびS. Machani、「Portable Symmetric Key Container（PSKC）」、RFC 6030、2010年10月。
[UT] Wikipedia, "Unix time", February 2011, <http://en.wikipedia.org/wiki/Unix_time>.
[UT]ウィキペディア、「Unix時間」、2011年2月、<http://en.wikipedia.org/wiki/Unix_time>。
Appendix A. TOTP Algorithm: Reference Implementation
付録A. TOTPアルゴリズム：リファレンス実装
<CODE BEGINS>
<コード開始>
/**
Copyright (c) 2011 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。 * /
import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.math.BigInteger;
import java.util.TimeZone;
/**
* This is an example implementation of the OATH
* TOTP algorithm.
* Visit www.openauthentication.org for more information.
*
* @author Johan Rydell, PortWise, Inc.
*/
public class TOTP {
パブリッククラスTOTP {
private TOTP() {}
/**
* This method uses the JCE to provide the crypto algorithm.
* HMAC computes a Hashed Message Authentication Code with the
* crypto hash algorithm as a parameter.
*
* @param crypto: the crypto algorithm (HmacSHA1, HmacSHA256,
* HmacSHA512)
* @param keyBytes: the bytes to use for the HMAC key
* @param text: the message or text to be authenticated
*/
private static byte[] hmac_sha(String crypto, byte[] keyBytes,
byte[] text){
try {
Mac hmac;
hmac = Mac.getInstance(crypto);
SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW");
hmac.init(macKey);
return hmac.doFinal(text);
} catch (GeneralSecurityException gse) {
throw new UndeclaredThrowableException(gse);
}
}
/**
* This method converts a HEX string to Byte[]
*
* @param hex: the HEX string
*
* @return: a byte array
*/
private static byte[] hexStr2Bytes(String hex){
// Adding one byte to get the right conversion
// Values starting with "0" can be converted
byte[] bArray = new BigInteger("10" + hex,16).toByteArray();
// Copy all the REAL bytes, not the "first"
byte[] ret = new byte[bArray.length - 1];
for (int i = 0; i < ret.length; i++)
ret[i] = bArray[i+1];
return ret;
}
private static final int[] DIGITS_POWER
// 0 1 2 3 4 5 6 7 8
= {1,10,100,1000,10000,100000,1000000,10000000,100000000 };
/**
* This method generates a TOTP value for the given
* set of parameters.
*
* @param key: the shared secret, HEX encoded
* @param time: a value that reflects a time
* @param returnDigits: number of digits to return
*
* @return: a numeric String in base 10 that includes
* {@link truncationDigits} digits
*/
public static String generateTOTP(String key,
String time,
String returnDigits){
return generateTOTP(key, time, returnDigits, "HmacSHA1");
}
/**
* This method generates a TOTP value for the given
* set of parameters.
*
* @param key: the shared secret, HEX encoded
* @param time: a value that reflects a time
* @param returnDigits: number of digits to return
*
* @return: a numeric String in base 10 that includes
* {@link truncationDigits} digits
*/
public static String generateTOTP256(String key,
String time,
String returnDigits){
return generateTOTP(key, time, returnDigits, "HmacSHA256");
}
/**
* This method generates a TOTP value for the given
* set of parameters.
*
* @param key: the shared secret, HEX encoded
* @param time: a value that reflects a time
* @param returnDigits: number of digits to return
*
* @return: a numeric String in base 10 that includes
* {@link truncationDigits} digits
*/
public static String generateTOTP512(String key,
String time,
String returnDigits){
return generateTOTP(key, time, returnDigits, "HmacSHA512");
}
/**
* This method generates a TOTP value for the given
* set of parameters.
*
* @param key: the shared secret, HEX encoded
* @param time: a value that reflects a time
* @param returnDigits: number of digits to return
* @param crypto: the crypto function to use
*
* @return: a numeric String in base 10 that includes
* {@link truncationDigits} digits
*/
public static String generateTOTP(String key,
String time,
String returnDigits,
String crypto){
int codeDigits = Integer.decode(returnDigits).intValue();
String result = null;
// Using the counter
// First 8 bytes are for the movingFactor
// Compliant with base RFC 4226 (HOTP)
while (time.length() < 16 )
time = "0" + time;
// Get the HEX in a Byte[]
byte[] msg = hexStr2Bytes(time);
byte[] k = hexStr2Bytes(key);
byte[] hash = hmac_sha(crypto, k, msg);
// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;
int binary =
((hash[offset] & 0x7f) << 24) |
((hash[offset + 1] & 0xff) << 16) |
((hash[offset + 2] & 0xff) << 8) |
(hash[offset + 3] & 0xff);
int otp = binary % DIGITS_POWER[codeDigits];
int otp =バイナリ％DIGITS_POWER [codeDigits];
result = Integer.toString(otp);
while (result.length() < codeDigits) {
result = "0" + result;
}
return result;
}
public static void main(String[] args) {
// Seed for HMAC-SHA1 - 20 bytes
String seed = "3132333435363738393031323334353637383930";
// Seed for HMAC-SHA256 - 32 bytes
String seed32 = "3132333435363738393031323334353637383930" +
"313233343536373839303132";
// Seed for HMAC-SHA512 - 64 bytes
String seed64 = "3132333435363738393031323334353637383930" +
"3132333435363738393031323334353637383930" +
"3132333435363738393031323334353637383930" +
"31323334";
long T0 = 0;
long X = 30;
long testTime[] = {59L, 1111111109L, 1111111111L,
1234567890L, 2000000000L, 20000000000L};
String steps = "0";
DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
try {
System.out.println(
"+---------------+-----------------------+" +
"------------------+--------+--------+");
System.out.println(
"| Time(sec) | Time (UTC format) " +
"| Value of T(Hex) | TOTP | Mode |");
System.out.println(
"+---------------+-----------------------+" +
"------------------+--------+--------+");
for (int i=0; i<testTime.length; i++) {
long T = (testTime[i] - T0)/X;
steps = Long.toHexString(T).toUpperCase();
while (steps.length() < 16) steps = "0" + steps;
String fmtTime = String.format("%1$-11s", testTime[i]);
String utcTime = df.format(new Date(testTime[i]*1000));
System.out.print("| " + fmtTime + " | " + utcTime +
" | " + steps + " |");
System.out.println(generateTOTP(seed, steps, "8",
"HmacSHA1") + "| SHA1 |");
System.out.print("| " + fmtTime + " | " + utcTime +
" | " + steps + " |");
System.out.println(generateTOTP(seed32, steps, "8",
"HmacSHA256") + "| SHA256 |");
System.out.print("| " + fmtTime + " | " + utcTime +
" | " + steps + " |");
System.out.println(generateTOTP(seed64, steps, "8",
"HmacSHA512") + "| SHA512 |");
System.out.println(
"+---------------+-----------------------+" +
"------------------+--------+--------+");
}
}catch (final Exception e){
System.out.println("Error : " + e);
}
}
}
<CODE ENDS>
<コード終了>
This section provides test values that can be used for the HOTP time-based variant algorithm interoperability test.
このセクションでは、HOTP時間ベースのバリアントアルゴリズムの相互運用性テストに使用できるテスト値を提供します。
The test token shared secret uses the ASCII string value "12345678901234567890". With Time Step X = 30, and the Unix epoch as the initial value to count time steps, where T0 = 0, the TOTP algorithm will display the following values for specified modes and timestamps.
テストトークン共有シークレットは、ASCII文字列値「12345678901234567890」を使用します。タイムステップX = 30、タイムステップをカウントする初期値としてUnixエポック（T0 = 0）を使用すると、TOTPアルゴリズムは指定されたモードとタイムスタンプの次の値を表示します。
+-------------+--------------+------------------+----------+--------+
| Time (sec) | UTC Time | Value of T (hex) | TOTP | Mode |
+-------------+--------------+------------------+----------+--------+
| 59 | 1970-01-01 | 0000000000000001 | 94287082 | SHA1 |
| | 00:00:59 | | | |
| 59 | 1970-01-01 | 0000000000000001 | 46119246 | SHA256 |
| | 00:00:59 | | | |
| 59 | 1970-01-01 | 0000000000000001 | 90693936 | SHA512 |
| | 00:00:59 | | | |
| 1111111109 | 2005-03-18 | 00000000023523EC | 07081804 | SHA1 |
| | 01:58:29 | | | |
| 1111111109 | 2005-03-18 | 00000000023523EC | 68084774 | SHA256 |
| | 01:58:29 | | | |
| 1111111109 | 2005-03-18 | 00000000023523EC | 25091201 | SHA512 |
| | 01:58:29 | | | |
| 1111111111 | 2005-03-18 | 00000000023523ED | 14050471 | SHA1 |
| | 01:58:31 | | | |
| 1111111111 | 2005-03-18 | 00000000023523ED | 67062674 | SHA256 |
| | 01:58:31 | | | |
| 1111111111 | 2005-03-18 | 00000000023523ED | 99943326 | SHA512 |
| | 01:58:31 | | | |
| 1234567890 | 2009-02-13 | 000000000273EF07 | 89005924 | SHA1 |
| | 23:31:30 | | | |
| 1234567890 | 2009-02-13 | 000000000273EF07 | 91819424 | SHA256 |
| | 23:31:30 | | | |
| 1234567890 | 2009-02-13 | 000000000273EF07 | 93441116 | SHA512 |
| | 23:31:30 | | | |
| 2000000000 | 2033-05-18 | 0000000003F940AA | 69279037 | SHA1 |
| | 03:33:20 | | | |
| 2000000000 | 2033-05-18 | 0000000003F940AA | 90698825 | SHA256 |
| | 03:33:20 | | | |
| 2000000000 | 2033-05-18 | 0000000003F940AA | 38618901 | SHA512 |
| | 03:33:20 | | | |
| 20000000000 | 2603-10-11 | 0000000027BC86AA | 65353130 | SHA1 |
| | 11:33:20 | | | |
| 20000000000 | 2603-10-11 | 0000000027BC86AA | 77737706 | SHA256 |
| | 11:33:20 | | | |
| 20000000000 | 2603-10-11 | 0000000027BC86AA | 47863826 | SHA512 |
| | 11:33:20 | | | |
+-------------+--------------+------------------+----------+--------+
Table 1: TOTP Table
表1：TOTPテーブル
Authors' Addresses
著者のアドレス
David M'Raihi Verisign, Inc. 685 E. Middlefield Road Mountain View, CA 94043 USA
David M'Raihi Verisign、Inc. 685 E. Middlefield Road Mountain View、CA 94043 USA
EMail: davidietf@gmail.com
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East, Suite 1801 Toronto, Ontario M2J 5C2 Canada
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East、Suite 1801トロントオンタリオ州M2J 5C2カナダ
EMail: smachani@diversinet.com
Mingliang Pei Symantec 510 E. Middlefield Road Mountain View, CA 94043 USA
Mingliang Pei Symantec Symantec 510 E. Middlefield Road Mountain View、CA 94043 USA
EMail: Mingliang_Pei@symantec.com
Johan Rydell Portwise, Inc. 275 Hawthorne Ave., Suite 119 Palo Alto, CA 94301 USA
Johan Rydell Portwise、Inc. 275 Hawthorne Ave.、Suite 119 Palo Alto、CA 94301 USA
EMail: johanietf@gmail.com