JP2008065835A - Data authentication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data authentication method for authenticating a client when authentication data are registered having the same kind of a biological data reading function as that of the client. <P>SOLUTION: In a system performing authentication with a pluralty of kinds of biological data, a method for collating all the biological data registered in advance with the biological data read from a biological sensor decides, on receipt of a request from a client to collate only the biological data, biological data to be collated from the data with biological reading apparatus information added to the biological data transmitted as the collation request, to collate it with specific biological data. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a data authentication method, and more particularly to a data authentication method in which a user is authenticated based on bioauthentication data.

  In a conventional system that performs authentication using a plurality of types of biodata, the correspondence between users and clients is uniquely determined. For this reason, even if authentication with a plurality of types of biodata is possible, the type of biodata at the time of authentication is determined in advance by the user.

Conventional techniques of this type include collation means that collates live pattern data obtained by reading a live pattern of physical features such as fingerprints and facial features with a reader and reference pattern data of recorded features, and collation. There is known a system for determining whether or not a live pattern is invalid data by means of a complete match, a time stamp match, or a history match before or after the means (see, for example, Patent Document 1). In addition, regarding a biometric authentication system for performing personal authentication using biometric information, a system that prevents a decrease in collation accuracy even when there is instability at the time of detecting biometric information is known (for example, see Patent Document 2).
JP 2003-308302 A JP 2006-6753 A

  In the conventional system, authentication could not be performed even if authentication data was registered with a biodata reading means of a type other than that set for authentication. For this reason, there is a problem that a client having only a means for reading biodata other than the set type cannot be authenticated.

  The present invention has been made in view of such problems, and any client can authenticate if authentication data of the same type as the biodata reading function of the client is registered. The purpose is to provide a data authentication method.

(1) The invention described in claim 1 is a method in which, in a system capable of authenticating with a plurality of types of biodata, the biodata is read from the biosensor and then collated with all the preregistered biodata. When there is a biodata-only collation request from a client, biodata to be collated is determined from the biodata sent as a collation request with bioreader information added, and collation with specific biodata is performed. Features.

(1) According to the first aspect of the invention, since the search time for collation can be shortened, the bioreader search efficiency and collation efficiency can be improved in collation in a multi-bio system.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a block diagram showing an embodiment of the present invention. In this embodiment, a database is provided on the client 20 side so that data verification can be performed without the need for a server. In the figure, 22 is a biosensor driver, 23 is a biodata collation unit, 24 is a biodata conversion unit, 26 is a program control unit, 40 is an application, and 50 is a database. The database 50 includes a bioauthentication data registration table 41 and a user table 42.

  The operation of the system configured as described above will be described with reference to FIG. FIG. 2 is a diagram showing a first processing flow of the present invention. First, a collation request is made from the application 40 (S1). As a result, the program control unit 26 is activated (S2). Each biosensor (bioreader) is driven by the biosensor driver 22 and outputs biodata (S3).

  The biodata conversion unit 24 receives the biodata and performs a process of extracting a feature portion (S4). Next, the biodata collation unit 23 reads the biodata measured by the biosensor and the authentication data stored in the bioauthentication data registration table 41 and collates with the authentication data (S5). Next, the collation result is determined (S6). Next, the program control unit 26 operates (S7) and notifies the result through the application 40 (S8).

  FIG. 3 is an explanatory diagram of the first data flow. In the figure, 10 is a server, and 30 is a database connected to the server 10. The database 30 includes N pieces of authentication data # 1 to #N, and each piece of authentication data includes user authentication data for each user. Reference numeral 20 'denotes a client with a plurality of bioreaders (biosensors), to which N readers # 1 to #N are attached. Reference numeral 20 denotes a client provided with a single-function reading function, which is a single-function client with a reading device. Reference numeral 60 denotes an authentication server program for authenticating a user using authentication data, which is provided in the server 10 (the same applies hereinafter). The following operations are performed mainly by the authentication server program 60.

  1) N types of biodata are read from a plurality of clients 20 'with bioreaders. Here, when there are a plurality of users, N types of biodata are read for each user. As a result, as shown in the database 30, each authentication data is obtained for each user and stored in the database 30.

  2) Here, an arbitrary client 20 issues an authentication request to the server 10. In this case, since a plurality of types of authentication data are stored for each user in the database 30, an authentication request can be made from any client.

  3) The authentication server program 60 collates the data sent from the client 20 with the corresponding authentication data. In this case, since the authentication data is stored for each user, it is necessary to input a user ID indicating which user is used for the authentication.

4) The authentication server program 60 transmits the verification result to each client 20.
According to this embodiment, the server 10 can collate biodata and authentication data as necessary, and notify the client 20 of the result.

  FIG. 4 is a diagram for explaining the first processing of the present invention. In this embodiment, the final authentication is determined based on the logical condition of the matching result in accordance with the importance. For example, as shown in the figure, when the importance is small, if any one of N pieces of biodata is collated, it is determined that the authentication is OK. That is, in this case, the OR of each authentication result is taken. In such a case, for example, when only accessing Windows, such as Windows (registered trademark of Microsoft Corporation) logon, it is called (fingerprint match) OR (voiceprint match) OR (face shape match). If there is even one item to be verified, authentication is OK.

  On the other hand, if the degree of importance increases (for example, settlement of workflow work), the condition that the collation is OK is tightened. That is, the authentication is OK when all of the N pieces of biodata are collated. Specifically, the authentication is OK when all are collated such as (fingerprint match) AND (voice print match) AND (face shape match).

  FIG. 5 is a diagram showing a second processing flow of the present invention. First, the operation when the importance is small will be described. In this case, first authentication is requested (S1). Thereby, the first authentication is started (S2). If the authentication is OK, the user is immediately determined (S3). If the authentication is NG, the process returns to step S1 to enter a process for making an authentication request for the next authentication data. If all the authentications are NG or the authentication is canceled, it is determined that the other person is present (S4).

  Next, the operation when the importance is the highest will be described. First, a first authentication request is made (S10), and first authentication is started (S11). If the authentication is OK, a second authentication request is made (S12). Then, the second authentication is started (S13). If this authentication is OK, a third authentication request is made. The above processing is performed up to the Nth authentication. That is, the Nth authentication request is made (S14), and the Nth authentication is started (S15). If the result of the Nth authentication is OK, it is determined that the user is the person himself (S16). Here, in step S15, the fact that the Nth authentication is OK indicates that all the authentications from the first to the Nth are OK. In the above processing, if the authentication is NG, the process returns to step S10 and the authentication is performed again from the beginning. If authentication is canceled in each authentication step, it is determined that the person is another person (S17).

  According to this embodiment, the level of authentication can be set depending on the application by combining a plurality of bio-authentications. In addition, it is possible to perform strict identity authentication in a system that handles high-priced payment processing or a system that handles high-priced products on the Internet.

Next, an authentication method using combination information of authentication types will be described. Combinations of authentication types can be held on both the server side and the client side.
FIG. 6 is a diagram showing a third processing flow of the present invention. As a system, FIG. 28 is used. FIG. 28 is a block diagram showing another embodiment of the present invention. Compared with the embodiment shown in FIG. 1, the difference is that the server 10 and the client 20 are connected. The server 10 is connected to the communication means 21 of the client 20 via the communication means 11. A biodata matching unit 12 is also provided on the server 10 side. Reference numeral 13 is a program control unit, and 30 is a database. The database 30 is provided with a bio-authentication data registration table 31 and a user table 32. On the client 20 side, reference numeral 25 denotes a storage unit for storing data, and reference numeral 25a denotes a cache memory for temporarily storing data from the server 10.

  When there is a collation request from the application 40 (S1), the control shifts to the program control unit 26 (S2). Next, determination of the authentication bio or the number of authentication requests is performed (S3). Next, the biosensor is searched for what kind of biosensor is provided (S4).

  When a biosensor is provided, a biosensor to be used is determined (S5). When the biosensor is determined, biodata is measured by the biosensor driver (S6). And biodata is read (S7). Biodata conversion is performed on the read biodata to extract a characteristic portion by the biodata conversion unit 24 (S8). Next, the read biodata is collated with the authentication data stored in the database (S9).

  Next, the collation result is determined (S10). When the collation result is determined, control is transferred to the program control unit 26 (S11), and the result is notified through the application 40 (S12). If the biosensor cannot be searched in step S4, control is passed to the program control unit 26 (S13). Then, the result is notified through the application 40 (S14).

  FIG. 7 is a diagram illustrating a configuration example of an application information table in a case where authentication type combination information is provided on the server side. As shown in the figure, bio-authentication data is stored for each application name. For example, in the bio authentication data 1 in the application 1, the bio authentication data is bio # 1 data.

FIG. 8 is a diagram illustrating authentication type combination information held by an application when the application side has authentication type combination information.
FIG. 9 is an explanatory diagram of the second data flow. The same components as those in FIG. 3 are denoted by the same reference numerals. In the figure, 33a is an application information table shown in FIG.
1) The setting information of the application and bio authentication is registered in the application information table 33 from the setting client 20. The application information table 33a can set a plurality of biodata. For example, Bio 1 + Bio 2 etc.
2) The user requests authentication through the application 1.
3) Register the application and bio related information from the application 1 or N to the application information table 33a.
4) Return application and bio related information to application 1.
5) Return bio 1 authentication from application 1.

  Thereafter, the read biodata is sent to the bio-authentication server 10 for verification. FIG. 10 is a diagram showing a processing flow of serial authentication, and shows the operation on the client side. When authentication is requested (S1), biodata is read and authentication means is determined (S2). Next, when the first authentication request is made (S3), the first authentication is started (S4). Then, the following processing is sequentially repeated. Then, an authentication request is made (S5), biodata is read, and an authentication means is determined (S6). Then, the Nth authentication request is made (S7), and the Nth authentication is started (S8). If the authentication is OK, the person is determined (S9).

Here, if the first authentication is NG in step S4, it is checked whether to authenticate again (S10). When authenticating again, it returns to step S1, and when not authenticating, it judges that it is another person (S11). Also in the case of step S12, it is checked whether or not to authenticate again (S12), and if authenticated, the process returns to step S1, and if not authenticated, it is judged as another person (S13). Here, when the authentication is canceled at the start of each authentication, it is determined that the user is another person (S14), and the process is terminated.

  According to this embodiment, the versatility of the program can be ensured by setting in advance a mechanism for calling a plurality of multi-bios. Server management is effective when the authentication type can be fixed according to the bio-information quality and operation of the person, and the combined information of the authentication type can be centrally managed. The application side management can be individually adjusted according to the required security strength.

  FIG. 11 is a diagram showing the processing flow of the individual authentication chart, and shows the operation on the client side. In this processing flow, authentication is performed using the individual authentication chart in the system shown in FIG. First, when an authentication request is made (S1), biodata is read to determine an authentication means (S2). Next, a first authentication request is made (S3). Then, the first authentication is started (S4). If the first authentication is OK, the process proceeds to the next.

  In step S4, if the authentication is NG, it is checked whether to authenticate again (S5). When authenticating again, it returns to step S1 and starts again from an authentication request. If authentication is not performed again, it is determined that the person is another person (S6). Such a sequence is repeated by the number of authentication means. And each time, the process of step S5 and S6 when authentication is NG is repeated.

  If the first authentication is OK, an authentication request is made (S7). And biodata is read and an authentication means is determined (S8). Then, the Nth authentication request is made (S9), and the Nth authentication is started (S10). If the Nth authentication result is OK, it is determined to be the person (S11). If the authentication result is NG, it is checked whether to authenticate again (S13). When authenticating again, it returns to step S7 and starts again from the authentication request. If it is not authenticated again, it is determined as someone else (S14). In the case of canceling with authentication, both are determined to be others (S12). The data flow explanatory diagram (third data flow explanatory diagram) in this embodiment is the same as the second data flow explanatory diagram shown in FIG.

  According to this embodiment, it is effective when the authentication type can be fixed in accordance with the bioinformation quality and operation of the person, and the combination information of the authentication type can be managed in an integrated manner. In addition, the application side management can be individually adjusted according to the required security strength.

  Next, the following embodiment will be described. In the following embodiment, the detection means is determined for each client, only one type of detection means is used for each client, and the authentication time is fixed to prevent unauthorized access from the client side. The time is shortened.

  FIG. 12 is a diagram showing a configuration example of a client information table used in this embodiment. The type that can be authenticated is fixed for each client. For example, in the case of bio-authentication data 1, the client 1 can authenticate only bio- # 1 data.

FIG. 13 is an explanatory diagram of the third data flow.
1) The setting information of the client and bio-authentication is registered in the client information table 34 from the setting client 20. Here, the client information table 34 can set a plurality of biodata. For example, Bio 1 + Bio 2 etc.
2) The user requests authentication through the application 1.
3) The client 1 and the bio related information are acquired from the application 1 or N to the client information table 34.
4) Return the client and bio related information to application 1.
5) Return bio 1 authentication from application 1.

Thereafter, the read biodata is sent to the bio-authentication server 10 for verification.
According to this embodiment, unauthorized access from a client can be prevented by fixing the authentication means. In addition, it is possible to shorten the authentication time when the access time is long, such as a remote place or a place where the communication speed is low.

FIG. 14 is an explanatory diagram of the fourth data flow. In this embodiment, authentication is performed using an individual authentication chart. The same components as those in FIG. 13 are denoted by the same reference numerals. 1) The setting information of the client and bio-authentication is registered in the client information table 34 from the setting client 20. The client information table 34 can set a plurality of biodata. For example, Bio 1 + Bio 2 etc.
2) The user requests authentication through the application 1.
3) Acquire client-related information from the application 1 or N to the client information table 34.
4) Return the client-bio related information to application 1.
5) Return bio 1 authentication from application 1.

After that, the read biodata is sent to the bio-authentication server for verification.
According to this embodiment, unauthorized access from a client can be prevented by fixing the authentication means.

  Next, a case where authentication accuracy is provided for the recognition rate at the time of data collation will be described. FIG. 15 is a diagram illustrating a configuration example of the bio-authentication data registration table. In this table, the authentication rate (authentication accuracy) is changed for each biodata. FIG. 19 is a diagram illustrating a configuration example of a bioauthentication user information table. This table provides biometric authentication accuracy corresponding to each user. For example, when the user ID is 1, the authentication accuracy of bio # 1 authentication data is set to 70%, and the authentication accuracy of bio #N authentication data is set to 85%. Here, the bio-authentication data registration table is 35, and the bio-authentication user information table is 36. These tables are provided on the database 30 side on the server 10 side. Or you may make it provide in each client side.

FIG. 17 is an explanatory diagram of a fifth data flow. An authentication accuracy log 37 stores authentication accuracy at the time of verification.
1) Define authentication data related to each biodata from the setting client 20.
2) Make a collation request from each client in ID units.
3) The collation result is determined and compared with the authentication data defined by the server 10.
At that time, the authentication accuracy is stored in correspondence with the authentication data. In this case, the method for obtaining the authentication accuracy at the time of verification is as follows. That is, 100 A / B (%) is obtained, where A is the number of matching authentication data at the time of verification and B is the number of authentication. The authentication accuracy obtained in this way is stored in the authentication accuracy log 37.
4) The authentication data is transmitted to the client 20 together with the authentication result.
5) At the time of the next verification request, the authentication accuracy log is read from the bio-authentication server 10, and if the predetermined authentication accuracy is not held, an authentication data update request or an unusable notification is sent to the authentication request client 20.

According to this embodiment, it is possible to prevent erroneous recognition due to a decrease in accuracy of authentication data due to aging of a living body.
FIG. 18 is an explanatory diagram of the sixth data flow. The operation when the user 1 accesses the server 10 from the setting client 20 is shown.
1) User 1 makes a registration request with bio-1 data.
2) The authentication server program 60 collates with the bio 1 data of the user 1. In this case, the system administrator is present for the first biodata verification.
3) A verification result is returned to the client 20 from the authentication server program 60.
4) If authenticated, registration permission to biodata N is given, and biodata N of user 1 is registered in database 30. If it is not authenticated, bio-N data for user 1 cannot be registered.

  According to this embodiment, when registering the second and subsequent biodata in a multi-biosystem, biodata registration is performed without the need for a system administrator, thereby avoiding the complexity of registration. it can.

  In the following embodiment, the user does not need to select the type of biodata at the time of collation. For this purpose, a bioauthentication user verification order table as shown in FIG. 19 is used. In this table, the collation order is determined for each user ID. For example, in the case of user 1, collation using biodata 1 is performed first, and then collation using biodata 2 is performed. Finally, collation using biodata N is performed. In the case of the user 2, the collation using the biodata 2 is performed first, the collation using the biodata 4 is performed second, and the collation using the biodata 1 is performed last.

FIG. 20 is an explanatory diagram of the seventh data flow. In the figure, 38 is the biometric user collation order table described above, and is provided in the database 30.
1) When registering biodata, define the order of biodata to be collated for each user ID.
2) A verification request is made from the client 20.
3) The authentication server program 60 determines the multi-bio collation order from the collation order table 38 based on the sent user ID 3) -1) and returns it to the client 20 3) -2).
4) The client 20 searches for a biosensor in the client 20 in accordance with the collation order, reads biodata, and makes a collation request.
5) On the server 10 side, the sent biodata is collated, and the collation result is notified to the client 20.

  According to this embodiment, in a system that handles multi-bio devices, it is possible to save time and effort to select a bio-recognition device to be verified. In a system that handles multi-bio devices, once the collation order is set, all clients can share the same setting. Furthermore, in a system that handles multi-bio devices, it is possible to set the priority of the collation order.

  The following embodiment will be described. The verification method described above is referred to as 1: 1 verification. That is, after the user ID is input, it is checked against the biodata registered based on the user ID to check the identity of the ID.

  In contrast, 1: N collation is a collation method in which biodata requested for collation is collated with all registered biodata and the person is identified from the biodata (only the biodata is the principal) To identify).

FIG. 21 is a diagram illustrating an example of an authentication screen. There is a part for inputting a user name (user ID field), and an authentication button, a cancel button, an end button, and the like are provided. In the case of the previous 1: 1 verification, it is necessary to put the user ID in the user ID field. FIG. 22 is an explanatory diagram of incorporation into the system login. Log in by writing the user ID in the user ID field.

  FIG. 23 is a flowchart showing the operation of the collation process. As the system, FIG. 1 is used. First, an authentication request is made from the application 40 (S1). As a result, control is transferred to the program control unit 26. The client 20 reads biodata (S3). Next, the client 20 determines whether an ID has been input (S4).

  When the ID is input, the server 10 searches biodata registered in advance based on the ID (S5). Then, the read biodata is collated with the registered biodata searched in step S5 (S6). Next, the collation result is determined (S7). Then, the collation result is returned to the requesting application 40 (S8).

  If no ID is input in step S4, the ID cannot be specified. Therefore, all biodata registered in advance is collated with the biodata read in step S3 (S9), and the process proceeds to step S7 (1: N collation).

  According to this embodiment, since the search time for collation can be shortened, the efficiency of bioreader search and the efficiency of collation can be improved in collation in a multi-bio system.

Further, when the user ID is not notified, the person can be identified even when there is no user ID by collating with all the biodata registered in advance.
In the following embodiment, collation is performed from registered data of the biodata type that matched last time. In order to see the previous verification history, a bio-authentication log data table 39 as shown in FIG. 24 is used. This table stores bio-authentication data, operation date, operation type, and result for each user ID. With reference to this bio-authentication log data table 39, the authentication data when the collation result is OK are used.

FIG. 25 is an explanatory diagram of the eighth data flow. In the figure, 39 is a bio-authentication log data table, which is provided in the database 30.
1) User 1 makes an inquiry request to authentication server program 60.
2) The authentication server program 60 searches the bio-authentication log data table 39 and acquires the bio-authentication type information of the user 1 that matched last time.
3) The authentication server program 60 collates with the biodata N.
4) Inform the client 20 of the collation result.

According to this embodiment, in the case of authentication of a combination using a plurality of types of biodata, the search time for verification can be shortened.
In the following embodiment, when a collation request is made from a client to a server, bioreader information is transferred together with biodata. FIG. 26 is an explanatory diagram of the ninth data flow. In the drawing, reference numeral 70 denotes a reading device information data table, which stores biodata corresponding to each reading device.
1) When reading biodata, the bioreader information is also read and a verification request is made to the authentication server program 60.
2) The server 10 refers to the reading device information data table 70 to determine the read biodata, and returns the bio authentication type data to the authentication server program 60.
3) Based on the information returned from 2), verification data is compared with the measured biodata.
4) The verification result is notified to the client 20.

  According to this embodiment, since the search time for collation can be shortened, the efficiency of bioreader search and the efficiency of collation can be improved in collation in a multi-bio system.

  The following embodiment will be described. In this embodiment, the authentication data originally held on the server side is transferred to the client side, and the authentication data is held on the client side so that the data can be collated only by the client. It is a thing.

FIG. 27 is an explanatory diagram of a tenth data flow. In this embodiment, a storage device 80 is provided on the client 20 side, and biodata from the database 30 is stored together with date data in this storage device.
1) The client 20 makes a verification request with the biodata 1.
2) The collation result on the server 10 side is notified to the client 20 side.
3) The authentication server 10 compares the date data on the server with the date data on the client side.
4) If the date data on the server 10 is newer than the date data on the client 20 side, the biodata of the user who requested the verification is downloaded (cached) to the client 20. If they are the same, do not download.

According to this embodiment, an excessive load on the authentication server and the network can be reduced.
As described above, according to the present invention, any client can authenticate if any authentication data of the same type as the biodata reading function of the client is registered. An apparatus can be provided.

It is a block diagram which shows one embodiment of this invention. It is a figure which shows the 1st processing flow of this invention. FIG. 6 is an explanatory diagram of a first data flow. It is 1st process explanatory drawing of this invention. It is a figure which shows the 2nd processing flow of this invention. It is a figure which shows the 3rd processing flow of this invention. It is a figure which shows the structural example of an application information table. It is a figure which shows the combination information of the authentication kind hold | maintained with an application. It is a 2nd data flow explanatory drawing. It is a figure which shows the processing flow of a series authentication. It is a figure which shows the processing flow of an individual authentication chart. It is a figure which shows the structural example of a client information table. It is a 3rd data flow explanatory drawing. It is a 4th data flow explanatory view. It is a figure which shows the structural example of a bioauthentication data registration table. It is a figure which shows the structural example of a bioauthentication user information table. FIG. 10 is an explanatory diagram of a fifth data flow. It is a 6th data flow explanatory view. It is a figure which shows the structural example of a bioauthentication user collation order table. It is a 7th data flow explanatory view. It is a figure which shows the example of an authentication screen. It is explanatory drawing of the incorporation to a system login. It is a flowchart which shows operation | movement of a collation process. It is a figure which shows the structural example of a bio authentication log data table. FIG. 10 is an explanatory diagram of an eighth data flow. It is 9th data flow explanatory drawing. It is a 10th data flow explanatory view. It is a block diagram which shows the other embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 20 Client 22 Biosensor driver 23 Biodata collation part 24 Biodata conversion part 25 Biosensor driver 26 Program control part 40 Application 41 Bio authentication data registration table 42 User table 50 Database

Claims (1)

In a system that can authenticate with multiple types of biodata, after reading the biodata from the biosensor, in the method of collating with all the biodata registered in advance,
When there is a biodata-only verification request from a client, biodata to be verified is determined from the biodata sent as a verification request with the bio-reader information added, and verified with specific biodata Data authentication method.

Images