"Data Security in client/server systems"

INTRODUCTION

Field of the Invention

The invention relates to data security for transaction processing.

Prior Art Discussion

A problem which exists at present is that when a user has authorised himself with a website, such as online banking, a "Trojan" (or "malware") hidden program on his computer can change, without the user knowing, values which are submitted such as account number and amounts. The values may be changed by changing form values as they are sent from a client computer to a server. Then, the hidden program, using the user's cookies to authenticate itself as the authorised user, performs an unauthorised act such as making a money transfer from the user's account to an unauthorised account.

EP 1980983 (Siemens) describes use of a photo-detector and cryptographic controller to ensure that data inputted on a client computer is correctly uploaded to a server.

US2006/0230455 describes a system to prevent problems arising from malware. A write filter provides information to a storage device depending on whether malware is detected. A temporary storage device may be used also. While this arrangement appears to be effective for some situations, it does not deal with situations where the malware is operating in client system memory in real time as interfacing is taking place with a server for a transaction.

US2006/0200861 describes an approach in which a computer's registry is modified so that it may be more easily cleansed of malware. Meta data associated with Web-installed software is stored in a partitioned part of the registry. This appears to allow more streamlined identification of malware which is received via the Internet, however there is a need for a robust mechanism to prevent fraudulent activity taking place due to malware which is not detected on time.

The invention addresses this problem.

SUMMARY OF THE INVENTION

According to the invention, there is provided a data security method performed by a client computer and a server to implement a transaction with data security, the method comprising the steps of:

(i) the client computer receiving transaction data;

(ii) the client computer writing the transaction data locally to a memory; (iii) the client computer generating a code derived from the transaction data;

(iv) the client computer receiving from a user a transaction authorisation;

(v) the client computer transmitting the code and the transaction data to the server;

(vi) the server independently generating a code from the received transaction data, comparing the server-generated code with the client computer-generated code, and completing the transaction only if the codes correspond.

In one embodiment, a security program executing on the client computer in parallel with transaction-processing software performs at least steps (ii), (iii), and (v).

In one embodiment, the security program is associated with a user control, such as an ActiveX control.

In one embodiment, step (iv) includes reading security information from a physical key inserted into the client computer by the user, said information being previously stored in the server.

In one embodiment, the client computer, for transaction authorization, checks user-inputted security information against security information read from the physical key.

In one embodiment, the client computer generates the code from a user identifier in addition to the transaction data.

In one embodiment, the client computer generates the code from a current timestamp in addition to transaction data.

In one embodiment, the client computer generates the code from a serial number of the physical key in addition to the transaction data.

In one embodiment, the code is generated dynamically as the transaction data is inputted.

In one embodiment, the code is a hash code.

In another aspect, the invention provides a transaction processing system comprising a client computer and a server adapted to perform any method defined above.

In a further aspect, the invention provides a computer program product comprising software for performing client computer operations for any method defined above when executing on digital processors.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:-

Fig. 1 is a flow diagram illustrating a data security method of the invention.

Description of the Embodiments

The invention provides client computer and server security programs and method of operation which ensure that even if malware is operating in the client computer fraudulent or unauthorized transactions do not take place. Thus even if malware has penetrated through a firewall and is free to execute on the client computer, an attempt at a fraudulent transaction is thwarted by operation of the security program. Thus the security program on the client computer can operate alongside conventional anti-virus software. In many cases such anti-virus software will detect the malware before it has a chance to operate, but the invention provides for transaction security even if the malware goes un-detected.

A user inputs transaction data in form input fields in a conventional manner, as viewed from the user's perspective. The user clicks a "submit" button on the form. Once clicked, the form is sent to the server with an additional hidden secure field. Data security ensures that the form data could not have been modified by unauthorized hidden programs such as Trojan software and that the user is the real account owner.

The following describes the method in more detail with reference to Fig. 1 as a series of steps 1 through 6.

In step 1 a USB device physical key 10 is inserted in the user's computer 11. This is in one embodiment a physical security (USB) key as described in our PCT published specification no. WO2004-109610

In step 2, an activeX control security program 12 is embedded in the client computer 11 Web page used for performing transactions such as logging in or transferring money. A server 13 also runs corresponding security software, as described below.

The activeX control 12 generates a display control which looks like a regular button and so its use is transparent to the user. The button may have text such as "Transfer Money" or "Submit".

The activeX control 12 takes focus of each of a number of HTML form input fields 14 to intercept the user data inputs to the form fields 14. When a user clicks a form field the activeX control 12 takes over the keyboard inputs. As each character is typed, the activeX control 12 logs the character to a memory space 15 and updates the relevant HTML form field 14 as the user types. Therefore, the method implemented by the security program is transparent to the user as he or she simply views the correct date in the relevant form field 14. In this way, the activeX control effectively intercepts the data inputted by the user, and stores the data in memory.

The activeX control 12 dynamically builds a SHA512 hash code from the inputted values and retains it in the memory 15. Thus in this embodiment the hash code is dynamically generated as the user inputs the data. Thus if a malware program attempts to interfere with operation of the activeX control 12 during its operation the hash code based on part of the user data may be used. However in another embodiment the hash code may alternatively be generated in one pass when all data has been inputted.

In step 3, when the user clicks the "submit" button, the activeX control 12 generates a display asking the user to insert their PIN number to authorise the transaction. The activeX control 12 rolls together the PIN with the USB key serial number and the current time stamp and the user identifier to generate the hash code. The activeX control 12 completes the SHA512 hash code based on this data and saves it to the memory 15 for transmission in a hidden field. It also writes a user identifier, a current timestamp, BLOB (binary large object) data, serial number, and PIN number to a text file for submission to the server 13.

The activeX control 12 then in step 4 instructs the form to submit to the server 13. The submission includes the hash code and the above-mentioned plain text inputted data.

In step 5 the server 13 receives the form data in clear text as well as the client-generated hashcode. The server 13 then performs validation of this transaction by generating its own version of the hashcode based on the information it knows (user identifier, current timestamp, BLOB data, serial number and PIN) and the new information it has received (form data). It then compares the submitted hash code against its own. If the hash codes match then the user is authenticated and thus proves that the form data has not been modified by malware (refer step 6). Because the server has previously stored the USB key serial number along with the other data there is excellent security. It would be extremely difficult for a malware to obtain the full set of data used to generate the hash code, even if it did obtain the necessary algorithm.

Thus, even if malware operates on the client computer to the extent of transmitting form field data including some user-inputted data (for example, user account details for originating a money transfer) and unauthorised data (for example an unauthorized account for destination of the money transfer) the server 13 would not process it as there would not be a hash accompanying the data. Also, even if the malware were sophisticated enough to generate a hash code from the data, it would not be synchronized with the server 13 in terms of the hashing algorithm. Also the data fed into its hashing algorithm of the malware would be incorrect. There is therefore a very significant level of security in the main steps of the process, even without the use of PIN verification using the USB physical key 10.

It will be appreciated that the invention achieves effective prevention of security breaches in performing transactions. It is very simple, as a single security program both captures the inputs and generates the hash, and also interfaces with the user to receive the authorization.

The invention is not limited to the embodiments described but may be varied in construction and detail. For example, in another embodiment there is no need for use of a physical key - other user authentication techniques such as a biometric technique or conventional username/password mechanism being used.