Internet Engineering Task Force (IETF) D. M'Raihi
Request for Comments: 6287 Verisign, Inc.
Category: Informational J. Rydell
ISSN: 2070-1721 Portwise, Inc.
S. Bajaj
Symantec Corp.
S. Machani
Diversinet Corp.
D. Naccache
Ecole Normale Superieure
June 2011
OCRA: OATH Challenge-Response Algorithm
Abstract
抽象
This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH). The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities.
この文書では、オープン認証のためのイニシアティブ（OATH）によって開発されたチャレンジレスポンス認証のためのアルゴリズムを説明します。指定されたメカニズムは、HMACベースのワンタイムパスワード（HOTP）アルゴリズムを活用し、一方向および相互認証、および電子署名機能を提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6287.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6287で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Notation and Terminology ........................................3
3. Algorithm Requirements ..........................................3
4. OCRA Background .................................................4
4.1. HOTP Algorithm .............................................4
5. Definition of OCRA ..............................................5
5.1. DataInput Parameters .......................................5
5.2. CryptoFunction .............................................7
6. The OCRASuite ...................................................8
6.1. Algorithm ..................................................9
6.2. CryptoFunction .............................................9
6.3. DataInput ..................................................9
6.4. OCRASuite Examples ........................................10
7. Algorithm Modes for Authentication .............................10
7.1. One-Way Challenge-Response ................................11
7.2. Mutual Challenge-Response .................................12
7.3. Algorithm Modes for Signature .............................13
7.3.1. Plain Signature ....................................13
7.3.2. Signature with Server Authentication ...............14
8. Security Considerations ........................................16
8.1. Security Analysis of OCRA .................................16
8.2. Implementation Considerations .............................17
9. Conclusion .....................................................18
10. Acknowledgements ..............................................18
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative References ...................................19
Appendix A. Reference Implementation ..............................20
Appendix B. Test Vectors Generation ...............................26
Appendix C. Test Vectors ..........................................33
C.1. One-Way Challenge Response .................................34
C.2. Mutual Challenge-Response ..................................35
C.3. Plain Signature ............................................37
The Initiative for Open Authentication (OATH) [OATH] has identified several use cases and scenarios that require an asynchronous variant to accommodate users who do not want to maintain a synchronized authentication system. A commonly accepted method for this is to use a challenge-response scheme.
オープン認証（OATH）[OATH]のためのイニシアティブは、同期認証システムを維持したくないユーザーに対応するために、非同期バリアントを必要とする複数のユースケースとシナリオを特定しています。このため一般的に受け入れられている方法は、チャレンジ・レスポンス方式を使用することです。
Such a challenge-response mode of authentication is widely adopted in the industry. Several vendors already offer software applications and hardware devices implementing challenge-response -- but each of those uses vendor-specific proprietary algorithms. For the benefits of users there is a need for a standardized challenge-response algorithm that allows multi-sourcing of token purchases and validation systems to facilitate the democratization of strong authentication.
認証のようなチャレンジ・レスポンスモードは、業界で広く採用されています。いくつかのベンダーは、既にチャレンジ・レスポンスを実現するソフトウェアアプリケーションおよびハードウェアデバイスを提供します - しかし、それらのそれぞれは、ベンダー固有の独自のアルゴリズムを使用しています。ユーザーの利益のためにトークンの購入および検証システムのマルチソーシングは、強力な認証の民主化を促進することを可能にする標準化されたチャレンジレスポンスアルゴリズムの必要性があります。
Additionally, this specification describes the means to create symmetric key-based short 'electronic signatures'. Such signatures are variants of challenge-response mode where the data to be signed becomes the challenge or is used to derive the challenge. Note that the term 'electronic signature' and 'signature' are used interchangeably in this document.
また、本明細書では、対称鍵ベースのショート「電子署名」を作成するための手段を記載します。そのような署名は、署名されるべきデータが課題となっ又はチャレンジを導出するために使用されるチャレンジ・レスポンス方式の変異体です。用語「電子署名」と「署名」は本書では互換的に使用されることに留意されたいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section presents the main requirements that drove this algorithm design. A lot of emphasis was placed on flexibility and usability, under the constraints and specificity of the HMAC-based One-Time Password (HOTP) algorithm [RFC4226] and hardware token capabilities.
このセクションでは、このアルゴリズムの設計を運転した主な要件を提示します。重点の多くは、HMACベースのワンタイムパスワード（HOTP）アルゴリズム[RFC4226]とハードウェアトークン機能の制約と特異性の下で、柔軟性と使いやすさの上に置きました。
R1 - The algorithm MUST support challenge-response-based authentication.
R1 - アルゴリズムは、チャレンジ・レスポンスベースの認証をサポートしなければなりません。
R2 - The algorithm MUST be capable of supporting symmetric key-based short electronic signatures. Essentially, this is a variation of challenge-response where the challenge is derived from the data that needs to be signed.
R2 - アルゴリズムは、対称鍵ベースの短い電子署名をサポートすることができなければなりません。本質的に、これは、チャレンジに署名する必要があるデータから導出されたチャレンジ - 応答の変化です。
R3 - The algorithm MUST be capable of supporting server authentication, whereby the user can verify that he/she is talking to a trusted server.
R3は - アルゴリズムは、ユーザが彼/彼女が信頼できるサーバに話していることを確認できる、サーバー認証をサポートすることができなければなりません。
R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building block.
R4 - アルゴリズムが重要なビルディングブロックとしてHOTP [RFC4226]を使用すべきです。
R5 - The length and format of the input challenge SHOULD be configurable.
R5 - 入力チャレンジの長さと形式は設定可能べきです。
R6 - The output length and format of the generated response SHOULD be configurable.
R6 - 生成された応答の出力長さと形式は設定可能べきです。
R7 - The challenge MAY be generated with integrity checking (e.g., parity bits). This will allow tokens with pin pads to perform simple error checking when the user enters the challenge value into a token.
R7 - 課題は、整合性チェック（例えば、パリティビット）を生成することができます。これにより、ユーザーはトークンにチャレンジ値を入力したときにピンパッドとトークンは、簡単なエラーチェックを実行することができます。
R8 - There MUST be a unique secret (key) for each token/soft token that is shared between the token and the authentication server. The keys MUST be randomly generated or derived using a key derivation algorithm.
R8は - トークンと認証サーバとの間で共有されている各トークン/ソフトトークンの一意の秘密（キー）が存在でなければなりません。キーは、ランダムに生成又はキー導出アルゴリズムを用いて導出されなければなりません。
R9 - The algorithm MAY enable additional data attributes such as a timestamp or session information to be included in the computation. These data inputs MAY be used individually or all together.
R9 - アルゴリズムは、計算に含まれるタイムスタンプまたはセッション情報などの追加のデータ属性を可能にすることができます。これらのデータ入力は、個別に、またはすべて一緒に使用することができます。
OATH introduced the HOTP algorithm as a first open, freely available building block towards strengthening authentication for end-users in a variety of applications. One-time passwords are very efficient at solving specific security issues thanks to the dynamic nature of OTP computations.
OATHは、様々な用途にエンドユーザの認証の強化に向けてブロックを構築し、最初のオープンとして自由に利用できるHOTPアルゴリズムを導入します。ワンタイムパスワードは、OTP計算の動的な性質のために、特定のセキュリティ問題のおかげで解決するのに非常に効率的です。
After carefully analyzing different use cases, OATH came to the conclusion that providing for extensions to the HOTP algorithms was important. A very natural extension is to introduce a challenge mode for computing HOTP values based on random questions. Equally beneficial is being able to perform mutual authentication between two parties, or short-signature computation for authenticating transaction to improve the security of e-commerce applications.
慎重に異なるユースケースを分析した後、OATHはHOTPアルゴリズムへの拡張のために提供することが重要だったという結論に達しました。非常に自然な拡張は、ランダムな質問に基づいて、HOTP値を計算するためのチャレンジモードを導入することです。等しく有益な電子商取引アプリケーションのセキュリティを向上させるために、トランザクションを認証するための2つのパーティ、または短い署名計算との間で相互認証を行うことができることです。
The HOTP algorithm, as defined in [RFC4226], is based on an increasing counter value and a static symmetric key known only to the prover and verifier parties.
HOTPアルゴリズムは、[RFC4226]で定義されるように、増加するカウンタ値と、証明者と検証者にのみ知られている静的対称鍵に基づいています。
As a reminder: HOTP(K,C) = Truncate(HMAC-SHA1(K,C))
HOTP（K、C）=切捨て（HMAC-SHA1（K、C））：リマインダーとして
where Truncate represents the function that converts an HMAC-SHA-1 value into an HOTP value.
切り捨ては、HOTP値にHMAC-SHA-1値を変換する関数を表します。
We refer the reader to [RFC4226] for the full description and further details on the rationale and security analysis of HOTP.
私たちは、完全な説明とHOTPの根拠とセキュリティ分析の詳細については[RFC4226]を読者に参照してください。
The present document describes the different variants based on similar constructions as HOTP.
現在のドキュメントはHOTPと同様の構造に基づいて種々の変形を説明します。
The OATH Challenge-Response Algorithm (OCRA) is a generalization of HOTP with variable data inputs not solely based on an incremented counter and secret key values.
OATHチャレンジ・レスポンスアルゴリズム（OCRA）はもっぱらインクリメントカウンタと秘密キーの値に基づいていない変数のデータ入力とHOTPの一般化です。
The definition of OCRA requires a cryptographic function, a key K and a set of DataInput parameters. This section first formally introduces OCRA and then introduces the definitions and default values recommended for all parameters.
OCRAの定義は、暗号化関数、鍵KとDataInput内のパラメータのセットを必要とします。このセクションでは、最初の正式OCRAを紹介し、すべてのパラメータの推奨定義とデフォルト値が導入されました。
In a nutshell, OCRA = CryptoFunction(K, DataInput)
一言で言えば、OCRA = CryptoFunction（K、DataInput内）
where:
どこ：
o K: a shared secret key known to both parties
O K：両当事者に知られている共有秘密鍵
o DataInput: a structure that contains the concatenation of the various input data values defined in details in section 5.1
O DataInput内：セクション5.1で詳細に定義された様々な入力データ値の連結を含む構造
o CryptoFunction: this is the function performing the OCRA computation from the secret key K and the DataInput material;
O CryptoFunction：これは秘密鍵KとDataInput内の材料からOCRA演算を行う関数です。
CryptoFunction is described in details in Section 5.2
CryptoFunctionは、5.2節で詳細に記述されています
This structure is the concatenation over byte array of the OCRASuite value as defined in section 6 with the different parameters used in the computation, save for the secret key K.
計算に使用される異なるパラメータでセクション6で定義されるように、この構造は、秘密鍵Kのために保存し、OCRASuite値のバイト配列上連結され
DataInput = {OCRASuite | 00 | C | Q | P | S | T} where:
DataInput内= {OCRASuite | 00 | C | Q | P | S | T}：
o OCRASuite is a value representing the suite of operations to compute an OCRA response
O OCRASuiteはOCRA応答を計算するための操作のスイートを表す値であります
o 00 is a byte value used as a separator o C is an unsigned 8-byte counter value processed high-order bit first, and MUST be synchronized between all parties; It loops around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts over at "{Hex}0". Note that 'C' is optional for all OCRA modes described in this document.
O 00は、C、Oセパレータは第一上位ビットを処理し、すべての当事者の間で同期されなければならない、符号なし8バイトのカウンタ値であるとして使用されるバイト値です。これは、「{}ヘキサFFFFFFFFFFFFFFFF」に「{}ヘキサ0」からの周りにループし、「{}ヘキサ0」でオーバー開始します。 「C」は、この文書に記載されているすべてのOCRAモードのオプションであることに注意してください。
o Q, mandatory, is a 128-byte list of (concatenated) challenge question(s) generated by the parties; if Q is less than 128 bytes, then it should be padded with zeroes to the right
O Qは、必須、当事者によって生成された（連結）チャレンジ質問（複数可）の128バイトのリストです。 Qが128バイト未満であれば、それは右に0でパディングされなければなりません
o P is a hash (SHA-1 [RFC3174], SHA-256 and SHA-512 [SHA2] are supported) value of PIN/password that is known to all parties during the execution of the algorithm; the length of P will depend on the hash function that is used
O Pがハッシュである（SHA-1 [RFC3174]、SHA-256およびSHA-512 [SHA2]サポートされている）アルゴリズムの実行中にすべての関係者には知られているPIN /パスワードの値。 Pの長さは、使用されるハッシュ関数に依存するであろう
o S is a UTF-8 [RFC3629] encoded string of length up to 512 bytes that contains information about the current session; the length of S is defined in the OCRASuite string
O Sは、現在のセッションについての情報を含む512バイトの長さまでのUTF-8 [RFC3629]エンコードされた文字列です。 Sの長さはOCRASuite文字列で定義されています
o T is an 8-byte unsigned integer in big-endian order (i.e., network byte order) representing the number of time-steps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970 [UT]. More specifically, if the OCRA computation includes a timestamp T, you should first convert your current local time to UTC time; you can then derive the UTC time in the proper format (i.e., seconds, minutes, hours, or days elapsed from epoch time); the size of the time-step is specified in the OCRASuite string as described in Section 6.3
O Tは、1月1日の深夜UTC以来の（指定した粒度に応じて、秒、分、時間、または日）時間ステップの数を表すビッグエンディアン順（すなわち、ネットワークバイト順）で8バイトの符号なし整数です1970 [UT]。 OCRAの計算は、タイムスタンプTが含まれている場合は具体的には、最初にUTC時刻に現在のローカル時間に変換する必要があります。あなたがして（すなわち、秒、分、時間、またはエポック時刻からの経過日数）適切な形式でUTC時刻を導出することができます。セクション6.3で説明したように、時間ステップのサイズはOCRASuite文字列で指定されています
When computing a response, the concatenation order is always the following:
応答を計算すると、連結順序は常に以下のとおりであります：
C |
C |
OTHER-PARTY-GENERATED-CHALLENGE-QUESTION |
OTHER-PARTY-GENERATED-CHALLENGE-QUESTION |
YOUR-GENERATED-CHALLENGE-QUESTION |
YOUR-GENERATED-CHALLENGE-QUESTION |
P| S | T
P | S | T
If a value is empty (i.e., a certain input is not used in the computation) then the value is simply not represented in the string.
値が空の場合、値は単に文字列で表現されていない（すなわち、特定の入力は、計算に使用されていません）。
The counter on the token or client MUST be incremented every time a new computation is requested by the user. The server's counter value MUST only be incremented after a successful OCRA authentication.
トークンまたはクライアント上のカウンタは、新たな計算は、ユーザによって要求されるたびに増加しなければなりません。サーバのカウンタ値は唯一の成功OCRAの認証後に増加しなければなりません。
The default CryptoFunction is HOTP-SHA1-6, i.e., the default mode of computation for OCRA is HOTP with the default 6-digit dynamic truncation and a combination of DataInput values as the message to compute the HMAC-SHA1 digest.
デフォルトCryptoFunctionはHOTP-SHA1-6である、すなわち、OCRAの計算のデフォルトモードはデフォルト6桁のダイナミック切り捨てとHMAC-SHA1ダイジェストを計算するためのメッセージとしてDataInput内の値の組み合わせとHOTPあります。
We denote t as the length in decimal digits of the truncation output. For instance, if t = 6, then the output of the truncation is a 6-digit (decimal) value.
我々は切り捨て出力の桁の長さとしてトンを示します。 tが6 =あれば、例えば、次に切り捨ての出力は、6桁（10進数）の値です。
We define the HOTP family of functions as an extension to HOTP:
私たちは、HOTPへの拡張としての機能のHOTPファミリを定義します。
1. HOTP-H-t: these are the different possible truncated versions of HOTP, using the dynamic truncation method for extracting an HOTP value from the HMAC output
1. HOTP-H-T：これらは、HMAC出力からHOTP値を抽出するための動的トランケーション方法を用いて、HOTPの異なる可能な切断型であります
2. We will denote HOTP-H-t as the realization of an HOTP function that uses an HMAC function with the hash function H, and the dynamic truncation as described in [RFC4226] to extract a t-digit value
T桁の値を抽出するために、[RFC4226]に記載されているように2我々は、ハッシュ関数Hを用いてHMAC関数を使用HOTP機能の実現、及び動的切り捨てとしてHOTP-H-Tを示します
3. t=0 means that no truncation is performed and the full HMAC value is used for authentication purposes
3. T = 0は切り捨てが行われず、フルHMAC値が認証のために使用されることを意味します
We list the following preferred modes of computation, where * denotes the default CryptoFunction:
私たちは、*は、デフォルトのCryptoFunctionを示し、計算、以下の好ましいモードをリスト：
o HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC and a dynamic truncation to a 4-digit value; this mode is not recommended in the general case, but it can be useful when a very short authentication code is needed by an application
O HOTP-SHA1-4：HMACのハッシュ関数と4桁の値に動的切り捨てとしてSHA-1を有するHOTP。このモードは、一般的なケースで推奨されていませんが、非常に短い認証コードがアプリケーションによって必要とされるとき、それは便利です
o HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC and a dynamic truncation to a 6-digit value
O HOTP-SHA1-6：HMACのハッシュ関数と6桁の値に動的切り捨てとしてSHA-1を有するHOTP
o HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC and a dynamic truncation to an 8-digit value
O HOTP-SHA1-8：HMACのハッシュ関数と8桁の値に動的切り捨てとしてSHA-1を有するHOTP
o HOTP-SHA256-6: HOTP with SHA-256 as the hash function for HMAC and a dynamic truncation to a 6-digit value
O HOTP-SHA256-6：HMACのハッシュ関数と6桁の値に動的切り捨てとしてSHA-256とHOTP
o HOTP-SHA512-6: HOTP with SHA-512 as the hash function for HMAC and a dynamic truncation to a 6-digit value
O HOTP-SHA512-6：HMACのハッシュ関数と6桁の値に動的切り捨てとしてSHA-512とHOTP
This table summarizes all possible values for the CryptoFunction:
このテーブルには、CryptoFunctionのためのすべての可能な値をまとめたものです。
+---------------+--------------------+-------------------------+
| Name | HMAC Function Used | Size of Truncation (t) |
+---------------+--------------------+-------------------------+
| HOTP-SHA1-t | HMAC-SHA1 | 0 (no truncation), 4-10 |
| HOTP-SHA256-t | HMAC-SHA256 | 0 (no truncation), 4-10 |
| HOTP-SHA512-t | HMAC-SHA512 | 0 (no truncation), 4-10 |
+---------------+--------------------+-------------------------+
Table 1: CryptoFunction Table
表1：CryptoFunction表
An OCRASuite value is a text string that captures one mode of operation for OCRA, completely specifying the various options for that computation. An OCRASuite value is represented as follows:
OCRASuite値は、完全にその計算のための様々なオプションを指定して、OCRAための動作の一つのモードを捕捉するテキスト文字列です。次のようにOCRASuite値が表現されます。
<Algorithm>:<CryptoFunction>:<DataInput>
<アルゴリズム>：<CryptoFunction>：<DataInput内>
The OCRASuite value is the concatenation of three sub-components that are described below. Some example OCRASuite strings are described in Section 6.4.
OCRASuite値は、以下に説明される3つのサブコンポーネントの連結です。いくつかの例OCRASuite文字列は6.4節で説明されています。
The client and server need to agree on one or two values of OCRASuite. These values may be agreed upon at the time of token provisioning or, for more sophisticated client-server interactions, these values may be negotiated for every transaction.
クライアントとサーバは、OCRASuiteの一つまたは二つの値に同意する必要があります。これらの値は、トークンのプロビジョニング時に合意することができるか、より洗練されたクライアント - サーバー間の相互作用のために、これらの値は、すべてのトランザクションのために交渉することができます。
The provisioning of OCRA keys and related metadata such as OCRASuite is out of scope for this document. [RFC6030] specifies one key container specification that facilitates provisioning of such data between the client and the server.
例えばOCRASuiteとしてOCRAキーと関連するメタデータのプロビジョニングは、この文書の範囲外です。 [RFC6030]は、クライアントとサーバの間でこのようなデータのプロビジョニングを容易に一つのキーコンテナの仕様を指定します。
Note that for Mutual Challenge-Response or Signature with Server Authentication modes, the client and server will need to agree on two values of OCRASuite -- one for server computation and another for client computation.
サーバー計算用とクライアントの計算のための別の - サーバー認証モードとの相互のチャレンジ・レスポンスや署名のために、クライアントとサーバがOCRASuiteの二つの値に同意する必要があることに注意してください。
Description: Indicates the version of OCRA.
説明：OCRAのバージョンを示します。
Values: OCRA-v where v represents the version number (e.g., 1, 2). This document specifies version 1 of OCRA.
値：OCRA-V vはバージョン番号を表す（例えば、1、2）。このドキュメントでは、OCRAのバージョン1を指定します。
Description: Indicates the function used to compute OCRA values
説明：OCRA値を計算するために使用される機能を示します
Values: Permitted values are described in Section 5.2.
値：許可された値は、5.2節で説明されています。
Description: This component of the OCRASuite string captures the list of valid inputs for that computation; [] indicates a value is optional:
説明：OCRASuite文字列のこのコンポーネントは、その計算のための有効な入力のリストを取り込み、 []の値がオプションであることを示します。
[C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation
[C] | QFxx | [PH | Snnn | TG]：チャレンジ・レスポンスの計算
[C] | QFxx | [PH | TG] : Plain Signature computation
[C] | QFxx | [PH | TG]：プレーン署名計算
Each input that is used for the computation is represented by a single letter (except Q), and they are separated by a hyphen.
計算のために使用される各入力は、（Q除く）単一文字で表され、それらはハイフンによって分離されています。
The input for challenge is further qualified by the formats supported by the client for challenge question(s). Supported values can be:
挑戦のための入力は、チャレンジ質問（複数可）のために、クライアントによってサポートされる形式によってさらに修飾されています。サポートされる値は指定できます
+------------------+-------------------+
| Format (F) | Up to Length (xx) |
+------------------+-------------------+
| A (alphanumeric) | 04-64 |
| N (numeric) | 04-64 |
| H (hexadecimal) | 04-64 |
+------------------+-------------------+
Table 2: Challenge Format Table
表2：チャレンジフォーマット表
The default challenge format is N08, numeric and up to 8 digits.
デフォルトの挑戦フォーマットはN08、数値と8桁までです。
The input for P is further qualified by the hash function used for the PIN/password. Supported values for hash function can be:
Pの入力は、PIN /パスワードに使用されるハッシュ関数によってさらに修飾されます。ハッシュ関数でサポートされる値は、ことができます：
Hash function (H) - SHA1, SHA256, SHA512.
ハッシュ関数（H） - SHA1、SHA256、SHA512。
The default hash function for P is SHA1.
Pのデフォルトのハッシュ関数はSHA1です。
The input for S is further qualified by the length of the session data in bytes. The client and server could agree to any length but the typical values are:
Sの入力は、バイト単位でのセッションデータの長さによってさらに修飾されます。クライアントとサーバーは、任意の長さに同意でしたが、典型的な値は次のとおりです。
Length (nnn) - 064, 128, 256, and 512.
長さ（NNN） - 064、128、256、および512。
The default length is 064 bytes.
デフォルトの長さは064バイトです。
The input for timestamps is further qualified by G, size of the time-step. G can be specified in number of seconds, minutes, or hours:
タイムスタンプのための入力はさらにG、タイムステップの大きさによって修飾されます。 Gは、秒、分、または時間数で指定することができます。
+--------------------+------------------------------+
| Time-Step Size (G) | Examples |
+--------------------+------------------------------+
| [1-59]S | number of seconds, e.g., 20S |
| [1-59]M | number of minutes, e.g., 5M |
| [0-48]H | number of hours, e.g., 24H |
+--------------------+------------------------------+
Table 3: Time-step Size Table
表3：時間ステップサイズ表
Default value for G is 1M, i.e., time-step size is one minute and the T represents the number of minutes since epoch time [UT].
Gのデフォルト値、すなわち、時間ステップサイズは1分であり、Tは、エポック時間[UT]からの分数を表し、1Mです。
Here are some examples of OCRASuite strings:
ここでOCRASuite文字列のいくつかの例は以下のとおりです。
o "OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1" means version 1 of OCRA with HMAC-SHA512 function, truncated to an 8-digit value, using the counter, a random challenge, and a SHA1 digest of the PIN/password as parameters. It also indicates that the client supports only numeric challenge up to 8 digits in length
O "OCRA-1：HOTP-SHA512-8：C-QN08-PSHA1" はカウンタ、ランダムチャレンジとのSHA1ダイジェストを使用して、8桁の値に切り捨てられたHMAC-SHA512機能とOCRAのバージョン1を意味しますパラメータとしてPIN /パスワード。また、クライアントの長さは8桁までの数字のみの挑戦をサポートしていることを示し
o "OCRA-1:HOTP-SHA256-6:QA10-T1M" means version 1 of OCRA with HMAC-SHA256 function, truncated to a 6-digit value, using a random alphanumeric challenge up to 10 characters in length and a timestamp in number of minutes since epoch time
O「OCRA-1：HOTP-SHA256-6：QA10-T1Mは」10個の長さの文字とのタイムスタンプまでのランダムな英数字のチャレンジを使用して、6桁の値に切り捨てられたHMAC-SHA256機能とOCRAのバージョン1を意味しますエポックタイムからの分数
o "OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of OCRA with HMAC-SHA1 function, truncated to a 4-digit value, using a random hexadecimal challenge up to 8 nibbles and a session value of 512 bytes
O「OCRA-1：HOTP-SHA1-4：QH8-S512」は8つのニブル512のセッションの値までランダム進チャレンジを使用して、4桁の値に切り捨てられたHMAC-SHA1機能付きOCRAのバージョン1を意味しますバイト
This section describes the typical modes in which the above defined computation can be used for authentication.
このセクションでは、上記で定義された計算は、認証のために使用することができる典型的な態様を説明しています。
A challenge-response is a security mechanism in which the verifier presents a question (challenge) to the prover, who must provide a valid answer (response) to be authenticated.
チャレンジ・レスポンスは、検証が認証されるべき有効な回答（応答）を提供しなければならない証明に質問（チャレンジ）を提示しているセキュリティ・メカニズムです。
To use this algorithm for a one-way challenge-response, the verifier will communicate a challenge value (typically randomly generated) to the prover. The prover will use the challenge in the computation as described above. The prover then communicates the response to the verifier to authenticate.
一方向のチャレンジ - 応答のためのこのアルゴリズムを使用するには、検証者が証明者に（典型的にはランダムに生成された）チャレンジ値を通信します。上記のように証明者が計算に挑戦を使用します。証明は、認証するための検証への応答を通信します。
Therefore in this mode, the typical data inputs will be:
したがって、このモードでは、典型的なデータ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
Q - Challenge question, mandatory, supplied by the verifier.
Q - 検証により供給された必須の挑戦の質問、。
P - Hashed version of PIN/password, optional.
P - PIN /パスワードのハッシュ化されたバージョン、オプション。
S - Session information, optional.
S - セッション情報、オプション。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
The diagram below shows the message exchange between the client (prover) and the server (verifier) to complete a one-way challenge-response authentication.
以下の図は、一方向チャレンジレスポンス認証を完了するためにクライアント（証明）とサーバ（検証者）との間のメッセージ交換を示しています。
It is assumed that the client and server have a pre-shared key K that is used for the computation.
クライアントとサーバーが計算に使用される事前共有鍵Kを持っていることを想定しています。
CLIENT SERVER
(PROVER) VERIFIER)
| |
| Verifier sends challenge to prover |
| Challenge = Q |
|<---------------------------------------|
| |
| Prover Computes Response |
| R = OCRA(K, {[C] | Q | [P | S | T]}) |
| Prover sends Response = R |
|--------------------------------------->|
| |
| Verifier Validates Response |
| If Response is valid, Server sends OK |
| If Response is not, Server sends NOK |
|<---------------------------------------|
| |
Mutual challenge-response is a variation of one-way challenge-response where both the client and server mutually authenticate each other.
相互チャレンジ・レスポンスは、クライアントとサーバーの両方が相互に認証一方向のチャレンジレスポンスの変化です。
To use this algorithm, the client will first send a random client-challenge to the server. The server computes the server-response and sends it to the client along with a server-challenge.
このアルゴリズムを使用するには、クライアントが最初のサーバにランダムクライアントチャレンジを送信します。サーバーは、サーバーの応答を計算し、サーバーチャレンジと一緒にクライアントに送信します。
The client will first verify the server-response to be assured that it is talking to a valid server. It will then compute the client-response and send it to the server to authenticate. The server verifies the client-response to complete the two-way authentication process.
クライアントは、まず、それが有効なサーバーに話していることを保証するサーバ応答を検証します。その後、クライアントの応答を計算し、認証するためにサーバーに送信します。サーバーは双方向の認証プロセスを完了するために、クライアントの応答を検証します。
In this mode there are two computations: client-response and server-response. There are two separate challenge questions, generated by both parties. We denote these challenge questions Q1 and Q2.
クライアント応答およびサーバーの応答：このモードでは2回の計算があります。両当事者によって生成された2つの別々のチャレンジ質問があります。我々は、これらのチャレンジ質問Q1とQ2を示します。
Typical data inputs for server-response computation will be:
サーバー応答計算のための典型的なデータ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
QC - Challenge question, mandatory, supplied by the client.
QC - クライアントが供給する義務チャレンジ質問、。
QS - Challenge question, mandatory, supplied by the server.
QS - サーバーによって提供される必須チャレンジ質問、。
S - Session information, optional.
S - セッション情報、オプション。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
Typical data inputs for client-response computation will be:
クライアント応答の計算のための典型的なデータ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
QS - Challenge question, mandatory, supplied by the server.
QS - サーバーによって提供される必須チャレンジ質問、。
QC - Challenge question, mandatory, supplied by the client.
QC - クライアントが供給する義務チャレンジ質問、。
P - Hashed version of PIN/password, optional.
P - PIN /パスワードのハッシュ化されたバージョン、オプション。
S - Session information, optional.
S - セッション情報、オプション。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
The following diagram shows the messages that are exchanged between the client and the server to complete a two-way mutual challenge-response authentication.
次の図は、双方向の相互チャレンジレスポンス認証を完了するために、クライアントとサーバ間で交換されるメッセージを示しています。
It is assumed that the client and server have a pre-shared key K (or pair of keys if using dual-key mode of computation) that is used for the computation.
クライアントとサーバが計算に使用される（計算のデュアルキーモードを使用する場合のキーまたは対）事前共有鍵Kを有すると仮定する。
CLIENT SERVER
(PROVER) (VERIFIER)
| |
| 1. Client sends client-challenge |
| QC = Client-challenge |
|------------------------------------------------->|
| |
| 2. Server computes server-response |
| and sends server-challenge |
| RS = OCRA(K, [C] | QC | QS | [S | T]) |
| QS = Server-challenge |
| Response = RS, QS |
|<-------------------------------------------------|
| |
| 3. Client verifies server-response |
| and computes client-response |
| OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP |
| RC = OCRA(K, [C] | QS | QC | [P | S | T]) |
| Response = RC |
|------------------------------------------------->|
| |
| 4. Server verifies client-response |
| OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP |
| Response = OK |
|<-------------------------------------------------|
| |
In this section we describe the typical modes in which the above defined computation can be used for electronic signatures.
このセクションでは、上記で定義された計算は、電子署名のために使用することができる典型的な態様を記載します。
To use this algorithm in plain signature mode, the server will communicate a signature-challenge value to the client (signer). The signature-challenge is either the data to be signed or derived from the data to be signed using a hash function, for example.
平野署名モードでこのアルゴリズムを使用するには、サーバはクライアント（署名者）に署名チャレンジ値を通信します。署名の課題は、データは署名または、例えば、ハッシュ関数を使用して署名されるべきデータに由来するとされますか。
The client will use the signature-challenge in the computation as described above. The client then communicates the signature value (response) to the server to authenticate.
前述したように、クライアントは、計算に署名チャレンジを使用します。その後、クライアントは、認証するためにサーバに署名値（応答）を伝達します。
Therefore in this mode, the data inputs will be:
したがって、このモードでは、データ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
QS - Signature-challenge, mandatory, supplied by the server.
QS - 署名 - 挑戦、必須、サーバーによって提供されます。
P - Hashed version of PIN/password, optional.
P - PIN /パスワードのハッシュ化されたバージョン、オプション。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
The picture below shows the messages that are exchanged between the client (prover) and the server (verifier) to complete a plain signature operation.
下の写真は、プレーン署名操作を完了するためにクライアント（証明）とサーバ（検証者）間で交換されるメッセージを示しています。
It is assumed that the client and server have a pre-shared key K that is used for the computation.
クライアントとサーバーが計算に使用される事前共有鍵Kを持っていることを想定しています。
CLIENT SERVER
(PROVER) (VERIFIER)
| |
| Verifier sends signature-challenge |
| Challenge = QS |
|<------------------------------------------|
| |
| Client Computes Response |
| SIGN = OCRA(K, [C] | QS | [P | T]) |
| Response = SIGN |
|------------------------------------------>|
| |
| Verifier Validates Response |
| Response = OK |
|<------------------------------------------|
| |
This mode is a variation of the plain signature mode where the client can first authenticate the server before generating a electronic signature.
このモードでは、クライアントが最初に電子署名を生成する前に、サーバーを認証することができ、プレーン署名モードのバリエーションです。
To use this algorithm, the client will first send a random client-challenge to the server. The server computes the server-response and sends it to the client along with a signature-challenge.
このアルゴリズムを使用するには、クライアントが最初のサーバにランダムクライアントチャレンジを送信します。サーバーは、サーバーの応答を計算し、署名チャレンジと一緒にクライアントに送信します。
The client will first verify the server-response to authenticate that it is talking to a valid server. It will then compute the signature and send it to the server.
クライアントは、まず、それが有効なサーバーに話していることを認証するために、サーバーの応答を確認します。その後、署名を計算し、それをサーバに送信します。
In this mode there are two computations: client-signature and server-response.
クライアント署名とサーバーの応答：このモードでは2回の計算があります。
Typical data inputs for server-response computation will be:
サーバー応答計算のための典型的なデータ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
QC - Challenge question, mandatory, supplied by the client.
QC - クライアントが供給する義務チャレンジ質問、。
QS - Signature-challenge, mandatory, supplied by the server.
QS - 署名 - 挑戦、必須、サーバーによって提供されます。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
Typical data inputs for client-signature computation will be:
クライアント署名の計算のための典型的なデータ入力は次のようになります。
C - Counter, optional.
C - カウンター、オプション。
QC - Challenge question, mandatory, supplied by the client.
QC - クライアントが供給する義務チャレンジ質問、。
QS - Signature-challenge, mandatory, supplied by the server.
QS - 署名 - 挑戦、必須、サーバーによって提供されます。
P - Hashed version of PIN/password, optional.
P - PIN /パスワードのハッシュ化されたバージョン、オプション。
T - Timestamp, optional.
T - タイムスタンプ、オプション。
The diagram below shows the messages that are exchanged between the client and the server to complete a signature with server authentication transaction.
下の図は、サーバーの認証トランザクションと署名を完了するために、クライアントとサーバ間で交換されるメッセージを示しています。
It is assumed that the client and server have a pre-shared key K (or pair of keys if using dual-key mode of computation) that is used for the computation.
クライアントとサーバが計算に使用される（計算のデュアルキーモードを使用する場合のキーまたは対）事前共有鍵Kを有すると仮定する。
CLIENT SERVER
(PROVER) VERIFIER)
| |
| 1. Client sends client-challenge |
| QC = Client-challenge |
|-------------------------------------------------->|
| |
| 2. Server computes server-response |
| and sends signature-challenge |
| RS = OCRA(K, [C] | QC | QS | [T]) |
| QS = signature-challenge |
| Response = RS, QS |
|<--------------------------------------------------|
| |
| 3. Client verifies server-response |
| and computes signature |
| OCRA(K, [C] | QC | QS | [T]) != RS -> STOP |
| SIGN = OCRA( K, [C] | QS | QC | [P | T]) |
| Response = SIGN |
|-------------------------------------------------->|
| |
| 4. Server verifies Signature |
| OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP |
| Response = OK |
|<--------------------------------------------------|
| |
Any algorithm is only as secure as the application and the authentication protocols that implement it. Therefore, this section discusses the critical security requirements that our choice of algorithm imposes on the authentication protocol and validation software.
任意のアルゴリズムを適用し、それを実装する認証プロトコルと同じくらい安全です。したがって、このセクションでは、アルゴリズムの私達の選択は、認証プロトコルと検証ソフトウェアに課す重要なセキュリティ要件について説明します。
The security and strength of this algorithm depend on the properties of the underlying building block HOTP, which is a construction based on HMAC [RFC2104] using SHA-1 [RFC3174] (or SHA-256 or SHA-512 [SHA2]) as the hash function.
このアルゴリズムのセキュリティ強度がHMACとしてSHA-1 [RFC3174]（またはSHA-256やSHA-512 [SHA2]）を使用して、[RFC2104]に基づいて構築され、基礎となるビルディングブロックHOTPの特性に依存しますハッシュ関数。
The conclusion of the security analysis detailed in [RFC4226] is that, for all practical purposes, the outputs of the dynamic truncation on distinct counter inputs are uniformly and independently distributed strings.
[RFC4226]に詳細なセキュリティ解析の結論は、すべての実用的な目的のために、別個のカウンタ入力に動的トランケーションの出力が一様にかつ独立して文字列を分散している、ということです。
The analysis demonstrates that the best possible attack against the HOTP function is the brute force attack.
分析は、HOTP機能に対する最善の攻撃はブルートフォース攻撃であることを示しています。
IC1 - In the authentication mode, the client 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 Response value for authentication purpose (two-factor authentication). Alternatively, instead of sending something you know to the server, the client may use a hash of the password or PIN code in the computation itself, thus implicitly enabling two-factor authentication.
IC1 - あなたが知っている何か（パスワードなどの秘密のコードなどのフレーズ、PINコードを、合格）とあなたが持っている何か（トークン）の認証モードでは、クライアントは、二要素認証をサポートしなければならない、すなわち、通信および検証。シークレットコードは、ユーザーに知られており、通常、認証目的（二要素認証）の応答値が入力されます。また、代わりにサーバーにあなたが知っている何かを送信すると、クライアントは、このように暗黙のうちに二要素認証を有効にする、計算自体にパスワードのハッシュまたはPINコードを使用することができます。
IC2 - Keys SHOULD be of the length of the CryptoFunction output to facilitate interoperability.
IC2 - キーは相互運用性を促進するためにCryptoFunction出力の長さであるべきです。
IC3 - Keys SHOULD be chosen at random or using a cryptographically strong pseudo-random generator properly seeded with a random value. We RECOMMEND following the recommendations in [RFC4086] for all pseudo-random and random generations. The pseudo-random numbers used for generating the keys SHOULD successfully pass the randomness test specified in [CN].
IC3は、 - キーは、ランダムに選択されたか、正しくランダム値を播種暗号的に強い疑似乱数発生器を使用する必要があります。我々は、すべての擬似ランダムおよびランダム世代のために[RFC4086]の推奨事項に従うことを推奨します。キーを生成するために使用される擬似乱数が正常[CN]で指定されたランダム性試験に合格すべきです。
IC4 - Challenge questions SHOULD be 20-byte values and MUST be at least t-byte values where t stands for the digit-length of the OCRA truncation output.
IC4 - チャレンジ質問は、20バイト値であるべきであり、そしてtはOCRA切り捨て出力の桁の長さを表し、少なくともTバイトの値でなければなりません。
IC5 - On the client side, the keys SHOULD be embedded in a tamper-resistant device or securely implemented in a software application. Additionally, by embedding the keys in a hardware device, you also have the advantage of improving the flexibility (mobility) of the authentication system.
IC5は、 - クライアント側では、鍵は耐タンパデバイス内に埋め込まするか安全ソフトウェアアプリケーションで実現します。また、ハードウェアデバイスに鍵を埋め込むことによって、あなたはまた、認証システムの柔軟性（移動性）を改善するという利点を持っています。
IC6 - All the communications SHOULD take place over a secure channel, e.g., SSL/TLS [RFC5246], IPsec connections.
IC6 - すべての通信は、例えば、SSL / TLS [RFC5246]、安全なチャネルを介してIPsec接続を行うべきです。
IC7 - OCRA, when used in mutual authentication mode or in signature with server authentication mode, MAY use dual-key mode -- i.e., there are two keys that are shared between the client and the server. One shared key is used to generate the server response on the server side and to verify it on the client side. The other key is used to create the response or signature on the client side and to verify it on the server side.
IC7 - OCRAは、相互認証モードまたはサーバー認証モードに署名に使用される場合、デュアルモードキーを使用するかもしれ - すなわち、クライアントとサーバの間で共有される2つのキーがあります。一つの共有キーは、サーバー側のサーバの応答を生成し、クライアント側でそれを確認するために使用されます。他のキーは、クライアント側の応答または署名を作成すると、サーバー側でそれを確認するために使用されます。
IC8 - We recommend that implementations MAY use the session information, S, as an additional input in the computation. For example, S could be the session identifier from the TLS session.
IC8は - 私たちは、実装は、計算で追加の入力として、セッション情報、Sを使用するかもしれないことをお勧めします。例えば、Sは、TLSセッションからセッション識別子である可能性があります。
This will mitigate against certain types of man-in-the-middle attacks. However, this will introduce the additional dependency that first of all the prover needs to have access to the session identifier to compute the response and the verifier will need access to the session identifier to verify the response. [RFC5056] contains a relevant discussion of using Channel Bindings to Secure Channels.
これは、man-in-the-middle攻撃の特定の種類を軽減します。しかし、これは最初にすべての証明の応答と応答を確認するために、セッション識別子へのアクセスを必要とする検証を計算するためにセッション識別子へのアクセス権を持っている必要があり、追加の依存関係を紹介します。 [RFC5056]はチャンネルを確保するためにチャネルバインディングを使用しての関連する議論が含まれています。
IC9 - In the signature mode, whenever the counter or time (defined as optional elements) are not used in the computation, there might be a risk of replay attack and the implementers should carefully consider this issue in the light of their specific application requirements and security guidelines. The server SHOULD also provide whenever possible a mean for the client (if able) to verify the validity of the signature challenge.
IC9 - （オプションの要素として定義される）カウンターや時間が計算に使用されていない時はいつでも署名モードでは、リプレイ攻撃や実装のリスクがあるかもしれませんが、慎重に彼らの特定のアプリケーションの要件に照らして、この問題を検討すべきであるとセキュリティガイドライン。クライアントの平均は、（可能ならば）署名挑戦の妥当性を検証するために、可能な限りサーバーも提供する必要があります。
IC10 - We also RECOMMEND storing the keys securely in the validation system, and more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the key is decrypted when needed to verify an OCRA response, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The key store MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database. Particularly, access to the key material should be limited to programs and processes required by the validation system only.
OCRAの応答を確認するために必要な場合、例えば、鍵が解読され、再： - IC10はまた、耐タンパ性ハードウェア暗号化を使用して暗号化し、必要な場合にのみ、それらを露光、より具体的に検証システムに安全に鍵を格納する勧め、及び短時間のRAMで露出を制限するために、すぐに-encrypted。キーストアは、検証システムと秘密データベース上で可能な直接攻撃な限り避けるために、安全な場所になければなりません。特に、キーマテリアルへのアクセスは、検証システムで必要なプログラムやプロセスに限定されるべきです。
This document introduced several variants of HOTP for challenge-response-based authentication and short signature-like computations.
この文書では、チャレンジ・レスポンスベースの認証と短い署名のような計算のためにHOTPのいくつかの変種を導入しました。
The OCRASuite provides for an easy integration and support of different flavors within an authentication and validation system.
OCRASuiteは、認証および検証システム内の異なる味の容易な統合とサポートを提供します。
Finally, OCRA should enable mutual authentication both in connected and off-line modes, with the support of different response sizes and mode of operations.
最後に、OCRAは異なる応答サイズ及び操作のモードをサポートして、両方の接続とオフラインモードで相互認証を可能にすべきです。
We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, Philip Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, Jonathan Tuliani, Stu Vaeth, Enrique Rodriguez, and Robert Zuccherato for their comments and suggestions to improve this document.
私たちは、この文書を改善するために、自分の意見や提案のためにジェフ・バースタイン、Shuhチャン、Oanhホアン、フィリップ・ホイヤー、ジョンMartinsson、フレデリックMENNES、Mingliangペイ、ジョナサンTuliani、ステューVaeth、エンリケ・ロドリゲス、そしてロバートZuccheratoに感謝したいと思います。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[RFC4226] M'Raihi、D.、ベラー、M.、Hoornaert、F.、Naccache、D.、およびO. Ranen、 "HOTP：HMACベースのワンタイムパスワードアルゴリズム"、RFC 4226、2005年12月。
[SHA2] NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)", October 2008, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.
[SHA2] NIST、 "FIPS PUB 180-3の：セキュアハッシュ標準（SHS）"、2008年10月、<http://csrc.nist.gov/publications/fips/ fips180-3 / fips180-3_final.pdf>。
[CN] Coron, J. and D. Naccache, "An accurate evaluation of Maurer's universal test", LNCS 1556, February 1999, <http: //www.gemplus.com/smart/rd/publications/pdf/CN99maur.pdf>.
[CN]コロン、J.とD. Naccache、 "マウラーのユニバーサルテストの正確な評価"、LNCS 1556、1999年2月、<のhttp：//www.gemplus.com/smart/rd/publications/pdf/CN99maur.pdf >。
[OATH] Initiative for Open Authentication, "OATH Vision", <http://www.openauthentication.org/about>.
[OATH]イニシアティブオープン認証のため、 "OATHビジョン"、<http://www.openauthentication.org/about>。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[RFC6030]ホイヤー、P.、ペイ、M.、およびS. Machani、 "ポータブル対称キーコンテナ（PSKC）"、RFC 6030、2010年10月。
[UT] Wikipedia, "Unix time", <http://en.wikipedia.org/wiki/Unix_time>.
[UT]ウィキペディア、 "Unixの時間"、<http://en.wikipedia.org/wiki/Unix_time>。
Appendix A. Reference Implementation
付録A.リファレンス実装
<CODE BEGINS>
<CODEが開始されます>
/**
Copyright (c) 2011 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。 * /
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.math.BigInteger;
/**
* This an example implementation of OCRA.
* Visit www.openauthentication.org for more information.
*
* @author Johan Rydell, PortWise
*/
public class OCRA {
private OCRA() {}
プライベートOCRA（）{}
/**
* This method uses the JCE to provide the crypto
* algorithm.
* HMAC computes a Hashed Message Authentication Code with the
* crypto hash algorithm as a parameter.
*
* @param crypto the crypto algorithm (HmacSHA1, HmacSHA256,
* HmacSHA512)
* @param keyBytes the bytes to use for the HMAC key
* @param text the message or text to be authenticated.
*/
private static byte[] hmac_sha1(String crypto,
byte[] keyBytes, byte[] text){
Mac hmac = null;
try {
hmac = Mac.getInstance(crypto);
SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW");
hmac.init(macKey);
return hmac.doFinal(text);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
private static final int[] DIGITS_POWER // 0 1 2 3 4 5 6 7 8 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 };
プライベート静的最終int型= {1,10,100,1000,10000,100000,1000000,10000000,100000000} // 0 1 2 3 4 5 6 7 8 [] DIGITS_POWER。
/**
* This method converts HEX string to Byte[]
*
* @param hex the HEX string
*
* @return A byte array
*/
private static byte[] hexStr2Bytes(String hex){
// Adding one byte to get the right conversion
// values starting with "0" can be converted
byte[] bArray = new BigInteger("10" + hex,16).toByteArray();
// Copy all the REAL bytes, not the "first"
byte[] ret = new byte[bArray.length - 1];
System.arraycopy(bArray, 1, ret, 0, ret.length);
return ret;
}
/**
* This method generates an OCRA HOTP value for the given
* set of parameters.
*
* @param ocraSuite the OCRA Suite
* @param key the shared secret, HEX encoded
* @param counter the counter that changes on a per use
* basis, HEX encoded
* @param question the challenge question, HEX encoded
* @param password a password that can be used, HEX encoded
* @param sessionInformation Static information that identifies
* the current session, Hex encoded
* @param timeStamp a value that reflects a time
*
* @return A numeric String in base 10 that includes
* {@link truncationDigits} digits
*/ static public String generateOCRA(String ocraSuite, String key, String counter, String question, String password, String sessionInformation, String timeStamp){
* /静的パブリック文字列generateOCRA（文字ocraSuite、文字列のキー、文字列のカウンター、文字列の質問、文字列のパスワード、文字列セッション情報、文字列のtimeStampに）{
int codeDigits = 0;
String crypto = "";
String result = null;
int ocraSuiteLength = (ocraSuite.getBytes()).length;
int counterLength = 0;
int questionLength = 0;
int passwordLength = 0;
int sessionInformationLength = 0;
int timeStampLength = 0;
// The OCRASuites components
String CryptoFunction = ocraSuite.split(":")[1];
String DataInput = ocraSuite.split(":")[2];
if(CryptoFunction.toLowerCase().indexOf("sha1") > 1)
crypto = "HmacSHA1";
if(CryptoFunction.toLowerCase().indexOf("sha256") > 1)
crypto = "HmacSHA256";
if(CryptoFunction.toLowerCase().indexOf("sha512") > 1)
crypto = "HmacSHA512";
// How many digits should we return codeDigits = Integer.decode(CryptoFunction.substring( CryptoFunction.lastIndexOf("-")+1));
//どのように多くの桁が、我々は返す必要がありますcodeDigits = Integer.decode（CryptoFunction.substring（CryptoFunction.lastIndexOf（ " - "）+ 1））;
// The size of the byte array message to be encrypted
// Counter
if(DataInput.toLowerCase().startsWith("c")) {
// Fix the length of the HEX string
while(counter.length() < 16)
counter = "0" + counter;
counterLength=8;
}
// Question - always 128 bytes
if(DataInput.toLowerCase().startsWith("q") ||
(DataInput.toLowerCase().indexOf("-q") >= 0)) {
while(question.length() < 256)
question = question + "0";
questionLength=128; }
questionLength = 128。 }
// Password - sha1
if(DataInput.toLowerCase().indexOf("psha1") > 1){
while(password.length() < 40)
password = "0" + password;
passwordLength=20;
}
// Password - sha256
if(DataInput.toLowerCase().indexOf("psha256") > 1){
while(password.length() < 64)
password = "0" + password;
passwordLength=32;
}
// Password - sha512
if(DataInput.toLowerCase().indexOf("psha512") > 1){
while(password.length() < 128)
password = "0" + password;
passwordLength=64;
}
// sessionInformation - s064
if(DataInput.toLowerCase().indexOf("s064") > 1){
while(sessionInformation.length() < 128)
sessionInformation = "0" + sessionInformation;
sessionInformationLength=64;
}
// sessionInformation - s128
if(DataInput.toLowerCase().indexOf("s128") > 1){
while(sessionInformation.length() < 256)
sessionInformation = "0" + sessionInformation;
sessionInformationLength=128;
}
// sessionInformation - s256
if(DataInput.toLowerCase().indexOf("s256") > 1){
while(sessionInformation.length() < 512)
sessionInformation = "0" + sessionInformation;
sessionInformationLength=256;
}
// sessionInformation - s512 if(DataInput.toLowerCase().indexOf("s512") > 1){ while(sessionInformation.length() < 1024)
//セッション情報 - S512 IF（。DataInput.toLowerCase（）のindexOf（ "S512"）> 1）{（sessionInformation.length（）<1024）、一方
sessionInformation = "0" + sessionInformation;
sessionInformationLength=512;
}
// TimeStamp
if(DataInput.toLowerCase().startsWith("t") ||
(DataInput.toLowerCase().indexOf("-t") > 1)){
while(timeStamp.length() < 16)
timeStamp = "0" + timeStamp;
timeStampLength=8;
}
// Remember to add "1" for the "00" byte delimiter byte[] msg = new byte[ocraSuiteLength + counterLength + questionLength + passwordLength + sessionInformationLength + timeStampLength + 1];
// "00" バイトの区切りバイトのために "1" を追加してください[] MSG =新しいバイト[ocraSuiteLength + counterLength + questionLength + passwordLength + sessionInformationLength + timeStampLength + 1];
// Put the bytes of "ocraSuite" parameters into the message
byte[] bArray = ocraSuite.getBytes();
System.arraycopy(bArray, 0, msg, 0, bArray.length);
// Delimiter msg[bArray.length] = 0x00;
//デリミタMSG [bArray.length] = 0x00で、
// Put the bytes of "Counter" to the message
// Input is HEX encoded
if(counterLength > 0 ){
bArray = hexStr2Bytes(counter);
System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1,
bArray.length);
}
// Put the bytes of "question" to the message
// Input is text encoded
if(questionLength > 0 ){
bArray = hexStr2Bytes(question);
System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
counterLength, bArray.length);
}
// Put the bytes of "password" to the message
// Input is HEX encoded if(passwordLength > 0){
bArray = hexStr2Bytes(password);
System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
counterLength + questionLength, bArray.length);
}
｝
// Put the bytes of "sessionInformation" to the message
// Input is text encoded
if(sessionInformationLength > 0 ){
bArray = hexStr2Bytes(sessionInformation);
System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
counterLength + questionLength +
passwordLength, bArray.length);
}
// Put the bytes of "time" to the message
// Input is text value of minutes
if(timeStampLength > 0){
bArray = hexStr2Bytes(timeStamp);
System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
counterLength + questionLength +
passwordLength + sessionInformationLength,
bArray.length);
}
bArray = hexStr2Bytes(key);
= hexStr2Bytesは（キー）に教示しました。
byte[] hash = hmac_sha1(crypto, bArray, msg);
バイト[]ハッシュ= HMAC_SHA1（暗号、bArray、MSG）。
// put selected bytes into result int int offset = hash[hash.length - 1] & 0xf;
//は、結果INT INTオフセット=ハッシュ[hash.length - 1]に選択されたバイトを入れ＆0xFの。
int binary = ((hash[offset] & 0x7f) << 24) | ((hash[offset + 1] & 0xff) << 16) | ((hash[offset + 2] & 0xff) << 8) | (hash[offset + 3] & 0xff);
int型のバイナリ=（（ハッシュ[オフセット]＆から0x7f）<< 24）| （（ハッシュ0xffの＆[+ 1オフセット]）<< 16）| （（ハッシュ[+ 2オフセット]＆0xffの）<< 8）| （ハッシュ[+ 3のオフセット]＆0xffで）。
int otp = binary % DIGITS_POWER[codeDigits];
INT OTP =バイナリ％DIGITS_POWER [codeDigits]。
result = Integer.toString(otp);
while (result.length() < codeDigits) {
result = "0" + result;
}
return result;
}
}
<CODE ENDS>
<CODEはENDS>
Appendix B. Test Vectors Generation
付録B.テストベクトルの生成
<CODE BEGINS>
<CODEが開始されます>
/**
Copyright (c) 2011 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。 * /
import java.math.BigInteger;
import java.util.*;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
public class TestOCRA {
{publicクラスTestOCRA
public static String asHex (byte buf[]) {
StringBuffer strbuf = new StringBuffer(buf.length * 2);
int i;
for (i = 0; i < buf.length; i++) {
if (((int) buf[i] & 0xff) < 0x10)
strbuf.append("0");
strbuf.append(Long.toString((int) buf[i] & 0xff, 16));
}
return strbuf.toString();
}
/**
* @param args
*/
public static void main(String[] args) {
String ocra = "";
String seed = "";
String ocraSuite = "";
String counter = "";
String password = "";
String sessionInformation = "";
String question = "";
String qHex = "";
String timeStamp = "";
// PASS1234 is SHA1 hash of "1234" String PASS1234 = "7110eda4d09e062aa5e4a390b0a572ac0d2c0220";
// PASS1234は、 "1234" の文字列PASS1234 = "7110eda4d09e062aa5e4a390b0a572ac0d2c0220" のSHA1ハッシュです。
String SEED = "3132333435363738393031323334353637383930";
String SEED32 = "31323334353637383930313233343536373839" +
"30313233343536373839303132";
String SEED64 = "31323334353637383930313233343536373839" +
"3031323334353637383930313233343536373839" +
"3031323334353637383930313233343536373839" +
"3031323334";
int STOP = 5;
Date myDate = Calendar.getInstance().getTime();
BigInteger b = new BigInteger("0");
String sDate = "Mar 25 2008, 12:06:30 GMT";
try{
DateFormat df =
new SimpleDateFormat("MMM dd yyyy, HH:mm:ss zzz");
myDate = df.parse(sDate);
b = new BigInteger("0" + myDate.getTime());
b = b.divide(new BigInteger("60000"));
System.out.println("Time of \"" + sDate + "\" is in");
System.out.println("milli sec: " + myDate.getTime());
System.out.println("minutes: " + b.toString());
System.out.println("minutes (HEX encoded): "
+ b.toString(16).toUpperCase());
System.out.println("Time of \"" + sDate
+ "\" is the same as this localized");
System.out.println("time, \""
+ new Date(myDate.getTime()) + "\"");
System.out.println();
System.out.println("Standard 20Byte key: " +
"3132333435363738393031323334353637383930");
System.out.println("Standard 32Byte key: " +
"3132333435363738393031323334353637383930");
System.out.println(" " +
"313233343536373839303132");
System.out.println("Standard 64Byte key: 313233343536373839"
+ "3031323334353637383930");
System.out.println(" 313233343536373839"
+ "3031323334353637383930");
System.out.println(" 313233343536373839"
+ "3031323334353637383930");
System.out.println(" 31323334");
System.out.println();
System.out.println("Plain challenge response");
System.out.println("========================");
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA1-6:QN08";
System.out.println(ocraSuite);
System.out.println("=======================");
seed = SEED;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = "";
for(int i=0; i < 10; i++){
question = "" + i + i + i + i + i + i + i + i;
qHex = new String((new BigInteger(question,10))
.toString(16)).toUpperCase();
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,
sessionInformation,timeStamp);
System.out.println("Key: Standard 20Byte Q: "
+ question + " OCRA: " + ocra);
}
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1";
System.out.println(ocraSuite);
System.out.println("=================================");
seed = SEED32;
counter = "";
question = "12345678";
password = PASS1234;
sessionInformation = "";
timeStamp = "";
for(int i=0; i < 10; i++){
counter = "" + i;
qHex = new String((new BigInteger(question,10))
.toString(16)).toUpperCase();
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,sessionInformation,timeStamp);
System.out.println("Key: Standard 32Byte C: "
+ counter + " Q: "
+ question + " PIN(1234): ");
System.out.println(password + " OCRA: " + ocra);
}
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA256-8:QN08-PSHA1";
System.out.println(ocraSuite);
System.out.println("===============================");
seed = SEED32;
counter = "";
question = "";
password = PASS1234;
sessionInformation = "";
timeStamp = "";
for(int i=0; i < STOP; i++){
question = "" + i + i + i + i + i + i + i + i;
qHex = new String((new BigInteger(question,10))
.toString(16)).toUpperCase();
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,sessionInformation,timeStamp);
System.out.println("Key: Standard 32Byte Q: "
+ question + " PIN(1234): ");
System.out.println(password + " OCRA: " + ocra);
}
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA512-8:C-QN08";
System.out.println(ocraSuite);
System.out.println("===========================");
seed = SEED64;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = "";
for(int i=0; i < 10; i++){
question = "" + i + i + i + i + i + i + i + i;
qHex = new String((new BigInteger(question,10))
.toString(16)).toUpperCase();
counter = "0000" + i;
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,sessionInformation,timeStamp);
System.out.println("Key: Standard 64Byte C: "
+ counter + " Q: "
+ question + " OCRA: " + ocra);
}
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA512-8:QN08-T1M";
System.out.println(ocraSuite);
System.out.println("=============================");
seed = SEED64;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = b.toString(16);
for(int i=0; i < STOP; i++){
question = "" + i + i + i + i + i + i + i + i;
counter = "";
qHex = new String((new BigInteger(question,10))
.toString(16)).toUpperCase();
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,sessionInformation,timeStamp);
System.out.println("Key: Standard 64Byte Q: "
+ question +" T: "
+ timeStamp.toUpperCase()
+ " OCRA: " + ocra);
}
System.out.println();
System.out.println();
System.out.println("Mutual Challenge Response");
System.out.println("=========================");
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08";
System.out.println("OCRASuite (server computation) = "
+ ocraSuite);
System.out.println("OCRASuite (client computation) = "
+ ocraSuite);
System.out.println("===============================" +
"===========================");
seed = SEED32;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = "";
for(int i=0; i < STOP; i++){
question = "CLI2222" + i + "SRV1111" + i;
qHex = asHex(question.getBytes());
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
password,sessionInformation,timeStamp);
System.out.println(
"(server)Key: Standard 32Byte Q: "
+ question + " OCRA: "
+ ocra);
question = "SRV1111" + i + "CLI2222" + i;
qHex = asHex(question.getBytes());
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
password,sessionInformation,timeStamp);
System.out.println(
"(client)Key: Standard 32Byte Q: "
+ question + " OCRA: "
+ ocra);
}
System.out.println();
String ocraSuite1 = "OCRA-1:HOTP-SHA512-8:QA08";
String ocraSuite2 = "OCRA-1:HOTP-SHA512-8:QA08-PSHA1";
System.out.println("OCRASuite (server computation) = "
+ ocraSuite1);
System.out.println("OCRASuite (client computation) = "
+ ocraSuite2);
System.out.println("===============================" +
"=================================");
ocraSuite = "";
seed = SEED64;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = "";
for(int i=0; i < STOP; i++){
ocraSuite = ocraSuite1;
question = "CLI2222" + i + "SRV1111" + i;
qHex = asHex(question.getBytes());
password = "";
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
password,sessionInformation,timeStamp);
System.out.println(
"(server)Key: Standard 64Byte Q: "
+ question + " OCRA: "
+ ocra);
ocraSuite = ocraSuite2;
question = "SRV1111" + i + "CLI2222" + i;
qHex = asHex(question.getBytes());
password = PASS1234;
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
password,sessionInformation,timeStamp);
System.out.println("(client)Key: Standard 64Byte Q: "
+ question);
System.out.println("P: " + password.toUpperCase()
+ " OCRA: " + ocra);
}
System.out.println();
System.out.println();
System.out.println("Plain Signature");
System.out.println("===============");
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08";
System.out.println(ocraSuite);
System.out.println("=========================");
seed = SEED32;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = "";
for(int i=0; i < STOP; i++){
question = "SIG1" + i + "000";
qHex = asHex(question.getBytes());
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
password,sessionInformation,timeStamp);
System.out.println(
"Key: Standard 32Byte Q(Signature challenge): "
+ question);
System.out.println(" OCRA: " + ocra);
}
System.out.println();
ocraSuite = "OCRA-1:HOTP-SHA512-8:QA10-T1M";
System.out.println(ocraSuite);
System.out.println("=============================");
seed = SEED64;
counter = "";
question = "";
password = "";
sessionInformation = "";
timeStamp = b.toString(16);
for(int i=0; i < STOP; i++){
question = "SIG1" + i + "00000";
qHex = asHex(question.getBytes());
ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
qHex,password,sessionInformation,timeStamp);
System.out.println(
"Key: Standard 64Byte Q(Signature challenge): "
+ question);
System.out.println(" T: "
+ timeStamp.toUpperCase() + " OCRA: " + ocra); }
TimeStamp.toUpperCase +（）+ "OCRA" +黄土）。 }
}catch (Exception e){ System.out.println("Error : " + e); } } } <CODE ENDS>
}キャッチ（例外e）{System.out.printlnは（ "エラー：" + E）。 }}} <CODEを終了します>
Appendix C. Test Vectors
付録C.テストベクトル
This section provides test values that can be used for the OCRA interoperability test.
このセクションでは、OCRAの相互運用性のテストのために使用することができるテスト値を提供します。
Standard 20Byte key:
標準20Byteキー：
3132333435363738393031323334353637383930
３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０
Standard 32Byte key:
標準的な32バイトのキー：
3132333435363738393031323334353637383930313233343536373839303132
３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２
Standard 64Byte key:
標準的な64バイトのキー：
313233343536373839303132333435363738393031323334353637383930313233343 53637383930313233343536373839303132333435363738393031323334
３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２３３３４３ ５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２３３３４３５３６３７３８３９３０３１３２３３３４
PIN (1234) SHA1 hash value:
PIN（1234）SHA1ハッシュ値：
7110eda4d09e062aa5e4a390b0a572ac0d2c0220
7110eda4d09e062aa5e4a390b0a572ac0d2c0220
C.1. One-Way Challenge Response
C.1。ワンウェイチャレンジレスポンス
+-----------------+----------+------------+
| Key | Q | OCRA Value |
+-----------------+----------+------------+
| Standard 20Byte | 00000000 | 237653 |
| Standard 20Byte | 11111111 | 243178 |
| Standard 20Byte | 22222222 | 653583 |
| Standard 20Byte | 33333333 | 740991 |
| Standard 20Byte | 44444444 | 608993 |
| Standard 20Byte | 55555555 | 388898 |
| Standard 20Byte | 66666666 | 816933 |
| Standard 20Byte | 77777777 | 224598 |
| Standard 20Byte | 88888888 | 750600 |
| Standard 20Byte | 99999999 | 294470 |
+-----------------+----------+------------+
OCRA-1:HOTP-SHA1-6:QN08
OCRA-1：HOTP-SHA1-6：QN08
+-----------------+---+----------+------------+
| Key | C | Q | OCRA Value |
+-----------------+---+----------+------------+
| Standard 32Byte | 0 | 12345678 | 65347737 |
| Standard 32Byte | 1 | 12345678 | 86775851 |
| Standard 32Byte | 2 | 12345678 | 78192410 |
| Standard 32Byte | 3 | 12345678 | 71565254 |
| Standard 32Byte | 4 | 12345678 | 10104329 |
| Standard 32Byte | 5 | 12345678 | 65983500 |
| Standard 32Byte | 6 | 12345678 | 70069104 |
| Standard 32Byte | 7 | 12345678 | 91771096 |
| Standard 32Byte | 8 | 12345678 | 75011558 |
| Standard 32Byte | 9 | 12345678 | 08522129 |
+-----------------+---+----------+------------+
OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1
OCRA-1：HOTP-SHA256-8：C-QN08-PSHA1
+-----------------+----------+------------+
| Key | Q | OCRA Value |
+-----------------+----------+------------+
| Standard 32Byte | 00000000 | 83238735 |
| Standard 32Byte | 11111111 | 01501458 |
| Standard 32Byte | 22222222 | 17957585 |
| Standard 32Byte | 33333333 | 86776967 |
| Standard 32Byte | 44444444 | 86807031 |
+-----------------+----------+------------+
OCRA-1:HOTP-SHA256-8:QN08-PSHA1
OCRA-1：HOTP-SHA256-8：QN08-PSHA1
+-----------------+-------+----------+------------+
| Key | C | Q | OCRA Value |
+-----------------+-------+----------+------------+
| Standard 64Byte | 00000 | 00000000 | 07016083 |
| Standard 64Byte | 00001 | 11111111 | 63947962 |
| Standard 64Byte | 00002 | 22222222 | 70123924 |
| Standard 64Byte | 00003 | 33333333 | 25341727 |
| Standard 64Byte | 00004 | 44444444 | 33203315 |
| Standard 64Byte | 00005 | 55555555 | 34205738 |
| Standard 64Byte | 00006 | 66666666 | 44343969 |
| Standard 64Byte | 00007 | 77777777 | 51946085 |
| Standard 64Byte | 00008 | 88888888 | 20403879 |
| Standard 64Byte | 00009 | 99999999 | 31409299 |
+-----------------+-------+----------+------------+
OCRA-1:HOTP-SHA512-8:C-QN08
OCRA-1：HOTP-SHA512-8：C-QN08
+-----------------+----------+---------+------------+
| Key | Q | T | OCRA Value |
+-----------------+----------+---------+------------+
| Standard 64Byte | 00000000 | 132d0b6 | 95209754 |
| Standard 64Byte | 11111111 | 132d0b6 | 55907591 |
| Standard 64Byte | 22222222 | 132d0b6 | 22048402 |
| Standard 64Byte | 33333333 | 132d0b6 | 24218844 |
| Standard 64Byte | 44444444 | 132d0b6 | 36209546 |
+-----------------+----------+---------+------------+
OCRA-1:HOTP-SHA512-8:QN08-T1M
OCRA-1：HOTP-SHA512-8：QN08-T1M
C.2. Mutual Challenge-Response
C.2。相互チャレンジ - レスポンス
OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08
OCRASuite（計算サーバ）OCRA-1 =：HOTP-SHA256-8：QA08
OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08
OCRASuite（計算クライアント）OCRA-1 =：HOTP-SHA256-8：QA08
+-----------------+------------------+------------+
| Key | Q | OCRA Value |
+-----------------+------------------+------------+
| Standard 32Byte | CLI22220SRV11110 | 28247970 |
| Standard 32Byte | CLI22221SRV11111 | 01984843 |
| Standard 32Byte | CLI22222SRV11112 | 65387857 |
| Standard 32Byte | CLI22223SRV11113 | 03351211 |
| Standard 32Byte | CLI22224SRV11114 | 83412541 |
+-----------------+------------------+------------+
Server -- OCRA-1:HOTP-SHA256-8:QA08
サーバ - OCRA-1：HOTP-SHA256-8：QA08
+-----------------+------------------+------------+
| Key | Q | OCRA Value |
+-----------------+------------------+------------+
| Standard 32Byte | SRV11110CLI22220 | 15510767 |
| Standard 32Byte | SRV11111CLI22221 | 90175646 |
| Standard 32Byte | SRV11112CLI22222 | 33777207 |
| Standard 32Byte | SRV11113CLI22223 | 95285278 |
| Standard 32Byte | SRV11114CLI22224 | 28934924 |
+-----------------+------------------+------------+
Client -- OCRA-1:HOTP-SHA256-8:QA08
クライアント - OCRA-1：HOTP-SHA256-8：QA08
OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08
OCRASuite（計算サーバ）OCRA-1 =：HOTP-SHA512-8：QA08
OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1
HOTP-SHA512-8：QA08-PSHA1 OCRASuite（計算クライアント）OCRA-1 =
+-----------------+------------------+------------+
| Key | Q | OCRA Value |
+-----------------+------------------+------------+
| Standard 64Byte | CLI22220SRV11110 | 79496648 |
| Standard 64Byte | CLI22221SRV11111 | 76831980 |
| Standard 64Byte | CLI22222SRV11112 | 12250499 |
| Standard 64Byte | CLI22223SRV11113 | 90856481 |
| Standard 64Byte | CLI22224SRV11114 | 12761449 |
+-----------------+------------------+------------+
Server -- OCRA-1:HOTP-SHA512-8:QA08
サーバ - OCRA-1：HOTP-SHA512-8：QA08
+-----------------+------------------+------------+
| Key | Q | OCRA Value |
+-----------------+------------------+------------+
| Standard 64Byte | SRV11110CLI22220 | 18806276 |
| Standard 64Byte | SRV11111CLI22221 | 70020315 |
| Standard 64Byte | SRV11112CLI22222 | 01600026 |
| Standard 64Byte | SRV11113CLI22223 | 18951020 |
| Standard 64Byte | SRV11114CLI22224 | 32528969 |
+-----------------+------------------+------------+
Client -- OCRA-1:HOTP-SHA512-8:QA08-PSHA1
クライアント - OCRA-1：HOTP-SHA512-8：QA08-PSHA1
C.3. Plain Signature
C.3。平野署名
In this mode of operation, Q represents the signature challenge.
この動作モードでは、Qは、署名の挑戦を表します。
+-----------------+----------+------------+
| Key | Q | OCRA Value |
+-----------------+----------+------------+
| Standard 32Byte | SIG10000 | 53095496 |
| Standard 32Byte | SIG11000 | 04110475 |
| Standard 32Byte | SIG12000 | 31331128 |
| Standard 32Byte | SIG13000 | 76028668 |
| Standard 32Byte | SIG14000 | 46554205 |
+-----------------+----------+------------+
OCRA-1:HOTP-SHA256-8:QA08
OCRA-1：HOTP-SHA256-8：QA08
+-----------------+------------+---------+------------+
| Key | Q | T | OCRA Value |
+-----------------+------------+---------+------------+
| Standard 64Byte | SIG1000000 | 132d0b6 | 77537423 |
| Standard 64Byte | SIG1100000 | 132d0b6 | 31970405 |
| Standard 64Byte | SIG1200000 | 132d0b6 | 10235557 |
| Standard 64Byte | SIG1300000 | 132d0b6 | 95213541 |
| Standard 64Byte | SIG1400000 | 132d0b6 | 65360607 |
+-----------------+------------+---------+------------+
OCRA-1:HOTP-SHA512-8:QA10-T1M
OCRA-1：HOTP-SHA512-8：QA10-T1M
Authors' Addresses
著者のアドレス
David M'Raihi Verisign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
デビッドM'Raihiベリサイン社487 E.ミドルロード、マウンテンビュー、CA 94043 USA
EMail: davidietf@gmail.com
メールアドレス：davidietf@gmail.com
Johan Rydell Portwise, Inc. 275 Hawthorne Ave, Suite 119 Palo Alto, CA 94301 USA
ヨハン・ライデルPortwise、Inc.の275ホーソーンアベニュー、スイート119パロアルト、CA 94301 USA
EMail: johanietf@gmail.com
メールアドレス：johanietf@gmail.com
Siddharth Bajaj Symantec Corp. 350 Ellis Street Mountain View, CA 94043 USA
シッダールタバジャジシマンテック350エリスストリートマウンテンビュー、CA 94043 USA
EMail: siddharthietf@gmail.com
メールアドレス：siddharthietf@gmail.com
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East, Suite 1801 Toronto, Ontario M2J 5C2 Canada
サラMachani Diversinet社2225シェパードアベニューイースト、スイート1801トロント、オンタリオM2J 5C2カナダ
EMail: smachani@diversinet.com
メールアドレス：smachani@diversinet.com
David Naccache Ecole Normale Superieure ENS DI, 45 rue d'Ulm Paris, 75005 France
デイビット・ナキャッシュ高等師範学校DI ENS、45 RUE D'ウルムパリ、75005フランス
EMail: david.naccache@ens.fr
メールアドレス：david.naccache@ens.fr