< draft-mraihi-oath-hmac-otp-02.txt   draft-mraihi-oath-hmac-otp-03.txt >
Internet Draft D. M'Raihi Internet Draft D. M'Raihi
Category: Informational VeriSign Category: Informational VeriSign
Document: draft-mraihi-oath-hmac-otp-02.txt M. Bellare Document: draft-mraihi-oath-hmac-otp-03.txt M. Bellare
Expires: April 2005 UCSD Expires: April 2005 UCSD
F. Hoornaert F. Hoornaert
Vasco Vasco
D. Naccache D. Naccache
Gemplus Gemplus
O. Ranen O. Ranen
Aladdin Aladdin
October 2004 October 2004
HOTP: An HMAC-based One Time Password Algorithm HOTP: An HMAC-based One Time Password Algorithm
skipping to change at page 2, line 12 skipping to change at page 2, line 12
membership to specify an algorithm that can be freely distributed membership to specify an algorithm that can be freely distributed
to the technical community. The authors believe that a common and to the technical community. The authors believe that a common and
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
shared algorithm will facilitate adoption of two-factor shared algorithm will facilitate adoption of two-factor
authentication on the Internet by enabling interoperability across authentication on the Internet by enabling interoperability across
commercial and open-source implementations. commercial and open-source implementations.
Table of Contents Table of Contents
1. Overview......................................................2 1. Overview....................................................3
2. Introduction................................................3 2. Introduction................................................3
3. Requirements Terminology....................................4 3. Requirements Terminology....................................4
4. Algorithm Requirements......................................4 4. Algorithm Requirements......................................4
5. HOTP Algorithm..............................................5 5. HOTP Algorithm..............................................5
5.1 Notation and Symbols........................................5 5.1 Notation and Symbols.......................................5
5.2 Description.................................................6 5.2 Description................................................6
5.3 Generating an HOTP value....................................6 5.3 Generating an HOTP value...................................6
5.4 Example of HOTP computation for Digit = 6...................7 5.4 Example of HOTP computation for Digit = 6..................7
6. Security and Deployment Considerations......................8 6. Security Considerations.....................................8
6.1 Authentication Protocol Requirements........................8 6.1 Authentication Protocol Requirements.......................8
6.2 Validation of HOTP values...................................8 6.2 Validation of HOTP values..................................9
6.3 Throttling at the server....................................9 6.3 Throttling at the server...................................9
6.4 Resynchronization of the counter............................9 6.4 Resynchronization of the counter...........................9
7. HOTP Algorithm Security: Overview..........................10 6.5 Management of Shared Secrets..............................10
8. Protocol Extensions and Improvements.........................11 7. HOTP Algorithm Security: Overview..........................12
8.1 Number of Digits...........................................11 8. Protocol Extensions and Improvements.......................12
8.2 Alpha-numeric Values.......................................11 8.1 Number of Digits..........................................13
8.3 Sequence of HOTP values....................................11 8.2 Alpha-numeric Values......................................13
8.4 A Counter-based Re-Synchronization Method..................12 8.3 Sequence of HOTP values...................................13
9. Conclusion.................................................12 8.4 A Counter-based Re-Synchronization Method.................14
10. Acknowledgements...........................................13 8.5 Composite Shared Secrets..................................14
11. Contributors...............................................13 8.6 Data Field................................................15
12. References.................................................13 9. Conclusion.................................................15
12.1 Normative................................................13 10. Acknowledgements...........................................16
12.2 Informative..............................................13 11. Contributors...............................................16
13. Authors' Addresses.........................................14 12. References.................................................16
Appendix A - HOTP Algorithm Security: Detailed Analysis.........14 12.1 Normative.................................................16
A.1 Definitions and Notations...................................15 12.2 Informative...............................................16
A.2 The idealized algorithm: HOTP-IDEAL.........................15 13. Authors' Addresses........................................17
A.3 Model of Security...........................................15 Appendix A - HOTP Algorithm Security: Detailed Analysis........18
A.4 Security of the ideal authentication algorithm..............17 A.1 Definitions and Notations..................................18
A.4.1 From bits to digits.......................................17 A.2 The idealized algorithm: HOTP-IDEAL........................18
A.4.2 Brute force attacks.......................................18 A.3 Model of Security..........................................19
A.4.3 Brute force attacks are the best possible attacks.........19 A.4 Security of the ideal authentication algorithm.............20
A.5 Security Analysis of HOTP...................................20 A.4.1 From bits to digits......................................21
Appendix B - HOTP Algorithm: Reference Implementation...........22 A.4.2 Brute force attacks......................................22
Appendix C - HOTP Algorithm: Test Values........................26 A.4.3 Brute force attacks are the best possible attacks........23
A.5 Security Analysis of HOTP..................................24
Appendix B - SHA-1 Attacks.....................................25
B.1 SHA-1 status...............................................25
B.2 HMAC-SHA-1 status..........................................26
B.3 HOTP status................................................27
HOTP: An HMAC-based One Time Password Algorithm October 2004
Appendix C - HOTP Algorithm: Reference Implementation..........27
Appendix D - HOTP Algorithm: Test Values.......................31
1. Overview 1. Overview
The document introduces first the context around the HOTP The document introduces first the context around the HOTP
algorithm. In section 4, the algorithm requirements are listed and algorithm. In section 4, the algorithm requirements are listed and
HOTP: An HMAC-based One Time Password Algorithm October 2004
in section 5, the HOTP algorithm is described. Sections 6 and 7 in section 5, the HOTP algorithm is described. Sections 6 and 7
focus on the algorithm security. Section 8 proposes some extensions focus on the algorithm security. Section 8 proposes some extensions
and improvements, and Section 9 concludes this document. The and improvements, and Section 9 concludes this document. The
interested reader will find in the Appendix a detailed, full-fledge interested reader will find in the Appendix a detailed, full-fledge
analysis of the algorithm security: an idealized version of the analysis of the algorithm security: an idealized version of the
algorithm is evaluated, and then the HOTP algorithm security is algorithm is evaluated, and then the HOTP algorithm security is
analyzed. analyzed.
2. Introduction 2. Introduction
skipping to change at page 3, line 48 skipping to change at page 4, line 4
interoperability require that it be made freely available to the interoperability require that it be made freely available to the
broad technical community of hardware and software developers. Only broad technical community of hardware and software developers. Only
an open system approach will ensure that basic two-factor an open system approach will ensure that basic two-factor
authentication primitives can be built into the next-generation of authentication primitives can be built into the next-generation of
consumer devices such USB mass storage devices, IP phones, and consumer devices such USB mass storage devices, IP phones, and
personal digital assistants). personal digital assistants).
One Time Password is certainly one of the simplest and most popular One Time Password is certainly one of the simplest and most popular
forms of two-factor authentication for securing network access. For forms of two-factor authentication for securing network access. For
example, in large enterprises, Virtual Private Network access often example, in large enterprises, Virtual Private Network access often
HOTP: An HMAC-based One Time Password Algorithm October 2004
requires the use of One Time Password tokens for remote user requires the use of One Time Password tokens for remote user
authentication. One Time Passwords are often preferred to stronger authentication. One Time Passwords are often preferred to stronger
forms of authentication such as PKI or biometrics because an forms of authentication such as PKI or biometrics because an
air-gap device does not require the installation of any client air-gap device does not require the installation of any client
desktop software on the user machine, therefore allowing them to desktop software on the user machine, therefore allowing them to
roam across multiple machines including home computers, kiosks and roam across multiple machines including home computers, kiosks and
personal digital assistants. personal digital assistants.
HOTP: An HMAC-based One Time Password Algorithm October 2004
This draft proposes a simple One Time Password algorithm that can This draft proposes a simple One Time Password algorithm that can
be implemented by any hardware manufacturer or software developer be implemented by any hardware manufacturer or software developer
to create interoperable authentication devices and software agents. to create interoperable authentication devices and software agents.
The algorithm is event-based so that it can be embedded in high The algorithm is event-based so that it can be embedded in high
volume devices such as Java smart cards, USB dongles and GSM SIM volume devices such as Java smart cards, USB dongles and GSM SIM
cards. The presented algorithm is made freely available to the cards. The presented algorithm is made freely available to the
developer community under the terms and conditions of the IETF developer community under the terms and conditions of the IETF
Intellectual Property Rights [RFC3668]. Intellectual Property Rights [RFC3668].
The authors of this document are members of the Open AuTHentication The authors of this document are members of the Open AuTHentication
skipping to change at page 4, line 47 skipping to change at page 5, line 5
goals is to have the HOTP algorithm embedded in high volume devices goals is to have the HOTP algorithm embedded in high volume devices
such as Java smart cards, USB dongles and GSM SIM cards. such as Java smart cards, USB dongles and GSM SIM cards.
R2 - The algorithm SHOULD be economical to implement in hardware by R2 - The algorithm SHOULD be economical to implement in hardware by
minimizing requirements on battery, number of buttons, minimizing requirements on battery, number of buttons,
computational horsepower, and size of LCD display. The algorithm computational horsepower, and size of LCD display. The algorithm
MUST work with tokens that do not supports any numeric input, but MUST work with tokens that do not supports any numeric input, but
MAY also be used with more sophisticated devices such as secure MAY also be used with more sophisticated devices such as secure
PIN-pads. PIN-pads.
HOTP: An HMAC-based One Time Password Algorithm October 2004
R3 - The value displayed on the token MUST be easily read and R3 - The value displayed on the token MUST be easily read and
entered by the user: This requires the HOTP value to be of entered by the user: This requires the HOTP value to be of
reasonable length. The HOTP value must be at least a 6-digit value. reasonable length. The HOTP value must be at least a 6-digit value.
It is also desirable that the HOTP value be 'numeric only' so that It is also desirable that the HOTP value be 'numeric only' so that
it can be easily entered on restricted devices such as phones. it can be easily entered on restricted devices such as phones.
HOTP: An HMAC-based One Time Password Algorithm October 2004
R4 - There MUST be user-friendly mechanisms available to R4 - There MUST be user-friendly mechanisms available to
resynchronize the counter. The sections 6.4 and 8.4 detail the resynchronize the counter. The sections 6.4 and 8.4 detail the
resynchronization mechanism proposed in this draft. resynchronization mechanism proposed in this draft.
R5 - The algorithm MUST use a strong shared secret. The length of R5 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This draft RECOMMENDs the shared secret MUST be at least 128 bits. This draft RECOMMENDs
a shared secret length of 160 bits. a shared secret length of 160 bits.
5. HOTP Algorithm 5. HOTP Algorithm
skipping to change at page 5, line 47 skipping to change at page 5, line 53
Here is a list of symbols used in this document. Here is a list of symbols used in this document.
Symbol Represents Symbol Represents
------------------------------------------------------------------- -------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client) MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server); and the HOTP validator (server);
K shared secret between client and server; each HOTP K shared secret between client and server; each HOTP
generator has a different and unique secret K; generator has a different and unique secret K;
T throttling parameter: the server will refuse connections
from a user after T unsuccessful authentication attempts;
s resynchronization parameter: the server will attempt to T throttling parameter: the server will refuse connections
verify a received authenticator across s consecutive
counter values;
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
from a user after T unsuccessful authentication attempts;
s resynchronization parameter: the server will attempt to
verify a received authenticator across s consecutive
counter values;
Digit number of digits in an HOTP value; system parameter. Digit number of digits in an HOTP value; system parameter.
5.2 Description 5.2 Description
The HOTP algorithm is based on an increasing counter value and a The HOTP algorithm is based on an increasing counter value and a
static symmetric key known only to the token and the validation static symmetric key known only to the token and the validation
service. In order to create the HOTP value, we will use the service. In order to create the HOTP value, we will use the
HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2]. HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2].
As the output of the HMAC-SHA1 calculation is 160 bits, we must As the output of the HMAC-SHA1 calculation is 160 bits, we must
skipping to change at page 6, line 47 skipping to change at page 7, line 4
Step 2: Generate a 4-byte string (Dynamic Truncation) Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined in Section 6.3.1 Let Sbits = DT(HS) // DT, defined in Section 6.3.1
// returns a 31 bit string // returns a 31 bit string
Step 3: Compute an HOTP value Step 3: Compute an HOTP value
Let Snum = StToNum(S) // Convert S to a number in Let Snum = StToNum(S) // Convert S to a number in
0...2^{31}-1 0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1 0...10^{Digit}-1
HOTP: An HMAC-based One Time Password Algorithm October 2004
The Truncate function performs Step 2 and Step 3, i.e. the dynamic The Truncate function performs Step 2 and Step 3, i.e. the dynamic
truncation and then the reduction modulo 10^Digit. The purpose of truncation and then the reduction modulo 10^Digit. The purpose of
the dynamic offset truncation technique is to extract a 4-byte the dynamic offset truncation technique is to extract a 4-byte
dynamic binary code from a 160-bit (20-byte) HMAC-SHA1 result. dynamic binary code from a 160-bit (20-byte) HMAC-SHA1 result.
DT(String) // String = String[0]...String[19] DT(String) // String = String[0]...String[19]
HOTP: An HMAC-based One Time Password Algorithm October 2004
Let OffsetBits be the low order four bits of String[19] Let OffsetBits be the low order four bits of String[19]
Offset = StToNum(OffSetBits) // 0 <= OffSet <= 15 Offset = StToNum(OffSetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3] Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P Return the Last 31 bits of P
The reason for masking the most significant bit of P is to avoid The reason for masking the most significant bit of P is to avoid
confusion about signed vs. unsigned modulo computations. Different confusion about signed vs. unsigned modulo computations. Different
processors perform these operations differently, and masking out processors perform these operations differently, and masking out
the signed bit removes all ambiguity. the signed bit removes all ambiguity.
skipping to change at page 7, line 48 skipping to change at page 8, line 4
------------------------------------------------------------- -------------------------------------------------------------
| Byte Number | | Byte Number |
------------------------------------------------------------- -------------------------------------------------------------
|00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19| |00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|
------------------------------------------------------------- -------------------------------------------------------------
| Byte Value | | Byte Value |
------------------------------------------------------------- -------------------------------------------------------------
|1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a| |1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a|
-------------------------------***********----------------++| -------------------------------***********----------------++|
HOTP: An HMAC-based One Time Password Algorithm October 2004
* The last byte (byte 19) has the hex value 0x5a. * The last byte (byte 19) has the hex value 0x5a.
* The value of the lower four bits is 0xa (the offset value). * The value of the lower four bits is 0xa (the offset value).
* The offset value is byte 10 (0xa). * The offset value is byte 10 (0xa).
* The value of the 4 bytes starting at byte 10 is 0x50ef7f19, * The value of the 4 bytes starting at byte 10 is 0x50ef7f19,
which is the dynamic binary code DBC1 which is the dynamic binary code DBC1
HOTP: An HMAC-based One Time Password Algorithm October 2004
* The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19 * The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19
* HOTP = DBC2 modulo 10^6 = 872921. * HOTP = DBC2 modulo 10^6 = 872921.
We treat the dynamic binary code as a 31-bit, unsigned, big-endian We treat the dynamic binary code as a 31-bit, unsigned, big-endian
integer; the first byte is masked with a 0x7f. integer; the first byte is masked with a 0x7f.
We then take this number modulo 1,000,000 (10^6) to generate the We then take this number modulo 1,000,000 (10^6) to generate the
6-digit HOTP value 872921 decimal. 6-digit HOTP value 872921 decimal.
6. Security and Deployment Considerations 6. Security Considerations
Any One-Time Password algorithm is only as secure as the Any One-Time Password algorithm is only as secure as the
application and the authentication protocols that implement it. application and the authentication protocols that implement it.
Therefore, this section discusses the critical security Therefore, this section discusses the critical security
requirements that our choice of algorithm imposes on the requirements that our choice of algorithm imposes on the
authentication protocol and validation software. The parameters T authentication protocol and validation software.
and s discussed in this section have a significant impact on the
security - further details in Section 7 elaborate on the relations The parameters T and s discussed in this section have a significant
between these parameters and their impact on the system security. impact on the security - further details in Section 7 elaborate on
the relations between these parameters and their impact on the
system security.
6.1 Authentication Protocol Requirements 6.1 Authentication Protocol Requirements
We introduce in this section some requirements for a protocol P We introduce in this section some requirements for a protocol P
implementing HOTP as the authentication method between a prover and implementing HOTP as the authentication method between a prover and
a verifier. a verifier.
RP1 - P MUST be two-factor, i.e. something you know (secret code RP1 - P MUST be two-factor, i.e. something you know (secret code
such as a Password, Pass phrase, PIN code, etc.) and something you such as a Password, Pass phrase, PIN code, etc.) and something you
have (token). The secret code is known only to the user and usually have (token). The secret code is known only to the user and usually
skipping to change at page 8, line 46 skipping to change at page 9, line 4
(two-factor authentication). (two-factor authentication).
RP3 - P MUST NOT be vulnerable to brute force attacks. This implies RP3 - P MUST NOT be vulnerable to brute force attacks. This implies
that a throttling/lockout scheme is REQUIRED on the validation that a throttling/lockout scheme is REQUIRED on the validation
server side. server side.
RP4 - P SHOULD be implemented with respect to the state of the art RP4 - P SHOULD be implemented with respect to the state of the art
in terms of security, in order to avoid the usual attacks and risks in terms of security, in order to avoid the usual attacks and risks
associated with the transmission of sensitive data over a public associated with the transmission of sensitive data over a public
network (privacy, replay attacks, etc.) network (privacy, replay attacks, etc.)
HOTP: An HMAC-based One Time Password Algorithm October 2004
6.2 Validation of HOTP values 6.2 Validation of HOTP values
The HOTP client (hardware or software token) increments its counter The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP-client. If the value and then calculates the next HOTP value HOTP-client. If the value
received by the authentication server matches the value calculated received by the authentication server matches the value calculated
by the client, then the HOTP value is validated. In this case, the by the client, then the HOTP value is validated. In this case, the
server increments the counter value by one. server increments the counter value by one.
HOTP: An HMAC-based One Time Password Algorithm October 2004
If the value received by the server does not match the value If the value received by the server does not match the value
calculated by the client, the server initiate the resynch protocol calculated by the client, the server initiate the resynch protocol
(look-ahead window) before it requests another pass. (look-ahead window) before it requests another pass.
If the resynch fails, the server asks then for another If the resynch fails, the server asks then for another
authentication pass of the protocol to take place, until the authentication pass of the protocol to take place, until the
maximum number of authorized attempts is reached. maximum number of authorized attempts is reached.
If and when the maximum number of authorized attempts is reached, If and when the maximum number of authorized attempts is reached,
the server SHOULD lock out the account and initiate a procedure to the server SHOULD lock out the account and initiate a procedure to
skipping to change at page 9, line 47 skipping to change at page 10, line 5
successful HOTP authentication, the counter on the token is successful HOTP authentication, the counter on the token is
incremented every time a new HOTP is requested by the user. Because incremented every time a new HOTP is requested by the user. Because
of this, the counter values on the server and on the token might be of this, the counter values on the server and on the token might be
out of synchronization. out of synchronization.
We RECOMMEND setting a look-ahead parameter s on the server, which We RECOMMEND setting a look-ahead parameter s on the server, which
defines the size of the look-ahead window. In a nutshell, the defines the size of the look-ahead window. In a nutshell, the
server can recalculate the next s HOTP-server values, and check server can recalculate the next s HOTP-server values, and check
them against the received HOTP-client. them against the received HOTP-client.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Synchronization of counters in this scenario simply requires the Synchronization of counters in this scenario simply requires the
server to calculate the next HOTP values and determine if there is server to calculate the next HOTP values and determine if there is
a match. Optionally, the system MAY require the user to send a a match. Optionally, the system MAY require the user to send a
sequence of (say 2, 3) HOTP values for resynchronization purpose, sequence of (say 2, 3) HOTP values for resynchronization purpose,
since forging a sequence of consecutive HOTP values is even more since forging a sequence of consecutive HOTP values is even more
difficult than guessing a single HOTP value. difficult than guessing a single HOTP value.
HOTP: An HMAC-based One Time Password Algorithm October 2004
The upper bound set by the parameter s ensures the server does not The upper bound set by the parameter s ensures the server does not
go on checking HOTP values forever (causing a DoS attack) and also go on checking HOTP values forever (causing a DoS attack) and also
restricts the space of possible solutions for an attacker trying to restricts the space of possible solutions for an attacker trying to
manufacture HOTP values. s SHOULD be set as low as possible, while manufacture HOTP values. s SHOULD be set as low as possible, while
still ensuring usability is not impacted. still ensuring usability is not impacted.
6.5 Management of Shared Secrets
The operations dealing with the shared secrets used to generate and
verify OTP values must be performed securely, in order to mitigate
risks of any leakage of sensitive information. We describe in this
section different modes of operations and techniquest to perform
these different operations with respect of the state of the art in
terms of data security.
We can consider two different avenues for generating and storing
(securely) shared secrets in the Validation system:
* Deterministic Generation: secrets are derived from a master
seed, both at provisioning and verification stages and generated
on-the-fly whenever it is required;
* Random Generation: secrets are generated randomly at
provisioning stage, and must be stored immediately and kept secure
during their life cycle.
Deterministic Generation
------------------------
A possible strategy is to derive the shared secrets from a master
secret. In this case, a tamper resistant device SHOULD be
generating the shared secrets based on the master seed and some
public information. The main benefit would be to avoid the exposure
of the shared secrets at any time and also avoid specific
requirements on storage, since the shared secrets could be
generated on-demand when needed at provisioning and validation
time.
The drawback in this case is that the exposure of the master secret
would obviously enable an attacker to rebuild any shared secret
based on correct public information. On the other hand, the device
being tamper resistant, and also, obvioulsly not exposed outside
HOTP: An HMAC-based One Time Password Algorithm October 2004
the security perimeter of the validation system, the risk of such a
break-out could be reduced.
Another option to mitigate the risk, would be to use a series of
master secrets, say MS1 to MS5, and generate a set of shared
secrets to be stored in the OTP generator devices. In this case, if
a master secret was compromised, then the system could switch to
another shared secret by selecting the proper secret in the device.
This is probably not applicable in all situations, and therefore,
the random generation method describes hereafter might be more
suited in some cases.
Random Generation
-----------------
The shared secrets are randomly generated. We RECOMMEND the usage
of a good random source for generating them. A (true) random
generator requires a naturally occurring source of randomness.
Practically, there are two possible avenues to consider for the
generation of the shared secrets:
* Hardware-based generators: they exploit the randomness which
occurs in physical phenomena. A nice implementation can be based on
oscillators, and built in such ways that active attacks are more
difficult to perform.
* Software-based generators: designing a good software random
generator is not an easy task. A simple, but efficient,
implementation should be based on various sources, and apply to the
sampled sequence a one-way function such as SHA-1.
We RECOMMEND to select proven products, being hardware or software
generators for the computation of shared secrets.
We also RECOMMEND storing the shared secrets securely, and more
specifically encrypting the shared secrets when stored using
tamper-resistant hardware encryption, and exposing them only when
required: e.g. the shared secret is decrypted when needed to verify
an HOTP value, and re-encrypted immediately to limit exposure in
the RAM for a short period of time. The data store holding the
shared secrets MUST be in a secure area, to avoid as much as
possible direct attack on the validation system and secrets
database.
Particularly, access to the shared secrets should be limited to
programs and processes required by the validation system only. We
will not elaborate on the different security mechanisms to put in
place, but obviously, the protection of shared secrets is of the
uttermost importance.
HOTP: An HMAC-based One Time Password Algorithm October 2004
7. HOTP Algorithm Security: Overview 7. HOTP Algorithm Security: Overview
The conclusion of the security analysis detailed in the Appendix The conclusion of the security analysis detailed in the Appendix
section is that, for all practical purposes, the outputs of the section is that, for all practical purposes, the outputs of the
dynamic truncation (DT) on distinct counter inputs are uniformly dynamic truncation (DT) on distinct counter inputs are uniformly
and independently distributed 31-bit strings. and independently distributed 31-bit strings.
The security analysis then details the impact of the conversion The security analysis then details the impact of the conversion
from a string to an integer and the final reduction modulo from a string to an integer and the final reduction modulo
10^Digit, where Digit is the number of digits in an HOTP value. 10^Digit, where Digit is the number of digits in an HOTP value.
skipping to change at page 11, line 5 skipping to change at page 12, line 50
- Sec is the probability of success of the adversary - Sec is the probability of success of the adversary
- s stands for the look-ahead synchronization window size; - s stands for the look-ahead synchronization window size;
- v stands for the number of verification attempts; - v stands for the number of verification attempts;
- Digit stands for the number of digits in HOTP values. - Digit stands for the number of digits in HOTP values.
Obviously, we can play with s, T (the Throttling parameter that Obviously, we can play with s, T (the Throttling parameter that
would limit the number of attempts by an attacker) and Digit until would limit the number of attempts by an attacker) and Digit until
achieving a certain level of security, still preserving the system achieving a certain level of security, still preserving the system
usability. usability.
HOTP: An HMAC-based One Time Password Algorithm October 2004 8. Protocol Extensions and Improvements
8. Protocol Extensions and Improvements
We introduce in this section several enhancements and suggestions We introduce in this section several enhancements and suggestions
to further improve the security of the algorithm HOTP to further improve the security of the algorithm HOTP
HOTP: An HMAC-based One Time Password Algorithm October 2004
8.1 Number of Digits 8.1 Number of Digits
A simple enhancement in terms of security would be to extract more A simple enhancement in terms of security would be to extract more
digits from the HMAC-SHA1 value. digits from the HMAC-SHA1 value.
For instance, calculating the HOTP value modulo 10^8 to build an For instance, calculating the HOTP value modulo 10^8 to build an
8-digit HOTP value would reduce the probability of success of the 8-digit HOTP value would reduce the probability of success of the
adversary from sv/10^6 to sv/10^8. adversary from sv/10^6 to sv/10^8.
skipping to change at page 12, line 5 skipping to change at page 13, line 50
values could be a simple and efficient way to improve security at a values could be a simple and efficient way to improve security at a
reduced cost and impact on users. reduced cost and impact on users.
8.3 Sequence of HOTP values 8.3 Sequence of HOTP values
As we suggested for the resynchronization to enter a short sequence As we suggested for the resynchronization to enter a short sequence
(say 2 or 3) of HOTP values, we could generalize the concept to the (say 2 or 3) of HOTP values, we could generalize the concept to the
protocol, and add a parameter L that would define the length of the protocol, and add a parameter L that would define the length of the
HOTP sequence to enter. HOTP sequence to enter.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Per default, the value L SHOULD be set to 1, but if security needs Per default, the value L SHOULD be set to 1, but if security needs
to be increased, users might be asked (possibly for a short period to be increased, users might be asked (possibly for a short period
of time, or a specific operation) to enter L HOTP values. of time, or a specific operation) to enter L HOTP values.
HOTP: An HMAC-based One Time Password Algorithm October 2004
This is another way, without increasing the HOTP length or using This is another way, without increasing the HOTP length or using
alphanumeric values to tighten security. alphanumeric values to tighten security.
Note: The system MAY also be programmed to request synchronization Note: The system MAY also be programmed to request synchronization
on a regular basis (e.g. every night, or twice a week, etc.) and to on a regular basis (e.g. every night, or twice a week, etc.) and to
achieve this purpose, ask for a sequence of L HOTP values. achieve this purpose, ask for a sequence of L HOTP values.
8.4 A Counter-based Re-Synchronization Method 8.4 A Counter-based Re-Synchronization Method
In this case, we assume that the client can access and send not In this case, we assume that the client can access and send not
skipping to change at page 12, line 39 skipping to change at page 14, line 35
Resynchronization Counter-based Protocol (RCP) Resynchronization Counter-based Protocol (RCP)
---------------------------------------------- ----------------------------------------------
The server accepts if the following are all true, where C-server is The server accepts if the following are all true, where C-server is
its own current counter value: its own current counter value:
1) C-client >= C-server 1) C-client >= C-server
2) C-client - C-server <= s 2) C-client - C-server <= s
3) Check that HOTP-client is valid HOTP(K,C-Client) 3) Check that HOTP-client is valid HOTP(K,C-Client)
4) If true, the server sets C to C-client + 1 and client 4) If true, the server sets C to C-client + 1 and client is
is authenticated authenticated
In this case, there is no need for managing a look-ahead window In this case, there is no need for managing a look-ahead window
anymore. The probability of success of the adversary is only v/10^6 anymore. The probability of success of the adversary is only v/10^6
or roughly v in one million. A side benefit is obviously to be able or roughly v in one million. A side benefit is obviously to be able
to increase s "infinitely" and therefore improve the system to increase s "infinitely" and therefore improve the system
usability without impacting the security. usability without impacting the security.
This resynchronization protocol SHOULD be use whenever the related This resynchronization protocol SHOULD be use whenever the related
impact on the client and server applications is deemed acceptable. impact on the client and server applications is deemed acceptable.
8.5 Composite Shared Secrets
It may be desirable to include additional authentication factors in
the shared secret K. These additional factors can consist of any
data known at the token but not easily obtained by others. Examples
of such data include:
* PIN or Password obtained as user input at the token
* Phone number
* Any unique identifier programmatically available at the token
HOTP: An HMAC-based One Time Password Algorithm October 2004
In this scenario the composite shared secret K is constructed
during the provisioning process from a random seed value combined
with one or more additional authentication factors. The server
could either build on-demand or store composite secrets - in any
case, depending on implementation choice, the token only stores the
seed value. When the token performs the HOTP calculation it
computes K from the seed value and the locally derived or input
values of the other authentication factors.
The use of composite shared secrets can strengthen HOTP based
authentication systems through the inclusion of additional
authentication factors at the token. To the extent that the token
is a trusted device this approach has the further benefit of not
requiring exposure of the authentication factors (such as the user
input PIN) to other devices.
8.6 Data Field
Another possibility would be to introduce the notion of a Data
field, that would be used for generating the One-Time password
values: HOTP (K, C, [Data]) where Data is an optional field that
can be the concatenation of various pieces of identity-related
information - e.g. Data = Address | PIN.
We could also use a Timer, either as the only moving factor or in
combination with the Counter - in this case, e.g. Data = Timer,
where Timer could be the UNIX-time (GMT seconds since 1/1/1970)
divided by some factor (8, 16, 32, etc.) in order to give a
specific time step. The time window for the One-Time Password is
then equal to the time step multiplied by the resynchronization
parameter as defined before - e.g. if we take 64 seconds as the
time step and 7 for the resynchronization parameter, we obtain an
acceptance window of +/- 3 minutes.
Using a Data field opens for more flexibility in the algorithm
implementation, provided that the Data field is clearly specified.
9. Conclusion 9. Conclusion
This draft describes HOTP, a HMAC-based One-Time Password This draft describes HOTP, a HMAC-based One-Time Password
algorithm. It also recommends the preferred implementation and algorithm. It also recommends the preferred implementation and
related modes of operations for deploying the algorithm. related modes of operations for deploying the algorithm.
HOTP: An HMAC-based One Time Password Algorithm October 2004
The draft also exhibits elements of security and demonstrates that The draft also exhibits elements of security and demonstrates that
the HOTP algorithm is practical and sound, the best possible attack the HOTP algorithm is practical and sound, the best possible attack
being a brute force attack that can be prevented by careful being a brute force attack that can be prevented by careful
implementation of countermeasures in the validation server. implementation of countermeasures in the validation server.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Eventually, several enhancements have been proposed, in order to Eventually, several enhancements have been proposed, in order to
improve security if needed for specific applications. improve security if needed for specific applications.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren
Hart and Nico Popp for their help during the conception and Hart and Nico Popp for their help during the conception and
redaction of this document. redaction of this document.
11. Contributors 11. Contributors
The authors of this draft would like to emphasize the role of two The authors of this draft would like to emphasize the role of three
persons who have made a key contribution to this document: persons who have made a key contribution to this document:
- Laszlo Elteto is system architect with SafeNet, Inc. - Laszlo Elteto is system architect with SafeNet, Inc.
- Ernesto Frutos is director of Engineering with Authenex, Inc. - Ernesto Frutos is director of Engineering with Authenex, Inc.
- Fred McClain is Founder and CTO with Boojum Mobile, Inc.
Without their advice and valuable inputs, this draft would not be Without their advice and valuable inputs, this draft would not be
the same. the same.
12. References 12. References
12.1 Normative 12.1 Normative
[BCK1] M. Bellare, R. Canetti, and H. Krawczyk, Keyed Hash [BCK1] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash
Functions and Message Authentication, Proceedings of Functions and Message Authentication", Proceedings of
Crypto'96, LNCS Vol. 1109, pp. 1-15. Crypto'96, LNCS Vol. 1109, pp. 1-15.
[BCK2] M. Bellare, R. Canetti, and H. Krawczyk, HMAC: [BCK2] M. Bellare, R. Canetti and H. Krawczyk, "HMAC:
Keyed-Hashing for Message Authentication, IETF Network Keyed-Hashing for Message Authentication", IETF Network
Working Group, RFC 2104, February 1997. Working Group, RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3668] Bradner, S., "Intellectual Propery Rights in IETF [RFC3668] S. Bradner, "Intellectual Propery Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
12.2 Informative 12.2 Informative
[OATH] www.openauthentication.org, Initiative for Open [OATH] Initiative for Open AuTHentication
AuTHentication http://www.openauthentication.org
[PrOo] B. Preneel and P. van Oorschot, "MD-x MAC and building
fast MACs from hash functions", Advances in Cryptology
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
CRYPTO '95, Lecture Notes in Computer Science Vol. 963,
D. Coppersmith ed., Springer-Verlag, 1995.
[Crack] Crack in SHA-1 code 'stuns' security gurus
http://www.eetimes.com/showArticle.jhtml?articleID=60402150
[Sha1] Bruce Schneier. SHA-1 broken. February 15, 2005.
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
[Res] Researchers: Digital encryption standard flawed
http://news.com.com/Researchers+Digital+encryption+standard+flawed/
2100-1002-5579881.html?part=dht&tag=ntop&tag=nl.e703
13. Authors' Addresses 13. Authors' Addresses
Primary point of contact (for sending comments and question): Primary point of contact (for sending comments and question):
David M'Raihi David M'Raihi
VeriSign, Inc. VeriSign, Inc.
685 E. Middlefield Road Phone: 1-650-426-3832 685 E. Middlefield Road Phone: 1-650-426-3832
Mountain View, CA 94043 USA Email: dmraihi@verisign.com Mountain View, CA 94043 USA Email: dmraihi@verisign.com
Other Authors' contact information: Other Authors' contact information:
skipping to change at page 14, line 41 skipping to change at page 18, line 4
Issy les Moulineaux, France Email: david.naccache@gemplus.com Issy les Moulineaux, France Email: david.naccache@gemplus.com
and and
Information Security Group, Information Security Group,
Royal Holloway, Royal Holloway,
University of London, Egham, University of London, Egham,
Surrey TW20 0EX, UK Email: david.naccache@rhul.ac.uk Surrey TW20 0EX, UK Email: david.naccache@rhul.ac.uk
Ohad Ranen Ohad Ranen
Aladdin Knowledge Systems Ltd. Aladdin Knowledge Systems Ltd.
15 Beit Oved Street 15 Beit Oved Street
HOTP: An HMAC-based One Time Password Algorithm October 2004
Tel Aviv, Israel 61110 Email: Ohad.Ranen@ealaddin.com Tel Aviv, Israel 61110 Email: Ohad.Ranen@ealaddin.com
Appendix A - HOTP Algorithm Security: Detailed Analysis Appendix A - HOTP Algorithm Security: Detailed Analysis
The security analysis of the HOTP algorithm is summarized in this The security analysis of the HOTP algorithm is summarized in this
section. We first detail the best attack strategies, and then section. We first detail the best attack strategies, and then
elaborate on the security under various assumptions, the impact of elaborate on the security under various assumptions, the impact of
the truncation and some recommendations regarding the number of the truncation and some recommendations regarding the number of
digits. digits.
HOTP: An HMAC-based One Time Password Algorithm October 2004
We focus this analysis on the case where Digit = 6, i.e. an HOTP We focus this analysis on the case where Digit = 6, i.e. an HOTP
function that produces 6-digit values, which is the bare minimum function that produces 6-digit values, which is the bare minimum
recommended in this draft. recommended in this draft.
A.1 Definitions and Notations A.1 Definitions and Notations
We denote by {0,1}^l the set of all strings of length l. We denote by {0,1}^l the set of all strings of length l.
Let Z_{n} = {0,.., n - 1}. Let Z_{n} = {0,.., n - 1}.
skipping to change at page 15, line 44 skipping to change at page 19, line 4
mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key
space Maps(c,n), so that a "key" for such an algorithm is a space Maps(c,n), so that a "key" for such an algorithm is a
function h from {0,1}^c to {0,1}^n. We imagine this key (function) function h from {0,1}^c to {0,1}^n. We imagine this key (function)
to be drawn at random. It is not feasible to implement this to be drawn at random. It is not feasible to implement this
idealized algorithm, since the key, being a function from is way idealized algorithm, since the key, being a function from is way
too large to even store. So why consider it? too large to even store. So why consider it?
Our security analysis will show that as long as H satisfies a Our security analysis will show that as long as H satisfies a
certain well-accepted assumption, the security of the actual and certain well-accepted assumption, the security of the actual and
idealized algorithms is for all practical purposes the same. The idealized algorithms is for all practical purposes the same. The
HOTP: An HMAC-based One Time Password Algorithm October 2004
task that really faces us, then, is to assess the security of the task that really faces us, then, is to assess the security of the
idealized algorithm. idealized algorithm.
In analyzing the idealized algorithm, we are concentrating on In analyzing the idealized algorithm, we are concentrating on
assessing the quality of the design of the algorithm itself, assessing the quality of the design of the algorithm itself,
independently of HMAC-SHA-1. This is in fact the important issue. independently of HMAC-SHA-1. This is in fact the important issue.
A.3 Model of Security A.3 Model of Security
The model exhibits the type of threats or attacks that are being The model exhibits the type of threats or attacks that are being
considered and enables to asses the security of HOTP and considered and enables to asses the security of HOTP and
HOTP: An HMAC-based One Time Password Algorithm October 2004
HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the
purpose of this security analysis. purpose of this security analysis.
The scenario we are considering is that a user and server share a The scenario we are considering is that a user and server share a
key K for ALG. Both maintain a counter C, initially zero, and the key K for ALG. Both maintain a counter C, initially zero, and the
user authenticates itself by sending ALG(K,C) to the server. The user authenticates itself by sending ALG(K,C) to the server. The
latter accepts if this value is correct. latter accepts if this value is correct.
In order to protect against accidental increment of the user In order to protect against accidental increment of the user
counter, the server, upon receiving a value z, will accept as long counter, the server, upon receiving a value z, will accept as long
skipping to change at page 16, line 43 skipping to change at page 20, line 5
The model gives B full control of the scheduling of events. It has The model gives B full control of the scheduling of events. It has
access to an authenticator oracle representing the user. By calling access to an authenticator oracle representing the user. By calling
this oracle, the adversary can ask the user to authenticate itself this oracle, the adversary can ask the user to authenticate itself
and get back the authenticator in return. It can call this oracle and get back the authenticator in return. It can call this oracle
as often as it wants and when it wants, using the authenticators it as often as it wants and when it wants, using the authenticators it
accumulates to perhaps "learn" how to make authenticators itself. accumulates to perhaps "learn" how to make authenticators itself.
At any time, it may also call a verification oracle, supplying the At any time, it may also call a verification oracle, supplying the
latter with a candidate authenticator of its choice. It wins if the latter with a candidate authenticator of its choice. It wins if the
server accepts this accumulator. server accepts this accumulator.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Consider the following game involving an adversary B that is Consider the following game involving an adversary B that is
attempting to compromise the security of an authentication attempting to compromise the security of an authentication
algorithm ALG: K x {0,1}^c --> R. algorithm ALG: K x {0,1}^c --> R.
Initializations - A key K is selected at random from K, a counter C Initializations - A key K is selected at random from K, a counter C
is initialized to 0, and the Boolean value win is set to false. is initialized to 0, and the Boolean value win is set to false.
Game execution - Adversary B is provided with the two following Game execution - Adversary B is provided with the two following
oracles: oracles:
Oracle AuthO() Oracle AuthO()
O = ALG(K,C) --------------
HOTP: An HMAC-based One Time Password Algorithm October 2004 A = ALG(K,C)
C = C + 1 C = C + 1
Return O to B Return O to B
Oracle VerO() Oracle VerO(A)
--------------
i = C i = C
While (i <= C + s - 1 and Win = FALSE) do While (i <= C + s - 1 and Win == FALSE) do
If O = ALG(K,i) then Win = TRUE; C = i + 1 If A == ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1 Else i = i + 1
Return Win to B Return Win to B
AuthO() is the authenticator oracle and VerO() is the verification AuthO() is the authenticator oracle and VerO(A) is the verification
oracle. oracle.
Upon execution, B queries the two oracles at will. Let Adv(B) be Upon execution, B queries the two oracles at will. Let Adv(B) be
the probability that win gets set to true in the above game. This the probability that win gets set to true in the above game. This
is the probability that the adversary successfully impersonates the is the probability that the adversary successfully impersonates the
user. user.
Our goal is to assess how large this value can be as a function of Our goal is to assess how large this value can be as a function of
the number v of verification queries made by B, the number a of the number v of verification queries made by B, the number a of
authenticator oracle queries made by B, and the running time t of authenticator oracle queries made by B, and the running time t of
B. This will tell us how to set the throttle, which effectively B. This will tell us how to set the throttle, which effectively
upper bounds v. upper bounds v.
A.4 Security of the ideal authentication algorithm A.4 Security of the ideal authentication algorithm
This section summarizes the security analysis of HOTP-IDEAL, This section summarizes the security analysis of HOTP-IDEAL,
starting with the impact of the conversion modulo 10^Digit and starting with the impact of the conversion modulo 10^Digit and
then, focusing on the different possible attacks. then, focusing on the different possible attacks.
HOTP: An HMAC-based One Time Password Algorithm October 2004
A.4.1 From bits to digits A.4.1 From bits to digits
The dynamic offset truncation of a random n-bit string yields a The dynamic offset truncation of a random n-bit string yields a
random 31-bit string. What happens to the distribution when it is random 31-bit string. What happens to the distribution when it is
taken modulo m = 10^Digit, as done in HOTP? taken modulo m = 10^Digit, as done in HOTP?
The following lemma estimates the biases in the outputs in this The following lemma estimates the biases in the outputs in this
case. case.
Lemma 1 Lemma 1
-------
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let: Z_{m} let:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}] P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Then for any z in Z_{m} Then for any z in Z_{m}
P_{N,m}(z) = (q + 1) / N if 0 <= z < r P_{N,m}(z) = (q + 1) / N if 0 <= z < r
HOTP: An HMAC-based One Time Password Algorithm October 2004
q / N if r <= z < m q / N if r <= z < m
Proof of Lemma 1 Proof of Lemma 1
----------------
Let the random variable X be uniformly distributed over Z_{N}. Let the random variable X be uniformly distributed over Z_{N}.
Then: Then:
P_{N,m}(z) = Pr [X mod m = z] P_{N,m}(z) = Pr [X mod m = z]
= Pr [X < mq] * Pr [X mod m = z| X < mq] = Pr [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N] + Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= mq/N * 1/m + = mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq (N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
skipping to change at page 18, line 35 skipping to change at page 22, line 4
Simplifying yields the claimed equation. Simplifying yields the claimed equation.
Let N = 2^31, d = 6 and m = 10^d. If x is chosen at random from Let N = 2^31, d = 6 and m = 10^d. If x is chosen at random from
Z_{N} (meaning, is a random 31-bit string), then reducing it to a Z_{N} (meaning, is a random 31-bit string), then reducing it to a
6-digit number by taking x mod m does not yield a random 6-digit 6-digit number by taking x mod m does not yield a random 6-digit
number. number.
Rather, x mod m is distributed as shown in the following table: Rather, x mod m is distributed as shown in the following table:
Values Probability that each appears as output Values Probability that each appears as output
HOTP: An HMAC-based One Time Password Algorithm October 2004
---------------------------------------------------------------- ----------------------------------------------------------------
0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6 0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6
483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6 483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6
If X is uniformly distributed over Z_{2^31} (meaning is a random If X is uniformly distributed over Z_{2^31} (meaning is a random
31-bit string) then the above shows the probabilities for different 31-bit string) then the above shows the probabilities for different
outputs of X mod 10^6. The first set of values appear with outputs of X mod 10^6. The first set of values appear with
probability slightly greater than 10^-6, the rest with probability probability slightly greater than 10^-6, the rest with probability
slightly less, meaning the distribution is slightly non-uniform. slightly less, meaning the distribution is slightly non-uniform.
However, as the Figure indicates, the bias is small and as we will However, as the Figure indicates, the bias is small and as we will
see later, negligible: the probabilities are very close to 10^-6. see later, negligible: the probabilities are very close to 10^-6.
A.4.2 Brute force attacks A.4.2 Brute force attacks
If the authenticator consisted of d random digits, then a brute If the authenticator consisted of d random digits, then a brute
force attack using v verification attempts would succeed with force attack using v verification attempts would succeed with
probability sv/10^Digit. probability sv/10^Digit.
HOTP: An HMAC-based One Time Password Algorithm October 2004
However, an adversary can exploit the bias in the outputs of HOTP- However, an adversary can exploit the bias in the outputs of HOTP-
IDEAL, predicted by Lemma 1, to mount a slightly better attack. IDEAL, predicted by Lemma 1, to mount a slightly better attack.
Namely, it makes authentication attempts with authenticators which Namely, it makes authentication attempts with authenticators which
are the most likely values, meaning the ones in the range 0,...,r - are the most likely values, meaning the ones in the range 0,...,r -
1, where (q,r) = IntDiv(2^31,10^Digit). 1, where (q,r) = IntDiv(2^31,10^Digit).
The following specifies an adversary in our model of security that The following specifies an adversary in our model of security that
mounts the attack. It estimates the success probability as a mounts the attack. It estimates the success probability as a
function of the number of verification queries. function of the number of verification queries.
For simplicity, we assume the number of verification queries is at For simplicity, we assume the number of verification queries is at
most r. With N = 2^31 and m = 10^6 we have r = 483,648, and the most r. With N = 2^31 and m = 10^6 we have r = 483,648, and the
throttle value is certainly less than this, so this assumption is throttle value is certainly less than this, so this assumption is
not much of a restriction. not much of a restriction.
Proposition 1 Proposition 1
-------------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume
s <= m. The brute-force attack adversary B-bf attacks HOTP using v s <= m. The brute-force attack adversary B-bf attacks HOTP using v
<= r verification oracle queries. This adversary makes no <= r verification oracle queries. This adversary makes no
authenticator oracle queries, and succeeds with probability authenticator oracle queries, and succeeds with probability
Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s
which is roughly equals to which is roughly equals to
sv * (q+1)/2^31 sv * (q+1)/2^31
HOTP: An HMAC-based One Time Password Algorithm October 2004
With m = 10^6 we get q = 2,147. In that case, the brute force With m = 10^6 we get q = 2,147. In that case, the brute force
attack using v verification attempts succeeds with probability attack using v verification attempts succeeds with probability
Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6 Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6
As this equation shows, the resynchronization parameter s has a As this equation shows, the resynchronization parameter s has a
significant impact in that the adversary's success probability is significant impact in that the adversary's success probability is
proportional to s. This means that s cannot be made too large proportional to s. This means that s cannot be made too large
without compromising security. without compromising security.
A.4.3 Brute force attacks are the best possible attacks A.4.3 Brute force attacks are the best possible attacks
A central question is whether there are attacks any better than the A central question is whether there are attacks any better than the
brute force one. In particular, the brute force attack did not brute force one. In particular, the brute force attack did not
attempt to collect authenticators sent by the user and try to attempt to collect authenticators sent by the user and try to
cryptanalyze them in an attempt to learn how to better construct cryptanalyze them in an attempt to learn how to better construct
authenticators. Would doing this help? Is there some way to "learn" authenticators. Would doing this help? Is there some way to "learn"
how to build authenticators that result in a higher success rate how to build authenticators that result in a higher success rate
than given by the brute-force attack? than given by the brute-force attack?
HOTP: An HMAC-based One Time Password Algorithm October 2004
The following says the answer to these questions is no. No matter The following says the answer to these questions is no. No matter
what strategy the adversary uses, and even if it sees, and tries to what strategy the adversary uses, and even if it sees, and tries to
exploit, the authenticators from authentication attempts of the exploit, the authenticators from authentication attempts of the
user, its success probability will not be above that of the brute user, its success probability will not be above that of the brute
force attack - this is true as long as the number of force attack - this is true as long as the number of
authentications it observes is not incredibly large. This is authentications it observes is not incredibly large. This is
valuable information regarding the security of the scheme. valuable information regarding the security of the scheme.
Proposition 2 Proposition 2
-------------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B
be any adversary attacking HOTP-IDEAL using v verification oracle be any adversary attacking HOTP-IDEAL using v verification oracle
queries and a <= 2^c - s authenticator oracle queries. Then queries and a <= 2^c - s authenticator oracle queries. Then
Adv(B) < = sv * (q+1)/ 2^31 Adv(B) < = sv * (q+1)/ 2^31
Note: This result is conditional on the adversary not seeing more Note: This result is conditional on the adversary not seeing more
than 2^c - s authentications performed by the user, which is hardly than 2^c - s authentications performed by the user, which is hardly
restrictive as long as c is large enough. restrictive as long as c is large enough.
With m = 10^6 we get q = 2,147. In that case, Proposition 2 says With m = 10^6 we get q = 2,147. In that case, Proposition 2 says
that any adversary B attacking HOTP-IDEAL and making v verification that any adversary B attacking HOTP-IDEAL and making v verification
attempts succeeds with probability at most attempts succeeds with probability at most
Equation 1 Equation 1
----------
sv * 2148/2^31 roughly = sv * 1.00024045/10^6 sv * 2148/2^31 roughly = sv * 1.00024045/10^6
HOTP: An HMAC-based One Time Password Algorithm October 2004
Meaning, B's success rate is not more than that achieved by the Meaning, B's success rate is not more than that achieved by the
brute force attack. brute force attack.
A.5 Security Analysis of HOTP A.5 Security Analysis of HOTP
We have analyzed in the previous sections, the security of the We have analyzed in the previous sections, the security of the
idealized counterparts HOTP-IDEAL of the actual authentication idealized counterparts HOTP-IDEAL of the actual authentication
algorithm HOTP. We now show that, under appropriate and algorithm HOTP. We now show that, under appropriate and
well-believed assumption on H, the security of the actual well-believed assumption on H, the security of the actual
skipping to change at page 21, line 5 skipping to change at page 24, line 28
The assumption in question is that H is a secure pseudorandom The assumption in question is that H is a secure pseudorandom
function, or PRF, meaning that its input-output values are function, or PRF, meaning that its input-output values are
indistinguishable from those of a random function in practice. indistinguishable from those of a random function in practice.
Consider an adversary A that is given an oracle for a function f: Consider an adversary A that is given an oracle for a function f:
{0,1}^c --> {0, 1}^n and eventually outputs a bit. We denote Adv(A) {0,1}^c --> {0, 1}^n and eventually outputs a bit. We denote Adv(A)
as the prf-advantage of A, which represents how well the adversary as the prf-advantage of A, which represents how well the adversary
does at distinguishing the case where its oracle is H(K,.) from the does at distinguishing the case where its oracle is H(K,.) from the
case where its oracle is a random function of {0,1}^c to {0,1}^n. case where its oracle is a random function of {0,1}^c to {0,1}^n.
HOTP: An HMAC-based One Time Password Algorithm October 2004
One possible attack is based on exhaustive search for the key K. If One possible attack is based on exhaustive search for the key K. If
A runs for t steps and T denotes the time to perform one A runs for t steps and T denotes the time to perform one
computation of H, its prf-advantage from this attack turns out to computation of H, its prf-advantage from this attack turns out to
be (t/T)2^-k . Another possible attack is a birthday one [3], be (t/T)2^-k . Another possible attack is a birthday one [PrOo],
whereby A can attain advantage p^2/2^n in p oracle queries and whereby A can attain advantage p^2/2^n in p oracle queries and
running time about pT. running time about pT.
Our assumption is that these are the best possible attacks. This Our assumption is that these are the best possible attacks. This
translates into the following. translates into the following.
Assumption 1 Assumption 1
------------
Let T denotes the time to perform one computation of H. Then if A Let T denotes the time to perform one computation of H. Then if A
is any adversary with running time at most t and making at most p is any adversary with running time at most t and making at most p
oracle queries, oracle queries,
Adv(A) <= (t/T)/2^k + p^2/2^n Adv(A) <= (t/T)/2^k + p^2/2^n
In practice this assumption means that H is very secure as PRF. For In practice this assumption means that H is very secure as PRF. For
example, given that k = n = 160, an attacker with running time 2^60 example, given that k = n = 160, an attacker with running time 2^60
and making 2^40 oracle queries has advantage at most (about) 2^-80. and making 2^40 oracle queries has advantage at most (about) 2^-80.
Theorem 1 Theorem 1
---------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B
be any adversary attacking HOTP using v verification oracle be any adversary attacking HOTP using v verification oracle
HOTP: An HMAC-based One Time Password Algorithm October 2004
queries, a <= 2^c - s authenticator oracle queries, and running queries, a <= 2^c - s authenticator oracle queries, and running
time t. Let T denote the time to perform one computation of H. If time t. Let T denote the time to perform one computation of H. If
Assumption 1 is true then Assumption 1 is true then
Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n
In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller
than the sv(q + 1)/2^n term, so that the above says that for all than the sv(q + 1)/2^n term, so that the above says that for all
practical purposes the success rate of an adversary attacking HOTP practical purposes the success rate of an adversary attacking HOTP
is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP
skipping to change at page 22, line 5 skipping to change at page 25, line 30
adversary making v authentication attempts will have a success rate adversary making v authentication attempts will have a success rate
that is at most that of Equation 1. that is at most that of Equation 1.
For example, consider an adversary with running time at most 2^60 For example, consider an adversary with running time at most 2^60
that sees at most 2^40 authentication attempts of the user. Both that sees at most 2^40 authentication attempts of the user. Both
these choices are very generous to the adversary, who will these choices are very generous to the adversary, who will
typically not have these resources, but we are saying that even typically not have these resources, but we are saying that even
such a powerful adversary will not have more success than indicated such a powerful adversary will not have more success than indicated
by Equation 1. by Equation 1.
HOTP: An HMAC-based One Time Password Algorithm October 2004
We can safely assume sv <= 2^40 due to the throttling and bounds on We can safely assume sv <= 2^40 due to the throttling and bounds on
s. So: s. So:
(t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160 (t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160
roughly <= 2^-78 roughly <= 2^-78
which is much smaller than the success probability of Equation 1 which is much smaller than the success probability of Equation 1
and negligible compared to it. and negligible compared to it.
Appendix B - HOTP Algorithm: Reference Implementation Appendix B - SHA-1 Attacks
This sections addresses the impact of the recent attacks on SHA-1
on the security of the HMAC-SHA-1 based HOTP. We begin with some
discussion of the situation of SHA-1 and then discuss the relevance
to HMAC-SHA-1 and HOTP. Cited references are at the bottom of the
document.
B.1 SHA-1 status
A collision for a hash function h means a pair x,y of different
inputs such that h(x)=h(y). Since SHA-1 outputs 160 bits, a
birthday attack finds a collision in 2^{80} trials. (A trial means
one computation of the function.) This was thought to be the best
possible until Wang, Yin and Yu announced on February 15, 2005 that
they had an attack finding collisions in 2^{69} trials.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Is SHA-1 broken? For most practical purposes we would say probably
not, since the resources needed to mount the attack are huge. Here
is one way to get a sense of it: we can estimate it is about the
same as the time we would need to factor a 760-bit RSA modulus, and
this is currently considered out of reach.
Burr of NIST is quoted [Crack] as saying ``Large national
intelligence agencies could do this in a reasonable amount of time
with a few million dollars in computer time.'' However, the
computation may be out of reach of all but such well-funded
agencies.
One should also ask what impact finding SHA-1 collisions actually
has on security of real applications such as signatures. To exploit
a collision x,y to forge signatures, you need to somehow obtain a
signature of x and then you can forge a signature of y. How
damaging this is depends on the content of y: the y created by the
attack may not be meaningful in the application context. Also, one
needs a chosen-message attack to get the signature of x. This seems
possible in some contexts, but not others. Overall, it is not clear
the impact on the security of signatures is significant.
Indeed, one can read that SHA-1 is ``broken,'' [Sha1], that
encryption and SSL are ``broken'' [Res], in the press. The media
have a tendency to magnify events: it would hardly be interesting
to announce in the news that a team of cryptanalysts did very
interesting theoretical work in attacking SHA-1.
Cryptographers are excited too. But mainly because this is an
important theoretical breakthrough. Attacks can only get beter with
time: it is therefore important to monitor any progress in hash
functions cryptanalysis and be prepared for any really practical
break with a sound migration plan for the future.
B.2 HMAC-SHA-1 status
The new attacks on SHA-1 have no impact on the security of HMAC-
SHA-1. The best attack on the latter remains one needing a sender
to authenticate 2^{80} messages before an adversary can create a
forgery. Why?
HMAC is not a hash function. It is a message authentication code
(MAC) that uses a hash function internally. A MAC depends on a
secret key, while hash functions don't. What one needs to worry
about with a MAC is forgery, not collisions. HMAC was designed so
that collisions in the hash function (here SHA-1) do not yield
forgeries for HMAC.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Recall that HMAC-SHA-1(K,x) = SHA-1(K_o,SHA-1(K_i,x)) where the
keys K_o,K_i are derived from K. Suppose the attacker finds a pair
x,y such that SHA-1(K_i,x)=SHA-1(K_i,y). (Call this a hidden-key
collision.) Then if it can obtain the MAC of x (itself a tall
order), it can forge the MAC of y. (These values are the same.) But
finding hidden-key collisions is harder than finding collisions,
because the attacker does not know the hidden key K_i. All it may
have is some outputs of HMAC-SHA-1 with key K. To date there are no
claims or evidence that the recent attacks on SHA-1 extend to find
hidden-key collisions.
Historically, the HMAC design has already proven itself in this
regard. MD5 is considered broken in that collisions in this hash
function can be found relatively easily. But there is still no
attack on HMAC-MD5 better than the trivial 2^{64} time birthday
one. (MD5 outputs 128 bits, not 160.) We are seeing this strength
of HMAC coming into play again in the SHA-1 context.
B.3 HOTP status
Since no new weakness has surfaced in HMAC-SHA-1, there is no
impact on HOTP. The best attacks on HOTP remain those described in
the document, namely to try to guess output values.
The security proof of HOTP requires that HMAC-SHA-1 behave like a
pseudorandom function. The quality of HMAC-SHA-1 as a pseudorandom
function is not impacted by the new attacks on SHA-1, and so
neither is this proven guarantee.
Appendix C - HOTP Algorithm: Reference Implementation
/* /*
* OneTimePasswordAlgorithm.java * OneTimePasswordAlgorithm.java
* OATH Initiative, * OATH Initiative,
* HOTP one-time password algorithm * HOTP one-time password algorithm
* *
*/ */
/* Copyright (C) 2004, OATH. All rights reserved. /* Copyright (C) 2004, OATH. All rights reserved.
* *
* License to copy and use this software is granted provided that it * License to copy and use this software is granted provided that it
* is identified as the "OATH HOTP Algorithm" in all material * is identified as the "OATH HOTP Algorithm" in all material
* mentioning or referencing this software or this function. * mentioning or referencing this software or this function.
* *
* License is also granted to make and use derivative works provided * License is also granted to make and use derivative works provided
* that such works are identified as * that such works are identified as
* "derived from OATH HOTP algorithm" * "derived from OATH HOTP algorithm"
* in all material mentioning or referencing the derived work. * in all material mentioning or referencing the derived work.
HOTP: An HMAC-based One Time Password Algorithm October 2004
* *
* OATH (Open AuTHentication) and its members make no * OATH (Open AuTHentication) and its members make no
* representations concerning either the merchantability of this * representations concerning either the merchantability of this
* software or the suitability of this software for any particular * software or the suitability of this software for any particular
* purpose. * purpose.
* *
* It is provided "as is" without express or implied warranty * It is provided "as is" without express or implied warranty
* of any kind and OATH AND ITS MEMBERS EXPRESSELY DISCLAIMS * of any kind and OATH AND ITS MEMBERS EXPRESSELY DISCLAIMS
* ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software. * ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
* *
skipping to change at page 23, line 4 skipping to change at page 28, line 28
* documentation and/or software. * documentation and/or software.
*/ */
package org.openauthentication.otp; package org.openauthentication.otp;
import java.io.IOException; import java.io.IOException;
import java.io.File; import java.io.File;
import java.io.DataInputStream; import java.io.DataInputStream;
import java.io.FileInputStream ; import java.io.FileInputStream ;
import java.lang.reflect.UndeclaredThrowableException; import java.lang.reflect.UndeclaredThrowableException;
HOTP: An HMAC-based One Time Password Algorithm October 2004
import java.security.GeneralSecurityException; import java.security.GeneralSecurityException;
import java.security.NoSuchAlgorithmException; import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException; import java.security.InvalidKeyException;
import javax.crypto.Mac; import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec; import javax.crypto.spec.SecretKeySpec;
/** /**
* This class contains static methods that are used to calculate the * This class contains static methods that are used to calculate the
skipping to change at page 23, line 33 skipping to change at page 29, line 4
// These are used to calculate the check-sum digits. // These are used to calculate the check-sum digits.
// 0 1 2 3 4 5 6 7 8 9 // 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits = private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 }; { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
/** /**
* Calculates the checksum using the credit card algorithm. * Calculates the checksum using the credit card algorithm.
* This algorithm has the advantage that it detects any single * This algorithm has the advantage that it detects any single
* mistyped digit and any single transposition of * mistyped digit and any single transposition of
HOTP: An HMAC-based One Time Password Algorithm October 2004
* adjacent digits. * adjacent digits.
* *
* @param num the number to calculate the checksum for * @param num the number to calculate the checksum for
* @param digits number of significant places in the number * @param digits number of significant places in the number
* *
* @return the checksum of num * @return the checksum of num
*/ */
public static int calcChecksum(long num, int digits) { public static int calcChecksum(long num, int digits) {
boolean doubleDigit = true; boolean doubleDigit = true;
int total = 0; int total = 0;
skipping to change at page 24, line 4 skipping to change at page 29, line 28
num /= 10; num /= 10;
if (doubleDigit) { if (doubleDigit) {
digit = doubleDigits[digit]; digit = doubleDigits[digit];
} }
total += digit; total += digit;
doubleDigit = !doubleDigit; doubleDigit = !doubleDigit;
} }
int result = total % 10; int result = total % 10;
if (result > 0) { if (result > 0) {
result = 10 - result; result = 10 - result;
HOTP: An HMAC-based One Time Password Algorithm October 2004
} }
return result; return result;
} }
/** /**
* This method uses the JCE to provide the HMAC-SHA1 * This method uses the JCE to provide the HMAC-SHA1
* algorithm. * algorithm.
* HMAC computes a Hashed Message Authentication Code and * HMAC computes a Hashed Message Authentication Code and
* in this case SHA1 is the hash algorithm used. * in this case SHA1 is the hash algorithm used.
* *
skipping to change at page 24, line 33 skipping to change at page 30, line 4
* The secret provided was not a valid HMAC-SHA1 key. * The secret provided was not a valid HMAC-SHA1 key.
* *
*/ */
public static byte[] hmac_sha1(byte[] keyBytes, byte[] text) public static byte[] hmac_sha1(byte[] keyBytes, byte[] text)
throws NoSuchAlgorithmException, InvalidKeyException throws NoSuchAlgorithmException, InvalidKeyException
{ {
// try { // try {
Mac hmacSha1; Mac hmacSha1;
try { try {
HOTP: An HMAC-based One Time Password Algorithm October 2004
hmacSha1 = Mac.getInstance("HmacSHA1"); hmacSha1 = Mac.getInstance("HmacSHA1");
} catch (NoSuchAlgorithmException nsae) { } catch (NoSuchAlgorithmException nsae) {
hmacSha1 = Mac.getInstance("HMAC-SHA1"); hmacSha1 = Mac.getInstance("HMAC-SHA1");
} }
SecretKeySpec macKey = SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW"); new SecretKeySpec(keyBytes, "RAW");
hmacSha1.init(macKey); hmacSha1.init(macKey);
return hmacSha1.doFinal(text); return hmacSha1.doFinal(text);
// } catch (GeneralSecurityException gse) { // } catch (GeneralSecurityException gse) {
// throw new UndeclaredThrowableException(gse); // throw new UndeclaredThrowableException(gse);
skipping to change at page 25, line 4 skipping to change at page 30, line 28
private static final int[] DIGITS_POWER private static final int[] DIGITS_POWER
// 0 1 2 3 4 5 6 7 8 // 0 1 2 3 4 5 6 7 8
= {1,10,100,1000,10000,100000,1000000,10000000,100000000}; = {1,10,100,1000,10000,100000,1000000,10000000,100000000};
/** /**
* This method generates an OTP value for the given * This method generates an OTP value for the given
* set of parameters. * set of parameters.
* *
* @param secret the shared secret * @param secret the shared secret
HOTP: An HMAC-based One Time Password Algorithm October 2004
* @param movingFactor the counter, time, or other value that * @param movingFactor the counter, time, or other value that
* changes on a per use basis. * changes on a per use basis.
* @param codeDigits the number of digits in the OTP, not * @param codeDigits the number of digits in the OTP, not
* including the checksum, if any. * including the checksum, if any.
* @param addChecksum a flag that indicates if a checksum digit * @param addChecksum a flag that indicates if a checksum digit
* should be appended to the OTP. * should be appended to the OTP.
* @param truncationOffset the offset into the MAC result to * @param truncationOffset the offset into the MAC result to
* begin truncation. If this value is out of * begin truncation. If this value is out of
* the range of 0 ... 15, then dynamic * the range of 0 ... 15, then dynamic
* truncation will be used. * truncation will be used.
skipping to change at page 25, line 32 skipping to change at page 30, line 54
* @throws InvalidKeyException * @throws InvalidKeyException
* The secret provided was not * The secret provided was not
* a valid HMAC-SHA1 key. * a valid HMAC-SHA1 key.
* *
* @return A numeric String in base 10 that includes * @return A numeric String in base 10 that includes
* {@link codeDigits} digits plus the optional checksum * {@link codeDigits} digits plus the optional checksum
* digit if requested. * digit if requested.
*/ */
static public String generateOTP(byte[] secret, static public String generateOTP(byte[] secret,
long movingFactor, long movingFactor,
int codeDigits, int codeDigits,
HOTP: An HMAC-based One Time Password Algorithm October 2004
boolean addChecksum, boolean addChecksum,
int truncationOffset) int truncationOffset)
throws NoSuchAlgorithmException, InvalidKeyException throws NoSuchAlgorithmException, InvalidKeyException
{ {
// put movingFactor value into text byte array // put movingFactor value into text byte array
String result = null; String result = null;
int digits = addChecksum ? (codeDigits + 1) : codeDigits; int digits = addChecksum ? (codeDigits + 1) : codeDigits;
byte[] text = new byte[8]; byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) { for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff); text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8; movingFactor >>= 8;
} }
// compute hmac hash // compute hmac hash
byte[] hash = hmac_sha1(secret, text); byte[] hash = hmac_sha1(secret, text);
// put selected bytes into result int // put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf; int offset = hash[hash.length - 1] & 0xf;
if ( (0<=truncationOffset) && if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) { (truncationOffset<(hash.length-4)) ) {
offset = truncationOffset; offset = truncationOffset;
} }
HOTP: An HMAC-based One Time Password Algorithm October 2004
int binary = int binary =
((hash[offset] & 0x7f) << 24) ((hash[offset] & 0x7f) << 24)
| ((hash[offset + 1] & 0xff) << 16) | ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8) | ((hash[offset + 2] & 0xff) << 8)
| (hash[offset + 3] & 0xff); | (hash[offset + 3] & 0xff);
int otp = binary % DIGITS_POWER[codeDigits]; int otp = binary % DIGITS_POWER[codeDigits];
if (addChecksum) { if (addChecksum) {
otp = (otp * 10) + calcChecksum(otp, codeDigits); otp = (otp * 10) + calcChecksum(otp, codeDigits);
} }
result = Integer.toString(otp); result = Integer.toString(otp);
while (result.length() < digits) { while (result.length() < digits) {
result = "0" + result; result = "0" + result;
} }
return result; return result;
} }
} }
Appendix C - HOTP Algorithm: Test Values Appendix D - HOTP Algorithm: Test Values
The following test data uses the ASCII string The following test data uses the ASCII string
"123456787901234567890" for the secret: "123456787901234567890" for the secret:
Secret = 0x3132333435363738393031323334353637383930 Secret = 0x3132333435363738393031323334353637383930
Table 1 details for each count, the intermediate hmac value. Table 1 details for each count, the intermediate hmac value.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Count Hexadecimal HMAC-SHA1(secret, count) Count Hexadecimal HMAC-SHA1(secret, count)
0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0 0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0
1 75a48a19d4cbe100644e8ac1397eea747a2d33ab 1 75a48a19d4cbe100644e8ac1397eea747a2d33ab
2 0bacb7fa082fef30782211938bc1c5e70416ff44 2 0bacb7fa082fef30782211938bc1c5e70416ff44
3 66c28227d03a2d5529262ff016a1e6ef76557ece 3 66c28227d03a2d5529262ff016a1e6ef76557ece
4 a904c900a64b35909874b33e61c5938a8e15ed1c 4 a904c900a64b35909874b33e61c5938a8e15ed1c
5 a37e783d7b7233c083d4f62926c7a25f238d0316 5 a37e783d7b7233c083d4f62926c7a25f238d0316
6 bc9cd28561042c83f219324d3c607256c03272ae 6 bc9cd28561042c83f219324d3c607256c03272ae
7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa 7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa
8 1b3c89f65e6c9e883012052823443f048b4332db 8 1b3c89f65e6c9e883012052823443f048b4332db
skipping to change at page 27, line 4 skipping to change at page 32, line 29
Table details for each count the truncated values (both in Table details for each count the truncated values (both in
hexadecimal and decimal) and then the HOTP value. hexadecimal and decimal) and then the HOTP value.
Truncated Truncated
Count Hexadecimal Decimal HOTP Count Hexadecimal Decimal HOTP
0 4c93cf18 1284755224 755224 0 4c93cf18 1284755224 755224
1 41397eea 1094287082 287082 1 41397eea 1094287082 287082
2 82fef30 137359152 359152 2 82fef30 137359152 359152
3 66ef7655 1726969429 969429 3 66ef7655 1726969429 969429
4 61c5938a 1640338314 338314 4 61c5938a 1640338314 338314
HOTP: An HMAC-based One Time Password Algorithm October 2004
5 33c083d4 868254676 254676 5 33c083d4 868254676 254676
6 7256c032 1918287922 287922 6 7256c032 1918287922 287922
7 4e5b397 82162583 162583 7 4e5b397 82162583 162583
8 2823443f 673399871 399871 8 2823443f 673399871 399871
9 2679dc69 645520489 520489 9 2679dc69 645520489 520489
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2004. This document is subject Copyright (C) The Internet Society 2004. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
 End of changes. 77 change blocks. 
117 lines changed or deleted 386 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/