Trusted authentication digital signature (tads) system

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563

TRUSTED AUTHENTICATION DIGITAL SIGNATURE (TADS) SYSTEM

I. Cross-Reference to Related Applications

This patent application claims priority in the United States under 35 U.S.C. 119, and under the Paris Convention worldwide, to the benefit of the filing date of Wheeler et al. U.S. provisional patent application serial no. 60/223,076, which was filed on August 4, 2000, and which is incorporated herein by reference. This application also incorporates herein by reference each of three international patent applications and three U.S. patent application to Anne and Lynn Wheeler filed concurrently herewith in the U.S. Patent & Trademark Office and bearing serial number PCT/US / (entitled “Person-Centric Account-Based Digital Signature System”) and serial number 09/___,____(entitled “Account-Based Digital Signature (ABDS) System”); serial number

PCT/US / (entitled “Entity Authentication in Electronic Communications by Providing Verification Status of Device”) and serial number 09/___,___(entitled “Modifying Message Data and Generating Random Number Digital Signature Within Computer Chip”); and serial number PCT/US / (entitled “Linking Public Key of Device to Information During Manufacture”) and serial number 09/ (entitled “Manufacturing Unique Devices That Generate Digital

Signatures”).

II· Field of the Present Invention

The present invention generally relates to entity authentication and, in particular, to entity authentication in the field of electronic communications.

III. Background of the Present Invention

As used herein, an electronic communication (“EC”) is considered to be any communication in electronic form. ECs have become an integral part of transacting business today, especially with the growth of the Internet and e-commerce. An EC can represent, for example, a request for access to information or a physical area, a financial transaction, such as an instruction to a bank to transfer funds, or a legal action, such as the delivery of an executed contract.

In order for ECs to be effective, a recipient of the EC must be able to associate reliably the EC with the entity sending the EC or on whose behalf the EC is sent (collectively referred to herein as “sender”). A recipient receiving an EC requesting access to information or a physical area, prior to granting such information, needs to know who is requesting the access to verify that access may be given. Similarly, a recipient such as a financial institution receiving an EC instructing it to transfer funds from an account of one of its customers needs to know who is requesting the transaction to verify that the sender is authorized to make the transaction on the account.

In order to identify reliably the sender of an EC, an entity first must identify itself in some manner to the recipient some time before sending the EC, in response to which the recipient must

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563 assign an entity identifier to the entity. Thereafter, the entity identifier is included in an EC. Upon receipt of the EC, the recipient then cross-references the entity identifier included therein with the assigned entity identifier to identify thereby the sender of the EC. As used herein, “Entity Authentication” refers to the act of checking an entity identifier provided by a suspect entity against a previously assigned entity identifier in order to identify reliably the suspect entity.

Three common types of Entity Authentication are utilized today. A first type is based on what an entity “has,” in that possession of an object serves as the entity identifier (herein referred to as “Factor A Entity Authentication”). An example of the use of Factor A Entity Authentication includes the presentation of a credit card at a “pay-at-the-pump” gas station, wherein sliding of the card within a magnetic card reader provides a credit account number, which is magnetically stored on the credit card, to the card reader. The account number then is transmitted in an EC to a thirdparty authorization service for comparison with credit account numbers. In a simple case, if the account number transmitted by the card reader matches a valid account number in the database of the authorization service, if the account has not exceeded its credit limit, and if the card has not been reported lost or stolen, then the authorization for the charge may be granted. In this example, the entity of the EC (i.e., the consumer at the gas pump) is identified by the account number previously assigned by a financial institution to the consumer.

A second type of Entity Authentication is based on what an entity “knows,” in that disclosure of particular information associated with the entity serves as the entity identifier (herein refened to as “Factor B Entity Authentication”). An example of the use of Factor B Entity Authentication includes a request by an entity for information regarding a credit card account, such as balance information over the telephone. In this example, before the financial institution at which the credit card account is maintained provides the account balance to the caller, the caller’s identity is verified by requiring the caller to provide the account number and some other cardholder specific information, such as the zip code for the cardholder or the last four digits of the cardholder’s social security number - information which does not appear on the face of the card itself. If the information transmitted in the EC over the telephone matches the information associated with the credit card account, as maintained by the financial institution, then the caller is authenticated and the account balance is provided. In this case, the entity of the EC (i.e., the caller) is identified by the account number previously assigned and the cardholder-specific information previously obtained by the financial institution.

A third type of Entity Authentication is based on what an entity “is,” in that a biometric characteristic—such as a fingerprint—of an entity serves as the entity identifier (herein referred to as “Factor C Entity Authentication”). While not including an EC, an example of the use of Factor C Entity Authentication includes a customer physically presenting a credit card for payment to a merchant and providing a handwritten signature on the charge slip. In this scenario, the merchant obtains and compares the signature on the charge slip signed by the customer against the signature

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 of the cardholder appearing on the back of the credit card. This comparison is made particularly in cases where the credit account number is not verified through an authorization service as described above, or where the purchase is for a large amount. Upon a successful comparison as determined by the merchant, the customer is authenticated as the cardholder and the merchant accepts the 5 charge slip as payment. Factor C Entity Authentication has yet to be widely utilized with respect to ECs and is most often found in high security scenarios in which a biometric characteristic, such as a fingerprint or retina scan of an individual, is required for authentication of the individual. When used with ECs, a value for the biometric characteristics is obtained with a sensor or other electronic apparatus and the biometric value is compared (using fuzzy logic) with a prestored 10 biometric value for the same biometric characteristic in determining whether there is a match.

For additional security, multiple provision of the same type of Entity Authentication is sometimes required. For example, requiring two forms of personal identification involves two different pieces of Factor A Entity Authentication information. Knowing and providing two different “shared-secrets,” such as a zip code and mother’s maiden name, involves two different 15 pieces of Factor B Entity Authentication information. Providing two different biometric samples, such as a handwritten signature and a thumbprint, involves two different pieces of Factor C Entity Authentication information. Additional security can also be achieved by requiring the combination of two of more different types of Entity Authentication. For example, Factors A and B Entity Authentication are required in ATM transactions, in which possession of an ATM card and 20 knowledge of the coresponding PIN are required for use.

It will be appreciated and well known by those having ordinary skill in the art that the trust associated with conventional authentication systems is relatively weak, in that the entity identifier utilized for verifying entities today is easily susceptible to misappropriation or forgery. For example, credit cards can readily be counterfeited. Further, an account number, account-specific 25 information, and customer-specific information—including biometric values—all are susceptible to discovery (such as during transmission for authentication) and then fraudulent use in later authentications for transactions upon the relevant account. Once such information is misappropriated, it is difficult for a recipient of an EC to determine that the EC, including an entity identifier, has been sent fraudulently. Moreover, because of the weakness of Entity Authentication 30 in ECs, business methods and systems including ECs are subject to higher risks and less trust than would otherwise be the case if the Entity Authentication were stronger.

In an attempt to increase the trust in business methods and systems utilizing Entity Authentication in ECs, encryption technology has been used to attempt to “hide” or otherwise prevent entity identifier information from being intercepted during communications and 35 transmissions. Digital signatures have also been incorporated into the existing business infrastructue as an attempted means of providing strong authentication, in that an EC sents with an attached digital signature is presumed to come from the entity that claims to have digitally signed

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 the message contained in the EC. In particular, a digital certificate now is used to establish the identity of an entity for which an EC is sent that includes a digital signature originated specifically for a particular message of the EC.

In this regard, the origination of a digital signature generally comprises: (1) the calculation of a message digest—such as a hash value; and (2) the subsequent encryption of the message digest. The message digest is encrypted by an electronic device generally using a private key of a key pair used in public-private key cryptography (also known as asymmetric cryptography). Tire resulting ciphertext itself usually constitutes the digital signature, which typically is appended to the message to form the EC. The second part of originating the digital signature—using encryption with a private key—is referred to herein as “generating” the digital signature, and the combined two steps is referred to herein as “originating” the digital signature. Furthermore, while the generation of the digital signature is conventionally understood as the encryption of the message digest, it is contemplated herein that generating the digital signature also may include simply encrypting the message rather than the message digest. Digital signatures are important because any change whatsoever to the message in an EC is detectable from an analysis of the message and the digital signature. In this context, the digital signature is used to “authenticate” a message contained within the EC (hereinafter referred to as “Message Authentication”). Message authentication verifies the integrity of the message and should not be confused with Entity Authentication, which verifies an identity of an entity as represented by an entity identifier.

In an example of Message Authentication, a message digest is calculated by applying a hashing algorithm—such as the SHA-1 algorithm—to data representing the message. The hashing algorithm may be applied either within the device or external to the device with the resulting hash value then being transmitted to the device for generation of the digital signature. In order to perform Message Authentication in this example, the recipient of the EC must know or be able to obtain both the identity of the hashing algorithm applied to the message as well as the public key (“PuK”) corresponding to the private key used to encrypt the message digest. With this knowledge, the recipient applies the appropriate hashing algorithm to the message to calculate a hash value, and the recipient decrypts the digital signature using the public key. If the hash value calculated by the recipient equals the hash value of the decrypted digital signature, then the recipient determines that the content of the message contained in the EC was not altered in transmission, which necessarily would have changed the hash value.

Although message authentication should not be confused with Entity Authentication, the process of performing Message Authentication simultaneously enables the recipient of an EC to authenticate the sender of the EC, in so much as the recipient thereby confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message. This inherently represents Factor A Entity Authentication regarding the EC. Factor A

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563

Entity Authentication is useful when the recipient of the EC has trusted information regarding the identity of the owner of the private key.

This trusted information conventionally is provided based on a digital certificate issued by a trusted third party that accompanies the digital signature and that binds the identity of the private key owner with the public key. A digital certificate (also known as a “digital ID”) comprises â voucher by a third-party (commonly referred to as a “Certification Authority”) certifying the identity (or other attributes) of an owner of a public key. Essentially, a digital certificate is the electronic counterpart to a driver license, passport, membership card, and other paper-based forms of identification. The digital certificate itself comprises an electronic message including a public key and the identity of the owner of the public key. A digital certificate also typically contains an expiration date for the public key, the name of the Certification Authority, a serial number of the digital certificate, and a digital signature of the Certification Authority for insuring the integrity of the digital certificate. One of the reasons for an expiration date is to limit the liability of a Certification Authority due to the likelihood that attributes other than the identity of the public key owner change over time. The most widely accepted format for digital certificates is defined by the CCITT X.509 international standard; thus, certificates can be read or written by any application complying with X.509. Based on a digital certificate included in an EC, a recipient is able to authenticate the digital certificate using a public key of the Certification Authority and thereby, presumably, confirm the identity of the owner set forth therein. The overall system wherein a digital certificate is included in an EC comprises a “public key infrastructure” (PKI), and is referred to herein as the “Certification Authority Digital Signature” or “CADS” system, which is incorporated herein by reference.

A conventional implementation 100 of the CADS system in the context of an electronic transaction between a purchaser 102 and an online merchant 110 is illustrated in Fig. 1. Under this system, a purchaser 102 using, for example, a computer 104 creates a purchase order in the form of an electronic message. The purchaser 102 includes in the message relevant account information of a financial institution 112 from which payment is to be made to the merchant 110. The account information includes, for example, a credit card number and expiration date as well as the name on the card. Software on the purchaser’s computer 104 then originates a digital signature for the message using a private key of the purchaser 102 safeguarded in the computer 104. The software also maintains a digital certificate on the computer 104 issued by a Certification Authority 106a. The message, digital signature, and digital certificate then are combined into an EC, and the EC is communicated over the Internet 108 to the merchant 110.

Upon receipt, the merchant 110 authenticates the message using the public key in the digital certificate. If successful, the merchant 110 then authenticates the digital certificate using a public key of the Certification Authority 106a. Successful authentication of the digital certificate may satisfy the merchant 110 that the purchaser—the sender of the EC—is the owner identified in

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 the digital certificate. If the merchant 110 is so satisfied, then the merchant 110 submits the account information to the relevant financial institution 112 for an approval for payment to the merchant 110 from the account. Upon receipt from the financial institution 112 of approval for payment, the merchant 110 fills the purchase order of the purchaser 102. Furthermore, confirmation of approval (or rejection) of the purchase order preferably is sent from the merchant 110 to the purchaser 102.

While the CADS system enables two parties who otherwise may not have a preexisting relationship with one another to communicate with each other with the confidence of knowing the other’s identity, the CADS system has significant drawbacks. For example, a digital certificate typically is issued with an expiration date, and an expired digital certificate generally is not recognized in the industry. Furthermore, if a private key is lost or stolen, then the owner of the private key must notify the Certification Authority to revoke the owner’s digital certificate; however, a recipient of an EC with a digital certificate will only know of the revocation of the digital certificate if the recipient cross-references the serial number of the digital certificate against a certificate revocation list (CRL) published by the Certification Authority. Another drawback to the CADS system is that the digital certificate itself is only as good as the particular authority that issues it, and it often is necessary to obtain multiple digital certificates (i.e., from Certificate Authorities 106a, 106b to 106n) in order to create a sufficient “chain” or “network” of trust between the purchaser 104 and merchant 110 for a transaction or communication to be accepted and acted upon.

In addition to these drawbacks, a fundamental flaw to the CADS system actually providing a trusted authentication system based upon digital signatures is that a digital certificate only certifies the identity (or other attributes) of the owner of a private key, and falls significantly short of certifying that the private key actually has been used by the legal owner thereof in generating a particular digital signature. Indeed, trust in the CADS system—and generally in any digital signature system—depends upon the legitimate possession and use of the private key, i.e., upon the sender of each particular EC actually being the private key owner. A fraudulent use of a private key to generate a digital signature of an EC currently cannot be detected through the abovedescribed Message Authentication and Factor A Entity Authentication procedures. The digital signature system therefore is susceptible to fraud if a private key of a device is stolen, either by discovery of the private key therein and subsequent copying and use in another device capable of generating digital signatures, or by physical theft of the device containing the private key.

To guard against fraudulent use of a device to generate a digital signature through theft of the device itself, a personal identification number (PIN), password, or passphrase (collectively referred to herein as “Secret”) is typically prestored within the device and must be input into the device before it will operate to generate digital signatures. Alternatively, the Secret is shared with the recipient beforehand and, when the EC later is sent to the recipient, the Secret also is sent to

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 the recipient in association with the message. In the first case, verification of the Secret authenticates the user of the device (herein “User Authentication”), and in the second case, verification of the Secret authenticates the sender of the EC (herein “Sender Authentication”). In either case, confirmation of the Secret represents entity authentication based on Factor B Entity Authentication. Another security aspect that guards against fraudulent use of the device through physical theft include the verification of a biometric characteristic—like a fingerprint—of the user of the device or sender of the EC. This type of authentication is based on Factor C Entity Authentication. As with the Secret, a biometric value is either maintained within the device for User Authentication, or is shared with the recipient beforehand for Sender Authentication by the recipient.

To guard against discovery of a private key and subsequent copying and use in another device, devices are manufactured with electronic shielding, zeroization, auditing, tamper evidence and tamper response, and other security aspects that serve to safeguard the private key (and other protected data) contained therein. Such security aspects of devices include hardware, software, and firmware, and are well known in the art of manufacturing secure computer chips and other devices having cryptographic modules. The requirements of such security aspects are specified, for example, in Federal Information Processing Standards Publication 140-1, Security Requirements for Cryptographic Modules, US DOC/NBS, January 11, 1994 (herein “FIPS PUB 140-1”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips; and Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules, US DOC/NBS, May 25, 2001 (herein “FIPS PUB 140-2”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips. FIPS PUB 140-1 and 140-2 also define security levels that may be met by a device based on the device’s security aspects, with each of these defined security levels generally representing a various level of difficulty—in terms of time and money—that would be encountered in attempting to discern a private key of a device. Currently, four security levels are defined with security level 4 being the highest level of security available. Specifications for such security aspects also are set forth in Trusted Computing Platform Alliance Trusted Platform Module Protection Profile Version 0,45, TRUSTED COMPUTING PLATFORM ALLIANCE, September 2000; Trusted Platform Module (TPM) Security Policy Version 0.45, Trusted Computing Platform Alliance, October 2000; and TCPA PC Implementations Specification Version 0.95, Trusted Computing Platform ALLIANCE, July 4, 2001, which are incorporated herein by reference (collectively “TCPA Documents”), and which are available for download at http://www.trustedpc.com; and Common Criteria for Information Technology Security Evaluation, Smart Card Protection Profile, Draft Version 2. Id, SMART CARD SECURITY USER Group, March 21, 2001, which is incorporated herein by reference (hereinafter “Smart Card Protection Profile”), and which is available for download at http://csrc.mst.gov.

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563

As described in more detail herein, the particular aspects of a device that safeguard against discovery of a private key and other protected data are referred to herein as “security characteristics” of the device. The particular aspects of a device that safeguard against unauthorized use of the device by authenticating the user are referred to herein as “authentication capabilities” of the device. The “security aspects” of a device (including a cryptographic module or TPM) comprise the security characteristics and authentication capabilities as well as other security aspects of the device, the requirements of which are specified in the above cited references.

Unfortunately, while the aforementioned security aspects generally reduce overall the risk of fraud within the digital signature system, a recipient of any one particular EC including a digital signature may be unfamiliar with the device used to generate the digital signature and, therefore, be unable to gauge the risk of whether the digital signature was generated fraudulently, either through theft of the device or discovery of the private key.

Of course, if the recipient possesses a shared secret or a biometric value of the sender for performing Sender Authentication, then the recipient may determine that the digital signature was not fraudulently generated assuming that the shared secret or biometric value was not stolen. However, this type of protection by the recipient has significant drawbacks and is not always used by the recipient. For example, if the Secret or biometric value is communicated to the recipient in association with a message for Sender Authentication by the recipient, then the Secret or biometric value first must have been shared with the recipient beforehand and safeguarded by the recipient as part of an established, preexisting relationship; consequently, a recipient having no prior existing relationship with the sender is unable to perform Sender Authentication.

Another drawback is that the sharing of the Secret or biometric value with the recipient exposes the recipient to liability and exposes the Secret or biometric value itself to a greater risk of theft and dissemination. The transmission of the Secret or biometric value for verification carries with it the risk of interception and discovery during transit. Upon receipt, the Secret or biometric value must be safeguarded by the recipient, which inherently gives rise to a risk of theft from the recipient. This is especially significant in the corporate context where a rogue employee may steal the safeguarded Secret or biometric value (insider fraud historically has been the greatest threat). The potential damages also are extensive when the Secret or biometric value is stolen. Since it is difficult for an individual to remember multiple Secrets for multiple recipients, it is common for the same Secret to be used with different recipients. The theft of the Secret from one recipient thereby compromises the Sender Authentication performed by all of the recipients, at least until the Secret is changed for each recipient. In the case of the theft of a biometric value, the damages are even more severe, as a sendee’s biometric characteristic cannot be changed and, once lost, potentially compromises any future Sender Authentication therewith.

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563

Alternatively, when the Secret or biometric value is prestored and maintained within the device for User Authentication, the risks associated with safeguarding of the Secret or biometric value by the recipient and associated with transmission of the Secret or biometric value to the recipient are avoided. In this conventional paradigm, the recipient does not actually perform the verification—it is done at the device level. A drawback to this alternative paradigm, however, is that because the device remains inoperable until the correct Secret or biometric value of the user is entered, the recipient is unable to monitor repeated attempts to guess the Secret or biometric value. Furthermore, when the device is enabled by the entry of the correct Secret or a biometric value resulting in a match, the device typically remains enabled for a predefined period of time thereafter, such as until it is powered off or resets. Under this alternative paradigm, a recipient is unable to determine whether a particular EC sent during such a time period includes a fraudulently generated digital signature, as the device may have been stolen after being enabled but before its deactivation. Accordingly, while there is User Authentication under this alternative paradigm, there is no provision per se for Sender Authentication.

Yet another drawback is that this alternative paradigm does not particularly accommodate the use of the device to send ECs.to different recipients when a biometric value is prestored and maintained within—and Factor C Entity Authentication is performed by—the device, fri this regard, different recipients may have different requirements as to what constitutes a biometric “match” so as to be a successful verification; a biometric match is a determination of whether a biometric value input is sufficiently close to a stored biometric value so as to meet at least a minimum security threshold. A security threshold is subjectively set by each recipient and includes factors such as the nature of the communication and the extent of liability to the recipient for actions and responses based on a fraudulently sent EC. Different recipients cannot make their own match/no-match determinations based on their own requirements, standards, and criteria if each recipient does not receive beforehand the biometric value of the sender, make its own comparison thereof with each additional biometric value that is received in association with a message, and apply its own business judgment as to whether the comparison is sufficiently close so as to be a match.

Accordingly, a need exists for a new authentication paradigm for ECs in which Factor B Entity Authentication and/or Factor C Entity Authentication is used, but in which the aforementioned drawbacks of the conventional paradigms that use such authentication techniques are overcome. In particular, a need exists for such a paradigm that provides for both User Authentication as well as for Sender Authentication using either or both of Factor B Entity Authentication and Factor C Entity Authentication, and all without requiring a recipient to safeguard either a Secret or a biometric value. In this regard, a need exists for such a paradigm in which Factor B Entity Authentication and Factor C Entity Authentication can be reliably inferred by the recipient without the recipient being privy to the authenticating information, thereby

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 addressing privacy concerns. Furthermore, a need exists in such a paradigm for the recipient to be able to determine, in its own subjective business judgment, what constitutes a successful biometric match when Factor C Entity Authentication is used. A need also exists for such a paradigm in which the recipient is able to monitor repeated attacks on a device to guess a Secret or a biometric value, and for such an authentication paradigm that further accommodates the use of a single device for the sending of ECs to various, unrelated recipients.

Additionally, a recipient generally is unable to gauge the risk of whether a digital signature was generated fraudulently when no secret or biometric value is shared between the sender and the recipient. Instead, a recipient must rely upon blind trust in accepting that the device used to generate the digital signature has not been stolen and in accepting that the device used to generate the digital signature has sufficient safeguards to protect its private key from discovery, copying, and use in a counterfeit device. A need therefore exists for a method by which a recipient may reliably identify a risk of whether a digital signature has been generated fraudulently using a stolen private key (whether stolen by physical theft of the device or discovery of the private key itself), whereby the recipient may protect itself against fraud. In this regard, a need also exists for a method by which a recipient of an EC including a digital signature may reliably determine at any given time the current level of security of the device to which belongs the private key used to generate the digital signature. A need also exists for a method by which a recipient of an EC may reliably determine an assurance level of the device as well as the specific safeguards of such device that protect against fraudulent use thereof.

Finally, a need also exists for an alternative paradigm in which Factor B and/or Factor C Entity Authentication can be reliably inferred from information provided to a recipient by a device, the reliability of such device also being ascertainable by the recipient.

IV. Summary of the Present Invention

The present invention herein described lies in the provision of a verification status regarding entity authentication performed by a device (herein “First aspect of the Present Invention”) and, in combination therewith, the reliable identification of information regarding the device (herein “Second aspect of the Present Invention”). Moreover, each of these two aspects includes various aspects and, accordingly, various alternative preferred implementations of the present invention comprise combinations of preferred aspects of each aspect. The present invention will first be described in detail with reference to each aspect of the present invention and the various preferred aspects and alternatives thereof. The synergies and benefits of the combination of these two aspects then will be described with regard to specific implementations of the present invention.

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563

A. First aspect of the Present Invention

The First aspect of the present invention relates to the provision of a verification status regarding entity authentication performed by a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of verification data of an entity input into the device and data prestored within the device; and, independent of the verification status identified, outputting from the device an indication of the identified verification status. The prestored data represents either a Secret or biometric characteristic—or both—of the entity that is authenticated by the device. The biometric data may represent, for example, a digitized fingerprint, a digitized handprint or hand geometry, a digitized retina, a digitized iris, a digitized voice print, a digitized facial scan, a digitized written signature, or a digitized DNA sample. The device also may prestore data for a plurality of different types of verification data, whether for one person or for several persons.

In a preferred aspect of the First aspect, one of the predefined verification statuses is representative of the verification data being the same as the prestored data, and at least one other verification status is representative of the verification data being different from the prestored data. Also, neither the verification data nor the prestored data preferably is revealed by the indication of the identified verification status. In other preferred aspects, one of the predefined verification statuses represents an unsuccessful verification; one of the predefined verification statuses represents a successful verification; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period comprising, for example, the time since a last successful verification or the time since a resetting of the device.

Additionally in preferred aspects, one of the predefined verification status represents a difference between verification data input into the device and data prestored within the device; one of the predefined verification statuses represents a degree of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents a percentage of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563 the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period.

In accordance with the First aspect of the present invention, a digital signature for a message is generated within the device as a function of the identified verification status, which includes modifying within the device data representing the message as a function of the identified verification status of the device such that the generated digital signature comprises the indication of the identified verification status. The generation of the digital signature includes encrypting within the device using a private key of a public private key pair a message digest for the modified data. The digital signature is generated in response to an external inquiry received by the device, in response to receipt of data representing the message, or in response to receipt of input comprising the verification data. The message digest preferably is calculated within the device. The digital signature for the modified data thereafter is output from the device. The message itself may be for the performance of a financial transaction, for the performance of a legal action, or for access-or a request for authentication for access—to a database, physical space, web site, or computer program. The message also may be predetermined and static, and may be stored within the device itself.

The digitally signed message preferably is composed within the device and is displayed on a display screen of the device for review and approval. The message also may be composed within an I/O support element external to the device which, in turn, transmits the input representing the message into the device through an interface of the device. Alternatively, a portion of the message may be composed within an I/O support element external to the device that, in turn, transmits input representing the portion of the message into the device through an interface of the device, with a remaining portion of the message then being composed within the device. The I/O support element may comprise, for example, a point of sale terminal, a biometric scanner, a card reader, or a computer.

Verification data may be required to be input into the device for a certain type of message such as, for example, each message representing a financial transaction. Verification also may not be required to be input into the device for other types of messages, or for a predefined period of time such as the time between approval of a request embodied in a message and a powering off of the device. Verification data also may be required to be input into the device following a predefined period of time after a last successful verification.

In a preferred aspect, the device identifies a current verification status by assigning an identification marker within the device equal to a value out of a set of predefined values corresponding to the predefined verification statuses. The value may be equated with a successful verification, and may further represent whether a digital signature was generated and/or output since verification data was last input into the device. The modification of the message data preferably includes: embedding the assigned value of the identification marker within the message

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 data; appending the assigned value of the identification marker to the message data; appending the assigned value of the identification marker to the beginning of the message data; or appending the assigned value of the identification marker to the end of the message data.

The device may be capable of receiving two (or more) instances of verification data input into the device, with each instance representing the same type or a different type of verification data. In such case the function with which the message data is modified preferably comprises the steps of: comparing the first instance of verification data with the appropriate data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and, comparing the second instance of verification data with the appropriate data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values. The message data then may be modified as a function of only one of—or both of—the assigned values for the first and second comparison markers, as desired.

The First aspect of the present invention also relates to the provision of a verification status regarding an entity authentication wherein no verification data is yet received by the device. In particular, prestored data of an entity is maintained within the device for identifying a verification status of the device as a function of the prestored data and verification data later input into the device. Thereafter, a current verification status is identified within the device that represents the lack of input of any verification data during a predefined period of time. An indication of the identified verification status is then output from the device. At some point thereafter, input comprising verification data is received within the device, a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and an indication of the identified verification status is again output from the device, wherein the second indication is for the identified verification status based on the comparison.

Other aspects of the First aspect include the verification data being input directly into the device by a user; and, alternatively, input representing the verification data being received within an I/O support element external to the device and then transmitted into the device. The TO support element may include, for example, a point of sale terminal, a biometric scanner, a card reader, an ATM machine, or a computer.

In addition to the foregoing, the First aspect of the present invention also includes receiving a digital signature; decrypting the digital signature using a public key of a public-private key pair; for each one of a plurality of predefined verification statuses of the device, modifying data representing a message as a function of the predefined verification status; and identifying the current verification status of the device as being the predefined verification status for which the modified data matches the decrypted digital signature. In a variation of this aspect, a message digest is calculated as a function of the modified data following the modification. The calculation

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563 of the message digest as a function of the modified data may include the calculation of a hash value for the modified data.

B. Second aspect of the Present Invention

The Second aspect of the present invention relates to the reliable identification of information regarding the device providing the indication of the verification status. Preferably, the information permits for a determination of both a security level and an assurance level of such device. Indeed, as the device is performing Factors B and/or C Entity Authentication and then only providing an indication of the verification status identified based thereon, a recipient receiving the verification status will desire to know sufficient information about the device in order to establish some level of trust in the device and the overall system of authentication of the present invention, which is based thereon.

The present invention generally comprises the linking in a reliable manner of a public key of a device that generates digital signatures using asymmetric cryptography to other information associated with the device within an environment in which the device is manufactured and, thereafter, later identifying of the other information regarding the device after the release of the device from the manufacturing environment based upon its public key. By considering such information later identified, a recipient is able to gauge a risk or likelihood of whether a digital signature using the private key belonging to the device was generated fraudulently.

As used herein, the “other information” comprises at least one of security aspects and manufacturing history of the device, and preferably includes both security aspects and manufacturing history of the device (herein collectively referred to as “Security Profile”). As described above, the security aspects include those aspects that safeguard the private key (and other protected data) within the device from discovery (herein referred to as “security characteristics”), those aspects that perform either or both of Factors B and C Entity Authentication with regard to authentication of the user of the device (herein referred to as “authentication capabilities”), and aspects that otherwise serve to provide security to the device. It is important to know the security aspects of a device—rather than simply a stated security level of the device—as technologies are developed over time that reduce the effectiveness of such security aspects and, consequently, result in the decrease of the actual security level of the device. Unless upgrades are made, the security aspects of a device are permanent while the security level of the device eventually will decrease over time. By knowing the security aspects, the appropriate security level of a device may be determined at any given time. Furthermore, by knowing the security characteristics of the device, a recipient is able to gauge a likelihood of whether the private key of the device has been compromised, and by knowing the authentication capabilities of the device (or lack thereof), a recipient is able to gauge a likelihood of whether someone other than the authorized user utilized the device to generate a digital signature.

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563

The “manufacturing history” of the device includes attributes of the manufacture of the device, preferably including: the manufacturer of the device; all specifications applicable to the device; manufacture date of the device; location of manufacture; batch identifier of the device; serial number or part number of the device; security of the manufacturing facility; physical instantiation of the device regarding layout and process geometry; software identification and release date; operating parameters of the device, including voltage and frequency ranges; identification of all enabled hardware and software security aspects of the device; cryptography characteristics of the device; random number generator characteristics of the device; and key generation characteristics of the device. The manufacturing history enables one to gauge an assurance level of the device. By knowing the manufacturing history of a device, the security aspects of the device may be revised as errors, omissions, flaws, security breaches, or possible improprieties and the like are discovered as having occurred during the manufacturing of the device.

The environment of manufacture preferably comprises a “secure environment,” i.e., an environment having a sufficient security rating at least as comparable to the security level of each device manufactured therein. By manufacturing each device in a secure environment, the security level of each device manufactured in such environment is not compromised.

The “linking” of the public key to the other information of a device comprises the recording of the information of the device in one or more databases maintained within the secure environment (herein collectively “secure database”) in association with the public key of the device, whereby the other information is retrievable from the secure database based on the public key. Preferably, the other information is indexed or mapped in the secure database to the public key of the device to which the information relates. Moreover, since each public key is unique—at least to a high degree of probability—the mapping in the secure database is one-to-one. Alternatively, the public key and Security Profile may be indexed to a unique identifier—such as a serial number of the device—within the secure database. The linking of the public key to the other information of a device also may comprise the combining of the public key with the other information into a record and then the digital signing of the record in the secure environment by a trusted entity using a private key of the trusted entity. The record and digital signature together form a “Security Certificate,” which then is imported into the device during its manufacture. The digital signing of the record by the trusted entity in the secure environment reliably links the public key of the manufactured device to the other information.

In accordance with preferred aspects of the Second aspect of the present invention, the device is manufactured in a secure environment (i.e., an environment having a sufficient security rating so as not to compromise the security level of any device manufactured in such environment). Furthermore, the information linked with the public key of the device comprises the Security Profile of the device. Accordingly, the recipient is able to determine a current security

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 level of the device based on the identified security aspects of the device. The recipient also is able to gauge a risk of whether the private key of the device was compromised based on the identified security characteristics of the device, and the recipient is able to gauge a risk of whether the device containing the private key was fraudulently used based on the identified authentication capabilities of the device. Finally, the recipient is able to evaluate the stated security aspects of the device based upon the identified manufacturing history of the device.

Preferably, before a manufactured device is removed from the secure environment, a public-private key pair is created within the device and the public key is exported and linked to the Security Profile of the device within the secure database. In particular, one of the keys—the public key—is recorded in the secure database by the device manufacturer or other trustworthy entity (“Secure Entity”), and the other key—the private key—is preferably retained within the manufactured device and safeguarded against discovery. The public key also is retained within the device and is exportable upon demand. The Security Profile of the manufactured device is recorded in the secure database, and the record therefor is indexed or mapped to the corresponding public key, thereby reliably linking together both the public key and Security Profile of the device. In this case, the unique identifier is stored within the device and is exportable upon demand. Moreover, since each public key is unique—at least to a high degree of probability—the mapping in the secure database is one-to-one. Alternatively, the public key and Security Profile are indexed to a unique identifier of the device within the secure database, thereby reliably linking together the public key and Security Profile of the device, whereby an assurance level of the device may be determined.

Subsequently, when an EC is received by a recipient that includes a digital signature generated by a suspect device and the message is authenticated utilizing a suspect public key, the recipient identifies the Security Profile linked to the suspect public key as pertaining to the actual manufactured device to which belongs the private key used to generate the digital signature of the EC (herein “genuine device”). Then, whether the digital signature was generated fraudulently can be gauged by the recipient based upon the known Security Profile for the genuine device. Specifically, the risk of whether the private key retained within the manufactured device has been compromised—and thus whether the suspect device is the genuine device—can be gauged based on the identified security characteristics of the genuine device, and the risk of whether the genuine device has been fraudulently used can be gauged based on the identified authentication capabilities of the genuine device. These evaluations also can be qualified based on the identified manufacturing history of the device, as appropriate, by determining an assurance level of the device.

In alternative preferred aspects of the Second aspect, a public-private key pair is created and the public key of the device is linked to the Security Profile of the device by combining the public key with the Security Profile into a record that then is digitally signed by the Secure Entity

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563 to form a Security Certificate of the respective device, which also is imported into the device. The digital signing of the record by the Secure Entity in the secure environment reliably links the Security Profile of the manufactured device and its public key. Subsequently, when a digital signature is generated by the device for inclusion in an EC, the Security Certificate also is included in the EC. Upon receipt and successful authentication of the message using the suspect public key set forth in the Security Certificate, the recipient authenticates the Security Certificate in the EC utilizing a public key of the Secure Entity. Upon successful authentication thereof, the recipient reliably identifies the Security Profile of the genuine device to which belongs the private key used in generating the digital signature of the EC. Then, whether the digital signature was generated fraudulently can be gauged by the recipient based upon the known Security Profile for the genuine device. Specifically, the risk of whether the private key retained within the manufactured device has been compromised—and thus whether the suspect device is the genuine device—can be gauged based on the identified security characteristics of the genuine device, and the risk of whether the genuine device has been fraudulently used can be gauged based on the identified authentication capabilities of the genuine device. These evaluations also can be qualified based on the identified manufacturing history of the device, as appropriate.

Additional aspects of both the First and Second aspects of the present invention include: a device with a computer-readable medium having computer-executable instructions that perform one or more steps of a method of the present invention; a device with an integrated circuitry that performs one or more steps of a method of the present invention; and a device with a computer chip that performs one or more steps of a method of the present invention.

V. Brief Description of the Drawings

Benefits and further aspects of the present invention will be apparent from a detailed description of preferred implementations thereof taken in conjunction with the following drawings, wherein like reference numbers refer to like elements, and wherein:

Fig. 1 illustrates a prior art Certification Authority Digital Certificate (CADS) system;

Fig. 2a illustrates a first preferred implementation of the first aspect of the present invention;

Fig. 2b illustrates a variation of the implementation of Fig. 2a;

Fig. 2c illustrates a variation of the implementation of Fig. 2a;

Fig. 3 illustrates a preferred mode of operation of the device of Figs. 2a, 2b, and 2c;

Fig. 4a illustrates a second preferred implementation of the first aspect of the present invention;

Fig. 4b illustrates a variation of the implementation of Fig. 4a;

Fig. 4c illustrates a variation of the implementation of Fig. 4a;

Fig. 5 illustrates a preferred mode of operation of the device of Figs. 4a, 4b, and 4c;

CA 02417770 2003-02-03

WO 02/13444

PCT/US01/24563

Fig. 6a illustrates a third preferred implementation of the first aspect of the present invention;

Fig. 6b illustrates a variation of the implementation of Fig. 6a;

Fig. 6c illustrates a variation of the implementation of Fig. 6a;

Fig. 7 illustrates a preferred mode of operation of the device of Figs. 6a, 6b, and 6c;

Fig. 8a illustrates a fourth preferred implementation of the first aspect of the present invention; ‘

Fig. 8b illustrates a variation of the implementation of Fig. 8a;

Fig. 8c illustrates a variation of the implementation of Fig. 8a;

Fig. 9 illustrates a preferred mode of operation of the device of Figs. 8a, 8b, and 8c;

Figs. 10a, 10b, and 10c illustrate preferred formats of prestored data of the first aspect of the present invention;

Figs. 11a, lib, and 11c illustrate preferred formats of verification data of the first aspect of the present invention;

Fig. 12 illustrates a preferred comparison and verification status identification process;

Figs. 13a and 13b illustrate preferred comparison and verification status identification processes of the first aspect of the present invention;

Fig. 14 illustrates a preferred comparison and verification status identification process of the first aspect of the present invention;

Figs. 15a and 15b illustrate preferred formats of identification markers of the first aspect of the present invention;

Fig. 16 illustrates preferred formats of identification markers of the first aspect of the present invention;

Fig. 17 illustrates a table of identification markers resulting from a hypothetical sequence of verification data inputs in accordance with the first aspect of the present invention;

Fig. 18 illustrates a preferred data flowchart within an implementation of the first aspect of the present invention using a computer chip;

Fig. 19 illustrates a first specific implementation of the first aspect of the present invention using an IC card;

Fig. 20 illustrates a second specific implementation of the first aspect of the present invention using an IC card;

Fig. 21 illustrates a third specific implementation of the first aspect of the present invention using an IC card;

Figs. 22a and 22b illustrate fourth and fifth specific implementations of the first aspect of the present invention using an IC card;

Fig. 23 illustrates a sixth specific implementation of the first aspect of the present invention using an IC card;

CA 02417770 2003-02-03

WO 02/13444 PCI7US01/24563

Fig. 24 illustrates use of an EC for session authentication and transaction authentication purposes in accordance with the first aspect of the present invention;

Fig. 25 illustrates use of an EC for transaction confirmation purposes in accordance with the first aspect of the present invention; and

Fig. 26 illustrates a preferred system in which a first preferred implementation of the second aspect of the present invention is practiced;

Fig. 27 illustrates a flowchart of steps performed within a secure environment in accordance with the first preferred implementation of the second aspect of the present invention;

Fig. 28 illustrates a communication sequence in identifying a Security Profile of a device in accordance with the first preferred implementation of the second aspect of the present invention;

Fig. 29 illustrates a flowchart of steps performed by a suspect device originating a digital signature in an EC in accordance with the first preferred implementation of the second aspect of the present invention;

Fig. 30 illustrates a flowchart of steps performed by a recipient in accordance with the first preferred implementation of the second aspect of the present invention;

Fig. 31 illustrates a flowchart of steps performed by a Secure Entity in accordance with the first preferred implementation of the second aspect of the present invention;

Fig. 32 illustrates a flowchart of steps performed within the secure environment in accordance with a second preferred implementation of the second aspect of the present invention;

Fig. 33 illustrates a communication sequence in identifying a Security Profile of a device in accordance with the second preferred implementation of the second aspect of the present invention;

Fig. 34 illustrates a flowchart of steps performed by a suspect device originating a digital signature in an EC in accordance with the second preferred implementation of the second aspect of the present invention;

Fig. 35 illustrates a flowchart of steps performed by a recipient in accordance with the second preferred implementation of the second aspect of the present invention;

Fig. 36 illustrates a flowchart of steps performed by a Secure Entity in accordance with the second preferred implementation of the second aspect of the present invention;

Fig. 37 illustrates a flowchart of steps performed within the secure environment in accordance with a third preferred implementation of the second aspect of the present invention;

Fig. 38 illustrates a communication sequence in identifying a Security Profile of a device in accordance with the third preferred implementation of the second aspect of the present invention;

Fig. 39 illustrates a flowchart of steps performed by a suspect device originating a digital signature in an EC in accordance with the third preferred implementation of the second aspect of the present invention;

CA 02417770 2003-02-03

WO 02/13444

PCI7US01/24563

Fig. 40 illustrates a flowchart of steps performed by a recipient in accordance with the third preferred implementation of the second aspect of the present invention;

Fig. 41 illustrates a flowchart of steps performed by a Secure Entity in accordance with the third preferred implementation of the second aspect of the present invention;

Fig. 42 illustrates a system related to the second aspect of the present invention in which a third-party provides goods and/or services to customers and maintains a customer account database in conjunction therewith;

Fig. 43 illustrates a preferred system in which a preferred implementation of the second aspect of the present invention is practiced;

Fig. 44 illustrates database records of an initial PuK-linked account database in accordance with the preferred implementation of the second aspect of the present invention;

Fig. 45 illustrates a PuK-linked account database of customers comprising the database records of Fig. 44 after having been updated and/or merged by the third-party representing an Internet service provider;

Fig. 46 illustrates a PuK-linked account database of customers comprising the database records of Fig. 44 after having been updated and/or merged by the third-party representing a financial institution;

Fig. 47 illustrates a preferred system in which a preferred implementation of the third aspect of the present invention is practiced;

Fig. 48 illustrates an established PuK-linked account database of customers of a thirdparty representing a financial institution in accordance with a preferred implementation of a fifth aspect of the present invention;

Fig. 49 illustrates a flow chart for considering whether to perform a transaction on an account in accordance with a preferred implementation of the fifth aspect of the present invention;

Fig. 50 illustrates an account database of a Central Key Authority in accordance with a sixth aspect of the present invention;

Fig. 51 illustrates a communication sequence in accordance with a preferred implementation of the sixth aspect of the present invention;

Fig. 52 illustrates a flowchart of steps performed by a user in accordance with the preferred implementation of the sixth aspect of the present invention of Fig. 51;

Fig. 53 illustrates a flowchart of steps performed by a Central Key Authority in accordance with the preferred implementation of the sixth aspect of the present invention of Fig. 51;

Fig. 54 illustrates a flowchart of steps performed by a first Account Authority in accordance with the preferred implementation of the sixth aspect of the present invention of Fig. 51;

CA 02417770 2003-02-03

WO 02/13444 PCT/US01/24563

Fig. 55 illustrates a flowchart of steps performed by a second Account Authority in accordance with the preferred implementation of the sixth aspect of the present invention of Fig. 51;

Fig. 56 illustrates a business application in accordance with a preferred embodiment of the present invention;

Fig. 57 illustrates a flowchart of steps performed by both an account holder and merchant (intermediate party) in the business application of Fig. 56; and

Fig. 58 illustrates a flowchart of steps performed by an account authority in the business application of Fig. 56.

VI. Detailed Description of Preferred Embodiments

As a preliminary matter, it readily will be understood by those persons skilled in the art that, in view of the following detailed description of the devices, systems, and methods of the present invention, the present invention is susceptible of broad utility and application. Many implementations and adaptations of the present invention other than those herein described, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the following detailed description thereof, without departing from the substance or scope of the present invention. Furthermore, those of ordinary skill in the art will understand and appreciate that although steps of various processes may be shown and described in some instances as being carried out in a preferred sequence or temporal order, the steps of such processes are not necessarily to be limited to being carried out in such particular sequence or order. Rather, in many instances the steps of processes described herein may be carried out in various different sequences and orders, while still falling within the scope of the present invention. Accordingly, while the present invention is described herein in detail in relation to preferred implementations, it is to be understood that this detailed description only is illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the present invention. The detailed description set forth herein is not intended nor is to be construed to limit the present invention or otherwise to exclude any such other implementations, adaptations, variations, modifications and equivalent arrangements of the present invention, the present invention being limited solely by the claims appended hereto and the equivalents thereof.