WO2010031142A1

WO2010031142A1 - Method and system for user authentication

Info

Publication number: WO2010031142A1
Application number: PCT/AU2009/001251
Authority: WO
Inventors: Joseph Elie Tefaye; Martin Sigmund
Original assignee: Joseph Elie Tefaye; Martin Sigmund
Priority date: 2008-09-22
Filing date: 2009-09-22
Publication date: 2010-03-25
Also published as: AU2009295193A1

Abstract

An authentication method for use in a system including a client device (140) operated by a user, and an authentication server (120). Unique identifying information and a set of encryption keys is associated with the user, and a client identifier based upon a plurality of identifying codes is associated with the client device (140). The user is authenticated by forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using a key from the set of encryption keys. The authentication message is transmitted (520) from the client device (140) to the authentication server (120), which decrypts the encrypted content of the authentication message, verifies the client identifier and generates an authentication response message based upon the result of the verification. A system (100), and computer software products implementing the method are also disclosed.

Description

METHOD AND SYSTEM OF USER AUTHENTICATION FIELD OF THE INVENTION

The present invention relates to electronic transaction security, and in particular to methods, systems and computer software products for authenticating users of electronic transaction services, and ensuring the security and integrity of their electronic transactions. While the invention has particular application to online financial transactions, such as Internet banking, it is not limited to this purpose and may be used, for example, to enhance the security of other forms of electronic transactions, including electronic point of sale (POS) transactions. BACKGROUND OF THE INVENTION

Electronic transactions have become commonplace throughout the developed world. While these initially consisted primarily of transactions conducted using dedicated terminal equipment and/or networks, such as transactions via automatic teller machines (ATMs) or via electronic point of sale (POS) terminals, over the past decade there has been a significant increase in the use of electronic commerce (e-commerce) applications on the Internet. E-commerce applications include online shopping and trading, as well as the online provision of financial services, such as banking, investment, share trading and so forth. All electronic transactions share one common feature, namely that the parties to the transaction are remotely located from one another, and are, accordingly, unable to verify each others identities in the traditional ways, such as by comparison with photographic records, or authenticated signature specimens. Security of transactions based upon dedicated terminal equipment, such as ATMs and POS terminals (that are typically considered as "trusted" devices), depends upon users of these systems maintaining the physical security and integrity of their credit and debit cards. While card-based fraud is becoming more sophisticated {eg through the use of card "skimmers"), and there is ample scope for enhancing the security of such transactions (of which the replacement of magnetic-striped cards with chip-based smart cards is one example), online transactions present particular additional challenges in terms of preserving transaction security and integrity. The Internet, in particular, is an entirely untrusted, and untrustworthy, network. Users' terminal equipment is generally their own home, office or portable PCs, and/or Internet-capable PDAs, none of which can generally be considered to be secure or trustworthy, particularly in view of the increasing prevalence of malware, including viruses, trojans and spyware, that users unwittingly allow to enter their systems. Major e-commerce service providers, including banks and other financial institutions, generally provide an acceptable level of security for their server systems, however electronic fraud techniques, such as so-called "phishing" scams can nonetheless be used to fool customers into believing that they are dealing with a trustworthy financial institution, when, in fact, they have been directed to a malicious server, the purpose of which is to acquire critical online credentials, such as user names and passwords. Widespread malware includes "key loggers", ie programs intended to record users' key strokes (including any user names and/or passwords that may be typed) and transmit this information back to a fraudulent operator.

Since the Internet itself is an untrusted network, all communications, including those related to financial transactions, are potentially subject to eavesdropping, redirection, and so-called "man-in-the-middle" attacks, wherein a malicious system interposes itself, more or less transparently, between the parties to a transaction (eg a customer and their bank web site). While encryption of communications between the parties to e-commerce transactions, for example using SSL or TLS technologies on the web {ie HTTPS protocols), is of some assistance in defeating these types of attacks, encryption alone does not provide a complete solution. For example, encrypting communications between two communications end-points does not enhance security if the user has already been tricked into making an encrypted connection to a malicious or fraudulent operator. Ultimately, the trustworthiness of encrypted connections on the Internet depends upon the use of digital certificates issued by trusted certificate authorities (CAs), however many users are insufficiently sophisticated to make suitably informed decisions as to whether or not they should accept and/or trust certificates with which they may be presented when conducting online transactions. Furthermore, there are known vulnerabilities in the MD5 hash algorithm that is used to ensure the integrity of a majority of the certificates used on the Internet today, thereby opening the possibility that users may be presented with forged certificates, apparently issued by trusted authorities. While more secure hashing algorithms may be used (such as SHA-2, or the forthcoming SHA-3), it remains a truism that advances in security technology are constantly required to stay ahead of corresponding advances in the techniques used to break such technology, as well as the level of computing power available with which to do so.

As such, there remains an ongoing need for improved methods and systems for enhancing electronic transaction security, which are sufficiently robust to remain effective despite the increasing sophistication of fraudulent operators. It is an object of the present invention to provide methods, systems and computer software products that are able to enhance the security and integrity of online and other electronic transactions. SUMMARY OF THE INVENTION In one aspect, the present invention provides a method for authentication of a user, in a system including a client device operated by the user in communication with an authentication server operated by or on behalf of a service provider, the method including the steps of: generating unique identifying information of the user and at least one set of encryption keys that is uniquely associated with the user; associating with the client device a plurality of identifying codes corresponding with a configuration of the client device; generating at least one client identifier based upon a selected set of said identifying codes; providing a user record in a database accessible by the authentication server, and storing a copy of the encryption keys, the unique identifying information of the user, and one or more of the client identifier and the identifying codes, in association with the user record; the client device requesting authentication of the user by: receiving the unique identifying information from the user; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; and transmitting the authentication request message to the authentication server, the authentication server authenticating the user by: receiving the authentication message; accessing the user record to retrieve the unique set of encryption keys, the client identifier and/or the identifying codes; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison. Advantageously, therefore, embodiments of the invention create a unique association between a particular user (eg a customer), one or more client devices owned or operated by the user (eg home, office or personal computers, PDAs and the like), whereby the user is authenticated not only by the provision of known credentials (ie unique identifying information such as a user name and/or password), but also by the use of the particular client device in the conduct of an electronic transaction. In particular, a specific client device may be identified by the user of characteristic configuration information, such as identifying information of installed hardware and/or software components, which may be unique, or almost so, to each relevant device. Advantageously, therefore, even if a third party is able to obtain the user's identifying information (eg user name and/or password), this information is insufficient to complete authentication. More particularly, authentication requires provision of the unique identifying information of the user, in combination with the identifying codes corresponding with the client device configuration and/or the associated client identifier, as well as the user's unique set of encryption keys. Preferred embodiments of the invention, as described in greater detail herein, include additional measures that substantially eliminate the possibility of any malicious third party gaining access to all of the information necessary to defeat the authentication process and thereby impersonate the original user.

Preferably, the set of encryption keys is not only uniquely associated with the user, but also uniquely associated with the client device. It is particularly preferred that multiple sets of encryption keys may exist, corresponding with a plurality of client devices of the user, such as the user's home PC, office PC, laptop, PDA and so forth. Similarly, multiple users of a single client device (such as different users of a single PC) will have their own sets of encryption keys uniquely associated with the user/device combination. Advantageously, therefore, fraudulent use of the encryption keys by another user and/or from an unknown client device may be prevented.

Preferably, the unique identifying information of the user includes a unique personal identifier, such as a user name. Advantageously, the unique personal identifier may be an email address of the user, since every email address (Ze combination of account name and email domain) is globally unique. Preferably the unique identifying information of the user further includes a password or pass phrase, which ideally is kept secret by the user.

The identifying codes corresponding with a configuration of the client device are preferably characteristic codes or values associated with particular items of installed hardware and/or software. For example, identifying codes may include serial numbers, or other unique identifying numbers of particular hardware components, installation keys, version numbers and/or serial numbers of installed software applications, disk volume identifiers, a processor ID, and/or any other information that is reasonably stable over time and accessible to software executing on the client device. In one example, much of this type of information may be retrieved from registry keys under the Microsoft Windows operating system, while other mechanisms are available in many other operating systems. As a further example, some configuration information may be available directly from installed hardware devices, or via copies stored in a registry or similar, such as the unique MAC address of a network interface card. Various other sources of identifying codes corresponding with a configuration of the client device will be apparent to persons skilled in the relevant art. In a preferred embodiment, the client identifier is a mathematical and/or logical function of the identifying codes. Advantageously, a plurality of such functions may be provided, such that a different client identifier value may be used in each authentication request and/or other transaction. In this case, even if a third party is able to obtain a client identifier, for example by eavesdropping upon one or more transactions, this identifier will be of no value unless the eavesdropper is also in possession of all of the underlying identifying codes, the full range of functions used to generate client identifiers, and knowledge of the sequence in which those functions are applied. It is further preferred that following authentication the set of encryption keys is replaced with a new set. A new set of encryption keys may be generated by the authentication server, and transmitted, in encrypted form, to the client device. Advantageously, even if a third party is able to obtain the user's set of encryption keys at some point in time, for example by the deployment of spyware on a client device, these keys may be invalid by the time the third party is in a position to make use of them. Transactions subsequent to the authentication process may also be encrypted using the user's set of encryption keys, and similarly the keys may be replaced following any such transaction.

It is further preferred that the content of the authentication request message is encrypted using an encryption key which is based not only upon the user's set of encryption keys, but also upon other information. In particular, the content of the authentication request message may be encrypted using an encryption key which is a function of at least one key from the set of encryption keys, and other information, such as the unique identifying information of the user and/or the client identifier. Similar encryption techniques may be used to protect the content of further transaction messages subsequent to authentication.

It is preferred that the content of the authentication response message is also encrypted in a similar manner. Accordingly, a third party will be prevented from intercepting the authentication response message and fraudulently modifying its contents.

In accordance with preferred embodiments, which operate over the Internet via the World Wide Web, the authentication request message, the authentication response message, and subsequent transaction messages, are transmitted via a channel that provides an additional level of encryption, such as an SSL or TLS connection. It is important to appreciate that the encryption provided in accordance with embodiments of the present invention is additional to any conventional encryption that may be utilised for communication of authentication and transaction messages.

More particularly, it is preferred that one or more subsequent transactions between the client device and a service provider server are at least partially encrypted and/or verified using at least one key from the set of encryption keys and/or other information, such as a client identifier or the unique identifying information of the user. Advantageously, this ensures that once the user and corresponding client device have been identified and authenticated, further transactions cannot be hijacked by a third party, such as an eavesdropper or man-in-the-middle.

The question naturally arises as to how the information required by the authentication method is initially shared between the user, client device and authentication server. This is addressed in preferred embodiments of the invention by, prior to authentication of the user, associating the client device with the user by performing the steps of: the user being provided with a unique activation code via a trusted communications channel; storing a copy of the activation code in association with the user record; the client device performing the steps of: receiving from the user the activation code and the unique identifying information of the user; forming an association request message including the unique identifying information of the user and the activation code, along with the client identifier and/or the identifying codes; and encrypting and transmitting the association request message to the authentication server, the authentication server performing the steps of: receiving and decrypting the association request message; comparing the activation code in the association request message with the copy stored in association with the user record; and in the event of a match, associating the client device with the user by storing a copy of the client identifier and/or the identifying codes in association with the user record.

Advantageously, therefore, preferred embodiments of the invention enable a client device to be associated with a user, and the relevant information transmitted to the authentication server, and stored in association with the user record, in a secure manner that is not readily susceptible to interception and/or interference by third parties. Central to this facility is the ability to provide the user with a unique activation code, unknown to any third party, via a trusted communications channel. The trusted communications channel is preferably distinct from the communications network, such as the Internet, used for communication between the client device and the authentication server. A trusted communications channel is not necessarily wholly technological in nature, and may involve personal delivery of an activation code to the user, for example by the user attending a local branch of their bank in order to obtain an activation code. Alternative options for the trusted communications channel are via telephone or regular mail (including registered mail).

The user may also be provided with the necessary software for installation on the client device via the same, or a different, trusted, communications channel. The software may itself be allocated a unique serial number, or equivalent code, which allows it to be installed on only one client device and/or in association with only one particular activation code. Such measures enable a very high degree of confidence to be obtained that a user and client device seeking access to the authentication services are the user and client device initially authorised by the service provider, such as the user's banking institution.

In another aspect, the invention provides a client device comprising: at least one microprocessor; a communications interface, operably associated with the microprocessor, which is connected to a communications network; a user interface device adapted to receive input from a user; at least one storage device, which includes at least one set of encryption keys that is uniquely associated with the user, and executable program instructions which, when executed by the microprocessor cause the client device to implement an authentication request method including the steps of: receiving, via the user interface device, unique identifying information of a user; generating a client identifier based upon a selected set of identifying codes corresponding with a configuration of the client device; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; transmitting the authentication request message, via the communications interface, to an authentication server; and receiving an authentication response message, via the communications interface, from the authentication server. In yet another aspect, the invention provides an authentication server comprising: at least one microprocessor; a communications interface, operably associated with the microprocessor, which is connected to a communications network; a database, accessible to the microprocessor, including one or more user records, each user record including unique identifying information of a corresponding user, at least one set of encryption keys uniquely associated with the user, and at least one client identifier and/or identifying codes corresponding with a client device of the user; and at least one storage device including executable program instructions which, when executed by the microprocessor cause the authentication server to implement a user authentication method including the steps of: receiving from a client device, via the communications interface, an authentication request message including unique identifying information of a user, and a client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys associated with the user; accessing the user record corresponding with the unique identifying information to retrieve the unique set of encryption keys, the client identifier, and/or the identifying codes; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison. In yet another aspect, the invention provides a computer software product comprising computer-executable instructions and computer-readable data embodied on a tangible computer-readable medium, wherein the computer-readable data includes at least one set of encryption keys that is uniquely associated with a user, and the computer-executable instructions, when loaded and executed on a client device, cause the client device to implement an authentication request method including the steps of: receiving, via a user interface of the client device, unique identifying information of a user; generating a client identifier based upon a selected set of identifying codes corresponding with a configuration of the client device; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; transmitting the authentication request message, via a communications interface of the client device, to an authentication server; and receiving an authentication response message, via the communications interface, from the authentication server.

In a preferred embodiment, the instructions and data comprise at least three components, wherein at least the second and third components are encrypted, and execution of the first component causes the client device to implement the steps of loading, decrypting and executing the second component which then causes the client device to load, decrypt and execute the third component. Furthermore, the second component preferably comprises a first part embodied on the computer-readable medium and a second part, which is downloadable in encrypted form from the authentication server, and execution of the first component causes the client device to implement the steps of: downloading the second part of the second component from the authentication server; loading the first and second parts of the second component; and decrypting and executing the second component.

It is further preferred that the first component is also encrypted, and is configured to be loaded, decrypted and executed by a signed applet, or equivalent, which is downloaded from a web site operated by, or on behalf of, the service provider.

Advantageously, preferred embodiments of the client device computer software product therefore provide additional layers of security directed at frustrating attempts by a third party, for example through the use of spyware or by other means, from hijacking the client device, or intercepting and/or interfering with the authentication process within the client device.

In yet another aspect, the invention provides a computer software product comprising computer-executable instructions embodied on a tangible computer-readable medium which, when loaded and executed on a suitable computer cause the computer to implement a user authentication method including the steps of: receiving, via a communications interface of the computer, an authentication request message including unique identifying information of a user, and a client identifier, wherein at least the client identifier is encrypted using at least one key from a set of encryption keys uniquely associated with a user: accessing a user record associated with the unique identifying information, and held in a database, wherein the user record includes a copy of said set of encryption keys uniquely associated with the user, and at least one client identifier and/or identifying codes corresponding with a client device of the user; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison. Further preferred features and advantages of the present invention will be apparent to those skilled in the art from the following description of a preferred embodiment of the invention, which should not be considered to be limiting of the scope of the invention as defined in any of the preceding statements, or in the claims appended hereto. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention are described with reference to the accompanying drawings, wherein:

Figure 1 is a schematic diagram of a system embodying the present invention; Figure 2 is a block diagram illustrating a software architecture of a system embodying the present invention;

Figure 3 illustrates a registration process according to preferred embodiments of the invention;

Figure 4 illustrates an association process according to preferred embodiments of the invention; and

Figure 5 illustrates an authentication and transaction process according to preferred embodiments of the invention. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Preferred embodiments of the present invention are described in detail below with reference to a particular implementation environment. In particular, an implementation relevant to a client device having a hardware architecture generally consistent with an IBM® compatible PC running the Microsoft®

Windows® operating system is described (ie "Wintel" platform), for convenience and specificity. However, it will be appreciated by persons skilled in the art that equivalent implementations may readily be developed for other platforms, such as computers manufactured by Apple Corporation and running the MAC OS™ operating system, and/or portable devices such as PDAs and cellular telephones, which support generally similar functionality to that of the "Wintel" platform. Accordingly, any reference to platform-specific technologies and functionality should not be considered to be limiting of the overall scope of the invention.

Embodiments of the invention also rely heavily upon the use of encryption. Unless otherwise specified, or required by the context, where the term "encryption" is used within the following description it should be taken to refer to a strong symmetric cipher, such as the Advanced Encryption Standard (AES) (based upon a 128-, 192- or 256-bit encryption key), Blowfish, or similarly strong symmetric cipher. The implementation of such encryption algorithms is well-known and widely publicised, and accordingly will not be described in detail herein. Rather, the advantageous features of the embodiments described below relate to the manner in which suitable encryption keys are generated and/or distributed within an authentication system.

Similarly, where the term "hash" is used within the description, this is to be interpreted as a reference to a strong cryptographic hash function. As is well known to persons skilled in the art, a cryptographic hash function takes a block of data (eg digital information, program code, and so forth) and returns a fixed-size result, using an algorithm selected such that an accidental or intentional change to the data will almost certainly change the hash value. Commonly used hash functions include MD5 and SHA-1 , however these functions are now known to have vulnerabilities, and thus are not preferred for use with embodiments of the present invention. Suitably strong hash functions include SHA-2, and its proposed successors, which provide preferred implementations.

The term "server" when used within the following description, refers to one or more computers and/or software executing thereon, which provide a particular automated technical implementation of a service, such as a banking or other online transaction service, or an authentication service in accordance with a preferred embodiment of the invention. The term "server" should be distinguished from the term "service provider" which refers herein to a person or corporation providing a specific service to consumers, such as banking, or other commercial or government services, for example.

Similarly, the term "client" or "client device" as used herein encompasses one or more microprocessor-based devices and/or software executing thereon which may be used to access a server, operated by or on behalf of a service provider. The term "client" should therefore be distinguished from the terms "user" and "customer", which refer to the human operator wishing to avail themselves of the service(s) provided by the service provider.

It will therefore also be understood that embodiments of the present invention provide a technical solution to the technical problems relating to authentication of client devices and security of critical transactions and other information exchanges within insecure networking environments, such as the Internet. While the invention finds particular application in relation to the online conduct of financial transactions, which have specific requirements in relation to authentication and security, it is not limited to such applications, and is not an "e-commerce" application per se. Embodiments of the invention are able to provide enhanced utility for any and all information exchanges taking place over insecure and/or public networks, irrespective of the nature and content of the information involved. Turning now to Figure 1 , there is shown a schematic diagram 100 of a system embodying the present invention. The system 100 includes a number of computers or other devices, 120, 140, 160, which are interconnected and in communication with one another via the Internet 102 and/or other communications links, eg private link 104. In particular, the exemplary system 100 includes a client device 140, a service provider server 160, and an authentication server 120. For convenience and specificity, but without limitation, in the subsequent description it is assumed that the service provider is a bank, and that the server 160 is configured to provide online banking services. Accordingly, in this example the authenticity and security of access to the online banking services is of critical importance, since unauthorised use may result in defrauding of bank customers, and subsequent losses to the bank.

In the exemplary schematic system 100, each of the components 120, 140, 160 is presumed to comprise a conventional computer architecture, from which details irrelevant to implementations of the invention have been omitted. Relevantly the authentication server 120 includes at least one microprocessor 122, which is interfaced, or otherwise associated, with a high-capacity, non-volatile memory/storage device 124, such as one or more hard disk drives. The storage device 124 typically contains program and data required for the operation of the server 120, and for the implementation and operation of various software components implementing an embodiment of the present invention. The programmatic means by which this may be achieved are well-known in the art, and accordingly will not be discussed in detail herein. The authentication server 120 further includes an additional storage medium 126, typically being a suitable type of volatile memory, such as random access memory, for containing program instructions and transient data relating to the operation of the server 120. Additionally, the authentication server 120 includes a network interface 128, accessible to the microprocessor 122, facilitating communications with other devices, and in particular with the bank server 160. As shown in the exemplary system 100, a dedicated communications link 104 is provided between the authentication server 120 and the bank server 160, to ensure the security and integrity of information transmitted therebetween. In various embodiments, however, the link 104 may be provided via a separate private network, or Virtual Private Network (VPN) implemented wholly or partially via the Internet 102.

In other embodiments, the authentication server 120 may be implemented as a separate software process, or group of software processes, executing concurrently with the online financial services on the bank server 160. All such variations are within the capability of persons skilled in the art, and fall within the scope of the present invention.

The authentication server memory device 126 contains a body of program instructions 130 embodying various software-implemented features of the present invention, as described in greater detail below with reference to the remaining drawings. In general, these features include data processing functions implementing a method for authentication of a user in the system 100, including the client device 140 operated by the user in order to access the bank server 160.

Turning now to the client device 140, this is similarly a computing device based upon a microprocessor 142, interfaced to a high-capacity, non-volatile memory/storage device 144, used primarily to contain programs and data required for operation of the client device 140, and for the implementation and operation of various software components implementing an embodiment of the present invention. The client device 140 also includes suitable volatile memory 146, such as Random Access Memory, for containing program instructions and transient data relating to the operation of the client device 140. A network interface 148, accessible to the processor 142, facilitates communications via the Internet 102. The memory device 146 contains a body of program instructions 150 embodying various software-implemented features of the present invention, as described in greater detail below with reference to the remaining drawings. Additionally, in the exemplary embodiment the executable instructions 150 include components of a web browser application, which is operated by a user in order to access the services provided by the bank server 160, as well as (eg via suitable plug-in or other extension components) the authentication services provided by the authentication server 120. Additional peripheral interfaces, eg 152, provide for user input and output, for example via a keyboard, display and/or pointing device, such as a mouse. The bank server 160, which may be just one of a farm of such servers, includes at least one microprocessor 162, which again is interfaced, or otherwise associated, with a high-capacity storage device 164, such as one or more hard disk drives. As with the computers 120, 140, a primary purpose of the storage device 164 is to contain programs and data required for the operation of the bank server 160, and to facilitate communication with the authentication server 120, in accordance with an embodiment of the present invention.

The bank server 160 further includes suitable volatile memory 166, for containing program instructions and transient data relating to the operation of the bank server 160. A first network interface 168 provides access to the Internet 102, enabling the client device 140 to access the online banking services provided by the server 160. A second network interface 170 facilitates communication with the authentication server 120. In some embodiments, a single network interface may be sufficient to enable communications via the Internet 102, and with the authentication server 120. In particular, the bank server is preferably located behind a firewall, indicated by the dashed line 106, which is configured to prevent unauthorised access to services and sensitive financial data maintained by, or with the assistance of, the bank server 160. Computers located behind the firewall 106, such as bank server 160 and authentication server 120, may communicate with one another securely, without the need to provide a dedicated link, such as link 104.

The memory device 166 contains a body of program instructions 172 which execute in order to provide the online financial services of the banking service provider. These may include a web server application, providing general access to information about the bank's services, and other less sensitive information and services, as well as additional software components implementing secure online financial services. In preferred embodiments, a further software component is provided within the body of instructions 172 which facilitates communications relating to authentication and transaction security involving the client device 140 and the authentication server 120. Further details of this preferred software architecture are described below with reference to Figure 2.

Turning now to Figure 2, there is illustrated a software architecture of a system embodying the present invention, corresponding with the physical configuration 100 represented in Figure 1. A web browser application 240 is executed on the client device 140. As described in greater detail below, with reference to Figures 3 to 5, a plug-in or extension module 242 is provided, which includes one or more software components embodying elements of the present invention. The module 242 may include an applet, such as a Java-based client application, and/or native code components, such as one or more dynamically linked libraries (DLLs) when implemented within the Microsoft® Windows® operating system environment.

A bank server application 260, executing on the server platform 160, includes the bank's web and other application server software components 262. These comprise the conventional online banking services, familiar to many Internet users. An additional web software component 264 provides an "interface" between the client application 240, and the authentication server application 220. In particular, and as described in greater detail below, authentication messages and other transaction messages requiring encryption, decryption, authentication, verification and so forth (ie services provided by the authentication server 120), and which are not therefore comprehensible to the conventional online service applications 262, are processed via component 264, which communicates with the authentication service 220 as required. The authentication service software components 220 are able to access a database 222, which contains user records associated with various users of the authentication services, and online banking services. The database 222 may be stored, for example, on the storage device 124. Alternatively, the database 222 may be located on a remote storage device, accessible via a suitably secure communications link or network.

As has previously been mentioned, it is not necessary that the online banking services applications 260 and the authentication service components 220 execute on distinct hardware platforms 160, 120. In particular, these services may be provided via a single server, and/or distributed over multiple computing platforms in a server farm. All such variations are within the capabilities of persons skilled in the art, and fall within the scope of the present invention.

The discussion now turns to a preferred method for authentication of a user, embodying the present invention. The core feature of the authentication method is a process whereby each time a user wishes to access online services provided by the server 160, the user may be reliably and securely authenticated in order to prevent unauthorised use of those services by third parties. In accordance with the preferred embodiment, this core authentication method forms part of a larger process whereby a user is first required to register for subsequent access to the authentication services, and then to associate one or more client devices with a user record maintained by the authentication server 120. Furthermore, preferred embodiments of the present invention provide for ongoing security of critical transactions that are conducted once the authentication steps have been completed. In summary, therefore, the preferred embodiment incorporates the following phases:

- registration, whereby the user provides adequate proof of identity, and an initial exchange of information takes place ensuring that the user is able to establish secure and trusted communications with the authentication server 120;

- association, whereby the user configures one or more client devices which will be used to access the authentication services; - authentication, which is the core method implemented by embodiments of the present invention, for confirming the identity of the user and securing information exchanged between a client device 140, the authentication server 120, and a service provider server 160; and

- subsequent support of secure transactions, based upon the authenticated user and client device information.

These phases will now be described in greater detail with reference to Figures 3 to 5. Figure 3 illustrates an exemplary registration process, according to an embodiment of the invention. Preferably, a suitable registration process is not fully automated, and may involve a conventional confirmation of the user's identity, for example by face-to-face contact, the provision of reliable security or identity documents (such as a passport), and/or a telephone interview in which the user is required to answer suitable "challenge" questions. In the case of a user seeking registration via a financial service provider, such as their bank, it is likely that the user will have an existing relationship with the service provider, and will have previously provided sufficient proof of identity, for example when opening one or more accounts. In this case, the user may initiate registration by visiting a local branch of the financial institution, or by contacting the financial institution via telephone.

The registration process 300, as depicted in Figure 3, consists of a series of transactions executed between the user, or customer, 302, and the financial institution 304. Some, but not all, of these transactions may be electronic and/or automated. In preferred embodiments, as previously mentioned, the critical transactions associated with establishing the identity of the customer 302, and providing the customer with essential data and software components, are not fully automated, and involve human verification.

At transaction 306, the customer 302 provides the financial institution 304 with adequate proof of identity, for example by presenting in person at a local branch. Transaction 308 represents confirmation of identity.

In a subsequent transaction 310, the customer 302 generates and provides to the bank unique identifying information, such as a user name and/or a password that the customer intends to use in order to access online financial services. The identifying information may be unique to the particular financial institution, but preferably is globally unique. Advantageously, the generation of globally unique identifying information enables the same identifiers to be used by the customer in association with authentication services provided by or on behalf of other service providers. In a particularly preferred embodiment, the services provided by the authentication server 120 include access to a global database that may be shared amongst service providers 160, such that ideally each user may be required to register only once, for example via a single service provider, and subsequently be able to access common authentication services when dealing with a range of other service providers. In this regard, an authentication service provider implementing systems and methods embodying the present invention may become a trusted global provider of authentication services.

During the transaction 310, which again may be conducted in person and/or over the telephone, the customer 302 may provide any other information required by the financial institution 304, or which may be subsequently convenient or desirable. Such information may include, but is not limited to, additional contact information and/or a "nickname" that may be used for convenience during online transactions with the server 160. The customer 302 must then be supplied with relevant software components for installation on one or more client devices, which the customer 302 intends to use in order to access online services provided by the server 160. Preferably, the financial institution 304 implements the step 312 of generating a unique software installation for use by the customer 302. The requisite "uniqueness" may be achieved by associating an individual serial number with the copy of the software provided to the customer 302, for example on a CD or other tangible media. Alternatively, the customer 302 may be able to download the software for installation, for example from the financial institution's web server 160, and may be assigned a unique download authorisation code for this purpose. Advantageously, this approach enables the financial institution 304 to track the use and registration of the software, to ensure that only authorised customers are able to successfully install the software. This additional layer of security may be desirable, in order to avoid subsequent reliance upon the unique identifying information of the user (eg an email address and/or password) which may become known to third parties.

In any event, transaction 314 consists of the financial institution 304 providing the customer 302 with the installable software, via any suitable means, such as those discussed above.

The financial institution 304 then completes a further step 316 of assigning or allocating one or more activation codes, and then providing these to the customer 302 via the transaction 318. Activation codes are unique pass codes, preferably being numbers and/or alphanumeric strings of at least 16 characters in length, that the customer 302 subsequently uses to associate particular client devices with the authentication service. Preferably, the an activation code is a "single-use" code, used once as part of an associate process, and then discarded. The association process is described in greater detail below with reference to Figure 4, however in general terms it should be noted that in preferred embodiments of the invention the activation codes are of great importance to the integrity of the overall authentication system and process, and are therefore provided wholly, or in-part, to the customer 302 via a trusted communications channel. That is, the activation codes are preferably provided to the customer 302 via communications means that are spatially and/or temporally distinct from those untrusted channels, ie the Internet, that are used for association and authentication. Activation codes may be provided to the customer 302 in person, via the telephone, or by mail for example. It will accordingly be very difficult for any third party to intercept the customer's unique identifying information, the necessary installation software, and the customer's uniquely assigned activation codes, all of which are required to establish subsequent access to the authentication services.

In summary, therefore, at the conclusion of the registration process 300 the customer 302 has been provided with, at a minimum, an installable software application and one or more activation codes. The service provider (Ze financial institution) 304 has unique identifying information of the customer 302 (eg email address or other user name and/or a password) that will be used for subsequent access to online services, and also preferably possesses records associated with a unique software installation and a copy of the activation codes that have been issued. The information obtained by the service provider 304 is transmitted to the authentication service provider eg to the authentication server 120, and a corresponding user record is created and stored within the database 222. The creation of this record enables subsequent association of a client device by the customer, which will now be described in greater detail with reference to Figure 4.

Figure 4 illustrates an exemplary association process 400, which takes place between a client device 402 and the authentication server 404.

As a prerequisite to the process 400, the user installs and executes the software application that has been provided by the bank 304 during the registration process 300. The software application prompts the user to provide the unique identifying information (eg user name and password) and the activation code provided by the bank 304, in a conventional manner, such as by the display of a suitable dialogue box on a graphical user interface of the client device 402. In accordance with preferred embodiments of the invention, the application also prompts the user to identify a location with which the client device 402 is associated. For example, the application may provide the user with a choice of "home", "office", "laptop", and so forth.

As has previously been noted, preferred embodiments of the invention enable the use of multiple client devices by an individual user, and each client device may optionally require a separate activation code, and may have separate encryption keys and other relevant data assigned to it. Accordingly, the "location" provides a convenient mechanism for the user to distinguish between different client devices. It should be noted that if a particular user has requested, and been assigned, multiple activation codes associated with different client devices, all of these activation codes may be stored in the database 222, in association with the user record, and will therefore be available to the authentication server 404. Knowledge of the purported identity of the user, and the corresponding client device (Ze location) is accordingly sufficient for the authentication server 404 to verify the validity of a corresponding activation code. It should further be noted that while a user may be provided with multiple activation codes via a single trusted communication channel, in some embodiments of the invention it is possible that one or more activation codes may be included within the installation software provided by the bank 304 to the customer 302. It is possible that, once the user has associated a first client device, and been authenticated, the additional activation codes may be made available to the user by appropriate execution of the initially installed software, which can, for example, decrypt and display an embedded activation code, and generate a corresponding installation application for use on a further client device. This mechanism may avoid the requirement for the user once again to contact the bank 304, or visit a local branch in person, if an additional activation code is required. The point to be made here is that once a particular user has initially confirmed their identity, for example by attendance at a branch in person, obtained corresponding installation software, and associated at least one client device, the user's identity can then subsequently be reliably authenticated on-line, enabling a variety of transactions to be conducted securely (including the issue of additional activation codes) that might otherwise have been considered an unacceptable risk. Accordingly, in still further embodiments a service provider may implement a facility, in conjunction with the authentication server, enabling an authenticated user to request and receive a new activation code, and corresponding installation software, on-line.

Turning back now to the main association process 400, it will be convenient in the following discussion to refer to the unique identifying information of the user simply as "UID" and or "password" or "PW", the location as "LOC", and the activation code as "AVC". Initially the client computes an encryption key that will be used for encryption of all sensitive information during the association process 400. Preferably, the unique encryption key is a function of the UID and the AVC. Additionally, the encryption key may be a function of suitably unique identifying information of the authentication server 404, such as the authentication server IP address. In one particular embodiment, the association encryption key EK_as is a function of a hash of the AVC, a hash of UID, and the authentication server IP address. In the example process 400, the hashing operation is represented by the "#" symbol. At step 406, the client device 402 constructs and transmits a message

(Msg) to the authentication server 404. The message includes UID and LOC in unencrypted form, along with additional critical information encrypted using the abovementioned association encryption key. The encrypted critical information includes at least the AVC. Preferably, the encrypted critical information further includes a client identifier (CID) computed by the client device 402, in a manner that will be discussed in greater detail below.

In a particularly preferred embodiment the critical information includes the user's password, the AVC, and a reversible function of the CID and a value derived from the AVC, such as a hash of the AVC and/or other function thereof.

Upon receiving the message transmitted at step 406, the authentication server 404 obtains UID and LOC, which were transmitted in unencrypted form. This information is sufficient to enable the authentication server 404 to identify the appropriate user record in the database 222, retrieve the AVC associated with LOC, and thereby compute the association encryption key EK_as. The authentication server 404 is thus able to decrypt the remainder of the message, thereby retrieving for further verification the user's password, the AVC, and then to compute the CID that was previously calculated and transmitted by the client device 402. At this point, the authentication server 404 now has at least one CID that identifies the client device 402, and which is now associated with the user.

At step 408, by way of confirmation, the authentication server 404 constructs a message, encrypted using the association encryption key EK_as, which includes LOC and CID. At this point, it is possible to verify the authenticity and/or integrity of the installation and association applications executing on the client device 402, in embodiments where the user is provided with an installer having a unique associated installation code and/or serial number or the like. In particular, in step 410 this software identifying information, or a value derived therefrom, is encrypted and transmitted from the client device 402 to the authentication server 404. In a particularly preferred embodiment, the actual value transmitted is a software-identifying code which is a function of the installation code or serial number, the CID, and a hash computed from the actual application program files. As will be appreciated, if this value is successfully verified by the server 404, this is strong evidence that the installation application has not been hijacked, or tampered with. Furthermore, the authentication server 404 may identify the received installation code or serial number as having been used, and subsequently refused to allow further installation and/or association processes to complete successfully, based upon the same installation code or serial number.

In a further preferred step 412, the client device 402 transmits all of the identifying codes corresponding with its configuration "CONF" to the authentication server 404 which is thereby able to store these codes in association with the user record. Advantageously, it is thereby possible for both the client device 402 and authentication server 404 to subsequently calculate one or more CIDs on demand, based upon the identifying codes CONF.

Assuming that all of the foregoing steps are successful, the association of the client device 402 with the user is deemed to be valid, and at step 414 the authentication server 404 transmits all of the program code components and data components required for subsequent authentication processes to the client device 402. In a preferred embodiment, the authentication software code comprises first-, second- and third-code components. The first-code component, identified herein as "lnterface.dll", which is a DLL that can be loaded into a browser application executing on the client device 402, to act as an interface between the web browser and the other authentication application components. A second-code component preferably consists of two parts, wherein the first part, identified as "AuxiliaryMain.obj" is downloaded to the client device 402 at step 414, and subsequently resides thereon. The second component is a further DLL, of which AuxiliaryMain.obj is an incomplete portion, whereby at authentication it is a function of lnterface.dll to download the second part from the authentication server 404, as described in greater detail below with reference to the authentication process in Figure 5. The third component, identified as "Authentication. obj" is a further DLL providing the main client authentication functionality, that is loaded and executed by the second-code component. In the exemplary embodiment, all three code components are downloaded in encrypted form, stored on the client device 402 in encrypted form, and are decrypted in memory, as required, to prevent unauthorised third parties from readily gaining access to their contents.

Data components that are downloaded in accordance with the exemplary embodiment include a service provider data file, identified as "VDAT.obj" which contains specific service provider information (such as the relevant server IP address) that may be required for subsequent authentication processes. Further data components include a pair of encryption key set files, identified as "EKSI .obj" and "EKS2.obj", the first of which is used for encryption of messages during authentication and transaction processes, and the second of which may be used to encrypt messages in transactions utilised to update the encryption key sets. As with the executable code components, all of the data components are preferably encrypted.

The key or keys required for decryption of the code and data components may be maintained by the authentication server 404, provided only as required for decryption of the code and data components, and may be changed after each use to ensure that if any one encryption key is intercepted by a third party, it cannot subsequently be used to gain access to the critical contents of the code and data components.

Once the code and data components have been downloaded to the client device 402 at step 414, the system is fully configured for subsequent authentication of the user.

As has been noted above, an important element of all transactions between a client device 402 and authentication server 404 is the CID, which in turn is based upon a number of identifying codes corresponding with a configuration of the client device. The identifying codes are values associated with various hardware and/or software components installed on the client device, and may include serial number, identifying addresses, part numbers, revision or version numbers, volume labels, and so forth that are commonly associated with hardware and software components, and which may be read directly from hardware and/or from system files such as the Windows® registry. Such codes may be associated, for example, with a system motherboard, monitor, keyboard, mouse, CD- or DVD-drive, hard disk drive, operating system configuration, user account details, network interface cards, modems, printers and so forth. A CID is preferably any convenient arithmetic and/or logical function of two or more of these identifying codes.

In a particularly preferred embodiment, multiple different functions are defined, each of which computes a CID based upon a subset of, for example, three, four or five, of the identifying codes. A particular CID may then be specified by a function identifier (which defines the use of a particular function), along with a sequence of values specifying which particular identifying codes should be used in the computation of the identified function. In addition, a "global" CID may be defined, which is, for example, a sum of all of the identifying codes. While the preceding and following description refers always just to a "CID", it should be understood that any CID may be either the "global" CID, or an alternative CID, ie a "dynamic" CID, based upon a suitable functional specification. In particular, as part of any transaction the authentication server may transmit to a client device a message specifying one or more dynamic CID functions, which are to be used to compute the CID in a corresponding one or more subsequent messages.

A further benefit of this approach is that it facilitates the management of client device configuration changes. As will be appreciated, certain hardware and software components on a given hardware device are liable to reconfiguration from time-to-time. For example, a user may install or uninstall particular software packages, or may add, remove or replace various hardware devices, such as a network card or printer. In this event, the record of corresponding identifying codes maintained by the authentication server will no longer match the client device. This may be handled in a number of ways, two examples of which are now provided.

In a first approach to managing client reconfiguration, suitable CID functions are defined that are reversible, in the sense that the original identifying codes used in calculation of the CID may be reconstructed from the result. In this case, if the authentication server identifies a mismatch between a CID received from a client device, and the corresponding CID calculated using its local information, it is able to determine whether the mismatch is due to a change in one or more of the individual identifying codes. If the only change is, for example, in a code associated with a hardware peripheral such as a network card, the authentication server may conclude that the client device has been reconfigured, and update its record of the identifying code accordingly. On the other hand, if all of the identifying codes appear to have changed, or a particularly significant hardware component, such as a motherboard, does not match, the authentication server may conclude that the client device is not authentic, and discontinue further transactions.

In a second exemplary approach, irreversible CID functions may be employed, and the authentication server may send a message to the client device requesting that it calculate multiple CIDs based upon different combinations of the individual identifying codes. Those CIDs that are based on codes corresponding with hardware or software components that have not been reconfigured will match the corresponding values computed by the authentication server. CIDs including identifying codes corresponding with hardware or software components that have been reconfigured will fail to match. In this way, the authentication server is able to identify, as previously, whether there has been a minor change in configuration, or alternatively whether the client device may be inauthentic.

An exemplary authentication and subsequent transactions process 500 is illustrated in Figure 5. This process takes place between a client device 502, which has previously been associated as described above, and a server 504 which will typically involve services provided by the both the bank server 260 and the authentication server 220, as illustrated in the software architecture 200 of Figure 2.

In a first step 506, the user of the client device 502 uses a web browser to access the bank web page, and enters unique identifying information, ie the user name or UID. It is not necessary that a password be supplied at this stage, and the security of the system is not in any event based upon a user name or password, but rather upon characteristic information of the client device 502, and the software and data components installed thereon. Advantageously, by the user providing a UID in the first step 506 is that the server 504 is thereby immediately able to access the corresponding user record in the database 222, for use in subsequent steps. It should be understood that provision of the UID simply informs the server 504 who the user of the client device 502 purports to be prior to authenticating this identity. At step 508 the server serves a suitable "log-on page" or equivalent to the browser executing on the client device 502, which may optionally use an encrypted connection, such as an SSL or TLS connection via the HTTPS protocol. At step 510 a signed applet is served by the bank server 504 to the client device 502. This is preferably a Java applet, but may be an ActiveX control or other functional equivalent. Since the applet is signed, the user will be prompted and required to accept a digital certificate to enable the applet to run on the client device 502. While this provides an additional level of security, and in principle enables the user to identify a fraudulent applet, even if the user mistakenly accepts an untrusted or forged certificate further levels of security embodied in the present invention will cause one or more of the subsequent steps to fail, if the applet is not genuine. Once executing on the client device 502, the applet verifies the various installed software and data components, for example by computing and checking a hash value of each component, and then loads, decrypts and executes the first component, "lnterface.dll".

The first component confirms successful initialisation at step 512, and the server 504 then responds at step 514. In particular, the response 514 is a message which has been encrypted using a suitable key, which is preferably a function of unique identifying information of the server 504, such as its IP address, and of one or more of the encryption keys held in the encryption key sets (EKS) associated with the client device 502. In order to decrypt this message, the first software component executing on the client device 502 may use a copy of the IP address held in the local "VDAT.obj" file, may resolve the address of the server 504 via the DNS system, or may use the source address of incoming IP datagrams sent by the server 504. Furthermore, the client device 502 may perform a validation step by comparing two or more of these values, in order to verify that the message has indeed been sent by the bank server 504. Ultimately, however, the client device 502 will be unable to decrypt the message if it was not encrypted using the correct identifying information and encryption keys. Accordingly, successful decryption of the message provides a strong assurance that the client device 502 is, and remains, in communication with the intended server 504. Nonethless, in preferred embodiments the validation step may be repeated during each subsequent transaction between the client and server, as an additional confirmation of the ongoing security and integrity of the session.

The message transmitted at step 514 may contain additional information required for further steps of the authentication process. For example, the message may contain, in encrypted form, instructions for the calculation of CID values to be used for subsequent messages. The message may also contain a hash of the user's password.

At step 516, the first component executing on the client device 502 requests that the server 504 provide a copy of the second part of the second software component, known herein as "AuxiliaryExtra.obj". At step 518 this part-program component is downloaded to the client device 502, in encrypted form. The first software component loads, assembles and decrypts both parts of the second software component in memory of the client device, and then executes the second software component. The primary function of the completed second software component is to load, decrypt and execute the third software component, "Authentication. obj".

Upon execution, the third software component presents the user with a further dialogue box, for entry of the user's password. A hash of this password is computed, using the same algorithm as for the hashed password sent by the server 504 in the message at step 514. If a match is found, then a CID is calculated. At step 520, a message is constructed which includes the UID, password, CID, and any other relevant information, the message is encrypted, using a key derived from the unique EKS of the client device and/or any other pertinent data (such as the CID), and the message is transmitted to the server 504. If the server is able to successfully decrypt the message, and if the UID, password, CID, and any other relevant information all match corresponding values held in the database in association with the user record, then the server 504 will be satisfied that the authentication request has been made by the specified user, using the associated client device, and a successful authentication will be completed.

Subsequent to authentication, any further sensitive transactions, such as financial transactions and/or transmission of other messages including personal information, may be transmitted in a secure and authenticated format. As illustrated by the step 522, such sensitive transactions may be conducted by combining the transaction data (which may be any information deemed to require secure and authenticated transmission, in either direction) with a CID, and then encrypting the resulting message using a key derived from the client device key sets EKS. Such messages will typically be intended for processing by the service provider, but will also require decryption and verification by the authentication server. The mechanism by which this may be achieved can be understood by reference to Figure 2. In particular, the transaction data generated via browser 240 on the client's device is converted into a secure transaction message, in the manner described above, by the "Authentication. obj" module 242. The relevant content of the message is intended for processing by the bank's web and other application server software components 262, but is passed via the interface application 264. The message is recognised as requiring verification, and is therefore passed to the authentication server application 220, which decrypts the message, extracts and verifies the CID, and (if successful) transfers the unencrypted transaction data back to the interface application 264, which in turn passes the message to the service applications 262. Various methods for implementing this functionality, for example with a web-based environment, will be apparent to persons skilled in the art. However, by way of example only, one possible implantation would utilise a server-side applet, such as a JSP or ASP component, which is executed in the service of each web page requiring the secure, authenticated transfer of transaction data.

In conclusion, embodiments of the present invention implement an advanced authentication system that enables users to conduct sensitive online transactions, and other communications, with a high degree of confidence and security. In particular, the effectiveness of the systems and methods embodying the invention is based upon forming an initial trusted association between a user, one or more specific client devices used by the user to access online services, and a set of unique data (including, for example, secure encryption keys), all of which must be consistent to enable successful authentication prior to conducting the sensitive transactions. Following the initial provision of installation software and/activation keys to the user, and the installation of that software on a particular client device, subsequent authenticated transactions impose no more onerous requirements upon the user than conventional services based upon a simple user name and password combination. All of the additional strong authentication and encryption is implemented by mechanisms embodied within the software components, requiring no additional user actions. In preferred embodiments, various additional layers of security and/or obfuscation are provided, in order to foil various possible attempts to compromise the security of the system at the earliest possible stage. These additional methods are also transparent to the end-user.

While preferred embodiments, including variations where appropriate, have been described, these should not be considered to be limiting of the scope of the invention, which is as defined in the accompanying claims.

Claims

CLAIMS:

1. A method for authentication of a user, in a system including a client device operated by the user in communication with an authentication server operated by or on behalf of a service provider, the method including the steps of: generating unique identifying information of the user and at least one set of encryption keys that is uniquely associated with the user; associating with the client device a plurality of identifying codes corresponding with a configuration of the client device; generating at least one client identifier based upon a selected set of said identifying codes; providing a user record in a database accessible by the authentication server, and storing a copy of the encryption keys, the unique identifying information of the user, and one or more of the client identifier and the identifying codes, in association with the user record; the client device requesting authentication of the user by: receiving the unique identifying information from the user; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; and transmitting the authentication request message to the authentication server, the authentication server authenticating the user by: receiving the authentication message; accessing the user record to retrieve the unique set of encryption keys, the client identifier and/or the identifying codes; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison.

2. The method of claim 1 wherein the set of encryption keys is also uniquely associated with the client device.

3. The method of claim 2 wherein a plurality of sets of encryption keys is provided, corresponding with a plurality of client devices of the user.

4. The method of claim 1 wherein the unique identifying information of the user includes a unique personal identifier, such as a user name.

5. The method of claim 4 wherein the unique personal identifier is an email address of the user.

6. The method of claim 4 wherein the unique identifying information of the user further includes a password or pass phrase.

7. The method of claim 1 wherein the identifying codes corresponding with a configuration of the client device are characteristic codes or values associated with particular items of installed hardware and/or software.

8. The method of claim 7 wherein the identifying codes include serial numbers, or other unique identifying numbers of particular hardware components, installation keys, version numbers and/or serial numbers of installed software applications, disk volume identifiers, and/or a processor ID.

9. The method of claim 1 wherein the client identifier is a mathematical and/or logical function of the identifying codes.

10. The method of claim 9 wherein a plurality of functions is provided, such that a different client identifier value may be used in each authentication request and/or transaction.

11. The method of claim 1 wherein following authentication the set of encryption keys is replaced with a new set.

12. The method of claim 1 wherein the content of the authentication request message is encrypted using an encryption key which is a function of at least one key from the set of encryption keys, as well as the unique identifying information of the user and/or the client identifier.

13. The method of claim 1 wherein one or more subsequent transactions between the client device and a service provider server are at least partially encrypted and/or verified using at least one key from the set of encryption keys and a client identifier.

14. The method of claim 1 wherein, prior to authentication of the user, the client device is associated with the user by performing the steps of: the user being provided with a unique activation code via a trusted communications channel; storing a copy of the activation code in association with the user record; the client device performing the steps of: receiving from the user the activation code and the unique identifying information of the user; forming an association request message including the unique identifying information of the user and the activation code, along with the client identifier and/or the identifying codes; and encrypting and transmitting the association request message to the authentication server, the authentication server performing the steps of: receiving and decrypting the association request message; comparing the activation code in the association request message with the copy stored in association with the user record; and in the event of a match, associating the client device with the user by storing a copy of the client identifier and/or the identifying codes in association with the user record.

15. A client device comprising: at least one microprocessor; a communications interface, operably associated with the microprocessor, which is connected to a communications network; a user interface device adapted to receive input from a user; at least one storage device, which includes at least one set of encryption keys that is uniquely associated with the user, and executable program instructions which, when executed by the microprocessor cause the client device to implement an authentication request method including the steps of: receiving, via the user interface device, unique identifying information of a user; generating a client identifier based upon a selected set of identifying codes corresponding with a configuration of the client device; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; transmitting the authentication request message, via the communications interface, to an authentication server; and receiving an authentication response message, via the communications interface, from the authentication server.

16. An authentication server comprising: at least one microprocessor; a communications interface, operably associated with the microprocessor, which is connected to a communications network; a database, accessible to the microprocessor, including one or more user records, each user record including unique identifying information of a corresponding user, at least one set of encryption keys uniquely associated with the user, and at least one client identifier and/or identifying codes corresponding with a client device of the user; and at least one storage device including executable program instructions which, when executed by the microprocessor cause the authentication server to implement a user authentication method including the steps of: receiving from a client device, via the communications interface, an authentication request message including unique identifying information of a user, and a client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys associated with the user; accessing the user record corresponding with the unique identifying information to retrieve the unique set of encryption keys, the client identifier, and/or the identifying codes; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison.

17. A computer software product comprising computer-executable instructions and computer-readable data embodied on a tangible computer-readable medium, wherein the computer-readable data includes at least one set of encryption keys that is uniquely associated with a user, and the computer-executable instructions, when loaded and executed on a client device, cause the client device to implement an authentication request method including the steps of: receiving, via a user interface of the client device, unique identifying information of a user; generating a client identifier based upon a selected set of identifying codes corresponding with a configuration of the client device; forming an authentication request message including the unique identifying information and the client identifier, wherein at least the client identifier is encrypted using at least one key from the set of encryption keys; transmitting the authentication request message, via a communications interface of the client device, to an authentication server; and receiving an authentication response message, via the communications interface, from the authentication server.

18. The computer software product of claim 17 wherein the instructions and data comprise at least three components, wherein at least the second and third components are encrypted, and execution of the first component causes the client device to implement the steps of loading, decrypting and executing the second component which then causes the client device to load, decrypt and execute the third component.

19. The computer software product of claim 18 wherein the second component comprises a first part embodied on the computer-readable medium and a second part, which is downloadable in encrypted form from the authentication server, and execution of the first component causes the client device to implement the steps of: downloading the second part of the second component from the authentication server; loading the first and second parts of the second component; and decrypting and executing the second component.

20. The computer software product of claim 18 wherein the first component is also encrypted, and is configured to be loaded, decrypted and executed by a signed applet, or equivalent, which is downloaded from a web site operated by, or on behalf of, the service provider.

21. A computer software product comprising computer-executable instructions embodied on a tangible computer-readable medium which, when loaded and executed on a suitable computer cause the computer to implement a user authentication method including the steps of: receiving, via a communications interface of the computer, an authentication request message including unique identifying information of a user, and a client identifier, wherein at least the client identifier is encrypted using at least one key from a set of encryption keys uniquely associated with a user: accessing a user record associated with the unique identifying information, and held in a database, wherein the user record includes a copy of said set of encryption keys uniquely associated with the user, and at least one client identifier and/or identifying codes corresponding with a client device of the user; decrypting encrypted content of the authentication message including at least the client identifier; comparing the decrypted client identifier with the client identifier and/or identifying codes retrieved from the user record; and generating and transmitting an authentication response message based upon the result of said comparison.