[要約] RFC 4226は、HMAC（Hash-based Message Authentication Code）を使用した一回限りのパスワード（OTP）アルゴリズムであるHOTP（HMAC-Based One-Time Password Algorithm）について定義しています。HOTPは、主に二要素認証システムで利用され、ユーザーが事前に共有された秘密とカウンターを基に生成した一度きりのパスワードを使用して認証を行います。このアルゴリズムは、オンラインバンキング、VPNアクセス、セキュアなログインシステムなどで広く採用されています。関連するRFCとしては、RFC 6238（TOTP: Time-Based One-Time Password Algorithm）があり、時間に基づくOTP生成の拡張を提供しています。
Network Working Group D. M'Raihi
Request for Comments: 4226 VeriSign
Category: Informational M. Bellare
UCSD
F. Hoornaert
Vasco
D. Naccache
Gemplus
O. Ranen
Aladdin
December 2005
HOTP: An HMAC-Based One-Time Password Algorithm
HOTP：HMACベースのワンタイムパスワードアルゴリズム
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティに情報を提供するものです。いかなる種類のインターネット標準を定めるものでもありません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）The Internet Society（2005）。
Abstract
概要
This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
このドキュメントでは、ハッシュメッセージ認証コード（HMAC）に基づいて、ワンタイムパスワード値を生成するためのアルゴリズムについて説明します。アルゴリズムのセキュリティ分析が提示され、アルゴリズムの安全な展開に関連する重要なパラメータについて議論します。提案されたアルゴリズムは、リモート仮想プライベートネットワーク（VPN）アクセス、Wi-Fiネットワークログオンからトランザクション指向Webアプリケーションまで、幅広いネットワークアプリケーションで使用できます。
This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. 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.
この作業は、技術コミュニティに自由に配布できるアルゴリズムを指定するための、OATH (Open AuTHentication) メンバーによる共同の取り組みです。著者らは、共通かつ共有されたアルゴリズムが、商用およびオープンソースの実装間での相互運用性を可能にすることで、インターネット上での二要素認証の採用を促進すると確信しています。
Table of Contents
目次
1. Overview ........................................................3
2. Introduction ....................................................3
3. Requirements Terminology ........................................4
4. Algorithm Requirements ..........................................4
5. HOTP Algorithm ..................................................5
5.1. Notation and Symbols .......................................5
5.2. Description ................................................6
5.3. Generating an HOTP Value ...................................6
5.4. Example of HOTP Computation for Digit = 6 ..................7
6. Security Considerations .........................................8
7. Security Requirements ...........................................9
7.1. Authentication Protocol Requirements .......................9
7.2. Validation of HOTP Values .................................10
7.3. Throttling at the Server ..................................10
7.4. Resynchronization of the Counter ..........................11
7.5. Management of Shared Secrets ..............................11
8. Composite Shared Secrets .......................................14
9. Bi-Directional Authentication ..................................14
10. Conclusion ....................................................15
11. Acknowledgements ..............................................15
12. Contributors ..................................................15
13. References ....................................................15
13.1. Normative References .....................................15
13.2. Informative References ...................................16
Appendix A - HOTP Algorithm Security: Detailed Analysis ...........17
A.1. Definitions and Notations .................................17
A.2. The Idealized Algorithm: HOTP-IDEAL .......................17
A.3. Model of Security .........................................18
A.4. Security of the Ideal Authentication Algorithm ............19
A.4.1. From Bits to Digits ................................19
A.4.2. Brute Force Attacks ................................21
A.4.3. Brute force attacks are the best possible attacks ..22
A.5. Security Analysis of HOTP .................................23
Appendix B - SHA-1 Attacks ........................................25
B.1. SHA-1 Status ..............................................25
B.2. HMAC-SHA-1 Status .........................................26
B.3. HOTP Status ...............................................26
Appendix C - HOTP Algorithm: Reference Implementation .............27
Appendix D - HOTP Algorithm: Test Values ..........................32
Appendix E - Extensions ...........................................33
E.1. Number of Digits ..........................................33
E.2. Alphanumeric Values .......................................33
E.3. Sequence of HOTP values ...................................34
E.4. A Counter-Based Resynchronization Method ..................34
E.5. Data Field ................................................35
The document introduces first the context around an algorithm that generates one-time password values based on HMAC [BCK1] and, thus, is named the HMAC-Based One-Time Password (HOTP) algorithm. In Section 4, the algorithm requirements are listed and in Section 5, the HOTP algorithm is described. Sections 6 and 7 focus on the algorithm security. Section 8 proposes some extensions and improvements, and Section 10 concludes this document. In Appendix A, the interested reader will find a detailed, full-fledged analysis of the algorithm security: an idealized version of the algorithm is evaluated, and then the HOTP algorithm security is analyzed.
この文書では、まずHMAC [BCK1]に基づいてワンタイムパスワード値を生成するアルゴリズムの背景を紹介します。したがって、これはHMACベースのワンタイムパスワード（HOTP）アルゴリズムと名付けられています。セクション4ではアルゴリズムの要件を列挙し、セクション5ではHOTPアルゴリズムについて説明します。セクション6と7はアルゴリズムのセキュリティに焦点を当てています。セクション8ではいくつかの拡張と改善を提案し、セクション10でこの文書を締めくくります。付録Aでは、関心のある読者のためにアルゴリズムのセキュリティに関する詳細かつ本格的な分析を提供しています。そこでは、アルゴリズムの理想化されたバージョンが評価され、その後HOTPアルゴリズムのセキュリティが分析されます。
Today, deployment of two-factor authentication remains extremely limited in scope and scale. Despite increasingly higher levels of threats and attacks, most Internet applications still rely on weak authentication schemes for policing user access. The lack of interoperability among hardware and software technology vendors has been a limiting factor in the adoption of two-factor authentication technology. In particular, the absence of open specifications has led to solutions where hardware and software components are tightly coupled through proprietary technology, resulting in high-cost solutions, poor adoption, and limited innovation.
今日、二要素認証の展開は、範囲と規模において非常に限定されたままです。脅威と攻撃のレベルがますます高まっているにもかかわらず、ほとんどのインターネットアプリケーションは依然としてユーザーアクセスの管理を弱い認証方式に依存しています。ハードウェアおよびソフトウェア技術ベンダー間の相互運用性の欠如が、二要素認証技術の採用における制限要因となっています。特に、オープンな仕様の欠如は、ハードウェアとソフトウェアのコンポーネントが独自の技術を通じて密結合されるソリューションにつながり、その結果、高コストなソリューション、採用の低迷、および限られたイノベーションをもたらしています。
In the last two years, the rapid rise of network threats has exposed the inadequacies of static passwords as the primary mean of authentication on the Internet. At the same time, the current approach that requires an end user to carry an expensive, single-function device that is only used to authenticate to the network is clearly not the right answer. For two-factor authentication to propagate on the Internet, it will have to be embedded in more flexible devices that can work across a wide range of applications.
過去2年間で、ネットワークの脅威の急激な増加は、インターネット上の認証の主な手段としての静的パスワードの不適切さを露呈させました。同時に、ネットワーク認証のみに使用される高価な単機能デバイスをエンドユーザーに携帯させることを要求する現在のアプローチは、明らかに正しい答えではありません。二要素認証がインターネット上で普及するためには、幅広いアプリケーションで動作可能な、より柔軟なデバイスに組み込まれる必要があります。
The ability to embed this base technology while ensuring broad interoperability requires that it be made freely available to the broad technical community of hardware and software developers. Only an open-system approach will ensure that basic two-factor authentication primitives can be built into the next generation of consumer devices such as USB mass storage devices, IP phones, and personal digital assistants.
幅広い相互運用性を確保しながらこの基本技術を組み込むためには、ハードウェアおよびソフトウェア開発者の幅広い技術コミュニティに対して自由に利用可能にする必要があります。オープンシステムアプローチのみが、USBマスストレージデバイス、IP電話、およびPDA（Personal Digital Assistant）などの次世代のコンシューマデバイスに基本的な二要素認証プリミティブを組み込むことを保証します。
One-Time Password is certainly one of the simplest and most popular forms of two-factor authentication for securing network access. For example, in large enterprises, Virtual Private Network access often requires the use of One-Time Password tokens for remote user authentication. One-Time Passwords are often preferred to stronger forms of authentication such as Public-Key Infrastructure (PKI) or biometrics because an air-gap device does not require the installation of any client desktop software on the user machine, therefore allowing them to roam across multiple machines including home computers, kiosks, and personal digital assistants.
ワンタイムパスワードは確かに、ネットワークアクセスを保護するための二要素認証の中で最も単純で人気のある形式の一つです。例えば、大企業では、VPNアクセスにリモートユーザー認証用のワンタイムパスワードトークンの使用が必要な場合がよくあります。ワンタイムパスワードは、公開鍵インフラストラクチャ（PKI）や生体認証などのより強力な認証形式よりも好まれることがよくあります。これは、エアギャップデバイス（ネットワークに接続されていないデバイス）ではユーザーのマシンにクライアントデスクトップソフトウェアをインストールする必要がないため、自宅のコンピュータ、キオスク、PDAなど、複数のマシン間を移動して利用できるからです。
This document proposes a simple One-Time Password algorithm that can be implemented by any hardware manufacturer or software developer to create interoperable authentication devices and software agents. The algorithm is event-based so that it can be embedded in high-volume devices such as Java smart cards, USB dongles, and GSM SIM cards. The presented algorithm is made freely available to the developer community under the terms and conditions of the IETF Intellectual Property Rights [RFC3979].
この文書は、相互運用可能な認証デバイスやソフトウェアエージェントを作成するために、あらゆるハードウェア製造元またはソフトウェア開発者が実装できる単純なワンタイムパスワードアルゴリズムを提案します。このアルゴリズムはイベントベースであり、Javaスマートカード、USBドングル、GSM SIMカードなどの大量生産されるデバイスに組み込むことができます。提示されたアルゴリズムは、IETF知的財産権[RFC3979]の条件の下で開発者コミュニティに自由に利用可能にされています。
The authors of this document are members of the Open AuTHentication initiative [OATH]. The initiative was created in 2004 to facilitate collaboration among strong authentication technology providers.
この文書の著者は、Open AuTHenticationイニシアチブ[OATH]のメンバーです。このイニシアチブは、強力な認証技術プロバイダ間の協力を促進するために2004年に設立されました。
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 presents the main requirements that drove this algorithm design. A lot of emphasis was placed on end-consumer usability as well as the ability for the algorithm to be implemented by low-cost hardware that may provide minimal user interface capabilities. In particular, the ability to embed the algorithm into high-volume SIM and Java cards was a fundamental prerequisite.
このセクションでは、このアルゴリズム設計を推進した主な要件を示します。エンドコンシューマの使いやすさだけでなく、最小限のユーザーインターフェース機能しか提供しない可能性のある低コストのハードウェアでもアルゴリズムを実装できる能力に、多くの重点が置かれました。特に、大量生産されるSIMカードやJavaカードにアルゴリズムを組み込む能力は、基本的な前提条件でした。
R1 - The algorithm MUST be sequence- or counter-based: one of the goals is to have the HOTP algorithm embedded in high-volume devices such as Java smart cards, USB dongles, and GSM SIM cards.
R1 - アルゴリズムはシーケンスベースまたはカウンタベースでなければなりません（MUST）。目標の一つは、Javaスマートカード、USBドングル、GSM SIMカードなどの大量生産されるデバイスにHOTPアルゴリズムを組み込むことです。
R2 - The algorithm SHOULD be economical to implement in hardware by minimizing requirements on battery, number of buttons, computational horsepower, and size of LCD display.
R2 - アルゴリズムは、バッテリー、ボタンの数、計算能力、およびLCDディスプレイのサイズに関する要件を最小限に抑えることにより、ハードウェアでの実装が経済的であるべきです（SHOULD）。
R3 - The algorithm MUST work with tokens that do not support any numeric input, but MAY also be used with more sophisticated devices such as secure PIN-pads.
R3 - アルゴリズムは、数値入力をサポートしないトークンで動作しなければなりません（MUST）が、セキュアPINパッドなどのより高度なデバイスでも使用できます（MAY）。
R4 - The value displayed on the token MUST be easily read and entered by the user: This requires the HOTP value to be of reasonable length.
R4 - トークンに表示される値は、ユーザーが簡単に読み取り、入力できなければなりません（MUST）。これには、HOTP値が適切な長さであることが必要です。
The HOTP value must be at least a 6-digit value. It is also desirable that the HOTP value be 'numeric only' so that it can be easily entered on restricted devices such as phones.
HOTP値は少なくとも6桁の値でなければなりません。また、電話などの入力が制限されたデバイスでも簡単に入力できるように、HOTP値が「数値のみ」であることも望ましいです。
R5 - There MUST be user-friendly mechanisms available to resynchronize the counter. Section 7.4 and Appendix E.4 details the resynchronization mechanism proposed in this document
R5 - カウンタを再同期するために利用可能なユーザーフレンドリーなメカニズムがなければなりません（MUST）。セクション7.4および付録E.4では、この文書で提案されている再同期メカニズムについて詳述しています。
R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.
R6 - アルゴリズムは強力な共有シークレットを使用しなければなりません（MUST）。共有シークレットの長さは少なくとも128ビットでなければなりません（MUST）。この文書では、160ビットの共有シークレット長を推奨します（RECOMMENDED）。
In this section, we introduce the notation and describe the HOTP algorithm basic blocks -- the base function to compute an HMAC-SHA-1 value and the truncation method to extract an HOTP value.
このセクションでは、表記法を紹介し、HOTPアルゴリズムの基本ブロック、すなわちHMAC-SHA-1値を計算するための基本関数と、HOTP値を抽出するための切り捨て（トランケーション）方法について説明します。
A string always means a binary string, meaning a sequence of zeros and ones.
文字列は常にバイナリ文字列を意味し、ゼロと1のシーケンスを意味します。
If s is a string, then |s| denotes its length.
sが文字列の場合、|s|はその長さを示します。
If n is a number, then |n| denotes its absolute value.
nが数値の場合、|n|はその絶対値を示します。
If s is a string, then s[i] denotes its i-th bit. We start numbering the bits at 0, so s = s[0]s[1]...s[n-1] where n = |s| is the length of s.
sが文字列の場合、s[i]はそのi番目のビットを示します。ビットの番号付けは0から始まるため、s = s[0]s[1]...s[n-1]となります。ここで、n = |s| はsの長さです。
Let StToNum (String to Number) denote the function that as input a string s returns the number whose binary representation is s. (For example, StToNum(110) = 6.)
StToNum (String to Number) を、文字列sを入力とし、その2進表現がsである数値を返す関数とします。（例えば、StToNum(110) = 6 です。）
Here is a list of symbols used in this document.
これはこの文書で使用されているシンボルのリストです。
Symbol Represents
-------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).
K shared secret between client and server; each HOTP generator has a different and unique secret K.
K クライアントとサーバー間の共有シークレット。各HOTPジェネレータは、異なる一意のシークレットKを持ちます。
T throttling parameter: the server will refuse connections from a user after T unsuccessful authentication attempts.
T スロットリングパラメータ：サーバーは、T回の認証失敗の試行後、ユーザーからの接続を拒否します。
s resynchronization parameter: the server will attempt to verify a received authenticator across s consecutive counter values.
s 再同期パラメータ：サーバーは、s個の連続したカウンタ値にわたって、受信したオーセンティケータを検証しようとします。
Digit number of digits in an HOTP value; system parameter.
Digit HOTP値の桁数。システムパラメータ。
The HOTP algorithm is based on an increasing counter value and a static symmetric key known only to the token and the validation service. In order to create the HOTP value, we will use the HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2].
HOTPアルゴリズムは、増加するカウンタ値と、トークンおよび検証サービスのみが知る静的対称鍵に基づいています。HOTP値を作成するために、RFC 2104 [BCK2]で定義されているHMAC-SHA-1アルゴリズムを使用します。
As the output of the HMAC-SHA-1 calculation is 160 bits, we must truncate this value to something that can be easily entered by a user.
HMAC-SHA-1計算の出力が160ビットであるため、ユーザーが簡単に入力できるものにこの値を切り捨てる必要があります。
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
Where:
ただし：
- Truncate represents the function that converts an HMAC-SHA-1 value into an HOTP value as defined in Section 5.3.
- Truncateは、セクション5.3で定義されているように、HMAC-SHA-1値をHOTP値に変換する関数を表します。
The Key (K), the Counter (C), and Data values are hashed high-order byte first.
キー（K）、カウンタ（C）、およびデータ値は、上位バイトから順にハッシュされます。
The HOTP values generated by the HOTP generator are treated as big endian.
HOTPジェネレータによって生成されたHOTP値は、ビッグエンディアンとして扱われます。
We can describe the operations in 3 distinct steps:
3つの異なるステップで操作を説明することができます。
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS
is a 20-byte string
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1
The Truncate function performs Step 2 and Step 3, i.e., the dynamic truncation and then the reduction modulo 10^Digit. The purpose of the dynamic offset truncation technique is to extract a 4-byte dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.
Truncate関数は、ステップ2とステップ3、すなわち動的切り捨て（Dynamic Truncation）と、それに続くモジュロ 10^Digit の演算を実行します。動的オフセット切り捨て技術の目的は、160ビット（20バイト）のHMAC-SHA-1の結果から4バイトの動的バイナリコードを抽出することです。
DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P
The reason for masking the most significant bit of P is to avoid confusion about signed vs. unsigned modulo computations. Different processors perform these operations differently, and masking out the signed bit removes all ambiguity.
Pの最上位ビットをマスクする理由は、符号付き対符号なしのモジュロ計算に関する混乱を避けるためです。プロセッサによってこれらの演算の実行方法が異なるため、符号ビットをマスクすることで、すべての曖昧さが排除されます。
Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value.
実装は、最低でも6桁のコード、可能であれば7桁や8桁のコードを抽出しなければなりません（MUST）。セキュリティ要件に応じて、より長いHOTP値を抽出するために、Digit = 7 以上を検討すべきです（SHOULD）。
The following paragraph is an example of using this technique for Digit = 6, i.e., that a 6-digit HOTP value is calculated from the HMAC value.
次の段落は、Digit = 6、すなわちHMAC値から6桁のHOTP値が計算される場合に、この技術を使用する例です。
The following code example describes the extraction of a dynamic binary code given that hmac_result is a byte array with the HMAC-SHA-1 result:
次のコード例は、hmac_resultがHMAC-SHA-1の結果を持つバイト配列であると仮定して、動的バイナリコードの抽出について説明しています。
int offset = hmac_result[19] & 0xf ;
int bin_code = (hmac_result[offset] & 0x7f) << 24
| (hmac_result[offset+1] & 0xff) << 16
| (hmac_result[offset+2] & 0xff) << 8
| (hmac_result[offset+3] & 0xff) ;
SHA-1 HMAC Bytes (Example)
SHA-1 HMACバイト（例）
-------------------------------------------------------------
| Byte Number |
-------------------------------------------------------------
|00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|
-------------------------------------------------------------
| Byte Value |
-------------------------------------------------------------
|1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a|
-------------------------------***********----------------++|
* The last byte (byte 19) has the hex value 0x5a. * The value of the lower 4 bits is 0xa (the offset value). * The offset value is byte 10 (0xa). * The value of the 4 bytes starting at byte 10 is 0x50ef7f19, which is the dynamic binary code DBC1. * The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19 . * HOTP = DBC2 modulo 10^6 = 872921.
* 最後のバイト（バイト19）は16進値0x5aを持ちます。 * 下位4ビットの値は0xa（オフセット値）です。 * オフセット値はバイト10（0xa）です。 * バイト10から始まる4バイトの値は0x50ef7f19であり、これが動的バイナリコードDBC1です。 * DBC1のMSBは0x50なので、DBC2 = DBC1 = 0x50ef7f19 です。 * HOTP = DBC2 modulo 10^6 = 872921。
We treat the dynamic binary code as a 31-bit, unsigned, big-endian integer; the first byte is masked with a 0x7f.
動的バイナリコードを31ビットの符号なしビッグエンディアン整数として扱います。最初のバイトは0x7fでマスクされます。
We then take this number modulo 1,000,000 (10^6) to generate the 6- digit HOTP value 872921 decimal.
その後、この数値のモジュロ 1,000,000 (10^6) を取り、6桁のHOTP値 872921（10進数）を生成します。
The conclusion of the security analysis detailed in the Appendix is that, for all practical purposes, the outputs of the Dynamic Truncation (DT) on distinct counter inputs are uniformly and independently distributed 31-bit strings.
付録に詳述されているセキュリティ分析の結論は、すべての実用的な目的において、異なるカウンタ入力に対する動的切り捨て（DT）の出力は、一様かつ独立して分布する31ビットの文字列であるということです。
The security analysis then details the impact of the conversion from a string to an integer and the final reduction modulo 10^Digit, where Digit is the number of digits in an HOTP value.
セキュリティ分析では、文字列から整数への変換の影響と、最終的なモジュロ 10^Digit による縮小の影響を詳述しています。ここでDigitはHOTP値の桁数です。
The analysis demonstrates that these final steps introduce a negligible bias, which does not impact the security of the HOTP algorithm, in the sense that the best possible attack against the HOTP function is the brute force attack.
分析は、これらの最終ステップが導入するバイアスは無視できる程度であり、HOTP関数に対する最良の攻撃がブルートフォース攻撃であるという意味において、HOTPアルゴリズムのセキュリティに影響を与えないことを示しています。
Assuming an adversary is able to observe numerous protocol exchanges and collect sequences of successful authentication values. This adversary, trying to build a function F to generate HOTP values based on his observations, will not have a significant advantage over a random guess.
敵対者が多数のプロトコル交換を観察し、成功した認証値のシーケンスを収集できると仮定します。観察に基づいてHOTP値を生成する関数Fを構築しようとするこの敵対者は、ランダムな推測以上の大きな優位性を持つことはないでしょう。
The logical conclusion is simply that the best strategy will once again be to perform a brute force attack to enumerate and try all the possible values.
論理的な結論は、最良の戦略はやはり、すべての可能な値を列挙して試行するブルートフォース攻撃を実行することである、という単純なものです。
Considering the security analysis in the Appendix of this document, without loss of generality, we can approximate closely the security of the HOTP algorithm by the following formula:
この文書の付録にあるセキュリティ分析を考慮すると、一般性を失うことなく、HOTPアルゴリズムのセキュリティを次の式で近似できます。
Sec = sv/10^Digit
Where:
- Sec is the probability of success of the adversary;
- s is the look-ahead synchronization window size;
- v is the number of verification attempts;
- Digit is the number of digits in HOTP values.
Obviously, we can play with s, T (the Throttling parameter that would limit the number of attempts by an attacker), and Digit until achieving a certain level of security, still preserving the system usability.
明らかに、システムの使いやすさを維持しつつ、一定レベルのセキュリティを達成するまで、s、T（攻撃者による試行回数を制限するスロットリングパラメータ）、およびDigitを調整することができます。
Any One-Time Password algorithm is only as secure as the application and the authentication protocols that implement it. Therefore, this section discusses the critical security requirements that our choice of algorithm imposes on the authentication protocol and validation software.
どのようなワンタイムパスワードアルゴリズムも、それを実装するアプリケーションおよび認証プロトコルと同程度の安全性しかありません。したがって、このセクションでは、我々が選択したアルゴリズムが認証プロトコルと検証ソフトウェアに課す重要なセキュリティ要件について説明します。
The parameters T and s discussed in this section have a significant impact on the security -- further details in Section 6 elaborate on the relations between these parameters and their impact on the system security.
このセクションで説明するパラメータTとsは、セキュリティに重大な影響を与えます。セクション6では、これらのパラメータ間の関係とシステムセキュリティへの影響についてさらに詳しく説明しています。
It is also important to remark that the HOTP algorithm is not a substitute for encryption and does not provide for the privacy of data transmission. Other mechanisms should be used to defeat attacks aimed at breaking confidentiality and privacy of transactions.
HOTPアルゴリズムは暗号化の代替ではなく、データ伝送のプライバシーを提供しないことに注意することも重要です。トランザクションの機密性とプライバシーを侵害することを目的とした攻撃を防ぐために、他のメカニズムを使用すべきです。
We introduce in this section some requirements for a protocol P implementing HOTP as the authentication method between a prover and a verifier.
このセクションでは、証明者（Prover）と検証者（Verifier）の間の認証方法としてHOTPを実装するプロトコルPに対するいくつかの要件を紹介します。
RP1 - P MUST support two-factor authentication, i.e., the communication and verification of something you know (secret code such as a Password, Pass phrase, PIN code, etc.) and something you have (token). The secret code is known only to the user and usually entered with the One-Time Password value for authentication purpose (two-factor authentication).
RP1 - Pは二要素認証、すなわち、あなたが知っているもの（パスワード、パスフレーズ、PINコードなどの秘密コード）と、あなたが持っているもの（トークン）の通信と検証をサポートしなければなりません（MUST）。秘密コードはユーザーのみに知られており、通常、認証目的でワンタイムパスワード値とともに入力されます（二要素認証）。
RP2 - P SHOULD NOT be vulnerable to brute force attacks. This implies that a throttling/lockout scheme is RECOMMENDED on the validation server side.
RP2 - Pはブルートフォース攻撃に対して脆弱であってはなりません（SHOULD NOT）。これは、検証サーバ側でスロットリング/ロックアウト方式が推奨される（RECOMMENDED）ことを意味します。
RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.
RP3 - Pは、ユーザーのプライバシーを保護し、リプレイ攻撃を避けるために、安全なチャネル上で実装されるべきです（SHOULD）。
The HOTP client (hardware or software token) increments its counter and then calculates the next HOTP value HOTP client. If the value received by the authentication server matches the value calculated by the client, then the HOTP value is validated. In this case, the server increments the counter value by one.
HOTPクライアント（ハードウェアまたはソフトウェアトークン）は、そのカウンタをインクリメントし、次のHOTP値を計算します。認証サーバーが受信した値がクライアントによって計算された値と一致する場合、HOTP値は検証されます。この場合、サーバーはカウンタ値を1つ増やします。
If the value received by the server does not match the value calculated by the client, the server initiate the resynch protocol (look-ahead window) before it requests another pass.
サーバーが受信した値がクライアントによって計算された値と一致しない場合、サーバーは別のパスを要求する前に再同期プロトコル（先読みウィンドウ）を開始します。
If the resynch fails, the server asks then for another authentication pass of the protocol to take place, until the maximum number of authorized attempts is reached.
再同期が失敗した場合、サーバーは、許可された試行の最大数に達するまで、プロトコルの別の認証パスを実行するように求めます。
If and when the maximum number of authorized attempts is reached, the server SHOULD lock out the account and initiate a procedure to inform the user.
許可された試行の最大数に達した場合、サーバーはアカウントをロックアウトし、ユーザーに通知する手順を開始すべきです（SHOULD）。
Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.
HMAC-SHA-1値を短い値に切り捨てると、ブルートフォース攻撃が可能になります。したがって、認証サーバーはブルートフォース攻撃を検出して停止する必要があります。
We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.
ワンタイムパスワード検証の可能な試行の最大数を定義するスロットリングパラメータTを設定することを推奨します（RECOMMEND）。検証サーバーは、失敗した試行を記録するために、HOTPデバイスごとに個別のカウンタを管理します。特にサーバーで使用される再同期方法がウィンドウベースであり、ウィンドウサイズが大きい場合は、Tを大きくしすぎないことを推奨します。Tは、使いやすさに大きな影響を与えない範囲で、できるだけ低く設定すべきです（SHOULD）。
Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.
もう一つの選択肢は、ブルートフォース攻撃を回避するための遅延スキームを実装することです。各失敗試行Aの後、認証サーバーは増加するT*A秒間待機します。例えばT=5の場合、1回目の試行後は5秒待ち、2回目の失敗試行では5*2=10秒待つ、といった具合です。
The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.
遅延またはロックアウトのスキームは、複数の並列推測技術に基づく攻撃を防ぐために、ログインセッションをまたいで適用されなければなりません（MUST）。
Although the server's counter value is only incremented after a successful HOTP authentication, the counter on the token is incremented every time a new HOTP is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization.
サーバーのカウンタ値はHOTP認証が成功した後にのみインクリメントされますが、トークンのカウンタはユーザーが新しいHOTPを要求するたびにインクリメントされます。このため、サーバーとトークンのカウンタ値の同期が外れる可能性があります。
We RECOMMEND setting a look-ahead parameter s on the server, which defines the size of the look-ahead window. In a nutshell, the server can recalculate the next s HOTP-server values, and check them against the received HOTP client.
先読みウィンドウのサイズを定義する先読みパラメータsをサーバーに設定することを推奨します（RECOMMEND）。簡単に言えば、サーバーは次のs個のHOTP-server値を再計算し、受信したHOTP-client値と照合することができます。
Synchronization of counters in this scenario simply requires the server to calculate the next HOTP values and determine if there is a match. Optionally, the system MAY require the user to send a sequence of (say, 2, 3) HOTP values for resynchronization purpose, since forging a sequence of consecutive HOTP values is even more difficult than guessing a single HOTP value.
このシナリオでのカウンタの同期は、サーバーが次のHOTP値を計算し、一致するかどうかを判断するだけで済みます。オプションとして、システムは再同期のためにユーザーに一連の（例えば2つか3つの）HOTP値を送信するよう要求してもかまいません（MAY）。連続したHOTP値のシーケンスを偽造することは、単一のHOTP値を推測するよりもさらに困難だからです。
The upper bound set by the parameter s ensures the server does not go on checking HOTP values forever (causing a denial-of-service attack) and also restricts the space of possible solutions for an attacker trying to manufacture HOTP values. s SHOULD be set as low as possible, while still ensuring that usability is not impacted.
パラメータsによって設定される上限は、サーバーがHOTP値を永遠にチェックし続けない（サービス拒否攻撃を引き起こす）ことを保証し、またHOTP値を生成しようとする攻撃者の可能な解空間を制限します。sは、使いやすさに影響を与えない範囲で、できるだけ低く設定すべきです（SHOULD）。
The operations dealing with the shared secrets used to generate and verify OTP values must be performed securely, in order to mitigate risks of any leakage of sensitive information. We describe in this section different modes of operations and techniques to perform these different operations with respect to the state of the art in data security.
OTP値を生成および検証するために使用される共有シークレットを扱う操作は、機密情報の漏洩リスクを軽減するために、安全に実行されなければなりません。このセクションでは、データセキュリティの最新技術に関して、これらの異なる操作を実行するためのさまざまな運用モードと技術について説明します。
We can consider two different avenues for generating and storing (securely) shared secrets in the Validation system:
検証システムにおいて共有シークレットを（安全に）生成および保存するための、2つの異なる手段を検討できます。
* Deterministic Generation: secrets are derived from a master seed, both at provisioning and verification stages and generated on-the-fly whenever it is required. * Random Generation: secrets are generated randomly at provisioning stage and must be stored immediately and kept secure during their life cycle.
* 決定論的生成：シークレットは、プロビジョニングおよび検証段階の両方でマスターシードから導出され、必要なときにいつでもオンザフライで生成されます。 * ランダム生成：シークレットはプロビジョニング段階でランダムに生成され、直ちに保存され、そのライフサイクルの間安全に保持されなければなりません。
Deterministic Generation
------------------------
A possible strategy is to derive the shared secrets from a master secret. The master secret will be stored at the server only. A tamper-resistant device MUST be used to store the master key and derive the shared secrets from the master key and some public information. The main benefit would be to avoid the exposure of the shared secrets at any time and also avoid specific requirements on storage, since the shared secrets could be generated on-demand when needed at provisioning and validation time.
可能な戦略の一つは、マスターシークレットから共有シークレットを導出することです。マスターシークレットはサーバーにのみ保存されます。マスターキーを保存し、マスターキーといくつかの公開情報から共有シークレットを導出するには、耐タンパー性のあるデバイスを使用しなければなりません（MUST）。主な利点は、共有シークレットがいかなる時点でも露出するのを避けること、およびプロビジョニングや検証時に必要に応じて共有シークレットをオンデマンドで生成できるため、ストレージに関する特定の要件を回避できることです。
We distinguish two different cases:
2つの異なるケースを区別します。
- A single master key MK is used to derive the shared secrets; each HOTP device has a different secret, K_i = SHA-1 (MK,i) where i stands for a public piece of information that identifies uniquely the HOTP device such as a serial number, a token ID, etc. Obviously, this is in the context of an application or service -- different application or service providers will have different secrets and settings. - Several master keys MK_i are used and each HOTP device stores a set of different derived secrets, {K_i,j = SHA-1(MK_i,j)} where j stands for a public piece of information identifying the device. The idea would be to store ONLY the active master key at the validation server, in the Hardware Security Module (HSM), and keep in a safe place, using secret sharing methods such as [Shamir] for instance. In this case, if a master secret MK_i is compromised, then it is possible to switch to another secret without replacing all the devices.
- 単一のマスターキーMKを使用して共有シークレットを導出する場合：各HOTPデバイスは異なるシークレット K_i = SHA-1 (MK,i) を持ちます。ここでiは、シリアル番号やトークンIDなど、HOTPデバイスを一意に識別する公開情報です。明らかに、これはアプリケーションまたはサービスのコンテキスト内にあります。異なるアプリケーションまたはサービスプロバイダーは、異なるシークレットと設定を持ちます。 - 複数のマスターキー MK_i が使用され、各HOTPデバイスが一連の異なる導出シークレット {K_i,j = SHA-1(MK_i,j)} を保存する場合：ここでjはデバイスを識別する公開情報です。このアイデアは、検証サーバーのアクティブなマスターキーのみをハードウェアセキュリティモジュール（HSM）に保存し、例えば[Shamir]のような秘密分散法を使用して安全な場所に保管することです。この場合、マスターシークレット MK_i が侵害されても、すべてのデバイスを交換することなく別のシークレットに切り替えることが可能です。
The drawback in the deterministic case is that the exposure of the master secret would obviously enable an attacker to rebuild any shared secret based on correct public information. The revocation of all secrets would be required, or switching to a new set of secrets in the case of multiple master keys.
決定論的な場合の欠点は、マスターシークレットが露出すると、攻撃者が正しい公開情報に基づいて任意の共有シークレットを再構築できてしまうことです。すべてのシークレットの失効が必要になるか、複数のマスターキーの場合は新しいシークレットセットへの切り替えが必要になります。
On the other hand, the device used to store the master key(s) and generate the shared secrets MUST be tamper resistant. Furthermore, the HSM will not be exposed outside the security perimeter of the validation system, therefore reducing the risk of leakage.
一方で、マスターキーを保存し共有シークレットを生成するために使用されるデバイスは、耐タンパー性がなければなりません（MUST）。さらに、HSMは検証システムのセキュリティ境界の外側に露出しないため、漏洩のリスクが軽減されます。
Random Generation
-----------------
The shared secrets are randomly generated. We RECOMMEND following the recommendations in [RFC4086] and selecting a good and secure random source for generating these secrets. A (true) random generator requires a naturally occurring source of randomness. Practically, there are two possible avenues to consider for the generation of the shared secrets:
共有シークレットはランダムに生成されます。[RFC4086]の推奨事項に従い、これらのシークレットを生成するために、良好で安全なランダムソースを選択することを推奨します（RECOMMEND）。（真の）ランダムジェネレータには、自然に発生するランダム性の源が必要です。実際には、共有シークレットの生成について考慮すべき2つの可能性があります。
* Hardware-based generators: they exploit the randomness that occurs in physical phenomena. A nice implementation can be based on oscillators and built in such ways that active attacks are more difficult to perform.
* ハードウェアベースのジェネレータ：物理現象で発生するランダム性を利用します。優れた実装は発振器に基づいており、能動的な攻撃の実行がより困難になるように構築できます。
* Software-based generators: designing a good software random generator is not an easy task. A simple, but efficient, implementation should be based on various sources and apply to the sampled sequence a one-way function such as SHA-1.
* ソフトウェアベースのジェネレータ：優れたソフトウェアランダムジェネレータの設計は容易な作業ではありません。単純ですが効率的な実装は、さまざまなソースに基づき、サンプリングされたシーケンスにSHA-1などの一方向関数を適用すべきです。
We RECOMMEND selecting proven products, being hardware or software generators, for the computation of shared secrets.
共有シークレットの計算には、ハードウェアまたはソフトウェアジェネレータであるかに関わらず、実績のある製品を選択することを推奨します（RECOMMEND）。
We also RECOMMEND storing the shared secrets securely, and more specifically encrypting the shared secrets when stored using tamper-resistant hardware encryption and exposing them only when required: for example, the shared secret is decrypted when needed to verify an HOTP value, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The data store holding the shared secrets MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database.
また、共有シークレットを安全に保存すること、より具体的には、耐タンパー性のあるハードウェア暗号化を使用して保存時に共有シークレットを暗号化し、必要な場合にのみ露出させることを推奨します（RECOMMEND）。例えば、共有シークレットはHOTP値を検証するために必要なときに復号化され、RAM内での露出を短時間に制限するために直ちに再暗号化されます。共有シークレットを保持するデータストアは、検証システムおよびシークレットデータベースへの直接攻撃を可能な限り回避するために、安全な領域になければなりません（MUST）。
Particularly, access to the shared secrets should be limited to programs and processes required by the validation system only. We will not elaborate on the different security mechanisms to put in place, but obviously, the protection of shared secrets is of the uttermost importance.
特に、共有シークレットへのアクセスは、検証システムに必要なプログラムおよびプロセスのみに制限されるべきです。導入すべきさまざまなセキュリティメカニズムについては詳しく述べませんが、明らかに共有シークレットの保護は最重要事項です。
It may be desirable to include additional authentication factors in the shared secret K. These additional factors can consist of any data known at the token but not easily obtained by others. Examples of such data include:
共有シークレットKに追加の認証要素を含めることが望ましい場合があります。これらの追加要素は、トークンでは既知であるが他者には容易に入手できない任意のデータで構成できます。そのようなデータの例は次のとおりです。
* PIN or Password obtained as user input at the token * Phone number * Any unique identifier programmatically available at the token
* トークンでのユーザー入力として取得されたPINまたはパスワード * 電話番号 * トークンでプログラム的に利用可能な任意の一意の識別子
In this scenario, the composite shared secret K is constructed during the provisioning process from a random seed value combined with one or more additional authentication factors. The server could either build on-demand or store composite secrets -- in any case, depending on implementation choice, the token only stores the seed value. When the token performs the HOTP calculation, it computes K from the seed value and the locally derived or input values of the other authentication factors.
このシナリオでは、複合共有シークレットKは、プロビジョニングプロセス中に、ランダムなシード値と1つ以上の追加認証要素を組み合わせて構築されます。サーバーは、オンデマンドで構築するか、複合シークレットを保存することができます。いずれの場合も、実装の選択に応じて、トークンはシード値のみを保存します。トークンがHOTP計算を実行するとき、シード値と、他の認証要素のローカルで導出された値または入力値からKを計算します。
The use of composite shared secrets can strengthen HOTP-based authentication systems through the inclusion of additional authentication factors at the token. To the extent that the token is a trusted device, this approach has the further benefit of not requiring exposure of the authentication factors (such as the user input PIN) to other devices.
複合共有シークレットの使用は、トークンに追加の認証要素を含めることで、HOTPベースの認証システムを強化できます。トークンが信頼できるデバイスである限り、このアプローチには、認証要素（ユーザー入力PINなど）を他のデバイスに露出させる必要がないというさらなる利点があります。
Interestingly enough, the HOTP client could also be used to authenticate the validation server, claiming that it is a genuine entity knowing the shared secret.
興味深いことに、HOTPクライアントは検証サーバーを認証するために使用することもでき、共有シークレットを知っている正当なエンティティであることを主張できます。
Since the HOTP client and the server are synchronized and share the
same secret (or a method to recompute it), a simple 3-pass protocol
could be put in place:
1- The end user enter the TokenID and a first OTP value OTP1;
2- The server checks OTP1 and if correct, sends back OTP2;
3- The end user checks OTP2 using his HOTP device and if correct,
uses the web site.
Obviously, as indicated previously, all the OTP communications have to take place over a secure channel, e.g., SSL/TLS, IPsec connections.
明らかに、前述のように、すべてのOTP通信は、安全なチャネル（例：SSL/TLS、IPsec接続）上で行われなければなりません。
This document describes HOTP, a HMAC-based One-Time Password algorithm. It also recommends the preferred implementation and related modes of operations for deploying the algorithm.
この文書では、HMACベースのワンタイムパスワードアルゴリズムであるHOTPについて説明します。また、アルゴリズムを展開するための推奨される実装および関連する運用モードについても推奨しています。
The document also exhibits elements of security and demonstrates that the HOTP algorithm is practical and sound, the best possible attack being a brute force attack that can be prevented by careful implementation of countermeasures in the validation server.
この文書はまた、セキュリティの要素を示し、HOTPアルゴリズムが実用的で健全であることを示しています。最良の攻撃はブルートフォース攻撃ですが、これは検証サーバーに対策を慎重に実装することで防ぐことができます。
Eventually, several enhancements have been proposed, in order to improve security if needed for specific applications.
最終的には、特定のアプリケーションに必要な場合はセキュリティを向上させるために、いくつかの機能強化が提案されています。
The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren Hart, and Nico Popp for their help during the conception and redaction of this document.
著者らは、この文書の構想および編集の際にご協力いただいたSiddharth Bajaj、Alex Deacon、Loren Hart、およびNico Poppに感謝します。
The authors of this document would like to emphasize the role of three persons who have made a key contribution to this document:
この文書の著者は、この文書に重要な貢献をした3名の役割を強調したいと思います。
- Laszlo Elteto is system architect with SafeNet, Inc.
- Laszlo EltetoはSafeNet, Inc.のシステムアーキテクトです。
- Ernesto Frutos is director of Engineering with Authenex, Inc.
- Ernesto FrutosはAuthenex, Inc.のエンジニアリングディレクターです。
- Fred McClain is Founder and CTO with Boojum Mobile, Inc.
- Fred McClainはBoojum Mobile, Inc.の創設者兼CTOです。
Without their advice and valuable inputs, this document would not be the same.
彼らのアドバイスや貴重な意見がなければ、この文書は同じものにはならなかったでしょう。
[BCK1] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash Functions and Message Authentication", Proceedings of Crypto'96, LNCS Vol. 1109, pp. 1-15.
[BCK1] M. Bellare、R. CanettiおよびH. Krawczyk、「キー付きハッシュ関数およびメッセージ認証」、Crypto'96、LNCS Vol. 1109、pp. 1-15。
[BCK2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[BCK2] Krawczyk、H.、Bellare、M.、およびR. Canetti、「HMAC：メッセージ認証のための鍵付きハッシング」、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., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[OATH] Initiative for Open AuTHentication http://www.openauthentication.org
[OATH] Initiative for Open AuTHentication http://www.openauthentication.org
[PrOo] B. Preneel and P. van Oorschot, "MD-x MAC and building fast MACs from hash functions", Advances in Cryptology CRYPTO '95, Lecture Notes in Computer Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995.
[PrOo] B. Preneel and P. van Oorschot, "MD-x MAC and building fast MACs from hash functions", Advances in Cryptology CRYPTO '95, Lecture Notes in Computer Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995.
[Crack] Crack in SHA-1 code 'stuns' security gurus
http://www.eetimes.com/showArticle.jhtml?
articleID=60402150
[Sha1] Bruce Schneier. SHA-1 broken. February 15, 2005.
http://www.schneier.com/blog/archives/2005/02/
sha1_broken.html
[Res] Researchers: Digital encryption standard flawed
http://news.com.com/
Researchers+Digital+encryption+standard+flawed/
2100-1002-5579881.html?part=dht&tag=ntop&tag=nl.e703
[Shamir] How to Share a Secret, by Adi Shamir. In Communications of the ACM, Vol. 22, No. 11, pp. 612-613, November, 1979.
[Shamir] How to Share a Secret, by Adi Shamir. In Communications of the ACM, Vol. 22, No. 11, pp. 612-613, November, 1979.
The security analysis of the HOTP algorithm is summarized in this section. We first detail the best attack strategies, and then elaborate on the security under various assumptions and the impact of the truncation and make some recommendations regarding the number of digits.
このセクションでは、HOTPアルゴリズムのセキュリティ分析を要約します。まず最良の攻撃戦略を詳述し、次に様々な仮定の下でのセキュリティと切り捨ての影響について詳しく説明し、桁数に関するいくつかの推奨事項を提示します。
We focus this analysis on the case where Digit = 6, i.e., an HOTP function that produces 6-digit values, which is the bare minimum recommended in this document.
我々は、Digit = 6、すなわち6桁の値を生成するHOTP関数の場合に焦点を当てて分析を行います。これは、この文書で推奨される最低限のものです。
We denote by {0,1}^l the set of all strings of length l.
{0,1}^l で、長さ l のすべての文字列の集合を表します。
Let Z_{n} = {0,.., n - 1}.
Let IntDiv(a,b) denote the integer division algorithm that takes
input integers a, b where a >= b >= 1 and returns integers (q,r)
the quotient and remainder, respectively, of the division of a by b. (Thus, a = bq + r and 0 <= r < b.)
それぞれ、a を b で割った商と剰余。（したがって、a = bq + r かつ 0 <= r < b。）
Let H: {0,1}^k x {0,1}^c --> {0,1}^n be the base function that takes a k-bit key K and c-bit counter C and returns an n-bit output H(K,C). (In the case of HOTP, H is HMAC-SHA-1; we use this formal definition for generalizing our proof of security.)
H: {0,1}^k x {0,1}^c --> {0,1}^n を、kビットの鍵KとcビットのカウンタCを取り、nビットの出力H(K,C)を返す基本関数とします。（HOTPの場合、HはHMAC-SHA-1です。この形式的な定義は、セキュリティの証明を一般化するために使用します。）
We now define an idealized counterpart of the HOTP algorithm. In this algorithm, the role of H is played by a random function that forms the key.
ここで、HOTPアルゴリズムの理想化された対応物を定義します。このアルゴリズムでは、Hの役割は、鍵を構成するランダム関数によって果たされます。
To be more precise, let Maps(c,n) denote the set of all functions
mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key
space Maps(c,n), so that a "key" for such an algorithm is a function
h from {0,1}^c to {0,1}^n. We imagine this key (function) to be
drawn at random. It is not feasible to implement this idealized
algorithm, since the key, being a function from {0,1}^c to {0,1}^n,
is way too large to even store. So why consider it?
Our security analysis will show that as long as H satisfies a certain well-accepted assumption, the security of the actual and idealized algorithms is for all practical purposes the same. The task that really faces us, then, is to assess the security of the idealized algorithm.
Hがある種の広く受け入れられている仮定を満たす限り、実際のアルゴリズムと理想化されたアルゴリズムのセキュリティは、すべての実用的な目的において同じであることを、我々のセキュリティ分析は示します。したがって、我々が直面する真の課題は、理想化されたアルゴリズムのセキュリティを評価することです。
In analyzing the idealized algorithm, we are concentrating on assessing the quality of the design of the algorithm itself, independently of HMAC-SHA-1. This is in fact the important issue.
理想化されたアルゴリズムを分析する際には、HMAC-SHA-1とは無関係に、アルゴリズム自体の設計の品質を評価することに集中しています。これは実際には重要な問題です。
The model exhibits the type of threats or attacks that are being considered and enables one to assess the security of HOTP and HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the purpose of this security analysis.
このモデルは、検討されている脅威や攻撃の種類を示し、HOTPとHOTP-IDEALのセキュリティを評価することができます。このセキュリティ分析の目的のために、HOTPまたはHOTP-IDEALのいずれかをALGと表記します。
The scenario we are considering is that a user and server share a key K for ALG. Both maintain a counter C, initially zero, and the user authenticates itself by sending ALG(K,C) to the server. The latter accepts if this value is correct.
私たちが検討しているシナリオは、ユーザーとサーバーがALGのためのキーKを共有することです。カウンタC、最初はゼロを維持し、ユーザはALG（k、c）をサーバに送信することによってそれ自体を認証する。この値が正しい場合は後者が受け入れます。
In order to protect against accidental increment of the user counter, the server, upon receiving a value z, will accept as long as z equals ALG(K,i) for some i in the range C,...,C + s-1, where s is the resynchronization parameter and C is the server counter. If it accepts with some value of i, it then increments its counter to i+1. If it does not accept, it does not change its counter value.
ユーザーカウンタの偶発的な増加を防ぐために、サーバーは値zを受信すると、C、...、C + s-1の範囲内のあ るiについて、zがALG(K,i)と等しい限り受け入れます。ここで、sは再同期パラメータ、Cはサーバーカウンタです。ある値iで受け入れた場合、サーバーはカウンタをi+1にインクリメントします。受け入れない場合、カウンタ値は変更しません。
The model we specify captures what an adversary can do and what it needs to achieve in order to "win". First, the adversary is assumed to be able to eavesdrop, meaning, to see the authenticator transmitted by the user. Second, the adversary wins if it can get the server to accept an authenticator relative to a counter value for which the user has never transmitted an authenticator.
モデルは、敵対者ができることと、それが「勝利」するために達成する必要があることを捉えます。第一に、敵対者は盗聴が可能である、つまりユーザーが送信したオーセンティケータを見ることができると仮定されます。第二に、ユーザーがオーセンティケータを送信したことがないカウンタ値に関連するオーセンティケータをサーバーに受け入れさせることができれば、敵対者の勝利となります。
The formal adversary, which we denote by B, starts out knowing which algorithm ALG is being used, knowing the system design, and knowing all system parameters. The one and only thing it is not given a priori is the key K shared between the user and the server.
Bで表す形式的な敵対者は、どのアルゴリズムALGが使用されているか、システム設計、およびすべてのシステムパラメータを知っている状態で開始します。唯一、先験的に与えられていないのは、ユーザーとサーバー間で共有されている鍵Kです。
The model gives B full control of the scheduling of events. It has access to an authenticator oracle representing the user. By calling this oracle, the adversary can ask the user to authenticate itself and get back the authenticator in return. It can call this oracle as often as it wants and when it wants, using the authenticators it accumulates to perhaps "learn" how to make authenticators itself. At any time, it may also call a verification oracle, supplying the latter with a candidate authenticator of its choice. It wins if the server accepts this accumulator.
モデルはBにイベントのスケジューリングに対する完全な制御を与えます。Bはユーザーを表すオーセンティケータ・オラクルにアクセスできます。このオラクルを呼び出すことで、敵対者はユーザーに認証を求め、その返答としてオーセンティケータを取得できます。敵対者は望むときに何度でもこのオラクルを呼び出すことができ、蓄積したオーセンティケータを使用して、おそらく自分自身でオーセンティケータを作成する方法を「学習」します。いつでも、検証オラクルを呼び出し、自分が選んだ候補オーセンティケータを提供することができます。サーバーがこのオーセンティケータを受け入れれば、敵対者の勝利です。
Consider the following game involving an adversary B that is attempting to compromise the security of an authentication algorithm ALG: K x {0,1}^c --> R.
認証アルゴリズムalgのセキュリティを危うくしようとしている敵対的Bを含む次のゲームを考慮してください.K X {0,1} ^ C - R.
Initializations - A key K is selected at random from K, a counter C is initialized to 0, and the Boolean value win is set to false.
初期化 - 鍵KがKからランダムに選択され、カウンタCが0に初期化され、ブール値Winがfalseに設定されます。
Game execution - Adversary B is provided with the two following oracles:
ゲームの実行 - 敵対者Bには、次の2つのオラクルが提供されます。
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
Oracle VerO(A)
--------------
i = C
While (i <= C + s - 1 and Win == FALSE) do
If A == ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1
Return Win to B
AuthO() is the authenticator oracle and VerO(A) is the verification oracle.
AuthO()はオーセンティケータ・オラクルで、VerO(A)は検証オラクルです。
Upon execution, B queries the two oracles at will. Let Adv(B) be the probability that win gets set to true in the above game. This is the probability that the adversary successfully impersonates the user.
実行時、Bは2つのオラクルを自由にクエリします。Adv(B)を、上記のゲームでwinがtrueに設定される確率とします。これは、敵対者がユーザーになりすますことに成功する確率です。
Our goal is to assess how large this value can be as a function of the number v of verification queries made by B, the number a of authenticator oracle queries made by B, and the running time t of B. This will tell us how to set the throttle, which effectively upper bounds v.
我々の目標は、Bが行う検証クエリの数v、Bが行うオーセンティケータ・オラクルクエリの数a、およびBの実行時間tの関数として、この値がどれくらい大きくなり得るかを評価することです。これにより、スロットルの設定方法がわかります。スロットルは事実上vの上限となります。
This section summarizes the security analysis of HOTP-IDEAL, starting with the impact of the conversion modulo 10^Digit and then focusing on the different possible attacks.
このセクションでは、モジュロ 10^Digit 変換の影響から始め、次に様々な可能な攻撃に焦点を当てて、HOTP-IDEALのセキュリティ分析を要約します。
The dynamic offset truncation of a random n-bit string yields a random 31-bit string. What happens to the distribution when it is taken modulo m = 10^Digit, as done in HOTP? The following lemma estimates the biases in the outputs in this case.
ランダムなnビット列の動的オフセット切り捨ては、ランダムな31ビット文字列を生成します。HOTPで行われているように、m = 10^Digit のモジュロを取ると、分布はどうなるでしょうか？次の補題（Lemma）は、この場合の出力のバイアスを推定します。
Lemma 1
-------
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Then for any z in Z_{m}
Z_{m} 内の任意の z について
P_{N,m}(z) = (q + 1) / N if 0 <= z < r
q / N if r <= z < m
Proof of Lemma 1
----------------
Let the random variable X be uniformly distributed over Z_{N}. Then:
P_{N,m}(z) = Pr [X mod m = z]
= Pr [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
0 if N - mq <= z <= m
= q/N +
r/N * 1 / r if 0 <= z < N - mq
0 if r <= z <= m
Simplifying yields the claimed equation.
単純化すると、主張された式が得られます。
Let N = 2^31, d = 6, and m = 10^d. If x is chosen at random from Z_{N} (meaning, is a random 31-bit string), then reducing it to a 6- digit number by taking x mod m does not yield a random 6-digit number.
N = 2^31、d = 6、m = 10^d とします。x が Z_{N} からランダムに選ばれた場合（つまり、ランダムな31ビット文字列である場合）、x mod m を取って6桁の数値に縮小しても、ランダムな6桁の数値は生成されません。
Rather, x mod m is distributed as shown in the following table:
むしろ、X MOD Mは次の表に示すように分散されています。
Values Probability that each appears as output
----------------------------------------------------------------
0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6
483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6
If X is uniformly distributed over Z_{2^31} (meaning, is a random 31-bit string), then the above shows the probabilities for different outputs of X mod 10^6. The first set of values appears with probability slightly greater than 10^-6, the rest with probability slightly less, meaning that the distribution is slightly non-uniform.
X が Z_{2^31} 上で一様に分布している場合（つまり、ランダムな31ビット文字列である場合）、上記は X mod 10^6 の異なる出力に対する確率を示しています。最初の値のセットは 10^-6 よりわずかに大きい確率で現れ、残りはわずかに小さい確率で現れます。つまり、分布はわずかに不均一です。
However, as the table above indicates, the bias is small, and as we will see later, negligible: the probabilities are very close to 10^-6.
しかしながら、上の表が示すようにバイアスは小さく、後で見るように無視できる程度です。確率は 10^-6 に非常に近いです。
If the authenticator consisted of d random digits, then a brute force attack using v verification attempts would succeed with probability sv/10^Digit.
オーセンティケータがd個のランダムな数字で構成されている場合、v回の検証試行を使用したブルートフォース攻撃は確率 sv/10^Digit で成功します。
However, an adversary can exploit the bias in the outputs of HOTP-IDEAL, predicted by Lemma 1, to mount a slightly better attack.
しかしながら、敵対者は、Lemma 1によって予測されたHOTP-IDEALの出力におけるバイアスを利用して、わずかに優れた攻撃を仕掛けることができます。
Namely, it makes authentication attempts with authenticators that are the most likely values, meaning the ones in the range 0,...,r - 1, where (q,r) = IntDiv(2^31,10^Digit).
すなわち、最も可能性の高い値であるオーセンティケータを使用して認証を試みます。これは、0,...,r - 1 の範囲内の値です。ここで (q,r) = IntDiv(2^31, 10^Digit) です。
The following specifies an adversary in our model of security that mounts the attack. It estimates the success probability as a function of the number of verification queries.
以下は、攻撃をマウントするセキュリティのモデルの敵対者を指定しています。それは、検証クエリの数の関数としての成功確率を推定します。
For simplicity, we assume that the number of verification queries is at most r. With N = 2^31 and m = 10^6, we have r = 483,648, and the throttle value is certainly less than this, so this assumption is not much of a restriction.
簡単にするために、検証クエリの数は最大でも r であると仮定します。N = 2^31 および m = 10^6 の場合、r = 483,648 となり、スロットル値は確実にこれより小さいため、この仮定はそれほど大きな制限にはなりません。
Proposition 1
-------------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume s <= m. The brute-force-attack adversary B-bf attacks HOTP using v <= r verification oracle queries. This adversary makes no authenticator oracle queries, and succeeds with probability
m = 10^Digit < 2^31 とし、(q,r) = IntDiv(2^31,m) とする。s <= m とする。ブルートフォース攻撃の攻撃者 B-bf は、v <= r の検証オラクルクエリを用いて HOTP を攻撃する。この攻撃者は認証子オラクルクエリを一切行わず、確率
Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s
which is roughly equal to
これはおよそ以下と等しいです
sv * (q+1)/2^31
With m = 10^6 we get q = 2,147. In that case, the brute force attack using v verification attempts succeeds with probability
m = 10^6 の場合、q = 2,147 となります。その場合、v回の検証試行を使用したブルートフォース攻撃は以下の確率で成功します
Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6
As this equation shows, the resynchronization parameter s has a significant impact in that the adversary's success probability is proportional to s. This means that s cannot be made too large without compromising security.
この式が示すように、再同期パラメータ s は、敵対者の成功確率が s に比例するという点で大きな影響を及ぼします。これは、セキュリティを犠牲にすることなく s を大きくしすぎることはできないことを意味します。
A.4.3. Brute force attacks are the best possible attacks.
A.4.3. ブルートフォース攻撃は可能な限り最良の攻撃です。
A central question is whether there are attacks any better than the brute force one. In particular, the brute force attack did not attempt to collect authenticators sent by the user and try to cryptanalyze them in an attempt to learn how to better construct authenticators. Would doing this help? Is there some way to "learn" how to build authenticators that result in a higher success rate than given by the brute-force attack?
中心的な問題は、ブルートフォース攻撃よりも優れた攻撃が存在するかどうかです。特に、ブルートフォース攻撃は、ユーザーが送信したオーセンティケータを収集し、それらを暗号解読して、より適切にオーセンティケータを構築する方法を学ぼうとはしませんでした。これを行うことは役に立つでしょうか？ブルートフォース攻撃で得られるよりも高い成功率をもたらすオーセンティケータの構築方法を「学習」する何らかの方法はあるでしょうか？
The following says the answer to these questions is no. No matter what strategy the adversary uses, and even if it sees, and tries to exploit, the authenticators from authentication attempts of the user, its success probability will not be above that of the brute force attack -- this is true as long as the number of authentications it observes is not incredibly large. This is valuable information regarding the security of the scheme.
以下は、これらの質問に対する答えがノーであることを示しています。敵対者がどのような戦略を用いても、たとえユーザーの認証試行からのオーセンティケータを見て、それを悪用しようとしたとしても、その成功確率はブルートフォース攻撃の成功確率を上回ることはありません。これは、敵対者が観察する認証の数が信じられないほど大きくない限り真実です。これは、このスキームのセキュリティに関する貴重な情報です。
Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let
(q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL
using v verification oracle queries and a <= 2^c - s authenticator
oracle queries. Then
Adv(B) < = sv * (q+1)/ 2^31
Note: This result is conditional on the adversary not seeing more than 2^c - s authentications performed by the user, which is hardly restrictive as long as c is large enough.
注：この結果は、敵対者がユーザーによって実行された 2^c - s 回を超える認証を見ないという条件付きですが、c が十分に大きい限り、これはほとんど制限になりません。
With m = 10^6, we get q = 2,147. In that case, Proposition 2 says that any adversary B attacking HOTP-IDEAL and making v verification attempts succeeds with probability at most
m = 10^6 の場合、q = 2,147 となります。その場合、命題2は、HOTP-IDEALを攻撃し、v回の検証試行を行う敵対者Bは、最大でも以下の確率で成功すると述べています。
Equation 1
----------
sv * 2148/2^31 roughly = sv * 1.00024045/10^6
Meaning, B's success rate is not more than that achieved by the brute force attack.
つまり、Bの成功率は、ブルートフォース攻撃によって達成されたものを超えることはありません。
We have analyzed, in the previous sections, the security of the idealized counterparts HOTP-IDEAL of the actual authentication algorithm HOTP. We now show that, under appropriate and well-believed assumption on H, the security of the actual algorithms is essentially the same as that of its idealized counterpart.
前のセクションでは、実際の認証アルゴリズムHOTPの理想化された対応物であるHOTP-IDEALのセキュリティを分析しました。ここでは、Hに関する適切かつ広く信じられている仮定の下で、実際のアルゴリズムのセキュリティは、その理想化された対応物のセキュリティと本質的に同じであることを示します。
The assumption in question is that H is a secure pseudorandom function, or PRF, meaning that its input-output values are indistinguishable from those of a random function in practice.
問題の仮定は、Hが安全な疑似乱数関数、またはPRFであり、その入力出力値は実際にはランダム関数のものと区別がつかないことです。
Consider an adversary A that is given an oracle for a function f: {0,1}^c --> {0, 1}^n and eventually outputs a bit. We denote Adv(A) as the prf-advantage of A, which represents how well the adversary does at distinguishing the case where its oracle is H(K,.) from the case where its oracle is a random function of {0,1}^c to {0,1}^n.
関数 f: {0,1}^c --> {0, 1}^n のオラクルを与えられ、最終的にビットを出力する敵対者Aを考えます。Adv(A) を A の prf-アドバンテージと表記します。これは、オラクルが H(K,.) である場合と、オラクルが {0,1}^c から {0,1}^n へのランダム関数である場合を、敵対者がどれだけうまく区別できるかを表します。
One possible attack is based on exhaustive search for the key K. If A runs for t steps and T denotes the time to perform one computation of H, its prf-advantage from this attack turns out to be (t/T)2^-k. Another possible attack is a birthday one [PrOo], whereby A can attain advantage p^2/2^n in p oracle queries and running time about pT.
考えられる攻撃の1つは、鍵Kの徹底的な探索（全探索）に基づいています。Aがtステップ実行し、TがHの1回の計算を実行する時間を表す場合、この攻撃によるprf-アドバンテージは (t/T)2^-k となります。もう1つの可能な攻撃は誕生日攻撃 [PrOo] であり、Aはp回のオラクルクエリと約pTの実行時間で p^2/2^n のアドバンテージを得ることができます。
Our assumption is that these are the best possible attacks. This translates into the following.
私たちの仮定は、これらが最高の可能な攻撃であることです。これは次のところに変換されます。
Assumption 1
------------
Let T denotes the time to perform one computation of H. Then if A is any adversary with running time at most t and making at most p oracle queries,
TをHの1回の計算を実行する時間とします。Aが最大tの実行時間を持ち、最大p回のオラクルクエリを行う任意の敵対者である場合、
Adv(A) <= (t/T)/2^k + p^2/2^n
In practice, this assumption means that H is very secure as PRF. For example, given that k = n = 160, an attacker with running time 2^60 and making 2^40 oracle queries has advantage at most (about) 2^-80.
実際には、この仮定は、HがPRFとして非常に安全であることを意味します。たとえば、k = n = 160であることを考えると、実行時間 2^60 で 2^40 回のオラクルクエリを行う攻撃者は、最大（約）2^-80 のアドバンテージを持ちます。
Theorem 1
---------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP using v verification oracle queries, a <= 2^c - s authenticator oracle queries, and running time t. Let T denote the time to perform one computation of H. If Assumption 1 is true, then
m = 10^Digit < 2^31 とし、(q,r) = IntDiv(2^31,m) とする。B を、検証オラクルクエリ v 回、認証オラクルクエリ a <= 2^c - s 回、実行時間 t で HOTP を攻撃する任意の攻撃者とする。T を H の 1 回の計算にかかる時間とする。仮定 1 が真であれば、
Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n
In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller than the sv(q + 1)/2^n term, so that the above says that for all practical purposes the success rate of an adversary attacking HOTP is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP algorithm is in practice essentially as good as its idealized counterpart.
実際には、(t/T)2^-k + ((sv + a)^2)2^-n の項は sv(q + 1)/2^n の項よりもはるかに小さいため、上記は、すべての実用的な目的において、HOTPを攻撃する敵対者の成功率は、HOTP-IDEALの場合と同様に sv(q + 1)/2^n であることを意味します。つまり、HOTPアルゴリズムは実際にはその理想化された対応物と本質的に同じくらい優れています。
In the case m = 10^6 of a 6-digit output, this means that an adversary making v authentication attempts will have a success rate that is at most that of Equation 1.
6桁の出力の m = 10^6 の場合、これは、v回の認証試行を行う敵対者の成功率が、最大でも式1の成功率であることを意味します。
For example, consider an adversary with running time at most 2^60 that sees at most 2^40 authentication attempts of the user. Both these choices are very generous to the adversary, who will typically not have these resources, but we are saying that even such a powerful adversary will not have more success than indicated by Equation 1.
たとえば、最大 2^60 の実行時間を持ち、最大 2^40 回のユーザー認証試行を見る敵対者を考えます。これらの選択は両方とも敵対者にとって非常に寛大なものであり、通常はこれらのリソースを持っていませんが、そのような強力な敵対者でさえ、式1で示される以上の成功を収めることはないと言っています。
We can safely assume sv <= 2^40 due to the throttling and bounds on s. So:
スロットリングと s の制限により、sv <= 2^40 と安全に仮定できます。したがって：
(t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160
roughly <= 2^-78
which is much smaller than the success probability of Equation 1 and negligible compared to it.
これは、式1の成功確率よりはるかに小さく、それと比較して無視できる。
This sections addresses the impact of the recent attacks on SHA-1 on the security of the HMAC-SHA-1-based HOTP. We begin with some discussion of the situation of SHA-1 and then discuss the relevance to HMAC-SHA-1 and HOTP. Cited references are in Section 13.
このセクションでは、HMAC-SHA-1ベースのHOTPのセキュリティに対するSHA-1に対する最近の攻撃の影響について説明します。SHA-1の状況についてのいくつかの議論から始めて、HMAC-SHA-1とHOTPとの関連性について説明します。引用文献はセクション13にあります。
A collision for a hash function h means a pair x,y of different inputs such that h(x)=h(y). Since SHA-1 outputs 160 bits, a birthday attack finds a collision in 2^{80} trials. (A trial means one computation of the function.) This was thought to be the best possible until Wang, Yin, and Yu announced on February 15, 2005, that they had an attack finding collisions in 2^{69} trials.
ハッシュ関数 h の衝突とは、h(x)=h(y) となる異なる入力のペア x,y を意味します。SHA-1は160ビットを出力するため、誕生日攻撃は 2^{80} 回の試行で衝突を見つけます。（試行とは、関数の1回の計算を意味します。）Wang、Yin、Yuが2005年2月15日に 2^{69} 回の試行で衝突を見つける攻撃を持っていると発表するまでは、これが最良であると考えられていました。
Is SHA-1 broken? For most practical purposes, we would say probably not, since the resources needed to mount the attack are huge. Here is one way to get a sense of it: we can estimate it is about the same as the time we would need to factor a 760-bit RSA modulus, and this is currently considered out of reach.
SHA-1は破られたのでしょうか？攻撃を仕掛けるために必要なリソースが膨大であるため、ほとんどの実用的な目的においては、おそらくそうではないと言えるでしょう。感覚をつかむ一つの方法は次のとおりです。これは、760ビットのRSAモジュラスを因数分解するのに必要な時間とほぼ同じであると推定でき、これは現在、達成不可能であると考えられています。
Burr of NIST is quoted in [Crack] as saying "Large national intelligence agencies could do this in a reasonable amount of time with a few million dollars in computer time". However, the computation may be out of reach of all but such well-funded agencies.
NISTのBurrは[Crack]の中で、「大規模な国家諜報機関であれば、数百万ドルのコンピュータ時間を使って、妥当な時間内にこれを行うことができるだろう」と述べていると引用されています。しかし、その計算は、そのような資金潤沢な機関以外のすべてにとっては手の届かないものかもしれません。
One should also ask what impact finding SHA-1 collisions actually has on security of real applications such as signatures. To exploit a collision x,y to forge signatures, you need to somehow obtain a signature of x and then you can forge a signature of y. How damaging this is depends on the content of y: the y created by the attack may not be meaningful in the application context. Also, one needs a chosen-message attack to get the signature of x. This seems possible in some contexts, but not others. Overall, it is not clear that the impact on the security of signatures is significant.
また、SHA-1の衝突を見つけることが、署名などの実際のアプリケーションのセキュリティに実際にどのような影響を与えるかも問うべきです。衝突 x,y を悪用して署名を偽造するには、どうにかして x の署名を取得する必要があり、そうすれば y の署名を偽造できます。これがどれほど損害を与えるかは y の内容に依存します。攻撃によって作成された y は、アプリケーションのコンテキストでは意味をなさないかもしれません。また、x の署名を取得するには選択平文攻撃（chosen-message attack）が必要です。これは一部のコンテキストでは可能かもしれませんが、他ではそうではありません。全体として、署名のセキュリティへの影響が重大であるかどうかは明らかではありません。
Indeed, one can read in the press that SHA-1 is "broken" [Sha1] and that encryption and SSL are "broken" [Res]. The media have a tendency to magnify events: it would hardly be interesting to announce in the news that a team of cryptanalysts did very interesting theoretical work in attacking SHA-1.
確かに、プレスではSHA-1が「破られた」[Sha1]、暗号化とSSLが「破られた」[Res]と読むことができます。メディアは出来事を誇張する傾向があります。暗号解読者のチームがSHA-1への攻撃において非常に興味深い理論的な仕事をしたとニュースで発表しても、ほとんど面白くはないでしょう。
Cryptographers are excited too. But mainly because this is an important theoretical breakthrough. Attacks can only get better with time: it is therefore important to monitor any progress in hash functions cryptanalysis and be prepared for any really practical break with a sound migration plan for the future.
暗号学者たちも興奮しています。しかし、それは主にこれが重要な理論的進歩だからです。攻撃は時間とともに良くなる一方です。したがって、ハッシュ関数の暗号解読の進歩を監視し、将来に向けた健全な移行計画を持って、真に実用的な解読に備えることが重要です。
The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1. The best attack on the latter remains one needing a sender to authenticate 2^{80} messages before an adversary can create a forgery. Why?
SHA-1に対する新しい攻撃は、HMAC-SHA-1のセキュリティに影響を与えません。後者に対する最良の攻撃は、敵対者が偽造を作成できるようになる前に、送信者が 2^{80} 個のメッセージを認証する必要があるというもののままです。なぜでしょうか？
HMAC is not a hash function. It is a message authentication code (MAC) that uses a hash function internally. A MAC depends on a secret key, while hash functions don't. What one needs to worry about with a MAC is forgery, not collisions. HMAC was designed so that collisions in the hash function (here SHA-1) do not yield forgeries for HMAC.
HMACはハッシュ関数ではありません。それは内部的にハッシュ関数を使用するメッセージ認証コード（MAC）です。MACは秘密鍵に依存しますが、ハッシュ関数はそうではありません。MACで心配する必要があるのは、衝突ではなく偽造です。HMACは、ハッシュ関数（ここではSHA-1）内の衝突がHMACの偽造物を生み出さないように設計されました。
Recall that HMAC-SHA-1(K,x) = SHA-1(K_o,SHA-1(K_i,x)) where the keys K_o,K_i are derived from K. Suppose the attacker finds a pair x,y such that SHA-1(K_i,x) = SHA-1(K_i,y). (Call this a hidden-key collision.) Then if it can obtain the MAC of x (itself a tall order), it can forge the MAC of y. (These values are the same.) But finding hidden-key collisions is harder than finding collisions, because the attacker does not know the hidden key K_i. All it may have is some outputs of HMAC-SHA-1 with key K. To date, there are no claims or evidence that the recent attacks on SHA-1 extend to find hidden-key collisions.
HMAC-SHA-1(K,x) = SHA-1(K_o,SHA-1(K_i,x)) であり、鍵 K_o, K_i は K から導出されることを思い出してください。攻撃者が SHA-1(K_i,x) = SHA-1(K_i,y) となるペア x,y を見つけたとします。（これを隠し鍵衝突と呼びます。）もし攻撃者が x の MAC を取得できれば（それ自体が困難な注文ですが）、y の MAC を偽造できます。（これらの値は同じです。）しかし、攻撃者は隠し鍵 K_i を知らないため、隠し鍵衝突を見つけることは衝突を見つけるよりも困難です。攻撃者が持っているのは、鍵 K を使用した HMAC-SHA-1 のいくつかの出力だけかもしれません。現在まで、SHA-1に対する最近の攻撃が隠し鍵衝突の発見に拡張されるという主張や証拠はありません。
Historically, the HMAC design has already proven itself in this regard. MD5 is considered broken in that collisions in this hash function can be found relatively easily. But there is still no attack on HMAC-MD5 better than the trivial 2^{64} time birthday one. (MD5 outputs 128 bits, not 160.) We are seeing this strength of HMAC coming into play again in the SHA-1 context.
歴史的に、HMACの設計はこの点ですでに実証されています。MD5は、このハッシュ関数の衝突が比較的容易に見つかるという点で、破られていると考えられています。しかし、HMAC-MD5に対しては、自明な 2^{64} 時間の誕生日攻撃よりも優れた攻撃はまだありません。（MD5は160ビットではなく128ビットを出力します。）SHA-1のコンテキストにおいて、HMACのこの強みが再び発揮されているのを見ています。
Since no new weakness has surfaced in HMAC-SHA-1, there is no impact on HOTP. The best attacks on HOTP remain those described in the document, namely, to try to guess output values.
HMAC-SHA-1に新たな弱点が浮上していないため、HOTPに影響はありません。HOTPに対する最良の攻撃は、文書に記載されているもの、すなわち出力値を推測しようとすることです。
The security proof of HOTP requires that HMAC-SHA-1 behave like a pseudorandom function. The quality of HMAC-SHA-1 as a pseudorandom function is not impacted by the new attacks on SHA-1, and so neither is this proven guarantee.
HOTPのセキュリティ証明は、HMAC-SHA-1が疑似ランダム関数のように振る舞うことを要求します。疑似ランダム関数としてのHMAC-SHA-1の品質は、SHA-1に対する新しい攻撃の影響を受けないため、この証明された保証も影響を受けません。
/*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* HOTP one-time password algorithm
*
*/
/* Copyright (C) 2004, OATH. All rights reserved.
*
* License to copy and use this software is granted provided that it
* is identified as the "OATH HOTP Algorithm" in all material
* mentioning or referencing this software or this function.
*
* License is also granted to make and use derivative works provided
* that such works are identified as
* "derived from OATH HOTP algorithm"
* in all material mentioning or referencing the derived work.
*
* OATH (Open AuTHentication) and its members make no
* representations concerning either the merchantability of this
* software or the suitability of this software for any particular
* purpose.
*
* It is provided "as is" without express or implied warranty
* of any kind and OATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS
* ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
*
* These notices must be retained in any copies of any part of this
* documentation and/or software.
*/
package org.openauthentication.otp;
package org.openauthentication.OTP;
import java.io.IOException;
import java.io.File;
import java.io.DataInputStream;
import java.io.FileInputStream ;
import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
/**
* This class contains static methods that are used to calculate the
* One-Time Password (OTP) using
* JCE to provide the HMAC-SHA-1.
*
* @author Loren Hart
* @version 1.0
*/
public class OneTimePasswordAlgorithm {
private OneTimePasswordAlgorithm() {}
// These are used to calculate the check-sum digits.
// 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
/**
* Calculates the checksum using the credit card algorithm.
* This algorithm has the advantage that it detects any single
* mistyped digit and any single transposition of
* adjacent digits.
*
* @param num the number to calculate the checksum for
* @param digits number of significant places in the number
*
* @return the checksum of num
*/
public static int calcChecksum(long num, int digits) {
boolean doubleDigit = true;
int total = 0;
while (0 < digits--) {
int digit = (int) (num % 10);
num /= 10;
if (doubleDigit) {
digit = doubleDigits[digit];
}
total += digit;
doubleDigit = !doubleDigit;
}
int result = total % 10;
if (result > 0) {
result = 10 - result;
}
return result;
}
/**
* This method uses the JCE to provide the HMAC-SHA-1
* algorithm. * HMAC computes a Hashed Message Authentication Code and * in this case SHA1 is the hash algorithm used. * * @param keyBytes the bytes to use for the HMAC-SHA-1 key * @param text the message or text to be authenticated. * * @throws NoSuchAlgorithmException if no provider makes * either HmacSHA1 or HMAC-SHA-1 * digest algorithms available. * @throws InvalidKeyException * The secret provided was not a valid HMAC-SHA-1 key. * */
* アルゴリズム。 * HMACはハッシュメッセージ認証コードを計算し、 * この場合、SHA1が使用されるハッシュアルゴリズムです。 * * @param keyBytes HMAC-SHA-1キーに使用するバイト * @param text 認証されるメッセージまたはテキスト。 * * @throws NoSuchAlgorithmException プロバイダーが * HmacSHA1 または HMAC-SHA-1 * ダイジェストアルゴリズムを利用可能にしていない場合。 * @throws InvalidKeyException * 提供されたシークレットが有効なHMAC-SHA-1キーではなかった場合。 * */
public static byte[] hmac_sha1(byte[] keyBytes, byte[] text)
throws NoSuchAlgorithmException, InvalidKeyException
{
// try {
Mac hmacSha1;
try {
hmacSha1 = Mac.getInstance("HmacSHA1");
} catch (NoSuchAlgorithmException nsae) {
hmacSha1 = Mac.getInstance("HMAC-SHA-1");
}
SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW");
hmacSha1.init(macKey);
return hmacSha1.doFinal(text);
// } catch (GeneralSecurityException gse) {
// throw new UndeclaredThrowableException(gse);
// }
}
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 an OTP value for the given
* set of parameters.
*
* @param secret the shared secret
* @param movingFactor the counter, time, or other value that
* changes on a per use basis.
* @param codeDigits the number of digits in the OTP, not
* including the checksum, if any.
* @param addChecksum a flag that indicates if a checksum digit
* should be appended to the OTP.
* @param truncationOffset the offset into the MAC result to
* begin truncation. If this value is out of
* the range of 0 ... 15, then dynamic
* truncation will be used.
* Dynamic truncation is when the last 4
* bits of the last byte of the MAC are
* used to determine the start offset.
* @throws NoSuchAlgorithmException if no provider makes
* either HmacSHA1 or HMAC-SHA-1
* digest algorithms available.
* @throws InvalidKeyException
* The secret provided was not
* a valid HMAC-SHA-1 key.
*
* @return A numeric String in base 10 that includes
* {@link codeDigits} digits plus the optional checksum
* digit if requested.
*/
static public String generateOTP(byte[] secret,
long movingFactor,
int codeDigits,
boolean addChecksum,
int truncationOffset)
throws NoSuchAlgorithmException, InvalidKeyException
{
// put movingFactor value into text byte array
String result = null;
int digits = addChecksum ? (codeDigits + 1) : codeDigits;
byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}
// compute hmac hash
byte[] hash = hmac_sha1(secret, text);
// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;
if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) {
offset = truncationOffset;
}
int binary =
((hash[offset] & 0x7f) << 24)
| ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8)
| (hash[offset + 3] & 0xff);
| (hash[offset + 3] & 0xff);
int otp = binary % DIGITS_POWER[codeDigits];
if (addChecksum) {
otp = (otp * 10) + calcChecksum(otp, codeDigits);
}
result = Integer.toString(otp);
while (result.length() < digits) {
result = "0" + result;
}
return result;
}
}
The following test data uses the ASCII string "12345678901234567890" for the secret:
次のテストデータは、SecretについてASCII文字列 "12345678901234567890"を使用します。
Secret = 0x3132333435363738393031323334353637383930
Table 1 details for each count, the intermediate HMAC value.
表1各カウント、中間HMAC値の詳細。
Count Hexadecimal HMAC-SHA-1(secret, count)
0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0
1 75a48a19d4cbe100644e8ac1397eea747a2d33ab
2 0bacb7fa082fef30782211938bc1c5e70416ff44
3 66c28227d03a2d5529262ff016a1e6ef76557ece
4 a904c900a64b35909874b33e61c5938a8e15ed1c
5 a37e783d7b7233c083d4f62926c7a25f238d0316
6 bc9cd28561042c83f219324d3c607256c03272ae
7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa
8 1b3c89f65e6c9e883012052823443f048b4332db
9 1637409809a679dc698207310c8c7fc07290d9e5
Table 2 details for each count the truncated values (both in hexadecimal and decimal) and then the HOTP value.
表2は、各カウントについて、切り捨てられた値（16進数と10進数の両方）と、HOTP値を詳述しています。
Truncated
Count Hexadecimal Decimal HOTP
0 4c93cf18 1284755224 755224
1 41397eea 1094287082 287082
2 82fef30 137359152 359152
3 66ef7655 1726969429 969429
4 61c5938a 1640338314 338314
5 33c083d4 868254676 254676
6 7256c032 1918287922 287922
7 4e5b397 82162583 162583
8 2823443f 673399871 399871
9 2679dc69 645520489 520489
We introduce in this section several enhancements to the HOTP algorithm. These are not recommended extensions or part of the standard algorithm, but merely variations that could be used for customized implementations.
このセクションでは、HOTPアルゴリズムに対するいくつかの機能強化を紹介します。これらは推奨される拡張ではなく、標準アルゴリズムの一部でもありませんが、カスタマイズされた実装に使用できる単なるバリエーションです。
A simple enhancement in terms of security would be to extract more digits from the HMAC-SHA-1 value.
セキュリティに関する単純な強化は、HMAC-SHA-1値からより多くの桁を抽出することです。
For instance, calculating the HOTP value modulo 10^8 to build an 8- digit HOTP value would reduce the probability of success of the adversary from sv/10^6 to sv/10^8.
たとえば、8桁のHOTP値を構築するためにHOTP値のモジュロ 10^8 を計算すると、敵対者の成功確率は sv/10^6 から sv/10^8 に低下します。
This could give the opportunity to improve usability, e.g., by increasing T and/or s, while still achieving a better security overall. For instance, s = 10 and 10v/10^8 = v/10^7 < v/10^6 which is the theoretical optimum for 6-digit code when s = 1.
これにより、例えば T や s を増やすことで、全体的により良いセキュリティを達成しながら、ユーザビリティを向上させる機会が得られます。例えば、s = 10 の場合、10v/10^8 = v/10^7 < v/10^6 となり、これは s = 1 の場合の6桁コードの理論上の最適値よりも小さくなります。
Another option is to use A-Z and 0-9 values; or rather a subset of 32 symbols taken from the alphanumerical alphabet in order to avoid any confusion between characters: 0, O, and Q as well as l, 1, and I are very similar, and can look the same on a small display.
もう1つのオプションは、A-Zと0-9の値を使用することです。あるいはむしろ、文字間の混乱を避けるために、英数字のアルファベットから取られた32個のシンボルのサブセットを使用することです。0、O、Q、および l、1、I は非常に似ており、小さなディスプレイでは同じに見えることがあります。
The immediate consequence is that the security is now in the order of sv/32^6 for a 6-digit HOTP value and sv/32^8 for an 8-digit HOTP value.
直接的な結果として、セキュリティは6桁のHOTP値で sv/32^6 のオーダー、8桁のHOTP値で sv/32^8 のオーダーになります。
32^6 > 10^9 so the security of a 6-alphanumeric HOTP code is slightly better than a 9-digit HOTP value, which is the maximum length of an HOTP code supported by the proposed algorithm.
32^6 > 10^9 なので、6桁の英数字HOTPコードのセキュリティは9桁のHOTP値よりわずかに優れており、これは提案されたアルゴリズムでサポートされているHOTPコードの最大長です。
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is significantly better than a 9-digit HOTP value.
32^8 > 10^12 なので、8桁の英数字HOTPコードのセキュリティは9桁のHOTP値よりもかなり優れています。
Depending on the application and token/interface used for displaying and entering the HOTP value, the choice of alphanumeric values could be a simple and efficient way to improve security at a reduced cost and impact on users.
HOTP値の表示と入力に使用されるアプリケーションとトークン/インターフェイスによっては、英数字の値の選択は、コストとユーザーへの影響を抑えつつセキュリティを向上させるための、シンプルで効率的な方法となり得ます。
As we suggested for the resynchronization to enter a short sequence (say, 2 or 3) of HOTP values, we could generalize the concept to the protocol, and add a parameter L that would define the length of the HOTP sequence to enter.
再同期を推奨して、HOTP値の短いシーケンス（つまり、2または3）を入力すると、概念をプロトコルに一般化し、入力するHOTPシーケンスの長さを定義するパラメータLを追加することができます。
Per default, the value L SHOULD be set to 1, but if security needs to be increased, users might be asked (possibly for a short period of time, or a specific operation) to enter L HOTP values.
デフォルトでは、値Lは1に設定すべきですが（SHOULD）、セキュリティを強化する必要がある場合、ユーザーは（おそらく短期間、または特定の操作のために）L個のHOTP値を入力するように求められるかもしれません。
This is another way, without increasing the HOTP length or using alphanumeric values to tighten security.
これは、HOTPの長さを増やしたり英数字の値を使用したりすることなく、セキュリティを強化するための別の方法です。
Note: The system MAY also be programmed to request synchronization on a regular basis (e.g., every night, twice a week, etc.) and to achieve this purpose, ask for a sequence of L HOTP values.
注：システムは、定期的に同期を要求するようにプログラムされてもよく、この目的を達成するために、一連のL HOTP値を問い合わせることもできます。
In this case, we assume that the client can access and send not only the HOTP value but also other information, more specifically, the counter value.
この場合、クライアントはHOTP値だけでなく他の情報、より具体的にはカウンタ値にアクセスして送信できるとします。
A more efficient and secure method for resynchronization is possible in this case. The client application will not send the HOTP-client value only, but the HOTP-client and the related C-client counter value, the HOTP value acting as a message authentication code of the counter.
この場合、再同期のためのより効率的で安全な方法が可能です。クライアントアプリケーションは、HOTPクライアント値のみを送信するのではなく、HOTPクライアント値と関連するCクライアントカウンタ値を送信します。ここで、HOTP値はカウンタのメッセージ認証コードとして機能します。
Resynchronization Counter-based Protocol (RCP)
----------------------------------------------
The server accepts if the following are all true, where C-server is its own current counter value:
C-server をそれ自身の現在のカウンタ値として、以下がすべて真である場合、サーバーは受け入れます。
1) C-client >= C-server
2) C-client - C-server <= s
3) Check that HOTP client is valid HOTP(K,C-Client)
4) If true, the server sets C to C-client + 1 and client is
authenticated
In this case, there is no need for managing a look-ahead window anymore. The probability of success of the adversary is only v/10^6 or roughly v in one million. A side benefit is obviously to be able to increase s "infinitely" and therefore improve the system usability without impacting the security.
この場合、もはや先読みウィンドウを管理する必要はありません。敵対者の成功確率はわずか v/10^6、つまりおよそ100万分の v です。副次的な利点は、明らかに s を「無限に」増やすことができ、したがってセキュリティに影響を与えることなくシステムの使いやすさを向上させることができることです。
This resynchronization protocol SHOULD be used whenever the related impact on the client and server applications is deemed acceptable.
この再同期プロトコルは、クライアントおよびサーバーアプリケーションへの関連する影響が許容できると見なされる場合は常に使用されるべきです（SHOULD）。
Another interesting option is the introduction of a Data field, which would be used for generating the One-Time Password values: HOTP (K, C, [Data]) where Data is an optional field that can be the concatenation of various pieces of identity-related information, e.g., Data = Address | PIN.
もう1つの興味深いオプションは、Dataフィールドの導入です。これはワンタイムパスワード値の生成に使用されます：HOTP (K, C, [Data])。ここで、Dataはオプションのフィールドであり、様々な本人確認関連情報の連結とすることができます。例：Data = Address | PIN。
We could also use a Timer, either as the only moving factor or in combination with the Counter -- in this case, e.g., Data = Timer, where Timer could be the UNIX-time (GMT seconds since 1/1/1970) divided by some factor (8, 16, 32, etc.) in order to give a specific time step. The time window for the One-Time Password is then equal to the time step multiplied by the resynchronization parameter as defined before. For example, if we take 64 seconds as the time step and 7 for the resynchronization parameter, we obtain an acceptance window of +/- 3 minutes.
また、唯一の移動因子として、あるいはカウンタと組み合わせて、タイマーを使用することもできます。この場合、例えば Data = Timer となります。ここで Timer は、特定のタイムステップを与えるために、ある係数（8、16、32など）で割ったUNIX時間（1970年1月1日からのGMT秒）とすることができます。ワンタイムパスワードのタイムウィンドウは、前述のように、タイムステップに再同期パラメータを掛けたものに等しくなります。例えば、タイムステップとして64秒、再同期パラメータとして7をとると、+/- 3分の受け入れウィンドウが得られます。
Using a Data field opens for more flexibility in the algorithm implementation, provided that the Data field is clearly specified.
データフィールドが明確に指定されている場合、データフィールドを使用すると、アルゴリズムの実装ではより柔軟性が向上します。
Authors' Addresses
著者の住所
David M'Raihi (primary contact for sending comments and questions) 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
Phone: 1-650-426-3832 EMail: dmraihi@verisign.com
電話：1-650-426-3832 Eメール：Dmraihi@verisign.com
Mihir Bellare Dept of Computer Science and Engineering, Mail Code 0114 University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093, USA
Mihir Bellare Dept of Computer Science and Engineering, Mail Code 0114 University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093, USA
EMail: mihir@cs.ucsd.edu
Frank Hoornaert VASCO Data Security, Inc. Koningin Astridlaan 164 1780 Wemmel, Belgium
Frank Hoornaert VASCO Data Security, Inc. Koningin Astridlaan 164 1780 Wemmel, Belgium
EMail: frh@vasco.com
David Naccache Gemplus Innovation 34 rue Guynemer, 92447, Issy les Moulineaux, France and Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK
David Naccache Gemplus Innovation 34 rue Guynemer, 92447, Issy les Moulineaux, France and Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK
EMail: david.naccache@gemplus.com, david.naccache@rhul.ac.uk
Ohad Ranen Aladdin Knowledge Systems Ltd. 15 Beit Oved Street Tel Aviv, Israel 61110
Ohad Ranen Aladdin Knowledge Systems Ltd. 15 Beit Oved Street Tel Aviv, Israel 61110
EMail: Ohad.Ranen@ealaddin.com
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれている権利、ライセンス、制限の対象となり、そこで定められている場合を除き、著者らはすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状のまま」基準で提供されており、投稿者、その代理人またはスポンサー（もしあれば）、The Internet Society、およびInternet Engineering Task Forceは、明示的または黙示的を問わず、すべての保証を放棄します。これには、本明細書に含まれる情報の使用がいかなる権利も侵害しないという保証や、商品性または特定目的への適合性の黙示的な保証が含まれますが、これらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、この文書に記載された技術の実装または使用に関連すると主張されるいかなる知的財産権やその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが利用可能であるか否かの範囲に関して、いかなる立場もとりません。また、そのような権利を特定するために独自の調査を行ったことを表明するものでもありません。RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピー、および利用可能になるライセンスの保証、あるいはこの仕様の実装者や利用者によるそのような所有権の使用のための一般的なライセンスまたは許可を得るための試みの結果は、http://www.ietf.org/ipr にあるIETFオンラインIPRリポジトリから入手できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権について、注意を喚起するよう関心のある当事者に求めます。情報は ietf-ipr@ietf.org までお送りください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在The Internet Societyによって提供されています。