idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 835 has weird spacing: '...eyBytes the ...' == Line 862 has weird spacing: '...ram hex the ...' == Line 883 has weird spacing: '...raSuite the...' == Line 894 has weird spacing: '...meStamp a v...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2011) is 4813 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'C' is mentioned on line 656, but not defined == Missing Reference: 'T' is mentioned on line 650, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. M'Raihi 3 Internet-Draft Verisign, Inc. 4 Intended status: Informational J. Rydell 5 Expires: August 17, 2011 Portwise, Inc. 6 S. Machani 7 Diversinet Corp. 8 D. Naccache 9 Ecole Normale Superieure 10 S. Bajaj 11 Symantec Corp. 12 February 14, 2011 14 OCRA: OATH Challenge-Response Algorithms 15 draft-mraihi-mutual-oath-hotp-variants-13.txt 17 Abstract 19 This document describes an algorithm for challenge-response 20 authentication developed by the "Initiative for Open AuTHentication" 21 (OATH). The specified mechanisms leverage the HMAC-based One-Time 22 Password algorithm (HOTP) and offer one-way and mutual authentication 23 capabilities. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 17, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 3 66 3. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 3 67 4. OCRA Background . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. HOTP Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Definition of OCRA . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. DataInput Parameters . . . . . . . . . . . . . . . . . . . 5 71 5.2. CryptoFunction . . . . . . . . . . . . . . . . . . . . . . 6 72 6. The OCRASuite . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.2. CryptoFunction . . . . . . . . . . . . . . . . . . . . . . 8 75 6.3. DataInput . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Algorithm Modes for Authentication . . . . . . . . . . . . . . 10 77 7.1. One way Challenge-Response . . . . . . . . . . . . . . . . 10 78 7.2. Mutual Challenge-Response . . . . . . . . . . . . . . . . 11 79 7.3. Algorithm Modes for Signature . . . . . . . . . . . . . . 12 80 7.3.1. Plain Signature . . . . . . . . . . . . . . . . . . . 13 81 7.3.2. Signature with Server Authentication . . . . . . . . . 13 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 8.1. Security Analysis of the OCRA algorithm . . . . . . . . . 15 84 8.2. Implementation Considerations . . . . . . . . . . . . . . 16 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12.1. Normative references . . . . . . . . . . . . . . . . . . . 18 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Appendix A. Reference Implementation . . . . . . . . . . . . . . 18 92 Appendix B. Test Vectors Generation . . . . . . . . . . . . . . . 25 93 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 32 94 C.1. Plain challenge response . . . . . . . . . . . . . . . . . 32 95 C.2. Mutual Challenge Response . . . . . . . . . . . . . . . . 34 96 C.3. Plain Signature . . . . . . . . . . . . . . . . . . . . . 35 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 99 1. Introduction 101 OATH [OATH] has identified several use cases and scenarios that 102 require an asynchronous variant to accommodate users who do not want 103 to maintain a synchronized authentication system. A commonly 104 accepted method for this is to use a challenge-response scheme. 106 Such challenge response mode of authentication is widely adopted in 107 the industry. Several vendors already offer software applications 108 and hardware devices implementing challenge-response - but each of 109 those uses vendor-specific proprietary algorithms. For the benefits 110 of users there is a need for a standardized challenge-response 111 algorithm which allows multi-sourcing of token purchases and 112 validation systems to facilitate the democratization of strong 113 authentication. Additionally, this specification describes the means 114 to create symmetric key based digital signatures. Such signatures 115 are variants of challenge-response mode where the data to be signed 116 becomes the challenge. 118 2. Notation and Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Algorithm Requirements 126 This section presents the main requirements that drove this algorithm 127 design. A lot of emphasis was placed on flexibility and usability, 128 under the constraints and specificity of the HOTP algorithm and 129 hardware token capabilities. 131 R1 - The algorithm MUST support asynchronous challenge-response based 132 authentication. 134 R2 - The algorithm MUST be capable of supporting symmetric key based 135 digital signatures. Essentially this is a variation of challenge- 136 response where the challenge is derived from the data that need to be 137 signed. 139 R3 - The algorithm MUST be capable of supporting server- 140 authentication, whereby the user can verify that he/she is talking to 141 a trusted server. 143 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building block. 145 R5 - The length and format of the input challenge SHOULD be 146 configurable. 148 R6 - The output length and format of the generated response SHOULD be 149 configurable. 151 R7 - The challenge MAY be generated with integrity checking (e.g., 152 parity bits). This will allow tokens with pin pads to perform simple 153 error checking when the user enters the challenge value into a token. 155 R8 - There MUST be a unique secret (key) for each token/soft token 156 that is shared between the token and the authentication server. The 157 keys MUST be randomly generated or derived using a key derivation 158 algorithm. 160 R9 - The algorithm MAY enable additional data attributes such as a 161 timestamp or session information to be included in the computation. 162 These data inputs MAY be used individually or all together. 164 4. OCRA Background 166 OATH introduced the HOTP algorithm as a first open, freely available 167 building block towards strengthening authentication for end-users in 168 a variety of applications. One-time passwords are very efficient at 169 solving specific security issues thanks to the dynamic nature of OTP 170 computations. 172 After carefully analyzing different use cases, OATH came to the 173 conclusion that providing for extensions to the HOTP algorithms was 174 important. A very natural extension is to introduce a challenge mode 175 for computing HOTP values based on random questions. Equally 176 beneficial is being able to perform mutual authentication between two 177 parties, or short-signature computation for authenticating 178 transaction to improve the security of e-commerce applications. 180 4.1. HOTP Algorithm 182 The HOTP algorithm, as defined in [RFC4226] is based on an increasing 183 counter value and a static symmetric key known only to the prover and 184 verifier parties. 186 As a reminder: 187 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 189 Where Truncate represents the function that converts an HMAC-SHA-1 190 value into an HOTP value. 192 We refer the reader to [RFC4226] for the full description and further 193 details on the rationale and security analysis of HOTP. 195 The present draft describes the different variants based on similar 196 constructions as HOTP. 198 5. Definition of OCRA 200 OCRA is a generalization of HOTP with variable data inputs not solely 201 based on an incremented counter and secret key values. 203 The definition of OCRA requires a cryptographic function, a key K and 204 a set of DataInput parameters. This section first formally 205 introduces the OCRA algorithm and then introduces the definitions and 206 default values recommended for all parameters. 208 In a nutshell, 209 OCRA = CryptoFunction(K, DataInput) 211 Where: 213 o K: a shared secret key known to both parties 214 o DataInput: a structure that contains the concatenation of the 215 various input data values defined in details in section 5.1 216 o CryptoFunction: this is the function performing the OCRA 217 computation from the secret key K and the DataInput material; 218 CryptoFunction is described in details in section Section 5.2 220 5.1. DataInput Parameters 222 This structure is the concatenation over byte array of the OCRASuite 223 value as defined in section 6 with the different parameters used in 224 the computation, save for the secret key K. 226 DataInput = {OCRASuite | 00 | C | Q | P | S | T} where: 228 o OCRASuite is a value representing the suite of operations to 229 compute an OCRA response 230 o 00 is a byte value used as a separator 231 o C is an unsigned 8-byte counter value processed high-order bit 232 first, and MUST be synchronized between all parties; It loops 233 around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts 234 over at "{Hex}0" 235 o Q, mandatory, is a 128-byte list of (concatenated) challenge 236 question(s) generated by the parties; if Q is less than 128 bytes, 237 then it should be padded with zeroes to the right 239 o P is a hash (SHA1, SHA256 and SHA512 are supported) value of PIN/ 240 password that is known to all parties during the execution of the 241 algorithm; the length of P will depend on the hash function that 242 is used 243 o S is an UTF-8 encoded string of length upto 512 bytes that 244 contains information about the current session; the length of S is 245 defined in the OCRASuite string 246 o T is an 8-byte unsigned integer in big endian (i.e. network byte 247 order) representing the number of time-steps(seconds, minutes, 248 hours or days depending on the specified granularity) since 249 midnight UTC of January 1, 1970. More specificatlly, if the OCRA 250 computation includes a timestamp T, you SHOULD first convert your 251 current local time to UTC time (text form); you can then derive 252 the UTC time in the proper format (i.e. seconds, minutes, hours or 253 days elapsed from Epoch time); the size of the time-step is 254 defined in the OCRASuite string 256 When computing a response, the concatenation order is always the 257 following: 259 C | 261 OTHER-PARTY-GENERATED-CHALLENGE-QUESTION | 263 YOUR-GENERATED-CHALLENGE-QUESTION | 265 P| S | T 267 If a value is empty (i.e. a certain input is not used in the 268 computation) then the value is simply not represented in the string. 270 The counter on the token or client MUST be incremented every time a 271 new computation is requested by the user. The server's counter value 272 MUST only be incremented after a successful OCRA authentication. 274 5.2. CryptoFunction 276 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 277 computation for OCRA is HOTP with the default 6-digit dynamic 278 truncation and a combination of DataInput values as the message to 279 compute the HMAC-SHA1 digest. 281 As indicated in section 5.1, we denote t as the length in digits of 282 the truncation output. For instance, if t = 6, then the output of 283 the truncation is a 6-digit value. 285 We define the HOTP family of functions as an extension to HOTP: 287 1. HOTP-H-t: these are the different possible truncated versions of 288 HOTP, using the dynamic truncation method for extracting an HOTP 289 value from the HMAC output 290 2. We will denote HOTP-H-t as the realization of an HOTP function 291 that uses an HMAC function with the hash function H, and the 292 dynamic truncation as described in [RFC4226] to extract a t-digit 293 value 294 3. t=0 means that no truncation is performed and the full HMAC value 295 is used for authentication purpose 297 We list the following preferred modes of computation, where * denotes 298 the default CryptoFunction: 300 o HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC and a 301 dynamic truncation to a 4-digit value; this mode is not 302 recommended in the general case but can be useful when a very 303 short authentication code is needed by an application 304 o HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC and a 305 dynamic truncation to a 6-digit value 306 o HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC and a 307 dynamic truncation to an 8-digit value 308 o HOTP-SHA256-6: HOTP with SHA-256 as the hash function for HMAC and 309 a dynamic truncation to a 6-digit value 310 o HOTP-SHA512-6: HOTP with SHA-512 as the hash function for HMAC and 311 a dynamic truncation to a 6-digit value 313 This table summarizes all possible values for the CryptoFunction: 315 +---------------+--------------------+-------------------------+ 316 | Name | HMAC Function Used | Size of Truncation (t) | 317 +---------------+--------------------+-------------------------+ 318 | HOTP-SHA1-t | HMAC-SHA1 | 0 (no truncation), 4-10 | 319 | HOTP-SHA256-t | HMAC-SHA256 | 0 (no truncation), 4-10 | 320 | HOTP-SHA512-t | HMAC-SHA512 | 0 (no truncation), 4-10 | 321 +---------------+--------------------+-------------------------+ 323 Table 1: CryptoFunction Table 325 6. The OCRASuite 327 An OCRASuite value is a text string that captures one mode of 328 operation for the OCRA algorithm, completely specifying the various 329 options for that computation. An OCRASuite value is represented as 330 follows: 331 Algorithm:CryptoFunction:DataInput 333 The client and server need to agree on one or two values of 334 OCRASuite. These values may be agreed at time of token provisioning 335 or for more sophisticated client-server interactions these values may 336 be negotiated for every transaction. 338 Note that for Mutual Challenge-Response or Signature with Server 339 Authentication modes, the client and server will need to agree on two 340 values of OCRASuite - one for server computation and another for 341 client computation. 343 6.1. Algorithm 345 Description: Indicates the version of OCRA algorithm. 347 Values: OCRA-v where v represents the version number (e.g. 1, 2 348 etc.). This document specifies version 1 of the OCRA algorithm. 350 6.2. CryptoFunction 352 Description: Indicates the function used to compute OCRA values 354 Values: Permitted values are described in section 5.2 356 6.3. DataInput 358 Description: This component of the OCRASuite string captures the list 359 of valid inputs for that computation; [] indicates a value is 360 optional: 362 [C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation 364 [C] | QFxx | [PH | TG] : Plain Signature computation 366 Each input that is used for the computation is represented by a 367 single letter (except Q) and they are separated by a hyphen. 369 The input for challenge is further qualified by the formats supported 370 by the client for challenge question(s). Supported values can be: 372 +------------------+-------------------+ 373 | Format (F) | Up to Length (xx) | 374 +------------------+-------------------+ 375 | A (alphanumeric) | 04-64 | 376 | N (numeric) | 04-64 | 377 | H (hexadecimal) | 04-64 | 378 +------------------+-------------------+ 380 Table 2: Challenge Format Table 382 The default challenge format is N08, numeric and upto 8 digits. 384 The input for P is further qualified by the hash function used for 385 the PIN/password. Supported values for hash function can be: 387 Hash function (H) - SHA1, SHA256, SHA512. 389 The default hash function for P is SHA1. 391 The input for S is further qualified by the length of the session 392 data in bytes. The client and server could agree to any length but 393 the typical values are: 395 Length (nnn) - 064, 128, 256 and 512. 397 The default length is 064 bytes. 399 The input for timestamps is further qualified by G, size of the time- 400 step. G can be specified in number of seconds, minutes or hours: 402 +--------------------+-----------------------------+ 403 | Time-step Size (G) | Examples | 404 +--------------------+-----------------------------+ 405 | [1-59]S | number of seconds, e.g. 20S | 406 | [1-59]M | number of minutes, e.g. 5M | 407 | [0-48]H | number of hours, e.g. 24H | 408 +--------------------+-----------------------------+ 410 Table 3: Time-step Size Table 412 Default value for G is 1M, i.e. time step size is one minute and the 413 T represents the number of minutes since Epoch time. 415 Here are some examples of OCRASuite strings: 416 o OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1 means version 1 of the OCRA 417 algorithm with HMAC-SHA512 function, truncated to an 8-digit 418 value, using the counter, a random challenge and a SHA1 digest of 419 the PIN/Password as parameters. It also indicates that the client 420 supports only numeric challenge upto 8 digits in length 421 o OCRA-1:HOTP-SHA256-6:QA10-T1M means version 1 of the OCRA 422 algorithm with HMAC-SHA256 function, truncated to a 6-digit value, 423 using a random alphanumeric challenge upto 10 characters in length 424 and a timestamp in number of minutes since Epoch time 425 o OCRA-1:HOTP-SHA1-4:QH8-S512 means version 1 of the OCRA algorithm 426 with HMAC-SHA1 function, truncated to a 4-digit value, using a 427 random hexadecimal challenge upto 8 nibbles and a session value of 428 512 bytes 430 7. Algorithm Modes for Authentication 432 This section describes the typical modes in which the above defined 433 computation can be used for authentication. 435 7.1. One way Challenge-Response 437 A challenge/response is a security mechanism in which the verifier 438 presents a question (challenge) to the prover who must provide a 439 valid answer (response) to be authenticated. 441 To use this algorithm for a one-way challenge-response, the verifier 442 will communicate a challenge value (typically randomly generated) to 443 the prover. The prover will use the challenge in the computation as 444 described above. The prover then communicates the response to the 445 verifier to authenticate. 447 Therefore in this mode, the typical data inputs will be: 448 C - Counter, optional. 449 Q - Challenge question, mandatory, supplied by the verifier. 450 P - Hashed version of PIN/password, optional. 451 S - Session information, optional. 452 T - Timestamp, optional. 454 The diagram below shows the message exchange between the client 455 (prover) and the server (verifier) to complete a one-way challenge- 456 response authentication. 458 It is assumed that the client and server have a pre-shared key K that 459 is used for the computation. 461 CLIENT SERVER 462 (PROVER) VERIFIER) 463 | | 464 | Verifier sends challenge to prover | 465 | Challenge = Q | 466 |<---------------------------------------| 467 | | 468 | Prover Computes Response | 469 | R = OCRA(K, {[C] | Q | [P | S | T]}) | 470 | Prover sends Response = R | 471 |--------------------------------------->| 472 | | 473 | Verifier Validates Response | 474 | If Response is valid, Server sends OK | 475 | If Response is not, Server sends NOK | 476 |<---------------------------------------| 477 | | 479 7.2. Mutual Challenge-Response 481 Mutual challenge-response is a variation of one-way challenge- 482 response where both the client and server mutually authenticate each 483 other. 485 To use this algorithm, the client will first send a random client- 486 challenge to the server. The server computes the server-response and 487 sends it to the client along with a server-challenge. 489 The client will first verify the server-response to be assured that 490 it is talking to a valid server. It will then compute the client- 491 response and send it to the server to authenticate. The server 492 verifies the client-response to complete the two-way authentication 493 process. 495 In this mode there are two computations: client-response and server- 496 response. There are two separate challenge questions, generated by 497 both parties. We denote these challenge questions Q1 and Q2. 499 Typical data inputs for server-response computation will be: 500 C - Counter, optional. 501 QC - Challenge question, mandatory, supplied by the client. 502 QS - Challenge question, mandatory, supplied by the server. 503 S - Session information, optional. 504 T - Timestamp, optional. 506 Typical data inputs for client-response computation will be: 508 C - Counter, optional. 509 QS - Challenge question, mandatory, supplied by the server. 510 QC - Challenge question, mandatory, supplied by the client. 511 P - Hashed version of PIN/password, optional. 512 S - Session information, optional. 513 T - Timestamp, optional. 515 The following picture shows the messages that are exchanged between 516 the client and the server to complete a two-way mutual challenge- 517 response authentication. 519 It is assumed that the client and server have a pre-shared key K (or 520 pair of keys if using dual-key mode of computation) that is used for 521 the computation. 523 CLIENT SERVER 524 (PROVER) (VERIFIER) 525 | | 526 | 1. Client sends client-challenge | 527 | QC = Client-challenge | 528 |------------------------------------------------->| 529 | | 530 | 2. Server computes server-response | 531 | and sends server-challenge | 532 | RS = OCRA(K, [C] | QC | QS | [S | T]) | 533 | QS = Server-challenge | 534 | Response = RS, QS | 535 |<-------------------------------------------------| 536 | | 537 | 3. Client verifies server-response | 538 | and computes client-response | 539 | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP | 540 | RC = OCRA(K, [C] | QS | QC | [P | S | T]) | 541 | Response = RC | 542 |------------------------------------------------->| 543 | | 544 | 4. Server verifies client-response | 545 | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP | 546 | Response = OK | 547 |<-------------------------------------------------| 548 | | 550 7.3. Algorithm Modes for Signature 552 In this section we describe the typical modes in which the above 553 defined computation can be used for digital signatures. 555 7.3.1. Plain Signature 557 To use this algorithm in plain signature mode, the server will 558 communicate a signature-challenge value to the client (signer). The 559 signature-challenge is either the data to be signed or derived from 560 the data to be signed using a hash function, for example. 562 The client will use the signature-challenge in the computation as 563 described above. The client then communicates the signature value 564 (response) to the server to authenticate. 566 Therefore in this mode, the data inputs will be: 567 C - Counter, optional. 568 QS - Signature-challenge, mandatory, supplied by the server. 569 P - Hashed version of PIN/password, optional. 570 T - Timestamp, optional. 572 The picture below shows the messages that are exchanged between the 573 client (prover) and the server (verifier) to complete a plain 574 signature operation. 576 It is assumed that the client and server have a pre-shared key K that 577 is used for the computation. 579 CLIENT SERVER 580 (PROVER) (VERIFIER) 581 | | 582 | Verifier sends signature-challenge | 583 | Challenge = QS | 584 |<------------------------------------------| 585 | | 586 | Client Computes Response | 587 | SIGN = OCRA(K, [C] | QS | [P | T]) | 588 | Response = SIGN | 589 |------------------------------------------>| 590 | | 591 | Verifier Validates Response | 592 | Response = OK | 593 |<------------------------------------------| 594 | | 596 7.3.2. Signature with Server Authentication 598 This mode is a variation of the plain signature mode where the client 599 can first authenticates the server before generating a digital 600 signature. 602 To use this algorithm, the client will first send a random client- 603 challenge to the server. The server computes the server-response and 604 sends it to the client along with a signature-challenge. 606 The client will first verify the server-response to authenticate that 607 it is talking to a valid server. It will then compute the signature 608 and send it to the server. 610 In this mode there are two computations: client-signature and server- 611 response. 613 Typical data inputs for server-response computation will be: 614 C - Counter, optional. 615 QC - Challenge question, mandatory, supplied by the client. 616 QS - Signature-challenge, mandatory, supplied by the server. 617 T - Timestamp, optional. 619 Typical data inputs for client-signature computation will be: 620 C - Counter, optional. 621 QC - Challenge question, mandatory, supplied by the client. 622 QS - Signature-challenge, mandatory, supplied by the server. 623 P - Hashed version of PIN/password, optional. 624 T - Timestamp, optional. 626 The diagram below shows the messages that are exchanged between the 627 client and the server to complete a signature with server 628 authentication transaction. 630 It is assumed that the client and server have a pre-shared key K (or 631 pair of keys if using dual-key mode of computation) that is used for 632 the computation. 634 CLIENT SERVER 635 (PROVER) VERIFIER) 636 | | 637 | 1. Client sends client-challenge | 638 | QC = Client-challenge | 639 |-------------------------------------------------->| 640 | | 641 | 2. Server computes server-response | 642 | and sends signature-challenge | 643 | RS = OCRA(K, [C] | QC | QS | [T]) | 644 | QS = signature-challenge | 645 | Response = RS, QS | 646 |<--------------------------------------------------| 647 | | 648 | 3. Client verifies server-response | 649 | and computes signature | 650 | OCRA(K, [C] | QC | QS | [T]) != RS -> STOP | 651 | SIGN = OCRA( K, [C] | QS | QC | [P | T]) | 652 | Response = SIGN | 653 |-------------------------------------------------->| 654 | | 655 | 4. Server verifies Signature | 656 | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP | 657 | Response = OK | 658 |<--------------------------------------------------| 659 | | 661 8. Security Considerations 663 Any algorithm is only as secure as the application and the 664 authentication protocols that implement it. Therefore, this section 665 discusses the critical security requirements that our choice of 666 algorithm imposes on the authentication protocol and validation 667 software. 669 8.1. Security Analysis of the OCRA algorithm 671 The security and strength of this algorithm depends on the properties 672 of the underlying building block HOTP, which is a construction based 673 on HMAC [RFC2104] using SHA-1 as the hash function. 675 The conclusion of the security analysis detailed in [RFC4226] is 676 that, for all practical purposes, the outputs of the dynamic 677 truncation on distinct counter inputs are uniformly and independently 678 distributed strings. 680 The analysis demonstrates that the best possible attack against the 681 HOTP function is the brute force attack. 683 8.2. Implementation Considerations 685 IC1 - In the authentication mode, the client MUST support two- factor 686 authentication, i.e., the communication and verification of something 687 you know (secret code such as a Password, Pass phrase, PIN code, 688 etc.) and something you have (token). The secret code is known only 689 to the user and usually entered with the Response value for 690 authentication purpose (two-factor authentication). Alternatively, 691 instead of sending something you know to the server, the client may 692 use a hash of the Password or PIN code in the computation itself, 693 thus implicitly enabling two-factor authentication. 695 IC2 - Keys SHOULD be of the length of the CryptoFunction output to 696 facilitate interoperability. 698 IC3 - Keys SHOULD be chosen at random or using a cryptographically 699 strong pseudo-random generator properly seeded with a random value. 700 We RECOMMEND following the recommendations in [RFC4086] for all 701 pseudo-random and random generations. The pseudo-random numbers used 702 for generating the keys SHOULD successfully pass the randomness test 703 specified in [CN]. 705 IC4 - Challenge questions SHOULD be 20-byte values and MUST be at 706 least t-byte values where t stands for the digit-length of the OCRA 707 truncation output. 709 IC5 - On the client side, the keys SHOULD be embedded in a tamper 710 resistant device or securely implemented in a software application. 711 Additionally, by embedding the keys in a hardware device, you also 712 have the advantage of improving the flexibility (mobility) of the 713 authentication system. 715 IC6 - All the communications SHOULD take place over a secure channel 716 e.g. SSL/TLS, IPsec connections. 718 IC7 - The OCRA algorithm when used in mutual authentication mode or 719 in signature with server authentication mode MAY use dual key mode - 720 i.e. there are two keys that are shared between the client and the 721 server. One shared key is used to generate the server response on 722 the server side and to verify it on the client side. The other key 723 is used to create the response or signature on the client side and to 724 verify it on the server side. 726 IC8 - We recommend that implementations MAY use the session 727 information, S as an additional input in the computation. For 728 example, S could be the session identifier from the TLS session. 730 This will mitigate against certain types of man-in-the-middle 731 attacks. However, this will introduce the additional dependency that 732 first of all the prover needs to have access to the session 733 identifier to compute the response and the verifier will need access 734 to the session identifier to verify the response. 736 IC9 - In the signature mode, whenever the counter or time (defined as 737 optional elements) are not used in the computation, there might be a 738 risk of replay attack and the implementers should carefully consider 739 this issue in the light of their specific application requirements 740 and security guidelines. The server SHOULD also provide whenever 741 possible a mean for the client (if able) to verify the validity of 742 the signature challenge. 744 IC10 - We also RECOMMEND storing the keys securely in the validation 745 system, and more specifically encrypting them using tamper-resistant 746 hardware encryption and exposing them only when required: for 747 example, the key is decrypted when needed to verify an OCRA response, 748 and re-encrypted immediately to limit exposure in the RAM for a short 749 period of time. The key store MUST be in a secure area, to avoid as 750 much as possible direct attack on the validation system and secrets 751 database. Particularly, access to the key material should be limited 752 to programs and processes required by the validation system only. 754 9. IANA Considerations 756 This document has no actions for IANA. 758 10. Conclusion 760 This draft introduced several variants of HOTP for challenge- 761 response based authentication and short signature-like computations. 763 The OCRASuite provides for an easy integration and support of 764 different flavors within an authentication and validation system. 766 Finally, OCRA should enable mutual authentication both in connected 767 and off-line modes, with the support of different response sizes and 768 mode of operations. 770 11. Acknowledgements 772 We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, Philip 773 Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, Jonathan 774 Tuliani, Stu Vaeth, Enrique Rodriguez and Robert Zuccherato for their 775 comments and suggestions to improve this draft document. 777 12. References 779 12.1. Normative references 781 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 782 Hashing for Message Authentication", RFC 2104, 783 February 1997, . 785 [RFC2119] "Key words for use in RFCs to Indicate Requirement 786 Levels", BCP 14, RFC 2119, March 1997, 787 . 789 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 790 Recommendations for Security", RFC 4086, June 2005, 791 . 793 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 794 O. Ranen, "HOTP: An HMAC-Based One-Time Password 795 Algorithm", RFC 4226, December 2005, 796 . 798 12.2. Informative References 800 [CN] Coron, J. and D. Naccache, "An accurate evaluation of 801 Maurer's universal test", LNCS 1556, February 1999, . 804 [OATH] Initiative for Open AuTHentication, "OATH Vision", 805 . 807 Appendix A. Reference Implementation 809 import java.lang.reflect.UndeclaredThrowableException; 810 import java.security.GeneralSecurityException; 811 import javax.crypto.Mac; 812 import javax.crypto.spec.SecretKeySpec; 813 import java.math.BigInteger; 815 /** 816 * This an example implementation of the OATH OCRA algorithm. 817 * Visit www.openauthentication.org for more information. 819 * 820 * @author Johan Rydell, PortWise 821 */ 822 public class OCRA { 824 private OCRA() {} 826 /** 827 * This method uses the JCE to provide the crypto 828 * algorithm. 829 * HMAC computes a Hashed Message Authentication Code with the 830 * crypto hash algorithm as a parameter. 831 * 832 * @param crypto the crypto algorithm (HmacSHA1, 833 * HmacSHA256, 834 * HmacSHA512) 835 * @param keyBytes the bytes to use for the HMAC key 836 * @param text the message or text to be authenticated. 837 */ 839 private static byte[] hmac_sha1(String crypto, 840 byte[] keyBytes, 841 byte[] text) 842 { 843 try { 844 Mac hmac; 845 hmac = Mac.getInstance(crypto); 846 SecretKeySpec macKey = 847 new SecretKeySpec(keyBytes, "RAW"); 848 hmac.init(macKey); 849 return hmac.doFinal(text); 850 } catch (GeneralSecurityException gse) { 851 throw new UndeclaredThrowableException(gse); 852 } 853 } 855 private static final int[] DIGITS_POWER 856 // 0 1 2 3 4 5 6 7 8 857 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 859 /** 860 * This method converts HEX string to Byte[] 861 * 862 * @param hex the HEX string 863 * 864 * @return A byte array 865 */ 867 private static byte[] hexStr2Bytes(String hex){ 868 // Adding one byte to get the right conversion 869 // values starting with "0" can be converted 870 byte[] bArray = new BigInteger("10" + hex,16).toByteArray(); 872 // Copy all the REAL bytes, not the "first" 873 byte[] ret = new byte[bArray.length - 1]; 874 for (int i = 0; i < ret.length ; i++) 875 ret[i] = bArray[i+1]; 876 return ret; 877 } 879 /** 880 * This method generates an OCRA HOTP value for the given 881 * set of parameters. 882 * 883 * @param ocraSuite the OCRA Suite 884 * @param key the shared secret, HEX encoded 885 * @param counter the counter that changes 886 * on a per use basis, 887 * HEX encoded 888 * @param question the challenge question, HEX encoded 889 * @param password a password that can be used, 890 * HEX encoded 891 * @param sessionInformation 892 * Static information that identifies the 893 * current session, Hex encoded 894 * @param timeStamp a value that reflects a time 895 * 896 * @return A numeric String in base 10 that includes 897 * {@link truncationDigits} digits 898 */ 899 static public String generateOCRA(String ocraSuite, 900 String key, 901 String counter, 902 String question, 903 String password, 904 String sessionInformation, 905 String timeStamp) 906 { 907 int codeDigits = 0; 908 String crypto = ""; 909 String result = null; 910 int ocraSuiteLength = (ocraSuite.getBytes()).length; 911 int counterLength = 0; 912 int questionLength = 0; 913 int passwordLength = 0; 914 int sessionInformationLength = 0; 915 int timeStampLength = 0; 917 if(ocraSuite.toLowerCase().indexOf("sha1") > 1) 918 crypto = "HmacSHA1"; 919 if(ocraSuite.toLowerCase().indexOf("sha256") > 1) 920 crypto = "HmacSHA256"; 921 if(ocraSuite.toLowerCase().indexOf("sha512") > 1) 922 crypto = "HmacSHA512"; 924 // How many digits should we return 925 String oS = ocraSuite.substring(ocraSuite.indexOf(":"), 926 ocraSuite.indexOf(":", ocraSuite.indexOf(":") + 1)); 927 codeDigits = Integer.decode(oS.substring 928 (oS.lastIndexOf("-")+1, 929 oS.length())); 931 // The size of the byte array message to be encrypted 932 // Counter 933 if(ocraSuite.toLowerCase().indexOf(":c") > 1) { 934 // Fix the length of the HEX string 935 while(counter.length() < 16) 936 counter = "0" + counter; 937 counterLength=8; 938 } 939 // Question 940 if((ocraSuite.toLowerCase().indexOf(":q") > 1) || 941 (ocraSuite.toLowerCase().indexOf("-q") > 1)) { 942 while(question.length() < 256) 943 question = question + "0"; 944 questionLength=128; 945 } 947 // Password 948 if((ocraSuite.toLowerCase().indexOf(":p") > 1) || 949 (ocraSuite.toLowerCase().indexOf("-p") > 1)){ 950 while(password.length() < 40) 951 password = "0" + password; 952 passwordLength=20; 953 } 955 // sessionInformation 956 if((ocraSuite.toLowerCase().indexOf(":s") > 1) || 957 (ocraSuite.toLowerCase().indexOf("-s", 958 ocraSuite.indexOf(":", 959 ocraSuite.indexOf(":") + 1)) > 1)){ 960 while(sessionInformation.length() < 128) 961 sessionInformation = "0" + sessionInformation; 963 sessionInformationLength=64; 964 } 965 // TimeStamp 966 if((ocraSuite.toLowerCase().indexOf(":t") > 1) || 967 (ocraSuite.toLowerCase().indexOf("-t") > 1)){ 968 while(timeStamp.length() < 16) 969 timeStamp = "0" + timeStamp; 970 timeStampLength=8; 971 } 973 // Remember to add "1" for the "00" byte delimiter 974 byte[] msg = new byte[ocraSuiteLength + 975 counterLength + 976 questionLength + 977 passwordLength + 978 sessionInformationLength + 979 timeStampLength + 980 1]; 982 // Put the bytes of "ocraSuite" parameters into the message 983 byte[] bArray = ocraSuite.getBytes(); 984 for(int i = 0; i < bArray.length; i++){ 985 msg[i] = bArray[i]; 986 } 988 // Delimiter 989 msg[bArray.length] = 0x00; 991 // Put the bytes of "Counter" to the message 992 // Input is HEX encoded 993 if(counterLength > 0 ){ 994 bArray = hexStr2Bytes(counter); 995 for (int i = 0; i < bArray.length ; i++) { 996 msg[i + ocraSuiteLength + 1] = bArray[i]; 997 } 998 } 1000 // Put the bytes of "question" to the message 1001 // Input is text encoded 1002 if(question.length() > 0 ){ 1003 bArray = hexStr2Bytes(question); 1004 for (int i = 0; i < bArray.length ; i++) { 1005 msg[i + ocraSuiteLength + 1 + counterLength] = 1006 bArray[i]; 1007 } 1008 } 1009 // Put the bytes of "password" to the message 1010 // Input is HEX encoded 1011 if(password.length() > 0){ 1012 bArray = hexStr2Bytes(password); 1013 for (int i = 0; i < bArray.length ; i++) { 1014 msg[i + ocraSuiteLength + 1 + counterLength 1015 + questionLength] = bArray[i]; 1016 } 1017 } 1019 // Put the bytes of "sessionInformation" to the message 1020 // Input is text encoded 1021 if(sessionInformation.length() > 0 ){ 1022 bArray = hexStr2Bytes(sessionInformation); 1023 for (int i = 0; i < 128 && i < bArray.length ; i++) { 1024 msg[i + ocraSuiteLength 1025 + 1 + counterLength 1026 + questionLength 1027 + passwordLength] = bArray[i]; 1028 } 1029 } 1031 // Put the bytes of "time" to the message 1032 // Input is text value of minutes 1033 if(timeStamp.length() > 0){ 1034 bArray = hexStr2Bytes(timeStamp); 1035 for (int i = 0; i < 8 && i < bArray.length ; i++) { 1036 msg[i + ocraSuiteLength + 1 + counterLength + 1037 questionLength + passwordLength + 1038 sessionInformationLength] = bArray[i]; 1039 } 1040 } 1042 byte[] hash; 1043 bArray = hexStr2Bytes(key); 1045 hash = hmac_sha1(crypto, bArray, msg); 1047 // put selected bytes into result int 1048 int offset = hash[hash.length - 1] & 0xf; 1050 int binary = 1051 ((hash[offset] & 0x7f) << 24) | 1052 ((hash[offset + 1] & 0xff) << 16) | 1053 ((hash[offset + 2] & 0xff) << 8) | 1054 (hash[offset + 3] & 0xff); 1056 int otp = binary % DIGITS_POWER[codeDigits]; 1057 result = Integer.toString(otp); 1058 while (result.length() < codeDigits) { 1059 result = "0" + result; 1060 } 1061 return result; 1062 } 1063 } 1065 Appendix B. Test Vectors Generation 1067 import java.math.BigInteger; 1068 import java.util.*; 1069 import java.text.DateFormat; 1070 import java.text.SimpleDateFormat; 1072 public class TestOCRA { 1074 public static String asHex (byte buf[]) { 1075 StringBuffer strbuf = new StringBuffer(buf.length * 2); 1076 int i; 1078 for (i = 0; i < buf.length; i++) { 1079 if (((int) buf[i] & 0xff) < 0x10) 1080 strbuf.append("0"); 1081 strbuf.append(Long.toString((int) buf[i] & 0xff, 16)); 1082 } 1083 return strbuf.toString(); 1084 } 1086 /** 1087 * @param args 1088 */ 1089 public static void main(String[] args) { 1091 String ocra = ""; 1092 String seed = ""; 1093 String ocraSuite = ""; 1094 String counter = ""; 1095 String password = ""; 1096 String sessionInformation = ""; 1097 String question = ""; 1098 String qHex = ""; 1099 String timeStamp = ""; 1101 String PASS1234 = "7110eda4d09e062aa5e4a390b0a572ac0d2c0220"; 1102 String SEED = "3132333435363738393031323334353637383930"; 1103 String SEED32 = "31323334353637383930313233343536373839" + 1104 "30313233343536373839303132"; 1105 String SEED64 = "31323334353637383930313233343536373839" + 1106 "3031323334353637383930313233343536373839" + 1107 "3031323334353637383930313233343536373839" + 1108 "3031323334"; 1109 int STOP = 5; 1110 Date myDate = Calendar.getInstance().getTime(); 1111 BigInteger b = new BigInteger("0"); 1112 String sDate = "Mar 25 2008, 12:06:30 GMT"; 1114 try{ 1115 DateFormat df = 1116 new SimpleDateFormat("MMM dd yyyy, HH:mm:ss zzz"); 1117 myDate = df.parse(sDate); 1118 b = new BigInteger("0" + myDate.getTime()); 1119 b = b.divide(new BigInteger("60000")); 1121 System.out.println("Time of \"" + sDate + "\" is in"); 1122 System.out.println("milli sec: " + myDate.getTime()); 1123 System.out.println("minutes: " + b.toString()); 1124 System.out.println("minutes (HEX encoded): " 1125 + b.toString(16).toUpperCase()); 1126 System.out.println("Time of \"" + sDate 1127 + "\" is the same as this localized"); 1128 System.out.println("time, \"" 1129 + new Date(myDate.getTime()) + "\""); 1131 System.out.println(); 1132 System.out.println("Standard 20Byte key: " + 1133 "3132333435363738393031323334353637383930"); 1134 System.out.println("Standard 32Byte key: " + 1135 "3132333435363738393031323334353637383930"); 1136 System.out.println(" " + 1137 "313233343536373839303132"); 1138 System.out.println("Standard 64Byte key: 313233343536373839" + 1139 "3031323334353637383930"); 1140 System.out.println(" 313233343536373839" + 1141 "3031323334353637383930"); 1142 System.out.println(" 313233343536373839" + 1143 "3031323334353637383930"); 1144 System.out.println(" 31323334"); 1146 System.out.println(); 1147 System.out.println("Plain challenge response"); 1148 System.out.println("========================"); 1149 System.out.println(); 1151 ocraSuite = "OCRA-1:HOTP-SHA1-6:QN08"; 1152 System.out.println(ocraSuite); 1153 System.out.println("======================="); 1154 seed = SEED; 1155 counter = ""; 1156 question = ""; 1157 password = ""; 1158 sessionInformation = ""; 1159 timeStamp = ""; 1160 for(int i=0; i < 10; i++){ 1161 question = "" + i + i + i + i + i + i + i + i; 1162 qHex = new String((new BigInteger(question,10)) 1163 .toString(16)).toUpperCase(); 1164 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1165 qHex,password, 1166 sessionInformation,timeStamp); 1167 System.out.println("Key: Standard 20Byte Q: " 1168 + question + " OCRA: " + ocra); 1169 } 1170 System.out.println(); 1172 ocraSuite = "OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1"; 1173 System.out.println(ocraSuite); 1174 System.out.println("================================="); 1175 seed = SEED32; 1176 counter = ""; 1177 question = "12345678"; 1178 password = PASS1234; 1179 sessionInformation = ""; 1180 timeStamp = ""; 1181 for(int i=0; i < 10; i++){ 1182 counter = "" + i; 1183 qHex = new String((new BigInteger(question,10)) 1184 .toString(16)).toUpperCase(); 1185 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1186 qHex,password,sessionInformation,timeStamp); 1187 System.out.println("Key: Standard 32Byte C: " 1188 + counter + " Q: " 1189 + question + " PIN(1234): "); 1190 System.out.println(password + " OCRA: " + ocra); 1191 } 1192 System.out.println(); 1194 ocraSuite = "OCRA-1:HOTP-SHA256-8:QN08-PSHA1"; 1195 System.out.println(ocraSuite); 1196 System.out.println("==============================="); 1197 seed = SEED32; 1198 counter = ""; 1199 question = ""; 1200 password = PASS1234; 1201 sessionInformation = ""; 1202 timeStamp = ""; 1203 for(int i=0; i < STOP; i++){ 1204 question = "" + i + i + i + i + i + i + i + i; 1205 qHex = new String((new BigInteger(question,10)) 1206 .toString(16)).toUpperCase(); 1207 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1208 qHex,password,sessionInformation,timeStamp); 1209 System.out.println("Key: Standard 32Byte Q: " 1210 + question + " PIN(1234): "); 1211 System.out.println(password + " OCRA: " + ocra); 1212 } 1213 System.out.println(); 1215 ocraSuite = "OCRA-1:HOTP-SHA512-8:C-QN08"; 1216 System.out.println(ocraSuite); 1217 System.out.println("==========================="); 1218 seed = SEED64; 1219 counter = ""; 1220 question = ""; 1221 password = ""; 1222 sessionInformation = ""; 1223 timeStamp = ""; 1224 for(int i=0; i < 10; i++){ 1225 question = "" + i + i + i + i + i + i + i + i; 1226 qHex = new String((new BigInteger(question,10)) 1227 .toString(16)).toUpperCase(); 1228 counter = "0000" + i; 1229 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1230 qHex,password,sessionInformation,timeStamp); 1231 System.out.println("Key: Standard 64Byte C: " 1232 + counter + " Q: " 1233 + question + " OCRA: " + ocra); 1234 } 1235 System.out.println(); 1237 ocraSuite = "OCRA-1:HOTP-SHA512-8:QN08-T1M"; 1238 System.out.println(ocraSuite); 1239 System.out.println("============================="); 1240 seed = SEED64; 1241 counter = ""; 1242 question = ""; 1243 password = ""; 1244 sessionInformation = ""; 1245 timeStamp = b.toString(16); 1246 for(int i=0; i < STOP; i++){ 1247 question = "" + i + i + i + i + i + i + i + i; 1248 counter = ""; 1249 qHex = new String((new BigInteger(question,10)) 1250 .toString(16)).toUpperCase(); 1251 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1252 qHex,password,sessionInformation,timeStamp); 1254 System.out.println("Key: Standard 64Byte Q: " 1255 + question +" T: " 1256 + timeStamp.toUpperCase() 1257 + " OCRA: " + ocra); 1258 } 1259 System.out.println(); 1261 System.out.println(); 1262 System.out.println("Mutual Challenge Response"); 1263 System.out.println("========================="); 1264 System.out.println(); 1266 ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08"; 1267 System.out.println("OCRASuite (server computation) = " 1268 + ocraSuite); 1269 System.out.println("OCRASuite (client computation) = " 1270 + ocraSuite); 1271 System.out.println("===============================" + 1272 "==========================="); 1273 seed = SEED32; 1274 counter = ""; 1275 question = ""; 1276 password = ""; 1277 sessionInformation = ""; 1278 timeStamp = ""; 1279 for(int i=0; i < STOP; i++){ 1280 question = "CLI2222" + i + "SRV1111" + i; 1281 qHex = asHex(question.getBytes()); 1282 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1283 password,sessionInformation,timeStamp); 1284 System.out.println( 1285 "(server)Key: Standard 32Byte Q: " 1286 + question + " OCRA: " 1287 + ocra); 1288 question = "SRV1111" + i + "CLI2222" + i; 1289 qHex = asHex(question.getBytes()); 1290 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1291 password,sessionInformation,timeStamp); 1292 System.out.println( 1293 "(client)Key: Standard 32Byte Q: " 1294 + question + " OCRA: " 1295 + ocra); 1296 } 1297 System.out.println(); 1299 String ocraSuite1 = "OCRA-1:HOTP-SHA512-8:QA08"; 1300 String ocraSuite2 = "OCRA-1:HOTP-SHA512-8:QA08-PSHA1"; 1301 System.out.println("OCRASuite (server computation) = " 1302 + ocraSuite1); 1303 System.out.println("OCRASuite (client computation) = " 1304 + ocraSuite2); 1305 System.out.println("===============================" + 1306 "================================="); 1307 ocraSuite = ""; 1308 seed = SEED64; 1309 counter = ""; 1310 question = ""; 1311 password = ""; 1312 sessionInformation = ""; 1313 timeStamp = ""; 1314 for(int i=0; i < STOP; i++){ 1315 ocraSuite = ocraSuite1; 1316 question = "CLI2222" + i + "SRV1111" + i; 1317 qHex = asHex(question.getBytes()); 1318 password = ""; 1319 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1320 password,sessionInformation,timeStamp); 1321 System.out.println( 1322 "(server)Key: Standard 64Byte Q: " 1323 + question + " OCRA: " 1324 + ocra); 1325 ocraSuite = ocraSuite2; 1326 question = "SRV1111" + i + "CLI2222" + i; 1327 qHex = asHex(question.getBytes()); 1328 password = PASS1234; 1329 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1330 password,sessionInformation,timeStamp); 1331 System.out.println("(client)Key: Standard 64Byte Q: " 1332 + question); 1333 System.out.println("P: " + password.toUpperCase() 1334 + " OCRA: " + ocra); 1335 } 1336 System.out.println(); 1338 System.out.println(); 1339 System.out.println("Plain Signature"); 1340 System.out.println("==============="); 1341 System.out.println(); 1342 ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08"; 1343 System.out.println(ocraSuite); 1344 System.out.println("========================="); 1345 seed = SEED32; 1346 counter = ""; 1347 question = ""; 1348 password = ""; 1349 sessionInformation = ""; 1350 timeStamp = ""; 1351 for(int i=0; i < STOP; i++){ 1352 question = "SIG1" + i + "000"; 1353 qHex = asHex(question.getBytes()); 1354 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1355 password,sessionInformation,timeStamp); 1356 System.out.println( 1357 "Key: Standard 32Byte Q(Signature challenge): " 1358 + question); 1359 System.out.println(" OCRA: " + ocra); 1360 } 1361 System.out.println(); 1363 ocraSuite = "OCRA-1:HOTP-SHA512-8:QA10-T1M"; 1364 System.out.println(ocraSuite); 1365 System.out.println("============================="); 1366 seed = SEED64; 1367 counter = ""; 1368 question = ""; 1369 password = ""; 1370 sessionInformation = ""; 1371 timeStamp = b.toString(16); 1372 for(int i=0; i < STOP; i++){ 1373 question = "SIG1" + i + "00000"; 1374 qHex = asHex(question.getBytes()); 1375 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1376 qHex,password,sessionInformation,timeStamp); 1377 System.out.println( 1378 "Key: Standard 64Byte Q(Signature challenge): " 1379 + question); 1380 System.out.println(" T: " 1381 + timeStamp.toUpperCase() + " OCRA: " 1382 + ocra); 1383 } 1385 }catch (Exception e){ 1386 System.out.println("Error : " + e); 1387 } 1388 } 1389 } 1391 Appendix C. Test Vectors 1393 This section provides test values that can be used for OCRA algorithm 1394 interoperability test. 1396 Standard 20Byte key: 1398 3132333435363738393031323334353637383930 1400 Standard 32Byte key: 1402 3132333435363738393031323334353637383930313233343536373839303132 1404 Standard 64Byte key: 1406 313233343536373839303132333435363738393031323334353637383930313233343 1407 53637383930313233343536373839303132333435363738393031323334 1409 PIN (1234) SHA1 hash value: 1411 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 1413 C.1. Plain challenge response 1415 +-----------------+----------+------------+ 1416 | Key | Q | OCRA Value | 1417 +-----------------+----------+------------+ 1418 | Standard 20Byte | 00000000 | 237653 | 1419 | Standard 20Byte | 11111111 | 243178 | 1420 | Standard 20Byte | 22222222 | 653583 | 1421 | Standard 20Byte | 33333333 | 740991 | 1422 | Standard 20Byte | 44444444 | 608993 | 1423 | Standard 20Byte | 55555555 | 388898 | 1424 | Standard 20Byte | 66666666 | 816933 | 1425 | Standard 20Byte | 77777777 | 224598 | 1426 | Standard 20Byte | 88888888 | 750600 | 1427 | Standard 20Byte | 99999999 | 294470 | 1428 +-----------------+----------+------------+ 1430 OCRA-1:HOTP-SHA1-6:QN08 1432 +-----------------+---+----------+------------+ 1433 | Key | C | Q | OCRA Value | 1434 +-----------------+---+----------+------------+ 1435 | Standard 32Byte | 0 | 12345678 | 65347737 | 1436 | Standard 32Byte | 1 | 12345678 | 86775851 | 1437 | Standard 32Byte | 2 | 12345678 | 78192410 | 1438 | Standard 32Byte | 3 | 12345678 | 71565254 | 1439 | Standard 32Byte | 4 | 12345678 | 10104329 | 1440 | Standard 32Byte | 5 | 12345678 | 65983500 | 1441 | Standard 32Byte | 6 | 12345678 | 70069104 | 1442 | Standard 32Byte | 7 | 12345678 | 91771096 | 1443 | Standard 32Byte | 8 | 12345678 | 75011558 | 1444 | Standard 32Byte | 9 | 12345678 | 08522129 | 1445 +-----------------+---+----------+------------+ 1447 OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1 1449 +-----------------+----------+------------+ 1450 | Key | Q | OCRA Value | 1451 +-----------------+----------+------------+ 1452 | Standard 32Byte | 00000000 | 83238735 | 1453 | Standard 32Byte | 11111111 | 01501458 | 1454 | Standard 32Byte | 22222222 | 17957585 | 1455 | Standard 32Byte | 33333333 | 86776967 | 1456 | Standard 32Byte | 44444444 | 86807031 | 1457 +-----------------+----------+------------+ 1459 OCRA-1:HOTP-SHA256-8:QN08-PSHA1 1461 +-----------------+-------+----------+------------+ 1462 | Key | C | Q | OCRA Value | 1463 +-----------------+-------+----------+------------+ 1464 | Standard 64Byte | 00000 | 00000000 | 07016083 | 1465 | Standard 64Byte | 00001 | 11111111 | 63947962 | 1466 | Standard 64Byte | 00002 | 22222222 | 70123924 | 1467 | Standard 64Byte | 00003 | 33333333 | 25341727 | 1468 | Standard 64Byte | 00004 | 44444444 | 33203315 | 1469 | Standard 64Byte | 00005 | 55555555 | 34205738 | 1470 | Standard 64Byte | 00006 | 66666666 | 44343969 | 1471 | Standard 64Byte | 00007 | 77777777 | 51946085 | 1472 | Standard 64Byte | 00008 | 88888888 | 20403879 | 1473 | Standard 64Byte | 00009 | 99999999 | 31409299 | 1474 +-----------------+-------+----------+------------+ 1476 OCRA-1:HOTP-SHA512-8:C-QN08 1478 +-----------------+----------+---------+------------+ 1479 | Key | Q | T | OCRA Value | 1480 +-----------------+----------+---------+------------+ 1481 | Standard 64Byte | 00000000 | 132d0b6 | 95209754 | 1482 | Standard 64Byte | 11111111 | 132d0b6 | 55907591 | 1483 | Standard 64Byte | 22222222 | 132d0b6 | 22048402 | 1484 | Standard 64Byte | 33333333 | 132d0b6 | 24218844 | 1485 | Standard 64Byte | 44444444 | 132d0b6 | 36209546 | 1486 +-----------------+----------+---------+------------+ 1488 OCRA-1:HOTP-SHA512-8:QN08-T1M 1490 C.2. Mutual Challenge Response 1492 OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08 1494 OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08 1496 +-----------------+------------------+------------+ 1497 | Key | Q | OCRA Value | 1498 +-----------------+------------------+------------+ 1499 | Standard 32Byte | CLI22220SRV11110 | 28247970 | 1500 | Standard 32Byte | CLI22221SRV11111 | 01984843 | 1501 | Standard 32Byte | CLI22222SRV11112 | 65387857 | 1502 | Standard 32Byte | CLI22223SRV11113 | 03351211 | 1503 | Standard 32Byte | CLI22224SRV11114 | 83412541 | 1504 +-----------------+------------------+------------+ 1506 Server -- OCRA-1:HOTP-SHA256-8:QA08 1508 +-----------------+------------------+------------+ 1509 | Key | Q | OCRA Value | 1510 +-----------------+------------------+------------+ 1511 | Standard 32Byte | SRV11110CLI22220 | 15510767 | 1512 | Standard 32Byte | SRV11111CLI22221 | 90175646 | 1513 | Standard 32Byte | SRV11112CLI22222 | 33777207 | 1514 | Standard 32Byte | SRV11113CLI22223 | 95285278 | 1515 | Standard 32Byte | SRV11114CLI22224 | 28934924 | 1516 +-----------------+------------------+------------+ 1518 Client -- OCRA-1:HOTP-SHA256-8:QA08 1520 OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08 1522 OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1 1524 +-----------------+------------------+------------+ 1525 | Key | Q | OCRA Value | 1526 +-----------------+------------------+------------+ 1527 | Standard 64Byte | CLI22220SRV11110 | 79496648 | 1528 | Standard 64Byte | CLI22221SRV11111 | 76831980 | 1529 | Standard 64Byte | CLI22222SRV11112 | 12250499 | 1530 | Standard 64Byte | CLI22223SRV11113 | 90856481 | 1531 | Standard 64Byte | CLI22224SRV11114 | 12761449 | 1532 +-----------------+------------------+------------+ 1534 Server -- OCRA-1:HOTP-SHA512-8:QA08 1536 +-----------------+------------------+------------+ 1537 | Key | Q | OCRA Value | 1538 +-----------------+------------------+------------+ 1539 | Standard 64Byte | SRV11110CLI22220 | 18806276 | 1540 | Standard 64Byte | SRV11111CLI22221 | 70020315 | 1541 | Standard 64Byte | SRV11112CLI22222 | 01600026 | 1542 | Standard 64Byte | SRV11113CLI22223 | 18951020 | 1543 | Standard 64Byte | SRV11114CLI22224 | 32528969 | 1544 +-----------------+------------------+------------+ 1546 Client -- OCRA-1:HOTP-SHA512-8:QA08-PSHA1 1548 C.3. Plain Signature 1550 In this mode of operation, Q represents the signature challenge. 1552 +-----------------+----------+------------+ 1553 | Key | Q | OCRA Value | 1554 +-----------------+----------+------------+ 1555 | Standard 32Byte | SIG10000 | 53095496 | 1556 | Standard 32Byte | SIG11000 | 04110475 | 1557 | Standard 32Byte | SIG12000 | 31331128 | 1558 | Standard 32Byte | SIG13000 | 76028668 | 1559 | Standard 32Byte | SIG14000 | 46554205 | 1560 +-----------------+----------+------------+ 1562 OCRA-1:HOTP-SHA256-8:QA08 1564 +-----------------+------------+---------+------------+ 1565 | Key | Q | T | OCRA Value | 1566 +-----------------+------------+---------+------------+ 1567 | Standard 64Byte | SIG1000000 | 132d0b6 | 77537423 | 1568 | Standard 64Byte | SIG1100000 | 132d0b6 | 31970405 | 1569 | Standard 64Byte | SIG1200000 | 132d0b6 | 10235557 | 1570 | Standard 64Byte | SIG1300000 | 132d0b6 | 95213541 | 1571 | Standard 64Byte | SIG1400000 | 132d0b6 | 65360607 | 1572 +-----------------+------------+---------+------------+ 1574 OCRA-1:HOTP-SHA512-8:QA10-T1M 1576 Authors' Addresses 1578 David M'Raihi 1579 Verisign, Inc. 1580 487 E. Middlefield Road 1581 Mountain View, CA 94043 1582 USA 1584 Email: davidietf@gmail.com 1586 Johan Rydell 1587 Portwise, Inc. 1588 275 Hawthorne Ave, Suite 119 1589 Palo Alto, CA 94301 1590 USA 1592 Email: johanietf@gmail.com 1594 Salah Machani 1595 Diversinet Corp. 1596 2225 Sheppard Avenue East, Suite 1801 1597 Toronto, Ontario M2J 5C2 1598 Canada 1600 Email: smachani@diversinet.com 1601 David Naccache 1602 Ecole Normale Superieure 1603 ENS DI, 45 rue d'Ulm 1604 Paris, 75005 1605 France 1607 Email: david.naccache@ens.fr 1609 Siddarth Bajaj 1610 Symantec Corp. 1611 350 Ellis Street 1612 Mountain View, CA 94043 1613 USA 1615 Email: siddharthietf@gmail.com