GB2368168A

GB2368168A - Transaction authentication

Info

Publication number: GB2368168A
Application number: GB0025681A
Authority: GB
Inventors: Nigel Henry Rawlins
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-05-17
Filing date: 2000-10-19
Publication date: 2002-04-24
Also published as: GB0025681D0; GB0011912D0

Abstract

An authentication server stores a plurality of user records each including signature information characterising the hardware of a user terminal, an identification key, and user account information indicating an account. The signature information, the identification key and the account information are transmitted from the terminal to the server for verification.

Description

TRANSACTION AUTHENTICATION This invention relates to authentication of transactions, such as purchases of goods or services.

Increasing numbers of transactions are being made over relatively insecure networks such as the internet. In order to make a payment on-line, conventionally consumers transmit digits specifying their credit card from their terminal to a server unit operated by a merchant or a credit card payment operator. Standard credit cards can currently be specified by means of a 16 digit card number, supported by a four digit expiry date. Very many credit cards are in circulation, and as the number rises the chance increases that a criminal wishing to make a transaction can readily guess the digits of a valid credit card in order to trigger a fraudulent payment from that card.

In addition, the relative insecurity of the internet means that data transferred over it may be intercepted, giving criminals access to credit card information in transit over the network, or that credit card information may be revealed by the hacking of a server unit holding credit card information. For a transaction to be secure it is greatly preferred that when any two devices are connected each party must be certain that: 1. They know beyond doubt to whom they are connected.

2. They can be certain that the communication cannot be intercepted, interrupted or invaded.

3. That any information transferred over the internet is stored in a system that cannot be accessed by a third party.

There is therefore a need for a way to increase the security of transactions by improved authentication.

According to one aspect of the present invention there is provided a method for authenticating a transaction by means of an authentication server connected to a terminal by a network, the authentication server storing a plurality of user records, the method comprising: deriving signature information characterising the hardware of the terminal ; receiving from the user an identification key; receiving from the user account information indicating an account; transmitting the signature information the identification key and the account information from the terminal to the server; verifying at the server whether the transmitted signature information, identification key and account information each have a match in a single one of the user records; and only if such a match is found, permitting the transaction to take place.

According to a second aspect of the invention there is provided a server for authenticating a transaction in communication with a terminal over a network, server comprising: a data store for storing a plurality of user records; a processing unit for receiving from the terminal signature information characterising the hardware of the terminal, an identification key and account information indicating an account, and verifying whether the transmitted signature information, identification key and account information each have a match in a single one of the user records; and only if such a match is found, permitting the transaction to take place.

Each user record preferably comprises stored signature information. The transmitted signature information preferably is deemed to match stored signature information only if they are identical. If no identical match is found, the server may begin a process of determining whether there has been a change in the hardware of the terminal.

The step of deriving signature information suitably comprises determining embedded serial number information for at least one hardware device of the terminal. Examples of hardware devices that may be interrogated in this way include, but are not limited to, embedded chips associated with the operating system, the BIOS board, any electronic serial numbers associated with the operating systems or on board hardware of the device, or any combination of such identifiable electronic markers.

The signature information suitably comprises the said serial number information. The step of deriving signature information may be performed by means of software executed through the terminal. The method may comprise the step of transmitting the software to the terminal over the network, for example from the server. (For this purpose the server may be represented by a local download centre).

Each user record suitably comprises a stored identification key. The transmitted identification key may be deemed to match a stored identification key only if they are identical. Alternatively, the transmitted identification key is equal to the result of a predetermined algorithm applied to signature information stored in that record.

The step of verifying preferably comprises performing a first verification operation in which it is verified whether the transmitted signature information and identification key have a match in a single one or the user records, and if such a match is found performing a second verification operation in which it is verified whether the transmitted account information has a match in a that one of the user records. If a match is found in the first verification operation the server may transmit a message to the terminal to invite account information. The transmission of the account information to the server may be performed between the first verification operation and the second verification operation.

The account information may be information identifying a financial account such as a credit card account, a debit card account or a bank account. The account information may suitably include a card or account number. The account information suitably includes a card expiry date. The step of permitting the transaction to take place preferably comprises the server transmitting information specifying the second party, the amount and at least some of the account information to a unit capable of effecting a financial transaction. The network suitable comprises at least part of the internet. The method may comprise an initial step of the user registering with the server by means of the terminal, whereby the server may generate a user record for the user including the hardware signature of the terminal.

The present invention will now be described by way of example with reference to the accompanying drawings, in which: figure 1 illustrates schematically a network and associated terminal and server units for supporting transaction processing; figure 2 illustrates a registration process; figure 3 illustrates a transaction process; and figure 4 illustrates a network architecture.

In the present system, a user first registers with an authentication server over a network such as the internet. The user's terminal is probed by software to determine a hardware signature that is characteristic of the user's terminal. The hardware signature may, for example, include one or more serial numbers of hardware units of the terminal such as processors or hard disc drives. The hardware signature is transmitted to the authentication server which applies a predetermined function to the signature to generate a personal identification number (PIN) for the user. The PIN is transmitted back to the user's terminal so that the user can remember it securely.

The user also transmits his credit card details to the server. The signature, the PIN and the credit card details are stored by the server.

When the user wishes to make a transaction he permits his terminal to be re-probed for a signature, and enters his PIN into the terminal. The signature and the PIN are transmitted to the server which verifies that they match. If they match the server transmits a corresponding message to the terminal and the user enters his credit card details into the terminal. The credit card details are transmitted from the terminal to the server, which checks that they match the signature and PIN transmitted earlier. Only if all three match is the transaction authenticated and permitted by the server to proceed.

The processes of registration and authentication will now be described in more detail.

Figure 1 shows a network, such as the internet, represented at 1. Connected to the network are a user terminal 2, a transaction authentication server 3 and a merchant server 4. The units 2,3, 4 can communicate with each other by means of the network 1. The transaction authentication server 3 is connected by a secure private data link 5 to the financial transfer system 6 of a financial payment body.

User terminal 2 may, for example, be a personal computer, a palmtop device, a settop box or a mobile phone. The user terminal includes a central processor 10 connected to peripheral units in the normal way. The peripheral units include a user input device, such as keyboard 11, for accepting input from a user; a user output device, such as a visual display unit 12, for providing output to a user; and a network interface unit 13 for connecting the terminal for data transfer to and from the network 1. The central processor is capable of communicating with a memory 14 for executing software stored in the memory. The user terminal may include other devices such as a modem, sound or graphics processors and hard disk drives.

Authentication server 3 includes a central processor 20 capable of executing software stored in memory 21, and a data storage device 22 with which the processor may communicate for storing and retrieving data. The authentication server has a first network interface unit 23 for data transfer to and from the network 1, and a second network interface unit 24 for data transfer to and from the private data link 5 in secure isolation from data traffic in the network 1. The first network interface unit 23 provides a security barrier against unauthorised communication with the network: for example to prevent the data in the storage device 22 from being read from outside the authentication server.

The merchant server 4 may be a conventional hypertext transfer protocol (HTTP) server, for providing information on goods or services for sale, adapted as described below to interface over the network 1 with the authentication server 3 when a transaction is to be performed.

The financial transfer system 6 is a computer system capable of performing credits and debits between bank and credit card accounts.

The operation of the system of figure 1 will now be described with reference to figures 2 and 3.

Figure 2 illustrates a process of registration of the user with the authentication server 3. If the user wishes to be able to make transactions by means of the authentication server he causes the terminal 2 to contact the authentication server 3 over the network 1 to initiate the registration process. The authentication server transmits interrogation software to the terminal 2. The interrogation software is executed by the terminal 2. The interrogation software detects characteristic physical information of the terminal and transmits that information back to the authentication server. The software may be stored on the user's terminal and activated by the authentication server, or downloaded by the user's terminal from the authentication server during the registration process. The physical information may, for example, include details of the terminal's specification or configuration: for example the types of devices contained within or connected to the terminal ; and/or unique identity information of devices contained in or connected to the terminal. Non-limiting examples of the information that may be collected are: 1. whether the terminal has a graphics card of other specific peripheral in or connected to it; 2. the type of monitor or other peripheral connected to the terminal ; 3. the serial number of an integrated circuit such as the central processor of the terminal ; and 4. the serial number of a hard disk drive, network adapter or other peripheral connected to the terminal. 5. Or any combination of the above required to generate a unique identification for that device.

This information provides a unique or at least highly characteristic signature of the terminal. At the server a predetermined algorithm is applied to the received information to generate a PIN. The PIN suitable has four or five digits. A new record is defined for the user in the data storage device 22. In that record are stored the received signature information, the algorithm used to generate the PIN and the generated PIN. The PIN is transmitted back to the terminal where it is displayed so that it can be remembered by the user. The user then enters his credit card details, which are transmitted from the terminal to the server 3 and stored in the user's record in the storage device 22. A message is then transmitted from the server to the terminal to inform the user that the registration process is complete. As part of the registration process the user my also provide data such as his name and address so as to allow him to be contacted.

Data may be transmitted between the terminal and the server by any suitable means. One preferred approach is to transfer the date using HTTP (hypertext transfer protocol). In this way, data can be displayed to the user on the terminal by an HTTP reader such as a web browser application and input means of hypertext mark-up language (HTML) forms. Software for interrogating the user's computer and initiating transmissions to the server may be provided as Java applets embedded in the HTML. For reasons of data protection it is preferred that the user has to explicitly consent to transmission of the identity data to the server. For security it is preferred that information is communicated between the terminal 2 and the server 3 by means of an encrypted protocol such as SSL (secure socket layer) or HTTPS (secure HTTP). The system preferably supports virtual private networks (VPNs), secure socket layers (SSL), X. 509 certificates and smart card technology.

The PIN could be transmitted to the user in another means, for added security. For example, the PIN could be sent by post to the user's postal address, as registered above. The user could then have to notify the operator of the authentication server 3 that the PIN had been safely received in order to activate his registration with the server.

Figure 3 illustrates a process of performing a transaction by a registered user. The registered user accesses information on the merchant server 4 over the network 1. The user specifies an article to be purchased at a specified price. When the user informs the merchant server that he wishes to proceed with the purchase of the article the merchant server contacts the authentication server 2 by means of the network 1. The merchant server identifies the merchant's bank account, the amount of the purchase and contact information (e. g. the IP (internet protocol) address) of the terminal being used by the user. Using that contact information the authentication server contacts the user's terminal. Software on the user's terminal interrogates the user's terminal to determine the same hardware identity information as in the registration process. Again, the software may be stored on the users terminal (e. g. following download during the registration process) and actuated by the server 3, or may be downloaded during the authentication process. The user enters his PIN, and the PIN and the hardware identity information are transmitted back authentication server 2.

At the authentication server the records in the storage device 22 are scanned to determine whether any of their stored hardware identities match that transmitted by the terminal in the authentication process. If an identical match is found then the terminal in the authentication process is assumed to be the same one as was used in generating the matched record. If no identical match is found that may be due to the user having reconfigured the terminal. In that case the user server 3 may search for a highly similar match to that of the terminal in the authentication process-for example a match from a previous registration of a terminal having a number of hardware devices of the same serial numbers as those if the terminal in the authentication process. If such a similar match is found then the server may begin a process to verify whether the user has reconfigured his terminal. Software running on the terminal may keep a log of configuration changes.

If an identical or acceptably authentic match is found then the PIN received from the terminal in the authentication process is checked against the PIN stored in the matched record. If the PINs are not the same then the user is sent a message to inform him that his attempt has been unsuccessful ; the user may then try again. If the PINs are the same then the user is invited to enter his credit card details (e. g. number and expiry date) at the terminal. Those details are then transmitted to the server. At the server the credit card details are checked against those stored in the matched user record during the authentication process. If the credit card details do not match those stored earlier then the user is invited to re-enter the details. If the credit card details do match those stored earlier then the transaction is fully authenticated and allowed to proceed.

To proceed with the transaction the authentication server 3 transmits a message to the financial transfer system 6 over the secure data link 5 specifying the amount of the transaction (as received from the merchant server), the account to be credited (as received from the merchant server) and the credit card details of the credit card account to be debited (as derived during the authentication process). The financial transfer system then performs the transfer of the specified amount of funds from the account to be debited to the account to be credited. If the transaction proceeds confirmatory messages may be sent to the merchant server 4 and/or the terminal 2 to indicate that the transaction has been made. In response to such a message the merchant server may cause goods to be shipped to the user.

In this system three levels of data are used to authenticate a transaction: the hardware identity, the PIN and the credit card details. This provides important additional security over present systems. In addition, the user does not have to provide his credit card details to the merchant. This eliminates the possibility of a criminal gaining access to the credit card information through a security flaw in the merchant's computer system. The system thus provides for positive client identification.

Positive client identification may be used for other purposes than authenticating financial transactions, for example identifying and tracing lost or stolen terminal devices which subsequently come on line, licensing of software via encrypted keys to restrict use to just that device, to being able to specifically target advertising to online devices where the configuration of that device would be known. Thus, in its simples form, video advertising would only be targeted to devices with an on-board video card.

The communication between the terminal and the authentication server may be by any suitable protocol. Internet protocols are preferred. As an alternative to HTTP, email protocols could be used. The communication-at least for data transferred from the terminal to the server-is preferably encrypted.

The algorithm used to generate the PIN may be a conventional security algorithm. It is preferred that the PINs generated by using algorithms that calculate PINs based upon the time and date of registration which would be recorded and thus be randomly distributed. Passwords or other keys may be used instead of or in addition to numerical keys. Instead of storing the PIN in each user's record, the PIN may be generated using the algorithm from the stored hardware identity each time the PIN is required in an authentication process. This may increase security if there is unauthorised access to the user record database. Alternatively, the PINs may be allocated randomly or pseudo-randomly, or at least independently of the hardware identity, in which case there is no risk of security being compromised by unauthorised access to the algorithm used for PIN generation. In the latter case, PINs must be stored in users'records in order to allow authentication.

In addition to credit cards, the authentication process could be applied analogously to other financial accounts such as debit card accounts, store card accounts or straightforward bank accounts. In each case, the user simply provides the authentication server with the details necessary to characterise the account he wishes funds to be debited from. The authentication server may verify the validity of the account with the financial transfer system 6 to check that the system 6 is capable of handling debits from the account, and that the account does exist with the details as specified by the user and that it is in use. This is preferably done during the registration process.

During the registration process the user may provide the server with a number of accounts any of which he may used for transfer of funds using the system. In that case, during the authentication process the authentication server may check the account details supplied by the user against all the accounts available in the matched user record.

The authentication server may support a user record update procedure for permitting a user to update his records. This may allow the user to add, delete or alter the details of stored accounts, to request a new PIN if he has forgotten his PIN and to de-register, for example if he is about to sell the machine whose hardware details are stored. The server 3 preferably stores additional identification in each user's record to allow the user's account to be located for de-registration even if the terminal on which the registration was performed is no longer available-for example if it has already been sold by the user.

For security it is preferred that the user's account is locked out by the server 3 after a number of unsuccessful attempts to authenticate a transaction. This reduces the possibility that another person with access to the user's terminal may succeed in authenticating a transaction.

The information used to form the hardware signature for a terminal may be gathered according to the same procedure for all terminals that register. Alternatively, additional security may be had by gathering different information for different terminals. The server 3 may store in the user's record the information that was used to generate the signature, and the interrogation software sent to each terminal may be adapted accordingly.

The operator of the server 3 may charge the user a fee for registering, and/or make a charge of the user or the merchant or the operator of the user or the merchant's accounts when a transaction is made.

In one specific example of a system implementing the above principles, the customer would first register the device to a secure authentication server system. This would be achieved through an initial web page, which would list the terms and conditions relating to the system along with details of the charges and registration fees. Included at this stage would be a declaration that certain information would be silently detected from the customer's device and retained on a secure and remote system and the customer's positive assent would be required before any such procedure could commence. Should such assent not be forthcoming the system would not proceed to the next stage. Upon receipt of the required positive assent, a continuous authentication software technique (CAST) would be engaged to protect the communication from any outside interception, interruption or invasion. Using positive client identification (PCI), silent detection would then commence, and certain numerical information would be recorded from the customer's device and stored securely on a remote device using a virtual page publication system (VPPS), which might not itself be connected to the internet. The virtual page produced by VPPS is sent to the customer in exactly the same way as a requested URL but immediately deleted from the system. The virtual page exists only for the amount of time necessary to send it to the requesting client. The source information for pages is stored where it is inaccessible from the web and may even be stored on other computers not connected to the Internet. The content cannot be accessed or hacked through the WWW because it does not need to exist on the WWW. It would, therefore, be protected from any attempt to hack into the information. The recovered numerical details would now give a record of a unique'fingerprint'of that device for future reference. This'fingerprint'would then be encrypted to give a Personal identification Number (PIN), equivalent to the PIN number as issued by banks, and which should only be known to the customer who first registered the device to the system. The system would then automatically download a small program to the customer's terminal device that would be used to identify that device on every future occasion that the customer accessed the system ('Cookie'). Finally the customer would be required to complete the registration process by furnishing the details of any credit cards that are to be used from that device, before logging off.

Once the user has registered with the system, he would now be able to access the world-wide web freely, in the usual way, and would be unaware of any software acting in the background. When the user visits a site where goods, services, etc. are to be purchased, then the system would only'kick in'when a financial transaction is about to take place. The software would be programmed that when the user agreed payment through the'Payment', 'Submit'or any other indication to proceed to payment on that web page, validation of the transaction would automatically start. This would be carried out by the following steps: 1. The'Positive Client Identification' (PCI),'Active Security Responder (ASR) and Continuous Authentication Software Technique (CAST) would instantly be engaged, to ensure that the communication is protected from interception, interruption or invasion.

2. The Software would first carry out a'silent detection'on the connected device to check for the'Fingerprint'of that device.

3. The Software would ask the user for the'Personal Identification Number' 4. Having verified these against the user's record the system can be sure that the user and the device are registered to the system.

5. An invitation to confirm the payment would be given to the user who would now have to enter the number of the credit card against which the transaction is to be charged.

6. The Credit card details would be checked against the original registration and if matched with the registration the transaction would be allowed to proceed.

7. The details of the transaction would now be sent to the Credit card issuer where the usual check for validity would be carried out. These could include Credit limits, Stolen card searches, Validity dates and checks on any restrictions that might be applied to that card. Only after completion of these procedures would the transaction be sanctioned and confirmation of the transaction passed back to the user via'pseudo uniform resource locators' (PURLs) which for further security could be encrypted using current standard 128 SSL techniques or subsequent upgrades.

Software on the server may perform the following functions to support the operation of the system: 'Authentication * Interception of all requests for web pages and web page components

'Examination of requests for evidence of interception or impersonation * Validation of the user and evaluation of a user profile 'Creation of appropriate responses * Evaluation of page profiles for requested PURLs * Execution of any actions associated with user profiles Preparation and logging information as required Transaction logging Preparation and publication of virtual pages using the Virtual Page Publication System . Provision of file access support for all Windows NT protocols The server may recognise a terminal to authenticate a transaction by means of data stored at the terminal in consequence of the terminal registering with the server. When the terminal registers with the server, or subsequently, the server and the terminal could cooperate to generate and exchange a data string to act as a key. The data string is stored by the terminal and the server so that it can be used by the server to authenticate a transaction that is to be carried out by the terminal. The data string is preferably stored in a non-volatile manner. The data string is preferably stored on a hard disk dive of the terminal, or the like. The data string is suitably stored with a specified name or in a specified location so that it can be retrieved when required for authentication. For example, the data string could be stored at a specified location on a hard disk of the terminal, or as a file having a name formed as a known function of the name of the server and/or the name of the user of the terminal.

The data string suitably includes information characterising hardware of the terminal.

Then, to authenticate the terminal the hardware of the terminal may be interrogated and details of it sent to the server, and the data string may be sent to the server and the server may then compare the hardware details, the data string as received and the data string (or another indication of the details of the hardware) as stored at the server in order to determine whether to permit a transaction. The transaction is suitably permitted only if all three items match.

One example of a sequence of operations to authenticate a transaction using such a data string key stored on the terminal will be described with reference to figure 4.

1. A user of a client terminal 41 accesses a registration server 40, and registers with that server. In the registration process the user provides the server with his identification information (name, address etc. ) and details of the funds accounts that he wishes to use in authenticated transactions. The server then generates a data string to act as a key and transmits that string to the terminal. The terminal stores the string, and the server stores the string in association with the user's registration details so that it can later be used to verify the identity of the terminal.

The registration server transmits the registration details (including the key data string) to an authentication server 46.

2. A user of a merchant terminal 42 accesses the registration server 40, and registers with that server. In the registration process the user provides the server with his identification information (name, address etc. ) and details of the funds accounts that he wishes to use in authenticated transactions. The server then generates a data string to act as a key and transmits that string to the terminal. The terminal stores the string, and the server stores the string in association with the user's registration details so that it can later be used to verify the identity of the terminal. The registration server transmits the registration details (including the key data string) to an authentication server 46.

3. The user of the terminal 41 communicates with the merchant terminal 42 over link 43, for example accessing a web site of the merchant server, and determines that he wishes to initiate a transaction with the merchant. The user transmits a signal to the merchant terminal to initiate the transaction.

4. The user terminal 41 and the merchant terminal 42 each transmit their stored key data strings to a node 44.44 interrogates terminal 41 and 42 to compare the key data strings submitted by each device to the physical properties of those devices. The data strings are transmitted together with the amount of the transaction and, if either the user or the merchant has registered more than one funds account with the registration server 40, an indication of the account to be used for the transaction. The data strings are transmitted with data that allows the node 44 to marry up the data strings from both parties to the transaction. For example each string could be sent with an indication of the other party to the transaction and/or with a unique identification for the transaction previously negotiated between the terminals 41 and 42. The terminal making the payment (generally the client terminal 41) also transmits its PIN as agreed with server 40 to the node 44.

Transmission of the PIN could trigger a routine for selection of the account to be used.

5. The node 44 marries together the information sent by both parties to the transaction and generates a transaction certificate comprising the key data strings from the client terminal and the merchant terminal, the identities of the accounts for the transaction, the amount of the transaction and the PIN. The key data strings have the effect of digitally signing the certificate for validation purposes.

6. The node 44 transmits the certificate to the authentication server 46. The authentication server verifies that the key data strings correctly match the account information as stored in its records. If either the client's or the merchant's accounts are not stored in a record of the server, or if the key data string stored at the authentication server in relation to either of the accounts does not match the corresponding key in the certificate then the authentication server rejects the transaction. Otherwise the authentication server authenticates the transaction by modifying the certificate to include an authorisation code.

7. If the transaction is authenticated the node 44 determines the address of a server 45 of the bank that administers the account from which the payment is to be made.

The node 44 transmits the certificate to that server, which checks the certificate and checks that the account is valid and has sufficient funds for the transaction. If so, it digitally signs the certificate and adds a transaction code number. The server 45 then debits the account by the amount indicated in the certificate.

8. The certificate is then sent to the server 47 of the bank that administers the account to which the payment is to be made. The server 47 checks the certificate and then credits the account with the amount indicated in the certificate. It digitally signs the certificate and returns it to node 44.

9. The certificate is retained by the node 44 as proof that the transaction has been completed. The node 44 informs the terminals 41,42 that the transaction has been completed.

When the transaction has been completed (e. g. when informing terminals 41 and 42 that the transaction has been completed), or if the transaction has been rejected, the node 44 may issue a new or modified key data string to each of the terminals 41,42 and inform the server 46 of the strings so it can store them in association with the appropriate records for future authentication. In this way the key data string could only be used once.

Communications to and from the terminals 41,42 (e. g. from those terminals to each other and to and from those terminals and server 40 and node 44) may be over insecure communications links, such as the internet. Such communications are preferably encrypted. Communications between node 44 and servers 45,46 and 47 are preferably over secure communications links.

Each data string is preferably generated by the server 40 and transmitted to the appropriate terminal, although it could be generated by the terminal to a specification (e. g. as to length) set by the server. The data string could be generated randomly or deterministically. The length of the data string is preferably sufficiently long that it is unlikely to be duplicated coincidentally by an unauthorised user; for example the key could be 2000 bits long or preferably longer.

The key data string could be transmitted to the terminal and/or stored at the terminal as a cookie. The cookie could be pushed to the terminal by server 40 acting as a web server when a user of the terminal accesses its associated web site. Key data strings could be accessed by node 44 acting as a web server.

Nodes 40,44 and 46 could be provided as a single entity.

The content of the cookie or other data stored on the terminal for identification purposes is suitably a key string of random (including pseudo-random) or semi-random data which is sufficiently long to make the risk of it being duplicated coincidentally by a person seeking to gain unauthorised access to funds very small. Preferably the key is at least 2000 bits long.

It is preferred that the data strings are transmitted in encrypted form to and from the terminals, to reduce the chance of them being made available to an unauthorised user. Conventional HTTPS encryption or a more secure form of encryption could be used.

The present invention may include any feature or combination of features disclosed herein either implicitly or explicitly or any generalisation thereof, irrespective of whether it relates to the presently claimed invention. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

CLAIMS 1. A method for authenticating a transaction by means of an authentication server connected to a terminal by a network, the authentication server storing a plurality of user records, the method comprising: deriving signature information characterising the hardware of the terminal ; receiving from the user an identification key; receiving from the user account information indicating an account, transmitting the signature information the identification key and the account information from the terminal to the server; verifying at the server whether the transmitted signature information, identification key and account information each have a match in a single one of the user records; and only if such a match is found, permitting the transaction to take place.
2. A method as claimed in claim 1, wherein each user record comprises stored signature information.
3. A method as claimed in claim 2, wherein the transmitted signature information is deemed to match stored signature information only if they are identical.
4. A method as claimed in any preceding claim, wherein the step of deriving signature information comprises determining embedded serial number information for at least one hardware device of the terminal.
5. A method as claimed in claim 4, wherein the signature information comprises the said serial number information.
6. A method as claimed in any preceding claim, wherein the step of deriving signature information is performed by means of software executed by the terminal.
7. A method as claimed in claim 6, comprising the step of transmitting the software to the terminal over the network.
8. A method as claimed in claim 7, wherein the software is transmitted from the server.
9. A method as claimed in any preceding claim, wherein each user record comprises a stored identification key.
10. A method as claimed in claim 9, wherein the transmitted identification key is deemed to match a stored identification key only if they are identical.
11. A method as claimed in claim 2 or any of claims 3 to 8 as dependant directly or indirectly on claim 2, wherein the transmitted identification key is deemed to match a user record if the transmitted identification key is equal to the result of a predetermined algorithm applied to the signature information stored in that record.
12. A method as claimed in any preceding claim, wherein the step of verifying comprises performing a first verification operation in which it is verified whether the transmitted signature information and identification key have a match in a single one of the user records, and if such a match is found performing a second verification operation in which it is verified whether the transmitted account information has a match in a that one of the user records.
13. A method as claimed in claim 12, wherein if a match is found in the first verification operation the server transmits a message to the terminal to invite account information, and the transmission of the account information to the server is performed between the first verification operation and the second verification operation.
14. A method as claimed in any preceding claim, wherein the account information is information identifying a financial account.
15. A method as claimed in claim 14, wherein the account information includes a card number.
16. A method as claimed in claim 14 or 15, wherein the account information includes a card expiry date.
17. A method as claimed in any preceding claim, comprising the step of receiving at the server information specifying a second party to the transaction and an amount of the transaction.
18. A method as claimed in claim 17, wherein the step of permitting the transaction to take place comprises the server transmitting information specifying the second party, the amount and at least some of the account information to a unit capable of effecting a financial transaction.
19. A method as claimed in any preceding claim, wherein the network comprises at least part of the internet.
20. A method as claimed in any preceding claim, comprising an initial step of the user registering with the server by means of the terminal, whereby the server may generate a user record for the user including the hardware signature of the terminal.
21. A method as claimed in any preceding claim, wherein the signature information is stored as a data string at the terminal.
22. A method as claimed in claim 2 or any of claims 3 to 20 as dependant directly or indirectly on claim 2, comprising the steps of deriving a data string from the terminal and comparing the data string with one or both of the derived signature information and the stored signature information.
23. A method as claimed in claim 21 or 22, wherein the data string is comprised in a cookie stored at the terminal.
24. A method as claimed in any of claims 21 to 23, wherein the hardware is a data storage device of the terminal.
25. A method as claimed in claim 24, wherein the storage device is a hard disk drive.
26. A server for authenticating a transaction in communication with a terminal over a network, server comprising: a data store for storing a plurality of user records; a processing unit for receiving from the terminal signature information characterising the hardware of the terminal, an identification key and account information indicating an account, and verifying whether the transmitted signature information, identification key and account information each have a match in a single one of the user records; and only if such a match is found, permitting the transaction to take place.
27. A method for authenticating a transaction substantially as herein described with reference to the accompanying drawings.
28. Apparatus for authenticating a transaction substantially as herein described with reference to the accompanying drawings.