Embodiments of the present invention relate to computing systems, and more particularly, to authentication over an insecure channel.
One means of authentication includes the use of password on computer systems. For example, on UNIX-type systems, the password for an account is stored in a hashed form. To make it harder for an attacker who has access to the hashed password to perform a class of brute force attacks and potentially gain knowledge of several passwords at once, the password is augmented with a small random value, also known as “salt” before it is hashed. The salt value and the hashed password are then stored in association with other account properties.
Since the salt value is randomly generated, only someone who already has access to the hashed password can compute what a hashed password value should be. This means that the hashed password has to be passed to the authentication process in clear text form. So, either the password must only be used over a secure connection, or the password can be stolen by an eavesdropper.
Thus, a need exists for a technique for a remote connection to authenticate itself over an insecure channel, without providing the password, without the server having access to the password in clear text, or without every password requiring the same type of encryption.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
Described herein is a method and apparatus for an authentication protocol. In one embodiment, a hashed value is computed from an encrypted password value and a displayed code value from a hardware token at a client. The encrypted password value is based on a username, a context identifier, and a password. The client provides the username and the hashed value to a server. The encrypted password value associated with the username is retrieved at the server. An expected hashed value is computed at the server. The client is validated based on a comparison of the hashed value and the expected hashed value.
The hashed value 206 can be a concatenation and hash construction, or a MAC. At this point, iterating the hash or MAC function does provide additional security, since it makes a brute-force attack more time-consuming. Given that the token's displayed value is only valid for a minute at most, and that the brute force attack would depend on the resources of the server to be accomplished, even a moderate iteration count would make a brute force attack effectively impossible. To authenticate, the client provides the username, and the hashed value 206 calculated to server 204 at 208.
Server 204 looks up the encrypted password from the username at 210, calculate the value it expects that user's token to be displaying at that point it in time, and calculate the combined password—token code hash/MAC from these expected values at 212. If it matches what was provided by client 202, client 202 is then authenticated at 214. Because the code provided by the token changes on a frequent basis, and the protocol could span a code change boundary (either because client 202 is slow, or the data path between client 202 and server 204 is, or a combination of both), server 204 may need to check the expected previous value, too.
In summary, client 202 just sends a single communication to authenticate. It may need to request the security context identifier, but presumably it would only need to do that one time, not each time it attempts to authenticate. There is no timestamp value in this protocol, since the value displayed by the hardware token is time based. This protocol sends no unencrypted data—as long as the hash or MAC functions are secure, the protocol is, too.
Server 304 validates the authentication value at 318 as in the protocol above, and checks that the MAC value is valid for the provided data at 320. Presuming the authentication step is successful, the server generates its own session random value at 322. Client 302 and server random values, the encrypted password, and the current display value from the token are all used to generate the required session keys at 324. For example, they could all be concatenated, and an iterated hash can be used. Alternately, the two random values can be concatenated, the encrypted password and displayed code value can be concatenated, and these two values used as inputs in an iterated MAC. However they are derived, the server provides a message that consists of the server random value, and an acknowledgment that is enciphered using the appropriate session key.
Client 302 takes the server random value 314, uses it to derive the appropriate session keys 310, and checks to make sure it can decipher the acknowledgment. The protocol could include an enciphered MAC as part of the acknowledgment (similar to SSL).
The following describes the communication that takes place after the keys are generated. Currently accepted security practice for enciphered point-to-point communication is to use four session keys—one for bulk encipherment each direction, and one to compute message authentication codes over the data portion of the communication in each direction. In the TLS standard, one of the ways these session keys are derived is from two random client values and a random server value in an iterated HMAC construction.
The TLS specified construction uses a secret (“s”), a seed value (“d”), and a label value (“1”). If HMAC(k, m) is a message authentication code using HMAC/SHA-256, with a key of k over the message m, and string concatenation is symbolized by the vertical bar (‘|’), the following equations define how TLS generates a sequence of pseudo-random bytes:
A(s,0)=d
A(s,n)=HMAC(s,A(s,n−1))
P(s,d)=HMAC(s,A(s,1)|d)|HMAC(s,A(s,2)|d)|HMAC(s,A(s,3)|d) . . .
PRF(s,l,d)=P(s,l|d)
The string generated by the pseudo-random function. PRF(s, 1, d) is then parceled out between the client-to-server MAC key, the server-to-client MAC key, the client-to-server encipherment key, and the server-to-client encipherment key. TLS specifies a “secret” value as either specified by the client or as jointly computed by the client and server, and a “seed” value as specified jointly by the client and server. For key bytes, the label “key expansion” (represented as an ASCII string, without quotes, length bytes, or delimiters) is used.
This construction can be used to generate session keys from the enciphered password, the currently displayed code value, and the client and server random values by calculating s=HMAC(p, t), where “p” is the encrypted password and “t” is the currently displayed code. Then, use PRF(s, “key expansion”, Rc|Rs) where the subscribed R values are the client and server random values. Alternately, the currently displayed code value could be used as the label.
Encrypted password value generator 404 is configured to generate an encrypted password value by first combining the username and a security context identifier to produce a salt value. The security context identifier is any string that can be unambiguously determined by the client and is unique to the authentication domain against which the client is authenticating. For example, vpn logins for “Acme, Inc.” could just use the string “ACMEVPN”. “Combining” the username and this identifier can be accomplished by concatenating them and hashing the result, or the username and password could be used as string and key (in either order) to a message authentication code. This can also be iterated an arbitrary number of times, but iteration provides no real additional security at this stage (since this operation can be done once and stored for each particular username-security ID combination).
This salt value is combined with the password in a similar fashion to produce an encrypted password value. Again, this can be concatenation and hashing, or a message authentication code. Iterating the combination function can also be done, but it provides no real security here, either. This encrypted password value would be stored on the server. It is assumed that the client would compute this every time it is required from the inputs provided by the user (but this assumption is not a requirement, and it doesn't affect the rest of the protocol).
Hash value generator 410 calculates a hashed value from the encrypted password value and the currently displayed code value from the hardware token. This can be a concatenation and hash construction, or a MAC. At this point, iterating the hash or MAC function does provide additional security, since it makes a brute-force attack more time-consuming.
Session keys generator 412 receives a server random value and uses it to derive the appropriate session keys, and checks to make sure it can decipher the acknowledgment. The protocol could include an enciphered MAC as part of the acknowledgment (similar to SSL).
Hardware token interface 406 includes a user input for a user to enter a current token display value from a hardware token.
Storage device 408 is configured to store session keys, hash values, encrypted password values.
Hash value computation module 504 is configured to look up the encrypted password from the username, calculate the value it expects that user's token to be displaying at that point it in time, and calculate the combined password—token code hash/MAC from these expected values.
Client validation module 506 is configured to determine whether the calculated combined password matches what was provided by the client. If there is a match, the client is authenticated.
Server session random value generator 508 is configured to generate a session random value, assuming the authentication step is successful.
Session key generator 510 is configured to use the client and server random values, the encrypted password, and the current display value from the token to generate the required session keys. For example, they could all be concatenated, and an iterated hash can be used. Alternately, the two random values can be concatenated, the encrypted password and displayed code value can be concatenated, and these two values used as inputs in an iterated MAC. However they are derived, the server provides a message that consists of the server random value, and an acknowledgment that is enciphered using the appropriate session key.
Hardware token interface 512 is configured to receive a current token display value associated with the hardware token of the user.
At 710, server receives the session random value, the authentication value, the username, and the MAC.
At 712, server validates the authentication value as in the protocol above, and checks that the MAC value is valid for the provided data at 714.
At 716, presuming the authentication step is successful, the server generates its own session random value. At 718, the client and server random values, the encrypted password, and the current display value from the token are all used to generate the required session keys.
The exemplary computer system 402 and 502 includes a processing device, a main memory (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device, which communicate with each other via a bus.
Processing device represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device is configured to execute the processing logic for performing the operations and steps discussed herein.
The computer system further include a network interface device.
The data storage device may include a machine-accessible storage medium on which is stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. The software may also reside, completely or at least partially, within the main memory and/or within the processing device during execution thereof by the computer system, the main memory and the processing device also constituting machine-accessible storage media. The software may further be transmitted or received over a network via the network interface device.
In the above description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions above are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
Number | Name | Date | Kind |
---|---|---|---|
5491752 | Kaufman et al. | Feb 1996 | A |
5774552 | Grimmer | Jun 1998 | A |
6049612 | Fielder et al. | Apr 2000 | A |
6073234 | Kigo et al. | Jun 2000 | A |
6085320 | Kaliski, Jr. | Jul 2000 | A |
6189096 | Haverty | Feb 2001 | B1 |
6243811 | Patel | Jun 2001 | B1 |
6401206 | Khan et al. | Jun 2002 | B1 |
6792424 | Burns et al. | Sep 2004 | B1 |
6883717 | Kelley et al. | Apr 2005 | B1 |
7031468 | Hoffstein et al. | Apr 2006 | B2 |
7073061 | Asano et al. | Jul 2006 | B2 |
7194765 | Blom | Mar 2007 | B2 |
7231521 | Buddhikot et al. | Jun 2007 | B2 |
7242766 | Lyle | Jul 2007 | B1 |
7363651 | de Jong et al. | Apr 2008 | B2 |
7673142 | Jeffries et al. | Mar 2010 | B2 |
7945776 | Atzmony et al. | May 2011 | B1 |
8156333 | Schneider | Apr 2012 | B2 |
8225093 | Fok et al. | Jul 2012 | B2 |
8352738 | Parno et al. | Jan 2013 | B2 |
8660268 | Schneider | Feb 2014 | B2 |
20020056040 | Simms | May 2002 | A1 |
20020146005 | Gallant et al. | Oct 2002 | A1 |
20030014646 | Buddhikot et al. | Jan 2003 | A1 |
20030093671 | Owlett | May 2003 | A1 |
20030105964 | Brainard et al. | Jun 2003 | A1 |
20030233546 | Blom | Dec 2003 | A1 |
20030236803 | Williams | Dec 2003 | A1 |
20040223619 | Jablon | Nov 2004 | A1 |
20050081036 | Hsu | Apr 2005 | A1 |
20060021036 | Chang et al. | Jan 2006 | A1 |
20060041759 | Kaliski et al. | Feb 2006 | A1 |
20060235700 | Wong et al. | Oct 2006 | A1 |
20070005963 | Eldar et al. | Jan 2007 | A1 |
20070101152 | Mercredi et al. | May 2007 | A1 |
20070169181 | Roskind | Jul 2007 | A1 |
20070226784 | Ueda et al. | Sep 2007 | A1 |
20080034216 | Law | Feb 2008 | A1 |
20080077979 | Jeffries et al. | Mar 2008 | A1 |
20080155112 | Ma et al. | Jun 2008 | A1 |
20080301435 | Simon | Dec 2008 | A1 |
20090193511 | Noe et al. | Jul 2009 | A1 |
20090271462 | Schneider | Oct 2009 | A1 |
20090287929 | Kolesnikov et al. | Nov 2009 | A1 |
20090288143 | Stebila et al. | Nov 2009 | A1 |
20090300364 | Schneider | Dec 2009 | A1 |
20100058060 | Schneider | Mar 2010 | A1 |
20100131756 | Schneider | May 2010 | A1 |
Number | Date | Country |
---|---|---|
WO 2005002131 | Jan 2005 | WO |
Entry |
---|
J. Franka et al., “RFC 2617 HTTP Authentication: Basic and Digest Access Authentication”, IETF (Jun. 1999). |
Oath Reference Architecture Release 2.0, Initiative for Open Authentication (2007). |
Office Action for U.S. Appl. No. 12/111,893 mailed Apr. 14, 2011. |
Office Action for U.S. Appl. No. 12/111,893 mailed Oct. 11, 2011. |
Office Action for U.S. Appl. No. 12/156,278, mailed Sep. 26, 2011. |
Notice of Allowance for U.S. Appl. No. 12/156,278, mailed Nov. 23, 2011. |
Office Action for U.S. Appl. No. 12/201,321 mailed Apr. 27, 2011. |
Office Action for U.S. Appl. No. 12/201,321 mailed Oct. 13, 2011. |
Office Action for U.S. Appl. No. 12/324,108, mailed Nov. 16, 2011. |
Biryukov, Alex, et al.; Cryptanalysis of the Alleged SecurID Hash Function (extended version) Lecture Notes in Computer Science, Springer-Verlag, 2003, 18 pages. |
Belare, Mihir, et al., “Keying Hash Functions for Message Authentication”, ,http://cseweb.uscd.edu/˜mihir/papers/kmd5.pdf . . . Published Jun. 1996. |
USPTO, Office Action for U.S. Appl. No. 12/111,893 mailed Oct. 31, 2012. |
USPTO, Office Action for U.S. Appl. No. 12/324,108, mailed Feb. 29, 2012. |
Xiang, Fei et al. “A New Pseudo-Random Number Generator with Application in RSA”, IEEE 2008. |
USPTO, Office Action for U.S. Appl. No. 12/111,893 mailed Apr. 18, 2013. |
USPTO, Notice of Allowance for U.S. Appl. No. 12/111,893 mailed Oct. 3, 2013. |
USPTO, Office Action for U.S. Appl. No. 12/201,321 mailed Aug. 14, 2013. |
Office Action for U.S. Appl. No. 12/201,321 mailed Apr. 8, 2014. |
Number | Date | Country | |
---|---|---|---|
20110131415 A1 | Jun 2011 | US |