U.S. patent application number 14/136795 was filed with the patent office on 2014-04-24 for token authentication system and method.
The applicant listed for this patent is SYMANTEC CORPORATION. Invention is credited to Nicolas Popp.
Application Number | 20140115677 14/136795 |
Document ID | / |
Family ID | 34910755 |
Filed Date | 2014-04-24 |
United States Patent
Application |
20140115677 |
Kind Code |
A1 |
Popp; Nicolas |
April 24, 2014 |
TOKEN AUTHENTICATION SYSTEM AND METHOD
Abstract
A method for calculating a One Time Password. A secret is
concatenated with a count, where the secret is uniquely assigned to
a token. The secret can be a private key or a shared secret
symmetric key. The count is a number that increases monotonically
at the token with the number of one-time Passwords generated at the
token. The count is also tracked at an authentication server, where
it increases monotonically with each calculation of a one-time
Password at the authentication server. An OTP can be calculated by
hashing a concatenated secret and count. The result can be
truncated.
Inventors: |
Popp; Nicolas; (Menlo Park,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SYMANTEC CORPORATION |
Mountain View |
CA |
US |
|
|
Family ID: |
34910755 |
Appl. No.: |
14/136795 |
Filed: |
December 20, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10590415 |
Oct 20, 2006 |
8639628 |
|
|
PCT/US05/05481 |
Feb 23, 2005 |
|
|
|
14136795 |
|
|
|
|
60546194 |
Feb 23, 2004 |
|
|
|
Current U.S.
Class: |
726/6 |
Current CPC
Class: |
H04L 63/0853 20130101;
H04L 9/0863 20130101; H04L 9/3226 20130101; H04L 9/3242 20130101;
H04L 9/3234 20130101; H04L 63/0838 20130101; H04L 9/3228
20130101 |
Class at
Publication: |
726/6 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. (canceled)
2. A token comprising: a counter to generate a count, wherein the
count is a value that increases with each One Time Password
generated by the token; a storage to store a secret and the count;
and a component, coupled to the storage, to: concatenate the secret
with the count; calculate a hash based upon the concatenated secret
and count; and truncate a result of the hash to obtain a new One
Time Password.
3. The token of claim 2, further comprising: a button, wherein the
new One Time Password is to be generated and the count is to be
incremented in response to a press of the button; and a display to
display the new One Time Password.
4. The token of claim 2, wherein the hash is calculated using an
SHA-1 hash function and the secret is a symmetric cryptographic
key.
5. The token of claim 2, wherein the One Time Password comprises at
most 4 bytes from the hash.
6. The token of claim 2, wherein truncating the result of the hash
comprises: determining an offset value from four bits of a
predetermined byte of the hash; indexing into bytes of the hash
based on the offset value; and returning values for a predetermined
number of bytes of the hash that are identified based on the
indexing.
7. An authentication server comprising: a storage to store a secret
and a count that are associated with a token, wherein the count is
a value that increases with each received valid One Time Password;
and a component, coupled to the storage, to: concatenate the secret
with the count; calculate a hash based upon the concatenated secret
and count; and truncate a result of the hash to compute a One Time
Password.
8. The authentication server of claim 7, wherein the computed One
Time Password is to be generated in response to receipt of a
request comprising a received One Time Password, and wherein the
component is further to: compare the computed One Time Password
with the received One Time Password; and responsive to a
determination that the computed One Time Password matches the
received One Time Password, authenticate the request and increment
the count.
9. The authentication server of claim 8, wherein responsive to a
determination that the computed One Time Password fails to match
the received One Time Password, the component is further to perform
authentication operations comprising: incrementing the count;
computing a new One Time Password based on the incremented count;
comparing the new One Time Password with the received One Time
Password; and if the new One Time Password matches the received One
Time Password, authenticating the request and increment the
count.
10. The authentication server of claim 9, wherein: the component is
further to repeat the authentication operations up to a threshold
number of times if the new One Time Password fails to match the
received One Time Password; and the component is to determine that
the request is not authenticated if no computed One Time Password
matches the received One Time Password.
11. The authentication server of claim 7, wherein the One Time
Password comprises at most 4 bytes from the hash.
12. The authentication server of claim 7, wherein truncating the
result of the hash comprises: determining an offset value from four
bits of a predetermined byte of the hash; indexing into bytes of
the hash based on the offset value; and returning values for a
predetermined number of bytes of the hash that are identified based
on the indexing.
13. A method comprising: receiving, by an authentication server, a
request for authentication, the request comprising a first One Time
Password generated by a token, wherein the first One Time Password
is based upon a value of a first count at the token and a secret
shared between the token and the authentication server;
calculating, by the authentication server, a second One Time
Password based upon the secret and a first value of a second count
at the authentication server; comparing the calculated second One
Time Password with the received first One Time Password; responsive
to a determination that the calculated second One Time Password
corresponds to the received first One Time Password, determining
that the request is authenticated; and responsive to a
determination that the calculated second One Time Password does not
correspond to the received first One Time Password, performing
additional authentication operations by the authentication server,
the additional authentication operations comprising: incrementing
the second count to a next value; recalculating the second One Time
Password based upon the incremented second count and the secret;
and comparing the recalculated second One Time Password with the
received first One Time Password.
14. The method of claim 13, further comprising: responsive to a
determination that the recalculated second One Time Password
corresponds to the received first One Time Password, determining
that the request is authenticated; and responsive to a
determination that the recalculated second One Time Password does
not correspond to the received first One Time Password, repeating
the additional authentication operations by the authentication
server until at least one of a) the count has been incremented a
threshold number of times or b) the recalculated second One Time
Password corresponds to the received first One Time Password.
15. The method of claim 14, further comprising: resetting the count
to the first value after the count is incremented the threshold
number of times if the recalculated second One Time Password does
not correspond to the received first One Time Password.
16. The method of claim 13, wherein the request further comprises a
serial number that is uniquely associated with the token and a
personal identification number associated with a user, the method
further comprising: retrieving the second count and the secret
based on at least one of the serial number or the personal
identification number.
17. The method of claim 13, wherein the hash function is SHA-1 and
the secret is a symmetric cryptographic key.
18. The method of claim 13, wherein calculating the second One Time
Password comprises: concatenating the secret with the second count;
calculating a hash based upon the concatenated secret and the
second count; and truncating a result of the hash to obtain the
second One Time Password.
19. The method of claim 18, wherein the second One Time Password
comprises at most 4 bytes from the hash.
20. The method of claim 18, wherein truncating the result of the
hash comprises: determining an offset value from four bits of a
predetermined byte of the hash; indexing into bytes of the hash
based on the offset value; and returning values for a predetermined
number of bytes of the hash that are identified based on the
indexing.
21. An authentication server comprising: a storage to store a
shared secret and a second count that are associated with a token,
wherein the second count is a value that increases with each
received valid One Time Password; and a component, coupled to the
storage, to: receive a request for authentication, the request
comprising a first One Time Password generated by the token,
wherein the first One Time Password is based upon a value of a
first count at the token and the shared secret; calculate a second
One Time Password based upon the shared secret and a first value of
the second count; compare the calculated second One Time Password
with the received first One Time Password; responsive to a
determination that the calculated second One Time Password
corresponds to the received first One Time Password, determine that
the request is authenticated; and responsive to a determination
that the calculated second One Time Password does not correspond to
the received first One Time Password, perform additional
authentication operations by the authentication server, the
additional authentication operations comprising: incrementing the
second count to a next value; recalculating the second One Time
Password based upon the incremented second count and the secret;
and comparing the recalculated second One Time Password with the
received first One Time Password.
22. The authentication server of claim 21, wherein the component is
further to: responsive to a determination that the recalculated
second One Time Password corresponds to the received first One Time
Password, determine that the request is authenticated; and
responsive to a determination that the recalculated second One Time
Password does not correspond to the received first One Time
Password, repeat the additional authentication operations until at
least one of a) the count has been incremented a threshold number
of times or b) the recalculated second One Time Password
corresponds to the received first One Time Password.
23. The authentication server of claim 21, wherein the component is
further to: reset the count to the first value after the count is
incremented the threshold number of times if the recalculated
second One Time Password does not correspond to the received first
One Time Password.
Description
RELATED APPLICATIONS
[0001] This patent application is a Continuation of U.S. patent
application Ser. No. 10/590,415, filed Oct. 20, 2006, which is a
nation stage entry application claiming priority under 35 U.S.C.
.sctn.371 to Patent Cooperation Treaty Application No.
PCT/US05/05481, filed Feb. 23, 2005, which claims priority to U.S.
Provisional Application No. 60/546,194, filed Feb. 23, 2004, each
of which are herein incorporated by reference.
TECHNICAL FIELD
[0002] The field of the invention is authentication, and in
particular authentication using a hardware device.
SUMMARY
[0003] A method for calculating a One Time Password. A secret is
concatenated with a count, where the secret is uniquely assigned to
a token. The secret can be a private key or a shared secret
symmetric key. The count is a number that increases monotonically
at the token with the number of One Time Passwords generated at the
token. The count is also tracked at an authentication server, where
it increases monotonically with each calculation of a One Time
Password at the authentication server. An OTP can be calculated by
hashing a concatenated secret and count. The result can be
truncated.
BACKGROUND
[0004] A common step in deciding whether to grant a request for
access to data or services in a network is to identify and
authenticate the requesting user. Authentication includes the
process of verifying the identity of a user. A known identification
and authentication system includes associating a user identifier
("user id") and a secret ("password") for a user. The password can
be a secret shared between the user and an authentication service.
The user can submit his user id and password to the authentication
service, which compares them with a user id and associated password
that can be stored at the service. If they match, then the user is
said to have been authenticated. If not, the user is said not to be
authenticated.
[0005] A token is a device that can be used to authenticate a user.
It can include one or more secrets, some of which can be shared
with a validation center. For example, a token can store a secret
key that can be used as the basis for calculating a One Time
Password (OTP). A OTP can be a number (or alphanumeric string) that
is generated once and then is not reused. The token can generate an
OTP and send it along with a unique token serial number to an
authentication server. The authentication server can calculate an
OTP using its copy of the secret key for the token with the
received serial number. If the OTPs match, then the user can be
said to be authenticated. To further strengthen the link from the
user to the token, the user can establish a secret Personal
Identification Number (PIN) shared with the token that must be
entered by the user to unlock the token. Alternatively, the PIN can
be shared between the user, the token and the authentication
server, and can be used with other factors to generate the OTP. A
token typically implements tamper-resistant measures to protect the
secrets from unauthorized disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 shows an authentication procedure in accordance with
an embodiment of the present invention.
[0007] FIG. 2 shows an authentication procedure in accordance with
another embodiment of the present invention.
DETAILED DESCRIPTION
[0008] An embodiment of the present invention includes a protocol
for generating One Time Passwords ("OTPs") at a hardware device
that can be used to authenticate a user. The OTPs are generated by
a token, which can be a physical device that includes mechanisms to
prevent the unauthorized modification or disclosure of the software
and information that it contains, and to help ensure its proper
functioning.
[0009] An embodiment of this protocol can be sequence based, and
can be two-factor, e.g., based upon something the user knows (such
as a Personal Identification Number, a secret shared between the
user and the authentication service) and a physical device having
special properties (e.g., a unique secret key such as a private
key, or a shared secret symmetric key) that the user possesses
(e.g., a token.).
[0010] The protocol for generating the OTPs can be based upon a
counter, e.g., a monotonically increasing number based, for
example, on the number of times a OTP has been requested from the
token. The value of the OTP can be displayed on a token, and can be
easily read and entered by the user, e.g., via a keyboard coupled
to a computer that is in turn coupled to a network. The OTP can be
transportable over the RADIUS system.
[0011] An embodiment of the protocol in accordance with the present
invention can based on an increasing counter value and a static
symmetric key known only to the token and an authentication service
(the "strong auth" service.) An OTP value can be created using the
HMAC-SHA1 algorithm as defined in RFC 2104, or any other suitable
hash algorithm. This hashed MAC algorithm has the strength of
SHA-1, but allows the addition of a secret during the calculation
of the output.
[0012] The output of the HMAC-SHA1 calculation is 160 bits.
However, this value can be truncated to a length that can be easily
entered by a user. Thus,
OTP=Truncate(HMAC-SHA1 (Count, Secret))
Both the client and authentication server can calculate the OTP
value. If the value received by the server matches the value
calculated by the server, then the user can be said to be
authenticated. Once an authentication occurs at the server, the
server increments the counter value by one.
[0013] Although the servers counter value can be incremented after
a successful OTP authentication, the counter on the token can be
incremented every time the button is pushed. Because of this, the
counter values on the server and on the token can often be out of
synchronization. Indeed, there is a good chance that the token will
always be out of synchronization with the server given the user
environment (e.g., the user pushes the button unnecessarily, button
is pushed accidentally, user mistypes the OTP, etc.)
[0014] Because the server's counter will only increment when a
valid OTP is presented, the server's counter value on the token is
expected to always be less than the counter value on token. It is
important to ensure that resynchronization is to ensure it's not a
burden to either the user or the enterprise IT department.
[0015] Synchronization of counters is in this scenario can be
achieved by having the server calculate the next n OTP values and
determine if there is a match, where n is an integer. If we assume
that the difference between the count at the token and the count at
the server is 50, then depending on the implementation of the
strong auth server, the server would at most have to calculate the
next 50 OTP values. Thus, for example, if the correct OTP is found
at the n+12 value, then the server can authenticate the user and
then increment the counter by 12.
[0016] It is important to carefully choose a value for n that can
be easily calculated by the server. There should be upper bounds to
ensure the server doesn't check OTP values forever, thereby
succumbing to a Denial of Service attack.
[0017] Truncating the HMAC-SHA1 value to a 6 character value could
make a brute force attack easy to mount, especially if only numeric
digits are used. Because of this, such attacks can be detected and
stopped at the strong auth server. Each time the server calculates
an OTP that does not validate, it should record this and implement
measures to prevent being swamped, e.g., at some point, turn away
future requests for validation from the same source. Alternatively,
the user can be forced to wait for a longer period of time between
validation attempts.
[0018] Once a user is locked out, the user can be to "self-unlock"
by providing a web interface that would require the user, for
example, to enter multiple OTP in a sequence, thus proving they
have the token.
[0019] Once the shared secret has been combined with the counter, a
160 bit (20-byte) HMAC-SHA1 result can be obtained. In one
embodiment, at most four bytes of this information for our OTP. The
HMAC RFC (RFC 2104--HMAC: Keyed-Hashing for Message Authentication)
further warns that we should use at least half the HMAC result in
Section 5, Truncated Output: [0020] Applications of HMAC can choose
to truncate the output of HMAC by outputting the t leftmost bits of
the HMAC computation . . . . We recommend that the output length t
be not less than half the length of the hash output . . . and not
less than 80 bits (a suitable lower bound on the number of bits
that need to be predicted by an attacker).
[0021] Thus, another way is needed to choose only four or fewer
bytes of the HMAC result in a way that will not weaken either HMAC
or SHA1. In one, dynamic offset truncation, described below, can be
used.
Dynamic Offset Truncation.
[0022] The purpose of this technique is to extract a four byte
dynamic binary code from an HMAC-SHA1 result while still keeping
most of the cryptographic strength of the MAC. [0023] 1. Take the
last byte (byte 19) [0024] 2. Mask off the low order four bits as
the offset value [0025] 3. use the offset value to index into the
bytes of the HMAC-SHA1 result. [0026] 4. return the following four
bytes as the dynamic binary code.
[0027] The following code example describes the extraction of a
dynamic binary code given that hmac_result is a byte array with the
HMAC-SHA1 result:
[0028] int offset=hmac_result[19] & 0xf;
[0029] int bin_code=(hmac_result[offset] & 0x7f)<<24
[0030] |(hmac_result[offset+1] & 0xff)<<16
[0031] |(hmac_result[offset+2] & 0xff)<<8
[0032] |(hmac_result[offset+3] & 0xff);
[0033] The following is an example of using this technique:
##STR00001##
[0034] We treat the dynamic binary code as a 31 bit, unsigned,
big-endian integer; the first byte is masked with a 0x7f.
[0035] The One Time Password for a given secret and moving factor
can vary based on three parameters: Encoding Base, Code Digits, and
Has Checksum. With 10 as an Encoding Base, 7 Code Digits and Has
Checksum set to TRUE, we continue with the above example: [0036]
The hex value 0x50ef7f19 converts to 1357872921 base 10. [0037] The
last 7 digits are 7872921 [0038] The credit card checksum of the
code digits calculates 7 as the checksum.
[0038] 10-((5+8+5+2+9+2+2)mod 10)=10-(33 mod 10)=10-3=7 [0039]
Yielding the following OTP: 78729217
[0040] The following is the Glossary of terms used in this
application: [0041] Checksum Digit--Result of applying the
Credit-Card checksum algorithm to the Code Digits. This digit is
optional. This check should catch any single transposition or any
single character mistyped. [0042] Code Digits--This parameter
indicates is the number of digits to be obtained from the binary
code. We calculate the Code Digits by converting the Binary Code to
the Encoding Base, zero padding to be at least Code Digits, and
taking the right hand (low order) digits. With ten as an Encoding
Base, no more than nine Code Digits can be supported by the 31-bit
Binary Code. [0043] Credit Card checksum algorithm--This checksum
algorithm has the advantage that it will catch any single mistyped
digit, or any single adjacent transposition of two digits. These
are the most common types of user errors. [0044] Encoding
Base--This parameter indicates what base to use for the password.
Base 10 is the preferred base because it can be entered in a
numeric pad. [0045] Has Checksum Digit--This boolean parameter
indicates if a checksum digit should be added to create the OTP. If
there is no checksum digit, just the Code Digits are used as the
OTP. If there is a checksum digit, it is calculated using the Code
Digits as input to the Credit-Card checksum algorithm. [0046]
OTP--The One-Time-Password. This value is constructed by appending
the Checksum Digit, if any, to the right of the Code Digits. If
there is no Checksum Digit, the OTP is the same as the Code
Digits.
[0047] The One Time Number value is calculated by first shifting in
the Hash Bits, and then the Synchronization Bits, and then shifting
in the result of the check_function ( ) of the prior intermediate
value.
[0048] The binary value is then translated to appropriate character
values. There are three likely character representations of the
password: Decimal, Hexadecimal, and Alpha-Numeric.
TABLE-US-00001 Decimal Hexadecimal Alpha-Numeric Required Display
Type 7-Segment 7-Segment Alpha-Numeric Conversion Cost Moderate
Trivial Simple Bits per character 3.2 4 5 Keyboard Entry Simple
Easy Easy Cell Phone Entry Easy Difficult Difficult
Decimal.
[0049] The token can convert the dynamic binary code to decimal and
then display then last Code Digits plus optionally the checksum.
For example, for a six digit, no checksum, decimal token will
convert the binary code to decimal and display the last six
digits.
Hexadecimal.
[0050] The token can convert the dynamic binary code to hexadecimal
and then display then last Code Digits plus optionally the
checksum. For example, for a six digit, no checksum, hexadecimal
token will convert the binary code to hexadecimal and display the
last six digits.
Alphanumeric.
[0051] The token can convert the dynamic binary code to base 32 and
then display then last Code Digits plus optionally the checksum.
For example, for a six digit, no checksum, base 32 token will
convert the binary code to base 32 and display the last six
digits.
The PIN.
[0052] In order to be a true two-factor authentication token, there
can also be a "what you know" value in addition to the "what you
have" value of the OTP. This value is usually a static PIN or
password known only to the user. This section discusses three
alternative architectures to validate this static PIN in accordance
with the present invention.
PIN Validation in the Cloud.
[0053] Enabling PIN validation in the cloud can bind a single PIN
to a single token. The PIN should be protected over the wire to
ensure it is not revealed. PIN management (set, change) should be
implemented by the strong auth service.
PIN Validation at the Enterprise.
[0054] Enabling PIN validation in the cloud may mean multiple PIN's
for a single token.
[0055] The PIN need never leave the "security world" of the
enterprise. PIN management can be implemented by the
enterprise.
PIN Validation at the Token.
[0056] This embodiment can be implemented using a keypad on the
token. The PIN is never sent over the wire, and may be used as a
seed to the OTP algorithm. The PIN may be used to simply unlock the
token.
Example Data Flows.
[0057] This section describes two data flow scenarios. The first
scenario assumes that the StrongAuth service does not knows the
username associated with a token. In this scenario it is assumed
that the PIN management operations require the user to enter their
token SN, instead of their user name.
[0058] The second scenario is very similar to the first, except by
the fact that the user name is the key into the StrongAuth service,
instead of the token SN. There are a few issues in this case.
First, the username is known to the service, and second we must
come up with a scheme to ensure a unique mapping from a username to
a token SN.
[0059] FIG. 1 shows an authentication procedure in accordance with
an embodiment of the present invention. It assumes the following:
[0060] Token SN and S distributed to StrongAuth Service; [0061]
Customer account associated with each token; [0062] PIN associated
with a particular token; [0063] StrongAuth service saves only the
SHA-1 hash of the PIN in the DB; [0064] Token SN added as an
attribute to the user account at the Enterprise, the plugin maps
the username to the SN.
[0065] A strong authentication server 110, an enterprise
authentication server 120 and a client 130 are coupled, e.g.,
through a network (not shown.) As shown in FIG. 1, a user at the
client sends a request for access to a protected resource to
enterprise server 120. The server determines if access to the
resource requires authentication. If so, it sends an
"authentication required" message to the client 130. The user can
be prompted for a username and a password. The user can push the
button on his token (not shown) to obtain a OTP. The OTP can be
generated as described above, e.g., by hashing a combination of the
token secret and the present value for the count as it is stored at
the token. The user then enters his username and his Personal
Identification Number (PIN) concatenated to the OTP provided by the
token. This information is sent to the enterprise server 120. The
enterprise server 120 looks up the token serial number based on the
username, and sends the serial number and the PIN+OTP to the
authentication server 110. The authentication server 110 looks up a
record based upon the serial number to obtain local hashed values
of the PIN and the secret and purported count. This can be done
because the token secret can be shared between the token to which
it is uniquely assigned and the authentication server 110. The
authentication server then calculates an OTP based upon the secret
for the token and the current value of the count for that token
stored at the authentication server. If the calculated OTP matches
the received OTP, then the value of the count at the authentication
server 110 is incremented by one. Otherwise, the authentication
server can try again to calculate the OTP by incrementing the count
for the token and hashing it with the secret for the token. This
can be done because, as described above, the count value at the
authentication server 110 may be different than the count value at
the token (not shown.) This procedure can be repeated any number of
times within reason to enable the count value to "catch up" with
the count value at the token. In an embodiment, the number of such
repeated tries to authenticate a token at the authentication server
is terminated after a predetermined number of the same, e.g., 12.
In the event that the token cannot be successfully authenticated by
the authentication server 110, the authentication server sends an
"not authenticated" message to the enterprise server 120. If the
token is successfully authenticated, then the authentication server
sends an "authenticated" message to the enterprise server 120.
Based upon the result obtained from the authentication server 110,
the enterprise server denies or grants, respectively, the requested
permission from the client to access a resource.
[0066] FIG. 2 shows an authentication procedure in accordance with
another embodiment of the present invention. It assumes the
following: [0067] Token SN and S distributed to StrongAuth Service;
[0068] Customer account and username is associated with each,
token; [0069] PIN associated with a particular token; [0070]
StrongAuth service saves only the SHA-1 hash of the PIN in the DB;
[0071] Username is forwarded from enterprise to the Strong Auth
service.
[0072] The authentication procedure of FIG. 2 is the same as for
FIG. 1 until just after the username and PIN+OTP is sent from the
client 130 to the enterprise server 120. Rather than look up the
token serial number based upon the username, the enterprise server
120 forwards the authentication request (including the username and
PIN+OTP) to the authentication server 110. The authentication
server looks up a record based upon the username, can verify the
PIN, and then follow the same procedure as shown in FIG. 1 for the
rest of the process.
* * * * *