System and method for authentication sheet distribution

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a computer-based security system, particularly the distribution of authentication seeds.

【0002】

[Conventional technology]

Security systems use verifiers to authenticate (ie, verify authenticity) other entities such as people or computers. When an entity is authenticated, that is, when the verifier determines that the entity is genuine, the entity has access, eg, physical access to a physical location in a physical security system, or in a data security system. Electronic access to information (eg, financial records, computer data, network access, etc.) is permitted.

【0003】

There are many possible verifyer configurations. Verifyers can receive input from keypads, keyboards, card readers, cameras, microphones, telephones, and computer networks, as well as other such data entry devices. As its output, the verifyer provides access by activating physical mechanisms, sending electronic data signals, configuring software, and performing other similar operations. The verifyer can be implemented in various ways, for example, it may be a dedicated electronic and / or mechanical system, or it may be a general purpose computer electrically connected to dedicated hardware (not necessarily dedicated hardware and electrical). It does not have to be connected to).

【0004】

Some verifyers use shared secret knowledge to authenticate entities. For example, knowledge of personal identification numbers, passwords, or passphrases can be used to validate an entity. Upon authentication, the entity reveals this secret or proves knowledge of this secret (that is, the fact that it knows this secret). If an entity shows this secret knowledge, it is authenticated.

【0005】

On some systems, an entity uses a physical or digital device (such a device is called a "token") that contains a secret within it. This secret is somehow stored in the device, and the entity that uses the device may or may not know this secret. A common door key is one of the simple mechanical examples of such a device. In this case, the shape of the key is a shared secret. When the key is inserted into the lock, the lock verifies that the key is in the correct shape. When the door key shows this "secret" knowledge to the verifier (lock), it is allowed to enter. Once the attacker knows the exact shape of the key, the intruder can create an appropriate token to authenticate himself to the lock.

【0006】

A credit card is a device that can record a secret identification number revealed when accessed by an automated teller machine (ATM). Some credit cards have adopted cryptography to make counterfeiting more difficult. Also, to provide an additional security barrier, automated teller machines have a device (credit card) that contains confidential information for the user, and another secret shared by the bank verifier and the account holder. You are required to enter a personal identification number (PIN).

【0007】

Some devices provide an authentication code different from this secret code, which is based on the secret code recorded on the device, in order to prove the secret knowledge recorded on the device. The use of such an authentication code allows the device to show knowledge of this secret without revealing the secret itself. On some systems, the authorization code is based on time-dependent information. The security advantage of using this type of device is that the secret itself is not revealed, making it more difficult to identify the secret by eavesdropping on the communication channel between the entity and the verifier.

【0008】

One example of this type of device used by a person (user) attempting to authenticate against a verifier is a token that contains an authentication code display. The user reads the verification code on the display and sends this verification code to the verifier. In such a system, the user may never know the secret of sharing. Some such tokens take user input, such as a PIN, and respond to this user input and other information (such as time-dependent information) with some result.

【0009】

This type of token stores a secret code called a "seed". The token mathematically combines this secret code (seed) with a time-varying value and a personal identification code provided by the user to generate an authentication code. This mathematical combination is done so that the secret code stored in the token cannot be identified from the result of its occurrence. That is, the secret code is cryptographically combined with the current time and other information. For example, in another system called a challenge-response system, where a verifier sends a challenge to a user and the user responds to this challenge, the secret code is cryptographically bound to the challenge, thereby Output is generated to be sent to the verifier in response to this challenge.

【0010】

[Problems to be Solved by the Invention]

In order to validate an entity using a shared secret, the verifier must have knowledge of this shared secret. In a security system that validates a large number of entities, there is a trade-off between security and verifier availability. The higher the number of verifiers, the more likely it is that there will be verifiers available when a particular entity requests authentication. However, as the number of verifiers with certain secret knowledge increases, it becomes more difficult to maintain the "secret" of this secret. For example, as the number of verifiers increases, so does the likelihood that one of the verifiers will be compromised in some way. On the other hand, if the number of verifiers is limited, there may not be any verifiers available to authenticate an entity when it requests authentication.

【0011】

Moreover, it is currently not possible to access multiple independent services using a single device. For example, the same device cannot be used to access a company's computer system and a financial institution's home page. Even if each independent service trusts its user and its device, each service does not trust each other. In the above example, trusting a user does not mean that the bank trusts the user's place of employment. If each service shares the same secret with its device, then those services will have information that can invade each other. For these reasons, a device cannot be used for multiple verifiers associated with multiple independent services.

【0012】

The usefulness of a security system is limited by the number and type of verifiers that an entity can easily authenticate. When an entity interacts with multiple devices that share different secrets with that entity, the entity may be a plurality of secrets (or multiple devices that record multiple secrets, each used to authenticate against one or a few verifiers. ) Must be managed. Managing a large number of secrets complicates computer-based entities and is inconvenient for human entities. The process of securely sharing different secrets between an entity and each of a number of verifiers can also be inconvenient and cumbersome.

【0013】

Similar problems occur in the area of security communications, which uses a single shared secret as an encryption key. In order for an entity to communicate securely with many other entities, the entity shares a different secret than each of the other entities, or even if the shared secret is less confidential (and more secure). Must share the same secret as the entity in.

【0014】

Public-key cryptography eliminates the need to securely share secrets between two parties attempting to communicate or authenticate. However, public key cryptography is impractical in many "user-to-device authentication". Reasons for this include, at least, the large amount of computing power required to perform multiple computations and the complexity of managing certificates and revocation lists.

【0015】

[Means for solving problems]

The systems and methods according to the invention allow an entity to authenticate to many verifiers without managing a large number of secrets. Although the authentication system of the present invention is a simple system, the user only needs to manage one secret, and yet the user can authenticate to a plurality of verifiers, which is compared with the conventional technology. Has been greatly improved. For example, using token-based systems and methods, various systems (eg, but not limited to, internal and external file servers of one or more companies, remote access servers, various services (eg finance, etc.) Authenticate some or all of web servers, other computers, home or office physical security systems, and bank cash depositors) associated with business, utilities, entertainment, etc.) It is possible. Such authentication methods and systems can avoid the complexity and cost of managing different secrets or devices for different services.

【0016】

The advantage of associating a user with one secret that is valid for multiple verifyers is that it has much more memory and processing power limitations than a smart card® or small token with limited memory and processing power. It is also useful for devices such as electronic wallets that are not stored in personal computers. This simplicity allows the system to be smaller and faster, while avoiding the complexity of sharing each secret.

【0017】

In certain embodiments of the user authentication methods and systems according to the invention, the device shares a secret called a master seed with the server. Both the device and the server use a key derivation function to derive one or more secrets from this master seed, called verifier seeds. The server shares one verifyer seed with one or more verifyers. The device or the entity that uses the device can authenticate to one of multiple verifiers using this appropriate verifyer seed. This method allows the device and the verifyer to share a secret (ie, the verifyer seed) without the verifyer having access to the master seed or other verifyer seeds. Therefore, the device only needs to store one master seed, have access to the information necessary to correctly derive the appropriate verifyer seed, and have the ability to derive the seed. Individual verifiers do not have access to the master seed and cannot invade the master seed. Moreover, if a particular verifier is compromised, only that verifier seed is affected, not other verifiers that use other verifier seeds.

【0018】

In certain aspects of the invention, a method of distributing credentials associated with a device uses the steps of generating a master seed associated with the device, the master seed, and the information associated with the verifier. It includes a step of deriving a verifyer seed and a step of transmitting the verifyer seed to the verifyer. In another embodiment, the method further comprises the step of transmitting the master seed to the device after the generation step. In another embodiment, the method further includes the step of sharing the master seed between the device and the server after the generation step. In another embodiment, the method comprises, after the generation step, a step of deriving a second verifyer seed using the information associated with the master seed and the second verifyer, and the second verification. Includes the step of transmitting the yased to the second verifyer. In another embodiment, the method further comprises the step of generating an authentication code in response to the verifyer seed after the transmission step.

【0019】

In certain embodiments, the authentication code generation step includes a step of generating an authentication code in response to the verifyer seed and a time-dependent value. In another embodiment, the method further comprises the step of performing authentication using the authentication code. In another embodiment, the authentication step includes the step of authenticating a user or device by verifying the authentication code. In another embodiment, the authentication step includes transmitting the authentication code to the verifyer. In another embodiment, the master seed generation step includes at least one of a step of randomly generating the master seed and a step of generating the master seed in a pseudo-random number.

【0020】

In certain embodiments, the derivation step includes deriving the verifyer seed in response to a time identifier. In another embodiment, the derivation step includes deriving a verifier seed using the master seed and information associated with the verifier as input to a key derivation function. In another embodiment, the key derivation function is a hash function.

【0021】

In another aspect of the invention, a system that distributes authentication information associated with a device comprises a seed generator that generates a master seed associated with the device, the master seed, and information associated with a verifier. A server for deriving the verification seed using the above, and a transmitter for transmitting the verification seed to the verification. In certain embodiments, the system further comprises a transmitter that transmits the master seed to the device. In another embodiment, the system further comprises a communication channel for sharing the master seed between the device and the server. In another embodiment, the server derives a second verifier seed using the master seed and the information associated with the second verifier, and the transmitter is the second verifier. The seed is sent to the second verifyer. In another embodiment, the system comprises an authentication code generator that generates an authentication code in response to the verifyer seed. In another embodiment, the system further comprises the verification seed and an authentication code generator that generates an authentication code in response to a time-dependent value. In another embodiment, the seed generator comprises at least one of a random number generator and a pseudo-random number generator. In another embodiment, the server comprises a key derivation function.

【0022】

In another aspect of the invention, the authentication method comprises storing the master seed associated with the device and deriving the verifyer seed using the master seed and the information associated with the verifier. Includes a step of generating an authentication code in response to the verifyer seed. In another embodiment, the method comprises the step of authenticating a user with the authentication code. In another embodiment, the method comprises transmitting the authorization code to a verifier. In another embodiment, the method comprises the step of receiving the authorization code by a verifier.

【0023】

In another aspect of the invention, the authentication system comprises a memory that stores the master seed associated with the device, a server that derives the verifyer seed using the master seed and the information associated with the verifyer. It includes an authentication code generator that generates an authentication code in response to the verifyer seed.

【0024】

In another aspect of the invention, the authentication verifyer is a data storage unit that stores a verifyer seed associated with the device, an input for receiving an input authentication code, and the input authentication code is the verification. It is provided with an authenticator that determines whether or not the data has been generated correctly in response to the yased.

【0025】

In another aspect of the invention, the token comprises a data storage unit that stores the master seed, a key derivation function that derives the verifier seed from the master seed in response to information associated with the verifier, and the verifier seed. It includes an authentication code generator that generates an authentication code in response to the above, and an output for giving the authentication code to the verifier.

【0026】

In another aspect of the invention, the authentication method derives a verifier seed from the master seed using a step of generating a master seed, a step of sharing the master seed between a token and a server, and a key derivation function. It includes a step and a step of transmitting an authentication code in response to the verifyer seed.

【0027】

BEST MODE FOR CARRYING OUT THE INVENTION

Overall, the same reference numerals refer to the same parts throughout each drawing. Also, the drawings are not necessarily on scale and, as a whole, focus on exemplifying the principles of the invention.

【0028】

With reference to FIG. 1, in one embodiment, the master seed S for device 102_MRaise 100. Master Seed S_M100 is a secret shared by device 102 and server 104. In one embodiment, the server 104 may be a dedicated seed distribution server, and in other embodiments, the server 104 may be a file server, web server, or authentication server with a built-in seed distribution function. .. In certain embodiments, Master Seed S_MThe 100 is randomly generated, for example, by using a sensor that monitors a sufficiently random physical phenomenon. In another embodiment, Master Seed S_M100 is generated by a pseudo-random number generator. In another embodiment, Master Seed S_MThe 100 is generated by other methods of generating secret numbers that are statistically unpredictable.

【0029】

In various embodiments, Master Seed S_M100 may be generated by device 102, server 104, or other seeding entity. Master Seed S_MThe 100 is preferably shared privately (eg, using a secure communication link) between the device 102 and the server 104. In some embodiments, device 102 is the master seed S._MGenerate 100 and share it with server 104. In other embodiments, the server 104 is the master seed S._MRaise 100 and share it with device 102. In yet other embodiments, another entity, such as a seed generator (not shown in FIG. 1), is the master seed S._MGenerates 100, communicates with either device 102 or server 104, and shares this between them. In yet another embodiment, the seed generator directs the master seed S to both device 102 and server 104._MCommunicate 100.

【0030】

Server 104 is the verifier seed S associated with verifier 108._VOccurs. Server 104 uses the key derivation function "KDF" to verify seed S_VOccurs. Key derivation functions are well known in the field of encryption for user-provided passwords. User-provided passwords are generally not directly useful as encryption keys in traditional cryptosystems. Systems that use passwords as the basis for encryption generally use key derivation functions to derive the encryption key from the password. The key derivation function is chosen because it can generate multiple outputs that are relatively different for different inputs, and it is difficult to back-calculate the inputs from those outputs (ie, a particular output). Is given, it is difficult to identify the input on which it is based). Many key derivation functions use hash functions, pseudo-random number functions, and the like.

【0031】

Key derivation functions are typically done by combining passwords with other information called "salts". "Salt" does not have to be a secret value. Iterated functions may also be included in the key derivation function. A number called an "iteration count" can be used to indicate how many times an underlying function is performed to derive a key. The use of iterative counts in the key derivation function increases the effort required to derive the encryption key from the password. A moderate number of iterations (eg 1000) is not a burden for a legitimate party to calculate the key, but it is a heavy burden for an intruder. If the password value is a large random number, a small iteration count may be used.

【0032】

In certain embodiments, the present invention is practiced using a key derivation function called "PBKDF2". In PBKDF2, the message authentication code HMAC-SHA-1 (message authentication code using the SHA-1 hash function) is used. HMAC-SHA-1 takes two arguments as input. The first argument is the encryption key and the second argument is the text encrypted by the encryption key. HMAC-SHA-1 has a variable encryption key length and produces an output value of 20 octets (160 bits). PBKDF2 gives HMAC-SHA-1 two inputs when using the basic function HMAC-SHA-1, and HMAC-SHA-1 responds with a 160-bit output.

【0033】

The key derivation function PBKDF2 has a password (P), a salt (S), an iteration count (c), and a length (Len) in octet (8-bit bytes) as inputs. PBKDF2 calculates the derived output independently for each block by applying the basic function (HMAC-SHA-1) c times. The block is the number of bits generated as output by the basic function (160 bits for HMAC-SHA-1). The first time, the password (P) is the first argument of the basic function, and the salt (s) concatenated with the number of blocks is the second argument of the basic function. The basic function uses this password as an encryption key to encrypt the salt concatenated with the number of blocks. From the second time onward, the result of the previous operation is passed as the second argument of the basic function while using this password again as the encryption key. The results obtained each time are combined using the exclusive OR operation, whereby the final operation result is obtained.

【0034】

In proper notation, the above PBKDF2 key derivation function is expressed by the following equation.

【0035】

[Number 1]

<img file="JP2000357156A_D0001.tif" />【0036】

However, [0037]

[Number 2]

<img file="JP2000357156A_D0002.tif" />【0038】

Is.

【0039】

In the formula, "INT (i)" is the number of blocks i encoded by 4 octets with the highest octet as the first, and "PRF" is the basic function. In the above embodiment, the PRF is HMAC-SHA-1. It is clear that other key derivation functions can be used as well, and that the verifier information and other information may be replaced with various other information, depending on the key derivation function used. Key derivation functions based on basic hash functions, block ciphers, message authentication codes, etc. are intended to be within the scope of the present invention.

【0040】

In one embodiment, the key derivation function PBKDF2 derives the verifier seed from the master seed using the master seed as the password P and the concatenation of the verifier identifier and the time identifier as the salt S. Therefore, the inputs to the key derivation function are the master seed and the concatenated verifier identifier and time identifier. Of course, instead of using the verifier identifier and / or the time identifier, it is possible to use the default value instead. Since the information about the salt can be substituted in this way, the verifier identifier and the time identifier do not have to be secret and may be public information. Verifier identifier V, as detailed below_IDContains information about verifiers and may also contain other information such as time values.

【0041】

In one embodiment, the key derivation function KDF is a master seed S._MIdentification V for 100 and Verifier 108_IDAnd is input. Device 102 is also Master Seed S_MStores 100 and verifier identifier information V_IDHave access to. Therefore, device 102 uses the same key derivation function KDF to master seed S._M100 and verifier identifier information V_IDFrom the same verifier seed S_VCan be obtained.

【0042】

To authenticate to the verifier 108, the device 102 is the verifier seed S shared by the device 102 and the verifier 108._VIs used. In certain embodiments, the device 102 is a verifier seed S._VIs sent to Verifier 108 as it is, and this authentication is performed. In another embodiment, device 102 is Verifier Seed S._VThis authentication is done by sending a mathematically derived value from Verifier 108. In this case, device 102 is Verifier Seed S_VMathematically derive a value from, and send this derived value to verifier 108. In various embodiments, this derivation is done using hash functions, block ciphers, message authentication codes or other techniques. In certain embodiments, the verifier seed S is part of the derivation._VIs combined with other information (eg, time-dependent information). For example, in one embodiment, device 102 is Verifier Seed S._VSend a hash of. In another embodiment, the device 102 uses the derived time-dependent value as a verifier seed S._VIs used as the encryption key to send the encrypted version. Other authentication and communication systems and methods available for sharing secrets between device 102 and verifier 108 may be extended to use verifier seeds. For example, U.S. Pat. Nos. 4,720,860, 4,885,778, 4,856,062, 4,998,279, 5,023,908, 5,058,161, 5,097,505, 5,237,614, 5,367,572, and 5,367,572. 5,361,062, 5,485,519 and 5,657,388 describe various authentication systems and methods using shared secrets. It is possible to incorporate into such systems the systems and methods of the invention that use verifier seeds as the basis for authentication. As another example, in a challenge / response system, verifier 108 sends a challenge value to device 102 and device 102 verifier seed S the challenge value._VEncrypt with and return the result to the verifier. In certain embodiments, the device 102 displays or communicates credentials to the user, and this user communicates the credentials to the verifier.

【0043】

In certain embodiments, the verifier seed S_VIs unique for a particular verifier 108. In another embodiment, Verifier Seed S_VIs associated with two or more verifiers 108 and is shared by those verifiers 108. In such an embodiment, the verifier identifier information V_IDIdentify a group of verifiers, not a specific verifier 108. The entity or device 102 may or may not know that two or more verifiers 108 are associated with a particular verifier identifier.

【0044】

In another embodiment, Verifier Seed S_VIs specific for a particular time or period. The term "hour or period" as used herein means a second, a minute, an hour, a day, a week, a month, a year, a time or period in a unit smaller than these, two or more of these, or a combination thereof. In one such embodiment, the time or period is represented by a time identifier (eg, a date written in the format YYYYMMDD) that indicates a particular day written in a particular format. In another such embodiment, the "day" is a day that begins with a particular number of seconds elapsed from a predetermined date. In certain embodiments, this predetermined date is January 1, 1970. In these embodiments, the verifier identifier information V_IDContains time identifier information.

【0045】

In another embodiment, Verifier Seed S_VIs unique for both a particular time or period and a particular verifier or group of verifiers. In one such embodiment, the "time or period" is the time identifier information T._IDThe above "verifier or group of verifiers" is represented by the verifier identifier V._IDRepresented by. In one such embodiment, the time identifier information T_IDAnd verifier identifier information V_IDIs a separate input to the key derivation function KDF. In another embodiment, the time identifier information T_IDAnd verifier identifier information V_IDAre mathematically combined before being provided as input to the key derivation function.

【0046】

In another embodiment, the verifier seed S for a particular time period_VIs a unique seed for that verifier (ie, verifier master seed S_VM) Derived from. Verifier Master Seed S_VMIs the master seed S_MDerived from. In one such embodiment, the verifier master seed uses the key derivation function as the master seed S._MAnd verifier identifier information V_IDDerived by applying to. The verifier seed uses the key derivation function as the verifier master seed S._VMAnd the time identifier T_IDDerived by applying to.

【0047】

FIG. 2 applies the embodiment of FIG. 1 to one verifier 108 with different verifier seeds S._VnThe case where it is extended to a plurality of verifiers 108-0, 108-1, 108-2, 108-3 and 108-4 (collectively referred to as "verifier 108") having the above is shown. Device 102 and server 104 are secret master seeds S_MShare 100. The server 104 uses the verifier seed S for each of the plurality of verifiers 108._V0, S_V1, S_V2, S_V3And S_V4(Collectively, "Verifier Seed S"_VnAlso called). The number of verifiers in the illustrated example is merely an example, and the present invention is not limited to a specific number of verifiers. In certain embodiments, the server 104 attaches a verifier seed S to each verifier 108._VnTo distribute. Appropriate Verifier Seed S for each Verifier 108_VnDevice 102 is used to authenticate against its verifier 108.

【0048】

A method of authenticating a user using a verifier according to the present invention will be described with reference to FIG. This method is Master Seed S_MIncludes step (step 200) to generate. As mentioned above, seeds may be generated by a seed generator provided on device 102 or server 104, or by a seed generator located elsewhere. In certain embodiments, Master Seed S_MIs specific to a particular device. In another embodiment, Master Seed S_MIs unique for a group of devices. In certain embodiments, Master Seed S_MIs stored in a hardware or software token device accessible by the user.

【0049】

This method is based on the master seed and verifier information._V(Step 201) is included. In certain embodiments, the verifier seed S_VIs derived using a key derivation function that takes the user's master seed and verifier identifier information as input. In certain embodiments, the verifier seed S_VIs unique for a single or multiple verifiers. In one embodiment, the key derivation function also receives other information as input. The above "other information" includes, but is not limited to, time identifier information. In certain embodiments, the "other information" is mathematically combined with a verifier identifier before being provided to the key derivation function. The key derivation function, as output, is a verifier seed S that is unique to the master seed and verifier._Vgive.

【0050】

This method uses Verifier Seed S_VIs further included (step 202). Preferably, this transmission is done over a secure channel. For example, in one embodiment, Verifier Seed S_VIs sent to the verifier over an encrypted network connection. In another embodiment, Verifier Seed S_VIs transmitted to the verifier by storing the seed on a portable medium such as a floppy disk and delivering the disc to the verifier. In another embodiment, Verifier Seed S_VIs transmitted to the verifier by inputting this information directly into the verifier via a keypad, keyboard or other input device. A secret shared by Verifier 108 and Device 102 after being sent to Verifier (ie, Verifier Seed S)_V) Can be used by verifiers for authentication, encryption or communication.

【0051】

FIG. 4 shows a case where the above authentication system is implemented using the token 211. In one such embodiment, token 211 is a hardware token, a credit card-sized device with a microprocessor with memory and associated hardware logic and firmware, a battery, and an LCD display. .. In certain embodiments, the token 211 also accepts data input via buttons, keypads, pressure sensitive displays, and the like. Seed generator 210 for each hardware token 211, master seed S_MTo generate. The seed generator 210 is a random number generator configured to output a random number seed. In one embodiment, the seed generator 210 generated the master seed S_MIs a random number with a length of 64 or 128 bits.

【0052】

In certain embodiments, the hardware token 211 is the master seed S of the token 211 during the manufacturing phase._MAnd programmed with the current time and verifyer and / or time identifier information. In another embodiment, some or all of this information is electronically entered into the memory of the hardware token via a data communication path or using a particular input button sequence. Also, the master seed S of this token_MIs sent to the seed distribution server 212 over a secure channel. In certain embodiments, the master seed S_MIs recorded on a portable medium such as a floppy disk by the seed generator 210, and this disk is delivered to the seed distribution server 212. In another embodiment, Master Seed S_MIs transmitted over the data network. In yet another embodiment, the master seed S associated with a particular token 211 is used using another transmission scheme._MIs provided to the server. Thus, token 211 and seed distribution server 212 are master seed S._MShare the secret of.

【0053】

The seed distribution server 212 generates verifier-specific seeds for various verifiers 220-222. Figure 4 shows three verifyer Vs as an example of multiple verifyers.₀220, V₁221 and V₂222 is shown, but this does not limit the invention to a particular number of verifiers. Each verifyer V₀220, V₁221 and V₂222 has the verifier identifier V, respectively._IDIs associated. The verifyer identifier is the input of the key derivation function. Depending on the key derivation function selected, it may be possible to use a simple verifyer identifier, such as a three-character code, as the verifyer identifier. Alternatively, the verifyer identifier can be a long and complex number. If the verifyer identifier is a long and complex number, you may give the user an easy-to-remember name or mnemonic (eg, a number or short alphanumeric code) for a verifyer. The name can be used to "look up" the actual verifyer identifier from a pre-programmed table.

【0054】

Verifyer identifier V_IDIs a verifyer seed S for each verifyer that utilizes a key derivation function_V0, S_V1And S_V2Is used to derive. Each verifyer seed S_VnIs sent to each verifyer over a secure channel. Therefore, Verifier Seed S_V0Is Verifier V₀Sent to 220, Verifier Seed S_V1Is Verifier V₁Sent to 221 and Verifier Seed S_V₂Is Verifier V₂Sent to 222. Subsequent verification seed S_VnThe same applies to. In certain embodiments, a unique verifyer seed S for each verifyer._VnIs recorded on portable media such as a floppy (registered trademark) disk by the seed distribution server 212, and this disk is recorded on each verifier V._nHanded to each verifyer V_nLoaded on. In another embodiment, the verifier-specific seed S_VnEach verifyer V over an encrypted communication channel on the computer network_nWill be sent to. In another embodiment, other transmission schemes are used. Thus, the verifyer seed S associated with a particular token 211_VnIs each verifyer V_nGiven to.

【0055】

When using this system, user 213 authenticates verifiers 220 to 222 using token 211. For convenience, the following is Verifier V₁The authentication process will be described for 221 but it goes without saying that the same process is used for other verifiers. User 213 is the verifier identifier V_IDOr verifyer identifier V_IDEnter the code associated with in token 211. In certain embodiments, this input is made using the input button on token 211. In certain embodiments, this code is Verifier V.₁The first few letters of the 221 name. In another embodiment, this code is a suitable verifyer one-button indicator, and in another embodiment, this code is an identifier number. In other embodiments, other techniques are used to verify the V.₁Identify 221. In certain embodiments, token 211 seeks a verifier identifier from the code entered by user 213. This verifyer identifier is actually the verifyer V entered by user 213.₁It may be the code associated with 221 or token 211 obtains a verifier identifier from the code entered by user 213 (eg, by performing a hash function or other arithmetic processing, or lookup processing). It may be derived.

【0056】

Token 211 uses the verifyer identifier to verify the verifyer's verifyer seed S._VnTo ask. After that, token 211 is verified seed S_VnUser 213 uses Verifier V₁Ask for an authentication code that can authenticate to 221. In one embodiment, the code output by token 211 is Verifier Seed S._VnIt is the result of arithmetic processing such as cryptographic processing performed on. In another embodiment, Verifier V₁In addition to the code associated with 221 the user 213 also enters a personal identification number (PIN) on token 211. In this embodiment, the code output by token 211 is verifyer seed S._VnAnd is the result of arithmetic processing such as cryptographic processing performed on the personal identification number. In another embodiment, the code output by token 211 is Verifier Seed S._Vn, A personal identification number entered by the user, and the result of arithmetic processing such as cryptographic processing performed on other information (eg, a value derived from the current time).

【0057】

User 213 reads the code output on the display of token 211 and sends this code to the verifyer. This transmission can be done in a variety of ways, including typing the code on a keypad or computer keyboard, writing the code, speaking the code, or sending the code over a computer or telephone network. These methods are not limited. Verifier V₁221 determines if this code is appropriate (eg, in the case of the above embodiment, if this code is correctly derived from the verifyer seed, the user's PIN and the current time). If properly derived, user 213 is authenticated and gained access. If the code is incorrect, other actions may occur. This "other operation" includes, but is not limited to, an operation such as transmitting a warning signal and causing the user 213 to retry.

【0058】

Another verifyer (eg Verifier V₀When authenticating to 220), user 213 enters the code associated with the verifyer. Token 211 is Verifier V₀220 Verifier Seed S_V0Ask for that verifyer V₀Give the appropriate authorization code for 220.

【0059】

In another embodiment of token 211, token 211 can store a static password and ask for an authorization code based on a verifyer seed. User 213 enters a static password in token 211 and associates this static password with the service identifier. When user 213 enters a service identifier in token 211, token 211 indicates whether this service identifier points to the static password stored in token 211, or whether this service identifier points to a verifier identifier. Judge whether or not. As mentioned above, in the case of a dynamic authentication code, the service identifier can be a verifier identifier or a reference to the verifier identifier. In certain embodiments, token 211 may also require the user to enter a PIN or other code in order to obtain a stored static password. In this embodiment, token 211 can serve as a multipurpose password / authentication tool that stores the user's static password and gives an authentication code based on various verifyer seeds based on the user's master seed.

【0060】

FIG. 5 shows the authentication method according to the present invention. This authentication method is Master Seed S_MIncludes a step (step 240) to generate. In certain embodiments, the seed generator 210 is the master seed S._MTo generate. In various embodiments, the seed generator 210 may be built into the server 212 or token 211, or it may be a separate device (seed generator 210). Seed generator 210 master seed S in such a way that it can be stored in token 211 and seed distribution server 212._MIs output, thereby master seed S_MIs shared between token 211 and seed distribution server 212 (step 241, step 244). In certain embodiments, the master seed S_MIs generated by token 211, then Master Seed S_MIs once displayed on the LCD display so that it can be shared with the seed distribution server 212. In yet another embodiment, the seed distribution server 212 is the master seed S._MAnd this master seed S_MIs programmed into token 211. The seed distribution server 212 is the master seed S, which is a verifier identifier._M, And (optionally) other information as input, for each verifier Seever Seed S_Vn(Step 242). Seed distribution server 212 attaches verifier seed S to verifiers 220-222._VnIs sent (step 243).

【0061】

In certain embodiments, Master Seed S_MWhen is shared, token 211 is in its memory, master seed S._MIs stored (step 244). To authenticate against the verifyer, token 211 is a master seed S_M, Verifier identifier, and (optionally) other information as input to derive the appropriate seed for that verifier (step 245). Token 211 is Verifier Seed S_V, And (optionally) generate an authorization code based on other information (step 246). In certain embodiments, the authorization code is based on additional information such as a PIN or current time. In such an embodiment, the authentication code becomes a useful code only for a short period of time. This authorization code is sent to the verifier (step 247). In one embodiment, user 213 reads the authorization code on the token 211 display and sends this authorization code to the verifier.

【0062】

Verifier V₁221 is Verifier Seed S from Server 212_VReceived this Verifier Seed S_VTo store. When token 211 tries to verify against the verifyer, the verifyer sees the verifyer seed S._VObtain the authorization code from (step 248). This verification code required by the verifyer is also obtained by the additional information such as PIN and current time when token 211 uses additional information when requesting the authentication code. The verifyer receives the verification code (step 249) and authenticates the entity by comparing the sent verification code with the verification code obtained in step 247 (step 250).

【0063】

In certain embodiments of the user authentication methods and systems according to the invention, the device shares a secret called a "master seed" with the server. Both the device and the server use a key derivation function to derive one or more secrets from this master seed, called verifier seeds. The server shares one verifyer seed with one or more verifyers. The device or the entity that uses the device can authenticate to one of multiple verifiers using this appropriate verifyer seed. This method allows the device and the verifier to share a secret (ie, the verifier seed for the verifier) without the verifier knowing the master seed or other verifier seeds. Therefore, the device only needs to store one master seed, have access to the information necessary to correctly derive the appropriate verifyer seed, and have the ability to derive the seed. Individual verifiers do not have access to the master seed and cannot invade the master seed.

【0064】

A person skilled in the art can make modifications, modifications and other embodiments to the embodiments described herein without departing from the spirit and scope of the invention as claimed. Is.

【0065】

For example, in some embodiments, it is possible to divide the seed derivation step into two or more steps without departing from the scope of the invention. In one such embodiment, a tentative intermediate seed is derived from the master seed by mathematically combining the master seed with a time identifier. From this temporary intermediate seed, a verifyer seed is generated and distributed to the verifyer on a regular basis. This method further reduces the likelihood that either the tentative intermediate seed or the verify seed will be compromised. This is because all such verify seeds are considered "expired" at the end of a given period. In one such embodiment, the tentative intermediate seed is derived from the master seed using a date identifier. Generate verifier seeds from tentative intermediate seeds daily with the appropriate verifier identifier. The server distributes these verifyer seeds to the verifyers. The user's device uses the time identifier to generate a tentative intermediate seed every day, and uses this tentative intermediate seed to derive a verifyer seed for each verifyer using the verifyer information.

【0066】

Further, by using the present invention, it is possible to perform authentication inside and outside the company using a single secret (master seed). When used within a single company, the company issues a token recording the master seed to each user and distributes verifyer seeds to various services within the company. Each of these services can authenticate a user with a shared secret and / or an authentication code derived from that shared secret. As a result, even if there is an invasion, the damage can be limited to a specific service. Even when used beyond the framework of a single company, the present invention makes it possible to authenticate to various services unrelated to each other using a single secret. These unrelated services receive a verifyer seed from a server that has a master seed. The user can then authenticate each of these unrelated services without prior contact with each service. The user only needs to know the appropriate verifyer identifier for the service.

【0067】

Further, the authentication code required based on the verification seed as described above can be used as an encryption key for secure communication between the user and the service having the verification seed for the user. Is. Communication may be continued using this secure channel as it is, or another encryption key may be securely transmitted using this channel for more secure communication.

【0068】

Therefore, the present invention is not defined by the above exemplary description, but by the gist and scope of the claims.

【0069】

[Effect of the invention]

Therefore, the systems and methods according to the invention allow an entity to authenticate to many verifiers without managing a large number of secrets.

[Simple explanation of drawings]

[Figure 1]

It is a block diagram which shows one Embodiment of the system by this invention.

[Figure 2]

It is a block diagram which shows one Embodiment of the system which has a plurality of verifiers by this invention.

[Fig. 3]

It is a flowchart which shows one Embodiment of the authentication method by this invention.

[Fig. 4]

It is a block diagram which shows one Embodiment of this invention using a token.

[Fig. 5]

It is a flowchart which shows the authentication method by this invention.

[Explanation of symbols]

100 master seed 102 devices 104 server 108 Verifier 210 seed generator 211 tokens 212 Seed distribution server 213 users 220 ~ 222 Verifier