KR20000047650A - Method and apparatus for enhancing remote user access security for computer networks - Google Patents

Abstract

PURPOSE: A method for authenticating a user request and an apparatus for doing the same and a program product code for doing the same are provided to make money interaction safer. CONSTITUTION: A method for authenticating a user request includes following steps. At the first step, a dedication key and common key pair are generated(128). At the second step(130), biological data corresponding to a specific user is generated. At the third step(132), the biological data corresponding to a specific user as well as the pair of dedication key and common key are stored in a remote position. At the forth step(134), a user request including the coded biological data is generated as a dedication key in a rear location. At the fifth step(146), the user request is transmitted to the remote location. At the sixth step(154), the user request is decoded with the dedication key. At the seventh step(162), the stored biological data is searched. At the eighth step(170), the biological data is validated so as to authenticate the user request.

Description

METHOD AND APPARATUS FOR ENHANCING REMOTE USER ACCESS SECURITY FOR COMPUTER NETWORKS}

TECHNICAL FIELD The present invention relates to security techniques in computer systems, and in particular, to authentication mechanisms for authenticating requests and messages from remote locations.

Public / private key pairs and user IDs / passwords are key aspects of modern authentication mechanisms currently used in computer system authentication schemes. These keys are used by specific software, such as a familiar Lotus Notes (trademark of IBM) application or by a secure web browser, and are often tied to a specific device through a digital certificate that resides on the machine. User IDs and passwords are often used to provide an additional layer of security when machine security issues are raised. In the past, the combination of physical use of specific device and user ID and password knowledge was considered sufficient to ensure user authentication.

However, as attacks continue on modern security systems, with increasingly sophisticated technology and information to penetrate them, it is now unfortunately not enough. For example, in the case of laptop computers or personal digital assistants (PDAs), if the user ID and password data is leaked and the device is publicly accessible or easily lost or stolen, the user's privileges are illegally illegal. It can have fatal consequences.

Therefore, in common facilities, especially through distribution devices such as PDAs, ATMs, kiosks, etc., as well as dedicated intranets such as a variety of intranets that are exploding in popularity among companies and other businesses or the Internet itself. Or on a public network, there is an urgent need for the application of techniques that can prevent the aforementioned threats so that secure transactions can be made.

Appropriate devices are provided with a public / private key pair assigned and equipped with a biometric data input device such as a fingerprint scanning pad at the time of manufacture. Biometric data is used in place of user IDs and passwords to validate the user's identity on common devices, including network computers, kiosks, personal digital assistants (PDAs), and automated banking terminals (ATMs). Service requests, such as biometric information and cash withdrawals or credit card purchases, are encrypted with a private key assigned to the device at the time of manufacture along with a unique device ID similar to universally administered addresses (UAA) assigned to a network card. And sent to the upstream trusted server along with the device ID and message header. At the server, biometric data and service requests are decrypted with the device's public key obtained using the device ID from the message, and prepared against a database of prestored biometric data of the type, such as sent retinal scans, fingerprints, etc. Confirmation is made. Once the user is authenticated and the service request is confirmed in consideration of the user's privileges, the server securely processes the submitted request.

1 is a high level functional block diagram illustrating a remote computer system implementing a portion of the present invention that interacts with a remote generic device such as a PDA.

2 is a functional block diagram illustrating a manner of configuring a remote user device in accordance with the present invention.

3 is a functional block diagram illustrating the components of a remote system interacting by the apparatus shown in FIG. 2 in accordance with the present invention.

4 is a flow diagram illustrating the steps in which the remote user device of FIG. 2 may be created and the system of FIG. 3 having security information;

5 is a flow chart illustrating a series of events when the apparatus of FIG. 2 interacts with the system of FIG. 3 to obtain secure transaction approval.

Explanation of symbols for the main parts of the drawings

58: cryptographic assembly 60: ROM

62: biometric input sensor device 66: network

72,74: database

1 illustrates an embodiment of a computer system that can be used in both remote and near locations to implement the improved security system of the present invention. The system includes a CPU 10, read-only memory (ROM) 11, random access memory (RAM) 12, I / O adapters, all interconnected via a common address / data and control path or bus 16 13, a user interface adapter 18, a communication adapter 14, and a display adapter 19. Each of the aforementioned components accesses the common bus using conventional techniques well known to those skilled in the art, and uses the CPU 10 as a bus master to provide a specific address range to each component in the system. It includes. As shown in FIG. 1, these external devices, such as DASD 15, interface to common bus 16 through each adapter, such as I / O adapter 13. Other external devices, such as display 21, similarly use their respective adapters, such as display adapter 19, which provides data flow between bus 16 and display 21 or other device. Various user interface means are provided for interconnection, in which the user interface adapter with a representative user input device such as joystick 23, mouse 25, keyboard 17, speaker and / or microphone 27 ( 18) is used. The system is provided with a conventional operating system 29 suitable for running one or more applications 31. Each of these devices is well known in the art and will not be described herein.

The invention is inherently intended on any computer system and corresponding microprocessor, such as RS / 6000 (TM), RISC-based workstations and personal computers from IBM running AIX (TM) and OS / 2 (TM) operating systems, or For example, in the case of an RS / 6000 workstation, it is implemented on a similar machine from another company, such as a 604 PowerPC (TM) RISC chip. (RS / 6000, IBM, AIX, OS / 2, and PowerPC are trademarks of IBCM Corporation.)

1 includes, in conjunction with the CPU 10, one or more microprocessors that perform the system address, data, and control processing functions typically required for the correct operation of the system of FIG. Although the present invention is applicable to a variety of microprocessor designs, in the embodiments disclosed herein, the microprocessor is a microprocessor of the PowerPC 604 microprocessor, which is a microprocessor of the kind known as a reduced instruction assembly computer (RISC) microprocessor manufactured by IBM Corporation. Has a form. Further details regarding the structure and operation of such microprocessors can be found in the IBM Copyright, November 1994, document # MPC604UM / AD, PowerPC 604 RISC Microprocessor User Manual, incorporated herein by reference.

In connection with the teachings of the present invention, a user may manipulate various objects such as a cursor and a pop-up or pop-down menu on the display 21, which are operable using various pointing devices such as a mouse 25 and voice driven navigation. You will see. In addition to operating system and application code residing in RAM 12 and / or DASD 15, the program code associated with user interface adapter 18 via device driver for designation tool 25 and microphone 27 may be used as a microphone ( 27 may move the cursor on the display screen 21 in response to and in response to correlated voice commands input to and facilitate this movement.

It will be apparent that the functional elements shown in the computer system of FIG. 1 may be desirably modified to suit the needs and applications of the near field device and the remote computer system, which will be described in more detail below. For example, when the near field device has the form of a PDA described above, it may or may not require a joystick or standalone mouse or other pointing device within the PDA itself. In this way, a standalone display may be inappropriate as an integral part of a PDA and an LCD or other smaller display may be rather suitable. Conversely, such a standalone display screen may be more appropriate, for example, in kiosk or ATM applications. However, the basic concepts may be applied to a wide variety of computing devices in both near and remote locations where the present invention may require the functional elements of FIG. 1 in different forms or as many as necessary, and thus the present invention is directed to specific computer systems. It is not limited.

Referring now to FIG. 2, in conjunction with the system of FIG. 3, there is provided a way for a manufacturer to prepare a remote device to be used by a terminal user to make a secure transaction. The generation of IDs and keys used in FIG.

First, a process 40 is used to generate multiple public / private key pairs 40 in a manner well known in the art. Similarly, process 46 generates a number of device IDs, each associated with a different unique physical device used by a remote user who interacts with the system of FIG. These unique device IDs are similar to IDs known as Universal Management Addresses (UAAs) associated with network information cards (NICs) typically used for network servers and clients, thereby (such as NICs, PDAs, ATMs, or kiosks). Each individual physical device will have an associated device ID. Following the public key / private key pair generation process, the flow proceeds to the public key shown by arrow 42 and the private key shown by arrow 50. Similarly, the flow proceeds to the device ID shown by arrows 48 and 56 following the device ID generation process 46. The public key-device ID pair shown at 44 as the ID / public key from these processes 40, 46 is encrypted key database 72 (FIG. 3) as schematically shown by arrow 45. Which will be explained later. It will be appreciated that there are a number of ID / public key pairs 44 in the database 72, each of which is unique for a different one of the plurality of individual devices.

Similarly, processes 40 and 46 generate a device ID shown by a unique device ID arrow 52 and a plurality of private keys shown by a dedicated key arrow 50, each of these unique dedicated key / device IDs. The pair is shown in a dedicated key / ID pair 54. Each of these dedicated key / ID pairs 54 is conveyed as shown by arrow 56, and more preferably, read-only memory constituting a portion of encryption processor assembly (EPA) 58. Burned onto (ROM) 60. Thus, it can be readily appreciated that each of these cryptographic processing assemblies (EPAs) 58 nonvolatile, having a different unique private key / ID pair 54 associated only with a particular EPA 58. Each EPA 58 also has an appropriate biometric input sensor device 62 associated with it. The sensor device may take the form of a fingerprint scanning pad, a retina or face scanning camera, or the like, for example, generating biometric data uniquely associated with a particular user of the EPA 58 for use in authentication in the present invention. It may be any device capable of doing so. Thus, the present invention is not limited to a particular type of biometric input sensor device, but rather applies to devices capable of generating biometric data uniquely associated with a particular user. In manufacturing terminal user devices such as ATMs, kiosks, PDAs, etc., the manufacturer will appreciate that the EPA 58 and biometric input sensor device 62 can be combined together or linked together as needed. . In the foregoing, it is noted that the terms "public" and "private" keys have been used only to differentiate the unique parts of the keys. It will be appreciated that the EPA 58 device operator will only access the "public" key.

Having described the generation of public / private keys and IDs so far, it has been described that devices using dedicated keys and IDs are used by remote users, and the system of FIG. 3 is now described as EPA and biometric input sensor devices and these ID / The input from public key pair 44 will be described in more detail.

First seen from the top of FIG. 3, the above-described encryption key database 72 is shown as a repository for a number of ID / public key pairs 44 generated in FIG. 2. Also shown in the lower part of FIG. 3 is a familiar PDA 58, including a ROM 60, wherein one of the private key / ID pairs generated in accordance with the process of FIG. 2 and uniquely associated with a particular EPA 58 is shown. One is saved.

Also shown in FIG. 3 is a biometric key database 74. This database consists of a number of biometric data-user data field pairs. For each pair, all of the biometric data uniquely associated with a particular terminal user and a number of data fields, such as licenses, account numbers, etc., uniquely associated with a particular terminal user and its biometric data, are stored in the database 74. Stored.

3 also includes a reliable server 70 that partially performs the function of servicing terminal user requests that are delivered in part by user interaction with the user's EPA 58. EPA 58 and trusted server 70 communicate with each other via a suitable network 66 disposed between this server 70 and EPA 58. This network may take the form of an intranet, the Internet, a dial-up network, or other suitable network suitable for interconnecting the remote EPA and the server 70.

A particularly important function of the present invention performed by the trusted server 70 is to use the encryption key stored in the database 72 to decrypt the request 64 that the EPA 58 makes, and to measure the biometric stored in the database 74. It provides the ability to authenticate user approvals and other data through historical data. As will be described in more detail below, this request 64 includes the device ID data 54 and other transaction data stored in the ROM 60 as well as biometric data of user input through the sensor device 62. The combination 10 of biometric information and transaction information is communicated to the server 70 via the network 66 and the link 68. The interaction between the server 74 and 72, respectively, shown by double arrows 76 and 78, decrypts the encrypted user request entered on line 68 in the manner described in detail below.

Thus, in summary, the user interacting with the EPA 58 in FIG. 3 may or may not use the biometric input sensor device 62 in the EPA 58, which is provided to a particular ATM, kiosk or PDA, or the like. Provide her biometric input data. The user does this to request confirmation for continued use based on the biometric data so provided. It should be noted that in the prior art such biometric data can be leaked (e.g., by the offender plagiarizing the fingerprint of a legitimate user), an important feature of the present invention is that this data is stored in ROM 60. By further encrypting with the private key 54 and uniquely associating it with a particular user, the misuse of this biometric data by a criminal who does not have the ability to use the biometric data in a particular EPA 58 becomes useless or almost useless. will be.

Once the server 70 decrypts using the information stored in the databases 72, 74, a notice for the confirmed terminal user is sent from the server 70 over the line 66 via the line 69, Eventually, it may be passed from the network 66 to the terminal user via his or her EPA 58 as shown by line 71. Thereafter, a secure link may be established, whereby the terminal user may provide additional data for the user data fields of the database 74 or, if necessary, permit retrieval of such data associated with a particular user. ) To provide additional details.

The confirmation function determination block 80 of FIG. 3 determines the private key / ID information coming on the line 64 and the corresponding ID / public key information in the database 72 to determine whether a valid request has been provided. And a set of logical processes that can be used to correlate biometric data in the database 74 functionally. Therefore, the present invention is not limited to the specific form of the confirmation function determination algorithm 80, and may be applied to the determination of appropriately using these inputs. The input is passed to decision block 80 via line 82, and the final decision result is returned from verification function decision block 80 to server 70 via line 86.

Referring now to FIG. 4, there is shown a flow diagram illustrating a series of events used in generating EPA 58 and placing various keys and IDs generated in the manner described above with reference to FIG. 2. First, in block 88, key pairs K ₁ and K ₂ are generated for each potential user in response to the key generation process 40 of FIG. Similarly, block 90 generates a number of unique device IDs, each corresponding to a different physical EPA 58, which corresponds to block 46 of FIG. 2. These key pairs and unique device IDs generated as shown by arrows 92 and 94 are combined to generate multiple ID, K _l pairs and multiple ID, K ₂ pairs at block 96. The ID, K ₂ pair is passed as shown by line 114 and stored in encryption key database 72 for subsequent transmission to the buyer of EPA 58 at block 116. When the device operator obtains or purchases an EPA 58, it sends a unique ID, K ₂ pair, to the last connected device operator at block 120, as shown in line 118, and then to line 122. In block 124, ID, K ₂ pairs are placed in a database 72 that is keyed on by various IDs at block 124. In this way, when a terminal user uses a particular EPA 58 corresponding to this EPA, there will be a unique ID and public key residing in the database 72.

With continued reference to FIG. 4, similar to the scheme for ID, K ₂ pairs, ID, K ₁ pairs are passed to EPA 58 that are uniquely associated with them, as schematically illustrated by arrow 98, where: ID, K ₁ pairs are baked into ROM 60 on a particular EPA 58. This is shown by block 100 in FIG. Although this ID, K ₁ pair has been described as "baked" to ROM 60, an important point here is that ID, K ₁ data uniquely associated with a particular EPA 58 is stored non-volatile on EPA 58. will be. Thus, the present invention employs a number of different techniques to accomplish this goal, one of which is to physically "burn" the ROM 60 by flash BIOS, EEPROM, by physically replacing the socket-type ROM or the like.

With continued reference to FIG. 4, once this ID, K1 data has been stored non-volatile in association with a particular EPA 58, processing continues to flow 102 and at block 104 the particular EPA 58 is stored. In combination with the selected biometric input device 62. This combination means electrical and software, and the ROM 60 and biometric input sensor device 62 are configured to provide data from the ROM (eg, a dedicated key / ID pair 54) and biometric input device. And integrated in such a way as to provide an electrically generated request that includes biometric input data for a particular user interacting with 62.

Once this EPA and biometric input device are electronically " coupled ", at block 108, it can be located and assembled with a suitable terminal device, such as an ATM, kiosk, or PDA, as described above.

Finally, as shown in flow 110, at block 112, a desired device, such as by installing an ATM machine in a kiosk in a shopping mall, a drive-thru bank, or selling a PDA to a terminal user, etc. This coupling assembly located at is placed.

Referring now to FIG. 5, illustrating the transaction approval flow for the system shown in FIG. 3, using the various keys, IDs, databases, and EPAs described above, the terminal user is directed to the server 70 via the network 66. A transaction can be issued and a security acknowledgment can be received. First, in use, the user interacts with an operator of the EPA to register biometric data through a similar biometric input sensor device. Once registered, in use the user enters 126 appropriate biometric data that is dependent on the particular transducer (Retina Scanner, Fingerprint Scanner, etc.) with EPA, and flow continues. Flow continues to block 130 along arrow 128. In block 130, the operator may modify the second or biometric data provided at block 126, as appropriate, with appropriately associated data (e.g., the aforementioned data fields such as account number, authorization, etc.). Used as a key in the database. Flow follows arrow 132 at block 134 where the user uses EPA coupled with a biometric data input device to request transaction approval. The flow proceeds to block 138 along arrow 136 and is functionally representative of the combination of biometric and transactional data entered into an encrypted message using the first key K ₁ .

With continued reference to FIG. 5, the flow continues to block 142 along arrow 140, where the system of EPA 58 adds the ID stored in ROM 60 as clear text to the request message. Again, at block 146 along arrow 144, the compiled message is sent over network 66 as request 64 and through trusted connection 70 to connection server 68 for subsequent decryption. Delivered.

The flow follows arrow 148 at block 150 where trusted server 70 extracts the EPA ID and uses it to look up the user's key K ₂ associated with database 72. Once this is done, the flow uses this key K ₂ in block 154 along arrow 152 to decrypt the pre-encrypted message with the K ₁ message in accordance with block 138 described above. The flow sends a message request to the confirmation function 80 at block 158 along arrow 156. The flow is at block 162 along arrow 160, where the verification function uses the biometric part of the message as a key to retrieve user data from biometric database 74. Flow follows arrow 164 at block 166, where confirmation function 80 makes an authorization decision based on this data received from server 70 shown as being passed along arrow 82. Note that the verification function can optionally encrypt the K ₂ key and response and return it to the original device, as shown by arrow 86. The flow then continues to block 170 along arrow 168. In this block 170 the server 70 sends an acknowledgment as a result of the user request over the network 66 to the terminal user using the EPA 58, where it is encrypted (step 166). This response can optionally be decrypted with a known K ₁ key, and the device 58 can operate based on this authorization decision data.

It will be appreciated that the preferred embodiments of the present invention may be variously modified and changed without departing from the spirit and scope of the present invention. This specification is for illustration only and is not intended to be limiting. It is intended that the scope of the invention only be limited by the following claims.

According to the present invention, once a set of users are authenticated and a service request is confirmed against the user's privileges, the server can securely process the submitted request, allowing secure transactions to be made.

Claims (30)

A method for authenticating user requests in a computer system network, the method comprising: Generating a private key and a public key pair, Generating biometric data corresponding to the user; Storing the biometric data and the public key at a remote location; Generating, at a local location, a user request including the biometric data encrypted with the private key; Sending the user request to the remote location; Decrypting, at the remote location, the user request with the public key into the biometric data; Retrieving the stored biometric data; Validating the biometric data to authenticate the user request Method for authenticating a user request comprising a. The method of claim 1, The checking step, Comparing the biometric data sent in the decrypted user request with the stored biometric data Method for authenticating a user request comprising a. The method of claim 2, And sending the user request over a network interconnecting the near location with the remote location. The method of claim 3, wherein Storing the private key with an associated ID number at the local location. The method of claim 4, wherein The ID number is uniquely associated with the public key, The method, Storing the ID number and the public key as a tuple in a first database at the remote location The method for authenticating a user request further comprising. The method of claim 5, And wherein the biometric data is stored in a second database. The method of claim 6, Generating a data field associated with the user and the biometric data; Storing the biometric data and the data field as a tuple in the second database The method for authenticating a user request further comprising. The method of claim 7, wherein And storing the private key is made at the local location. The method of claim 8, Wherein the generation of the biometric data is made at the close location. The method of claim 9, Processing the request in response to the confirmation. An apparatus for authenticating user requests in a computer system network, the apparatus comprising: Means for generating a private and public key pair, Means for generating biometric data corresponding to the user, Means for storing the biometric data and the public key at a remote location; Means for generating, at a local location, a user request including the biometric data encrypted with the private key; Means for sending the user request to the remote location; Means for decrypting, at the remote location, the user request with the public key into the biometric data; Means for retrieving the stored biometric data; Means for verifying the biometric data to authenticate the user request Apparatus for authenticating a user request having a. The method of claim 11, Means for the confirmation, Means for comparing the biometric data sent in the decrypted user request with the stored biometric data Apparatus for authenticating a user request having a. The method of claim 12, And means for sending the user request is for authenticating a user request over a network interconnecting the short distance location with the remote location. The method of claim 13, And means for storing the private key having an associated ID number at the near location. The method of claim 14, The ID number is uniquely associated with the public key, The device, Means for storing the ID number and the public key as a tuple in a first database at the remote location Apparatus for authenticating a user request further comprising. The method of claim 15, And means for storing the biometric data in a second database at the remote location. The method of claim 16, Means for generating a data field associated with the user and the biometric data; Means for storing the biometric data and the data field as a tuple in the second database Apparatus for authenticating a user request further comprising. The method of claim 17, And storing the private key is made at the local location. The method of claim 18, The generation of the biometric data may comprise an apparatus for authenticating a user request made at the near location; The method of claim 19, And a means for processing the request in response to the confirmation. In a computer program product comprising program code means usable by a computer system network, the program code means comprises: Program code means for generating a private key and a public key pair, Program code means for generating biometric data corresponding to the user; Program code means for storing the biometric data and the public key at a remote location; Program code means for issuing a user request including the biometric data encrypted with the private key at a local location; Program code means for sending the user request to the remote location; Program code means for decrypting the user request into the biometric data with the public key at the remote location; Program code means for retrieving the stored biometric data; Program code means for verifying the biometric data to authenticate the user request Program product code with. The method of claim 21, Program code means for the confirmation, Program code means for comparing the biometric data sent in the decrypted user request with the stored biometric data Program product code with. The method of claim 22, Program code means for sending the user request is made over a network interconnecting the near location and the remote location. The method of claim 23, Program code means for storing said private key having an associated ID number at said close location. The method of claim 24, The ID number is uniquely associated with the public key, The program code means for storing, Program code means for storing the ID number and the public key as a tuple in a first database at the remote location Program product code with more. The method of claim 25, Program code means for storing the biometric data in a second database at the remote location. The method of claim 26, Program code means for generating a data field associated with the user and the biometric data; Program code means for storing the biometric data and the data field as a tuple in the second database Program product code with more. The method of claim 27, And storing said private key is done at said near location. The method of claim 28, The generation of said biometric data is performed at said close location. The method of claim 29, Program code means for processing said request in response to said confirmation.