METHOD FOR GENERAΗNG, STORING, AND VERIFYING A BINDING BETWEEN AN AUTHORIZED USER AND A TOKEN
5 BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a binding between an authorized user and a token having certain attributes. Attributes of relevance to the binding can include physical characteristics of the token or information stored within the token, or 0 associated with the token, such as serial number or other data associated with the token. This invention relates more particularly to a data structure comprising an encoded combination of at least one characteristic of an authorized user and at least one physical attribute or other characteristic of a particular token that is issued to that user. The data structure is generated, a portion of it is stored on 5 the token, and the data structure is used to authenticate both user and token upon presentation of the token for use in gaining access to a secured enterprise.
2. Description of Related Art
Restricted facilities are commonplace wherein the facilities themselves, as 0 well as the personnel and information inside the facilities, must be protected. Similarly, modern networks are used to process highly sensitive information and to perform critical functions. For example, modern networks are used to control much of our civilian infrastructure (e.g., gas, electricity, water supplies, and telecommunications) and many of our financial institutions.
For purposes of this patent application, the term "secured enterprise" is used to refer to all events, activities, entities or objects for which restricted access by a person or persons is desired or required. Likewise, the term "secured enterprise" includes a controlled exchange of information or items between persons or systems elements such as hardware or software. For purposes of this patent application, secured enterprises must also be suited to or adaptable to accommodate the presentation of a token by a prospective user in order for that prospective user to gain access or be permitted to engage in a transaction. Use of the token may occur either alone or in combination with other security measures. Examples of secured enterprises within the meaning intended in this patent application include but are not limited to restricted access buildings and other facilities, computer and telecommunications networks or files, financial systems and transactions made in the context person-to-person exchanges such as may be necessary in a courier system.
Countermeasures against unauthorized access to secured enterprises must account for changing threats and advancing technology. Tokens may be used to limit access to authorized users. Frequently used tokens include magnetic strip cards, smart cards or PCMCIA cards. Token-based access to secured enterprises is premised on a user presenting a token in order to demonstrate a given level of access authorization or permission to engage in a restricted transaction. Conventional tokens generally store information to be confirmed by a person seeking access to a secured enterprise. This information can include passwords, PINs or cryptographic keys. When these types of tokens are employed, authorized users input the appropriate user-
specific information (e.g., a password) when prompted. Whether access is granted depends on verification that the information supplied is appropriate.
In the scheme just described, although tokens are issued to authorized users, the strongest link between a particular token and a particular authorized user is knowledge by the user of the information associated with the token. Consequently, an unauthorized user having knowledge of the information associated with, and perhaps stored on, a token may use the token to gain unauthorized access to a secured enterprise. Furthermore, because particular tokens are not linked to particular authorized users, counterfeit tokens may be used, so long as the data associated with the token and that supplied by the user correlate.
To further limit access to secured enterprises, a unique characteristic of an authorized user, such as a biometric, may be measured and compared to the unique characteristic data base of authorized users. Examples of biometrics information include fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics. Biometrics information can be used alone to limit access, or it may be used in parallel combination with a token to limit access. When used in parallel combination with a token, measured biometrics information is compared with biometrics data stored either on a network or the token.
In applications where tokens store biometrics data, each token is linked to a particular authorized user by the biometrics data stored on the token. The use of a particular token is therefore limited to persons having biometrics characteristics that essentially match biometrics data stored on that token. However, tokens can be made
or perhaps altered to reflect biometrics of any user. For that reason, access to a secured enterprise may be gained fraudulently by using counterfeit tokens, so long as the biometrics of the individual presenting the token and the biometrics information stored on the token match closely enough to be accepted by the verification system of the secured enterprise. Accordingly, there exists a need to strongly link particular tokens to particular authorized users in a way that significantly decreases the likelihood that the counterfeiting activities described above will be successful in permitting unauthorized access to secured enterprises.
SUMMARY OF THE INVENTION
An object of this invention is to provide a binding between an authorized user and a particular token issued to that authorized user.
A further object of this invention is to provide a means for limiting access to secured enterprises unless both identifying characteristics of an authorized user and attributes of a token issued to that user are authenticated and correlated.
A further object of the invention is to cryptographically generate a signature at the time of enrollment which binds an authorized user to a particular token, wherein the signature is distinguishable and recognized as authentic at the time access to a secured enterprise is sought. A further object of the invention is to employ cryptographic methodologies in generating the signature used to bind a token to a particular authorized user.
Another object of the invention is to provide a method of binding a particular user to a particular token assigned to that user during an enrollment process that includes the following steps:
• providing a token including a memory and at least one attribute which distinguishes the token from other tokens
• detecting the distinguishing token attribute (or attributes) and creating digital representations of it (or them, if more than one is required for a given system)
• designating an authorized user for the token
• detecting at least one unique and distinguishing characteristic of the authorized user and creating a digital representation of it (or them, if more than one is required for a given system)
• calculating a digital signature using at least both categories of the digital representations mentioned above together with a cryptographic signature algorithm and a cryptographic key • storing in the memory of the token the digital signature, the digital representation of the distinguishing characteristic (or characteristics) of the authorized user and the digital representation of the token attribute (or attributes). Yet another object of the present invention is to provide a method of authenticating both a presented token (purported by the presenter to be authentic) and a presenting user (purporting to have access authorization), and verifying a binding between the token and user, comprising the steps of:
• locating and reading from the token information purported to correspond to at least one authentic token attribute and at least one characteristic of an authorized user
• locating and reading from the token a digital signature purported to be both authentic and generated according to the principles mentioned above for calculating a signature during the enrollment process for an authentic token
• detecting at least one characteristic of the presenting user and at least one attribute of the presented token (the specific combination of characteristics and attributes depending on the given system in which they are used), and creating digital representations of them
• comparing the digital representation of the (detected) presenting user characteristic information with the (stored) purportedly authentic authorized user characteristic information (if, indeed, stored information was previously located) using a standard algorithm for that user characteristic • comparing the digital representation of the (detected) presented token attribute information with the (stored) purportedly authentic token attribute information (if, indeed, stored information was previously located) using a standard algorithm for that token attribute
• calculating a first number using a numerical aspect of the digital signature stored on the presented token
• calculating a second number using the digital representations of user and token information read from the memory of presented token
• verifying whether the presented token and the presenting user are authentic based on: 1 ) the presence of appropriate types of information on the presented token, 2) the degree of correlation between the detected information and the stored information, and 3) the degree of correlation between the first calculated number and the second calculated number.
Another object of the present invention in to provide a data structure that includes a token bearing a memory and having at least one unique or distinguishing attribute, an authorized token user having at least one unique or distinguishing characteristic, and a digital signature stored in the memory of the token. The above and other objects are achieved by the present invention using a data structure which includes, stored on a token, digital bits representing one or more characteristics of an authorized user, digital bits representing one or more attributes of the authentic token, and a digital signature. The signature combines, at a minimum, information about the characteristics of the authorized user together with information about the attributes of the authentic token. The signature is created using a cryptographic key provided by a Trusted Authority.
Because of the features of cryptographic signatures, generally, the digital signature employed in the context of this invention using cryptographic principles
provides for a strong link or binding between the authentic token and the authorized user to whom it is issued. This binding makes compromise of the system infeasible for an adversary who possesses information about only one of the two parts (token attribute and user characteristic) of a signature created at enrollment. Moreover, if an
adversary lacks the necessary cryptographic key information, the likelihood that the adversary could replicate a functional signature on the token is infinitesimally small. Appropriate user characteristics include biometrics information that is unique to the authorized user, such as fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics. Suitable token attributes include information associated with or stored internally on the token as well as geometric, acoustic, chemical, electrical, mechanical and optical properties that are unique to that token.
Further scope of applicability of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of example only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS The present invention will become more fully understood from the detailed description given below and the accompanying drawings which are given by way of illustration only, and thus are not limitative of the present invention, and wherein:
FIGURE 1 is a flowchart describing an example of the enrollment process used at enrollment to generate and store the signature contained in the memory of the token; and
FIGURE 2 is a flowchart describing an example of the authentication process used when a token is presented by an individual intending to gain access to a secured enterprise; and
FIGURE 3 is a block diagram showing examples of components used to perform the signing and verification in the enrollment and authentication processes according to the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. The Token and Critical System Attributes
Fundamental to the principles of the invention is use of a token, or physical object, having certain unique properties referred to herein as "token attributes." Token attributes can include physical attributes, but they may also include information, such
as a serial number, which is associated with the object but not strictly tied to its physical characteristics. A token attribute (or a combination of token attributes) according to the invention must serve to distinguish an authentic token from other tokens. A token suited to the principles of this invention includes, but is not limited to a smart card, a magnetic strip card, a PCMCIA card, an optical memory card, and other types of cards or keys.
The token must also include a memory for storing information about at least two Critical System Attributes and a signature based on those Critical System Attributes. Critical System Attributes for this invention include, at a minimum, token attributes (as defined above) and distinguishing features of an authorized user. Those distinguishing features are referred to herein as "user characteristics." Examples of token attributes include geometric properties, acoustic properties, chemical properties, electrical properties, mechanical properties, optical properties and stored information in the memory. Examples of user characteristics include biometrics information such as fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
Along with the Critical System Attributes data, the memory stores a unique digital signature, which is derived from the Critical Systems Attributes data and created using a cryptographic signature algorithm and a cryptographic key. The digital signature is created during the enrollment process and forms the binding that provides the necessary strong link between the authorized user and that user's authentic token.
It is noted in passing that other information in addition to user characteristics and token attributes may also be stored in token memory and function as Critical System Attributes for purposes of the signature and verification features of the invention. For instance, the memory may store information such as the user's system access privileges and public/private information including the serial number of the token or passwords. If additional system attributes such as these were to be employed in a given application, their effect would be to add layers of security; as set forth in detail below, however, user characteristics and token attributes form the minimal and fundamental basis of the binding. As in the remainder of this specification, in the descriptions that follow, listings of user characteristics,- token attributes and public/private information are not intended to be exhaustive. Neither are they intended to be more or less limiting of the claims than other similar listings set forth in this specification. The figures are intended to be illustrative of the principles of the invention, and the examples selected are chosen for their clarity for the purpose of conveying an understanding the particular embodiments depicted in connection with the figures.
The Enrollment Process
FIGURE 1 is a flowchart describing an example of the enrollment process used to generate and store the signature contained in the memory of the token. It is during this process that the binding between a token and authorized user for that token is created. Enrollment must take place before the token is distributed to the user for
operational or regular use. In the example depicted in this Figure, and in the several figures to follow, a physical attribute is selected as the distinguishing feature of the token. As suggested elsewhere in this disclosure, though, an informational attribute in the form of data stored in the memory of the token or associated with the token can likewise serve to distinguish the token, and may be better suited for this purpose, given particular circumstances or requirements.
According to this example, in step 101 , a physical attribute of the token is detected, and a digital representation of that physical attribute is generated. For instance, an optical camera may be used to detect a reflective particle tag (RPT) created during the application of one of the materials used in the production of the token. The camera output can then be converted into digital format.
Similarly, in step 102, a characteristic of an authorized user is detected, and a digital representation of that characteristic is generated. For instance, a sensor can be used to detect biometrics information (Bio) such as a fingerprint or handwriting dynamics of an authorized user. This sensor output can then converted into digital format.
Step 103 illustrates that other public and private information can likewise be obtained, if needed or desired, and a digital representation of that information may be generated. Examples of public and private information that can be collected in this step include the serial number of the token (SN), user-specific system privileges (Pr), passwords, and personal identification numbers (PINs).
In step 104, a calculation is performed to generate a signature (S) based on at least the digital representations of the characteristic of the authorized user and the token attribute, and perhaps the digital representation of information obtained in step 103, if needed. For instance, equation 1 provides an illustrative example of the concept of a signature algorithm (CSK) that can be used in step 104 to cryptographically sign a group of Critical System Attributes from steps 101 -103 (e.g., Bio, Pr, RPT and SN):
S = Csκ [Bio, Pr, RPT, SNJ (1)
SK is a cryptographic key provided to the token issuing agent by a Trusted Authority. The encoding process of step 104 may, for example, use a Hash function, if appropriate for the application. Use of Hash functions is known to those skilled in the art of cryptography and it, along with other cryptographic techniques, is generally described in Applied Cryptography, Second Edition (© 1996 Bruce Schneier, published by John Wiley and Sons), pp. 483 - 502, which is herein incorporated by reference in its entirety. Additionally, any of a variety of standard digital signature algorithms known to those skilled in the art of cryptography can be used to generate the signature for purposes of this invention. These include but are not limited to using public key cryptography techniques based on the difficulty of solving knapsacks, discrete logarithms or factorization problems. Techniques for accomplishing this include RSA (U.S. Patent 4,405,829), DSA (U.S. Patent 5,231 ,668), Schnorr (U.S.
Patent 4,995,082), ESIGN (U.S. Patent 4,625,076), El Gamal (see: Diffie-Helman, U.S. Patents 5,724,425, 5,668,877, 5,633,933 and 5,588,060), and the Russian technique GOST (all of which are mentioned in the Applied Cryptography reference noted above). A cryptographic key known only to the token issuing agent is used to create the binding upon enrollment which can be the basis for distinguishing an authorized combination of Critical System Attributes from an unauthorized combination which, nevertheless, may exhibit otherwise sufficient internal correlation. As noted previously in this disclosure, absent the knowledge of which cryptographic key was used to generate the signature at the time of enrollment, the chances are very small that a counterfeiter could replicate a signature that would be recognized by the system upon verification. According to the invention, signing (step 104) which takes place during the enrollment process and verification which takes place in the authentication process described later with respect to FIGURE 2 both require a Trusted Authority to provide cryptographic information. In step 105, data from steps 101 -104 are stored in the memory of the token.
Specifically, the token memory stores the digital representation of the token attribute generated in step 101 , the digital representation of the user characteristic generated in step 102, the public and private information obtained in step 103, and the signature generated in step 104. Steps 101-103 may be performed simultaneously or in any order desired. Furthermore, as shown by the broken line connecting steps 103 and 105, the public and private information obtained in step 103 can be used to generate the signature, or it can simply be stored directly in the memory of the token, or both.
The Authentication Process
FIGURE 2 is a flowchart describing an example authentication process used in the present invention. The authentication process of FIGURE 2 is used to determine whether access to a secured enterprise should be granted based on the contents of the token memory and information gathered at the time of verification. In step 201 , when a token is inserted into a token reading machine (token reader), the various parameters stored in the token memory when the signature was made at the time of enrollment are read by a token reader. Such parameters can include, for instance: the signature (S'), attributes of the token stored at the time of signing (during the enrollment process) (RPT1), and identifiable characteristics of the authorized user to whom the token was issued at the time of signing (Bio1), as well as public and private information (SN' and Pr").
In steps 202-204, information is collected for comparison with the parameters read in step 201. More specifically, in step 202, a detector detects (and perhaps measures) an identifying characteristic (Bio") of the individual presenting the token. The type of characteristic detected, of course, must correspond to the type of user characteristic detected and measured at the time of signature and for which digitized information (Bio') is stored on the token. In step 203, a detector is used to detect attributes of the token that correspond to the token attribute information obtained at the time of enrollment and stored in the token memory. For instance, if the token memory stores reflective particle tag (RPT)
data, an optical camera can be used to detect reflective particle tag (RPT") data of the token presented.
In step 204 public and/or private information is obtained corresponding to the public and/or private information stored in the token memory at the time of enrollment. For instance, if a Trusted Authority indicates that the token memory stores the serial number of the token (SN') and user-specific system privileges (Pr'), a serial number of the presented token (SN") is obtained and the user is prompted for system privilege information (Pr").
Steps 201-204 may be performed simultaneously or in any order desired or dictated by a given application. However, step 201 (reading data stored in the token memory at the time of enrollment) and steps 202-204 (collecting current information) must be performed prior to step 205.
Step 205 compares the data read from the token memory in step 201 with the information collected in steps 202-204. Also in step 205 a two calculations are performed to verify the signature read from the token memory. These calculations may each involve one or more steps, depending on the given application. More specifically, verification according to the present invention requires at least two independent comparisons. The two comparisons discussed below are described in the sequence using the terms "first" and "second" for convenience. In practice, the comparisons can be made in any order and still fall within the scope of the invention. Rejection of a token based on either comparison may negate the need to perform the other comparison.
First, a comparison is made of the stored Critical System Attributes data (e.g., RPT', Bio', SN', Pr'), which were read from the token memory during step 201 , with the detected parameters (e.g., RPT", Bio", SN", Pr") collected in steps 202, 203 and 204. If Critical Systems Attributes data are missing from the token, or if any of the data read from the token are sufficiently dissimilar to the data detected from the presented token or user, the token will be rejected by the system. Encryption of the detected attributes and characteristics can be included if privacy becomes an issue.
Second, a numerical comparison is made based on information associated with the stored signature. Using a verification algorithm and a cryptographic key, which may either be identical to or related mathematically to the key used at enrollment, the token reader performs a first calculation based on a numerical aspect of the digital signature read from the memory. This first calculation yields a first calculated numerical result that will be used later as the basis for a comparison. A second calculation is also performed, but this time it is based on the digital representations of the user characteristics information and token attributes information read from the memory of the presented token. The second calculation yields a second numerical result. Then, a comparison is drawn between the first numerical result (which is based on signature data) and the second numerical result (based on the stored user and token data).
If the token, user and signature are all the same as those earlier enrolled (and therefore, all authentic) the first numerical result will correlate with the second numerical result, and the token, user and signature will all be verified. If, however,
there is insufficient correlation between the two numerical results, the token and the user will be rejected by the system.
This verification process proves or disproves the binding between the token and the user. Counterfeiting is deterred since in order to make a functional substitute token having a recognizable signature, or to be able to alter an enrolled token in a fashion that will deceive the token reader, a counterfeiter would need to have knowledge of the cryptographic key used at signing. Absent a breach of security within the Trusted Authority, such key information would not be available to a counterfeiter. Moreover, without the key information, a counterfeiter would not be able to replicate a signature that would be recognized on authentication since the same key, or cryptographically related keys, are used both in generating the signature and performing the calculations used at verification.
More comparisons between stored information and information collected at the time of verification may be incorporated into the verification process if additional layers of protection are desired. Similarly, more varieties of user- or token-specific information may be stored on the token, encoded into the signature on the token, and detected at the time the token is presented. The at least two comparisons of step 205 may be performed in any order so long they are both performed after the stored parameters (e.g., RPT, Bio', SN', Pr') and the detected parameters (e.g., RPT", Bio", SN", P ) are collected.
As described above, during the verification process, token attributes and user characteristics stored in the token memory are used in at least two ways: First, they are
used to determine the accuracy of parameters that are susceptible to error; specifically, whether measured (actual) user characteristics and the measured (actual) token attributes are within an acceptable range of error when compared with information stored on the token. Second, they are used to determine the accuracy of parameters that are not susceptible to error, i.e. those parameters used to create a signature.
Exemplary Components
FIGURE 3 is a block diagram showing exemplary components used to perform signing and verification processes according to the present invention where the user is authorized and the token is authentic. For purposes of this illustration, the user presenting the token and the token (including the token memory) are assumed to be the same as those involved at signing. For this reason, only a single user 304 and a single token and memory 305 are depicted in the Figure. In instances where they are not the same, and either the presenting user is not authorized or the presented token is not authentic, or both, verification according to the method of the invention should fail to take place. Also, note that for purposes of this illustration, detectors, token readers and token sensors are referenced as either "first" or "second" depending on whether they are employed at enrollment (during the signing step) or at authentication (during the verification step). First user detector 301 , first token reader 302 and first token sensor 303 perform the signing during the enrollment process. First token sensor 303 detects attributes of a particular token, and first user detector 301 detects characteristics of an authorized
user to whom the particular token is or will be issued. First token reader 302 receives information from first user detector 301 and first token sensor 303, and performs (either alone or in combination with other computing means) computations based on that information. The output generated by first token reader 302 (either alone or in combination with other computing means) is stored in the memory of token 305 using techniques well known to those skilled in the art pertaining to digital memory. For instance, assume that token 305 is intended to be used by user 304. According to this example, first token sensor 303 detects attributes of token 305. First user detector 301 detects characteristics of user 304. First token reader 302 performs computations (either alone or in combination with other computing means) necessary for generating the signature based on information output from first token sensor 303 and first user detector 301. Finally, first token reader supplies the computation output (signature) to the memory of token 305 along with any detected information (pertaining to user characteristics and perhaps token attributes) requiring storage in the token memory. Second user detector 306, second token reader 307 and second token sensor
308 perform verification during the authorization process when a user 304 presents a token 305. Second token sensor 308 detects attributes of the token presented, and second user detector 306 detects characteristics of the user presenting the token. Second token reader 307 reads information from the memory of token 305, receives
information from second user detector 306 and second token sensor 308. Second token reader 307 then performs computations on the information read and received.
FIGURE 3 illustrates the case in which the user detector, token reader and token sensor used at signing are different from those used at verification. This need not, however, always be the case. For example, a single detection instrument can be used both at signing and at verification. The same is true for the token reader and the token sensor. For convenience in a given application, though, it might be desirable to employ different instruments. Any combination of same or different instruments used for detection, sensing and reading at signing versus at verification may be used without departing from the spirit and scope of the appended claims. FIGURE 3 is intended to generically describe exemplary components used to perform the signing and verification processes of the present invention. These components may be combined, and other components known to those skilled in the art of user and token verification may be added without departing from the scope of this invention.
While there have been illustrated and described what are at present considered to be preferred embodiments of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof, without departing from the true scope of the present invention. In addition, many modifications may be made to adapt a particular situation to the teaching of the present invention without departing from the central scope thereof. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out the present invention, but that the present invention includes all embodiments falling within the scope of the appended claims.
The foregoing description and the drawings are regarded by the applicant as including a variety of individually inventive concepts, some of which may lie partially or wholly outside the scope of some or all of the following claims. The fact that the applicant has chosen at the time of filing of the present application to restrict the claimed scope of protection in accordance with the following claims is not to be taken as a disclaimer or alternative inventive concepts that are included in the contents of the application and could be defined by claims differing in scope from the following claims, which different claims may be adopted subsequently during prosecution, for example, for the purposes of a continuing or divisional application.