WO1999065175A1 - Method for generating, storing, and verifying a binding between an authorized user and a token - Google Patents

Method for generating, storing, and verifying a binding between an authorized user and a token Download PDF

Info

Publication number
WO1999065175A1
WO1999065175A1 PCT/US1999/013000 US9913000W WO9965175A1 WO 1999065175 A1 WO1999065175 A1 WO 1999065175A1 US 9913000 W US9913000 W US 9913000W WO 9965175 A1 WO9965175 A1 WO 9965175A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
group
user
attribute
information
Prior art date
Application number
PCT/US1999/013000
Other languages
French (fr)
Inventor
Yair Frankel
Judy H. Moore
Larry M. Moore
Original Assignee
Sandia Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sandia Corporation filed Critical Sandia Corporation
Priority to AU45571/99A priority Critical patent/AU4557199A/en
Publication of WO1999065175A1 publication Critical patent/WO1999065175A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231Biological data, e.g. fingerprint, voice or retina
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • 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.
  • Restricted facilities are commonplace wherein the facilities themselves, as 0 well as the personnel and information inside the facilities, must be protected.
  • modern networks are used to process highly sensitive information and to perform critical functions.
  • 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.
  • 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.
  • the term “secured enterprise” includes a controlled exchange of information or items between persons or systems elements such as hardware or software.
  • 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.
  • 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.
  • 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.
  • a unique characteristic of an authorized user such as a biometric
  • 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.
  • 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.
  • 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.
  • 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:
  • 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
  • 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.
  • 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.
  • 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.
  • 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;
  • 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
  • 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.
  • 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.”
  • token attributes include geometric properties, acoustic properties, chemical properties, electrical properties, mechanical properties, optical properties and stored information in the memory.
  • user characteristics include biometrics information such as fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
  • 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.
  • 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.
  • 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.
  • 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.
  • a physical attribute is selected as the distinguishing feature of the token.
  • 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.
  • a physical attribute of the token is detected, and a digital representation of that physical attribute is generated.
  • 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.
  • RPT reflective particle tag
  • the camera output can then be converted into digital format.
  • a characteristic of an authorized user is detected, and a digital representation of that characteristic is generated.
  • 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.
  • Bio biometrics information
  • 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).
  • SN serial number of the token
  • Pr user-specific system privileges
  • PINs personal identification numbers
  • 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.
  • 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):
  • CSK signature algorithm
  • 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.
  • 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.
  • 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.
  • 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.
  • step 105 data from steps 101 -104 are stored in the memory of the token.
  • 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.
  • 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.
  • 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.
  • 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) (RPT 1 ), and identifiable characteristics of the authorized user to whom the token was issued at the time of signing (Bio 1 ), as well as public and private information (SN' and Pr").
  • a detector detects (and perhaps measures) an identifying characteristic (Bio") of the individual presenting the token.
  • the type of characteristic detected 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.
  • 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.
  • RPT reflective particle tag
  • 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").
  • SN serial number of the token
  • Pr' user-specific system privileges
  • 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.
  • Critical System Attributes data e.g., RPT', Bio', SN', Pr'
  • a numerical comparison is made based on information associated with the stored signature.
  • the token reader uses 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the user presenting the token and the token 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.
  • 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
  • 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.
  • 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
  • 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
  • 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.

Abstract

A data structure is disclosed which provides for establishment of a strong link between an authorized user and a token issued to that authorized user. A digital signature (104), created using a digital signature algorithm, a corresponding verification algorithm and a cryptographic key, is based on, at a minimum attribute(s) (101) of the token and characteristic(s) (102) of the authorized user (e.g. biometrics) to whom the token is issued. The signature and information about token attributes (101) and user characteristics (102) are used to create the binding during enrollment, and the digital signature (104) is stored in the token memory (105) along with at least information about the characteristic(s) (102) of the authorized user and the attributes (101) of the token. Additionally, information about distinguishing attribute(s) is available from the token, perhaps from the token memory (105). The data structure permits verification of token authenticity and user authorization when a token is presented for use.

Description

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 = C [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.

Claims

We claim:
1. A method of binding a particular user to a particular token assigned to that user comprising the steps of: providing a token comprising a memory and having at least one token attribute which distinguishes the token from at other tokens, designating an authorized user of the token, the authorized user having at least one user characteristic which distinguishes the authorized user from other potential users, detecting the at least one token attribute and creating a digital representation of the at least one token attribute,
detecting the at least one user characteristic and creating a digital representation of the at least one user characteristic, calculating a digital signature using a cryptographic signature algorithm and a cryptographic key and information corresponding to the at least one token attribute and the at least one user characteristic, and storing in the memory information comprising the digital representation of the at least one user characteristic and the digital signature.
2. The method of claim 1 wherein the calculating of the digital signature includes using a public key cryptography method based on a technique selected from the group consisting of solving knapsacks, solving discrete logarithms, solving factorization problems and any combination thereof.
3. The method of claim 2 employing a technique selected from the group consisting of RSA, DSA, Schnorr, ESIGN, El Gamal, GOST and any combination thereof.
4. The method of claim 1 wherein the at least one token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
5. The method of claim 2 wherein the at least one token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
6. The method of claim 3 wherein the at least one token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
7. A verification method comprising the steps of: reading information from a memory on a token, the information comprising a digital signature generated using a digital signature algorithm, a digital representation corresponding to at least one user characteristic, and a digital representation corresponding to at least one token attribute, detecting at least one characteristic of the presenting user and creating a digital representation of the at least one characteristic, detecting at least one attribute of the token and creating a digital representation of the at least one attribute, generating a first calculated numerical result by performing a calculation comprising at least one mathematical step using a cryptographic key, and using at least one numerical aspect of the digital signature read from the token memory, generating a second calculated numerical result by performing calculation comprising at least one mathematical step using a cryptographic key determined by the digital signature algorithm used in generating the digital signature and using the biometrics information and the token attribute information previously read from the token memory, verifying a binding between a presented token and a presenting token user only if
a predetermined degree of correlation is found between the digital representation of the at least one detected characteristic of the presenting user with the digital information corresponding to user characteristic read from the token memory, a predetermined degree of correlation is found between the digital representation of the detected token attribute information and the digital information corresponding to token attribute information read from the token memory, and a predetermined degree of correlation is found between the first calculated numerical result and second calculated numerical result.
8. The method of claim 7 wherein the digital signature is calculated using a public key cryptography method based on a technique selected from the group consisting of the group consisting of solving knapsacks, solving discrete logarithms, solving factorization problems and any combination thereof.
9. The method of claim 8 employing a technique selected from the group consisting of the group consisting of RSA, DSA, Schnorr, ESIGN, El Gamal, GOST and any combination thereof.
10. The method of claim 7 wherein the at least one token attribute is selected from the group consisting of the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
11. The method of claim 8 wherein the at least one token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
12. The method of claim 9 wherein the at least one token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
13. A data structure comprising: a token bearing a memory and having at least one distinguishing attribute, an authorized token user having at least one distinguishing characteristic, and a digital signature stored in the memory of the token.
14. The data structure of claim 13 wherein the digital signature contains embedded data comprising: information about the at least one distinguishing attribute of the token, and information about the at least one distinguishing characteristic of the authorized token user.
15. The data structure of claim 14 wherein the digital signature is cryptographically generated.
16. The data structure of claim 15 wherein the digital signature is generated using a public key cryptography method based on a technique selected from the group consisting of solving knapsacks, solving discrete logarithms, solving factorization problems and any combination thereof.
17. The data structure of claim 15 wherein the digital signature is generated using employing a technique selected from the group consisting of RSA, DSA, Schnorr, ESIGN, El Gamal, GOST and any combination thereof.
18. The data structure of claim 15 wherein the at least one distinguishing token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one distinguishing user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
19. The data structure of claim 16 wherein the at least one distinguishing token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one distinguishing user characteristic is a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
20. The data structure of claim 17 wherein the at least one distinguishing token attribute is selected from the group consisting of geometric, acoustic, chemical, electrical, mechanical and optical characteristics of the token and the at least one distinguishing user characteristic is. a biometric selected from the group consisting of fingerprint data, voice patterns, handwriting dynamics, hand geometry, and retinal or iris characteristics.
PCT/US1999/013000 1998-06-10 1999-06-09 Method for generating, storing, and verifying a binding between an authorized user and a token WO1999065175A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU45571/99A AU4557199A (en) 1998-06-10 1999-06-09 Method for generating, storing, and verifying a binding between an authorized user and a token

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US9543098A 1998-06-10 1998-06-10
US09/095,430 1998-06-10

Publications (1)

Publication Number Publication Date
WO1999065175A1 true WO1999065175A1 (en) 1999-12-16

Family

ID=22251985

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/013000 WO1999065175A1 (en) 1998-06-10 1999-06-09 Method for generating, storing, and verifying a binding between an authorized user and a token

Country Status (2)

Country Link
AU (1) AU4557199A (en)
WO (1) WO1999065175A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001074008A1 (en) * 2000-03-27 2001-10-04 Alpine-Invent Gmbh Method for generating electronic signatures
WO2002087151A1 (en) * 2001-04-25 2002-10-31 Telefonaktiebolaget L M Ericsson (Publ) Cryptographic signing in small devices
WO2003034655A1 (en) * 2001-10-01 2003-04-24 New Rocket Science As System, portable device and method for digital authenticating, crypting and signing by generating short-lived cryptokeys
DE10340064A1 (en) * 2003-08-28 2005-04-07 Francotyp-Postalia Ag & Co. Kg Arrangement for detecting biometric data, especially medical data, of individual stores identification associated with individual in memory; processing unit performs manipulation-proof combination of biometric data with identification
US7174463B2 (en) 2001-10-04 2007-02-06 Lenovo (Singapore) Pte. Ltd. Method and system for preboot user authentication
US20080059793A1 (en) * 2006-08-31 2008-03-06 Lord Robert B Methods and systems for phone home token registration
US7882363B2 (en) 2002-05-31 2011-02-01 Fountain Venture As Biometric authentication system
US8229177B2 (en) 2001-05-31 2012-07-24 Fountain Venture As Data processing apparatus and method
US8572673B2 (en) 2004-06-10 2013-10-29 Dominic Gavan Duffy Data processing apparatus and method
US9305153B1 (en) * 2012-06-29 2016-04-05 Emc Corporation User authentication
US9384338B2 (en) 2004-06-09 2016-07-05 Genkey Netherlands B.V. Architectures for privacy protection of biometric templates

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4993068A (en) * 1989-11-27 1991-02-12 Motorola, Inc. Unforgeable personal identification system
US5396558A (en) * 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
US5434917A (en) * 1993-10-13 1995-07-18 Thomson Consumer Electronics S.A. Unforgeable identification device, identification device reader and method of identification
US5613012A (en) * 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5796832A (en) * 1995-11-13 1998-08-18 Transaction Technology, Inc. Wireless transaction and information system
US5872848A (en) * 1997-02-18 1999-02-16 Arcanvs Method and apparatus for witnessed authentication of electronic documents

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4993068A (en) * 1989-11-27 1991-02-12 Motorola, Inc. Unforgeable personal identification system
US5396558A (en) * 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
US5434917A (en) * 1993-10-13 1995-07-18 Thomson Consumer Electronics S.A. Unforgeable identification device, identification device reader and method of identification
US5613012A (en) * 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5796832A (en) * 1995-11-13 1998-08-18 Transaction Technology, Inc. Wireless transaction and information system
US5872848A (en) * 1997-02-18 1999-02-16 Arcanvs Method and apparatus for witnessed authentication of electronic documents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SCHNEIER B.: "Applied cryptography : protocols, algorithms and source code in C", 1 January 1996, JOHN WILEY & SONS, New York [u.a.], ISBN: 978-0-471-11709-4, article SCHNEIER B: "APPLIED CRYPTOGRAPHY", pages: 482 - 502, XP002923783, 021893 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001074008A1 (en) * 2000-03-27 2001-10-04 Alpine-Invent Gmbh Method for generating electronic signatures
ES2219192A1 (en) * 2001-04-25 2004-11-16 Telefonaktiebolaget L M Ericsson (Publ) Cryptographic signing in small devices
WO2002087151A1 (en) * 2001-04-25 2002-10-31 Telefonaktiebolaget L M Ericsson (Publ) Cryptographic signing in small devices
US8229177B2 (en) 2001-05-31 2012-07-24 Fountain Venture As Data processing apparatus and method
US7996683B2 (en) 2001-10-01 2011-08-09 Genkey As System, portable device and method for digital authenticating, crypting and signing by generating short-lived cryptokeys
WO2003034655A1 (en) * 2001-10-01 2003-04-24 New Rocket Science As System, portable device and method for digital authenticating, crypting and signing by generating short-lived cryptokeys
US7174463B2 (en) 2001-10-04 2007-02-06 Lenovo (Singapore) Pte. Ltd. Method and system for preboot user authentication
US7882363B2 (en) 2002-05-31 2011-02-01 Fountain Venture As Biometric authentication system
DE10340064A1 (en) * 2003-08-28 2005-04-07 Francotyp-Postalia Ag & Co. Kg Arrangement for detecting biometric data, especially medical data, of individual stores identification associated with individual in memory; processing unit performs manipulation-proof combination of biometric data with identification
US9384338B2 (en) 2004-06-09 2016-07-05 Genkey Netherlands B.V. Architectures for privacy protection of biometric templates
US8572673B2 (en) 2004-06-10 2013-10-29 Dominic Gavan Duffy Data processing apparatus and method
US20080059793A1 (en) * 2006-08-31 2008-03-06 Lord Robert B Methods and systems for phone home token registration
US9038154B2 (en) * 2006-08-31 2015-05-19 Red Hat, Inc. Token Registration
US9305153B1 (en) * 2012-06-29 2016-04-05 Emc Corporation User authentication

Also Published As

Publication number Publication date
AU4557199A (en) 1999-12-30

Similar Documents

Publication Publication Date Title
US4993068A (en) Unforgeable personal identification system
Bhargav-Spantzel et al. Privacy preserving multi-factor authentication with biometrics
EP2513834B1 (en) System and method for verifying the identity of an individual by employing biometric data features associated with the individual as well as a computer program product for performing said method
KR100757350B1 (en) Method of data protection and apparatus therefor
US6185316B1 (en) Self-authentication apparatus and method
EP1085424A1 (en) Authentication card system
Breebaart et al. Biometric template protection: The need for open standards
US20030182151A1 (en) Method of using biometric measurements as a legal seal for authenticating real estate deeds and mortgages
EP0983662A1 (en) Identification and security using biometric measurements
EP1584035A1 (en) Authorized anonymous authentication
WO2004100083A1 (en) Smart authenticating card
WO1999065175A1 (en) Method for generating, storing, and verifying a binding between an authorized user and a token
CN101488256B (en) Counter employee identity authentication system and method
JPS62212781A (en) Personal identification system
JP2007108832A (en) Individuals confirmation method and program and transaction processor
RU2573235C2 (en) System and method for checking authenticity of identity of person accessing data over computer network
WO1999017255A1 (en) Method and apparatus for authenticating ic card
KR20080109118A (en) Method for certificating fingerprint information using smart card, and system therefor
JP2001092960A (en) Fingerprint verifying method
JP3090265B2 (en) Authentication IC card
Cimato et al. Biometrics and privacy
WO1999060485A1 (en) Authentication card system
Bovelander et al. Smartcards and Biometrics: An Overview
JP2002304378A (en) Personal authentication system
Sollie Security and usability assessment of several authentication technologies

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase