REGISTER  |  SIGN IN
United States Patent5805719
Pare, Jr. , ; et al.September 8, 1998
Title
Tokenless identification of individuals
Abstract
A tokenless identification system and method for authorization of transactions and transmissions. The tokenless system and method are principally based on a correlative comparison of a unique biometrics sample, such as a finger print or voice recording, gathered directly from the person of an unknown user, with an authenticated biometrics sample of the same type obtained and stored previously. The system can be networked to act as a full or partial intermediary between other independent computer systems, or may be the sole computer systems carrying out all necessary executions. The system further contemplates the use of a private code that is returned to the user after the identification has been complete, authenticating and indicating to the user that the computer system was accessed. The identification system and method additionally include emergency notification device to permit an authorized user to alert authorities an access attempt is coerced.
Inventors:Pare, Jr.; David Ferrin (Berkeley, CA), Hoffman; Ned  (Berkeley, CA), Lee; Jonathan Alexander  (Berkeley, CA)
Assignee:SmartTouch (Berkeley, CA)
Appl. No.:820008
Filed:March 18, 1997
Current U.S. Class:382/115 382/224 
Field of Search:340/825.34,825.33,825.31 395/244,241,243 380/21,24 902/26,1,2,3,4,5,6,8,9,10,12,13,22,23,24,25,27 235/380,375,376,379,381,382,383,382.5,384,385,386 382/115,116,117,118,119,124,128,181,190,209
U.S. Patent Documents
4821118April 1989Lafreniere
4837422June 1989Dethloff et al.
4961142October 1990Elliott et al.
4993068February 1991Piosenka et al.
4995086February 1991Lilley et al.
4998279March 1991Weiss
5036461July 1991Elliott et al.
5054089October 1991Uchida et al.
5095194March 1992Barbanell
5109427April 1992Yang
5109428April 1992Igaki et al.
5144680September 1992Kobayashi et al.
5146102September 1992Higuchi et al.
5168520December 1992Weiss
5180901January 1993Hiramatsu
5191611March 1993Lang
5210588May 1993Lee
5210797May 1993Usui et al.
5222152June 1993Fishbine et al.
5229764July 1993Matchett et al.
5230025July 1993Fisfbine et al.
5239583August 1993Parrillo
5241606August 1993Horie
5251259October 1993Mosley
5265162November 1993Bush et al.
5276314January 1994Martino et al.
5280527January 1994Gullman et al.
5321242June 1994Heath, Jr.
5325442June 1994Knapp
5335288August 1994Faulkner
5343529August 1994Goldfine et al.
5351303September 1994Willmore
Other References
Security Management V 37, n11 (Nov. 1993):17-19 Anderson, et al., American Society for Industrial Security 1993, "Security Works", Senior Editor, Harowitz (Address-Security Management, 1655 N. Ft. Myer Dr., Suite 1200, Arlington, VA 22204)..~
Primary Examiner: Boudreau; Leo
Assistant Examiner: Tadayon; Bijan
Attorney, Agent or Firm:Kamarei; Ali
Parent Case Text


CROSS-REFERENCE

The present application is a continuation-in-part of U.S. patent application Ser. No. 08/442,895, filed May 17, 1995, which is now U.S. Pat. No. 5,613,012, which is a continuation-in-part of U.S. patent application Ser. No. 08/345,523, filed Nov. 28, 1994, now U.S. Pat. No. 5,615,277, incorporated herein by reference.
Claims

What is claimed is:
1. A tokenless method for rapid search of previously stored biometric samples from individuals using at least two biometric baskets, at least one biometric basket containing at least two algorithmically unique biometric samples from different individuals, each biometric basket containing less than the total number of samples registered with the system, and each biometric basket being identified by a personal identification code, the method comprising;
a. a storage step further comprising:
i. gathering a biometric sample from an individual;
ii. selecting a personal identification code that indexes a biometric basket;
iii. locating the biometric basket identified by the personal identification code;
iv. comparing the biometric sample gathered from said individual, with all previously stored biometric samples in the biometric basket, to make sure that the biometric sample gathered from the individual is algorithmically unique from all biometric samples currently stored in said biometric basket for producing a successful or failed uniqueness result; and
v. upon return of a successful uniqueness result, storing of the entered biometric sample gathered from said individual in the selected biometric basket; and
b. a bid step further comprising:
i. entering a bid personal identification code by a candidate individual;
ii. entering a bid biometric sample by said candidate individual; and
c. a comparison step further comprising:
i. locating the biometric basket that is identified by the bid personal identification code entered by said candidate individual; and
ii. comparison of the bid biometric sample from said candidate individual with all of the biometric samples stored in the identified biometric basket for producing either a successful or failed identification result.
Description
BACKGROUND

The use of tokens and credit cards in today's financial world is pervasive. A token would be any inanimate object which confers a capability to the individual presenting the object. Remote access of every financial account is through the use of tokens or plastic cards. Whether buying groceries with debit cards or consumer goods with credit cards, at the heart of that transaction is a money transfer enabled by a token, which acts to identify an individual and the financial account he is accessing.

The reason for the migration from metal coins to plastic cards is simple and straightforward: access to money in this money transfer system is vastly safer and more convenient for both merchants and consumers than handling large quantities of coins and notes.

Unfortunately, current technology in combination with this convenient token-based money transfer system results in a system that is prone to theft and fraud.

As verification of user identity is based solely on data placed on the token, which can be easily reproduced and transferred between individuals, such security must rely on both the diligence and the luck of the authorized user and merchant in maintaining this information as proprietary. However, by their very nature, tokens do not have a very strong connection with the individual. Identification of the rightful owner of the token through the token is tenuous at best. This is easily demonstrated by the fact that individuals other than the rightful owners of the tokens have been using these tokens to defraud merchants and other consumer goods suppliers.

The mammoth expansion of the consumer credit industry during the 1980s brought with it large profits for issuers, and newfound convenience for consumers. However, as consumer credit became easier for consumers to acquire, it also became a target for criminals. Much as the mobility of the automobile led to a rash of bank robberies in the late 1920's and early 1930's, so too did the ubiquity of consumer credit lead to vastly increased opportunities for criminals.

Initially, the banking industry was willing to accept a certain amount of loss due to fraud, passing the cost on to the consumer. However, as criminals became more organized, more technically adept, and as credit retail stations began to be manned by people who were more and more poorly trained in credit card security matters, the rate of increase of fraud losses skyrocketed. The staggering statistics on fraud and cost of preventive steps, has forced the credit card companies in particular, to look for other solutions to the problem.

Fraud losses in the credit card industry stem from many different areas due to the highly vulnerable nature of the system, but they are mainly due to either lost, stolen, or counterfeit cards. Credit cards operate without the use of a personal identification code (PIC), therefore a lost credit card can be turned into cash if the card falls into the wrong hands. While theft of a token constitutes the majority of fraud in the system, the use of counterfeit credit cards has been on the rise. Counterfeit credit cards are manufactured by a more technically sophisticated criminal by acquiring a cardholder's valid account number and then producing a counterfeit card using that valid number. The counterfeiter encodes the magnetic strip, and embosses the counterfeit plastic card with the account number. The card is then presented to merchants and charged up to the rightful cardholder's account. Another form of loss is by a criminal merchant who surreptitiously obtains the cardholder's account number. Yet another type of fraud is committed by the authorized cardholder when the token is used for making purchases and thereafter a claim is made that the token was either lost or stolen. It is estimated that losses due to all types of fraud exceeds $950 million dollars annually.

Generally, debit cards are used in conjunction with a personal identification code (PIC). Counterfeiting a debit card is more difficult as the criminal must acquire not only the account number, but also the PIC, and then manufacture the card as in the credit card example. However, various strategies have been used to obtain PICs from unwary cardholders; these range from Trojan horse automated teller machines, or ATMs, in shopping malls that dispense cash but record the PIC, to merchant point of sale devices that also record the PIC, to individuals with binoculars that watch cardholders enter PICs at ATMs. The subsequently manufactured counterfeit debit cards are then used in various ATM machines until the unlucky account is emptied.

The financial industry is well aware of the trends in fraud expense, and is constantly taking steps to improve the security of the card. Thus fraud and theft of token have an indirect impact on the cost to the system.

Card blanks are manufactured under very tight security. Then they are individualized with the account number, expiration date, and are then mailed to the cardholder. Manufacturing and distributing the card alone costs the industry approximately one billion dollars annually. The standard card costs the financial industry $2 for each, but only $0.30 of this $2 is associated with actual manufacturing cost.

Over the last ten years, the industry has altered the tokens because of counterfeiting fraud, without any fundamental changes in the use of the credit transaction system. The remedy has been mostly administrative changes such as having customers call the issuer to activate their card. Other changes include addition of a hologram, a picture ID, or an improved signature area. These type of changes in particular, are an indication that the systems susceptibility to fraud is due to lack of true identification of the individual. It is estimated that this could double the manufacturing cost to two billion dollars annually.

In the near future, the banking industry expects to move to an even more expensive card, called a "smart card". Smart cards contain as much computing power as did some of the first home computers. Current cost projections for a first-generation smart card is estimated at approximately $3.50, not including distribution costs, which is significantly higher than the $0.30 plastic card blank.

This significant increase in cost has forced the industry to look for new ways of using the power in the smart card in addition to simple transaction authorization. It is envisioned that in addition to storing credit and debit account numbers, smart cards may also store phone numbers, frequent flyer miles, coupons obtained from stores, a transaction history, electronic cash usable at tollbooths and on public transit systems, as well as the customer's name, vital statistics, and perhaps even medical records. Clearly, the financial industry trend is to further establish use of tokens.

The side effect of increasing the capabilities of the smart card is centralization of functions. The flip side of increased functionality is increased vulnerability. Given the number of functions that the smart card will be performing, the loss or damage of this monster card will be excruciatingly inconvenient for the cardholder. Being without such a card will financially incapacitate the cardholder until it is replaced. Additionally, losing a card full of electronic cash will also result in a real financial loss as well. Furthermore, ability of counterfeiters to one day copy a smartcard is not addressed.

Unfortunately, because of the projected concentration of functions onto the smart card, the cardholder is left more vulnerable to the loss or destruction of the card itself Thus, after spending vast sums of money, the resulting system will be more secure, but threatens to levy heavier and heavier penalties for destruction or loss of this card on the consumer.

The financial industry recognizes the security issues associated with smartcards, and efforts are currently underway to make each plastic card difficult to counterfeit. Billions of dollars will be spent in the next five years in attempts to make plastic ever more secure. To date, the consumer financial transaction industry has had a simple equation to balance: in order to reduce fraud, the cost of the card must increase.

In addition to and associated with the pervasiveness of electronic financial transactions, there is now the widespread use of electronic facsimiles, electronic mail messages and similar electronic communications. Similar to the problem of lack of proper identification of individuals for financial transactions is the problem of lack of proper identification of individuals for electronic transmissions. The ease and speed of electronic communication, and its low cost compared to conventional mail, has made it a method of choice for communication between individuals and businesses alike. This type of communication has expanded greatly and is expected to continue to expand. However, millions of electronic messages such as facsimiles and electronic mail (or "E-mail" or "email") messages are sent without knowing whether they arrive at their true destination or whether a certain individual actually sent or received that electronic message. Furthermore, there is no way to verify the identify the individual who sent or who received an electronic message.

Recently, various attempts have been made to overcome problems inherent in the token and code security system. One major focus has been to encrypt, variablize or otherwise modify the PIC to make it more difficult for an unauthorized user to carry out more than one transaction, largely by focusing on manipulation of the PIC to make such code more fraud resistant. A variety of approaches have been suggested, such as introducing an algorithm that varies the PIC in a predictable way known only to the user, thereby requiring a different PIC code for each subsequent accessing of an account. For example, the PIC code can be varied and made specific to the calendar day or date of the access attempt. In yet another approach, a time-variable element is introduced to generate a non-predictable personal identification code that is revealed only to an authorized user at the time of access. Although more resistant to fraud that systems incorporating non-variable codes, such an approach is not virtually fraud-proof because it still relies on data that is not uniquely and irreproducibly personal to the authorized user. Furthermore, such systems further inconvenience consumers that already have trouble remembering constant codes, much less variable ones. Examples of these approaches are disclosed in U.S. Pat. Nos. 4,837,422 to Dethloff et al.; 4,998,279 to Weiss; 5,168,520 to Weiss; 5,251,259 to Mosley; 5,239,538 to Parrillo; 5,276,314 to Martino et al.; and 5,343,529 to Goldfine et al. all of which are incorporated herein by reference.

More recently, some have turned their attention from the use of personal identification codes to the use of unique biometrics as the basis of identity verification, and ultimately computer access. In this approach, authenticated biometrics are recorded from a user of known identity and stored for future reference on a token. In every subsequent access attempt, the user is required to enter physically the requested biometrics, which are then compared to the authenticated biometrics on the token to determine if the two match in order to verify user identity. Because the biometrics are uniquely personal to the user and because the act of physically entering the biometrics are virtually irreproducible, a match is putative of actual identity, thereby decreasing the risk of fraud. Various biometrics have been suggested, such as finger prints, hand prints, voice prints, retinal images, handwriting samples and the like. However, because the biometrics are generally stored in electronic (and thus reproducible) form on a token and because the comparison and verification process is not isolated from the hardware and software directly used by the individual attempting access, a significant risk of fraudulent access still exists. Examples of this approach to system security are described in U.S. Pat. Nos. 4,821,118 to Lafreniere; 4,993,068 to Piosenka et al.; 4,995,086 to Lilley et al.; 5,054,089 to Uchida et al.; 5,095,194 to Barbanell; 5,109,427 to Yang; 5,109,428 to Igaki et al.; 5,144,680 to Kobayashi et al.; 5,146,102 to Higuchi et al.; 5,180,901 to Hiramatsu; 5,210,588 to Lee; 5,210,797 to Usui et al.; 5,222,152 to Fishbine et al.; 5,230,025 to Fishbine et al.; 5,241,606 to Horie; 5,265,162 to Bush et al.; 5,321,242 to Heath, Jr.; 5,325,442 to Knapp; 5,351,303 to Willmore, all of which are incorporated herein by reference.

As will be appreciated from the foregoing discussion, a dynamic but unavoidable tension arises in attempting to design a security system that is highly fraud resistant, but nevertheless easy and convenient for the consumer to use. Unfortunately, none of the above-disclosed proposed improvements to the token and code system adequately address, much less attempt to balance, this tension. Such systems generally store the authenticated biometrics in electronic form directly on the token that can presumably be copied. Further, such systems do not adequately isolate the identity verification process from tampering by someone attempting to gain unauthorized access.

An example of token-based security system which relies on a biometrics of a user can be found in U.S. Pat. No. 5,280,527 to Gullman et al. In Gullman's system, the user must carry and present a credit card sized token (referred to as a biometrics security apparatus) containing a microchip in which is recorded characteristics of the authorized user's voice. In order to initiate the access procedure, the user must insert the token into a terminal such as an ATM, and then speak into the terminal to provide a biometrics input for comparison with an authenticated input stored in the microchip of the presented token. The process of identity verification is generally not isolated from potential tampering by one attempting unauthorized access. If a match is found, the remote terminal may then signal the host computer that access should be permitted, or may prompt the user for an additional code, such as a PIN (also stored on the token), before sending the necessary verification signal to the host computer.

Although Gullman's reliance of comparison of stored and input biometrics potentially reduces the risk of unauthorized access as compared to numeric codes, Gullman's use of the token as the repository for the authenticating data combined with Gullman's failure to isolate the identity verification process from the possibility of tampering greatly diminishes any improvement to fraud resistance resulting from the replacement of a numeric code with a biometrics. Further, the system remains somewhat cumbersome and inconvenient to use because it too requires the presentation of a token in order to initiate an access request.

Almost uniformly, patents that disclose token-based systems teach away from biometrics recognition without the use of tokens. Reasons cited for such teachings range from storage requirements for biometrics recognition systems to significant time lapses in identification of a large number of individuals, even for the most powerful computers.

In view of the foregoing, there has long been a need for a computer access system that is highly fraud-resistant, practical, and efficient for the user to operate and carry out electronic transactions and transmissions expeditiously.

There is also a need for a computer system that is completely tokenless and that is capable of verifying a user's personal identity, based solely upon a personal identification code and biometrics that is unique and physically personal to an authorized user, as opposed to verifying an individual's possession of any physical objects that can be freely transferred between different individuals. Such biometrics must be easily and non-intrusively obtained; must be easy and cost-effective to store and to analyze; and must not unduly invade the user's privacy rights.

A further need in computer access system design is user convenience. It is highly desirable for a consumer to able to access the system spontaneously, particularly when unexpected needs arise, with a minimum of effort. In particular, there is a need for a system that greatly reduces or eliminates the need to memorize numerous or cumbersome codes, and that eliminates the need to possess, carry, and present a proprietary object in order to initiate an access request.

Such systems must be simple to operate, accurate and reliable. There is also a need for a computer access system that can allow a user to access multiple accounts and procure all services authorized to the user, and carry out transactions in and between all financial accounts, make point of purchase payments, receive various services, etc.

There is further a great need for a computer access system that affords an authorized user the ability to alert authorities that a third party is coercing the user to request access without the third party being aware that an alert has been generated. There is also a need for a system that is nevertheless able to effect, unknown to the coercing third party, temporary restrictions on the types and amounts of transactions that can be undertaken once access is granted.

Furthermore, the computer system must be affordable and flexible enough to be operatively compatible with existing networks having a variety of electronic transaction and transmission devices and system configurations.

Finally, there is a need for secured sending and receipt of electronic mail messages and electronic facsimiles, where content of the electronic message is protected from disclosure to unauthorized individuals, and the identity of the sender or recipient can be obtained with a high degree of certainty.

SUMMARY OF THE INVENTION

The present invention satisfies these needs by providing an improved identification system for determining an individual's identity from a comparison of an individual's biometrics sample and personal identification code gathered during a bid step with biometrics sample and personal identification code for that individual gathered during a registration step and stored at a remote site wherein there is a data processing center. The invention comprises a computer network host system with means for comparing the entered biometrics sample and personal identification code, and is equipped with various data bases and memory modules. Furthermore, the invention is provided with biometrics and personal identification code input apparatus and terminals for entering data to provide information for execution of the requested transactions and transmissions by the host system once the identity of the individual is determined. The invention is also provided with means for connecting the host system with the terminal and the biometrics input apparatus.

The computer also has means for execution of various transactions and transmission in addition to traditional storing of and modification of data. Additionally, the computer can output the evaluation of the biometrics-PIC ("personal identification code") comparison, and the determination of an identification evaluation, or status of any execution of transactions or transmissions. Furthermore, the computer system notifies and authenticates to the individual being identified that the computer system was accessed, by returning to the individual a private code which was previously selected by that individual during the registration step.

Preferably, the computer system is protected from electronic eavesdropping and electronic intrusion and viruses. Further, the devices used by the computer for gathering biometric samples and personal identification codes would comprise: a) at least one biometric input device for gathering biometric samples, which would have a hardware and a software component; b) at least one terminal device that is functionally partially or fully integrated with the biometric input means for input of and appending ancillary information; c) at least one data entry device for input of a personal identification code whereby this data entry device is integrated either with the biometric input device or the terminal device; and, d) a means for interconnecting the biometric input device, data entry device and the terminal. The terminal device also has at least one display device for displaying data and information. For additional security the computer system uniquely identifies the biometric input apparatus, and the counter party or merchant through a counter party or merchant identification code relating to the terminal that is connected to the biometric input device. It is also preferred that the biometric input apparatus be secured from physical and electronic tampering, and that in case of physical breach of the device, means be employed to physically and/or electronically destroy components within the apparatus and/or erase critical data from the device's memory modules.

In addition, the biometric input apparatus would have a hardware component comprising: a) at least one computing module for data processing; b) erasable and non-erasable memory modules for storage of data and software; c) a biometric scanner device for input of biometric data; d) a data entry device for entering data; e) a digital communications port; f) a device for prevention of electronic eavesdropping.

In order to protect the integrity and confidentiality of electronic data sent between the biometric input apparatus, the terminal, and the computer network, it is preferred that the data be encrypted and sealed.

The host computer network is also connected to and is able to communicate with other independent computer systems, databases, facsimile machines, and other computer networks through conventional means.

The method of the present invention includes voluntarily identifying an individual without the use of any tokens by means of examination of at least one biometrics sample provided by that the individual and a personal identification code also provided by that individual. During a registration step, the individual is to register with the system an authenticated biometric sample, a personal identification code and a private code. Thereafter, during a bid step the biometrics sample and personal identification code of the individual is gathered and compared to the ones registered during the registration step. A match of the personal identification codes and biometrics sample will result in the positive identification of the individual. In order to authenticate to the identified individual that the real computer system was accessed, the individual's private code, which was collected at the registration step, is returned to the individual.

It is preferred that the method of the invention include a method for examining the biometrics samples during registration and comparing such biometrics with a collection of biometrics samples from individuals who have been designated as having previously attempted to perpetrate or who have actually perpetrated fraud upon the system.

In a preferred embodiment, the invention includes a method for notifying authorities of the presence of exigent circumstances or that the authorized user is under duress.

It is also preferred that a method of encryption and sealing of data be used to protect the data, including the digitized biometrics sample, from being revealed accidentally or unveiled from criminal elements during transmission.

It is also preferred that the method include steps for the individual to choose various financial accounts, and choose various modes of electronic transmissions.

It is also preferred that the method include a method for archiving of data and electronic transmissions, and retrieval of the archived data using a tracking code.

It is furthermore preferred that any document, such as a facsimile or an electronic mail message be uniquely checksummed using algorithm for future identification of the document.

Yet another method of the invention is to be able to rapidly identify an individual from an examination of his biometrics sample and personal identification code by storing several dissimilar biometrics samples from different individuals in an electronic basket that is identified by one personal identification code.

In one embodiment of the invention, the computer system can allow individuals to select their own personal identification code (or "PIC") from a group of PICs selected by the remote data processing center. This is performed in a method whereby once the individual's biometric is gathered, the data processing center selects several PICs at random which may be condusive to being memorized. The data processing center then conducts a comparison of the biometric gathered with those already in those PIC baskets or groups. In the event the new registrant's biometric is to similar to any previously registered biometric which has been allotted to any one of those randomly selected PIC groups, then that PIC is rejected by the database for use by the new individual and an alternative PIC is selected for another such biometric comparison. Once the data processing center has generated several PIC options without a confusingly similar biometric, those PICs are presented to the new registrant from which the individual may select one PIC.

In another embodiment of the invention, there is a method for rapid search of previously stored biometric samples from individuals using at least two biometric baskets, at least one biometric basket containing at least two algorithmically unique biometric samples from different individuals. Each biometric basket contains less than the total number of samples registered with the system, and each biometric basket is identified by a personal identification code (a biometric basket code). The method comprises a storage step further comprising gathering a biometric from an individual; selecting a personal identification code that indexes a biometric basket; a) the selection of a private code by a first individual; locating the biometric basket identified by the personal identification code; comparing the biometric sample gathered from said individual with all previously stored biometric samples in the biometric basket to make sure that the biometric sample gathered from the individual is algorithmically unique from all biometric samples currently stored in said biometric basket, for producing a successful or failed uniqueness result. Upon return of a successful uniqueness result, the gathered biometric sample is stored in the selected biometric basket. There is a bid step further comprising: a) entering a bid personal identification code by a candidate individual, and; b) entering a bid biometric sample by said candidate individual. There is also a comparison step comprising: a) locating the biometric basket that is identified by the personal identification code entered by said candidate individual, and; b) comparison of the bid biometric sample from said candidate individual with all of the biometric samples stored in the identified biometric basket for producing either a successful or failed identification result.

According to one embodiment of the invention, the host system is positioned in series between the individual being identified and other computer networks that are to be accessed, thereby acting as an interface. It will be appreciated that in this embodiment, the user tenders an access request directly to the host computer system of the invention, which is operationally interactive with other independent secured computer systems such as VISANET. The computer system would therefore maintain authenticated biometrics data samples for all authorized users of each secured computer system that it services. These data would be cross-referenced by each authorized user. Thus, after identity verification is completed, the security system provides to the user a listing of systems that he is authorized to access, and prompts the user to select the desired network. Thereafter, the requested execution step and information regarding the transaction is forwarded to the selected independent computer network similar to the type of communications sent today between merchants and credit card companies.

In a second embodiment the host system may also carry out the functions of the other independent computer systems such as debiting or crediting a financial account. In this system, the computer system of the invention carries out the functions requested by the individual without use of external, independent computer networks.

According to a further embodiment of the invention, a means is provided for alerting predesignated authorities during an access attempt during which the user has been coerced by a third party to request access to the host computer system. In such an embodiment, an authorized user would have a number of codes, most of which would be recognized by the computer system as the standard access codes, and others which would be recognized as emergency codes. The comparison means of the computer system of the invention would be configured to accept and recognize at least one code per authorized user, and to activate the emergency alert means whenever the code entered by the user matched an emergency code. At the same time, the determination of an authorized identity for the user would result in the user being afforded access to the requested secured computer system perhaps on an access level that has been predetermined to be restricted or perhaps resulting in the display of misleading data (i.e., "false screens"), thereby preventing the coercing third party from knowing that an emergency notification had been entered by the user. The emergency code would be entered as a part of or simultaneously with the user's personal identification code or by selecting an emergency account index during the access of the computer system. In either case, the well-being of the user requesting access might be jeopardized if the coercing party discovered that the user was attempting to notify authorities. Thus, it is critical that the access procedure continue uninterruptedly and that access be granted to an authorized user so that the coercing party believes that everything is proceeding normally. Although these features can be incorporated into the invention's host computer network, it is also possible that an independent computer network can also carry out the same or modified versions of the above-mentioned features.

The present invention is clearly advantageous over the prior art in a number of ways. First, it is extremely easy and efficient for the user, particularly where the user is accessing financial accounts, because it eliminates the need to carry and present any tokens in order to access one's accounts. The present invention eliminates all the inconveniences associated with carrying, safeguarding and locating any desired tokens. Further, because tokens are often specific to a particular computer system that further requires remembering a secret code assigned to the particular token, this invention eliminates all such tokens and thereby significantly reduces the amount of memorization and diligence increasingly required of consumers by providing access to all assets using only one personal identification code. Thus, in a single, tokenless transaction, the consumer can efficiently and securely conduct virtually any commercial exchange or electronic message, from withdrawing cash from a bank account, to authorization his agreement to the terms of a contract, to making a purchase directly from television, to paying local property taxes. The consumer is now uniquely empowered, by means of this invention, to conveniently conduct his personal and/or professional electronic transmissions and transactions at any time without dependance upon tokens which may be stolen, lost or damaged.

The invention is clearly advantageous from a convenience standpoint to retailers and financial institutions by making purchases and other financial transactions less cumbersome and more spontaneous. The paper work of financial transactions is significantly reduced as compared to current systems, such as credit card purchase wherein separate receipts are generated for use by the credit card company, the merchant and the consumer. Such electronic transactions also save merchants and banks considerable time and expense by greatly reducing operational costs. Because the system of the invention is designed to provide a consumer with simultaneous direct access to all of his financial accounts, the need for transactions involving money, checks, commercial paper and the like will be greatly reduced, thereby reducing the cost of equipment and staff required to collect and account for such transactions. Further, the substantial manufacturing and distributing costs of issuing and reissuing credit cards, ATM cards, calling cards and the like will be eliminated, thereby providing further economic savings to merchants, banks, and ultimately to consumers. In fact, the system of the invention will likely spur economic growth since all of a consumer's electronic financial resources will be available at the mere input of his fingerprint or other biometrics.

The invention is markedly advantageous and superior to existing systems in being highly fraud resistant. As discussed above, present computer systems are inherently unreliable because they base determination of a user's identity on the physical presentation of a unique manufactured object along with, in some cases, information that the user knows. Unfortunately, both the token and information can be transferred to another, through loss, theft or by voluntary action of the authorized user. Thus, unless the loss or unintended transfer of these items is realized and reported by the authorized user, anyone possessing such items will be recognized by existing security systems as the authorized user to whom that token and information is assigned.

By contrast, the present invention virtually eliminates the risk of granting access to non-authorized users by determining user identity from an analysis of one or more of a user's unique, biometrics characteristics. Even in the very rare circumstance of coersion, where an authorized individual is coerced by a coercing party to access his accounts, the system anticipates an emergency account index, whereby the authorized user can alert authorities of the transgression without the knowledge of the coercing party.

The invention further enhances fraud resistance by maintaining authenticating data and carrying out the identity verification operations at a point in the system that is operationally isolated from the user requesting access, thereby preventing the user from acquiring copies of the authenticating data or from tampering with the verification process. Such a system is clearly superior to existing token-based systems wherein authenticating information, such as personal codes, is stored on and can be recovered from the token, and wherein the actual identity determination is potentially in operational contact with the user during the access process.

It is an object of the invention therefore to provide a computer access identification system that eliminates the need for a user to possess and present a physical object, such as a token, in order to initiate a system access request.

It is another object of the invention to provide a computer access identification system that is capable of verifying a user's identity, as opposed to verifying possession of proprietary objects and information.

It is yet another object of the invention to verify user identity based upon one or more unique characteristics physically personal to the user.

Yet another object of the invention is to provide a system of secured access that is practical, convenient, and easy use.

Still another object of the invention is to provide a system of secured access to a computer system that is highly resistant to fraudulent access attempts by non-authorized users.

Yet another object of the invention is to provide a computer access identification system that enables a user to notify authorities that a particular access request is being coerced by a third party without giving notice to said third party of the notification.

There is also a need for a computer access identification system that automatically restricts a user's transactional capabilities on the computer system according a desired configuration provided by the user.

These and other advantages of the invention will become more fully apparent when the following detailed description of the invention is read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of the system of the present invention;

FIG. 2 is a diagram of the Data Processing Center (DPC) and its internal data bases and execution modules;

FIG. 3 is a diagram of the retail point of sale terminal, the biometrics input apparatus and its components, and the interconnections between them;

FIG. 4 is a flow chart of the operation of the biometrics input apparatus and the terminal for generating a request packet;

FIG. 5 is a representational diagram of the request packet and the mandatory and optional data it contains;

FIG. 6 is a representational diagram of the response packet and the mandatory and optional data it contains;

FIG. 7 is a flow chart depicting the data encryption and sealing process at the biometrics input device;

FIG. 8 is a flow chart depicting the data decryption and counter party identification process at the DPC;

FIG. 9 is a flow chart depicting the data encryption and sealing process at the DPC;

FIG. 10 is a flow chart representing the registration of an individual during the registration process;

FIG. 11 is a flow chart representing the process of identification of the individual and returning a private code to the individual;

FIG. 12 is a flow chart of the skeleton of the processes that occur at the DPC and an execution step;

FIG. 13 is a flow chart of the emergency request and response process at the DPC;

FIG. 14 is a flow chart of the overall operation of retail transaction authorization execution at the DPC;

FIG. 15 is a flow chart of the overall operation of remote transaction authorization execution step at the DPC;

FIG. 16 is a flow chart of the overall operation of ATM account access execution at the DPC;

FIG. 17 is a flow chart of the overall operation of issuer batch modification execution at the DPC;

FIG. 18 is a flow chart of the overall operation of secure fax submit and electronic document submit execution at the DPC;

FIG. 19 is a flow chart of the overall operation of secure fax data and electronic document data execution at the DPC;

FIG. 20A is a representational diagram of the electronic signature request packet;

FIG. 20B is a representational diagram of the electronic signature response packet;

FIG. 20C is a representational diagram of the electronic signature verification request packet;

FIG. 20D is a representational diagram of the electronic signature verification request packet;

FIG. 21 is a flow chart of the overall operation of electronic signature execution at the DPC; and

FIG. 22 is a flow chart of the overall operation of electronic signature verification execution at the DPC.

DETAILED DESCRIPTION OF THE INVENTION

As noted, the main objective of this invention is to provide a tokenless, secure, reliable, safe, and consistent, apparatus and method, for identifying individuals for the purpose of performing financial transactions and non-financial transmissions, which can accommodate large numbers of users. It is the essence of this invention that consumers have the ability to conduct these transactions without the use of any tokens, credit cards, badges or identification cards including drivers licenses. In order to be functional it is important that the system operate at speeds required for completing financial transactions such as credit card purchases and ATM services, from multiple banks and credit accounts. The system must be secure, such that individuals records and their biometrics information remain confidential and safe, both within the computer system that identifies the individual and authorizes transactions, or during transfer of data between the computer system and remote sites with which the computer system communicates. Furthermore, the system must be reliable in that errors in identification and authorization must not hamper or make use of the system cumbersome. Since only the use of biometrics are contemplated for identification of individuals, the system must also have security measures to either reduce access, even to the authorized user, or notify authorities in emergency cases. It is appreciated that the system must be able to handle a large number of users, and accommodate storage and transfer of large amounts of data, such as bio-characteristic information, commensurate with speeds at which financial transactions are carried on today.

Turning now to the figures, the overall configuration of the invention and its components are shown in FIG. 1. Essentially a Data Processing Center (DPC) 1 is connected to various terminals 2 through various type of communication means 3 which can be one of several types. The DPC is also connected and communicates with independent computer networks 4. The DPC contains several data bases and software execution modules as shown in FIG. 2. In a preferred embodiment of the invention, the data bases are backed up or "mirrored" for safety reasons. The Firewall Machine 5 is responsible for prevention of electronic intrusion of the system while the Gateway Machine 6 is responsible for carrying out all requests from the user, including adding, deleting and otherwise modifying all data bases. The Gateway Machine is also responsible for decryption and de-packaging of data that has arrived from the terminals using the MACM module 7, MDM module 8, and the SNM module 9. The PGL module 10, and the IML module 11 are used to locate the proper personal identification code and biometrics sample basket. FIG. 3 depicts an example of a terminal and the biometrics input device 12, which has a biometrics scanner 13, data entry means such as a key pad or PIN pad 14, and a display panel 15. The biometrics scanner can be any one of finger print scanner, voice recognition, palm print scanner, retinal scanner or the like, although the fingerprint scanner will be used as an example. The biometrics input device is further equipped with computing modules 16, device drivers, and erasable and non-erasable memory modules. The biometrics input device communicates with the terminal through preferably a serial port 17. The terminal 2 communicates through a conventional modem 18 with the DPC 1 through request packets 19 and response packets 20 using one of the interconnecting means in FIG. 1 such as cable network, cellular telephone networks, telephone networks, Internet, ATM network, or X.25. FIG. 4 shows a representational diagram of the request packet 19 and its method of generation by the biometrics input device software. FIG. 5 and FIG. 6 show a representational diagram of the request packet and response packet with optional and mandatory data segments. Furthermore, it is shown which parts of the packets are encrypted and which ones are sealed. FIG. 7 is a block diagram of the overall process for data encryption and sealing showing the use of DUKPT key data 20 for encryption of data before appending additional data before sealing the request packet with a Message Authentication Code Key (MAC) 21. FIG. 8 and FIG. 9 show the decryption and encryption process at the DPC. FIG. 12 through 19 and 21 through 22 are block diagrams of selected examples of execution steps carried on at the DPC.

Description of the drawings, diagrams, flow charts and the description of the invention, including hardware components, software components, execution modules, data bases, connection means, the data transferred between them, and the method of the invention is described in detail as follows.

1.1. Biometric Input Apparatus (BIA)

1.1.1. Introduction

The BIA is a combination of hardware and software whose job is to gather, encode, and encrypt biometric input for use in individual identification. All actions of the BIA are directed by an outside controlling entity called a terminal, which issues commands and receives results over the BIA's serial line.

BIA hardware comes in four basic versions: standard, wireless, integrated phone/cable television (or "CATV")/fax, and ATM. Each BIA hardware variant addresses a particular need in the marketplace, and because of the differences in construction, each variant has a different level of security.

BIA software comes in seven basic versions: personal computer (or "PC"), retail, ATM, registration, internal, issuer, and integrated remote. Each software load provides a different, use-specific command set. For instance, the registration software load does not accept requests to form retail transaction messages. Likewise, the retail software command set cannot send individual registration messages. To provide another layer of security, the DPC knows what software package is loaded into each BIA; any attempts by an BIA to send a message that it is normally not able to send is rejected, and treated as a major security violation.

The ability of the invention to detect and combat merchant-based fraud relies on the fact that the BIA's external interface is strictly limited, that the construction of the BIA makes it extremely difficult to tamper with the contents, that each BIA has its unique encryption codes that are known only to the DPC, and that each BIA is only allowed to perform operations limited to its designated function. Each biometric input means has a hardware identification code previously registered with the DPC, which makes the biometric input means uniquely identifiable to the DPC in each subsequent transmission from that biometric input device.

The BIA is constructed with the assumption that the controlling terminal is a source for fraud and deception. Terminals range from software applications running on personal computers to dedicated hardware/software systems developed for a particular use such as a retail point of sale. Regardless of the particular model, no BIA reveals unencrypted biometric information. BIA models without display means (such as LCD, LED, or quartz screens) must reveal selected information (such as individual private codes) to the terminal for display, and as a result those particular terminal-BIA combinations are considered to be less secure.

Depending on the task at hand, BIA models are either partially or fully integrated with the terminal. Partially integrated devices are physically separate from the terminal, and they include wireless and standard retail point of sale BIAs. Fully integrated devices are contained within the physical enclosure of the terminal itself, for instance, an ATM, or a telephone.

No BIA ever discloses any secret encryption codes to any external source.

1.1.2. BIA Models

Particular BIA hardware models have different configurations. They are introduced in brief here:

BIA

Standard model has computing module (i.e., multichip modules), biometric scanner (i.e., single fingerprint scanner), display means (i.e., LCD screen), communications port (i.e., serial port), data entry means (i.e., a manual data entry key board or PIC pad) encased in tamper-resistant case, and electronic detection means (i.e., RF shielding).

BIA/Wireless

Standard model, but serial line replaced with spread-spectrum wireless communications module using external antenna. Used in restaurant point of sale.

BIA/ATM

Has heavy-duty scanner and serial port, along with a multichip module. The fact that the LCD is part of the terminal and not the BIA means lower security because it must reveal the private code to the terminal. Used in ATMs.

BIA/Catv

Has light-duty scanner, otherwise like ATM. Used in telephones, CATV remotes, and fax machines. Weakest security, both because the LCD and PIC pad are part of the terminal not the BIA, and because of the low-cost nature of the market.

1.1.3. BIA Command Set Messages

Each BIA software command set provides a different set of operations. They are introduced briefly here:

BIA/ATM

Account Access

BIA/Catv

Remote Transaction Authorization

BIA/Fax

Secure Fax Submit

Secure Fax Data

Secure Fax Tracking

Secure Fax Retrieve

Secure Fax Reject

Secure Fax Archive

Secure Fax Contract Accept

Secure Fax Contract Reject

Electronic Document Archive Retrieve

BIA/Internal

Individual Identification

BIA/Issuer

Issuer Batch

BIA/PC

Electronic Document Submit

Electronic Document Data

Electronic Document Tracking

Electronic Document Retrieve

Electronic Document Reject

Electronic Document Archive

Electronic Document Archive Retrieve

Electronic Signature Submission

Electronic Signature Check

Remote Transaction Authorization

Network Credential

Secured Connection

BIA/Registration

Individual Identification

Biometric Registration

BIA/Retail

Transaction Authorization

1.1.4. BIA Hardware: Standard Model

The Standard BIA hardware is a multichip module combined with a single-print scanner, an LCD screen, a serial port, and a PIC pad encased in a hard tamper-resistant case that makes attempts to penetrate obvious while also providing RF shielding for the contents.

The following components are amalgamated into a multichip module, called the BIA Multichip Module (a process for encapsulating several processors in one physical shell, well known in the industry), constructed to protect the communications pathways between the devices from easy wiretapping.

Serial processor

PIC pad processor

LCD screen processor

CCD scanner A/D processor

High-speed DSP processor containing both flash and mask ROM

General purpose microprocessor

Standard RAM

EEPROM

The following software packages and data are stored in mask ROM. Mask ROM is cheaper than other types of read only memory, but it is easily reverse engineered, and is not electronically erasable. As such we only place the noncritical commonly available code here. (Mask ROM is well known in the industry).

MAC calculation library

DUKPT Key Management library

DES (with CBC) Encryption library

Base-64 (8-bit to printable ASCII) converter library

Public Key Encryption library

Embedded Operating System

Serial line device driver

LCD device driver

PIC pad device driver

Scanner device driver

Unique hardware identification code

Multi-Language profiles

The following standard data and software packages are stored in flash ROM. Flash ROM is more expensive, but it is much more difficult to reverse engineer, and most importantly, it is electronically erasable. All of the more critical information is stored here. Flash ROM is used in an attempt to increase the difficulty of duplicating an BIA. (Flash ROM is well known in the industry).

Unique DUKPT Future Key Table

Unique 112-bit MAC Key

DSP biometric quality determination algorithm

DSP biometric encoding algorithm

Random number generator algorithm

Command function table

The message sequence number, incremented each time a message is sent from the BIA, is stored in the EEPROM. EEPROM can be erased many times, but is also nonvolatile--its contents remain valid across power interruptions. (EEPROM is well known in the industry).

The following data is stored in RAM. RAM is temporary in nature, and is lost whenever power is lost.

Encoded Biometric Register

PIC Register

Account Index Code Register

Title Index Code Register

Amount Register

Document Name Register

PIC-Block Key

Message Key

Response Key

Shared Session Key

Private Session Key

8 General Registers

stack and heap space

Each multichip module contains a "write-once" memory location that is irreversibly set following the initialization of the flash ROM. Whenever an attempt is made to download software to the flash ROM, this memory location is checked; if it is already been set, then the BIA refuses to load. This way, critical software and data keys may only be downloaded once into the device, at the time of manufacture.

All registers and keys are explicitly zeroed when a transaction is canceled. Once a transaction is completed, registers are cleared as well. Once a "form message" command is executed, biometric, PIC, and account index code registers are also cleared, along with any encryption keys that aren't required for subsequent use.

It is important that the software not keep copies of registers or keys in stack variables (known in the industry).

The following associated hardware components comprise the standard BIA hardware module.

BIA Multichip module

CCD single-print scanner

capacitance detector plate (known in the industry)

lighted PIC keypad

2-line 40-column LCD screen

RF shielding

tamper-resistant case

serial connection (up to 57.6 kb)

breech detection hardware (known in the industry)

optional thermite charge attached to Multichip module (known in the industry)

All temporary storage and internal hardware and software used to calculate these values are secured, which means they resist any attempts to determine their current values, or their means of functioning. This feature is essential for the security of the invention, just as it is critical that the "wiretapping" of an BIA and specifically the gathering of a Biometric-PIC Block for fraudulent means is made as difficult as possible.

The multichip module and the components are, where practical, physically connected to each other without exposed wiring being present.

The enclosure protecting the electronic components of the BIA is welded shut during manufacture; it cannot be opened under any circumstances without significant damage to the case. Upon detecting any opening (or damage) of the enclosure, the BIA performs an emergency electronic zero of any and all keys residing in flash ROM, followed by all of the software libraries. Specific breech detection methods are kept confidential and proprietary.

In addition to protecting the contents, the case also shields the internal operations from RF signal detectors.

Supersecure versions of the BIA exist whereby breech mechanism methods are connected to a mechanism that physically destroys the multichip module as well as the detection methods themselves.

1.1.5. BIA Hardware: Wireless Model

The Wireless version of BIA hardware is identical to the Standard model in construction, except that it exports a spread-spectrum wireless communications module using an external antenna instead of an external serial port.

This version is designed to be used in restaurants, where transactions are authorized at the customer's convenience.

In the following descriptions, items which are added to the standard set are signified by the + character, while items that are removed from the standard set are signified by the - character.

Multichip Module

Document Name Register

Shared Session Key

Private Session Key

Message Key

Components

Serial port

External antenna

Spread-spectrum wireless serial module (known in the industry)

1.1.6. BIA Hardware: ATM Model

The ATM version of BIA hardware is a multichip module combined with a heavy-duty single-print scanner and a serial port. The components are encased in a tamper-resistant case that makes attempts to penetrate obvious while also providing RF shielding for the contents.

This version is designed to be retrofitted into ATM locations. As such, the scanner pad is a heavy-duty sensor pad, and the entire construction makes use of the existing screens and keypads present in the ATM itself.

In the following descriptions, items which are added to the standard set are signified by the + character, while items that are removed from the standard set are signified by the - character.

Multichip Module

Amount Register

Document Name Register

Shared Session Key

Private Session Key

Message Key Components:

lighted PIC keypad

2-line 40-column LCD screen

Note that since the ATM has no LCD screen or PIC keypad, it really has no need of those device drivers in the mask ROM.

1.1.7. BIA Hardware: Phone/CA TV Model

The Phone/CATV version of BIA hardware is a multichip module combined with a single-print scanner and a serial port. The module is physically attached to the scanner, and the whole is encased in plastic in order to make tampering more difficult. Some amount of RF shielding is provided for the components.

This version is designed to be integrated with telephones, television remote controls, and fax machines. As a result, it makes use of the existing keypads and LCD or television screens to enter or display values. It also uses the communication facilities of the host terminal. For example, the fax machine uses the built-in fax modem and the television remote uses the CATV cable network.

This hardware model is (in comparison with other models) relatively insecure, as it is intended that these devices cost as little as possible, be lightweight, and integrate easily with existing low-cost devices.

Of course, higher-security versions with more complete enclosures are possible and encouraged.

In the following descriptions, items which are added to the standard set are signified by the + character, while items that are removed from the standard set are signified by the - character.

Multichip Module

Document Name Register

Shared Session Key

Private Session Key

Message Key

Components

lighted PIC keypad

2-line 40-column LCD screen

1.2. BIA Software

1.2.1. BIA Software Command Interface

The external interface to the BIA is much like a standard modem; commands are sent to it from a controlling terminal using the external serial line. When a command completes, a response code is sent from the BIA to the terminal.

Each BIA software load supports a different set of operations. For instance, a retail load supports only transaction authorizations, while a registration load supports individual identification and biometric registration.

All BIA data fields are in printable ASCII, with fields separated by fs control characters, and records separated by newlines. Encrypted fields are binary converted to 64-bit ASCII using the base-64 conversion library (all known in the industry).

Some commands are not available in some configurations. For instance, the ATM BIA cannot "Get PIC", since there is no attached PIC pad. Instead, the ATM BIA supports a "Set PIC" command.

1.2.1.1 Response Codes

Out of time:

The time allotted for the command has expired. A message to that effect will be displayed on the LCD screen, if available. When time expires for a given command, the BIA acts as if the cancel button was pushed.

Canceled:

The "cancel" button has been pushed, and the entire operation has been canceled. This has the side effect of clearing all information which was gathered. A message to that effect will be displayed on the LCD screen, if available.

Ok:

The command was successful.

Other:

Each command may have specific other response codes which are valid only for it. These response codes will generally have text accompanying the code, which will be displayed on the LCD screen if it is available.

Message:

This indicates that the command is ongoing, but that the BIA wants to send a message to the terminal with an interim result message. The result is also displayed on the LCD, if available. This facility is used for prompts, as well as status messages.

1.2.1.2 Commands

In the argument list of the commands below, the < > characters surround individual arguments, [ ] characters surround optional arguments, and the .vertline. character indicates that a given argument may be comprised of one of the choices presented.

Set Language <language-name>

This command selects from one of a number of different languages encoded within the BIA for prompting for user input.

Get Biometric <time> [primary.vertline.secondary]

This command requests the BIA to activate its scanner to get biometric input from the individual, storing it into the Encoded Biometric Register.

First, the message "Please place finger on lighted panel" is displayed on the LCD panel and returned to the terminal. The scanner pad is illuminated, prompting the individual to enter his biometric.

A <time> value of zero means that there is no limit to the time for biometric scan input.

When in scanning mode, a fingerprint scan is taken and given a preliminary analysis by the print quality algorithm. If the scan is not good enough, the BIA continues to take new scans until <time> seconds pass. As time passes and snapshots of the print are taken and analyzed, messages are posted to the LCD screen and sent to the terminal based on the problems detected by the print quality software. If no print of appropriate quality is forthcoming, the BIA returns an error code of time expired, displaying a message to that effect on the LCD.

Once the print quality algorithm affirms the quality of the print scan, the print's minutiae are then extracted by the print encoding algorithm. Only a subset of the minutiae are selected at random, with care taken to retain enough sufficient for identification. These minutiae are then ordered randomly, and are placed in the Encoded Biometric Register. Then the BIA responds with the success result code.

If the [primary.vertline.secondary] is specified (only available in the biometric registration command set) then the entire minutiae set is selected, not just the smaller subset. Likewise, primary/secondary biometric selection ends up placing the encoded biometric into the appropriate register.

Whether or not the operation succeeds, as soon as scanning has terminated, the light indicating that scanning is in progress is turned off.

It is very important that the same biometric input yields different encodings, so as to complicate the task of anyone attempting to discover the encryption codes of a captured BIA. This is accomplished by the selection of a random subset and random ordering of the encoded biometric.

Get PIC <time>

This command requests the BIA to fill the PIC Register by reading from the keypad.

First, the message "Please enter your PIC, then press <enter>" is displayed on the LCD display and sent to the terminal, the appropriate keypad lights are turned on, and then keypad scanning begins.

Scanning terminates when either <time> number of seconds runs out, or when the individual hits the "enter" key.

Note that the individual digits of the PIC are not displayed on the LCD panel, but for each digit the individual types, a star "*" appears to give the individual feedback. When the "correction" key is pressed, the last digit entered is erased, allowing the individual to fix input mistakes.

When PIC input terminates, the keypad lights turns off.

If successful, the command returns OK.

Get Account Index Code <time>

First, the message "Now enter your account index code, then press <enter>" is displayed on the LCD and sent to the terminal. This prompts the individual to enter his account index code. When each key is pressed, that value appears on the LCD panel. The correction button can be pressed to erase one of the values. When the "enter" button is pressed, the Account index code register is set.

During input, the appropriate keypad keys are lit, and when input is concluded, the keypad lights are turned off.

If successful, the command returns OK.

Get Title Index Code <time>

First, the message "Please enter your title index code, then press <enter>" is displayed on the LCD and sent to the terminal. This prompts the individual to enter his title index code. When each key is pressed, that value appears on the LCD panel. The correction button can be pressed to erase one of the values. When the "enter" button is pressed, the Title Index Code register is set.

During input, the appropriate keypad keys are lit, and when input is concluded, the keypad lights are turned off.

If successful, the command returns OK.

Validate Amount <amount> <time>

The Validate Amount command sends the message "Amount <amount> OK?" to the terminal, and displays it on the LCD screen. If the individual confirms the amount by hitting the "yes" (or enter) button, the Amount Register is set to <amount>. The <amount> value must be a valid number, with no control characters or spaces, etc. During prompting, the yes, no, and cancel buttons are lit. Once prompting is complete, all the lights are turned off.

If the individual enters "no", then the transaction is canceled.

Enter Amount <time>

The Enter Amount command sends the message "Enter amount" to the terminal, and also displays it on the LCD screen as well. The individual must then enter the dollar amount himself Each character entered is displayed on the LCD screen. All appropriate buttons are lit. If the enter button is hit, the Amount Register is set to be the value entered on the keyboard. Once entry is complete, all the lights are turned off.

Validate Document <name> <time>

The Validate Document command sends the message "Document <name> OK?" to the terminal, and displays it on the LCD screen as well. If the individual confirms the document by hitting the "yes" (or enter) button, the Document Name Register is set to <name>. The <name> must be printable ASCII, with no control characters, and no leading or trailing spaces. During prompting, the yes, no, and cancel buttons are lit. Once prompting is complete, all the lights are turned off.

If the individual enters "no", the transaction is canceled.

Assign Register <register> <text>

The assign register command sets the designated General <register> to have the value <text>. This is used to set information such as the merchant code, the product information, and so on.

Get Message Key

The Get Message Key command causes the BIA to generate a 56-bit random key to be used by the controlling hardware to encrypt any message body that the controlling device wishes to add to the message. That generated key is returned by the BIA in hexadecimal format (known in the industry). The message key are then added to the biometric-PIC block.

Form Message <type=identification.vertline.transaction.vertline.account access . . . >

The form message command instructs the BIA to output a message containing all the information it has gathered. It also checks to make sure that all the registers appropriate to that specific message <type> have been set. If all required registers are not set, the BIA returns with an error. The specific command set software will determine which messages can be formed by that BIA model; all others will be rejected.

Each message includes a transmission code consisting of the BIA's unique hardware identification code and an incrementing sequence number. The transmission code allows the DPC to identify the sending BIA and to detect resubmission attacks.

The BIA uses the DUKPT key management system to select the biometric-PIC block encryption 56-bit DES key from the Future Key Table. This key is then used to encrypt the Biometric-PIC Block using cipher block chaining (CBC). In addition, a response DES key is also generated randomly, and is used by the DPC to encrypt the portions of the response that need to be encrypted.

Note: splitting the response key from the biometric-PIC block key is very important, since each encryption key must be used only within the context of its own responsibilities. That way, if someone were to break the key encoding the private code, it would not result in the disclosure of the biometric-PIC.

The Biometric-PIC block consists of the following fields:

300-byte authorization biometric

4-12 digit PIC

56-bit response key

[optional 56-bit message key]

Note that the message key is only present if the controlling terminal has requested a message key for this message. It is up to the controlling terminal to encrypt any message body attached to the transaction authorization request using the message key.

Once all encryption is complete, the BIA outputs the body of the appropriate request message (such as a Transaction Authorization Request message), terminated by and protected with the Message Authentication Code (MAC).

The MAC field is calculated using the BIA's secret 112-bit DES MAC key, and covers all message fields from first to last. The MAC assures the DPC that nothing in the message has changed effectively sealing the message, while still allowing the plaintext fields to be inspected by the controlling terminal.

When the Form Message command is done, the BIA sends the message "I'm talking to DPC Central" to the terminal as well as displaying it on the LCD screen, indicating that work is proceeding on the request.

The command returns OK in addition to returning the entire formed message upon completion of the command.

Show Response <encrypted response> <time>

The Show Response command instructs the BIA to use its current Response Key to decrypt the private code from the system.

After decryption, a chime sounds, and the private code is displayed on the LCD screen for <time> seconds. At no time does this command transmit the decrypted private code to the controlling terminal.

Validate Private <encrypted validation> <time>

This command is used by a terminal during a secure network communications session to ask the individual to validate a message from an outside source. The message comes encrypted and in two parts: the challenge, and the response.

Upon receipt of a Validate Private command, the BIA displays the text of the challenge message as in "OK <challenge>?" on the LCD screen, but does not send this to the terminal. When the individual validates the challenge, the response is encrypted by the BIA using the Private Session Key, and then returned to the terminal along with the OK response code. If the individual does not validate the challenge, then the BIA returns with a "failed" response code, along with the text "transaction canceled at your request," which is also displayed on the LCD screen.

Note that the terminal is never allowed to see the plaintext of either the challenge or the response.

Reset

The Reset command instructs the BIA to clear all temporary registers, the LCD screen, all temporary Key registers, and to turn off all keypad lights that may be on.

Set PIC <value>

This command assigns the BIA's PIC Register to be <value>.

Note that allowing a non-secured device to provide the PIC is a potential security problem, because non-secured devices are much more vulnerable to wiretapping or replacement.

Set Account index code <value>

This command assigns the BIA's Account index code Register to be <value>.

Note that allowing a non-secured device to provide the account index code is a potential security problem, because non-secured devices are much more vulnerable to wiretapping or replacement.

Set Title Index Code <value>

This command assigns the BIA's Title Index Code Register to be <value>.

Note that allowing a non-secured device to provide the Title Index Code is a potential security problem, because non-secured devices are much more vulnerable to wiretapping or replacement.

Set Amount <value>

This command assigns the BIA's Amount Register to be <value>.

Decrypt Response <encrypted response message>

The Decrypt Response command instructs the BIA to use it's current Response Key to decrypt the encrypted portion of the response message. Once decrypted, the response is returned to the controlling device, presumably for display on the ATM terminal's LED screen.

Note that providing this decryption ability is a security problem, as once the plaintext leaves the BIA, the terminal has the ability to do with it what it will.

1.2.2. BIA Software: Support Libraries

The BIA software is supported by several different software libraries. Some of them are standard, generally available libraries, but some have special requirements in the context of the BIA.

1.2.2.1. Random Number Generator

Since the BIA is constantly selecting random DES keys for use in the message body and message response encryption, it is important that the keys selected be unpredictable keys. If the random number generator is based on time of day, or on some other externally-predictable mechanism, then the encryption keys will be much more easily guessed by an adversary that happens to know the algorithm. In order to assure the security of the encryption techniques used in the BIA, it is assumed that both the random number generator algorithm as well as the encryption algorithms are both publicly known.

A standard random number algorithm for generating DES keys is defined in ANSI X9.17, appendix C (known in the industry).

1.2.2.2. DSP Biometric Encoding Algorithms

The biometric encoding algorithm is a proprietary algorithm for locating the minutiae that are formed by ridge endings and bifurcations on human fingertips. A complete list of minutiae is stored in the DPC as a reference, while only a partial list is required by the algorithm when performing a comparison between an identification candidate and a registered individual.

During both biometric registration as well as identification, the encoding algorithm ensures that enough minutiae are found before ending the biometric input step.

1.2.2.3. Operating System and Device Drivers

The BIA is a realtime computing environment, and as such requires a realtime embedded operating system to run it. The operating system is responsible for taking interrupts from devices and scheduling tasks.

Each device driver is responsible for the interface between the operating system and the specific hardware, such as the PIC pad device driver, or the CCD Scanner device driver. Hardware is the source for events such as "PIC pad key pressed", or "CCD Scanner scan complete". The device driver handles such interrupts, interprets the events, and then takes action on the events.

1.2.2.4. DES Encryption Library

There are any number of DES implementations publicly available. DES implementations provide a secret key-based encryption from plaintext to ciphertext, and decryption from ciphertext to plaintext, using 56-bit secret keys.

1.2.2.5. Public Key Encryption Library

Public Key encryption support libraries are available from Public Key Partners, holders of the RSA public key patent (known in the industry). Public Key cryptosystems are asymmetric encryption systems that allow communication to take place without requiring a costly exchange of secret keys. To use a public key encryption system, a public key is used to encrypt a DES key, and then the DES key is used to encrypt a message. The BIA uses public key cryptosystems to provide for the secure exchange of secret keys.

Unfortunately, public key systems are significantly less well tested than secret-key systems, and as such there is an overall lower level of confidence in such algorithms. As a result, the invention uses public key cryptography for communications security and short-lived credential exchange, and not long-term storage of secrets. Both the end-user individual and the bank are identified by the DPC to create the network credential. The network credential includes the end-user individual's identification as well as the context of the connection (i.e., the TCP/IP source and destination ports).

1.2.2.6. DUKPT Key Management Library

The derived unique key per transaction key (DUKPT) management library is used to create future DES keys given an initial key and a message sequence number. Future keys are stored in a Future Key Table. Once used, a given key is cleared from the table. Initial keys are only used to generate the initial future key table. Therefore the initial key is not stored by the BIA

The use of DUKPT is designed to create a key management mechanism that provided a different DES key for each transaction, without leaving behind the trace of the initial key. The implications of this are that even successful capture and dissection of a given future key table does not reveal messages that were previously sent, a very important goal when the effective lifetime of the information transmitted is decades. DUKPT is fully specified in ANSI X9.24 (known in the industry).

DUKPT was originally developed to support PIC encryption mechanisms for debit card transactions. In this environment, it was critical to protect all transactions. An assumption is made that a criminal records encrypted transactions for a six month period, and then captures and successfully extracts the encryption code from the PIC pad. The criminal could then manufacture one new counterfeit debit card for each message that had been transmitted over that six month period. Under DUKPT, however, the criminal's theft and dissection would not allow him to decrypt previous messages (although new messages would still be decryptable if the criminal were to replace the PIC pad subsequent to dissection).

In the biometric-PIC situation, the criminal has an even harder time, as even if messages are decrypted, turning a digital biometric-PIC into a physical fingerprint is much harder than turning an account number-PIC into a plastic card, which is one of the significant benefits of the tokenless system.

Still, if a criminal can decrypt, he can encrypt, which might allow him to electronically submit a biometric-PIC to the system to authorize a fraudulent transaction. While this is quite difficult, it is still best to restrict the options available to the criminal as much as possible, hence the use of DUKPT.

1.3. BIA Software Command Sets

1.3.1. BIA Software: Retail Command Set

The BIA/Retail software interface exports an interface that allows specific retail point of sale terminals to interact with the system.

The BIA/Retail interface is designed to allow the terminal to perform the following operation:

Transaction Authorization

In order to implement those operations, the BIA/Retail provides the following command set:

Set Language <language-name>

Get Biometric <time>

Get PIC <time>

Assign Register <register> <value>

Get Account index code <time>

Validate Amount <amount> <time>

Enter Amount <time>

Form Message <type>

Show Response <encrypted response> <time>

Reset

1.3.2. BIA Software: CATV (Integrated Remote) Command Set

The BIA/CATV software interface exports a command set that allows terminals integrated with a Phone/CATV BIAs to interact with the system. The following operation is supported:

Remote Transaction Authorization

In order to implement that operation, the BIA/CATV provides the following command set:

Get Biometric <time>

Set PIC <text>

Assign Register <register> <text>

Set Account index code <text>

Form Message <type>

Decrypt Response <encrypted response message>

Reset

1.3.3. BIA Software: Integrated FAX Command Set

The BIA/Fax software interface exports a command set that allows terminals integrated with a fax BIA to interact with the system. The following operations are supported:

Secure Fax Submit

Secure Fax Data

Secure Fax Tracking

Secure Fax Retrieve

Secure Fax Reject

Secure Fax Archive

Secure Fax Contract Accept

Secure Fax Contract Reject

Electronic Document Archive Retrieve

In order to implement these operations, the BIA/Fax provides the following command set:

Get Biometric <time>

Set PIC <text>

Set Title Index Code <text>

Assign Register <register> <value>

Get Message Key

Form Message <type>

Decrypt Response <encrypted response message>

Reset

1.3.4. BIA Software: Registration Command Set

The BIA/Reg software interface exports an interface that allows general purpose computers to interact with the system to identify and register individuals. The following operations are supported:

Individual Identification

Biometric Registration

In order to support those operations, the BIA/Reg provides the following command set:

Set Language <language-name>

Get Biometric <time> [primary.vertline.secondary]

Get PIC <time>

Assign Register <register> <text>

Get Message Key

Form Message <type>

Show Response <encrypted response> <time>

Reset

1.3.5. BIA Software: PC Command Set

The BIA/PC software interface exports a command set that allows general purpose computers to send, receive, and sign electronic documents, conduct transactions across the network, and provide biometric-derived credentials to sites on the network. The following operations are supported:

Electronic Document Submit

Electronic Document Data

Electronic Document Tracking

Electronic Document Retrieve

Electronic Document Reject

Electronic Document Archive

Electronic Document Archive Retrieve

Electronic Signature Submission

Electronic Signature Check

Remote Transaction Authorization

Network Credential

Secured Connection

In order to support those operations, the BIA/PC provides the following command set:

Set Language <language-name>

Get Biometric <time>

Get PIC <time>

Get Account index code <time>

Validate Amount <amount> <time>

Enter Amount <time>

Validate Document <name> <time>

Assign Register <register> <text>

Get Message Key

Form Message <type>

Show Response <encrypted response> <time>

Validate Private <encrypted validation> <time>

Reset

1.3.6. BIA Software: Issuer Command Set

The BIA/Iss software interface exports an interface that allows general purpose computers to interact with the system to authenticate and submit batch change requests. The following operation is supported:

Issuer Batch

In order to implement this operation, the BIA/Iss provides the following command set:

Set Language <language-name>

Get Biometric <time> [primary.vertline.secondary]

Get PIC <time>

Assign Register <register> <value>

Get Message Key

Form Message <type>

Show Response <encrypted response> <time>

Reset

1.3.7. BIA Software: Internal Command Set

The BIA/Int exports a command set that allows general purpose computers to interact with the system to identify individuals. The following operation is supported:

Individual Identification

In order to implement this operation, the BIA/Int provides the following command set:

Set Language <language-name>

Get Biometric <time>

Get PIC <time>

Assign Register <register> <value>

Get Message Key

Form Message <type>

Show Response <encrypted response> <time>

Reset

1.3.8. BIA Software: ATM Command Set

The BIA/ATM software interface exports a command set that allows ATMs to identify individuals. The following operation is supported:

Account Access

In order to implement this operation, the BIA/ATM provides the following command set:

Get Biometric <time>

Set PIC <text>

Set Account index code <text>

Assign Register <register> <value>

Form Message <type>

Decrypt Response <encrypted response message>

Reset

1.4. Terminals

1.4.1. Introduction

The terminal is the device that controls the BIA and connects to the DPC via modem, X.25 connection, or Internet connection--methods well-known to the industry. Terminals come in different shapes and sizes, and require different versions of the BIA to perform their tasks. Any electronic device, which issues commands to and receives results from the biometric input device, can be a terminal.

Some terminals are application programs that run on a general purpose microcomputer, while other terminals are combinations of special purpose hardware and software.

While the terminal is critical for the functioning of the system as a whole, the system itself places no trust in the terminal whatsoever. Whenever a terminal provides information to the system, the system always validates it in some manner, either through presentation to the individual for confirmation, or by cross-checking through other previously registered information.

While terminals are able to read some parts of BIA messages in order to validate that the data was processed properly by the BIA, terminals cannot read biometric identification information including the biometric, the PIC, encryption keys, or account index codes.

Specific BIAs export some security functionality to the terminal, such as PIC entry, and private code display. As a result, such devices are regarded as somewhat less secure than their entirely self-contained counterparts, and as such have consequently lower security ratings.

There are many different terminal types; each is connected to a specific model BIA. Each terminal is described in brief below:

ATM (Automated Teller Machinery)

Integrated BIA/ATM with ATM software load provides biometric-PIC access to ATM cash dispensers.

BRT (Biometric Registration Terminal)

Standard BIA with Registration software load attached to a microcomputer provides banks with the ability to register new individuals with the system along with their financial asset accounts and other personal information.

CET (Certified Email Terminal)

Standard BIA with PC software load attached to a microcomputer provides individuals with the ability send, receive, archive, reject, and track certified email messages.

CPT (Cable-TV Point of Sale Terminal)

BIA/catv with CATV software load attached to the CATV broadband provides individuals with biometric-television (or "TV") remotes with the ability to authorize television shopping purchases.

CST (Customer Service Terminal)

Standard BIA with Internal software load attached to a microcomputer system authorizes employees to construct database requests for the purposes of customer service.

EST (Electronic Signature Terminal)

Standard BIA with personal computer software load attached to a microcomputer provides individuals with the ability to construct and verify electronic signatures on documents.

IPT (Internet Point of Sale Terminal)

Standard BIA with personal computer software load attached to a microcomputer provides individuals with internet connections the ability to purchase products from a merchant that is connected to the Internet.

IT (Issuer Terminal)

Standard BIA with Issuer software load attached to a microcomputer provides banks with the ability to send batched changes of asset accounts to the DPC.

ITT (Internet Teller Terminal)

Standard BIA with personal computer software load attached to a microcomputer with an internet connection provides individuals with the ability to perform transactions with their favorite Internet Bank.

PPT (Phone Point of Sale Terminal)

BIA/catv with CATV software load integrated with a telephone provides individuals with the ability to authorize transactions over the telephone.

RPT (Retail Point of Sale Terminal)

Standard BIA with Retail software load attached to an X.25 network or using a modem allows an individual to purchase items using transaction authorizations in a store.

SFT (Secure Fax Terminal)

BIA/catv with Fax software load integrated with a fax machine provides individuals with the ability to send, receive, reject archive, and track secured fax messages.

1.4.2 Terminal: Retail Point of Sale Terminal

1.4.2.1. Purpose

The purpose of the RPT is to allow individuals to purchase items at a store without having to use either cash, check, or a debit or credit card.

The RPT uses a BIA/Retail to authorize financial transactions from an individual to a merchant. In addition to being used to accept biometric-PIC authorizations, the RPT provides standard debit and credit card scanning functions as well.

Note that only the biometric-related transactions are described in detail here. It is assumed that the RPT will also consist of standard credit and debit magnetic stripe card readers, as well as optional smart card readers too.

1.4.2.2. Construction

Each RPT is connected to the DPC by a modem, an X.25 network connection, an ISDN connection, or similar mechanism. The RPT may also be connected to other devices, such as an electronic cash register, from which it obtains the amount of the transaction and the merchant code.

The RPT consists of:

an BIA/Retail

an inexpensive microprocessor

9.6 kb modem/X.25 network interface hardware

merchant identification code number in non-volatile RAM

a DTC serial port for connecting to the BIA

magnetic stripe card reader (known in the industry)

ECR (electronic cash register) connection port

optional smart card reader (known in the industry)

1.4.2.3. Identification

Two entities need to be identified for the DPC to respond positively to an BIA transaction authorization request: the individual, and the merchant.

The individual is identified by the biometric-PIC, and the merchant is identified by the DPC, which cross-checks the merchant code contained in the BIA's VAD record with the merchant code added to the transaction request by the RPT.

1.4.2.4. Operation

First, the merchant enters the value of the transaction into his electronic cash register. Then, the individual enters his biometric-PIC, his account index code, and then validates the amount. The RPT then adds the product information and the merchant code to the BIA, instructs the BIA to construct the transaction, and then sends the transaction to the DPC through its network connection (modem, X.25, etc).

When the DPC receives this message, it validates the biometric-PIC, obtains the account number using the index code, and cross-checks the merchant code in the message with the registered owner of the BIA. If everything checks out, the DPC forms and sends a credit/debit transaction to execute the exchange. The response from the credit/debit network is added to the private code to form the transaction response message, which the DPC then sends back to the RPT. The RPT examines the response to see whether or not the authorization succeeded, and then forwards the response to the BIA, which then displays the individual's private code, concluding the transaction.

1.4.2.5. Security

Messages between the RPT and the DPC are secured by encryption and MAC calculation from the BIA. The MAC allows the RPT to review the unencrypted parts of the message, but the RPT cannot change them. Encryption prevents the encrypted part of the message from being disclosed to the RPT.

Each retail BIA must be registered to a merchant. This helps to discourage BIA theft. Furthermore, because the RPT adds the merchant code onto each message, replacing a merchant's BIA with a different BIA is detected by the cross-check performed at the DPC.

1.4.3. Terminal: Internet Point of Sale Terminal

1.4.3.1. Purpose

The purpose of an Internet Point of sale Terminal (IPT) is to authorize credit and debit financial transactions from an individual at a computer to a merchant, both of whom are on the Internet.

Note that the Internet simply represents a general purpose network where a merchant, the DPC, and the IPT can all connect to each other in real time. As a result, this mechanism would work exactly the same on any other general purpose network.

1.4.3.2. Construction

The IPT consists of:

an BIA/PC

a microcomputer

an Internet Shopper software application

an Internet (or other network) connection

1.4.3.3. Identification

In addition to identifying the individual, the IPT must also identify the remote merchant who is the counterparty to the transaction. The merchant must also identify both the DPC and the IPT.

The Internet Shopper program stores the hostname (or other form of net name) of the merchant from which the purchase is taking place in order to verify the merchant's identity. Since the merchant registers all of his legitimate internet hosts with the DPC, this allows the DPC to cross-check the merchant code with the merchant code stored under that hostname to verify the merchant's identity.

1.4.3.4. Operation

First, the IPT connects to the merchant using the Internet. Once a connection is established, the IPT secures it by generating and then sending a Session Key to the merchant. In order to assure that the session key is protected from disclosure, it is encrypted with the merchant's Public Key using Public Key Encryption. When the merchant receives this encrypted Session Key, he decrypts it using his Private Key. This process is called securing a connection through a Public Key Encrypted secret key exchange.

Once connected, the IPT downloads the merchant code, and both price and product information from the merchant. Once the individual is ready to make a purchase, he selects the merchandise he wishes to buy. Then, the individual enters the biometric-PIC using the BIA/PC, the IPT sends the merchant code, the product identification information, and the amount to the BIA, and instructs it to construct a Remote Transaction Authorization request. Then the IPT sends the request to the merchant via the secure channel.

The merchant is connected to the DPC via the same sort of secure connection that the IPT has with the merchant, namely, using Public Key Encryption to send a secure session key. Unlike the IPT-merchant connection, however, merchant-DPC session keys are good for an entire day, not for just one connection.

The merchant connects to the DPC, securing the connection using the session key, forwarding the transaction to the DPC for validation. The DPC validates the biometric-PIC, cross-checks the merchant code contained in the request with the merchant code stored under the hostname that was sent in the request, and then sends a transaction to the credit/debit network. Once the credit/debit network responds, the DPC constructs a reply message including the credit/debit authorization, an encrypted private code, and the address of the individual, and sends that message back to the merchant.

Once the merchant receives the reply, it copies the individual's mailing address out of the reply, makes note of the authorization code, and forwards the reply message to the IPT.

The IPT hands the reply to the BIA, which decrypts the private code and displays it on the LCD screen, indicating that the DPC recognized the individual. The IPT also shows the result of the transaction as well, be it success or failure.

1.4.3.5. Security

Since the system in general assumes that an adversary inhabiting the network can hijack network connections at any point, all parties must have secure communications during their realtime interactions. The main concern isn't disclosure of information, but rather insertion or redirection of messages.

The whole system of Public Key Encryption relies on having a trusted source for the Public Keys. These trusted sources are called Certifying Authorities, and we assume that such a source will be available on the Internet in the near future.

1.4.4. Terminal: Internet Teller Terminal

1.4.4.1. Purpose

The Internet Teller Terminal (ITT) is used to identify individuals for internet banking sessions. The DPC, the bank's computer system, and the individual are all connected to the Internet.

There are two main tasks. The first is providing a secure communications channel from the ITT to an internet bank. The second is providing unimpeachable identity credentials to the internet bank. Once both are accomplished, the ITT can provide a secure internet banking session. In addition, the BIA's challenge-response verification capability is used to provide additional security for all high-value and/or irregular transactions.

1.4.4.2. Construction

The ITT consists of:

an BIA (standard PC model)

a microcomputer

an Internet Teller software application

an Internet connection

The ITT accepts biometric identification using an BIA/PC connected to the microcomputer serving as the individual's Internet terminal.

1.4.4.3. Identification

Both the individual and the bank are identified by the DPC to create the network credential. The network credential includes the individual's identification as well as the context of the connection (i.e., the TCP/IP source and destination ports).

The DPC identifies the bank by cross-checking the code that the bank sends to the ITT with the bank's hostname that the ITT sends to the DPC.

1.4.4.4. Operation

First, the ITT connects to the internet bank, making sure that the bank has the computing resources required to handle a new session for the individual. If the bank has sufficient resources, it sends back the bank identification code to the ITT.

Once connected, the ITT instructs the BIA to obtain the biometric-PIC and the account index code from the individual. Then the ITT adds both the bank's hostname as well as the bank code. Using all this information, the BIA is then asked to form a network credential request message which the ITT sends to the DPC via the Internet.

When the DPC receives this message, it validates the biometric-PIC, obtains the account number using the index code, and makes sure that the bank code from the message matches the bank code stored under the bank's hostname in the Remote Merchant database. The DPC also checks to make sure that the account number returned by the index code belongs to the bank as well. If all checks out, then the DPC creates a network credential using the individual's account identification, the time of day, and the bank code. The DPC signs this credential using Public Key Encryption and the DPC's Private Key. The DPC retrieves the bank's public key, and the individual's private code, and with the credential forms the network credential response message. The response message is encrypted using the BIA response key, and is then sent back to the ITT.

When the ITT receives the response, it hands the response message to the BIA. The BIA decrypts and then displays the individual's private code on the LCD screen. The bank's public key is stored in the Public Key register. Two random session keys are generated by the BIA. The first key, called the Shared Session Key, is revealed in plaintext to the ITT. The ITT uses this shared session key to secure the connection with the bank.

The other session key, called the Private Session Key, is not shared with the ITT. It is used for the BIA's challenge-response mechanism, a mechanism that allows the bank to obtain specific validation for non-routine transactions straight from the individual, without involving the (untrustworthy) ITT.

After receiving the Shared Session Key, the ITT asks the BIA to form a Secure Connection Request message, which includes both session keys and the network credential, and are all encrypted with the bank's public key. The ITT then sends the Secure Connection Request message to the bank.

When the bank receives the request message, it decrypts the message using its own Private Key. Then, it decrypts the actual network credential using the DPC's public key. If the network credential is valid and has not expired (a credential times out after a certain number of minutes), the individual is authorized, and the conversation continues, with the session key used to ensure security.

Whenever the individual performs any non-routine or high-value transactions, the bank may wish to ask the individual to validate those transactions for extra security. To do so, the bank sends a challenge-response message encrypted with the Private Session Key to the ITT, which forwards that challenge-response message to the BIA. The BIA decrypts the message, displays the challenge (usually of the form "Transfer of $2031.23 to Rick Adams OK?"), and when the individual validates by hitting the OK button, the BIA re-encrypts the response with the Private Session Key and sends that message to the ITT, which forwards it to the bank, validating the transaction.

1.4.4.5. Security

The system makes use of public key cryptography to both provide credentials and to secure communications between the ITT and the bank.

For this mechanism to function properly, the bank must know the DPC's public key, and the DPC must know the bank's public key. It is critical to the security of the system that both parties keep the respective public keys secure from unauthorized modification. Note that public keys are readable by anyone, they just cannot be modifiable by anyone. Of course, any session or secret keys must be kept secure from observation, and those secret keys must be destroyed after the session has ended.

The extra validation step for non-routine transactions is necessary because of the relative difficulty involved in securing personal computer applications on the Internet due to viruses, hackers, and individual ignorance. Banks should probably restrict routine money transfers available to ITT's to include only money transfers to well-known institutions, such as utility companies, major credit card vendors, and so on.

1.4.5. Terminal: Electronic Signature

1.4.5.1. Purpose

The electronic signature terminal (EST) is used by individuals to generate electronic signatures that cannot be forged for electronic documents. The EST either allows individuals to sign electronic documents, or verifies electronic signatures already on such documents.

1.4.5.2. Construction

The EST consists of:

an BIA/PC

a microcomputer

a message digest encoder algorithm

a modem, an X.25 connection, or an Internet connection

an electronic signature software application

The EST uses an BIA/PC attached to a microcomputer, with events controlled by an electronic signature software application.

1.4.5.3. Identification

To create a digital signature without using some sort of public/private keyed token, three things need to be done. First, the document to be signed needs to be uniquely identified, the time of day needs to be recorded, and the individual performing the signature needs to be identified. This links the document, the individual, and the time, creating a unique time stamped electronic signature.

1.4.5.4. Operation

First the document to be signed is processed by a message digest encoding algorithm that generates a message digest code. One such algorithm is the MD5 algorithm by RSA, which is well known in the industry. By their nature, message digest algorithms are specifically designed so that it is almost impossible to come up with another document that generates the same message digest code.

Then, the individual enters his biometric-PIC using the BIA, the message digest code is handed to the BIA,