idnits 2.17.00 (12 Aug 2021) /tmp/idnits21679/draft-mraihi-oath-hmac-otp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1329. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([BCK1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 255 has weird spacing: '... Digit num...' == Line 1167 has weird spacing: '...eyBytes the ...' == Line 1210 has weird spacing: '...eDigits the ...' == Line 1212 has weird spacing: '...hecksum a fla...' == Line 1217 has weird spacing: '...ncation will ...' -- 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 (October 2004) is 6426 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 section? 'BCK1' on line 639 looks like a reference -- Missing reference section? 'RFC3668' on line 650 looks like a reference -- Missing reference section? 'OATH' on line 655 looks like a reference -- Missing reference section? '0' on line 302 looks like a reference -- Missing reference section? '1' on line 229 looks like a reference -- Missing reference section? 'BCK2' on line 643 looks like a reference -- Missing reference section? '19' on line 330 looks like a reference -- Missing reference section? 'OffSet' on line 307 looks like a reference -- Missing reference section? 'RFC2119' on line 647 looks like a reference -- Missing reference section? '3' on line 1009 looks like a reference -- Missing reference section? '8' on line 1242 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. M'Raihi 3 Category: Informational VeriSign 4 Document: draft-mraihi-oath-hmac-otp-02.txt M. Bellare 5 Expires: April 2005 UCSD 6 F. Hoornaert 7 Vasco 8 D. Naccache 9 Gemplus 10 O. Ranen 11 Aladdin 12 October 2004 14 HOTP: An HMAC-based One Time Password Algorithm 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 or will be disclosed, and any of which I become aware will be 21 disclosed, in accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than a "work in 32 progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This document describes an algorithm to generate one-time password 42 values, based on HMAC [BCK1]. A security analysis of the algorithm 43 is presented, and important parameters related to the secure 44 deployment of the algorithm are discussed. The proposed algorithm 45 can be used across a wide range of network applications ranging 46 from remote VPN access, Wi-Fi network logon to transaction-oriented 47 Web applications. 49 This work is a joint effort by the OATH (Open AuTHentication) 50 membership to specify an algorithm that can be freely distributed 51 to the technical community. The authors believe that a common and 52 HOTP: An HMAC-based One Time Password Algorithm October 2004 54 shared algorithm will facilitate adoption of two-factor 55 authentication on the Internet by enabling interoperability across 56 commercial and open-source implementations. 58 Table of Contents 60 1. Overview......................................................2 61 2. Introduction................................................3 62 3. Requirements Terminology....................................4 63 4. Algorithm Requirements......................................4 64 5. HOTP Algorithm..............................................5 65 5.1 Notation and Symbols........................................5 66 5.2 Description.................................................6 67 5.3 Generating an HOTP value....................................6 68 5.4 Example of HOTP computation for Digit = 6...................7 69 6. Security and Deployment Considerations......................8 70 6.1 Authentication Protocol Requirements........................8 71 6.2 Validation of HOTP values...................................8 72 6.3 Throttling at the server....................................9 73 6.4 Resynchronization of the counter............................9 74 7. HOTP Algorithm Security: Overview..........................10 75 8. Protocol Extensions and Improvements.........................11 76 8.1 Number of Digits...........................................11 77 8.2 Alpha-numeric Values.......................................11 78 8.3 Sequence of HOTP values....................................11 79 8.4 A Counter-based Re-Synchronization Method..................12 80 9. Conclusion.................................................12 81 10. Acknowledgements...........................................13 82 11. Contributors...............................................13 83 12. References.................................................13 84 12.1 Normative................................................13 85 12.2 Informative..............................................13 86 13. Authors' Addresses.........................................14 87 Appendix A - HOTP Algorithm Security: Detailed Analysis.........14 88 A.1 Definitions and Notations...................................15 89 A.2 The idealized algorithm: HOTP-IDEAL.........................15 90 A.3 Model of Security...........................................15 91 A.4 Security of the ideal authentication algorithm..............17 92 A.4.1 From bits to digits.......................................17 93 A.4.2 Brute force attacks.......................................18 94 A.4.3 Brute force attacks are the best possible attacks.........19 95 A.5 Security Analysis of HOTP...................................20 96 Appendix B - HOTP Algorithm: Reference Implementation...........22 97 Appendix C - HOTP Algorithm: Test Values........................26 99 1. Overview 101 The document introduces first the context around the HOTP 102 algorithm. In section 4, the algorithm requirements are listed and 103 HOTP: An HMAC-based One Time Password Algorithm October 2004 105 in section 5, the HOTP algorithm is described. Sections 6 and 7 106 focus on the algorithm security. Section 8 proposes some extensions 107 and improvements, and Section 9 concludes this document. The 108 interested reader will find in the Appendix a detailed, full-fledge 109 analysis of the algorithm security: an idealized version of the 110 algorithm is evaluated, and then the HOTP algorithm security is 111 analyzed. 113 2. Introduction 115 Today, deployment of two-factor authentication remains extremely 116 limited in scope and scale. Despite increasingly higher levels of 117 threats and attacks, most Internet applications still rely on weak 118 authentication schemes for policing user access. The lack of 119 interoperability among hardware and software technology vendors has 120 been a limiting factor in the adoption of two-factor authentication 121 technology. In particular, the absence of open specifications has 122 led to solutions where hardware and software components are tightly 123 coupled through proprietary technology, resulting in high cost 124 solutions, poor adoption and limited innovation. 126 In the last two years, the rapid rise of network threats has 127 exposed the inadequacies of static passwords as the primary mean of 128 authentication on the Internet. At the same time, the current 129 approach that requires an end-user to carry an expensive, 130 single-function device that is only used to authenticate to the 131 network is clearly not the right answer. For two factor 132 authentication to propagate on the Internet, it will have to be 133 embedded in more flexible devices that can work across a wide range 134 of applications. 136 The ability to embed this base technology while ensuring broad 137 interoperability require that it be made freely available to the 138 broad technical community of hardware and software developers. Only 139 an open system approach will ensure that basic two-factor 140 authentication primitives can be built into the next-generation of 141 consumer devices such USB mass storage devices, IP phones, and 142 personal digital assistants). 144 One Time Password is certainly one of the simplest and most popular 145 forms of two-factor authentication for securing network access. For 146 example, in large enterprises, Virtual Private Network access often 147 requires the use of One Time Password tokens for remote user 148 authentication. One Time Passwords are often preferred to stronger 149 forms of authentication such as PKI or biometrics because an 150 air-gap device does not require the installation of any client 151 desktop software on the user machine, therefore allowing them to 152 roam across multiple machines including home computers, kiosks and 153 personal digital assistants. 155 HOTP: An HMAC-based One Time Password Algorithm October 2004 157 This draft proposes a simple One Time Password algorithm that can 158 be implemented by any hardware manufacturer or software developer 159 to create interoperable authentication devices and software agents. 160 The algorithm is event-based so that it can be embedded in high 161 volume devices such as Java smart cards, USB dongles and GSM SIM 162 cards. The presented algorithm is made freely available to the 163 developer community under the terms and conditions of the IETF 164 Intellectual Property Rights [RFC3668]. 166 The authors of this document are members of the Open AuTHentication 167 initiative [OATH]. The initiative was created in 2004 to facilitate 168 collaboration among strong authentication technology providers. 170 3. Requirements Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 174 this document are to be interpreted as described in RFC 2119. 176 4. Algorithm Requirements 178 This section presents the main requirements that drove this 179 algorithm design. A lot of emphasis was placed on end-consumer 180 usability as well as the ability for the algorithm to be 181 implemented by low cost hardware that may provide minimal user 182 interface capabilities. In particular, the ability to embed the 183 algorithm into high volume SIM and Java cards was a fundamental 184 pre-requisite. 186 R1 - The algorithm MUST be sequence or counter-based: One of the 187 goals is to have the HOTP algorithm embedded in high volume devices 188 such as Java smart cards, USB dongles and GSM SIM cards. 190 R2 - The algorithm SHOULD be economical to implement in hardware by 191 minimizing requirements on battery, number of buttons, 192 computational horsepower, and size of LCD display. The algorithm 193 MUST work with tokens that do not supports any numeric input, but 194 MAY also be used with more sophisticated devices such as secure 195 PIN-pads. 197 R3 - The value displayed on the token MUST be easily read and 198 entered by the user: This requires the HOTP value to be of 199 reasonable length. The HOTP value must be at least a 6-digit value. 200 It is also desirable that the HOTP value be 'numeric only' so that 201 it can be easily entered on restricted devices such as phones. 203 HOTP: An HMAC-based One Time Password Algorithm October 2004 205 R4 - There MUST be user-friendly mechanisms available to 206 resynchronize the counter. The sections 6.4 and 8.4 detail the 207 resynchronization mechanism proposed in this draft. 209 R5 - The algorithm MUST use a strong shared secret. The length of 210 the shared secret MUST be at least 128 bits. This draft RECOMMENDs 211 a shared secret length of 160 bits. 213 5. HOTP Algorithm 215 In this section, we introduce the notation and describe the HOTP 216 algorithm basic blocks - the base function to compute an HMAC-SHA-1 217 value and the truncation method to extract an HOTP value. 219 5.1 Notation and Symbols 221 A string always means a binary string, meaning a sequence of zeros 222 and ones. 224 If s is a string then |s| denotes its length. 226 If n is a number then |n| denotes its absolute value. 228 If s is a string then s[i] denotes its i-th bit. We start numbering 229 the bits at 0, so s = s[0]s[1]..s[n-1] where n = |s| is the length 230 of s. 232 Let StToNum (String to Number) denote the function which as input a 233 string s returns the number whose binary representation is s. 234 (For example StToNum(110) = 6). 236 Here is a list of symbols used in this document. 238 Symbol Represents 239 ------------------------------------------------------------------- 240 C 8-byte counter value, the moving factor. This counter 241 MUST be synchronized between the HOTP generator (client) 242 and the HOTP validator (server); 244 K shared secret between client and server; each HOTP 245 generator has a different and unique secret K; 247 T throttling parameter: the server will refuse connections 248 from a user after T unsuccessful authentication attempts; 250 s resynchronization parameter: the server will attempt to 251 verify a received authenticator across s consecutive 252 counter values; 253 HOTP: An HMAC-based One Time Password Algorithm October 2004 255 Digit number of digits in an HOTP value; system parameter. 257 5.2 Description 259 The HOTP algorithm is based on an increasing counter value and a 260 static symmetric key known only to the token and the validation 261 service. In order to create the HOTP value, we will use the 262 HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2]. 264 As the output of the HMAC-SHA1 calculation is 160 bits, we must 265 truncate this value to something that can be easily entered by a 266 user. 268 HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) 270 Where: 271 - Truncate represents the function that converts an HMAC-SHA-1 272 value into an HOTP value as defined in Section 5.3. 274 The Key (K) and the Counter (C) values are hashed high-order byte 275 first. 277 The HOTP values generated by the HOTP generator are treated as big 278 endian. 280 5.3 Generating an HOTP value 282 We can describe the operations in 3 distinct steps: 284 Step 1: Generate an HMAC-SHA-1 value 285 Let HS = HMAC-SHA-1(K,C) // HS is a 20 byte string 287 Step 2: Generate a 4-byte string (Dynamic Truncation) 288 Let Sbits = DT(HS) // DT, defined in Section 6.3.1 289 // returns a 31 bit string 291 Step 3: Compute an HOTP value 292 Let Snum = StToNum(S) // Convert S to a number in 293 0...2^{31}-1 294 Return D = Snum mod 10^Digit // D is a number in the range 295 0...10^{Digit}-1 297 The Truncate function performs Step 2 and Step 3, i.e. the dynamic 298 truncation and then the reduction modulo 10^Digit. The purpose of 299 the dynamic offset truncation technique is to extract a 4-byte 300 dynamic binary code from a 160-bit (20-byte) HMAC-SHA1 result. 302 DT(String) // String = String[0]...String[19] 303 HOTP: An HMAC-based One Time Password Algorithm October 2004 305 Let OffsetBits be the low order four bits of String[19] 306 Offset = StToNum(OffSetBits) // 0 <= OffSet <= 15 307 Let P = String[OffSet]...String[OffSet+3] 308 Return the Last 31 bits of P 310 The reason for masking the most significant bit of P is to avoid 311 confusion about signed vs. unsigned modulo computations. Different 312 processors perform these operations differently, and masking out 313 the signed bit removes all ambiguity. 315 Implementations MUST extract a 6-digit code at a minimum and 316 possibly 7 and 8-digit code. Depending on security requirements, 317 Digit = 7 or more SHOULD be considered in order to extract a longer 318 HOTP value. 320 The following paragraph is an example of using this technique for 321 Digit = 6, i.e. that a 6-digit HOTP value is calculated from the 322 HMAC value. 324 5.4 Example of HOTP computation for Digit = 6 326 The following code example describes the extraction of a dynamic 327 binary code given that hmac_result is a byte array with the 328 HMAC-SHA1 result: 330 int offset = hmac_result[19] & 0xf ; 331 int bin_code = (hmac_result[offset] & 0x7f) << 24 332 | (hmac_result[offset+1] & 0xff) << 16 333 | (hmac_result[offset+2] & 0xff) << 8 334 | (hmac_result[offset+3] & 0xff) ; 336 SHA-1 HMAC Bytes (Example) 338 ------------------------------------------------------------- 339 | Byte Number | 340 ------------------------------------------------------------- 341 |00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19| 342 ------------------------------------------------------------- 343 | Byte Value | 344 ------------------------------------------------------------- 345 |1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a| 346 -------------------------------***********----------------++| 348 * The last byte (byte 19) has the hex value 0x5a. 349 * The value of the lower four bits is 0xa (the offset value). 350 * The offset value is byte 10 (0xa). 351 * The value of the 4 bytes starting at byte 10 is 0x50ef7f19, 352 which is the dynamic binary code DBC1 353 HOTP: An HMAC-based One Time Password Algorithm October 2004 355 * The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19 356 * HOTP = DBC2 modulo 10^6 = 872921. 358 We treat the dynamic binary code as a 31-bit, unsigned, big-endian 359 integer; the first byte is masked with a 0x7f. 361 We then take this number modulo 1,000,000 (10^6) to generate the 362 6-digit HOTP value 872921 decimal. 364 6. Security and Deployment Considerations 366 Any One-Time Password algorithm is only as secure as the 367 application and the authentication protocols that implement it. 368 Therefore, this section discusses the critical security 369 requirements that our choice of algorithm imposes on the 370 authentication protocol and validation software. The parameters T 371 and s discussed in this section have a significant impact on the 372 security - further details in Section 7 elaborate on the relations 373 between these parameters and their impact on the system security. 375 6.1 Authentication Protocol Requirements 377 We introduce in this section some requirements for a protocol P 378 implementing HOTP as the authentication method between a prover and 379 a verifier. 381 RP1 - P MUST be two-factor, i.e. something you know (secret code 382 such as a Password, Pass phrase, PIN code, etc.) and something you 383 have (token). The secret code is known only to the user and usually 384 entered with the one-time password value for authentication purpose 385 (two-factor authentication). 387 RP3 - P MUST NOT be vulnerable to brute force attacks. This implies 388 that a throttling/lockout scheme is REQUIRED on the validation 389 server side. 391 RP4 - P SHOULD be implemented with respect to the state of the art 392 in terms of security, in order to avoid the usual attacks and risks 393 associated with the transmission of sensitive data over a public 394 network (privacy, replay attacks, etc.) 396 6.2 Validation of HOTP values 398 The HOTP client (hardware or software token) increments its counter 399 and then calculates the next HOTP value HOTP-client. If the value 400 received by the authentication server matches the value calculated 401 by the client, then the HOTP value is validated. In this case, the 402 server increments the counter value by one. 404 HOTP: An HMAC-based One Time Password Algorithm October 2004 406 If the value received by the server does not match the value 407 calculated by the client, the server initiate the resynch protocol 408 (look-ahead window) before it requests another pass. 410 If the resynch fails, the server asks then for another 411 authentication pass of the protocol to take place, until the 412 maximum number of authorized attempts is reached. 414 If and when the maximum number of authorized attempts is reached, 415 the server SHOULD lock out the account and initiate a procedure to 416 inform the user. 418 6.3 Throttling at the server 420 Truncating the HMAC-SHA1 value to a shorter value makes a brute 421 force attack possible. Therefore, the authentication server needs 422 to detect and stop brute force attacks. 424 We RECOMMEND setting a throttling parameter T, which defines the 425 maximum number of possible attempts for One-Time-Password 426 validation. The validation server manages individual counters per 427 HOTP device in order to take note of any failed attempt. We 428 RECOMMEND T not to be too large, particularly if the 429 resynchronization method used on the server is window-based, and 430 the window size is large. T SHOULD be set as low as possible, while 431 still ensuring usability is not significantly impacted. 433 6.4 Resynchronization of the counter 435 Although the server's counter value is only incremented after a 436 successful HOTP authentication, the counter on the token is 437 incremented every time a new HOTP is requested by the user. Because 438 of this, the counter values on the server and on the token might be 439 out of synchronization. 441 We RECOMMEND setting a look-ahead parameter s on the server, which 442 defines the size of the look-ahead window. In a nutshell, the 443 server can recalculate the next s HOTP-server values, and check 444 them against the received HOTP-client. 446 Synchronization of counters in this scenario simply requires the 447 server to calculate the next HOTP values and determine if there is 448 a match. Optionally, the system MAY require the user to send a 449 sequence of (say 2, 3) HOTP values for resynchronization purpose, 450 since forging a sequence of consecutive HOTP values is even more 451 difficult than guessing a single HOTP value. 453 HOTP: An HMAC-based One Time Password Algorithm October 2004 455 The upper bound set by the parameter s ensures the server does not 456 go on checking HOTP values forever (causing a DoS attack) and also 457 restricts the space of possible solutions for an attacker trying to 458 manufacture HOTP values. s SHOULD be set as low as possible, while 459 still ensuring usability is not impacted. 461 7. HOTP Algorithm Security: Overview 463 The conclusion of the security analysis detailed in the Appendix 464 section is that, for all practical purposes, the outputs of the 465 dynamic truncation (DT) on distinct counter inputs are uniformly 466 and independently distributed 31-bit strings. 468 The security analysis then details the impact of the conversion 469 from a string to an integer and the final reduction modulo 470 10^Digit, where Digit is the number of digits in an HOTP value. 472 The analysis demonstrates that these final steps introduce a 473 negligible bias, which does not impact the security of the HOTP 474 algorithm, in the sense that the best possible attack against the 475 HOTP function is the brute force attack. 477 Assuming an adversary is able to observe numerous protocol 478 exchanges and collect sequences of successful authentication 479 values. This adversary, trying to build a function F to generate 480 HOTP values based on his observations, will not have a significant 481 advantage over a random guess. 483 The logical conclusion is simply that is best strategy will once 484 again be to perform a brute force attack to enumerate and try all 485 the possible values. 487 Considering the security analysis in the Appendix section of this 488 document, without loss of generality, we can approximate closely 489 the security of the HOTP algorithm by the following formula: 491 Sec = sv/10^Digit 493 Where: 494 - Sec is the probability of success of the adversary 495 - s stands for the look-ahead synchronization window size; 496 - v stands for the number of verification attempts; 497 - Digit stands for the number of digits in HOTP values. 499 Obviously, we can play with s, T (the Throttling parameter that 500 would limit the number of attempts by an attacker) and Digit until 501 achieving a certain level of security, still preserving the system 502 usability. 504 HOTP: An HMAC-based One Time Password Algorithm October 2004 506 8. Protocol Extensions and Improvements 508 We introduce in this section several enhancements and suggestions 509 to further improve the security of the algorithm HOTP 511 8.1 Number of Digits 513 A simple enhancement in terms of security would be to extract more 514 digits from the HMAC-SHA1 value. 516 For instance, calculating the HOTP value modulo 10^8 to build an 517 8-digit HOTP value would reduce the probability of success of the 518 adversary from sv/10^6 to sv/10^8. 520 This could give the opportunity to improve usability, e.g. by 521 increasing T and/or s, while still achieving a better security 522 overall. For instance, s = 10 and 10v/10^8 = v/10^7 < v/10^6 which 523 is the theoretical optimum for 6-digit code when s = 1. 525 8.2 Alpha-numeric Values 527 Another option is to use A-Z and 0-9 values; or rather a subset of 528 32 symbols taken from the alphanumerical alphabet in order to avoid 529 any confusion between characters: 0, O and Q as well as l, 1 and I 530 are very similar, and can look the same on a small display. 532 The immediate consequence is that the security is now in the order 533 of sv/32^6 for a 6-digit HOTP value and sv/32^8 for an 8-digit HOTP 534 value. 536 32^6 > 10^9 so the security of a 6-alphanumeric HOTP code is 537 slightly better than a 9-digit HOTP value, which is the maximum 538 length of an HOTP code supported by the proposed algorithm. 540 32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is 541 significantly better than a 9-digit HOTP value. 543 Depending on the application and token/interface used for 544 displaying and entering the HOTP value, the choice of alphanumeric 545 values could be a simple and efficient way to improve security at a 546 reduced cost and impact on users. 548 8.3 Sequence of HOTP values 550 As we suggested for the resynchronization to enter a short sequence 551 (say 2 or 3) of HOTP values, we could generalize the concept to the 552 protocol, and add a parameter L that would define the length of the 553 HOTP sequence to enter. 555 HOTP: An HMAC-based One Time Password Algorithm October 2004 557 Per default, the value L SHOULD be set to 1, but if security needs 558 to be increased, users might be asked (possibly for a short period 559 of time, or a specific operation) to enter L HOTP values. 561 This is another way, without increasing the HOTP length or using 562 alphanumeric values to tighten security. 564 Note: The system MAY also be programmed to request synchronization 565 on a regular basis (e.g. every night, or twice a week, etc.) and to 566 achieve this purpose, ask for a sequence of L HOTP values. 568 8.4 A Counter-based Re-Synchronization Method 570 In this case, we assume that the client can access and send not 571 only the HOTP value but also other information, more specifically 572 the counter value. 574 A more efficient and secure method for resynchronization is 575 possible in this case. The client application will not send the 576 HOTP-client value only, but the HOTP-client and the related 577 C-client counter value, the HOTP value acting as a message 578 authentication code of the counter. 580 Resynchronization Counter-based Protocol (RCP) 581 ---------------------------------------------- 583 The server accepts if the following are all true, where C-server is 584 its own current counter value: 586 1) C-client >= C-server 587 2) C-client - C-server <= s 588 3) Check that HOTP-client is valid HOTP(K,C-Client) 589 4) If true, the server sets C to C-client + 1 and client 590 is authenticated 592 In this case, there is no need for managing a look-ahead window 593 anymore. The probability of success of the adversary is only v/10^6 594 or roughly v in one million. A side benefit is obviously to be able 595 to increase s "infinitely" and therefore improve the system 596 usability without impacting the security. 598 This resynchronization protocol SHOULD be use whenever the related 599 impact on the client and server applications is deemed acceptable. 601 9. Conclusion 603 This draft describes HOTP, a HMAC-based One-Time Password 604 algorithm. It also recommends the preferred implementation and 605 related modes of operations for deploying the algorithm. 607 HOTP: An HMAC-based One Time Password Algorithm October 2004 609 The draft also exhibits elements of security and demonstrates that 610 the HOTP algorithm is practical and sound, the best possible attack 611 being a brute force attack that can be prevented by careful 612 implementation of countermeasures in the validation server. 614 Eventually, several enhancements have been proposed, in order to 615 improve security if needed for specific applications. 617 10. Acknowledgements 619 The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren 620 Hart and Nico Popp for their help during the conception and 621 redaction of this document. 623 11. Contributors 625 The authors of this draft would like to emphasize the role of two 626 persons who have made a key contribution to this document: 628 - Laszlo Elteto is system architect with SafeNet, Inc. 630 - Ernesto Frutos is director of Engineering with Authenex, Inc. 632 Without their advice and valuable inputs, this draft would not be 633 the same. 635 12. References 637 12.1 Normative 639 [BCK1] M. Bellare, R. Canetti, and H. Krawczyk, Keyed Hash 640 Functions and Message Authentication, Proceedings of 641 Crypto'96, LNCS Vol. 1109, pp. 1-15. 643 [BCK2] M. Bellare, R. Canetti, and H. Krawczyk, HMAC: 644 Keyed-Hashing for Message Authentication, IETF Network 645 Working Group, RFC 2104, February 1997. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC3668] Bradner, S., "Intellectual Propery Rights in IETF 651 Technology", BCP 79, RFC 3668, February 2004. 653 12.2 Informative 655 [OATH] www.openauthentication.org, Initiative for Open 656 AuTHentication 657 HOTP: An HMAC-based One Time Password Algorithm October 2004 659 13. Authors' Addresses 661 Primary point of contact (for sending comments and question): 663 David M'Raihi 664 VeriSign, Inc. 665 685 E. Middlefield Road Phone: 1-650-426-3832 666 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 668 Other Authors' contact information: 670 Mihir Bellare 671 Dept of Computer Science and Engineering, Mail Code 0114 672 University of California at San Diego 673 9500 Gilman Drive 674 La Jolla, CA 92093, USA Email: mihir@cs.ucsd.edu 676 Frank Hoornaert 677 VASCO Data Security, Inc. 678 Koningin Astridlaan 164 679 1780 Wemmel, Belgium Email: frh@vasco.com 681 David Naccache 682 Gemplus Innovation 683 34 rue Guynemer, 92447, 684 Issy les Moulineaux, France Email: david.naccache@gemplus.com 685 and 686 Information Security Group, 687 Royal Holloway, 688 University of London, Egham, 689 Surrey TW20 0EX, UK Email: david.naccache@rhul.ac.uk 691 Ohad Ranen 692 Aladdin Knowledge Systems Ltd. 693 15 Beit Oved Street 694 Tel Aviv, Israel 61110 Email: Ohad.Ranen@ealaddin.com 696 Appendix A - HOTP Algorithm Security: Detailed Analysis 698 The security analysis of the HOTP algorithm is summarized in this 699 section. We first detail the best attack strategies, and then 700 elaborate on the security under various assumptions, the impact of 701 the truncation and some recommendations regarding the number of 702 digits. 704 HOTP: An HMAC-based One Time Password Algorithm October 2004 706 We focus this analysis on the case where Digit = 6, i.e. an HOTP 707 function that produces 6-digit values, which is the bare minimum 708 recommended in this draft. 710 A.1 Definitions and Notations 712 We denote by {0,1}^l the set of all strings of length l. 714 Let Z_{n} = {0,.., n - 1}. 716 Let IntDiv(a,b) denote the integer division algorithm that takes 717 input integers a, b where a >= b >= 1 and returns integers (q,r) 718 the quotient and remainder, respectively, of the division of a by 719 b. (Thus a = bq + r and 0 <= r < b.) 721 Let H: {0,1}^k x {0,1}^c --> {0,1}^n be the base function that 722 takes a k-bit key K and c-bit counter C and returns an n-bit output 723 H(K,C). (In the case of HOTP, H is HMAC-SHA-1; we use this formal 724 definition for generalizing our proof of security) 726 A.2 The idealized algorithm: HOTP-IDEAL 728 We now define an idealized counterpart of the HOTP algorithm. In 729 this algorithm, the role of H is played by a random function that 730 forms the key. 732 To be more precise, let Maps(c,n) denote the set of all functions 733 mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key 734 space Maps(c,n), so that a "key" for such an algorithm is a 735 function h from {0,1}^c to {0,1}^n. We imagine this key (function) 736 to be drawn at random. It is not feasible to implement this 737 idealized algorithm, since the key, being a function from is way 738 too large to even store. So why consider it? 740 Our security analysis will show that as long as H satisfies a 741 certain well-accepted assumption, the security of the actual and 742 idealized algorithms is for all practical purposes the same. The 743 task that really faces us, then, is to assess the security of the 744 idealized algorithm. 746 In analyzing the idealized algorithm, we are concentrating on 747 assessing the quality of the design of the algorithm itself, 748 independently of HMAC-SHA-1. This is in fact the important issue. 750 A.3 Model of Security 752 The model exhibits the type of threats or attacks that are being 753 considered and enables to asses the security of HOTP and 754 HOTP: An HMAC-based One Time Password Algorithm October 2004 756 HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the 757 purpose of this security analysis. 759 The scenario we are considering is that a user and server share a 760 key K for ALG. Both maintain a counter C, initially zero, and the 761 user authenticates itself by sending ALG(K,C) to the server. The 762 latter accepts if this value is correct. 764 In order to protect against accidental increment of the user 765 counter, the server, upon receiving a value z, will accept as long 766 as z equals ALG(K,i) for some i in the range C,...,C + s-1, where s 767 is the resynchronization parameter and C is the server counter. If 768 it accepts with some value of i, it then increments its counter to 769 i+ 1. If it does not accept, it does not change its counter value. 771 The model we specify captures what an adversary can do and what it 772 needs to achieve in order to "win." First, the adversary is assumed 773 to be able to eavesdrop, meaning see the authenticator transmitted 774 by the user. Second, the adversary wins if it can get the server to 775 accept an authenticator relative to a counter value for which the 776 user has never transmitted an authenticator. 778 The formal adversary, which we denote by B, starts out knowing 779 which algorithm ALG is being used, knowing the system design and 780 knowing all system parameters. The one and only thing it is not 781 given a priori is the key K shared between the user and the server. 783 The model gives B full control of the scheduling of events. It has 784 access to an authenticator oracle representing the user. By calling 785 this oracle, the adversary can ask the user to authenticate itself 786 and get back the authenticator in return. It can call this oracle 787 as often as it wants and when it wants, using the authenticators it 788 accumulates to perhaps "learn" how to make authenticators itself. 789 At any time, it may also call a verification oracle, supplying the 790 latter with a candidate authenticator of its choice. It wins if the 791 server accepts this accumulator. 793 Consider the following game involving an adversary B that is 794 attempting to compromise the security of an authentication 795 algorithm ALG: K x {0,1}^c --> R. 797 Initializations - A key K is selected at random from K, a counter C 798 is initialized to 0, and the Boolean value win is set to false. 800 Game execution - Adversary B is provided with the two following 801 oracles: 803 Oracle AuthO() 804 O = ALG(K,C) 805 HOTP: An HMAC-based One Time Password Algorithm October 2004 807 C = C + 1 808 Return O to B 810 Oracle VerO() 811 i = C 812 While (i <= C + s - 1 and Win = FALSE) do 813 If O = ALG(K,i) then Win = TRUE; C = i + 1 814 Else i = i + 1 815 Return Win to B 817 AuthO() is the authenticator oracle and VerO() is the verification 818 oracle. 820 Upon execution, B queries the two oracles at will. Let Adv(B) be 821 the probability that win gets set to true in the above game. This 822 is the probability that the adversary successfully impersonates the 823 user. 825 Our goal is to assess how large this value can be as a function of 826 the number v of verification queries made by B, the number a of 827 authenticator oracle queries made by B, and the running time t of 828 B. This will tell us how to set the throttle, which effectively 829 upper bounds v. 831 A.4 Security of the ideal authentication algorithm 833 This section summarizes the security analysis of HOTP-IDEAL, 834 starting with the impact of the conversion modulo 10^Digit and 835 then, focusing on the different possible attacks. 837 A.4.1 From bits to digits 839 The dynamic offset truncation of a random n-bit string yields a 840 random 31-bit string. What happens to the distribution when it is 841 taken modulo m = 10^Digit, as done in HOTP? 843 The following lemma estimates the biases in the outputs in this 844 case. 846 Lemma 1 847 Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in 848 Z_{m} let: 850 P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}] 852 Then for any z in Z_{m} 854 P_{N,m}(z) = (q + 1) / N if 0 <= z < r 855 HOTP: An HMAC-based One Time Password Algorithm October 2004 857 q / N if r <= z < m 859 Proof of Lemma 1 860 Let the random variable X be uniformly distributed over Z_{N}. 861 Then: 863 P_{N,m}(z) = Pr [X mod m = z] 865 = Pr [X < mq] * Pr [X mod m = z| X < mq] 866 + Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N] 868 = mq/N * 1/m + 869 (N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq 870 0 if N - mq <= z <= m 872 = q/N + 873 r/N * 1 / r if 0 <= z < N - mq 874 0 if r <= z <= m 876 Simplifying yields the claimed equation. 878 Let N = 2^31, d = 6 and m = 10^d. If x is chosen at random from 879 Z_{N} (meaning, is a random 31-bit string), then reducing it to a 880 6-digit number by taking x mod m does not yield a random 6-digit 881 number. 883 Rather, x mod m is distributed as shown in the following table: 885 Values Probability that each appears as output 886 ---------------------------------------------------------------- 887 0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6 888 483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6 890 If X is uniformly distributed over Z_{2^31} (meaning is a random 891 31-bit string) then the above shows the probabilities for different 892 outputs of X mod 10^6. The first set of values appear with 893 probability slightly greater than 10^-6, the rest with probability 894 slightly less, meaning the distribution is slightly non-uniform. 896 However, as the Figure indicates, the bias is small and as we will 897 see later, negligible: the probabilities are very close to 10^-6. 899 A.4.2 Brute force attacks 901 If the authenticator consisted of d random digits, then a brute 902 force attack using v verification attempts would succeed with 903 probability sv/10^Digit. 905 HOTP: An HMAC-based One Time Password Algorithm October 2004 907 However, an adversary can exploit the bias in the outputs of HOTP- 908 IDEAL, predicted by Lemma 1, to mount a slightly better attack. 910 Namely, it makes authentication attempts with authenticators which 911 are the most likely values, meaning the ones in the range 0,...,r - 912 1, where (q,r) = IntDiv(2^31,10^Digit). 914 The following specifies an adversary in our model of security that 915 mounts the attack. It estimates the success probability as a 916 function of the number of verification queries. 918 For simplicity, we assume the number of verification queries is at 919 most r. With N = 2^31 and m = 10^6 we have r = 483,648, and the 920 throttle value is certainly less than this, so this assumption is 921 not much of a restriction. 923 Proposition 1 924 Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume 925 s <= m. The brute-force attack adversary B-bf attacks HOTP using v 926 <= r verification oracle queries. This adversary makes no 927 authenticator oracle queries, and succeeds with probability 929 Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s 931 which is roughly equals to 933 sv * (q+1)/2^31 935 With m = 10^6 we get q = 2,147. In that case, the brute force 936 attack using v verification attempts succeeds with probability 938 Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6 940 As this equation shows, the resynchronization parameter s has a 941 significant impact in that the adversary's success probability is 942 proportional to s. This means that s cannot be made too large 943 without compromising security. 945 A.4.3 Brute force attacks are the best possible attacks 947 A central question is whether there are attacks any better than the 948 brute force one. In particular, the brute force attack did not 949 attempt to collect authenticators sent by the user and try to 950 cryptanalyze them in an attempt to learn how to better construct 951 authenticators. Would doing this help? Is there some way to "learn" 952 how to build authenticators that result in a higher success rate 953 than given by the brute-force attack? 954 HOTP: An HMAC-based One Time Password Algorithm October 2004 956 The following says the answer to these questions is no. No matter 957 what strategy the adversary uses, and even if it sees, and tries to 958 exploit, the authenticators from authentication attempts of the 959 user, its success probability will not be above that of the brute 960 force attack - this is true as long as the number of 961 authentications it observes is not incredibly large. This is 962 valuable information regarding the security of the scheme. 964 Proposition 2 965 Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B 966 be any adversary attacking HOTP-IDEAL using v verification oracle 967 queries and a <= 2^c - s authenticator oracle queries. Then 969 Adv(B) < = sv * (q+1)/ 2^31 971 Note: This result is conditional on the adversary not seeing more 972 than 2^c - s authentications performed by the user, which is hardly 973 restrictive as long as c is large enough. 975 With m = 10^6 we get q = 2,147. In that case, Proposition 2 says 976 that any adversary B attacking HOTP-IDEAL and making v verification 977 attempts succeeds with probability at most 979 Equation 1 980 sv * 2148/2^31 roughly = sv * 1.00024045/10^6 982 Meaning, B's success rate is not more than that achieved by the 983 brute force attack. 985 A.5 Security Analysis of HOTP 987 We have analyzed in the previous sections, the security of the 988 idealized counterparts HOTP-IDEAL of the actual authentication 989 algorithm HOTP. We now show that, under appropriate and 990 well-believed assumption on H, the security of the actual 991 algorithms is essentially the same as that of its idealized 992 counterpart. 994 The assumption in question is that H is a secure pseudorandom 995 function, or PRF, meaning that its input-output values are 996 indistinguishable from those of a random function in practice. 998 Consider an adversary A that is given an oracle for a function f: 999 {0,1}^c --> {0, 1}^n and eventually outputs a bit. We denote Adv(A) 1000 as the prf-advantage of A, which represents how well the adversary 1001 does at distinguishing the case where its oracle is H(K,.) from the 1002 case where its oracle is a random function of {0,1}^c to {0,1}^n. 1004 HOTP: An HMAC-based One Time Password Algorithm October 2004 1006 One possible attack is based on exhaustive search for the key K. If 1007 A runs for t steps and T denotes the time to perform one 1008 computation of H, its prf-advantage from this attack turns out to 1009 be (t/T)2^-k . Another possible attack is a birthday one [3], 1010 whereby A can attain advantage p^2/2^n in p oracle queries and 1011 running time about pT. 1013 Our assumption is that these are the best possible attacks. This 1014 translates into the following. 1016 Assumption 1 1017 Let T denotes the time to perform one computation of H. Then if A 1018 is any adversary with running time at most t and making at most p 1019 oracle queries, 1021 Adv(A) <= (t/T)/2^k + p^2/2^n 1023 In practice this assumption means that H is very secure as PRF. For 1024 example, given that k = n = 160, an attacker with running time 2^60 1025 and making 2^40 oracle queries has advantage at most (about) 2^-80. 1027 Theorem 1 1028 Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B 1029 be any adversary attacking HOTP using v verification oracle 1030 queries, a <= 2^c - s authenticator oracle queries, and running 1031 time t. Let T denote the time to perform one computation of H. If 1032 Assumption 1 is true then 1034 Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n 1036 In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller 1037 than the sv(q + 1)/2^n term, so that the above says that for all 1038 practical purposes the success rate of an adversary attacking HOTP 1039 is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP 1040 algorithm is in practice essentially as good as its idealized 1041 counterpart. 1043 In the case m = 10^6 of a 6-digit output this means that an 1044 adversary making v authentication attempts will have a success rate 1045 that is at most that of Equation 1. 1047 For example, consider an adversary with running time at most 2^60 1048 that sees at most 2^40 authentication attempts of the user. Both 1049 these choices are very generous to the adversary, who will 1050 typically not have these resources, but we are saying that even 1051 such a powerful adversary will not have more success than indicated 1052 by Equation 1. 1054 HOTP: An HMAC-based One Time Password Algorithm October 2004 1056 We can safely assume sv <= 2^40 due to the throttling and bounds on 1057 s. So: 1058 (t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160 1059 roughly <= 2^-78 1061 which is much smaller than the success probability of Equation 1 1062 and negligible compared to it. 1064 Appendix B - HOTP Algorithm: Reference Implementation 1066 /* 1067 * OneTimePasswordAlgorithm.java 1068 * OATH Initiative, 1069 * HOTP one-time password algorithm 1070 * 1071 */ 1073 /* Copyright (C) 2004, OATH. All rights reserved. 1074 * 1075 * License to copy and use this software is granted provided that it 1076 * is identified as the "OATH HOTP Algorithm" in all material 1077 * mentioning or referencing this software or this function. 1078 * 1079 * License is also granted to make and use derivative works provided 1080 * that such works are identified as 1081 * "derived from OATH HOTP algorithm" 1082 * in all material mentioning or referencing the derived work. 1083 * 1084 * OATH (Open AuTHentication) and its members make no 1085 * representations concerning either the merchantability of this 1086 * software or the suitability of this software for any particular 1087 * purpose. 1088 * 1089 * It is provided "as is" without express or implied warranty 1090 * of any kind and OATH AND ITS MEMBERS EXPRESSELY DISCLAIMS 1091 * ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software. 1092 * 1093 * These notices must be retained in any copies of any part of this 1094 * documentation and/or software. 1095 */ 1097 package org.openauthentication.otp; 1099 import java.io.IOException; 1100 import java.io.File; 1101 import java.io.DataInputStream; 1102 import java.io.FileInputStream ; 1103 import java.lang.reflect.UndeclaredThrowableException; 1104 HOTP: An HMAC-based One Time Password Algorithm October 2004 1106 import java.security.GeneralSecurityException; 1107 import java.security.NoSuchAlgorithmException; 1108 import java.security.InvalidKeyException; 1110 import javax.crypto.Mac; 1111 import javax.crypto.spec.SecretKeySpec; 1113 /** 1114 * This class contains static methods that are used to calculate the 1115 * One-Time Password (OTP) using 1116 * JCE to provide the HMAC-SHA1. 1117 * 1118 * @author Loren Hart 1119 * @version 1.0 1120 */ 1121 public class OneTimePasswordAlgorithm { 1122 private OneTimePasswordAlgorithm() {} 1124 // These are used to calculate the check-sum digits. 1125 // 0 1 2 3 4 5 6 7 8 9 1126 private static final int[] doubleDigits = 1127 { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 }; 1129 /** 1130 * Calculates the checksum using the credit card algorithm. 1131 * This algorithm has the advantage that it detects any single 1132 * mistyped digit and any single transposition of 1133 * adjacent digits. 1134 * 1135 * @param num the number to calculate the checksum for 1136 * @param digits number of significant places in the number 1137 * 1138 * @return the checksum of num 1139 */ 1140 public static int calcChecksum(long num, int digits) { 1141 boolean doubleDigit = true; 1142 int total = 0; 1143 while (0 < digits--) { 1144 int digit = (int) (num % 10); 1145 num /= 10; 1146 if (doubleDigit) { 1147 digit = doubleDigits[digit]; 1148 } 1149 total += digit; 1150 doubleDigit = !doubleDigit; 1151 } 1152 int result = total % 10; 1153 if (result > 0) { 1154 result = 10 - result; 1155 HOTP: An HMAC-based One Time Password Algorithm October 2004 1157 } 1158 return result; 1159 } 1161 /** 1162 * This method uses the JCE to provide the HMAC-SHA1 1163 * algorithm. 1164 * HMAC computes a Hashed Message Authentication Code and 1165 * in this case SHA1 is the hash algorithm used. 1166 * 1167 * @param keyBytes the bytes to use for the HMAC-SHA1 key 1168 * @param text the message or text to be authenticated. 1169 * 1170 * @throws NoSuchAlgorithmException if no provider makes 1171 * either HmacSHA1 or HMAC-SHA1 1172 * digest algorithms available. 1173 * @throws InvalidKeyException 1174 * The secret provided was not a valid HMAC-SHA1 key. 1175 * 1176 */ 1178 public static byte[] hmac_sha1(byte[] keyBytes, byte[] text) 1179 throws NoSuchAlgorithmException, InvalidKeyException 1180 { 1181 // try { 1182 Mac hmacSha1; 1183 try { 1184 hmacSha1 = Mac.getInstance("HmacSHA1"); 1185 } catch (NoSuchAlgorithmException nsae) { 1186 hmacSha1 = Mac.getInstance("HMAC-SHA1"); 1187 } 1188 SecretKeySpec macKey = 1189 new SecretKeySpec(keyBytes, "RAW"); 1190 hmacSha1.init(macKey); 1191 return hmacSha1.doFinal(text); 1192 // } catch (GeneralSecurityException gse) { 1193 // throw new UndeclaredThrowableException(gse); 1194 // } 1195 } 1197 private static final int[] DIGITS_POWER 1198 // 0 1 2 3 4 5 6 7 8 1199 = {1,10,100,1000,10000,100000,1000000,10000000,100000000}; 1201 /** 1202 * This method generates an OTP value for the given 1203 * set of parameters. 1204 * 1205 * @param secret the shared secret 1206 HOTP: An HMAC-based One Time Password Algorithm October 2004 1208 * @param movingFactor the counter, time, or other value that 1209 * changes on a per use basis. 1210 * @param codeDigits the number of digits in the OTP, not 1211 * including the checksum, if any. 1212 * @param addChecksum a flag that indicates if a checksum digit 1213 * should be appended to the OTP. 1214 * @param truncationOffset the offset into the MAC result to 1215 * begin truncation. If this value is out of 1216 * the range of 0 ... 15, then dynamic 1217 * truncation will be used. 1218 * Dynamic truncation is when the last 4 1219 * bits of the last byte of the MAC are 1220 * used to determine the start offset. 1221 * @throws NoSuchAlgorithmException if no provider makes 1222 * either HmacSHA1 or HMAC-SHA1 1223 * digest algorithms available. 1224 * @throws InvalidKeyException 1225 * The secret provided was not 1226 * a valid HMAC-SHA1 key. 1227 * 1228 * @return A numeric String in base 10 that includes 1229 * {@link codeDigits} digits plus the optional checksum 1230 * digit if requested. 1231 */ 1232 static public String generateOTP(byte[] secret, 1233 long movingFactor, 1234 int codeDigits, 1235 boolean addChecksum, 1236 int truncationOffset) 1237 throws NoSuchAlgorithmException, InvalidKeyException 1238 { 1239 // put movingFactor value into text byte array 1240 String result = null; 1241 int digits = addChecksum ? (codeDigits + 1) : codeDigits; 1242 byte[] text = new byte[8]; 1243 for (int i = text.length - 1; i >= 0; i--) { 1244 text[i] = (byte) (movingFactor & 0xff); 1245 movingFactor >>= 8; 1246 } 1248 // compute hmac hash 1249 byte[] hash = hmac_sha1(secret, text); 1251 // put selected bytes into result int 1252 int offset = hash[hash.length - 1] & 0xf; 1253 if ( (0<=truncationOffset) && 1254 (truncationOffset<(hash.length-4)) ) { 1255 offset = truncationOffset; 1256 } 1257 HOTP: An HMAC-based One Time Password Algorithm October 2004 1259 int binary = 1260 ((hash[offset] & 0x7f) << 24) 1261 | ((hash[offset + 1] & 0xff) << 16) 1262 | ((hash[offset + 2] & 0xff) << 8) 1263 | (hash[offset + 3] & 0xff); 1265 int otp = binary % DIGITS_POWER[codeDigits]; 1266 if (addChecksum) { 1267 otp = (otp * 10) + calcChecksum(otp, codeDigits); 1268 } 1269 result = Integer.toString(otp); 1270 while (result.length() < digits) { 1271 result = "0" + result; 1272 } 1273 return result; 1274 } 1275 } 1277 Appendix C - HOTP Algorithm: Test Values 1279 The following test data uses the ASCII string 1280 "123456787901234567890" for the secret: 1282 Secret = 0x3132333435363738393031323334353637383930 1284 Table 1 details for each count, the intermediate hmac value. 1286 Count Hexadecimal HMAC-SHA1(secret, count) 1287 0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0 1288 1 75a48a19d4cbe100644e8ac1397eea747a2d33ab 1289 2 0bacb7fa082fef30782211938bc1c5e70416ff44 1290 3 66c28227d03a2d5529262ff016a1e6ef76557ece 1291 4 a904c900a64b35909874b33e61c5938a8e15ed1c 1292 5 a37e783d7b7233c083d4f62926c7a25f238d0316 1293 6 bc9cd28561042c83f219324d3c607256c03272ae 1294 7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa 1295 8 1b3c89f65e6c9e883012052823443f048b4332db 1296 9 1637409809a679dc698207310c8c7fc07290d9e5 1298 Table details for each count the truncated values (both in 1299 hexadecimal and decimal) and then the HOTP value. 1301 Truncated 1302 Count Hexadecimal Decimal HOTP 1303 0 4c93cf18 1284755224 755224 1304 1 41397eea 1094287082 287082 1305 2 82fef30 137359152 359152 1306 3 66ef7655 1726969429 969429 1307 4 61c5938a 1640338314 338314 1308 HOTP: An HMAC-based One Time Password Algorithm October 2004 1310 5 33c083d4 868254676 254676 1311 6 7256c032 1918287922 287922 1312 7 4e5b397 82162583 162583 1313 8 2823443f 673399871 399871 1314 9 2679dc69 645520489 520489 1316 Full Copyright Statement 1318 Copyright (C) The Internet Society 2004. This document is subject 1319 to the rights, licenses and restrictions contained in BCP 78, and 1320 except as set forth therein, the authors retain all their rights. 1322 This document and the information contained herein are provided on 1323 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1324 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1325 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1326 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1327 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1328 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1329 PARTICULAR PURPOSE.