idnits 2.17.1 draft-mraihi-totp-timebased-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a prover may send the same OTP inside a given time window multiple times to a verifier. The verifier MUST not accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP. -- 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 24, 2011) is 4809 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 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 S. Machani 5 Expires: August 28, 2011 Diversinet Corp. 6 M. Pei 7 Symantec 8 J. Rydell 9 Portwise, Inc. 10 February 24, 2011 12 TOTP: Time-based One-time Password Algorithm 13 draft-mraihi-totp-timebased-08.txt 15 Abstract 17 This document describes an extension of one-time password (OTP) 18 algorithm, namely the HMAC-Based One-Time Password (HOTP) Algorithm 19 as defined in RFC 4226, to support time-based moving factor. The 20 HOTP algorithm specifies an event based OTP algorithm where the 21 moving factor is an event counter. The present work bases the moving 22 factor on a time value. A time-based variant of the OTP algorithm 23 provides short-lived OTP values, which are desirable for enhanced 24 security. 26 The proposed algorithm can be used across a wide range of network 27 applications ranging from remote Virtual Private Network (VPN) 28 access, Wi-Fi network logon to transaction-oriented Web applications. 29 The authors believe that a common and shared algorithm will 30 facilitate adoption of two-factor authentication on the Internet by 31 enabling interoperability across commercial and open-source 32 implementations. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 28, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 71 3. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 4 72 4. TOTP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.2. Description . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.2. Validation and Time-step Size . . . . . . . . . . . . . . 7 78 6. Resynchronization . . . . . . . . . . . . . . . . . . . . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9.1. Normative references . . . . . . . . . . . . . . . . . . . 9 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 84 Appendix A. TOTP Algorithm: Reference Implementation . . . . . . 10 85 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 1.1. Scope 92 This document describes an extension of one-time password (OTP) 93 algorithm HMAC-Based One-Time Password (HOTP) as defined in [RFC4226] 94 to support time based moving factor. 96 1.2. Background 98 As defined in [RFC4226] the HOTP algorithm is based on the HMAC-SHA-1 99 algorithm, as specified in [RFC2104] applied to an increasing counter 100 value representing the message in the HMAC computation. 102 Basically, the output of the HMAC-SHA-1 calculation is truncated to 103 obtain user-friendly values: 105 HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) 107 where Truncate represents the function that can convert an HMAC-SHA-1 108 value into an HOTP value. K and C reprensent the shared secret and 109 counter value, see [RFC4226] for their detail definition. 111 TOTP is the time-based variant of this algorithm where a value T 112 derived from a time reference and a time step replaces the counter C 113 in the HOTP computation. 115 TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, 116 based on SHA-256 or SHA-512 [SHA2] hash functions, instead of HMAC- 117 SHA-1 function that has been specified for HOTP computation in 118 [RFC4226]. 120 2. Notation and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119] 126 3. Algorithm Requirements 128 This section summarizes the requirements taken into account for 129 designing the TOTP algorithm. 131 R1 - The prover (e.g. token, soft token) and verifier (authentication 132 or validation server) MUST know or be able to derive the current Unix 133 time (i.e. the number of seconds elapsed since midnight UTC of 134 January 1, 1970) for OTP generation. See [UT] for more detail 135 definition of the commonly known "Unix time". The precision of the 136 time used by the prover affects how often the clock synchronization 137 should be done, see Section 6. 139 R2 - The prover and verifier MUST either share a same secret or the 140 knowledge of a secret transformation to generate a shared secret 142 R3 - The algorithm MUST use HOTP [RFC4226] as a key building block. 144 R4 - The prover and verifier MUST use the same time step value X. 146 R5 - There MUST be a unique secret (key) for each prover. 148 R6 - The keys SHOULD be randomly generated or derived using a key 149 derivation algorithms. 151 R7 - The keys MAY be stored in a tamper-resistant device and SHOULD 152 be protected against unauthorized access and usage. 154 4. TOTP Algorithm 156 This variant of the HOTP algorithm specifies the calculation of a 157 one-time password value, based on a representation of the counter as 158 a time factor. 160 4.1. Notations 162 - X represents the time step in seconds (default value X = 30 163 seconds) and is a system parameter; 165 - T0 is the Unix time to start counting time steps (default value is 166 0, Unix epoch) and is also a system parameter. 168 4.2. Description 170 Basically, we define TOTP as TOTP = HOTP(K, T) where T is an integer 171 and represents the number of time steps between the initial counter 172 time T0 and the current Unix time. 174 More specifically T = (Current Unix time - T0) / X where: 176 - X represents the time step in seconds (default value X = 30 177 seconds) and is a system parameter. 179 - T0 is the Unix time to start counting time steps (default value is 180 0, Unix epoch) and is also a system parameter; 182 - The default floor function is used in the computation. For 183 example, with T0 = 0 and time step X = 30, T = 1 if the current Unix 184 time is 59 seconds and T = 2 if the current Unix time is 60 seconds. 186 The implementation of this algorithm MUST support the time value T 187 larger than 32-bit integer when it is beyond year 2038. The value of 188 the system parameters X and T0 are pre-established during the 189 provisioning process and communicated between a prover and verifier 190 as part of the provisioning step. The provisioning flow is out of 191 scope of this document, refer to [RFC6030] for such provisioning 192 container specification. 194 5. Security Considerations 196 5.1. General 198 The security and strength of this algorithm depends on the properties 199 of the underlying building block HOTP, which is a construction based 200 on HMAC [RFC2104] using SHA-1 as the hash function. 202 The conclusion of the security analysis detailed in [RFC4226] is 203 that, for all practical purposes, the outputs of the dynamic 204 truncation on distinct inputs are uniformly and independently 205 distributed strings. 207 The analysis demonstrates that the best possible attack against the 208 HOTP function is the brute force attack. 210 As indicated in the algorithm requirement section, keys SHOULD be 211 chosen at random or using a cryptographically strong pseudo-random 212 generator properly seeded with a random value. 214 Keys SHOULD be of the length of the HMAC output to facilitate 215 interoperability. 217 We RECOMMEND following the recommendations in [RFC4086] for all 218 pseudo-random and random generations. The pseudo-random numbers used 219 for generating the keys SHOULD successfully pass the randomness test 220 specified in [CN] or a similar well-recognized test. 222 All the communications SHOULD take place over a secure channel e.g. 223 SSL/TLS [RFC5246], IPsec connections [RFC4301]. 225 We also RECOMMEND storing the keys securely in the validation system, 226 and more specifically encrypting them using tamper-resistant hardware 227 encryption and exposing them only when required: for example, the key 228 is decrypted when needed to verify an OTP value, and re-encrypted 229 immediately to limit exposure in the RAM for a short period of time. 231 The key store MUST be in a secure area, to avoid as much as possible 232 direct attack on the validation system and secrets database. 233 Particularly, access to the key material should be limited to 234 programs and processes required by the validation system only. 236 5.2. Validation and Time-step Size 238 An OTP generated within the same Time-step will be the same. When an 239 OTP is received at a validation system, it doesn't know a client's 240 exact timestamp when an OTP was generated. The validation system may 241 typically use the timestamp when an OTP is received for OTP 242 comparison. Due to the network latency for an OTP to transmit from a 243 requesting application to a validation system and user's actual input 244 time of an OTP to a receiving system, such timestamp gap between the 245 actual OTP generation time and server's receiving time may be large. 246 The receiving time at the validation system and the actual OTP 247 generation may not fall within the same Time-step window that produce 248 the same OTP. When an OTP is generated at the end of a Time-step 249 window, the receiving time most likely falls into the next Time-step 250 window. A validation system SHOULD typically set a policy for an 251 acceptable OTP transmission delay window for validation. The 252 validation system should compare OTPs not only with the receiving 253 timestamp but also the past timesteps that are within the 254 transmission delay. A larger acceptable delay window would introduce 255 some OTP attack window. We RECOMMEND that at most one time step is 256 allowed as the network delay. 258 The Time-step size has impact on both security and usability. A 259 larger Time-step size means larger validity window for an OTP to be 260 accepted by a validation system. There are the following 261 implications with a larger Time-step size. 263 At first, a larger Time-step size exposes larger window for attack. 264 When an OTP is generated and exposed to a third party before it is 265 consumed, the third party can consume the OTP within the Time-step 266 window. 268 We RECOMMEND default Time-step size for 30 seconds. This default 269 value of 30 seconds is selected to balance between security and 270 usability. 272 Secondly, the next different OTP must be generated in the next Time- 273 step window. A user must wait till the clock moves to the next Time- 274 step window from the last submission. The waiting time may not be 275 exactly the length of Time-step depending on when the last OTP was 276 generated. For example, if the last OTP was generated at the half 277 way in a Time-step window, the waiting time for the next OTP is half 278 of length of Time-step. In general, a larger Time-step window means 279 larger waiting time for a user to get the next valid OTP after the 280 last successfully OTP validation. A too large window, for example 10 281 minutes, most probably won't be suitable for typical internet login 282 use cases; a user may not be able to get the next OTP within 10 283 minutes and therefore re-login back to the same site in 10 minutes. 285 Note that a prover may send the same OTP inside a given time window 286 multiple times to a verifier. The verifier MUST not accept the 287 second attempt of the OTP after the successful validation has been 288 issued for the first OTP, which ensures one-time only use of an OTP. 290 6. Resynchronization 292 Because of possible clock drifts between a client and a validation 293 server, we RECOMMEND that the validator be set with a specific limit 294 to the number of time steps a prover can be 'out of synch' before 295 being rejected. 297 This limit can be set both forward and backwards from the calculated 298 time step on receipt of the OTP value. If the time step is 30 299 seconds as recommended, and the validator is set to only accept 2 300 time step backwards then the maximum elapsed time drift would be 301 around 89 seconds, i.e. 29 seconds in the calculated time step and 60 302 for two backward time steps. 304 This would mean the validator could perform a validation against the 305 current time and then further two validations for each backward step 306 (for a total of 3 validations). Upon successful validation, the 307 validation server can record the detected clock drift for the token 308 in terms of number of Time-step. When a new OTP is received after 309 this step, the validator can validate the OTP with current timestamp 310 adjusted with recorded number of Time-step clock drifts for the 311 token. 313 Also, it is important to note that the longer a prover has not sent 314 an OTP to a validation system, the longer (potentially) the 315 accumulated clock drift between the prover and the verifier. In such 316 cases, the automatic resynchronization described above may not work 317 if the drift exceeds the allowed threshold. Additional 318 authentication measures should be used to safely authenticate the 319 prover and explicitly resynchronize the clock drift between the 320 prover and the validator. 322 7. IANA Considerations 324 This document has no actions for IANA. 326 8. Acknowledgements 328 The authors of this draft would like to thank the following people 329 for their contributions and support to make this a better 330 specification: Hannes Tschofenig, Jonathan Tuliani, David Dix, 331 Siddharth Bajaj, Stu Veath, Shuh Chang, Oanh Hoang, John Huang, and 332 Siddhartha Mohapatra. 334 9. References 336 9.1. Normative references 338 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 339 Hashing for Message Authentication", RFC 2104, 340 February 1997, . 342 [RFC2119] "Key words for use in RFCs to Indicate Requirement 343 Levels", BCP 14, RFC 2119, March 1997, 344 . 346 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 347 Recommendations for Security", RFC 4086, June 2005, 348 . 350 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 351 O. Ranen, "HOTP: An HMAC-Based One-Time Password 352 Algorithm", RFC 4226, December 2005, 353 . 355 [SHA2] NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)", 356 October 2008, . 359 9.2. Informative References 361 [CN] Coron, J. and D. Naccache, "An accurate evaluation of 362 Maurer's universal test", LNCS 1556, February 1999, . 365 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 366 Internet Protocol", RFC 4301, December 2005, 367 . 369 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 370 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 371 . 373 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 374 Key Container (PSKC)", RFC 6030, October 2010, 375 . 377 [UT] Wikipedia, "Unix time", February 2011, 378 . 380 Appendix A. TOTP Algorithm: Reference Implementation 382 384 /** 385 Copyright (c) 2011 IETF Trust and the persons identified as authors of 386 the code. All rights reserved. 388 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 389 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 390 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 391 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 392 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 393 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 394 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 395 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 396 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 397 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 398 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 399 */ 401 import java.lang.reflect.UndeclaredThrowableException; 402 import java.security.GeneralSecurityException; 403 import java.text.DateFormat; 404 import java.text.SimpleDateFormat; 405 import java.util.Date; 406 import javax.crypto.Mac; 407 import javax.crypto.spec.SecretKeySpec; 408 import java.math.BigInteger; 409 import java.util.TimeZone; 411 /** 412 * This an example implementation of the OATH TOTP algorithm. 413 * Visit www.openauthentication.org for more information. 414 * 415 * @author Johan Rydell, PortWise, Inc. 416 */ 417 public class TOTP { 419 private TOTP() {} 421 /** 422 * This method uses the JCE to provide the crypto 423 * algorithm. 424 * HMAC computes a Hashed Message Authentication Code with the 425 * crypto hash algorithm as a parameter. 426 * 427 * @param crypto the crypto algorithm (HmacSHA1, HmacSHA256, 428 * HmacSHA512) 429 * @param keyBytes the bytes to use for the HMAC key 430 * @param text the message or text to be authenticated. 431 */ 432 private static byte[] hmac_sha(String crypto, byte[] keyBytes, 433 byte[] text){ 434 try { 435 Mac hmac; 436 hmac = Mac.getInstance(crypto); 437 SecretKeySpec macKey = 438 new SecretKeySpec(keyBytes, "RAW"); 439 hmac.init(macKey); 440 return hmac.doFinal(text); 441 } catch (GeneralSecurityException gse) { 442 throw new UndeclaredThrowableException(gse); 443 } 444 } 446 /** 447 * This method converts HEX string to Byte[] 448 * 449 * @param hex the HEX string 450 * 451 * @return A byte array 452 */ 453 private static byte[] hexStr2Bytes(String hex){ 454 // Adding one byte to get the right conversion 455 // values starting with "0" can be converted 456 byte[] bArray = new BigInteger("10" + hex,16).toByteArray(); 458 // Copy all the REAL bytes, not the "first" 459 byte[] ret = new byte[bArray.length - 1]; 460 for (int i = 0; i < ret.length ; i++) 461 ret[i] = bArray[i+1]; 462 return ret; 464 } 466 private static final int[] DIGITS_POWER 467 // 0 1 2 3 4 5 6 7 8 468 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 470 /** 471 * This method generates an TOTP value for the given 472 * set of parameters. 473 * 474 * @param key the shared secret, HEX encoded 475 * @param time a value that reflects a time 476 * @param returnDigits number of digits to return 477 * 478 * @return A numeric String in base 10 that includes 479 * {@link truncationDigits} digits 480 */ 481 public static String generateTOTP(String key, 482 String time, 483 String returnDigits){ 484 return generateTOTP(key, time, returnDigits, "HmacSHA1"); 485 } 487 /** 488 * This method generates an TOTP value for the given 489 * set of parameters. 490 * 491 * @param key the shared secret, HEX encoded 492 * @param time a value that reflects a time 493 * @param returnDigits number of digits to return 494 * 495 * @return A numeric String in base 10 that includes 496 * {@link truncationDigits} digits 497 */ 498 public static String generateTOTP256(String key, 499 String time, 500 String returnDigits){ 501 return generateTOTP(key, time, returnDigits, "HmacSHA256"); 502 } 504 /** 505 * This method generates an TOTP value for the given 506 * set of parameters. 507 * 508 * @param key the shared secret, HEX encoded 509 * @param time a value that reflects a time 510 * @param returnDigits number of digits to return 511 * 512 * @return A numeric String in base 10 that includes 513 * {@link truncationDigits} digits 514 */ 515 public static String generateTOTP512(String key, 516 String time, 517 String returnDigits){ 518 return generateTOTP(key, time, returnDigits, "HmacSHA512"); 519 } 521 /** 522 * This method generates an TOTP value for the given 523 * set of parameters. 524 * 525 * @param key the shared secret, HEX encoded 526 * @param time a value that reflects a time 527 * @param returnDigits number of digits to return 528 * @param crypto the crypto function to use 529 * 530 * @return A numeric String in base 10 that includes 531 * {@link truncationDigits} digits 532 */ 533 public static String generateTOTP(String key, 534 String time, 535 String returnDigits, 536 String crypto){ 537 int codeDigits = Integer.decode(returnDigits).intValue(); 538 String result = null; 540 // Using the counter 541 // First 8 bytes are for the movingFactor 542 // Complaint with base RFC 4226 (HOTP) 543 while(time.length() < 16 ) 544 time = "0" + time; 546 // Get the HEX in a Byte[] 547 byte[] msg = hexStr2Bytes(time); 548 byte[] k = hexStr2Bytes(key); 550 byte[] hash = hmac_sha(crypto, k, msg); 552 // put selected bytes into result int 553 int offset = hash[hash.length - 1] & 0xf; 554 int binary = 555 ((hash[offset] & 0x7f) << 24) | 556 ((hash[offset + 1] & 0xff) << 16) | 557 ((hash[offset + 2] & 0xff) << 8) | 558 (hash[offset + 3] & 0xff); 560 int otp = binary % DIGITS_POWER[codeDigits]; 562 result = Integer.toString(otp); 563 while (result.length() < codeDigits) { 564 result = "0" + result; 565 } 566 return result; 567 } 569 public static void main(String[] args) { 570 // Seed for HMAC-SHA1 - 20 bytes 571 String seed = "3132333435363738393031323334353637383930"; 572 // Seed for HMAC-SHA256 - 32 bytes 573 String seed32 = "3132333435363738393031323334353637383930" + 574 "313233343536373839303132"; 575 // Seed for HMAC-SHA512 - 64 bytes 576 String seed64 = "3132333435363738393031323334353637383930" + 577 "3132333435363738393031323334353637383930" + 578 "3132333435363738393031323334353637383930" + 579 "31323334"; 580 long T0 = 0; 581 long X = 30; 582 long testTime[] = {59L, 1111111109L, 1111111111L, 583 1234567890L, 2000000000L, 20000000000L}; 585 String steps = "0"; 586 DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); 587 df.setTimeZone(TimeZone.getTimeZone("UTC")); 589 try{ 590 System.out.println( 591 "+---------------+-----------------------+" + 592 "------------------+--------+--------+"); 593 System.out.println( 594 "| Time(sec) | Time (UTC format) " + 595 "| Value of T(Hex) | TOTP | Mode |"); 596 System.out.println( 597 "+---------------+-----------------------+" + 598 "------------------+--------+--------+"); 600 for(int i=0; i 631 Appendix B. Test Vectors 633 This section provides test values that can be used for HOTP time- 634 based variant algorithm interoperability test. 636 The test token shared secret uses the ASCII string value 637 "12345678901234567890". With Time Step X = 30, and Unix epoch as 638 initial value to count time steps where T0 = 0, the TOTP algorithm 639 will display the following values for specified modes and timestamps. 641 +-------------+--------------+------------------+----------+--------+ 642 | Time (sec) | UTC Time | Value of T (hex) | TOTP | Mode | 643 +-------------+--------------+------------------+----------+--------+ 644 | 59 | 1970-01-01 | 0000000000000001 | 94287082 | SHA1 | 645 | | 00:00:59 | | | | 646 | 59 | 1970-01-01 | 0000000000000001 | 46119246 | SHA256 | 647 | | 00:00:59 | | | | 648 | 59 | 1970-01-01 | 0000000000000001 | 90693936 | SHA512 | 649 | | 00:00:59 | | | | 650 | 1111111109 | 2005-03-18 | 00000000023523EC | 07081804 | SHA1 | 651 | | 01:58:29 | | | | 652 | 1111111109 | 2005-03-18 | 00000000023523EC | 68084774 | SHA256 | 653 | | 01:58:29 | | | | 654 | 1111111109 | 2005-03-18 | 00000000023523EC | 25091201 | SHA512 | 655 | | 01:58:29 | | | | 656 | 1111111111 | 2005-03-18 | 00000000023523ED | 14050471 | SHA1 | 657 | | 01:58:31 | | | | 658 | 1111111111 | 2005-03-18 | 00000000023523ED | 67062674 | SHA256 | 659 | | 01:58:31 | | | | 660 | 1111111111 | 2005-03-18 | 00000000023523ED | 99943326 | SHA512 | 661 | | 01:58:31 | | | | 662 | 1234567890 | 2009-02-13 | 000000000273EF07 | 89005924 | SHA1 | 663 | | 23:31:30 | | | | 664 | 1234567890 | 2009-02-13 | 000000000273EF07 | 91819424 | SHA256 | 665 | | 23:31:30 | | | | 666 | 1234567890 | 2009-02-13 | 000000000273EF07 | 93441116 | SHA512 | 667 | | 23:31:30 | | | | 668 | 2000000000 | 2033-05-18 | 0000000003F940AA | 69279037 | SHA1 | 669 | | 03:33:20 | | | | 670 | 2000000000 | 2033-05-18 | 0000000003F940AA | 90698825 | SHA256 | 671 | | 03:33:20 | | | | 672 | 2000000000 | 2033-05-18 | 0000000003F940AA | 38618901 | SHA512 | 673 | | 03:33:20 | | | | 674 | 20000000000 | 2603-10-11 | 0000000027BC86AA | 65353130 | SHA1 | 675 | | 11:33:20 | | | | 676 | 20000000000 | 2603-10-11 | 0000000027BC86AA | 77737706 | SHA256 | 677 | | 11:33:20 | | | | 678 | 20000000000 | 2603-10-11 | 0000000027BC86AA | 47863826 | SHA512 | 679 | | 11:33:20 | | | | 680 +-------------+--------------+------------------+----------+--------+ 682 Table 1: TOTP Table 684 Authors' Addresses 686 David M'Raihi 687 Verisign, Inc. 688 685 E. Middlefield Road 689 Mountain View, CA 94043 690 USA 692 Email: davidietf@gmail.com 694 Salah Machani 695 Diversinet Corp. 696 2225 Sheppard Avenue East, Suite 1801 697 Toronto, Ontario M2J 5C2 698 Canada 700 Email: smachani@diversinet.com 702 Mingliang Pei 703 Symantec 704 510 E. Middlefield Road 705 Mountain View, CA 94043 706 USA 708 Email: Mingliang_Pei@symantec.com 710 Johan Rydell 711 Portwise, Inc. 712 275 Hawthorne Ave, Suite 119 713 Palo Alto, CA 94301 714 USA 716 Email: johan.rydell@portwise.com