RFC4226 日本語訳
4226 HOTP: An HMAC-Based One-Time Password Algorithm. D. M'Raihi, M.Bellare, F. Hoornaert, D. Naccache, O. Ranen. December 2005. (Format: TXT=77117 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
M'Raihiがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4226年のベリサインカテゴリ: 情報のM.のD.Naccache Gemplus O.RanenアラジンBellare UCSD F.Hoornaertヴァスコ2005年12月
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).
Copyright(C)インターネット協会(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.
このドキュメントは、Hashedメッセージ立証コード(HMAC)に基づいてワンタイムパスワード値を生成するためにアルゴリズムを説明します。 アルゴリズムの証券分析は提示されます、そして、アルゴリズムの安全な展開に関連する重要なパラメタについて議論します。 リモートVirtual兵士のNetwork(VPN)アクセス(トランザクション指向のウェブアプリケーションへのWi-Fiネットワークログオン)から変化するさまざまなネットワーク応用の向こう側に提案されたアルゴリズムを使用できます。
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(開いているAuTHentication)会員資格による共同努力です。 作者は、一般的で共有されたアルゴリズムがコマーシャルとオープンソース実装の向こう側に相互運用性を可能にすることによってインターネットにおける2要素の認証の採用を容易にすると信じています。
M'Raihi, et al. Informational [Page 1] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [1ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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
1. 概要…3 2. 序論…3 3. 要件用語…4 4. アルゴリズム要件…4 5. HOTPアルゴリズム…5 5.1. 記法とシンボル…5 5.2. 記述…6 5.3. HOTPが値であると生成します…6 5.4. ケタ=6のためのHOTP計算に関する例…7 6. セキュリティ問題…8 7. セキュリティ要件…9 7.1. 認証プロトコル要件…9 7.2. HOTP値の合法化…10 7.3. サーバでは、阻止します。10 7.4. カウンタのResynchronization…11 7.5. 共有秘密キーの管理…11 8. 共有秘密キーを合成してください…14 9. 双方向の認証…14 10. 結論…15 11. 承認…15 12. 貢献者…15 13. 参照…15 13.1. 標準の参照…15 13.2. 有益な参照…16 付録A--HOTPアルゴリズムセキュリティ: 詳細な分析…17 A.1。 定義と記法…17 A.2。 理想化されたアルゴリズム: HOTP-理想…17 A.3。 セキュリティのモデル…18 A.4。 理想的な認証アルゴリズムのセキュリティ…19 A.4.1。 ビットからケタまで…19 A.4.2。 ブルートフォースアタック…21 A.4.3。 ブルートフォースアタックは可能な限り良い攻撃です。22 A.5。 HOTPの証券分析…23 付録B--SHA-1は攻撃します…25 B.1。 SHA-1状態…25 B.2。 HMAC-SHA-1状態…26 B.3。 HOTP状態…26 付録C--HOTPアルゴリズム: リファレンスインプリメンテーション…27 付録D--HOTPアルゴリズム: 値をテストしてください…32付録E--、拡大…33 E.1。 ケタの数…33 E.2。 英数字の値…33 E.3。 HOTP値の系列…34 E.4。 カウンタベースのResynchronizationメソッド…34 E.5。 データ分野…35
M'Raihi, et al. Informational [Page 2] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [2ページ]情報のRFC4226HOTPアルゴリズム2005年12月
1. Overview
1. 概要
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 One-時間Password(HOTP)アルゴリズムと命名されます。 セクション4では、アルゴリズム要件は記載されています、そして、セクション5では、HOTPアルゴリズムは説明されます。 セクション6と7はアルゴリズムセキュリティに焦点を合わせます。 セクション8はいくつかの拡大と改良を提案します、そして、セクション10はこのドキュメントを結論づけます。 Appendix Aでは、興味のある読者はアルゴリズムセキュリティの詳細で、完全な分析を見つけるでしょう: アルゴリズムの理想化されたバージョンは評価されます、そして、次に、HOTPアルゴリズムセキュリティは分析されます。
2. Introduction
2. 序論
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.
今日、2要素の認証の展開は範囲とスケールが非常に制限されている残っています。 ますますより高いレベルの脅威と攻撃にもかかわらず、ほとんどのインターネットアプリケーションがまだユーザアクセサリーを取り締まることの弱い認証体系を当てにしています。 ハードウェアの中の相互運用性とソフトウェア技術ベンダの不足は2要素の認証技術の採用で限定因子です。 特に、開いている仕様の欠如は専有技術でハードウェアとソフトウェアコンポーネントが密結合であるところでソリューションにつながりました、高費用解答、不十分な採用、および限られた革新をもたらして。
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年間で、ネットワークの脅威の急騰はインターネットにおける認証のプライマリ平均として静的なパスワードの不適当を暴露しました。 同時に、エンドユーザが単にネットワークに認証するのにおいて使用された高価で、単一の機能デバイスを運ぶのを必要とする現在のアプローチは明確に正しい答ではありません。 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.
広い相互運用性を確実にしている間にこのベース技術を埋め込む能力は、ハードウェアとソフトウェア開発者の広い技術的な共同体が自由にそれを入手するのを必要とします。 オープンシステムアプローチだけが、基本の2要素の認証基関数をUSB大記憶装置や、IP電話や、携帯情報端末などの民生品の次世代に組み込むことができるのを確実にするでしょう。
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
確かに、1回のPasswordはネットワークアクセサリーを機密保護するための2要素の認証の最も簡単で最もポピュラーなフォームの1つです。 例えば、大企業では、Virtual兵士のNetworkアクセスはOne-時間Passwordトークンのリモート・ユーザー認証の使用をしばしば必要とします。 1回のPasswordsは、より強いというよりもしばしば好まれます。
M'Raihi, et al. Informational [Page 3] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [3ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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.
エアギャップデバイスがするので、公開鍵基盤などの認証(PKI)か生体認証のフォームはどんなクライアントデスクトップ・ソフトウェアのユーザマシンへのインストールも必要としません、したがって、パソコン、キオスク、および携帯情報端末を含んでいて、複数のマシンの向こう側に移動するためにそれらを許容します。
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].
このドキュメントはどんなハードウェアメーカーやソフトウェア開発者も共同利用できる認証デバイスとソフトウェアエージェントを創造するために実装することができる簡単なOne-時間Passwordアルゴリズムを提案します。 アルゴリズムは、Javaスマートカードや、USBドングルや、GSM SIMカードなどの大容量デバイスにそれを埋め込むことができるようにイベントベースです。 IETF Intellectual Property Rights[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.
このドキュメントの作者はオープンAuTHenticationイニシアチブ[OATH]のメンバーです。 イニシアチブは、2004年に強い認証技術プロバイダーの中で共同を容易にするために作成されました。
3. Requirements Terminology
3. 要件用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
4. Algorithm Requirements
4. アルゴリズム要件
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--アルゴリズムは、系列かカウンタベースであるに違いありません: 目標の1つは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--、アルゴリズム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--アルゴリズムは、どんな数値入力もサポートしないトークンで働かなければなりませんが、また、安全な暗証番号パッドなどの、より精巧なデバイスと共に使用されるかもしれません。
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--ユーザは、トークンに表示された値を、容易に読まれて、入れなければなりません: これは、HOTP値が妥当な長さのものであることを必要とします。
M'Raihi, et al. Informational [Page 4] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [4ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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--カウンタを再連動させるように利用可能なユーザフレンドリーなメカニズムがあるに違いありません。 再同期メカニズムが本書では提案したセクション7.4とAppendix 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--アルゴリズムは強い共有秘密キーを使用しなければなりません。 共有秘密キーの長さは少なくとも128ビットでなければなりません。 これは160ビットの共有秘密キーの長さにRECOMMENDsを記録します。
5. HOTP Algorithm
5. HOTPアルゴリズム
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値を抽出するトランケーションメソッド。
5.1. Notation and Symbols
5.1. 記法とシンボル
A string always means a binary string, meaning a sequence of zeros and ones.
ゼロとものの系列を意味して、五弦はいつも2進のストリングを意味します。
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[i]が、sであるならaがストリングであることを指示する、それ、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(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).
シンボルは表します。------------------------------------------------------------------- Cの8バイトの対価、感動的な要素。 このカウンタはHOTPジェネレータ(クライアント)とHOTP validator(サーバ)の間で連動しなければなりません。
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失敗の認証試みの後にユーザから接続を拒否するでしょう。
M'Raihi, et al. Informational [Page 5] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [5ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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.
HOTP値における、ケタの桁数。 システム・パラメータ。
5.2. Description
5.2. 記述
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値を作成するために、私たちはRFC2104[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))
HOTP(K、C)=は先端を切ります。(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.
- 先端を切る、セクション5.3で定義されるようにHMAC-SHA-1値をHOTP値に変換する機能を表します。
The Key (K), the Counter (C), and Data values are hashed high-order byte first.
最初に、Key(K)、Counter(C)、およびData値は論じ尽くされた高位バイトです。
The HOTP values generated by the HOTP generator are treated as big endian.
HOTPジェネレータによって生成されたHOTP値はビッグエンディアンとして扱われます。
5.3. Generating an HOTP Value
5.3. 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
ステップ1: 生成する、HMAC-SHA-1値Let HS=HMAC-SHA-1(K、C)//HSは20バイトのストリングです。
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
ステップ2: DT(HS)//DTであって、以下で定義されていた状態で(ダイナミックなTruncation)がSbitsに等しくさせる4バイトのストリングを生成してください、そして、//は31ビット列を返します。
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
ステップ3: StToNum(Sbits)//HOTP値のLet Snum=転向者Sを0における数まで計算してください…2 ^Snumモッズ10^Digit//31-1リターンD=Dは範囲0の数です…10^ケタ、-1
M'Raihi, et al. Informational [Page 6] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [6ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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機能は、Step2とStep3、すなわち、ダイナミックなトランケーションを実行して、次に、減少法10^Digitを実行します。 ダイナミックなオフセットトランケーションのテクニックの目的は160ビット(20バイト)のHMAC-SHA-1結果から4バイトのダイナミックな2進コードを抜粋することです。
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
DT(ストリング)//は=ストリング[0]を結びます…ストリング[19]は、OffsetBitsが15Let P=String[19]オフセット=OffSet StToNum(OffsetBits)//0<=<=ストリングの下位の4ビットであることをさせました[OffSet]…ストリング[OffSet+3]はPのビットをLast31に返します。
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.
実装は最小限、ことによると7、および8ケタのコードにおける6ケタのコードを抜粋しなければなりません。 7以上セキュリティ要件、Digit=SHOULDによって、より長いHOTP値を抽出するために考えられてください。
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.
以下のパラグラフは計算される6ケタのHOTPがHMAC値から評価するすなわち、Digit=6にこのテクニックを使用する例です。
5.4. Example of HOTP Computation for Digit = 6
5.4. ケタ=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_結果がHMAC- SHA-1結果があるバイト配列であるならダイナミックな2進コードの抽出について説明します:
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) ;
intは=hmac_結果[19]と0xfを相殺しました。 int容器_コードは<<24と等しいです(hmac_結果[相殺する]と0x7f)。| (hmac_結果[+1に、相殺する]と0xff) <<16| (hmac_結果[+2に、相殺する]と0xff) <<8| (hmac_結果[+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| -------------------------------***********----------------++|
------------------------------------------------------------- | バイト番号| ------------------------------------------------------------- |00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19| ------------------------------------------------------------- | バイト値| ------------------------------------------------------------- |1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a| -------------------------------***********----------------++|
M'Raihi, et al. Informational [Page 7] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [7ページ]情報のRFC4226HOTPアルゴリズム2005年12月
* 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)には、十六進法価値の0x5aがあります。 * 低級4ビットの価値は0xa(オフセット値)です。 * オフセット値はバイト10です(0xa)。 * バイト10で始まる4バイトの値は0x50ef7f19です。(その0x50ef7f19はダイナミックな2進コードDBC1です)。 * DBC2は、DBC1のMSBが0×50であるので、DBC1=0x50ef7f19と等しいです。*HOTPはDBC2法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ビットの、そして、未署名のビッグエンディアン整数としてダイナミックな2進コードを扱います。 最初のバイトは0x7fで仮面です。
We then take this number modulo 1,000,000 (10^6) to generate the 6- digit HOTP value 872921 decimal.
そして、私たちは、6ケタHOTP価値が872921小数であると生成するためにこの数の法1,000,000(10^6)で取ります。
6. Security Considerations
6. セキュリティ問題
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.
Appendixで詳細な証券分析の結論は異なったカウンタ入力のDynamic Truncation(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:
一般性の喪失なしでセキュリティがこのドキュメントのAppendixでの分析であると考える場合、私たちは以下の公式で密接にHOTPアルゴリズムのセキュリティに近似できます:
Sec = sv/10^Digit
秒はsv/10^ケタと等しいです。
M'Raihi, et al. Informational [Page 8] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [8ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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.
どこ: - 秒は敵の成功の確率です。 - sは先の外観同期ウィンドウサイズです。 - vは検証試みの数です。 - ケタはHOTP値において、ケタの数です。
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(攻撃者による試みの数を制限するThrottlingパラメタ)、およびDigitと共にあるレベルのセキュリティを達成するまでプレーできます、まだシステムユーザビリティを保存していて。
7. Security Requirements
7. セキュリティ要件
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.
どんなOne-時間Passwordアルゴリズムもそれを実装するアプリケーションと単に認証プロトコルと同じくらい安全です。 したがって、このセクションは私たちのアルゴリズムの選択が認証プロトコルと合法化ソフトウェアにでしゃばるという重要なセキュリティ要件について論じます。
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アルゴリズムが暗号化の代用品でなく、またデータ伝送のプライバシーに備えないと述べるのも重要です。 他のメカニズムは、トランザクションの壊れている秘密性とプライバシーが目的とされた攻撃を破るのに使用されるべきです。
7.1. Authentication Protocol Requirements
7.1. 認証プロトコル要件
We introduce in this section some requirements for a protocol P implementing HOTP as the authentication method between a prover and a 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はすなわち、あなたが知ること(Password、Pass句、暗証番号コードなどの暗合)とあなたが持っている何か(トークン)の2要素の認証、コミュニケーション、および検証をサポートしなければなりません。 暗合は、ユーザだけにおいて知られて、通常、認証目的(2要素の認証)のためにOne-時間Password価値で入れられます。
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はユーザのプライバシーを保護するために安全なチャンネルの上に実装されて、反射攻撃を避けます。
M'Raihi, et al. Informational [Page 9] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [9ページ]情報のRFC4226HOTPアルゴリズム2005年12月
7.2. Validation of HOTP Values
7.2. HOTP値の合法化
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クライアントについて計算します。 認証サーバによる対価領収がクライアントによって計算された値に合っているなら、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は、アカウントを締め出して、ユーザに知らせるために手順に着手します。
7.3. Throttling at the Server
7.3. サーバにおける阻止
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.
私たち、RECOMMENDのセットしているaがパラメタTを阻止して、どれがOne-時間Password合法化のための可能な試みの最大数を定義しますか? 合法化サーバは、どんな未遂にも注目するためにHOTPデバイスあたりの個々のカウンタを管理します。 私たち、それほど大きくないRECOMMEND 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*を何秒も待っているでしょう、例えば、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.
複数の平行な推測のテクニックに基づく攻撃を防ぐために、遅れかロックアウト体系がログインセッションのむこうにあるに違いありません。
M'Raihi, et al. Informational [Page 10] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [10ページ]情報のRFC4226HOTPアルゴリズム2005年12月
7.4. Resynchronization of the Counter
7.4. カウンタのResynchronization
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-サーバ値について再計算して、容認されたHOTPクライアントに対してそれらをチェックできます。
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値の系列を送るのを必要とするかもしれません、連続した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ができるだけ低く用意ができていて、そのユーザビリティはまだ確実にしている間、影響を与えられません。
7.5. Management of Shared Secrets
7.5. 共有秘密キーの管理
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:
私たちはValidationシステムの共有秘密キーを生成して、保存する(しっかりと)ために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.
* 決定論的な世代: それが必要であるときはいつも、秘密は、食糧を供給するのと検証段階でマスター種子から得られて、急いで生成されます。 * 無作為の世代: 秘密を手当たりしだいにステージに食糧を供給するのに生成されて、すぐに、保存されて、彼らのライフサイクルの間、安全に守らなければなりません。
M'Raihi, et al. Informational [Page 11] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [11ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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.
可能な戦略はマスター秘密から共有秘密キーを得ることです。 マスター秘密はサーバだけで保存されるでしょう。 マスターキーを保存して、マスターキーと何らかの公開情報から共有秘密キーを得るのに耐タンパー性デバイスを使用しなければなりません。 主な利益は、いつでも、共有秘密キーの暴露を避けて、また、ストレージのときに決められた一定の要求を避けるだろうことです、食糧を供給するのと合法化時に必要であると共有秘密キーが要求次第で生成されるかもしれないので。
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は私が唯一通し番号、トークンIDなどのHOTPデバイスを特定する公共の情報を表すSHA-1(MK、i)と等しいです。 明らかに、これはアプリケーションの、または、サービスの文脈にあります--異なったアプリケーションかサービスプロバイダーには、異なった秘密と設定があるでしょう。 - 数個のマスターキーMK_iが使用されています、そして、それぞれのHOTPデバイスはjが公共の情報のためにデバイスを特定しながら立つ異なった派生している秘密、K_i、j=SHA-1(MK_i、j)の1セットを保存します。 考えは、Hardware Security Moduleの合法化サーバ(HSM)でアクティブなマスターキーだけを保存して、安全な場所に閉じ込められるだろうことです、例えば、[シャミル]などの秘密の共有法を使用して。 この場合、マスターの秘密の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.
他方では、マスターキーを保存して、共有秘密キーを生成するのに使用されるデバイスは耐タンパー性であるに違いありません。 その上、HSMは合法化システムのセキュリティ周辺の外で暴露されないでしょう、したがって、漏出の危険を減少させます。
M'Raihi, et al. Informational [Page 12] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [12ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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がも必要です: 例えば、共有秘密キーは、短期間の間、RAMで暴露を制限するためにHOTP値について確かめるのが必要であるときに、解読されて、すぐに、再暗号化されます。 合法化システムと秘密データベースで直接攻撃をできるだけ避けるために、共有秘密キーを保持するデータ・ストアは安全な領域にあるに違いありません。
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.
特に、共有秘密キーへのアクセスはプログラムに制限されるべきです、そして、プロセスが合法化システムだけが必要です。 私たちは適所に置く異なったセキュリティー対策について詳しく説明するつもりではありませんが、明らかに、共有秘密キーの保護は極限重要です。
M'Raihi, et al. Informational [Page 13] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [13ページ]情報のRFC4226HOTPアルゴリズム2005年12月
8. Composite Shared Secrets
8. 合成共有秘密キー
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.のTheseの追加要素の追加認証要素を含んでいるのがトークンで知られていましたが、他のものによって容易に得られなかった少しのデータからも成ることができるのは、望ましいかもしれません。 そのようなデータに関する例は:
* PIN or Password obtained as user input at the token
* Phone number
* Any unique identifier programmatically available at the token
* ユーザがトークン*電話番号*でプログラムに基づいてトークンで利用可能な状態でどんなユニークな識別子も入力したので入手された暗証番号かPassword
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ベースの認証システムを強化できます。 このアプローチには、トークンが信じられたデバイスであるという範囲まで、認証要素(ユーザ入力暗証番号などの)の暴露を対向機器に必要としないさらなる利益があります。
9. Bi-Directional Authentication
9. 双方向の認証
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.
HOTPクライアントとサーバが同期して、同じ秘密(または、それを再計算するメソッド)を共有するので、簡単な3パスのプロトコルを適所に置くことができました: 1 エンドユーザはTokenIDと最初のOTP値のOTP1に入ります。 そして、サーバがチェックする2OTP1、正しい、OTP2を返送します。 エンドユーザがチェックする3OTP2が彼のHOTPデバイスを使用して、正しい、ウェブサイトを使用します。
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接続の上で行われなければなりません。
M'Raihi, et al. Informational [Page 14] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [14ページ]情報のRFC4226HOTPアルゴリズム2005年12月
10. Conclusion
10. 結論
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.
このドキュメントはHOTP、HMACベースのOne-時間Passwordアルゴリズムを説明します。 また、それはアルゴリズムを配布するための操作の都合のよい実装と関連するモードを推薦します。
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.
結局、いくつかの増進が、特定のアプリケーションに必要であるならセキュリティを向上させるために提案されました。
11. Acknowledgements
11. 承認
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、アレックスDeacon、ロレーン・ハート、およびニコ・ポップに感謝したがっています。
12. Contributors
12. 貢献者
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.
- ラズロEltetoはSafeNet Inc.のシステム建築家です。
- Ernesto Frutos is director of Engineering with Authenex, Inc.
- エルネストFrutosはAuthenex Inc.があるEngineeringのディレクターです。
- Fred McClain is Founder and CTO with Boojum Mobile, Inc.
- フレッド・マックレインは、BoojumのモバイルInc.があるFounderとCTOです。
Without their advice and valuable inputs, this document would not be the same.
彼らのアドバイスと貴重な入力がなければ、このドキュメントは同じでないでしょう。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[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.カネッティとH.Krawczyk)は「ハッシュ関数と通報認証を合わせました」、Crypto96年のProceedings、LNCS Vol.1109、ページ 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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
M'Raihi, et al. Informational [Page 15] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [15ページ]情報のRFC4226HOTPアルゴリズム2005年12月
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3979、2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
13.2. Informative References
13.2. 有益な参照
[OATH] Initiative for Open AuTHentication
http://www.openauthentication.org
開いている認証 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とP.はOorschot、「MD-x MAC、ハッシュ関数から速いMACsを造ること」をバンに積んで、Cryptology CRYPTOのAdvancesは95年です、コンピュータScience Vol.963におけるLecture Notes、D.Coppersmith教育、Springer-Verlag、1995
[Crack] Crack in SHA-1 code 'stuns' security gurus
http://www.eetimes.com/showArticle.jhtml?
articleID=60402150
SHA-1コードの[ひび]ひびはセキュリティ導師 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
[Sha1]ブルース・シュナイアー。 壊されたSHA-1。 2005年2月15日 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
[Res]研究者: 標準の、または、デジタル暗号化標準の失敗する http://news.com.com/ Researchers+Digital+暗号化+失敗する/2100-1002-5579881.htmlパート=dht、タグ=ntop、およびタグ=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.
[シャミル] アディシャミルで秘密を共有する方法。 ACMのCommunications、Vol.22、No.11、ページで 612-613と、1979年11月。
M'Raihi, et al. Informational [Page 16] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [16ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Appendix A - HOTP Algorithm Security: Detailed Analysis
付録A--HOTPアルゴリズムセキュリティ: 詳細に渡る分析
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機能と等しいケースの上のこの分析の焦点を合わせます。(それは、このドキュメントのお勧めの最低限です)。
A.1. Definitions and Notations
A.1。 定義と記法
We denote by {0,1}^l the set of all strings of length l.
私たちは長さlのすべてのストリングのセットを0、1^l指示します。
Let Z_{n} = {0,.., n - 1}.
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)
IntDiv(a、b)に>がb>=1と等しいところで入力整数a、bを取って、整数を返す整数分割アルゴリズムを指示させてください。(q、r)
the quotient and remainder, respectively, of the division of a by b. (Thus, a = bq + r and 0 <= r < b.)
それぞれ商と残り、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 x0、1^c-->0、1^nはk-ビットの主要なK取るベース機能であり、反対にCにcで噛み付いて、リターンはn-ビット出力H(K、C)に噛み付きました。 (HOTPの場合では、HはHMAC-SHA-1です; 私たちは私たちのセキュリティの証拠を広めるのにこの公式の定義を使用します。)
A.2. The Idealized Algorithm: HOTP-IDEAL
A.2。 理想化されたアルゴリズム: HOTP理想的です。
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?
より正確に、なるように、Maps(c、n)に^cを0、1から0、1に^nに写像するすべての機能のセットを指示させてください。 理想化されたアルゴリズムには主要なスペースMaps(c、n)があります、0、1^cから0、1^nまでそのようなアルゴリズムのための「キー」が機能hであるように。 私たちは、このキー(機能)が無作為に描かれると想像します。 この理想化されたアルゴリズムを実装するのは可能ではありません、0、1^cから0、1^nまでの機能でありキーがずっと保存さえできないくらい大きいので。 それで、なぜそれを考えますか?
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が、あるよく受け入れられた仮定を満たす限り、実際の、そして、理想化されたアルゴリズムのセキュリティが実際上は同じであることを示すでしょう。 次に本当に私たちに面しているタスクは理想化されたアルゴリズムのセキュリティを査定することです。
M'Raihi, et al. Informational [Page 17] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [17ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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の如何にかかわらず。 事実上、これは切迫した課題です。
A.3. Model of Security
A.3。 セキュリティのモデル
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.
モデルは、考えられている脅威か攻撃のタイプを示して、1つが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を受けるとき、zが範囲CのいくつかのiのためにALG(K、i)と等しい限り、サーバは受け入れるでしょう…C+s-1。(そこでは、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.
私たちが指定するモデルは敵ができることが得ます。そして、「勝つ」ために達成するそれが必要があること。 まず最初に、固有識別文字がユーザによって伝えられるのを見ることを意味して、敵が盗み聞くことができると思われます。 2番目に、サーバがそれでユーザが固有識別文字を一度も伝えたことがない対価に比例して固有識別文字を受け入れることができるなら、敵は勝ちます。
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完全な支配力を与えます。 それはユーザの代理をする固有識別文字神託に近づく手段を持っています。 この神託を呼ぶことによって、敵は、代わりにそれ自体を認証して、固有識別文字を取り戻すようにユーザに頼むことができます。 それは好きなだけ頻繁、欲しく時この神託を呼ぶことができます、それが恐らくそれ自体で固有識別文字を作る方法を「学ぶ」ために蓄積する固有識別文字を使用して。 いつでも、また、選択の候補固有識別文字を後者に供給して、それは検証神託を呼ぶかもしれません。 サーバがこのアキュムレータを受け入れるなら、それは勝ちます。
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 x0、1^c-->R。
M'Raihi, et al. Informational [Page 18] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [18ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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に初期化されて、ブール値の勝利は誤っているのに設定されます。
Game execution - Adversary B is provided with the two following oracles:
ゲーム実行--2つの次の神託を敵Bに提供します:
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
オラクルAuthO()-------------- =ALG(K、C)CはBへのC+1リターンOと等しいです。
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
オラクルVerO(A)-------------- C i=While(i<=C+s--1とWin=FALSE)はALG(K、i)当時のWin=If A=TRUEをします。 i+1C=Else iはBへのi+1Return Winと等しいです。
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)が勝利が上のゲームで本当に用意するという確率であることをさせてください。 これは敵が首尾よくユーザをまねるという確率です。
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.
私たちの目標が検証質問のNo.vの関数がBを作ったのでこの値がどれくらい大きい場合があるか、そして、固有識別文字神託質問のaがBで作った数、およびB.Thisのtがスロットルを設定する方法を私たちに教える実行時間を評価することである、どれ、事実上上限v。
A.4. Security of the Ideal Authentication Algorithm
A.4。 理想的な認証アルゴリズムのセキュリティ
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.
このセクションはHOTP-IDEALの証券分析をまとめます、変換法10^Digitの影響から始まって、次に、異なった可能な攻撃に焦点を合わせて。
A.4.1. From Bits to Digits
A.4.1。 ビットからケタまで
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?
無作為のn-ビット列のダイナミックなオフセットトランケーションは無作為の31ビット列をもたらします。 それがHOTPでするように取られた法m=10^Digitであることの分配はどうなりますか?
M'Raihi, et al. Informational [Page 19] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [19ページ]情報のRFC4226HOTPアルゴリズム2005年12月
The following lemma estimates the biases in the outputs in this case.
以下の補助定理はこの場合出力における偏見を見積もっています。
Lemma 1
-------
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let:
補助定理1------- N>=m>=1が整数であることをさせてください、そして、(q、r)=IntDiv(N、m)をさせてください。 Z_mのzに関しては、以下をさせてください。
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
P_、N、m、(z)はPrと等しいです。[z: xがZ_nで手当たりしだいに選ぶxモッズm=]
Then for any z in Z_{m}
Z_のどんなzのためのその時m
P_{N,m}(z) = (q + 1) / N if 0 <= z < r
q / N if r <= z < m
P_、N、m、(z) = (q+1)/Nは0<であるならr<がz<mと等しいならz<r q/Nと等しいです。
Proof of Lemma 1
----------------
Let the random variable X be uniformly distributed over Z_{N}. Then:
補助定理1の証拠---------------- Z_Nの上に一様に確率変数Xを分配させてください。 その時:
P_{N,m}(z) = Pr [X mod m = z]
P_、N、m、(z)はPrと等しいです。[Xモッズm=z]
= Pr [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= Pr[X<mq]*Pr[Xモッズm=z| X<mq]+Pr[mq<はX<Nと等しい]*Pr[Xモッズ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
= mq/N*1/m+(N--mq)/N*1/(N--mq)は0<であるならz<Nと等しいです--mq0はN--mq<=z<であるならmと等しいです。
= q/N +
r/N * 1 / r if 0 <= z < N - mq
0 if r <= z <= m
= q/N+r/N*1/rは0<であるならz<Nと等しいです--mq0は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ビット列です)、それを6桁数までx取っているモッズm減少させるのは無作為の6桁数をもたらしません。
Rather, x mod m is distributed as shown in the following table:
むしろ、xモッズ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
出力されるようにそれぞれ見えるProbabilityを評価します。---------------------------------------------------------------- 0,1,...^31がおよそ1.00024045/10^6 483648と等しい483647 2148/2…^31がおよそ0.99977478/10^6と等しい999999 2147/2
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
Xが一様にZ_2^31の上に分配されるなら(意味は無作為の31ビット列です)、上記がXモッズ風の10^6の異なった出力のために確率を示しているその時です。 値の第一セットは現れます。
M'Raihi, et al. Informational [Page 20] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [20ページ]情報のRFC4226HOTPアルゴリズム2005年12月
probability slightly greater than 10^-6, the rest with probability slightly less, meaning that the distribution is slightly non-uniform.
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の非常に近くにあります。
A.4.2. Brute Force Attacks
A.4.2。 ブルートフォースアタック
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乱数から成るなら、検証に対して試みを使用するブルートフォースアタックは確率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.
しかしながら、敵は、わずかに良い攻撃を仕掛けるのにLemma1によって予測された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 -------------
提案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
10^Digit m=<2^31であると思って、IntDiv(2^31、m)と等しくさせます(q、r)。 s<=がmであると仮定してください。 ブルートフォースアタック敵のB-bfは、<=rに対して検証神託質問を使用することでHOTPを攻撃します。 この敵は、固有識別文字神託質問を全くしないで、確率で成功します。
Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s
Adv(B-bf)=1--(1--v(q+1)/2^31)^s
which is roughly equal to
どれにおよそ同輩はいますか?
sv * (q+1)/2^31
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
10m=^6で、私たちはq=2,147を得ます。 その場合、検証に対して試みを使用するブルートフォースアタックは確率で成功します。
Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6
Adv(B-bf)はおよそsv sv*2148/2^31=*1.00024045/10^6と等しいです。
M'Raihi, et al. Informational [Page 21] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [21ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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?
根本的な問いは獣の力1より少しも良い攻撃があるかどうかということです。 特に、ブルートフォースアタックは、固有識別文字をよりよく構成する方法を学ぶ試みでユーザによって送られた固有識別文字を集めて、cryptanalyzeにそれらを試みるのを試みませんでした。 これをするのは助けるでしょうか? 全数探索法で与えるより高い成功率でその結果を固有識別文字に築き上げる方法を「学ぶ」何らかの方法がありますか?
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.
以下は、これらの質問の答えがNo.であると言います。 利用するトライ、ユーザの認証試みからの固有識別文字、ブルートフォースアタックのものの上に成功確率がないでしょう--敵がどんな戦略を使用するか、そして、見る、それが観測する認証の数が信じられないほど大きくない限り、これが本当であっても。 これは体系のセキュリティに関する貴重な情報です。
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
提案2------------- 10^Digit m=<2^31であると思って、IntDiv(2^31、m)と等しくさせます(q、r)。 Bが検証神託質問と<=に対して2^cを使用することでHOTP-IDEALを攻撃しているあらゆる敵であることをさせてください--s固有識別文字神託質問。 その時
Adv(B) < = sv * (q+1)/ 2^31
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を見ない敵に依存しています--cが十分大きい限り、ほとんど制限していないユーザによって実行されたs認証。
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
10m=^6で、私たちはq=2,147を得ます。 その場合、Proposition2は、HOTP-IDEALを攻撃して、検証に対して試みをしているどんな敵Bも高々確率で成功すると言います。
Equation 1
----------
sv * 2148/2^31 roughly = sv * 1.00024045/10^6
方程式1---------- sv*2148/2^31はおよそsv*1.00024045/10^6と等しいです。
Meaning, B's success rate is not more than that achieved by the brute force attack.
意味しているビーズ成功率はブルートフォースアタックによって達成されたそれほど多くはありません。
M'Raihi, et al. Informational [Page 22] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [22ページ]情報のRFC4226HOTPアルゴリズム2005年12月
A.5. Security Analysis of HOTP
A.5。 HOTPの証券分析
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のための神託が与えられている敵Aを考えてください: 0、1、^c-->0、1^nと出力結局、しばらく。 私たちは神託がH(K)である敵のどれくらいよく代理をするAのprf-有利な立場がケースを区別するのに指示するように神託が0、1^cから0、1^nの確率関数であるケースからAdv(A)を指示します。
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.
攻撃がtステップのための主要なK.If A下痢の徹底的な検索に基づいていて、TがHの1つの計算を実行する時間を指示するのが可能な1つ、この攻撃からのprf-利点は(t/T)2^kであると判明します。 別の可能な攻撃は誕生日のもの[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 ------------
仮定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はAがほとんどのtの実行時間と大部分でpを神託質問にするあらゆる敵であるならH.Thenの1つの計算を実行する時間を指示します。
Adv(A) <= (t/T)/2^k + p^2/2^n
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神託を質問にする攻撃者はほとんどの(about)2^-80に利点を持っています。
Theorem 1 ---------
定理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,
10^Digit m=<2^31であると思って、IntDiv(2^31、m)と等しくさせます(q、r)。 Bがv検証神託質問を使用することでHOTPを攻撃しているあらゆる敵であることをさせてください。
M'Raihi, et al. Informational [Page 23] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [23ページ]情報のRFC4226HOTPアルゴリズム2005年12月
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
<は2^cと等しいです--s固有識別文字神託質問、および実行時間t。 次に、TにH.If Assumption1の1つの計算を実行するのが本当である時を指示させてください。
Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n
sv*(q+1)/2^31+(t/T)/2^k+(sv+a)^2)Adv(B)<=/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を攻撃している敵の成功率がsv(q+1)/2^nであると言うように、まさしくHOTP-IDEALのように、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ケタの=10^6が出力したケースmでは、これは、認証に対して試みをしている敵が高々Equation1のものである成功率を持つことを意味します。
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^40の認証試みを高々見るほとんどの2^60で実行時間をもっている敵を考えてください。 敵にとって、これらの選択の両方が非常に寛大ですが、私たちは、そのような強敵にさえEquation1によって示されるより多くの成功がないと言っています。(その敵は、これらのリソースを通常持たないでしょう)。
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
(t/t)/2^k+(sv+a)^2)/2^n<がおよそ2^60/2^160+(2^41)^2/2^160と等しい、<=2^-78
which is much smaller than the success probability of Equation 1 and negligible compared to it.
それと比べて、Equation1の成功確率よりはるかに小さくて、取るにたらないです。
M'Raihi, et al. Informational [Page 24] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [24ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Appendix B - SHA-1 Attacks
付録B--SHA-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にあります。
B.1. SHA-1 Status
B.1。 SHA-1状態
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のための衝突は、組x、異なることのyがそのようなものを入力することを意味します。そのh(x)=h(y)。 SHA-1が160ビットを出力するので、誕生日の攻撃は2^での衝突に80のトライアルに当たります。 (トライアルは機能の1つの計算を意味します。) ワング、殷、およびユーが、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は壊れていますか? ほとんどの実用的な目的のために、攻撃を仕掛けるのに必要であるリソースが膨大であるので、私たちは、たぶんそうでないと言うでしょう。 ここに、それの感覚を得る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のばりが、「大きい国家情報代理店は妥当な時間でコンピュータ時間における数100万ドルでこれができました」と言ったと伝えられます。 しかしながら、計算はすべての範囲から脱していたかもしれませんが、そのようなものは政府機関によく資金を供給しました。
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の署名を得るために選ばれたメッセージ攻撃を必要とします。 これは他のものではなく、いくつかの文脈で可能に思えます。 全体的に見て、署名のセキュリティへの影響が重要であることは、明確ではありません。
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.
また、暗号使用者は興奮しています。 しかし、主にこれが重要な理論上のブレークスルーであるので。 攻撃は時間で改善されることができるだけです: したがって、未来にハッシュ関数暗号文解読術でどんな進歩もモニターして、どんな本当に実用的な休み中にも音の移動プランで用意をするのは重要です。
M'Raihi, et al. Informational [Page 25] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [25ページ]情報のRFC4226HOTPアルゴリズム2005年12月
B.2. HMAC-SHA-1 Status
B.2。 HMAC-SHA-1状態
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メッセージを認証するのが必要でありながら、後者に対する最も良い攻撃は1のままで残っています。 なぜですか?
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、SHA-1(K_i、x)がキーK_o、K_iは攻撃者が組xに見つけるK.Supposeから引き出しています、yによってSHA-1(K_i、y)と等しいx)。 (隠されて主要な衝突にこれに電話をしてください。) そして、x(無理難題自体)のMACを入手できるなら、それはyのMACを鍛造できます。 (これらの値は同じです。) しかし、隠されて主要な衝突を見つけるのは攻撃者が隠された主要なK_iを知らないので衝突を見つけるより困難です。 それが持っているかもしれないすべてがToが日付を入れるキー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は、比較的容易にこのハッシュ関数における衝突を見つけることができるので、壊れていると考えられます。 しかし、まだ、些細な2^64時間誕生日1より良いHMAC-MD5に対する攻撃が全くありません。 (MD5は160ではなく128ビットを出力します。) 私たちはHMACのこの強さが再びSHA-1文脈でプレーに入っているのが見えています。
B.3. HOTP Status
B.3。 HOTP状態
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が擬似ランダム機能のように振る舞うのを必要とします。 SHA-1に対する新しい攻撃で擬似ランダム機能としてのHMAC-SHA-1の品質が影響を与えられないので、どちらもこの立証された保証ではありません。
M'Raihi, et al. Informational [Page 26] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [26ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Appendix C - HOTP Algorithm: Reference Implementation
付録C--HOTPアルゴリズム: リファレンスインプリメンテーション
/*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* HOTP one-time password algorithm
*
*/
/**OneTimePasswordAlgorithm.java*OATH Initiative、*HOTPワンタイムパスワードアルゴリズム**/
/* 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.
*/
/*著作権(C)2004、誓い。 All rights reserved。 * * このソフトウェアをコピーして、使用するライセンスはそれであれば与えて、*が*このソフトウェアかこの機能に言及するか、または参照をつけながら「OATH HOTPアルゴリズム」としてすべての材料の中で特定されるということです。 * * また、*が派生している仕事に言及するか、または参照をつけながらすべての材料の中で*を「OATH HOTPアルゴリズムから、派生した」ので、特定されていた状態でそのような作品が*ですが、提供された派生している作品を作って、使用するためにライセンスを与えます。 * * OATH(開いているAuTHentication)とそのメンバーはこの*ソフトウェアの市場性かどんな特定の*目的のためのこのソフトウェアの適合のどちらかに関しても*を全く表現にしません。 * * このソフトウェアに関連するどんな種類とOATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS*ANY WARRANTY OR LIABILITY OF ANY KINDの急行も黙示的な保証*なしでもそれを「そのままで」提供します。 * * この*ドキュメンテーション、そして/または、ソフトウェアのどんな部分のどんなコピーでもこれらの通知を保有しなければなりません。 */
package org.openauthentication.otp;
org.openauthentication.otpをパッケージしてください。
import java.io.IOException; import java.io.File; import java.io.DataInputStream; import java.io.FileInputStream ; import java.lang.reflect.UndeclaredThrowableException;
java.io.IOExceptionを輸入してください。 java.io.Fileを輸入してください。 java.io.DataInputStreamを輸入してください。 java.io.FileInputStreamを輸入してください。 java.lang.reflect.UndeclaredThrowableExceptionを輸入してください。
import java.security.GeneralSecurityException; import java.security.NoSuchAlgorithmException; import java.security.InvalidKeyException;
java.security.GeneralSecurityExceptionを輸入してください。 java.security.NoSuchAlgorithmExceptionを輸入してください。 java.security.InvalidKeyExceptionを輸入してください。
import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec;
javax.crypto.Macを輸入してください。 javax.crypto.spec.SecretKeySpecを輸入してください。
M'Raihi, et al. Informational [Page 27] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [27ページ]情報のRFC4226HOTPアルゴリズム2005年12月
/**
* 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() {}
このクラスがHMAC-SHA-1を提供するために*JCEを使用することで*1回のPassword(OTP)について計算するのに使用される静的な方法を含む/***。 * * @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 };
これらが使用されている//はチェックサムケタについて計算します。 0、2、4、6、8、1、3、5、7、//0 1 2 3 4 5 6 7 8 9個人的な静的な最終的なint[] doubleDigits=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;
}
/***は、クレジットカードアルゴリズムを使用することでチェックサムについて計算します。 * このアルゴリズムには、ケタに隣接してそれがどんなただ一つの*mistypedケタにも検出する利点と*のどんなただ一つの転置もあります。 * * @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) intケタは(doubleDigit)であるなら(int)(num%10)(num/=10)と等しいです。論理演算子doubleDigitが本当に; int合計=0;等しい、ゆったり過ごす(0<ケタ--)、ケタ=doubleDigits[ケタ]; 合計+=ケタ; doubleDigitはdoubleDigitと等しいです;、総int結果=%10(結果>0)結果=10(結果)が結果を返すなら
/**
* This method uses the JCE to provide the HMAC-SHA-1
この方法がHMAC-SHA-1を提供するのにJCEを使用する/***
M'Raihi, et al. Informational [Page 28] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [28ページ]情報のRFC4226HOTPアルゴリズム2005年12月
* 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はHashedメッセージ立証コードを計算します、そして、この場合、SHA1は使用される細切れ肉料理アルゴリズムです。 * * @param keyBytes the bytes to use for the HMAC-SHA-1 key * @param text the message or text to be authenticated. * * @throwsどんなプロバイダーも*HmacSHA1かHMAC-SHA-1のどちらかを*にしないなら、NoSuchAlgorithmExceptionは利用可能なアルゴリズムを読みこなします。 * @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);
// }
}
公共の静的なバイト[]hmac_sha1、(バイト[]keyBytes、バイト[]テキスト) 一投NoSuchAlgorithmException、InvalidKeyException//トライ、Mac hmacSha1; 試みてください、hmacSha1がMac.getInstanceと等しい、(「HmacSHA1")、;、(NoSuchAlgorithmException nsae)を捕らえてください、hmacSha1がMac.getInstanceと等しい、(「HMAC-SHA-1インチ)、;、SecretKeySpec macKeyが新しいSecretKeySpec(「生で」のkeyBytes); hmacSha1.init(macKey); hmacSha1.doFinal(テキスト)を返します; //と等しい、//一投の新しいUndeclaredThrowableException(gseする); (GeneralSecurityException 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};
1、1万100、1000、10000、100000、1000000、10000000、個人的な静的な最終的なint[] DIGITS_POWER // 0 1 2 3 4 5 6 7 8=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
/、***この方法は与えられた*セットのパラメタのためにOTP値を発生させます。 * * @param secret the shared secret * @param movingFactor the counter, time, or other value that * changes on a per use basis. * @param codeDigitsもしあればチェックサムを含む*ではなく、OTPのケタの数 * @param addChecksumそれがチェックサムケタであるなら示す旗
M'Raihi, et al. Informational [Page 29] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [29ページ]情報のRFC4226HOTPアルゴリズム2005年12月
* 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;
}
* OTPに追加するべきです。 * @param truncationOffset*へのMAC結果へのオフセットはトランケーションを始めます。 この値が*からの0の範囲であるなら… 15 そして、ダイナミックな*トランケーションは使用されるでしょう。 * ダイナミックなトランケーションはMACの最後のバイトのベスト4*ビットが始めが相殺されたことを決定するのに使用される*である時です。 * @throwsどんなプロバイダーも*HmacSHA1かHMAC-SHA-1のどちらかを*にしないなら、NoSuchAlgorithmExceptionは利用可能なアルゴリズムを読みこなします。 * @throws秘密が提供したInvalidKeyException*はa有効なHMAC-SHA-1が合わせる*ではありませんでした。 * * @return@link*codeDigitsを含んでいるベース10の中のA数値String、ケタと任意のチェックサム*ケタ、要求されるなら。 */静的な公共のString generateOTP(バイト[]の秘密の、そして、長いmovingFactor、int codeDigits、論理演算子addChecksum、int truncationOffset)はNoSuchAlgorithmExceptionを投げます、InvalidKeyException、//かかっているmovingFactorが(int i=text.length--1; i>=0(i))のために、addChecksum(codeDigits+1)?: バイト[]テキストが新しいバイト[8]と等しいというバイトアレイString結果=intヌル;ケタ=codeDigitsをテキストに評価します。テキスト[i]は(バイト)(movingFactorと0xff)と等しいです; movingFactor>>=8
// compute hmac hash
byte[] hash = hmac_sha1(secret, text);
//はhmac細切れ肉料理バイト[]細切れ肉料理=hmac_sha1(秘密、テキスト)を計算します。
// 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)
/が置いた/は結果int intオフセット=細切れ肉料理[hash.length--1]と0xfにバイトを選択しました。 (0<=truncationOffset)である、(truncationOffset<(hash.length-4))、オフセット=truncationOffset;、intバイナリー=(細切れ肉料理[相殺する]と0x7f)<<24)| ((細切れ肉料理[オフセット+1]と0xff)<<16) | ((細切れ肉料理[オフセット+2]と0xff)<<8)
M'Raihi, et al. Informational [Page 30] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [30ページ]情報のRFC4226HOTPアルゴリズム2005年12月
| (hash[offset + 3] & 0xff);
| (細切れ肉料理[オフセット+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;
}
}
2進のint otp=%DIGITS_POWER[codeDigits]。 (addChecksum) otp=(otp*10)+calcChecksum(otp、codeDigits); 結果はInteger.toString(otp)と等しいです。 (result.length()<ケタ)である、結果が等しい、「0インチ+結果;、結果を返してください、」、。 } }
M'Raihi, et al. Informational [Page 31] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [31ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Appendix D - HOTP Algorithm: Test Values
付録D--HOTPアルゴリズム: 試験値
The following test data uses the ASCII string "12345678901234567890" for the secret:
以下のテストデータは秘密にASCIIストリング「12345678901234567890」を使用します:
Secret = 0x3132333435363738393031323334353637383930
秘密の=0×3132333435363738393031323334353637383930
Table 1 details for each count, the intermediate HMAC value.
中間的HMACは、それぞれのためのテーブル1の詳細が重要であることを評価します。
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
Hexadecimal HMAC-SHA-1(秘密、カウント)0cc93cf18508d94934c64b65d8ba7667fb7cde4b0 1 75a48a19d4cbe100644e8ac1397eea747a2d33ab2 0bacb7fa082fef30782211938bc1c5e70416ff44 3 66c28227d03a2d5529262ff016a1e6ef76557ece4a904c900a64b35909874b33e61c5938a8e15ed1c5a37e783d7b7233c083d4f62926c7a25f238d0316 6bc9cd28561042c83f219324d3c607256c03272ae7a4fb960c0bc06e1eabb804e5b397cdc4b45596fa8 1b3c89f65e6c9e883012052823443f048b4332db9 1637409809a679dc698207310c8c7fc07290d9e5を数えてください。
Table 2 details for each count the truncated values (both in hexadecimal and decimal) and then the HOTP value.
端が欠けている値(16進と小数における)を数えて、次に、それぞれのためのテーブル2の詳細は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
端が欠けているカウント16進10進HOTP 0 4c93cf18 1284755224 755224 1 41397eea1094287082 287082 2 82fef30 137359152 359152 3 66ef7655 1726969429 969429 4 61c5938a1640338314 338314 5 33c083d4 868254676 254676 6 7256c032 1918287922 287922 7 4e5b397 82162583 162583 8 2823443f673399871 399871 9 2679dc69 645520489 520489
M'Raihi, et al. Informational [Page 32] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [32ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Appendix E - Extensions
付録E--拡大
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アルゴリズムにいくつかの増進を取り入れます。 これらは標準のアルゴリズムのお勧めの拡大か一部ではなく、単にカスタマイズされた実現に使用できた変化です。
E.1. Number of Digits
E.1。 ケタの数
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はs=1であるのに、6ケタのコードのための理論上の最適条件であるv/10^7<v/10^6と等しいです。
E.2. Alphanumeric Values
E.2。 英数字値
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.
別のオプションはA-Zと0-9の値を使用することです。 むしろキャラクタの間のどんな混乱も避けるために英数字のアルファベットから取られた32のシンボルの部分集合: 0、O、lと同様にQ、1、および私は非常に同様です、そして、小さい表示のときに同じに見えることができます。
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.
6英数字のHOTPコードのセキュリティがあって、32^6>10^9は提案されたアルゴリズムを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値を表示して、入れるのに使用されるアプリケーションと象徴/インタフェースによって、英数字値の選択はユーザへの割引料金と影響におけるセキュリティを向上させる簡単で効率的な方法であるかもしれません。
M'Raihi, et al. Informational [Page 33] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [33ページ]情報のRFC4226HOTPアルゴリズム2005年12月
E.3. Sequence of HOTP Values
E.3。 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.
デフォルトに従って、1にもかかわらず、セキュリティが、増加する必要であるかどうかに値Lの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.
以下に注意してください。 そして、また、システムが定期的に同期を要求するようにプログラムされるかもしれない、(例えば、毎晩、1週間の2倍など)、この目的を達成するには、L HOTP値の系列を求めてください。
E.4. A Counter-Based Resynchronization Method
E.4。 カウンタベースのResynchronization方法
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) ----------------------------------------------
Resynchronizationのカウンタベースのプロトコル(RCP)----------------------------------------------
The server accepts if the following are all true, where C-server is its own current counter value:
以下がすべて本当であるなら、サーバはC-サーバがそれ自身の現在の対価であるところで受け入れます:
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
1) C-クライアント>=C-サーバ2) C-クライアント--C-サーバ<はs3)と等しいです。 HOTPクライアントが有効なHOTP(K、C-クライアント)であることをチェックしてください。 4) 本当に、サーバがC-クライアント+1にCを設定して、クライアントが認証されるなら
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を「無限に」増加させて、したがって、明らかにセキュリティに影響を与えないでシステムユーザビリティを改良することであることができます。
M'Raihi, et al. Informational [Page 34] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [34ページ]情報のRFC4226HOTPアルゴリズム2005年12月
This resynchronization protocol SHOULD be used whenever the related impact on the client and server applications is deemed acceptable.
この再同期はSHOULDについて議定書の中で述べます。クライアントとサーバ・アプリケーションへの関連する影響が許容できると考えられるときはいつも、使用されてください。
E.5. Data Field
E.5。 データ・フィールド
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.
別のおもしろいオプションはData分野の導入です:(分野は、One-時間Password値を発生させるのに使用されるでしょう)。 Dataが様々なアイデンティティ関連の情報の連結であるかもしれない任意の分野であるHOTP(K、C[データ])、例えば、Dataはアドレスと等しいです。| ピンで止めます。
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.
また、私たちは唯一の感動的な要素かCounterと組み合わせてTimerを使用できました--この場合、例えば、Dataはタイマと等しいです。そこでは、Timerが何らかの要素(8、16、32など)が特定の時間ステップを与えるために割られたUNIX-時間であるかもしれません(グリニッジ標準時の1/1/1970以来の秒)。 One-時間Passwordのためのタイムウィンドウはその時、再同期パラメタが以前定義されるように掛けられた時間ステップと等しいです。 例えば、再同期パラメタのための時間ステップと7として64秒取るなら、私たちは3分間+/-の承認ウィンドウを入手します。
Using a Data field opens for more flexibility in the algorithm implementation, provided that the Data field is clearly specified.
Data分野が明確に指定されれば、Data分野を使用するのはアルゴリズム実装における、より多くの柔軟性のために開きます。
M'Raihi, et al. Informational [Page 35] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [35ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Authors' Addresses
作者のアドレス
David M'Raihi (primary contact for sending comments and questions) VeriSign, Inc. 685 E. Middlefield Road Mountain View, CA 94043 USA
デヴィッドM'Raihi(コメントと質問を送ることに関する一次的接触)ベリサインInc.685E.Middlefield Roadカリフォルニア94043マウンテンビュー(米国)
Phone: 1-650-426-3832 EMail: dmraihi@verisign.com
以下に電話をしてください。 1-650-426-3832 メールしてください: 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部、メールコード0114カリフォルニア大学サンディエゴ校9500ギルマン・ドライブラ・ホーヤ、カリフォルニア 92093、米国
EMail: mihir@cs.ucsd.edu
メール: mihir@cs.ucsd.edu
Frank Hoornaert VASCO Data Security, Inc. Koningin Astridlaan 164 1780 Wemmel, Belgium
1780Wemmel、フランクHoornaertヴァスコデータ機密保護Inc.Koningin Astridlaan164ベルギー
EMail: frh@vasco.com
メール: 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
デヴィッドNaccache Gemplus Innovation34はGuynemer、92447、Issy les Moulineaux、フランス、および情報Security Groupを悔悟します、ロイヤルホロウェイ、ロンドンの大学、エガム、サリーTW20 0EX、イギリス
EMail: david.naccache@gemplus.com, david.naccache@rhul.ac.uk
メール: 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アラジン知識システム株式会社15バイトOved通りテルアビブ(イスラエル)61110
EMail: Ohad.Ranen@ealaddin.com
メール: Ohad.Ranen@ealaddin.com
M'Raihi, et al. Informational [Page 36] RFC 4226 HOTP Algorithm December 2005
M'Raihi、他 [36ページ]情報のRFC4226HOTPアルゴリズム2005年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
M'Raihi, et al. Informational [Page 37]
M'Raihi、他 情報[37ページ]
一覧
スポンサーリンク
