JP3010022B2 - Double signature authentication method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for performing double signature authentication of, for example, a person entering a regulated area, an authenticator of an exchange document, or an application user on a network for various types of identity verification.

[0002]

2. Description of the Related Art In a service business such as a bank, it is extremely important to confirm whether or not the other party is the principal at the time of a transaction, that is, authentication. This is to prevent another person from withdrawing money from the account by impersonating the person or transferring money.

[0003] Classically, for this authentication, for example,
Ask them to submit a driver's license, certain identification cards, etc.
Checking whether or not he / she is himself. In recent years, with the development of automatic cash dispensers and the like, a method of authenticating an individual using a magnetic card, a password, or the like has been widely adopted.

[0004] Such "authentication" is often required for other than banks. For example, in research institutes and the like, in order to prevent leakage of secrets, it is often the case that only authorized persons are allowed to enter a certain area, and other persons are restricted from entering. Membership clubs must also confirm that they are members in some way. It is preferable to use the magnetic card, the password, the membership card, and the like in the research institution and the membership club. However, there is a possibility that the magnetic card and the membership card are lost, and a possibility of forgetting the password is not small. Therefore, as a method of confirming the identity, a method of using a so-called biometric physical quantity such as a fingerprint or a retinal pattern as data for authentication (hereinafter referred to as authentication data) has been proposed.

[0005] As this kind of authentication method, it is also practical to use a signature to confirm the identity of the person and to approve the person, which is particularly useful as an electronic document approval process in a company. In recent years, the use of CAD has become common in companies, and in the approval process, the shape of the signature data can be attached to the CAD data as image data.

On the other hand, with the development of networks, various services have been provided on the networks. For example, in the so-called Internet,
2. Description of the Related Art Multimedia title providing services using the WWW (World Wide Web) and the like are widely performed. In the provision of such services, access may be granted only to certain qualified persons, similarly to services in general banks and the like. For services on such a network, "authentication" is a very important issue, as is the case with conventional services.

[0007] However, it is generally very difficult to use the above-mentioned biometric authentication data when authenticating the identity of the user. For example, each terminal needs to be provided with a device for inputting a retinal pattern, a fingerprint, a palm print or the like, and a mechanism for transmitting such a physical quantity via a network is also newly required.

For this reason, attention has been paid to using signature data as a biometric physical quantity. Since the signature data can be easily input by a so-called tablet, and includes not only two-dimensional data on a plane but also changes in pen pressure and the speed at which a signature is written, it is confirmed whether or not the user is the principal. Has excellent characteristics as authentication data for Furthermore, since tablets can be generally configured at low cost, the tablet has a feature that the cost of the terminal can be reduced.

[0009]

However, in the conventional general signature authentication method, the correct signature of the user is registered as only one single authentication data, which greatly restricts the authentication method. There was a problem that would.

[0010] In particular, in the case of signatures, different signatures are often used depending on the case. For example, a signature in the native language is used for domestic authentication, but a signature in English is used in international transactions. It is used every time. Also, even in the native language, there are cases where several different signature patterns are used.For example, when both the first and last names are used or when only one of them is used as a signature, the use of the full name signature and the initials signature or the kanji style It is convenient for the user to use a plurality of types of patterns at the time of actual signature input, such as properly using the characters.

The present invention has been made in view of such a conventional problem, and an object of the present invention is to provide a new multiple signature authentication method capable of treating a plurality of types of personal signatures in parallel as correct signature authentication data. To provide.

[0012]

Means for Solving the Problems The present invention includes: a storage step of plural kinds stored in the storage means the correct signature authentication data a Subscriber with a predetermined condition, verification requests for signing authentication data of a predetermined user from the outside According to the predetermined user
Signature authentication data that is determined from the predetermined conditions.
A search step of taking particular those from the storage means to, in response to the verification request, Eject by said search step
By comparing and verifying the specified correct signature authentication data with the signature authentication data related to the verification request,
If the signature authentication data relating to the verification request is
A collation step of determining whether the data is name authentication data, and a specific correct signature authentication defined from the predetermined condition.
This is a double signature authentication method characterized by using data for collation .

[0013]

[0014]

[0015]

[0016]

According to the present invention, a user can selectively use a plurality of registered signature authentication data in various cases, and associates usage conditions with corresponding signatures in advance, thereby enabling applications requiring authentication. For example, it is possible to specify registration signature data to be collated in an electronic decision such as settlement at a financial institution, electronic mail, in-house approval, etc., thereby improving the security of authentication.

[0018] Further, a partner using the signature verification system, for example, a business partner, a company, a financial institution or the like is designated,
It is also possible to use a different signature for each partner.

Further, by specifying signature data for identifying a person by month, day, day of the week, or time zone, it is possible to provide more detailed security.

[0020]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows an application server (A) provided on a network in this embodiment.
user host (User Host) 20 that uses the service of the application server 10
And a collation server (Server) 30 used for authentication of the user host 20 are arranged on a network.

A feature of the present embodiment is that the collation operation at the time of authentication of the user host 20 is not performed in the application server 10 but is provided on the network separately from the application server 10. This is performed using the matching server 30 that is in use. As described above, by providing the collation server 30 performing the collation operation on the network independently of the application server 10, each application server 10 can hold “correct” authentication data for authenticating the user host 20, There is no need to have a function for In FIG. 1, the application server 10
Although only one configuration is shown, it is also preferable to provide a plurality of application servers 10 on the network. In this case, the plurality of application servers 10 use one collation server 30 to perform “collation”. The operation can be entrusted, and the authentication data collation function conventionally provided in a plurality of application servers 10 can be integrated into one, and efficient resource operation becomes possible.

It is also preferable to provide a plurality of matching servers 30 on the network. Then, each application server 10 can use a suitable collation server according to the contents of the authentication. For example, it is conceivable to change the matching server 30 used when signature data is used as authentication data and when fingerprint data is used as authentication data. Alternatively, it is conceivable that each user specifies the collation server 30 which holds his / her authentication data.

As shown in FIG. 1, the matching server 3
By providing 0 on the network independently of the application server 10, the exchange of messages at the time of authentication becomes as shown by an arrow in FIG. 1, for example. As shown in FIG. 1A, first, the application server 10 requests the user host 20 to send signature authentication data (indicated by a in FIG. 1A).

The user host 20 inputs the user's signature data in response to the request a from the tablet, and returns it to the application server 10 together with the user's identification data (for example, a member number and a user name) (FIG. 1 ( In a) b
). The application server 10 stores this authentication data in advance and checks it against “authentic” signature authentication data to determine whether the user host 20 is a correct user.

A feature of the present invention is that a plurality of types of "valid" signature authentication data are registered. For example, both signatures in the native language and English are registered by the user in advance. In the present embodiment, the user inputs his or her signature from the tablet as any one of the signatures selected at the time of authentication, and the application server 10
The input single signature is compared with two types of registered signature authentication data, and if either one is verified,
It is determined that the user is valid. What is characteristic in the present embodiment is that this collation operation is outsourced to an external collation server 30. Therefore, the application server 10 sends a message including the authentication data and the identification data sent from the user host 20 to the collation server 30 and requests collation (indicated by c in FIG. 1A).

Upon receiving the message including the authentication data and the identification data sent from the application server 10, the verification server 30 checks whether the authentication data is valid authentication data. The collation server 30 internally stores a user name claiming that the user host 20 is the principal and two types of correct signature authentication data of the user as a database. Then, by searching this database, the correct signature authentication data of the user who claims to be the user host 20 is extracted. Then, the extracted authentication data and the signature authentication data sent from the application server 10 are compared and collated, and it is determined whether or not one of them matches, and the result is returned to the application server 10 ( This is indicated by d in FIG. 1 (a)). The application server 10 authenticates the user host 20 based on the collation result returned from the collation server 30.

In the present embodiment, since the part for performing the collation operation is provided on the network independently of the application server 10, the collation provided in common to the plurality of application servers 10 is provided. The function can be saved, and the reliability of the signature authentication operation can be ensured.

In FIG. 1A, the signature data (authentication data) sent from the user host 20 is supplied to the collation server 30 via the application server 10. Sending is also suitable.

FIG. 1B shows an example in which signature authentication data is sent directly from the user host 20 to the verification server 30. According to the example shown in FIG. 1B, first, the application server 10 requests the user host 20 to send the signature authentication data to the verification server 30 (see e in FIG. 1B). Shown).

The user host 20 inputs the user's signature data from the tablet in response to the request e, and sends the signature data to the collation server 30 (indicated by f in FIG. 1B). The application server 10 determines whether the user host 20 is a correct user or not, and entrusts the “collation” operation required for signature authentication to an external collation server 30 so to speak. For this reason, the verification server 30 stores the signature authentication data sent from the user host 20 in advance, and stores
Check with signature authentication data. As in the example shown in FIG. 1A, the collation server 30 stores a user name that claims that the user host 20 is the user and two types of correct signature authentication data of the user as a database. Holding. Then, by searching this database, two types of correct signature authentication data for the user whose user host 20 claims to be his / herself are extracted.
Then, the extracted signature authentication data is compared and collated with the signature authentication data sent from the user host 20, and the result is sent to the application server 10 (indicated by g in FIG. 1). The application server 10 authenticates the user host 20 based on the collation result returned from the collation server 30.

In each of FIGS. 1A and 1B, the application server 10 may be a server that provides various services such as a WWW server on the Internet or various databases.

FIG. 2 shows the user host 20, the application server 10, and the collation server 3 shown in FIG.
0 is a configuration block diagram showing a detailed configuration of 0.
FIG. 2A is a configuration diagram corresponding to FIG. As shown in FIG. 2A, the user host 20
It is composed of terminals such as personal computers,
A netscape (Netscape) 52 for connecting to the Internet and connecting to the WWW server 42 is provided. In this embodiment, the netscape 52 is used, but this is a mosaic (Mosaic).
For example, another WWW browser may be used. The user host 20 has, besides the netscape 52, a tablet (Tablet) 54 for the user to input signature data.
It has. Also, a tablet driver program 56 for controlling the tablet 54 and extracting signature data is provided. The tablet driver program 56 receives the request from the application server 10 to send the signature authentication data via the netscape 52 and receives the request from the application server 10.
4 is sent to the application server 10 with the signature authentication data obtained. It should be noted that the same reference numerals a, b, and c are used for the same message exchanges as the message exchanges a, b, c, and d shown in FIG.
c and d are also shown in FIG.

The application server 10 is a Unix server.
Often built on machines. The application server 10 includes a WWW server 42 for providing a multimedia title as shown in FIG.
A signature verification request program 44 for confirming the validity of the user is provided. The collation server 30 is constructed on a machine such as Unix like the application server 10, and has registration data 62 in which a valid user name and two types of signature authentication data of the user are registered. . Then, based on the user name (user identification code) transmitted from the signature verification request program 44 and the signature authentication data transmitted from the user host 20, verification is performed with any of the registered signatures. The collation result indicating whether there is a match is returned to the signature collation request program 44 of the application server 10.

The configuration diagram corresponding to FIG. 1B is shown in FIG.
This is shown in (b). The configurations of the application server 10, the user host 20, and the matching server 30 in FIG. 2B are exactly the same as the configurations shown in FIG. 2A. The difference is that a request for collation is issued directly from the driver program of the user host 20 to the collation server 30. The only difference is whether the collation server receives the signature authentication data to be collated from the user host 20 or via the application server 10. Other configurations are the same as those shown in FIGS. 2A and 2B. Is exactly the same. Also, FIG. 2B corresponds to FIG. 1B, and the exchanged messages include e,
Symbols f and g are assigned.

In the present embodiment, the registration data 62 of the collation server 30 is managed by a relational database (hereinafter, referred to as RDB). FIG. 3 shows the state of the registration data in the RDB. As shown in FIG. 3, the registration data is recorded in the form of a table in which predetermined data is recorded for each valid user. As shown in the figure, first, a flag (flag) is a flag for indicating various states of the system, and is used as a deletion flag (for example, indicating whether the user has been deleted from the system) or the like. Can be The system unique key (SysUniq Key) is a system key given to each user, and is uniquely determined in a table (shown in FIG. 3) in the matching server 30.
The registered tablet type indicates the type of tablet used by the user. In addition, signature data (Sig
“nature data” is time-series data representing the movement of the electronic pen moving on the tablet.
It is composed of two types of signature registration data "Signature 1" and "Signature 2". Each signature data contains not only information indicating the two-dimensional position but also information on pen pressure and pen speed, so it is possible to accurately authenticate the identity of the user. It is.

As described above, the RDB in the collation server 30
Since the system unique key and the two types of signature data are registered in the server, the signature data sent from the application server 10 and the signature data transmitted using the system unique key indicating the user are used. Can be determined as valid based on whether or not matches any of the signature registration data. The contents of the result of this determination will be described later.

In the RDB according to the present embodiment, in addition to the system unique key and the signature data, a system required item (System required items)
Is stored. As shown in FIG. 3, the system request items include the user name (Name) and the user's birthday (Date of bi).
rth) and the user's telephone number (Phone #) are registered. These system requirements are used in place of the system unique key. That is, the system unique key is a key for identifying the user held by the application server and the matching server as described later, but the user must remember the system unique key given to him / her. Not necessarily. Therefore, when the user wants to confirm the registered signature data, it is desirable that there is a means for specifying the user by using a means other than the system unique key. In such a case, in addition to the system unique key, the user can be identified by the user's name, birthday, telephone number, and the like.

As described above, in the present embodiment, not only the system authentication key but also the “correct” authentication data is used.
Since it is configured to be able to read out even predetermined data, it is possible to confirm the signature authentication data from a telephone number or the like even if the user has forgotten the system unique key.

Further, in the present embodiment, as shown in FIG. 3, an optional field (Opti
online fields) are provided. The data registered in this optional field is so-called system audit data, and is management data used when a network administrator manages the operation of the matching server 30. As shown in FIG. 3, the data for management includes a data creation date (Creation Date).
date), the creator of the data (Creation h
ost) and the last access date (Last acc.
date) and the last accessor (Last acc.
by), other access count (access cou)
nt) and the number of times matching failed (failure cou
nt) can be registered.

The application server 10 also has an RDB in which information about the user is registered, corresponding to the RDB in the collation server 30. Contents registered in the RDB in the application server 10 are shown in FIG. As shown in FIG. 4, various types of registration data are registered for each user. FIG.
As shown in (1), first, the “verification server name” indicates which verification server should be used to verify the signature authentication data sent by the user. FIG.
Although only one collation server 30 is shown in the configuration diagram shown in FIG. 1, a plurality of collation servers 30 may exist in the network as a configuration. For example, each user may want to use a collation server 30 that is easy for him to contact, and the application server 10 may want to change the collation server for each user for administrative reasons. There will be cases.

The flag (flag) and system unique key (Sys Uniq Key) shown in FIG. 4 are the same as the flag and system unique key in FIG. This system unique key is uniquely determined in the RDB of the collation server 30 as described above. In other words, there is a possibility that the same system unique key is assigned to users having different collation servers 30. Therefore, the user is strictly identified by combining the system unique key and the matching server name. Application user key (App. User
key) is a key indicating whether or not the service provided by the application server 10 can be received. In some cases, as shown in FIG. 4, additional application user keys (Additional app.
user key) may be set. In addition, as shown in FIG.
ate) and the last access date (Last acc. da)
te), the last accessor (Last acc. b)
y), the number of accesses (access count), the number of times the verification failed (failure count), and the like are registered corresponding to the RDB in the verification server 30 shown in FIG. Although the specific item names are not shown, the application optional field (A
application optionalfield
It is also preferable to register predetermined registration data used by the application in s).

FIG. 5 is an explanatory diagram of a protocol supported by the matching server 30 according to the present embodiment. As shown in FIG. 5, first, in the protocol “key registration”, the application server 10 sends a message including predetermined required items to the collation server 30. The collation server registers these required items in the RDB and generates a system unique key. This system unique key is registered in the RDB and returned to the application server 10. In this way,
The system unique key that identifies the user is the matching server 3
0 is generated. This system unique key is also registered in the RDB in the application server 10, and the collation server 30 and the application server 10 share the system unique key.

Next, in the protocol “Registration of signature data”, the application server 10 sends the system unique key, three first signature data, three second signature data, tablet type and the like to the verification server 30. Then, the two types of “correct” signature data are registered in the RDB in the verification server 30. Here, sending three pieces of signature data for each signature is performed by obtaining an average value of the signature data in the verification server and calculating the average value in the RDB.
It is for registering within. If the registration is completed normally, a return value "ok" is returned to the application server 10,
If the registration has already been made, "error" is returned as a return value. If the three pieces of signature data are significantly different from each other, the reliability as the signature data is low.
"le" as a return value.

In the protocol “preparation for collation”, the application server 10 sends only the system unique key to the collation server 30 and causes the RDB to call two kinds of “correct” signature authentication data from the RDB.
As described above, by promptly calling the signature authentication data prior to the actual protocol for verifying the signature authentication data, a quick verification process can be performed as described later. This protocol is performed for speeding up the processing. If speeding up is not necessary, the protocol may be omitted and a “collation” protocol described later may be directly issued. If the call of the “correct” signature authentication data is completed normally, the message ID is returned to the application server 10, but if an error occurs, “error” is returned to the application server 10 as a return value.

The protocol "collation" is performed by the user host 20
Alternatively, the protocol is such that the application server 10 sends the system unique key, the signature data, the tablet type, and the message ID to the collation server 30 to perform the collation operation. As the message ID, the message ID returned as a return value when the “collation preparation” protocol has been issued first is used. As will be described later, the collation result is sent to the application server 10. At this time, the message ID is used as a tag for identifying the user whose signature is authenticated.
That is, in the present embodiment, this message I
D is an identification number for signature authentication, and is also an ID indicating that the signature authentication data has already been called in the cache. In this case, the first generation of the message ID is performed by the collation server 30 and is added to the message at the time of responding to the collation preparation request.

On the other hand, if the “verification preparation” protocol has not been issued, this message ID merely serves as an identifier for identifying the user for whom the signature authentication is to be performed. In this case message I
The first creation of D is the application server 10.

The collation server 30 can know whether or not the signature authentication data has already been read into the cache, based on whether or not the message ID is assigned by itself. If two types of "correct" signature authentication data have already been called, the data is compared and collated with the sent signature authentication data. When the “correct” signature authentication data has not been called, the “correct” signature authentication data is newly called from the RDB, and the comparison / collation operation is performed.

As a result of the comparison and collation, when it is determined that the input signature and one of the registered signatures are very close and correct signature authentication data, “yes” is sent to the application server 10 as a return value. . On the other hand, if the sent signature authentication data is completely different from any “correct” authentication data, “no” is returned as the return value.
Is sent. As a result of the comparison and collation, if it is not clear whether or not the data is correct signature authentication data, "may"
"be" is sent to the application server 10. The measures to be taken in the unknown case will be different for each application server 10, but for example, measures such as re-signing the signature to the user will be taken. In the case where “correct” signature authentication data to be compared / matched is not found, “error” is returned to the application server 10 as a return value.

Next, the manner in which the signature of an actual user is authenticated will be described with reference to FIG. Hereinafter, this user is referred to as an application client (FIG. 6).
First, the application client issues a connection request to the application server 10 via the user host 20.

In response, the application server 1
0 requests the application client to input an application key. In response to this, a prompt for inputting the application key is displayed on the display device of the user host 20.

When the application client inputs a predetermined key on the user host 20, the data is sent to the application server 10.

Upon receiving this key data, the application server 10 sends a request for signature data collation preparation to the collation server 30. This collation preparation request is made for speeding up the processing as described above, and can be omitted.

When the collation server 30 receives the collation preparation request, as described above, the two types of signature authentication data are
And sends the message ID and encryption key to the application server 10. The encryption key is a key used for encrypting communication data, and need not be sent if encryption is not required.

The application server 10 that has received the message ID and the like outputs a signature input request to make the application client input a signature.

In response to the signature input request, the user host 2
At 0, the signature input program starts. Based on the activation of this program, the application client signs using the tablet 54 provided in the user host 20.

In the configuration corresponding to FIG. 1A, the user host 20 transmits the signature data input from the tablet 54 to the application server 10. Then, the application server 10 issues a collation request including the received signature data to the collation server 30.
On the other hand, in the configuration corresponding to FIG. 1B, the user host 20 sends the signature data input from the tablet 54 to the verification server 30 (a verification request). At this time, FIG.
As shown in (1), the key data and the message ID are sent to the verification server 30 together with the signature data.

The collation server 30 performs collation based on the collation request, and returns the result to the application server 10. When the collation request is sent from the application server 10, the destination of the collation result is the application server 10 that issued the collation request. on the other hand,
When the collation request is sent from the user host 20, the message ID sent simultaneously with the collation request
Based on the above, the application server 10 to which the matching result is to be transmitted is specified.

The application server 10 performs authentication based on the collation result. The operation at this time differs depending on each application server 10, but if the authentication data matches, "authentication" will be given. If they do not match, "authentication" will not be given or the signature will be redone. .

As described above, according to the present embodiment, the collation operation performed at the time of authentication is outsourced to an external collation server, so that the load on the application server is reduced and the collation operation is simplified. And the use of a single matching server by a plurality of application servers leads to more effective use of resources on the network.

According to the above-described embodiment, if any one of the plural types of registered signature authentication data matches the data input by the user at the time of authentication, authentication of identity verification is given. As another embodiment, it is also possible to specify a plurality of types of registered signature data in accordance with predetermined conditions. The certification server is based on various conditions input from the signature verification request program, for example, differences in uses such as monetary settlement and electronic approval, differences in designated counterparties, and differences in months, days, days of the week, or time zones. A predetermined specific single registration signature data is used for collation.

According to this embodiment, only the user and the verification server know specific conditions, and the security can be further improved.

[0063]

[0064]

[0065]

As described above , according to the present invention, different registered signature data can be specified in accordance with predetermined conditions, and signatures can be selectively used in accordance with the use, the partner, or the time. It is possible to provide an authentication system with extremely high security.

[Brief description of the drawings]

FIG. 1 is an explanatory diagram illustrating a configuration of an embodiment of the present invention.

FIG. 2 is an explanatory diagram illustrating details of a configuration according to an embodiment of the present invention.

FIG. 3 is an explanatory diagram illustrating a configuration of an RDB in a collation server.

FIG. 4 is an explanatory diagram illustrating a configuration of an RDB in an application server.

FIG. 5 is an explanatory diagram showing a protocol supported by the matching server.

FIG. 6 is an explanatory diagram showing exchange of messages in the present embodiment.

[Explanation of symbols]

10 application servers, 20 user hosts,
30 verification server, 42 WWW server, 44 signature verification request program, 52 netscape, 54 tablet, 56 tablet driver program, 62
Registration data.

Claims (1)

(57) [Claims] [Claim 1] the correct signature authentication data of the user specified conditions
A storage step of storing a plurality of types in a storage means together with a case, and collation relating to signature authentication data of a predetermined external user
Upon request, the correct signature authentication data of the given user
A specific one determined from the predetermined conditions
A retrieval step to retrieve from the storage means, and in response to the collation request, retrieved by the retrieval step
By comparing and verifying specific correct signature authentication data with the signature authentication data related to the verification request,
A verification step of determining whether the signature authentication data relating to the request is the specific correct signature authentication data, and a specific correct signature determined from the predetermined condition.
A double signature authentication method characterized by using authentication data for verification .