JP2012048728A - Token-based transaction authentication under condition of presence of individual - Google Patents

Abstract

PROBLEM TO BE SOLVED: To protect an authentication token connected to a computer from being hijacked by a malicious program.SOLUTION: In order to authenticate a transaction between a host and a server, a token is connected to the host. The host receives an identification certificate of a user. The identification certificate is then verified by the token and/or the server. When the token detects an artificial specified operation, the token generates token authentication data, and the host transmits the token authentication data to the server. Upon receiving the authentication data, the server authenticates the transaction.

Description

The present invention relates to a hardware token for authenticating a transaction on a communication network.

The Internet and mobile communication networks are increasingly used for financial transactions, primarily in the context of electronic commerce. For most transactions, the identity of the person requesting the transaction must be certified. Communication networks are often unstable, and it is commonplace for malicious software to exist. As a result, personal personal computers and mobile phones are not considered trustworthy, and whatever you type into a personal computer or mobile phone and communicate using such a device can be hacked by others. To be exposed. As a result, there are hundreds of millions of dollars per year from fraudulent transactions,
It is borne by consumers, distributors and financial institutions.

Special electronic hardware in the form of “tokens” or “smart cards” has been developed to provide more secure identification. Such hardware combines a structure that cannot be tampered with cryptography to withstand normal attacks well. Techniques known as “challenge and response”, “one-time password” or “time-dependent key” ensure that a session cannot be reused for another transaction even if the transaction session with the token is blocked. ing.

Therefore, when a token issued by a financial institution is coupled to a personal computer using, for example, a USB interface or a smart card reader, the authentication session between the financial institution server and the personal computer satisfactorily verifies the authenticity of the token. . As part of the verification, the token sends token authentication data to the server. Such verification of the authenticity of the token is referred to in the text as “authentication” of the token. However, what really matters is not the authenticity of the token, but the authenticity of the token owner. This indicates that there are still two loopholes involved in token misuse. 1) If a token is physically lost or stolen, it can be used to steal the ID of its legal owner. 2) A malicious program in the computer can illegally generate a transaction that will benefit the criminal by manipulating the token associated with the computer. In order to solve the first loophole, the security provider can identify "what you have" (ie token), "what you know" (eg PIN code) and "who you are Multi-combination combined with at least one of “is there” (eg biological attribute such as fingerprint)
A factor authentication paradigm is being developed.

Cases of computers operating under the control of malicious programs are personal computers infected by viruses or computers used by an unspecified number of people in Internet cafes or office service stores. In both cases, a PIN entered from a computer keyboard or a fingerprint image read by a device coupled to a personal computer can be intercepted by a malicious program and then reused to activate a token for fraudulent transactions. There is sex. This risk is greatly increased if the token is left inserted in the host for a long time. Token is, for example, USB
If it forms part of a multipurpose device such as a flash memory key, it can remain coupled to the computer for hours. An effective remedy for such vulnerabilities is to include a PIN pad or fingerprint reader in the token itself or in a multipurpose device that includes the token. However, such additions are often undesirable because they increase the size and cost of the token.

Another method for detecting human presence is called “CAPTCHA”. For example,
See "http://www.captcha.net." The user is required to type a random character string visually presented to the user using a font that is readable by humans but not readable by malicious programs. The disadvantage of this technology is
A malicious program is a so-called “arbiter” attack that sends CAPTCHA graphics to human accomplices elsewhere.

Thus, a token can be used to maliciously connect an authentication token coupled to a computer without having to include an input device for receiving a PIN or converting a user's biological attributes into biometric information. The need for a method of protecting against hijacking is widely recognized and it is highly advantageous to obtain such a method.

It is an object of the present invention to turn an authentication token connected to a computer into a malicious program without requiring that the token include an input device for receiving a PIN or measuring a biological attribute. It is to provide a system and function to protect against being hijacked. More specifically, the object of the present invention is to execute a malicious program running on a user's computer using a PIN intercepted during the last legitimate authentication session and using a token connected to the computer. To protect the token user from unintentional and unobtrusive authentication sessions.

A “token” is a unique ID that contains data and / or is associated with a device
Means a portable device that includes the processing power to authenticate. Exemplary form factors for tokens include smart cards, USB keys, and expansion cards for phones or handheld computers. Even if the token is a standalone device,
Alternatively, it may form part of another device such as a USB flash memory disk.

“Host” means a processing and communication device for performing transactions with a “server” of a “provider”, typically a merchant or financial institution. Examples of hosts include personal desktop or laptop computers, cell phones, 2-way pagers, and handheld computers.

A “user” means an individual who wants to perform a transaction with a provider and needs to authenticate his or her identity or operate on behalf of an organization that requires authentication of the identity to execute the transaction.

“Transaction” means a business process between a user and a provider with mutual commitment of the parties.

“Personal identification number” or “PIN” means a secret character string represented by a number that is known to the individual and that authenticates the individual. According to one common paradigm, PIN is
Known only to users and providers. According to an alternative common paradigm, the PIN is known only to the user and his (female) token. Therefore, it functions to unlock the token. “Password” or “Passphrase” is PIN for that purpose.
But usually also includes letters and symbols. Thus, a PIN is a special case of a password. A “biological attribute” is a characteristic of an individual's body (eg, a fingerprint or iris pattern) that is read by a suitable sensor and digitized. Therefore, digital data generated by the sensor is referred to as “biological information” in the text. “User identification” means receiving and verifying either a PIN, password, or biometric information. PIN, password, and biometric information are examples of identification credentials. “Identification proof” means data that is expected to be received only from an individual authorized to request a transaction. “What you know” (for example, a password or PIN) or “You are” (
For example, biometric information).

“Authorization” means reliable verification of user identification, combining information from tokens and user IDs. The combination of information from the token and user ID is
Two separate pieces of essential information are used to reach the provider's server, or the user ID is verified locally to unlock and operate the token, and then only the information from the token is Server (or on dedicated hardware or by an authentication service associated with the provider's server).

“Malicious program” means software code that has been illegally installed on a host for the purpose of generating fraudulent transactions via fake authentication. A malicious program intercepts a PIN, password or biometric information entered via an input device (eg, a conventional keyboard or fingerprint reader) coupled to the host, and accesses a token connected to the host Is possible.

“Human-defined action” means an action defined for a specific purpose that excludes actions that can only be performed by individuals and that are generated by machines that may serve the same purpose.
For example, the purpose of the human prescribed action of the present invention is by the token connected to the host:
It is to detect the presence of an individual. This can be accomplished, for example, by requiring the token to be disconnected and reconnected, or by providing the token with a button that must be pressed to verify the presence of the individual.

“Anonymous interaction” means an interaction by an individual with a device or system. For example, this action can be applied to individuals who have restricted information such as PINs or passwords.
It does not require the individual to be identified, nor does he require the individual to have attributes such as biological features that are unique to the individual and identify the individual. Thus, anonymous interactions verify the presence of an individual but do not identify the individual.

An object of the present invention is to prevent a malicious program on a host that intercepts user ID data input in a regular transaction from transparently generating a transaction and unauthorizedly authorizing the transaction on behalf of the user. That is.

The goal of the present invention can be accomplished by embedding a keypad and / or fingerprint sensor in the body of the token, but with such additions, the token becomes more bulky and more expensive. It will be a thing. The present invention, therefore, without the use of a PIN or password keypad or biometric sensor embedded in the token,
Aiming to achieve the above objectives.

Thus, according to the present invention, there is provided a method comprising the following steps for authorizing a host-server transaction initiated by a host user. (A) A step of connecting a token to the host. (B) receiving a user identification certificate by the host; (C) verifying the identity certificate with at least one device selected from the group consisting of a token and a server; (D) detecting a prescribed action by a human by means of a token; (E) Subject to detection, by the token,
Generating token authentication data; (F) Sending token authentication data to the server by the host. And (g) authorizing the transaction by the server on the condition that the token authentication data has been received.

In addition, according to the present invention, there is provided a device for authenticating a transaction between a host and a server, including: (A) Device for interacting with the host
Interface. (B) A connector for detachably connecting the device interface to the host. And (c) a controller operable to authenticate a transaction only once upon receipt of a transaction authentication request from the host via the device interface, subject to detection by the controller of a prescribed action by an anonymous human.

Furthermore, according to the present invention, there is provided a method including the following steps for confirming the presence of an individual in a peripheral device connected to the host by the individual. (A) providing a host user input interface to the host; (B) Providing a device user output interface to the peripheral device. (C) generating at least one output at the device user output interface by the peripheral device; (D) For each of the at least one output, monitoring the host user input interface by the host to capture the corresponding input. And (e) reporting each of the corresponding inputs to the peripheral device by the host. An individual's presence is confirmed only when each report is received by a peripheral device.

In addition, according to the present invention, there is provided a device for authenticating a transaction between a host and a server, including: (A) Device for interacting with the host
Interface. (B) User interface. And (c) upon receiving a transaction authentication request from the host via the device interface, verifying the server,
And a controller operable to indicate successful verification via the user interface.

Furthermore, according to the present invention, there is provided a method including the following steps for authenticating a transaction between a host and a server. (A) A step of connecting a token to the host. (B) verifying the server with the token; And (c) displaying a successful verification by token via the token user interface.

The first method of the present invention is a method for authorizing a host-server transaction initiated by a host user. According to the basic method, the token is connected to the host. The host receives a user identity certificate. Identity credentials are verified by token, by server, or by both token and server. To ensure that the identity proof is not generated by a malicious program running on the host, the token generates token authentication data only if the token detects a prescribed human action. To do. The host then sends token authentication data to the server. If the server receives token authentication data, the server authorizes the transaction.

The identification certificate received by the host is preferably a password such as a PIN, or alternatively, biometric information.

Preferably, the human defined action that the token detects includes an interaction between the individual and the token that is performed at least in part while the token is operatively connected to the host. The fact that the interaction must be performed at least partially while the token is operatively connected to the host is simply from the scope of the interaction definition, without first separating the token from the host. Excludes connecting token to host. In this regard, separating the token from the host should be performed while the token is operatively connected to the host, since the token is actually operatively connected to the host at the start of the operation. Note that it is considered an operation.

The scope of the present invention includes interactions that identify an individual, eg, through receipt of an identification proof, but because the identification proof is received by the host rather than by the token, the token may be, for example, a keypad or biometric There is no need to include a large and costly user interface such as a sensor. Nevertheless, it is within the scope of the present invention to provide a token with a small, inexpensive user interface, such as a button or LED, to detect the presence of an individual without identifying the individual. Combining user identification via the host user interface with anonymous user presence detection by token via a minimal token user interface is an important element of the present invention.

The anonymous interaction is preferably a direct interaction between the individual and the token. An interaction is “direct” means that it is not arbitrated by another entity, eg, a host. An example of such a direct interaction is to decouple the token from the host, then reconnect the token to the host, and manipulate the (minimal) user interface that composes the token anonymously Including that. Another such direct interaction requires the token to be provided with a user interface to signal that the token will soon generate authentication data. The associated interaction is to leave the token operably connected to the host for at least a predetermined time after the signal.

Alternatively, anonymous interactions are arbitrated by the host rather than directly on the token. One example of such arbitration interaction where the token comprises a user interface is interacting with the host, for example by pressing a key on the host keyboard. In this case, the host receives corresponding user input from the token user interface that is substantially synchronized to each of the at least one signal, and preferably substantially synchronized to each of the plurality of signals. Upon receiving input, the host immediately reports receipt of input to the token. The reception of these reports substantially synchronized with the generation of the corresponding signal is
Configures the detection of prescribed actions by humans with tokens. “Synchronization” in this context is defined taking into account normal human reaction time. For example, pressing a key within 1 second after listening to a signal means synchronizing with the signal, but pressing a key after 20 seconds after listening to the signal does not mean synchronizing with the signal.

The method also preferably includes providing a user interface to the token, validating the server with the token, and indicating with the token whether the validation was successful. In this case, the prescribed action by humans is conditional on successful verification. If verification fails, the user refrains from interacting with the token.

A basic first device of the present invention for authenticating a transaction between a host and a server is a device interface for interacting with the host, and a connector for removably connecting the device to the host. And a controller that authenticates the transaction only once when a transaction authentication request is received from the host via the device interface and the prescribed action by the anonymous human is detected by the controller.

An example of such a human prescribed action is within a predetermined time period before an authentication request is received,
To connect the device interface to the host. This state is detected through the device interface.

Another example of human prescribed behavior requires that the device also include a user interface. One such example is interaction with the user interface to allow authentication. Another such example is to leave the device interface operatively connected to the host for at least a predetermined time after the user interface indicates that an authentication request has been received. It is. Another such example is interacting with the host in substantial synchronization with each of the at least one signal from the user interface. However, in this case, it is preferable to synchronize with each of a plurality of signals from the user interface. In a later example, detecting a prescribed action by a human by the controller includes a controller for receiving an interaction notification from the host.

Authentication by the controller is also preferably contingent upon receipt of identification credentials (eg, password, PIN or biometric information) entered at the host by the controller via the device interface and verification of the identification credentials by the controller .

The device also includes a user interface, and the controller also
Preferably, the server is operable and operable to display via the user interface whether the server verification was successful.

The device also preferably includes a functional component, such as a memory, to provide functions not related to transaction authentication, such as storing data received from the host via the device interface. If the authentication request is pending when the device interface is connected to the host, the controller will satisfy the requirement because the requirement has been met without providing that functionality to the host, Alternatively, it is most preferred that the controller handle the authentication request by rejecting the authentication request because the requirements were not met, otherwise the controller provides the function to the host if the authentication request is not a concern. After handling the authentication request, the controller
When a request is received via the device interface to provide functionality to the host, the controller prompts the user to detach the device interface from the host and then reconnect the device interface to the host. Is most preferred.
Also, if the controller receives an authentication request while providing functionality to the host, the controller will prompt the user to disconnect the device interface from the host and then reconnect the device interface to the host. It is most preferable to prompt.

Alternatively, after handling an authentication request, when the controller receives a request to provide functionality to the host via the device interface, the controller begins to provide functionality to the host. If the controller receives an authentication request while providing functionality to the host, the controller stops providing functionality to the host and instead
Handle authentication requests.

Another method of the present invention is a method for confirming that an individual actually exists in a peripheral device such as a token connected to the host by the individual. According to the basic method,
The host has a host user input interface, the peripheral device has a device user output interface, generates at least one output at the device user output interface, and the host has a corresponding to each of its outputs Monitor the host user input interface to capture the input and report the input to the peripheral device. Only when the peripheral device actually receives the corresponding report (s)
The presence of the individual is confirmed. An “input interface” in this context is an interface, such as a button or a keyboard, for receiving input from a user.
An “output interface” is an interface, such as an LED or display screen, for providing output to the user. In fact, the host applying this method
Almost every case includes an input interface and an output interface, but the method uses only the host input interface. A peripheral device may or may not include an input interface, but must include an output interface.

The peripheral device preferably generates a plurality of outputs that are randomly distributed in time. It is also preferred that an individual's presence be confirmed only when each report is received by a peripheral device substantially in synchrony with the generation of the corresponding output by the host.

The second device of the present invention is also a device for authenticating a transaction between a host and a server. The device includes a device interface, a user interface and a controller for interacting with the host. When the controller receives a transaction authentication request from the host via the device interface, the controller validates the server and uses the user interface to indicate whether the server validation was successful.

A third method of the present invention for authenticating a transaction between a host and a server comprises:
Corresponds to the second device. A token operatively connected to the host validates the server and indicates whether validation was successful via its user interface.

    The invention will now be described, by way of example only, with reference to the accompanying drawings.

FIG. 2 is an advanced block diagram representing a system according to the present invention. 2 is a flow chart representing two methods of operating the system shown in FIG. 2 is a flow chart representing two methods of operating the system shown in FIG. FIG. 3 is a high level block diagram representing another system according to the present invention. 4 is a flow chart representing two methods of operating the system shown in FIG. 4 is a flow chart representing two methods of operating the system shown in FIG. FIG. 5 is a flow chart representing the preferred preferred method for human permission.

The present invention relates to a token that can be used for user authentication, where the token does not need to receive user specific information directly.

The principles and operation of a token according to the present invention can be better understood with reference to the drawings and descriptions thereof.

Reference is now made to the drawings. FIG. 1 illustrates a preferred embodiment 10 of a system constructed in accordance with the present invention.
Represents an authentication token 112 that represents 0 and forms part of the multipurpose portable device 110. The multipurpose portable device 110 combines the token function of the authentication token 112 with other functions 114, such as storage. The controller 115 controls the operation of the multipurpose portable device 110, and the authentication token 112 and function 1
14 is controlled. The indicator 118 is under the control of the controller 115 and is audible and / or
Alternatively, a visual signal is provided to the user. The button 120 is an option for the user to provide a permission signal. Button 120 may be a physical push button or, alternatively, a light sensor that interacts with indicator 118. For example, when a user touches the body of the multipurpose portable device 110, his (female) finger reflects light coming from the indicator 118,
This is sensed by a photosensitive sensor forming part of the button 120. The device interface 116 is a standard electrical and logical interface, such as a USB (Universal Serial Bus) interface or an SD (Secure Digital) interface on the device side. The device connector 130 is a link 140 to the host 150.
Provide a wired connection or wireless connection via.

For example, a host 150, such as a personal computer, mobile phone or two-way pager, allows a user to transaction with a remote server of a provider (not shown) via a network connection 172, such as a connection to the Internet or a mobile link. Make it possible to execute. CPU 156 is an operating system, word processor, communication program, etc.
The operation of the host 150 is controlled under the service 154 which is a software program. The user operates the host 150 using a user interface 152 including, for example, a keyboard, a fingerprint reader, and / or a screen, and provides a PIN, password, or biometric information as a user ID. The host interface 158 provides a standard electrical and logical interface to the host side, multipurpose portable device 110, and the host connector 170 is wired or wired via the link 140 to the multipurpose portable device 110. Provide wireless connection. A malicious program 160 exists in the host 150 and intercepts the PIN, password and / or biometric information entered via the user interface 152, and then the multipurpose portable device 110 is connected to the host 150. It is presumed that sometimes an attempt is made to use the authentication token 112 to impersonate the legitimate owner of the multi-purpose portable device 110 and generate a fraudulent transaction.

FIG. 2 is a flow chart representing a first preferred method for operation of the multipurpose portable device 110 shown in FIG. As mentioned above, the main purpose of the method is to
When the multipurpose portable device 110 is connected to the host 150 for the purpose of the function 114, for example, the multipurpose portable device 110 that includes a storage function within the function 114.
Is connected to the host 150 for a long time for storage purposes, the malicious program 16
It is to prevent 0 from generating an illegal transaction. In step 200,
The multipurpose portable device 110 is operatively connected to the host 150. As part of the connection, between device interface 116 and host interface 158,
A logical handshake is performed. This allows the controller 115 to identify at step 202 whether the host 150 is in a pending authentication session. If the answer is no, at step 210 the controller 115 mounts only the multipurpose portable device 110 for the function 114 function. That is, the authentication token 112 is separated and access to the host 150 is impossible. At step 212, while the authentication token 112 is unavailable, the host 150 performs the service 154 and / or works with the function 114 of the multipurpose portable device 110 (eg, a data storage device included within the function 114). Perform read and write operations above). Obviously, at this stage, since the authentication token 112 is not connected, the malicious program 160 cannot execute any authentication transaction. If one of the services requires authentication, this is detected in step 214 and proceeds to step 230. Here, the user is prompted to remove the multipurpose portable device 110 from the host 150 and then reconnect the multipurpose portable device 110 to the host 150. This is a manual task that requires human involvement and cannot be executed by the malicious program 160. Only when the user follows in step 230, the system 100 returns to step 200, but this time the host 150 notifies the host interface 158 by the CPU 156 and waits for authentication. At this point in the handshake between the multipurpose portable device 110 and the host 150, if step 202 identifies that there is a pending authentication, then proceed to step 220 accordingly. Thus, for the function of the authentication token 112, the multi-purpose portable device 110 is mounted and the function 114 is disabled. In step 221, the user is prompted to present his (female) PIN, password, or biological identification attribute to the user interface 152, and in step 222, a single authentication session is performed, after which the authentication is performed. The token 112 becomes unusable. If, in step 226, additional operations by function 114 are desired, the multipurpose portable device 1 when prompted in step 230
10 need to be reconnected.

The procedure of FIG. 2 protects the owner of the multipurpose portable device 110 from malicious programs 160 activating the authentication token 112 on his or her behalf and repeating unauthorized transactions without being noticed. It is clear to do. However, there are still some loopholes where the malicious program 160 is available. These loopholes are steps 223, 224, 225 and 227 of FIG.
At least partially solve. The first loophole is that the malicious program 160 prepares a fraudulent transaction in the background. This is the function 1
14 to the host 150 to perform certain functions
A malicious program can actually generate an authentication pending status and execute a fraudulent transaction in step 202. In this case, the user fails to access his (female) desired function because there is a move to step 220 for authentication and the use of the function is disabled, but many users simply You don't blame your wearer and don't notice fraudulent transactions. To prevent this,
Optionally, explicit human permission at step 224 is required. This explicit permission can be achieved by pressing button 120 or under the method described in FIG. 5 below.
It can also be provided through the host user interface 152. Alternatively or additionally, in step 225, indicator 118 generates a special audio and / or visual signal to inform the user of the transaction so that it is not unaware of the transaction. In addition, the audiovisual signal can precede the authentication session for a few seconds, so the user is shown in step 227, sufficient to prevent the transaction,
There is time to remove the multipurpose portable device 110 from the host 150. Another precaution may be taken against “phishing” that causes the user to believe that he / she is executing a transaction on a legitimate website while connected to a different website. it can. Phishing is prevented by host verification in step 223. In this case, the authentication in step 222 is extended to the network connection 17.
2, including cryptographic verification of the ID of the provider's server connected via 2 and that the other host has been verified and that ID was recorded by the authentication token 112 via an indicator 118 (eg, a special Signal (by sound or flashing green light).

FIG. 2A illustrates an operating system 100 that does not require physical removal of the multipurpose portable device 110 from the host 150 between authentication and other functional sessions.
6 is a flow chart showing an alternative method of All steps except for the following:
It is the same as that of FIG. It is imperative to indicate the explicit human permission of step 224 by pressing button 120 or applying the method of FIG. Step 2
Mounting for both 30 and 240 modes is logically performed under the control of the controller 115, so there is no need to physically remove the multipurpose portable device 110 from the host 150. The mode switching from one to the other in steps 234 and 236 is performed by logical remount, not physical remount. It should be noted that instead of using a logical mount, both the authentication token 112 and the function 114 may remain mounted at the same time, and the controller 115 may simply switch between those functions. Thus, the word “activate” appears in steps 230 and 240 as an alternative to the word “mount”. What is clear is that FIG.
Under this embodiment, since human permission 224 is essential, only a single authentication can be performed per permission.

FIG. 3 illustrates another preferred system 300 of the present invention. This replaces the multipurpose portable device 110 shown in FIG. 1 with a single purpose portable token 310 that has no function other than authentication. Host 151 is similar to host 150 except that service 155 need not include services that require additional functionality 114 of multipurpose portable device 110. Token interface 318 and token connector 330 are similar to device interface 116 and device connector 130, respectively, shown in FIG. The crypto controller 316 controls the operation of the portable token 310 and the indicators 118 and buttons 120 are the same as their counterparts shown in FIG.

FIG. 4 is a flowchart representing the operation of system 300 of FIG. At step 400, portable token 310 is operatively connected to host 151. Since the only purpose of the portable token 310 is authentication, it is assumed that the actual authentication operation is performed within a predetermined time period (eg, 1 minute) as checked in step 404. If the authentication is started within this time limit, steps 221 and 222 are executed as shown in FIG.
A single authentication operation is performed, similar to that of FIG. 2, with optional host verification 223, human authorization 224, and audiovisual display 225 as well. If at step 426 the user wishes to perform another authentication session via one of the services 155 shown in FIG.
You are prompted to physically disconnect token 310 and reconnect to host 151. If at step 404 authentication is not initiated within a predetermined time period of (for example) 1 minute,
At step 410, the token is disabled. If authentication is required in step 414, the user is prompted to physically disconnect portable token 310 and reconnect to host 151 in step 430.

FIG. 4A is a flow chart representing an alternative method of operating system 300 that does not require physical removal of portable token 310 from host 151 between authentication sessions. In step 400, the portable token 310 is transferred to the host 15
Connect to 1. Steps 221, 222, 223, 224 and 225 are the same as those in FIG. 4 except for step 224 where explicit human permission is essential. Step 426 may be performed (such as the user ID of step 221), such as with a clear human permission 222 that is mandatory.
May be led to another authentication operation in step 222).

FIG. 5 is a flow chart representing a preferred alternative to pressing button 120 for the mandatory human permission 224 shown in FIGS. 2, 2A, 4 and 4A. An application that detects key presses runs on host 150 or host 151 and reports instantly to the connected multipurpose portable device 110 or portable token 310 each time a key is pressed. The goal is to allow the user interface 152 (eg, a conventional keyboard) to be used in a manner that the malicious program 160 cannot imitate for user authorization. This is done by having the user press a key on the user interface 152 in synchronization with the signal received from the audiovisual indicator 118. (Signal is sent by controller 115 or crypto controller 316
Although the human user notices the signal), the malicious program 160 is blind to the signal, so the presence of the human operator can be confirmed. The illustrated exemplary procedure prompts the user to press a key on the user interface 152 of the host computer four times in succession in synchronization with the signal received from the indicator 118. If the user misses any key press during the first, fourth press session, he / she has two more chances for the fourth key press. If he / she fails the session three times in a row, the token locks itself. Unlocking a locked token requires decisive manual work by a human user, for example, a visit to a service office. This requirement means that malicious programs
It is provided to prevent repeated attempts to randomly guess the correct timing of key presses until a correct timing can be estimated across multiple sessions. To detect failure, a failure counter is provided that forms part of controller 115 (FIG. 1) or of crypto controller 316 (FIG. 3). This failure counter is pre-zeroed at the time of manufacture, personalization, or when a user performs other definitive manual work on a trusted computer in a service office where a malicious program would not be reachable. Set. Also, the failure counter is reset to zero when a series of key presses are successful, as will be described in step 540 below.

Accordingly, in step 500, the success flag is set to logic true, and then in step 502, a loop is made through a session of four key presses. At step 504, controller 115 or crypto controller 316 generates a random number between 0 and 4 and waits this number of seconds while indicator 118 is off. In step 506, if a key press is detected within this waiting time, the success flag is set to false. then,
At step 508, a signal is generated via indicator 118 by controller 115 or crypto controller 316. In step 510, a key press is expected within the signal duration. If a key press is detected, the fourth key press session loop returns to step 502. Otherwise, in step 512, the success flag is set to false,
Thereafter, the loop in step 502 is continued. When all four sessions are complete, the loop goes to step 530 where the success flag is checked. The success flag remains true only if all four key presses on the user interface 152 are synchronized to the signal from the indicator 118. This leads to resetting the failure counter included in controller 115 or crypto controller 316 to zero at step 540 and then authorizing authentication at step 542. That is, FIG.
Any of 2A, 4 and 4A leads to execution of step 222. Even with a single failure in key press and signal synchronization, the loop 502 ends with success = false at step 530. This leads to step 532 and increments the previously mentioned failure counter by one. If the failure counter exceeds the allowable number of failures, e.g. 3, step 534 leads controller 115 or crypto controller 316 to lock itself in step 536 and rejects service in step 538 (i.e. 2 and 2
In any of A, 4 and 4A, authentication is not performed in step 222). However, for up to two previous failures, step 534 leads to generate a message via indicator 118 and / or user interface 152 at step 498 and to try the user again at step 500. recommend.

It should be noted that all variant embodiments described above require mandatory manual steps that can only be performed by humans in order to prevent malicious programs from completing authentication alone. Also, it is rare for such a step to be required for authentication, and it makes no sense if used elsewhere. Examples of such manual steps include: Reconnect the device to the host, press a special purpose button, send a warning signal to allow the user to disconnect the token before unauthorized authentication occurs, and send the token to the host in a timely manner Connect and press the host key in sync with the audiovisual signal received from the token.

Therefore, the focus of the present invention is to confirm that a human operator actually exists and manages in order to prevent a malicious program from manipulating the token alone. A human operator needs to be identified separately by presenting a PIN, password or biological attribute to the host. The user identification request is for loss or theft, and has not protected the token from malicious programs (assuming that a PIN, password or biometric information was intercepted). Therefore, an implied that a criminal who attempts to generate a fraudulent transaction with a picked-up or stolen token is not the same as a criminal who secretly installs a malicious program on the host used by the token owner I will assume that. A criminal who installs a malicious program on a host and then obtains a token used on the host can easily pretend to be the owner of the token. Although the present invention is powerless for such scenarios, the general usefulness of the present invention is maintained because such scenarios are rarely possible.

Although the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention are possible.

Claims (1)

A method for authorizing a transaction between a host and a server initiated by a user of the host, comprising:
(A) operably connecting a token to the host;
(B) receiving the user's identity certificate by the host;
(C) verifying the identity certificate with at least one device selected from the group consisting of the token and the server;
(D) detecting a prescribed action by a human by the token;
(E) generating token authentication data with the token, subject to the detection;
(F) sending the token authentication data to the server by the host;
And (g) comprising the step of authorizing a transaction by the server, provided that the token authentication data is received.

Images