JP2007041801A - Controller of transaction system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a controller for controlling a transaction system prevented from being used illegally by a third party who acquires a security code illegally. <P>SOLUTION: The controller, for controlling the transaction system that allows transactions using a network by authenticating users based on security codes inputted by the users, stores a conversion table for converting the security codes inputted, and displays a transaction input screen on a terminal, including a correspondence table between inputs and outputs to the conversion table. The security codes inputted from terminals are converted using the conversion table and the users are authenticated based on the security codes after the conversion. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a control apparatus that controls a transaction system, and more particularly to a control apparatus that controls a transaction system that performs a transaction through a network by authenticating a user with a security code input by the user.

In a transaction system that conducts commercial transactions and financial transactions via a network, the user is authenticated by checking whether or not the security code (for example, a password) input by the user from the terminal matches a pre-registered code. Control that enables transactions only to the users who have been made is performed.
JP 11-338799 A

  However, if the security code is obtained by a third party, for example, if it is illegally obtained on the network or from the keyboard key entry history (also called key logger) entered by the user, unauthorized use by impersonation is permitted. It will be.

  In particular, when the transaction system is a bank system, a change in information in an account or an illegal payment operation occurs, causing direct damage to the user and impairing the reliability of the system.

  In view of the above-described conventional problems, the present invention provides a control device that controls a transaction system that eliminates unauthorized use of a security code by unauthorized acquisition by a third party.

  In order to solve this problem, the control device of the present invention is a control device that controls a transaction system that performs a transaction through a network by authenticating a user with a security code input by the user, and the security code that is input Storage means for converting a conversion table, display control means for displaying a transaction input screen including an input / output correspondence table in the conversion table on a terminal, and a security code input from the terminal using the conversion table And authenticating means for authenticating the user with the converted security code.

  Here, the storage means has a plurality of conversion tables, and further includes selection means for selecting one conversion table at random from the plurality of conversion tables before displaying the transaction input screen. The conversion table is randomly generated before the transaction input screen is displayed and stored in the storage means. The transaction system is a bank system via a network, and the transaction is payment between accounts.

  As described above, according to the present invention, it is possible to provide a control device that controls a transaction system that eliminates unauthorized use due to unauthorized acquisition of a security code by a third party.

  The configuration and operation of a control device for controlling a transaction system according to an embodiment of the present invention will be described below in detail with reference to the accompanying drawings. In the following description, the transaction system of the present invention will be described using the e-bank system as an example. However, unauthorized acquisition and unauthorized use of the security code is not limited to the e-bank system, and can be applied to other transaction systems. These are possible and are included in the present invention.

<Configuration example of transaction system of this embodiment (FIG. 1)>
FIG. 1 is a block diagram illustrating a configuration example of a transaction system according to the present embodiment.

  In FIG. 1, reference numeral 10 denotes an e-bank server that controls an e-bank system that is a transaction system of the present embodiment. The e-bank server 10 controls the account database 20 (including a deposit database, etc., but not shown), and the like, thereby constructing a virtual bank system.

  The e-bank server 10 may be realized by a general-purpose computer or a dedicated computer. As basic components, the e-bank server 10 includes a CPU 11 for calculation / control, a ROM 12 for storing fixed programs and parameters, a dedicated network 30 for ATM, or a user. Communication control unit 13 for controlling communication via public network 60 for access from, RAM 14 having an area for loading a program executed by CPU 11 and an area for temporarily storing parameters, a disk, a CD, a memory card, etc. And an external storage unit 15 for storing programs and databases.

  In this example, the RAM 14 stores, as a data storage area, an area 14a for storing a message received from the PCs 70-1 to 70-M, an area 14b for storing a security code input by the user included in the received message, and the PCs 70-1 to 70-1. An area 14c for storing a transmission message to be sent to 70-M; and an area 14d for storing a pointer pointing to a conversion table used for converting a security code input by the user into a security code for authentication. It also has a program load area 14e. Note that the data in the data storage area indicates data essential to the present embodiment, and other data and parameters for functioning as the e-bank server 10 are not shown in order to avoid complications. Description is omitted in this application. Note that the conversion table itself may be stored in the RAM 14 instead of the conversion table pointer.

  The external storage unit 15 includes, as a data storage area, an area 15a for storing a conversion table used for converting a security code input by a user into a security code for authentication. A reference conversion table is stored in the security code conversion table / storage area 15a, and a plurality of conversion tables are stored in advance even if processing is performed while generating a conversion table that is actually used from this point. Even if processing is performed by selecting at random, a conversion table generated at random may be stored.

  Further, as a program storage area, an area 15b for storing a module for converting a security code using a security code conversion table 15a, which corresponds to a flowchart to be described later, and user authentication is performed based on the converted security code. And an area 15c for storing modules. The modules in the program storage area show programs essential to the present embodiment, and other programs (including OS etc.) for functioning as the ebank server 10 are shown in order to avoid complexity. It is not shown and description is omitted in this application.

  A dedicated network 30 connects the e-bank server 10 and the ATM. In this example, postal saving ATMs 40-1 to 40-n and bank ATMs 50-1 to 50-m are connected via the dedicated network 30. Note that the number of such dedicated networks 30 is not limited to one, and a plurality of dedicated networks may be connected, or a plurality of dedicated networks 30 are connected to each other and another dedicated network is connected via a certain dedicated network. It may be configured as follows.

  Reference numeral 60 denotes a public network or a network such as the Internet. The network 60 may be wired, wireless, or a mixed network thereof. General PCs 70-1 to 70 -M and mobile phones 80-1 to 80 -N are connected via the public network 60.

  As processing of this embodiment, the connection from the PCs 70-1 to 70-M to the e-bank server 10 is approved, the user is authenticated by the security code, authenticated and requested, and the transaction is executed.

<Operation example of transaction system of this embodiment>
FIG. 2 is a diagram showing an example of a transaction input screen displayed on the screen of the PC 70 in the e-bank system shown in FIG.

  In FIG. 2, a transaction for paying 1 yen of the ordinary account 000930 is input to the newly opened account, the ebank branch 204, from the user account, the ordinary account 000595 of the ebank branch 201.

  Here, in order to execute this transaction, a personal identification number is input as a security code, and an execution button is clicked. The conversion table 90 is displayed so that the code number is input by the alphabet corresponding to the numbers from 0 to 9, not the number input as it is. In the example of FIG. 2, a to j correspond to 0 to 9 in ascending order. For example, if 4 digits “1234” is the password, “bcde” is entered.

  In this way, it is “bcde” that is illegally obtained from both the keyboard history and the network, and if the correspondence is randomly changed for each transaction, the personal identification number “1234” is It will be protected from unauthorized use.

(Example of operation procedure of transaction system of this embodiment: FIG. 3)
FIG. 3 is a flowchart showing a processing procedure between the PC 70 and the e-bank server 10 which is the control device of the present embodiment. In FIG. 3, the left side shows the processing procedure of the PC, the right side shows the processing procedure of the ebank server, and the broken line connecting both processing procedures shows the information transmitted via the network.

  First, when a transaction request is made via the PC 70 in step S31, the server 10 waiting in step S41 receives this request and proceeds to step S42 to set a conversion table used in the current transaction. Such a conversion table may be fixed for a certain period as long as it is changed periodically and / or under predetermined conditions. In addition, as described above, it is conceivable that each transaction is randomly generated from the reference conversion table, one that is selected randomly from a plurality of conversion tables, one that is randomly generated for each transaction, etc. . In step S43, the server 10 sends an input screen as shown in FIG. 2 including the code correspondence table of the set conversion table.

  After receiving the input screen from the server 10, the PC 70 waiting for the input screen in step S32 after the transaction request in step S31 displays it in step S33, and inputs the transaction settings. In step S34, all the settings necessary for the transaction are completed and the execution button is clicked. When the execution button is clicked, the process proceeds to step S35, and the transaction content including the security code (password) is stored in the server 10. Send to. It should be noted that inadequacy of transaction details other than the security code (password) may be checked in step S33 of the PC 70 to notify the user of the error, or the transaction content is received on the server 10 side. You may check later.

  The server 10 waits for the transaction content in step S44, and when the transaction content is received, proceeds to step S45 to convert the received security code into a security code for authentication using the conversion table set in step S42. Next, the security code converted in step S46 is compared with a security code registered in advance in the account database 20 to determine whether or not they match. If they match, the transaction is executed in step S47 with authentication OK and the completion of the transaction is notified to the PC 70. If they do not match, the PC 70 is informed in step S48 that authentication cannot be performed.

  The PC 70 waits for a transaction result notification (from S47 or S48) in step S36, and if there is a notification, proceeds to step S37 to display the transaction result. If authentication is not possible or if there is a mistake in the transaction contents, not shown, the process returns to step S31 or S33, the transaction contents or security code is input again, and the transaction is requested again.

(Example of conversion table data)
FIG. 4 shows other examples of the security code conversion table. The present invention is not limited to these conversion tables, and various other examples can be easily assumed by those skilled in the art.

  FIG. 4A is an example in which the correspondence between numbers and alphabets in ascending order as shown in FIG. FIG. 4B shows an example in which kana-kana input is supported instead of alphabet. (C) in FIG. 4 corresponds to a combination of two numbers for each digit of the password.

  Such selection of the conversion table is easy to decipher when it is simple, while input errors increase when it is complicated, so that an appropriate conversion table may be selected based on this. In addition, since the ease of decoding can be prevented by changing the conversion table at random every transaction, a simple conversion table as shown in FIG. 2 is desirable from the user's operation side.

  The technical idea of the present invention is not limited to a banking system via a network, and is effective in a system that requires user authentication, particularly when there is a keyboard history, etc. Can be applied.

It is a block diagram which shows the structural example of the transaction system which concerns on this embodiment. It is a figure which shows an example of the transaction input screen displayed on the screen of PC70 in the e-bank system of FIG. It is a flowchart which shows the process sequence of PC70 and the ebank server 10 which is a control apparatus of this embodiment. Several other examples of the security code conversion table are shown.

Claims (4)

A control device that controls a transaction system that authenticates a user by a security code input by the user and performs a transaction through a network,
Storage means for storing a conversion table for converting the input security code;
Display control means for causing a terminal to display a transaction input screen including an input / output correspondence table in the conversion table;
A control apparatus comprising: an authentication unit that converts a security code input from the terminal using the conversion table and authenticates a user using the converted security code.   2. The storage unit according to claim 1, further comprising a selection unit that randomly selects one conversion table from the plurality of conversion tables before displaying the transaction input screen. Control device.   The control device according to claim 1, wherein the conversion table is randomly generated and stored in a storage unit before the transaction input screen is displayed.   4. The control apparatus according to claim 1, wherein the transaction system is a bank system via a network, and the transaction is payment between accounts.

Images