git.squeep.com Git - squeep-totp/blob - reference/rfc6238.txt

   1
   2
   3
   4
   5
   6
   7 Internet Engineering Task Force (IETF)                        D. M'Raihi
   8 Request for Comments: 6238                                Verisign, Inc.
   9 Category: Informational                                       S. Machani
  10 ISSN: 2070-1721                                         Diversinet Corp.
  11                                                                   M. Pei
  12                                                                 Symantec
  13                                                                J. Rydell
  14                                                           Portwise, Inc.
  15                                                                 May 2011
  16
  17
  18               TOTP: Time-Based One-Time Password Algorithm
  19
  20 Abstract
  21
  22    This document describes an extension of the One-Time Password (OTP)
  23    algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm,
  24    as defined in RFC 4226, to support the time-based moving factor.  The
  25    HOTP algorithm specifies an event-based OTP algorithm, where the
  26    moving factor is an event counter.  The present work bases the moving
  27    factor on a time value.  A time-based variant of the OTP algorithm
  28    provides short-lived OTP values, which are desirable for enhanced
  29    security.
  30
  31    The proposed algorithm can be used across a wide range of network
  32    applications, from remote Virtual Private Network (VPN) access and
  33    Wi-Fi network logon to transaction-oriented Web applications.  The
  34    authors believe that a common and shared algorithm will facilitate
  35    adoption of two-factor authentication on the Internet by enabling
  36    interoperability across commercial and open-source implementations.
  37
  38 Status of This Memo
  39
  40    This document is not an Internet Standards Track specification; it is
  41    published for informational purposes.
  42
  43    This document is a product of the Internet Engineering Task Force
  44    (IETF).  It represents the consensus of the IETF community.  It has
  45    received public review and has been approved for publication by the
  46    Internet Engineering Steering Group (IESG).  Not all documents
  47    approved by the IESG are a candidate for any level of Internet
  48    Standard; see Section 2 of RFC 5741.
  49
  50    Information about the current status of this document, any errata,
  51    and how to provide feedback on it may be obtained at
  52    http://www.rfc-editor.org/info/rfc6238.
  53
  54
  55
  56
  57
  58 M'Raihi, et al.               Informational                     [Page 1]
  59 \f
  60 RFC 6238                      HOTPTimeBased                     May 2011
  61
  62
  63 Copyright Notice
  64
  65    Copyright (c) 2011 IETF Trust and the persons identified as the
  66    document authors.  All rights reserved.
  67
  68    This document is subject to BCP 78 and the IETF Trust's Legal
  69    Provisions Relating to IETF Documents
  70    (http://trustee.ietf.org/license-info) in effect on the date of
  71    publication of this document.  Please review these documents
  72    carefully, as they describe your rights and restrictions with respect
  73    to this document.  Code Components extracted from this document must
  74    include Simplified BSD License text as described in Section 4.e of
  75    the Trust Legal Provisions and are provided without warranty as
  76    described in the Simplified BSD License.
  77
  78 Table of Contents
  79
  80    1. Introduction ....................................................2
  81       1.1. Scope ......................................................2
  82       1.2. Background .................................................3
  83    2. Notation and Terminology ........................................3
  84    3. Algorithm Requirements ..........................................3
  85    4. TOTP Algorithm ..................................................4
  86       4.1. Notations ..................................................4
  87       4.2. Description ................................................4
  88    5. Security Considerations .........................................5
  89       5.1. General ....................................................5
  90       5.2. Validation and Time-Step Size ..............................6
  91    6. Resynchronization ...............................................7
  92    7. Acknowledgements ................................................7
  93    8. References ......................................................8
  94       8.1. Normative References .......................................8
  95       8.2. Informative References .....................................8
  96    Appendix A. TOTP Algorithm: Reference Implementation ...............9
  97    Appendix B. Test Vectors ..........................................14
  98
  99 1.  Introduction
 100
 101 1.1.  Scope
 102
 103    This document describes an extension of the One-Time Password (OTP)
 104    algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm,
 105    as defined in [RFC4226], to support the time-based moving factor.
 106
 107
 108
 109
 110
 111
 112
 113
 114 M'Raihi, et al.               Informational                     [Page 2]
 115 \f
 116 RFC 6238                      HOTPTimeBased                     May 2011
 117
 118
 119 1.2.  Background
 120
 121    As defined in [RFC4226], the HOTP algorithm is based on the
 122    HMAC-SHA-1 algorithm (as specified in [RFC2104]) and applied to an
 123    increasing counter value representing the message in the HMAC
 124    computation.
 125
 126    Basically, the output of the HMAC-SHA-1 calculation is truncated to
 127    obtain user-friendly values:
 128
 129       HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
 130
 131    where Truncate represents the function that can convert an HMAC-SHA-1
 132    value into an HOTP value.  K and C represent the shared secret and
 133    counter value; see [RFC4226] for detailed definitions.
 134
 135    TOTP is the time-based variant of this algorithm, where a value T,
 136    derived from a time reference and a time step, replaces the counter C
 137    in the HOTP computation.
 138
 139    TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions,
 140    based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the
 141    HMAC-SHA-1 function that has been specified for the HOTP computation
 142    in [RFC4226].
 143
 144 2.  Notation and Terminology
 145
 146    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 147    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 148    document are to be interpreted as described in [RFC2119].
 149
 150 3.  Algorithm Requirements
 151
 152    This section summarizes the requirements taken into account for
 153    designing the TOTP algorithm.
 154
 155    R1: The prover (e.g., token, soft token) and verifier (authentication
 156        or validation server) MUST know or be able to derive the current
 157        Unix time (i.e., the number of seconds elapsed since midnight UTC
 158        of January 1, 1970) for OTP generation.  See [UT] for a more
 159        detailed definition of the commonly known "Unix time".  The
 160        precision of the time used by the prover affects how often the
 161        clock synchronization should be done; see Section 6.
 162
 163    R2: The prover and verifier MUST either share the same secret or the
 164        knowledge of a secret transformation to generate a shared secret.
 165
 166    R3: The algorithm MUST use HOTP [RFC4226] as a key building block.
 167
 168
 169
 170 M'Raihi, et al.               Informational                     [Page 3]
 171 \f
 172 RFC 6238                      HOTPTimeBased                     May 2011
 173
 174
 175    R4: The prover and verifier MUST use the same time-step value X.
 176
 177    R5: There MUST be a unique secret (key) for each prover.
 178
 179    R6: The keys SHOULD be randomly generated or derived using key
 180        derivation algorithms.
 181
 182    R7: The keys MAY be stored in a tamper-resistant device and SHOULD be
 183        protected against unauthorized access and usage.
 184
 185 4.  TOTP Algorithm
 186
 187    This variant of the HOTP algorithm specifies the calculation of a
 188    one-time password value, based on a representation of the counter as
 189    a time factor.
 190
 191 4.1.  Notations
 192
 193    o  X represents the time step in seconds (default value X =
 194       30 seconds) and is a system parameter.
 195
 196    o  T0 is the Unix time to start counting time steps (default value is
 197       0, i.e., the Unix epoch) and is also a system parameter.
 198
 199 4.2.  Description
 200
 201    Basically, we define TOTP as TOTP = HOTP(K, T), where T is an integer
 202    and represents the number of time steps between the initial counter
 203    time T0 and the current Unix time.
 204
 205    More specifically, T = (Current Unix time - T0) / X, where the
 206    default floor function is used in the computation.
 207
 208    For example, with T0 = 0 and Time Step X = 30, T = 1 if the current
 209    Unix time is 59 seconds, and T = 2 if the current Unix time is
 210    60 seconds.
 211
 212    The implementation of this algorithm MUST support a time value T
 213    larger than a 32-bit integer when it is beyond the year 2038.  The
 214    value of the system parameters X and T0 are pre-established during
 215    the provisioning process and communicated between a prover and
 216    verifier as part of the provisioning step.  The provisioning flow is
 217    out of scope of this document; refer to [RFC6030] for such
 218    provisioning container specifications.
 219
 220
 221
 222
 223
 224
 225
 226 M'Raihi, et al.               Informational                     [Page 4]
 227 \f
 228 RFC 6238                      HOTPTimeBased                     May 2011
 229
 230
 231 5.  Security Considerations
 232
 233 5.1.  General
 234
 235    The security and strength of this algorithm depend on the properties
 236    of the underlying building block HOTP, which is a construction based
 237    on HMAC [RFC2104] using SHA-1 as the hash function.
 238
 239    The conclusion of the security analysis detailed in [RFC4226] is
 240    that, for all practical purposes, the outputs of the dynamic
 241    truncation on distinct inputs are uniformly and independently
 242    distributed strings.
 243
 244    The analysis demonstrates that the best possible attack against the
 245    HOTP function is the brute force attack.
 246
 247    As indicated in the algorithm requirement section, keys SHOULD be
 248    chosen at random or using a cryptographically strong pseudorandom
 249    generator properly seeded with a random value.
 250
 251    Keys SHOULD be of the length of the HMAC output to facilitate
 252    interoperability.
 253
 254    We RECOMMEND following the recommendations in [RFC4086] for all
 255    pseudorandom and random number generations.  The pseudorandom numbers
 256    used for generating the keys SHOULD successfully pass the randomness
 257    test specified in [CN], or a similar well-recognized test.
 258
 259    All the communications SHOULD take place over a secure channel, e.g.,
 260    Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
 261    IPsec connections [RFC4301].
 262
 263    We also RECOMMEND storing the keys securely in the validation system,
 264    and, more specifically, encrypting them using tamper-resistant
 265    hardware encryption and exposing them only when required: for
 266    example, the key is decrypted when needed to verify an OTP value, and
 267    re-encrypted immediately to limit exposure in the RAM to a short
 268    period of time.
 269
 270    The key store MUST be in a secure area, to avoid, as much as
 271    possible, direct attack on the validation system and secrets
 272    database.  Particularly, access to the key material should be limited
 273    to programs and processes required by the validation system only.
 274
 275
 276
 277
 278
 279
 280
 281
 282 M'Raihi, et al.               Informational                     [Page 5]
 283 \f
 284 RFC 6238                      HOTPTimeBased                     May 2011
 285
 286
 287 5.2.  Validation and Time-Step Size
 288
 289    An OTP generated within the same time step will be the same.  When an
 290    OTP is received at a validation system, it doesn't know a client's
 291    exact timestamp when an OTP was generated.  The validation system may
 292    typically use the timestamp when an OTP is received for OTP
 293    comparison.  Due to network latency, the gap (as measured by T, that
 294    is, the number of time steps since T0) between the time that the OTP
 295    was generated and the time that the OTP arrives at the receiving
 296    system may be large.  The receiving time at the validation system and
 297    the actual OTP generation may not fall within the same time-step
 298    window that produced the same OTP.  When an OTP is generated at the
 299    end of a time-step window, the receiving time most likely falls into
 300    the next time-step window.  A validation system SHOULD typically set
 301    a policy for an acceptable OTP transmission delay window for
 302    validation.  The validation system should compare OTPs not only with
 303    the receiving timestamp but also the past timestamps that are within
 304    the transmission delay.  A larger acceptable delay window would
 305    expose a larger window for attacks.  We RECOMMEND that at most one
 306    time step is allowed as the network delay.
 307
 308    The time-step size has an impact on both security and usability.  A
 309    larger time-step size means a larger validity window for an OTP to be
 310    accepted by a validation system.  There are implications for using a
 311    larger time-step size, as follows:
 312
 313    First, a larger time-step size exposes a larger window to attack.
 314    When an OTP is generated and exposed to a third party before it is
 315    consumed, the third party can consume the OTP within the time-step
 316    window.
 317
 318    We RECOMMEND a default time-step size of 30 seconds.  This default
 319    value of 30 seconds is selected as a balance between security and
 320    usability.
 321
 322    Second, the next different OTP must be generated in the next time-
 323    step window.  A user must wait until the clock moves to the next
 324    time-step window from the last submission.  The waiting time may not
 325    be exactly the length of the time step, depending on when the last
 326    OTP was generated.  For example, if the last OTP was generated at the
 327    halfway point in a time-step window, the waiting time for the next
 328    OTP is half the length of the time step.  In general, a larger time-
 329    step window means a longer waiting time for a user to get the next
 330    valid OTP after the last successful OTP validation.  A too-large
 331    window (for example, 10 minutes) most probably won't be suitable for
 332    typical Internet login use cases; a user may not be able to get the
 333    next OTP within 10 minutes and therefore will have to re-login to the
 334    same site in 10 minutes.
 335
 336
 337
 338 M'Raihi, et al.               Informational                     [Page 6]
 339 \f
 340 RFC 6238                      HOTPTimeBased                     May 2011
 341
 342
 343    Note that a prover may send the same OTP inside a given time-step
 344    window multiple times to a verifier.  The verifier MUST NOT accept
 345    the second attempt of the OTP after the successful validation has
 346    been issued for the first OTP, which ensures one-time only use of an
 347    OTP.
 348
 349 6.  Resynchronization
 350
 351    Because of possible clock drifts between a client and a validation
 352    server, we RECOMMEND that the validator be set with a specific limit
 353    to the number of time steps a prover can be "out of synch" before
 354    being rejected.
 355
 356    This limit can be set both forward and backward from the calculated
 357    time step on receipt of the OTP value.  If the time step is
 358    30 seconds as recommended, and the validator is set to only accept
 359    two time steps backward, then the maximum elapsed time drift would be
 360    around 89 seconds, i.e., 29 seconds in the calculated time step and
 361    60 seconds for two backward time steps.
 362
 363    This would mean the validator could perform a validation against the
 364    current time and then two further validations for each backward step
 365    (for a total of 3 validations).  Upon successful validation, the
 366    validation server can record the detected clock drift for the token
 367    in terms of the number of time steps.  When a new OTP is received
 368    after this step, the validator can validate the OTP with the current
 369    timestamp adjusted with the recorded number of time-step clock drifts
 370    for the token.
 371
 372    Also, it is important to note that the longer a prover has not sent
 373    an OTP to a validation system, the longer (potentially) the
 374    accumulated clock drift between the prover and the verifier.  In such
 375    cases, the automatic resynchronization described above may not work
 376    if the drift exceeds the allowed threshold.  Additional
 377    authentication measures should be used to safely authenticate the
 378    prover and explicitly resynchronize the clock drift between the
 379    prover and the validator.
 380
 381 7.  Acknowledgements
 382
 383    The authors of this document would like to thank the following people
 384    for their contributions and support to make this a better
 385    specification: Hannes Tschofenig, Jonathan Tuliani, David Dix,
 386    Siddharth Bajaj, Stu Veath, Shuh Chang, Oanh Hoang, John Huang, and
 387    Siddhartha Mohapatra.
 388
 389
 390
 391
 392
 393
 394 M'Raihi, et al.               Informational                     [Page 7]
 395 \f
 396 RFC 6238                      HOTPTimeBased                     May 2011
 397
 398
 399 8.  References
 400
 401 8.1.  Normative References
 402
 403    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 404               Hashing for Message Authentication", RFC 2104,
 405               February 1997.
 406
 407    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 408               Requirement Levels", BCP 14, RFC 2119, March 1997.
 409
 410    [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
 411               "Randomness Recommendations for Security", BCP 106,
 412               RFC 4086, June 2005.
 413
 414    [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
 415               O. Ranen, "HOTP: An HMAC-Based One-Time Password
 416               Algorithm", RFC 4226, December 2005.
 417
 418    [SHA2]     NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)",
 419               October 2008, <http://csrc.nist.gov/publications/fips/
 420               fips180-3/fips180-3_final.pdf>.
 421
 422 8.2.  Informative References
 423
 424    [CN]       Coron, J. and D. Naccache, "An Accurate Evaluation of
 425               Maurer's Universal Test", LNCS 1556, February 1999,
 426               <http://www.gemplus.com/smart/rd/publications/pdf/
 427               CN99maur.pdf>.
 428
 429    [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
 430               Internet Protocol", RFC 4301, December 2005.
 431
 432    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 433               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 434
 435    [RFC6030]  Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
 436               Key Container (PSKC)", RFC 6030, October 2010.
 437
 438    [UT]       Wikipedia, "Unix time", February 2011,
 439               <http://en.wikipedia.org/wiki/Unix_time>.
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 M'Raihi, et al.               Informational                     [Page 8]
 451 \f
 452 RFC 6238                      HOTPTimeBased                     May 2011
 453
 454
 455 Appendix A.  TOTP Algorithm: Reference Implementation
 456
 457  <CODE BEGINS>
 458
 459  /**
 460  Copyright (c) 2011 IETF Trust and the persons identified as
 461  authors of the code. All rights reserved.
 462
 463  Redistribution and use in source and binary forms, with or without
 464  modification, is permitted pursuant to, and subject to the license
 465  terms contained in, the Simplified BSD License set forth in Section
 466  4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
 467  (http://trustee.ietf.org/license-info).
 468  */
 469
 470  import java.lang.reflect.UndeclaredThrowableException;
 471  import java.security.GeneralSecurityException;
 472  import java.text.DateFormat;
 473  import java.text.SimpleDateFormat;
 474  import java.util.Date;
 475  import javax.crypto.Mac;
 476  import javax.crypto.spec.SecretKeySpec;
 477  import java.math.BigInteger;
 478  import java.util.TimeZone;
 479
 480
 481  /**
 482   * This is an example implementation of the OATH
 483   * TOTP algorithm.
 484   * Visit www.openauthentication.org for more information.
 485   *
 486   * @author Johan Rydell, PortWise, Inc.
 487   */
 488
 489  public class TOTP {
 490
 491      private TOTP() {}
 492
 493      /**
 494       * This method uses the JCE to provide the crypto algorithm.
 495       * HMAC computes a Hashed Message Authentication Code with the
 496       * crypto hash algorithm as a parameter.
 497       *
 498       * @param crypto: the crypto algorithm (HmacSHA1, HmacSHA256,
 499       *                             HmacSHA512)
 500       * @param keyBytes: the bytes to use for the HMAC key
 501       * @param text: the message or text to be authenticated
 502       */
 503
 504
 505
 506 M'Raihi, et al.               Informational                     [Page 9]
 507 \f
 508 RFC 6238                      HOTPTimeBased                     May 2011
 509
 510
 511      private static byte[] hmac_sha(String crypto, byte[] keyBytes,
 512              byte[] text){
 513          try {
 514              Mac hmac;
 515              hmac = Mac.getInstance(crypto);
 516              SecretKeySpec macKey =
 517                  new SecretKeySpec(keyBytes, "RAW");
 518              hmac.init(macKey);
 519              return hmac.doFinal(text);
 520          } catch (GeneralSecurityException gse) {
 521              throw new UndeclaredThrowableException(gse);
 522          }
 523      }
 524
 525
 526      /**
 527       * This method converts a HEX string to Byte[]
 528       *
 529       * @param hex: the HEX string
 530       *
 531       * @return: a byte array
 532       */
 533
 534      private static byte[] hexStr2Bytes(String hex){
 535          // Adding one byte to get the right conversion
 536          // Values starting with "0" can be converted
 537          byte[] bArray = new BigInteger("10" + hex,16).toByteArray();
 538
 539          // Copy all the REAL bytes, not the "first"
 540          byte[] ret = new byte[bArray.length - 1];
 541          for (int i = 0; i < ret.length; i++)
 542              ret[i] = bArray[i+1];
 543          return ret;
 544      }
 545
 546      private static final int[] DIGITS_POWER
 547      // 0 1  2   3    4     5      6       7        8
 548      = {1,10,100,1000,10000,100000,1000000,10000000,100000000 };
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 M'Raihi, et al.               Informational                    [Page 10]
 563 \f
 564 RFC 6238                      HOTPTimeBased                     May 2011
 565
 566
 567      /**
 568       * This method generates a TOTP value for the given
 569       * set of parameters.
 570       *
 571       * @param key: the shared secret, HEX encoded
 572       * @param time: a value that reflects a time
 573       * @param returnDigits: number of digits to return
 574       *
 575       * @return: a numeric String in base 10 that includes
 576       *              {@link truncationDigits} digits
 577       */
 578
 579      public static String generateTOTP(String key,
 580              String time,
 581              String returnDigits){
 582          return generateTOTP(key, time, returnDigits, "HmacSHA1");
 583      }
 584
 585
 586      /**
 587       * This method generates a TOTP value for the given
 588       * set of parameters.
 589       *
 590       * @param key: the shared secret, HEX encoded
 591       * @param time: a value that reflects a time
 592       * @param returnDigits: number of digits to return
 593       *
 594       * @return: a numeric String in base 10 that includes
 595       *              {@link truncationDigits} digits
 596       */
 597
 598      public static String generateTOTP256(String key,
 599              String time,
 600              String returnDigits){
 601          return generateTOTP(key, time, returnDigits, "HmacSHA256");
 602      }
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 M'Raihi, et al.               Informational                    [Page 11]
 619 \f
 620 RFC 6238                      HOTPTimeBased                     May 2011
 621
 622
 623      /**
 624       * This method generates a TOTP value for the given
 625       * set of parameters.
 626       *
 627       * @param key: the shared secret, HEX encoded
 628       * @param time: a value that reflects a time
 629       * @param returnDigits: number of digits to return
 630       *
 631       * @return: a numeric String in base 10 that includes
 632       *              {@link truncationDigits} digits
 633       */
 634
 635      public static String generateTOTP512(String key,
 636              String time,
 637              String returnDigits){
 638          return generateTOTP(key, time, returnDigits, "HmacSHA512");
 639      }
 640
 641
 642      /**
 643       * This method generates a TOTP value for the given
 644       * set of parameters.
 645       *
 646       * @param key: the shared secret, HEX encoded
 647       * @param time: a value that reflects a time
 648       * @param returnDigits: number of digits to return
 649       * @param crypto: the crypto function to use
 650       *
 651       * @return: a numeric String in base 10 that includes
 652       *              {@link truncationDigits} digits
 653       */
 654
 655      public static String generateTOTP(String key,
 656              String time,
 657              String returnDigits,
 658              String crypto){
 659          int codeDigits = Integer.decode(returnDigits).intValue();
 660          String result = null;
 661
 662          // Using the counter
 663          // First 8 bytes are for the movingFactor
 664          // Compliant with base RFC 4226 (HOTP)
 665          while (time.length() < 16 )
 666              time = "0" + time;
 667
 668          // Get the HEX in a Byte[]
 669          byte[] msg = hexStr2Bytes(time);
 670          byte[] k = hexStr2Bytes(key);
 671
 672
 673
 674 M'Raihi, et al.               Informational                    [Page 12]
 675 \f
 676 RFC 6238                      HOTPTimeBased                     May 2011
 677
 678
 679          byte[] hash = hmac_sha(crypto, k, msg);
 680
 681          // put selected bytes into result int
 682          int offset = hash[hash.length - 1] & 0xf;
 683
 684          int binary =
 685              ((hash[offset] & 0x7f) << 24) |
 686              ((hash[offset + 1] & 0xff) << 16) |
 687              ((hash[offset + 2] & 0xff) << 8) |
 688              (hash[offset + 3] & 0xff);
 689
 690          int otp = binary % DIGITS_POWER[codeDigits];
 691
 692          result = Integer.toString(otp);
 693          while (result.length() < codeDigits) {
 694              result = "0" + result;
 695          }
 696          return result;
 697      }
 698
 699      public static void main(String[] args) {
 700          // Seed for HMAC-SHA1 - 20 bytes
 701          String seed = "3132333435363738393031323334353637383930";
 702          // Seed for HMAC-SHA256 - 32 bytes
 703          String seed32 = "3132333435363738393031323334353637383930" +
 704          "313233343536373839303132";
 705          // Seed for HMAC-SHA512 - 64 bytes
 706          String seed64 = "3132333435363738393031323334353637383930" +
 707          "3132333435363738393031323334353637383930" +
 708          "3132333435363738393031323334353637383930" +
 709          "31323334";
 710          long T0 = 0;
 711          long X = 30;
 712          long testTime[] = {59L, 1111111109L, 1111111111L,
 713                  1234567890L, 2000000000L, 20000000000L};
 714
 715          String steps = "0";
 716          DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
 717          df.setTimeZone(TimeZone.getTimeZone("UTC"));
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 M'Raihi, et al.               Informational                    [Page 13]
 731 \f
 732 RFC 6238                      HOTPTimeBased                     May 2011
 733
 734
 735          try {
 736              System.out.println(
 737                      "+---------------+-----------------------+" +
 738              "------------------+--------+--------+");
 739              System.out.println(
 740                      "|  Time(sec)    |   Time (UTC format)   " +
 741              "| Value of T(Hex)  |  TOTP  | Mode   |");
 742              System.out.println(
 743                      "+---------------+-----------------------+" +
 744              "------------------+--------+--------+");
 745
 746              for (int i=0; i<testTime.length; i++) {
 747                  long T = (testTime[i] - T0)/X;
 748                  steps = Long.toHexString(T).toUpperCase();
 749                  while (steps.length() < 16) steps = "0" + steps;
 750                  String fmtTime = String.format("%1$-11s", testTime[i]);
 751                  String utcTime = df.format(new Date(testTime[i]*1000));
 752                  System.out.print("|  " + fmtTime + "  |  " + utcTime +
 753                          "  | " + steps + " |");
 754                  System.out.println(generateTOTP(seed, steps, "8",
 755                  "HmacSHA1") + "| SHA1   |");
 756                  System.out.print("|  " + fmtTime + "  |  " + utcTime +
 757                          "  | " + steps + " |");
 758                  System.out.println(generateTOTP(seed32, steps, "8",
 759                  "HmacSHA256") + "| SHA256 |");
 760                  System.out.print("|  " + fmtTime + "  |  " + utcTime +
 761                          "  | " + steps + " |");
 762                  System.out.println(generateTOTP(seed64, steps, "8",
 763                  "HmacSHA512") + "| SHA512 |");
 764
 765                  System.out.println(
 766                          "+---------------+-----------------------+" +
 767                  "------------------+--------+--------+");
 768              }
 769          }catch (final Exception e){
 770              System.out.println("Error : " + e);
 771          }
 772      }
 773  }
 774
 775  <CODE ENDS>
 776
 777 Appendix B.  Test Vectors
 778
 779    This section provides test values that can be used for the HOTP time-
 780    based variant algorithm interoperability test.
 781
 782
 783
 784
 785
 786 M'Raihi, et al.               Informational                    [Page 14]
 787 \f
 788 RFC 6238                      HOTPTimeBased                     May 2011
 789
 790
 791    The test token shared secret uses the ASCII string value
 792    "12345678901234567890".  With Time Step X = 30, and the Unix epoch as
 793    the initial value to count time steps, where T0 = 0, the TOTP
 794    algorithm will display the following values for specified modes and
 795    timestamps.
 796
 797   +-------------+--------------+------------------+----------+--------+
 798   |  Time (sec) |   UTC Time   | Value of T (hex) |   TOTP   |  Mode  |
 799   +-------------+--------------+------------------+----------+--------+
 800   |      59     |  1970-01-01  | 0000000000000001 | 94287082 |  SHA1  |
 801   |             |   00:00:59   |                  |          |        |
 802   |      59     |  1970-01-01  | 0000000000000001 | 46119246 | SHA256 |
 803   |             |   00:00:59   |                  |          |        |
 804   |      59     |  1970-01-01  | 0000000000000001 | 90693936 | SHA512 |
 805   |             |   00:00:59   |                  |          |        |
 806   |  1111111109 |  2005-03-18  | 00000000023523EC | 07081804 |  SHA1  |
 807   |             |   01:58:29   |                  |          |        |
 808   |  1111111109 |  2005-03-18  | 00000000023523EC | 68084774 | SHA256 |
 809   |             |   01:58:29   |                  |          |        |
 810   |  1111111109 |  2005-03-18  | 00000000023523EC | 25091201 | SHA512 |
 811   |             |   01:58:29   |                  |          |        |
 812   |  1111111111 |  2005-03-18  | 00000000023523ED | 14050471 |  SHA1  |
 813   |             |   01:58:31   |                  |          |        |
 814   |  1111111111 |  2005-03-18  | 00000000023523ED | 67062674 | SHA256 |
 815   |             |   01:58:31   |                  |          |        |
 816   |  1111111111 |  2005-03-18  | 00000000023523ED | 99943326 | SHA512 |
 817   |             |   01:58:31   |                  |          |        |
 818   |  1234567890 |  2009-02-13  | 000000000273EF07 | 89005924 |  SHA1  |
 819   |             |   23:31:30   |                  |          |        |
 820   |  1234567890 |  2009-02-13  | 000000000273EF07 | 91819424 | SHA256 |
 821   |             |   23:31:30   |                  |          |        |
 822   |  1234567890 |  2009-02-13  | 000000000273EF07 | 93441116 | SHA512 |
 823   |             |   23:31:30   |                  |          |        |
 824   |  2000000000 |  2033-05-18  | 0000000003F940AA | 69279037 |  SHA1  |
 825   |             |   03:33:20   |                  |          |        |
 826   |  2000000000 |  2033-05-18  | 0000000003F940AA | 90698825 | SHA256 |
 827   |             |   03:33:20   |                  |          |        |
 828   |  2000000000 |  2033-05-18  | 0000000003F940AA | 38618901 | SHA512 |
 829   |             |   03:33:20   |                  |          |        |
 830   | 20000000000 |  2603-10-11  | 0000000027BC86AA | 65353130 |  SHA1  |
 831   |             |   11:33:20   |                  |          |        |
 832   | 20000000000 |  2603-10-11  | 0000000027BC86AA | 77737706 | SHA256 |
 833   |             |   11:33:20   |                  |          |        |
 834   | 20000000000 |  2603-10-11  | 0000000027BC86AA | 47863826 | SHA512 |
 835   |             |   11:33:20   |                  |          |        |
 836   +-------------+--------------+------------------+----------+--------+
 837
 838                             Table 1: TOTP Table
 839
 840
 841
 842 M'Raihi, et al.               Informational                    [Page 15]
 843 \f
 844 RFC 6238                      HOTPTimeBased                     May 2011
 845
 846
 847 Authors' Addresses
 848
 849    David M'Raihi
 850    Verisign, Inc.
 851    685 E. Middlefield Road
 852    Mountain View, CA  94043
 853    USA
 854
 855    EMail: davidietf@gmail.com
 856
 857
 858    Salah Machani
 859    Diversinet Corp.
 860    2225 Sheppard Avenue East, Suite 1801
 861    Toronto, Ontario  M2J 5C2
 862    Canada
 863
 864    EMail: smachani@diversinet.com
 865
 866
 867    Mingliang Pei
 868    Symantec
 869    510 E. Middlefield Road
 870    Mountain View, CA  94043
 871    USA
 872
 873    EMail: Mingliang_Pei@symantec.com
 874
 875
 876    Johan Rydell
 877    Portwise, Inc.
 878    275 Hawthorne Ave., Suite 119
 879    Palo Alto, CA  94301
 880    USA
 881
 882    EMail: johanietf@gmail.com
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 M'Raihi, et al.               Informational                    [Page 16]
 899 \f