GB2440358A

GB2440358A - Authentication system and method using One Time Passwords (OTPs)

Info

Publication number: GB2440358A
Application number: GB0613106A
Authority: GB
Inventors: Guy Moas; Ram Gabay
Original assignee: G3 Vision Ltd
Current assignee: G3 Vision Ltd
Priority date: 2006-06-30
Filing date: 2006-06-30
Publication date: 2008-01-30
Anticipated expiration: 2026-06-30
Also published as: GB2440358B; GB0613106D0

Abstract

An authentication system and method are provided, the method comprising, storing a user identification code (e.g. PIN) associated with said user, generating a plurality of functions (One Time Password (OTP) functions) for producing a pass code based on at least one input by a user, said at least one input comprising said user identification code, storing at least one function and associating said function with a user, generating an application (OTP application) adapted to implement said at least one function on the user device, supplying the application to said user device, generating a transaction code (or random/pseudo-random transaction number) associated with said transaction and supplying the transaction code to said application; and receiving a pass code (One Time Password) for said transaction from the user device and authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction. The authentication may comprise a comparison of the stored and supplied user identification code (PIN) or of the supplied and generated One Time Password ("OTP comparison", Figure 4).

Description

1 2440358

AUTHENTICATION SYSTEM AND METHOD

Field of the invention

In general, the invention relates to identity or password authentication in communication systems. In particular, the invention relates to systems having one or more user devices and a communication system. The Communication system may include a server providing services. In such systems a client device performs authentication with the communication system by using passwords and other security measures. The invention may also be used to authenticate users of other services where the transaction is person to person. Business to business application are also envisaged.

Background of the Invention

For many purposes, including transactions and other communications on communication networks, passwords will provide the most widely accepted authentication method for the foreseeable future. Password based authentication is readily available independent of network and device technologies.

Passwords can be vulnerable to interception (known as "snooping") while being transmitted to the authenticating machine or person. If the password is carried as electrical signals on unsecured physical wiring between the user access point and the central system controlling the password database, it is subject to snooping by wiretapping methods. If it is carried over the Internet, anyone able to watch the packets containing the logon information can snoop with very little possibility of detection.

Cable modems may be more vulnerable to snooping than DSL and dialup connections, and ethernet may or may not be snoopable, depending particularly on the choice of networking hardware and wiring. Some organizations have noted a significant increase in stolen passwords after users began using cable internet connections.

The risk of interception of passwords sent over the Internet can be reduced with the Transport Layer Security (TLS, previously called SSL) feature built into many Internet browsers. Most browsers display a closed lock icon when TLS is in use.

Unfortunately, there is a conflict between stored hashed-passwords and hash-based challenge-response authentication; the latter requires a client to prove to a server that he knows what the shared secret (the password) is, and to do this, the server end needs to be able to obtain the shared secret from its stored form. On Unix-type systems doing remote authentication, the shared secret becomes the hashed form and has the serious limitation that they expose passwords to offline guessing attack.

Rather than transmitting the password, password-authenticated key agreement systems can perform a zero-knowledge password proof, which proves knowledge of the password without revealing it. Taking it a step further, augmented systems for password-authenticated key agreement (e.g. AMP, B-SPEKE, PAK-Z, SRP-6) avoid both the conflict and limitation of hash-based methods; An augmented system allows a client to prove knowledge of the password to a server, where the server knows only a (not exactly) hashed password, and where the unhashed password is required to gain access.

Two-factor authentication (TFA) is an authentication technique that requires two independent ways to establish identity and privileges. This contrasts with traditional password authentication, which requires only one factor' (for example, knowledge of a static password) in order to gain access to a system.

The two factors' are generally: * Something you know', such as a password or PIN.

* Something you have', such as a credit card or hardware token.

Traditionally, two-factor authentication requires hardware tokens, which are expensive to distribute.

US-A-2003/0204726 discloses a method and system for secure transmission of information. A client sends to a server, a request, at least one unique identifier and an encryption key. The server generates a reply to the request and identifies a mobile device (based on the at least one unique identifier) to which to send the reply. The reply is encrypted using the encryption key. The encrypted reply is sent from the server to the identified client device. The request may be a request for an OTP.

US-A-200610059344 discloses an authentication service and aims to provide effective password delivery in communication systems. The technique disclosed comprises receiving key information for calculating at least one password by a user equipment from a communication network system via a secure channel, generating at least one password on the basis of the key information in the user equipment, and performing authentication between the user equipment and the communication network system using the at least one password. The intention is that password security and management be improved to reach the largest possible user base without authentication being the bottleneck for launching new services in mobile networks. Recently mobile operator's WLAN (Wireless Local Area Network) and xDSL (Digital Subscriber Line) authentication and access independent use of IMS (IP Multimedia Subsystem) and PoC (Push to talk over Cellular) services have suffered from strong coupling between the authentication, access network and terminal technologies. To minimize the SMS (Short Message Service) load that a conventional http digest password delivery causes, a Seed and Hash Approach is used. An entity in the communication network system, e.g. an operator's own service management system with a terminal management server generates the seed and optionally a (new) secret key, and sends it/them to the user equipment or terminal over SMS. The service management system generates and sends a new seed (and secret key) to the terminal after the number of generated passwords reaches a configurable threshold or a timeout expires. Requiring a subscriber to enter a PiN code before applying the hash function enhances the security of the mechanism.

Applying different seeds, secret keys and/or hash functions can create password domains.

US-A-2005/0245257 discloses a system and method of using the PSTN in providing authentication or authorisation for online transactions. Using substantially simultaneous transmissions on two different networks to verify a user's identity. US-A-2006/0036857 discloses user authentication based on linking between a randomly generate authentication secret and a personalised secret.

US-A-0l 14675 discloses user authentication by creating a key in the form of a user formula, presenting a user with an arrangement of variables, each assigned a value, applying the assigned values to matching variables in the user formula and calculating a first result; the user is authenticated if the first result matches a second result of a separate and independent calculation of the user formula.

US-A-2005/0069137 discloses a method of distributing the public key of an asymmetric key pair with a private key and the public key from a mobile station to a key managing computer, the method comprising communicating an OTP from the key managing computer to the mobile station by mean of a secure channel to provide a shared secret, first and second codes are calculated at the mobile station and the key managing computer respectively, transmitting the first code and the public key to the key managing computer, checking the authenticity of the user by comparing the first and second codes.

US-A-2003/0 172272 discloses authentication of a user identity, which use two separate communication channels, including a communications network and a mobile communication channel. US-A-2005/0268 107 discloses authentication of users via any one of two or three of 1) something the user knows; 2) something the user has; and 3) a physical characteristic of the user.

US-A-2006/0094401 discloses authentication in a wireless communication network. A secret is shared between a mobile and a home device. A remote device determines whether the mobile device can connect to the remote device by concurrently sending a challenge to the mobile and home devices and comparing the results.

A transaction authentication number, or TAN, is used by some online banking services as a form of single use passwords to authorize financial transactions. TANs are a second layer of security above and beyond the traditional single-password authentication.

An outline of how TANs function: 1. The bank creates a set of unique TANs for the user. Typically, there are 50 TANs printed on a list, each 8 characters long, which is enough to last haifa year for a normal user.

2. The user picks up the list from the nearest bank branch. The user must typically identify him/herself through presenting a passport, an ID card or similar document.

3. A few days later, the user receives a 5 digit password by mail to the user's home address. The user is requested to memorise the password, destroy the notice and keep the TAN list in a safe place near the PC.

4. To log on to his/her account, the user must enter user name and password. This may give access to account information but the ability to process transactions is disabled.

5. To perform a transaction, the user enters the request and "signs" the transaction by entering an unused TAN. The bank verifies the TAN submitted against the list of TANs they issued to the user. If it is a match, the transaction is processed.

If it is not a match, the transaction is rejected.

6. The TAN has now been consumed and will not be recognized for any further transactions.

7. If the TAN list is compromised, the user may cancel it by notifying the bank.

TANs are believed to provide additional security because they act as a form of two-factor authentication. If the physical document containing the TANs is stolen, it will be of little use without the password. On the other hand, if a hacker cracks the user's password, they can not process transactions without the TAN.

Summary of the Invention

The invention provides an authentication system for granting permission to a user having a user device to perform a transaction, the system comprising, means for storing a user identification code associated with said user; means for generating a plurality of functions for producing a pass code based on at least one input by a user, said at least one input comprising said user identification code; means for storing at least one function and associating said function with a user; means for generating an application adapted to implement said at least one function on the user device; means for supplying the application to said user device; means for generating a transaction code associated with said transaction and for supplying the transaction code to said application; and means for receiving a pass code for said transaction from the user device and for authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction. In an embodiment a unique OTP function is used per user, which results in an extremely secure authentication protocol. If a hacker is able to intercept and decrypt an O1'P function, it will only affect one user. Even if this were to happen, the user's account would still be secure as, without the user's identification code, the function would be useless.

In an embodiment the plurality of functions are symmetric or reversible functions such that at least one input can be derived from knowledge of the remaining inputs, the function and the output. At least two of said functions may be functionally unique. The at least two functions may be associated with different users.

The application may be adapted to implement more than one of said functions. The system may be adapted to send a control code to said application to select one of said functions. The user identification code and the transaction codes may be used as inputs to said function.

The transaction code may be used to select one of said functions to implement for said transaction.

The means for generating a plurality of functions may comprise a library of function components and means for selecting randomly from said function components to provide said composite function. The function components may comprise components selected from the group consisting of: mathematical functions, mathematical operations, string manipulation, date calculation, bit manipulation, computer logic commands, computer logic flows, computer logic conditions, embedded hard coded values, and data structure processing.

The means for generating a plurality of functions, comprises means for validating the functions. The means for validating the functions may perform a comparison with a predetermined selection of previously generated function and reject the generated function if a predetermined level of duplication is exceeded. In an embodiment each function in a batch of functions is unique.

The application adapted to implement said at least one function may provide a user interface.

The means for supplying the application to the user device may comprise a means for sending an electronic message to the user device, the message including an address from which the application can be downloaded.

The invention also provides an authentication method comprising, storing a user identification code associated with said user; generating a plurality of functions for producing a pass code based on at least one input by a user, said at least one input comprising said user identification code; storing at least one function and associating said function with a user; generating an application adapted to implement said at least one function on the user device; supplying the application to said user device; generating a transaction code associated with said transaction and supplying the transaction code to said application; and receiving a pass code for said transaction from the user device and authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction.

Traditionally two-factor authentication requires hardware tokens, which are expensive to distribute. In the present invention the second factor of the two-factor authentication process, the something you have' factor, is a software solution that produces a One Time Password (OTP). As the name suggests, an OTP is a password which is valid for one transaction, or combination of transactions that constitute a single set, the next transaction will require a different OTP.

The present invention can be implemented in any convenient form, for example using dedicated hardware, or a mixture of dedicated hardware and software. The present invention is particularly suited to implementation as computer software implemented by a server, workstation or laptop computer. The invention may further comprise a network, which can include any local area network or even wide area, conventional terrestrial or wireless communications network. The systems may comprise any suitably programmable apparatuses such as a general purpose computer, personal digital assistant, mobile telephone (such as a WAP or 3G-compliant phone) and so on. Aspects of the present invention encompass computer software implementable on a programmable device. The computer software can be provided to the programmable device using any conventional carrier medium. The carrier medium can comprise a transient carrier medium such as an electrical, optical, microwave, acoustic or radio frequency signal carrying the computer code. An example of such a transient medium is a TCP/IP signal carrying computer code over an IP network, such as the Internet.

The carrier medium can also comprise a storage medium for storing processor readable code such as a floppy disk, hard disk, CD ROM, magnetic tape device or solid state memory device.

The invention will now be described in more detail and by way of example only with reference to the accompanying drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS -Th

Figure 1 is a flow diagram representing the generation of an OTP; Figure 2 is a flow diagram representing a PIN determination step performed during a registration process; Figure 3 is a flow diagram representing registration process according to an embodiment of the invention; Figure 4 is a flow diagram representing a transaction process according to the present invention; Figure 5 is a box diagram of a system operative in accordance with an embodiment of the present invention; Figure 6 is box diagram showing elements of an OTP application generator according to an embodiment of the invention;

DESCRIPTION OF THE EMBODIMENTS

Figures 1 to 4 represent processes of an authentication method according to an embodiment of the invention.

As shown in figure 1, a one-time password (OTP) is generated by an OTP function on the basis of a PIN, which is an example of a secret key, and a transaction number, which is an example of a transaction specific code. The transaction number identifies the transaction in which the OTP will be used to authenticate the user. The transaction number is typically provided to the user or user device when a request is made by the user to access a particular service or an Internet site, for example.

In an embodiment the user device is a mobile telephone of the type having at least SMS capability. The user device is capable of running a computer program provided by the authentication system as described below. The computer program, called herein an OTP application, may be provided to the user device in any suitable manner. The OTP application may be pre-installed on the user device before purchase of the device, or alternatively may be provided to the user device on request. A convenient method may be to download the OTP application from a secure location on the communication system controlled by the authentication server.

In the case where the 01? application is pre-installed on a user device, the OTP application may need to be registered at the authentication server. Registration can conveniently be performed by using a registration security code provided with the user device when purchased. The security code may be supplied to the authentication server, together with user identification details in order to associate the OTP application (and therefore the OTP function or functions) with the new user.

The user device may be any communication device, which may have a single communication channel, but modem devices tend to have two or more communication channels. Allowing plural communication channels on the same device. Plural communication channels may be provided also by using a different device for transferring some information for the authentication process. It is likely that that embodiments of the invention will be implemented using a Java application capable of running on mobile telephone handsets. However, it is possible for it to be used on virtually any computer based platform, i.e. PDA's, set top boxes, etc. Embodiments of the present invention use a hardware device that the vast majority of Internet users already possess -a mobile phone. This not only greatly decreases implementation costs, but also improves the user experience by allowing them to use a device that they are familiar with. However, the user device can include any communication device that is able to run a suitable OTP application program and receive the necessary transaction code from the authentication system.

In the present embodiment the user is assigned or chooses a user identification code, which is an example of a secret key. Typically, the user identification code is a Personal Identification Number (PIN), for example a four-digit number. To improve security the PIN is defined by the user during registration and can be any length. Furthermore, whilst for ease the PIN is an actual number, any pass code including alphanumeric sequences could be used as is well known in the art. The authentication process may use more than one secret key either as part of a separate, additional authentication step, or as further inputs to the OTP function. The secret keys are communicated to the authentication server during a registration process. If there is more than one secret key then these may be communicated to the authentication server at different times and through different channels. For example, in the case where the OTP application is installed on a new user device such as a mobile telephone, user information can be communicated to the authentication server from, for example, a terminal at the shop at which the telephone was purchased. A PIN or other user identification code might then be selected by the user during a subsequent registration process.

In an embodiment of a registration process of the present invention, the authentication server receives an OTP from the user device and performs the inverse of the OTP function to determine the PIN chosen by the user (Figure 2). The PiN is then stored, together with any other user information, and is specifically associated with that user. It is desirable that the user information is store securely, for example on a secure server, which may be the authentication server.

In the present embodiment a transaction code or transaction number is generated for each transaction. The transaction number of the present embodiment is a random or pseudo random number generated on the server. Known random number generators are capable of generating numbers with sufficient randomness that it is virtually impossible to predict the next number that will be produced. The transaction numbers are, therefore, cryptographically secure. The random number generator may be implemented in hardware. A hardware random number generator is an apparatus that generates random numbers from a physical process. Such devices are typically based on microscopic phenomena such as thermal noise or the photoelectric effect or other quantum phenomena. A quantum-based hardware random number generator typically contains an amplifier to bring the output of the physical process into the macroscopic realm, and a transducer to convert the output into a digital signal.

The PIN and transaction number are the inputs to an OTP function (see Figure 1). The OTP function is a randomly generated composite function, which comprises, in an embodiment, a number of partial functions, such as mathematical functions. The output of the OTP function is a unique OTP for each transaction using the PIN and transaction number as two inputs to the OT? application, as discussed below. Two inputs are the minimum inputs to the OTP application, there may be further inputs including further user information, for example, a date, an employee or account number, or other item of user identification information. Furthermore, in alternative embodiments further codes may be supplied to the 01? function by the authentication system. Whilst only a single transaction code is necessary, further codes may be supplied to change the behaviour of the OTP function as discussed below.

During registration (Figure 3), the inverse of the OTP function associated with the user is used in order to determine the PIN a user has chosen based on a transaction number and an OTP. Whilst in the prior art, security of password generation is provided by encryption and the use of one-way hash functions, the present embodiment uses instead a reversible or symmetrical function, which makes authentication less computationally intensive. Security is provided by the provision of unique OTP functions for each user.

Embodiments of the invention allow for a new OTP function for every transaction.

Encryption can of course be used to improve security as is well known in the art.

Generally, each user is assigned a unique 01? function, whereby even if a hacker were to intercept and decrypt an OTP function, it would only affect one user. The security can be further increased by generating a unique OTP function for each transaction or group of transactions. Where the balance between security and processing power requires it, OTP functions could be assigned to more than one user or user device. It is a feature of the present invention that unique functions are derived for delivery to user devices. The system of the present invention makes it possible to calculate a vast number of unique symmetrical functions, which are tested for their validity and uniqueness. In theory, every single function used in the system could be different. Of course, depending on the security level required there might be an acceptable amount of re-use of functions. For example, if the number of users is very large the risk of re-using functions does not affect the level of security unacceptably. Furthermore, if a function has not been used for a long time, especially if it is not presently in use in the system, that is it is not already assigned to a user, then such a function need not be rejected by the system and may be embedded in an OTP application for provision to a user.

The unique OTP functions may be created in a batch process by a function generator' module provided by the authentication server. In the present embodiment, the function generator creates an OTP function, an inverse of the function, and a computer program (OTP Application), which provides the function with a user interface for entering a PIN and displaying the OTP. The displayed OTP may then be used in a registration or transaction process, possibly using a different device or in a person to person transaction at a bank. Alternatively, the OTP can be provided directly from the client device to the communication system for authentication by the authentication server. The number of OTP functions created in each batch process can be chosen by the client (where the authentication system is being provided as a service to a third party), or set to automatically adjust based on recent transaction levels. If the system runs out of available OTP functions during the day, it is able to generate them on an ad-hoc basis.

The nature of the OTP application will depend on the platform for which the solution is being implemented. For a mobile telephone based implementation, for example, the computer program could be in the form of a Java application suitable for use on any modern mobile handset. For user devices that are not Java compliant other suitable programming languages could be used.

Registration process The purpose of the registration process is to supply the user with their unique OTP application and to obtain from them their chosen PIN. In an embodiment, the registration process includes the following steps: * User contacts the communication network or a client server to initiate a transaction * The user is asked to register for the authentication process in order to proceed with the transaction * User is supplied with an OTP application containing an OTP function, * a transaction number is supplied to the OTP application by the authentication system * User chooses PIN arid enters it into OTP application.

* OTP application uses the PIN and transaction number as inputs to the OTP function to generate an OTP, which can be supplied to the user or directly to the authentication system.

* OTP is supplied to the authentication system.

* The authentication system uses the inverse of the OTP function associated with the user to establish the user's PIN using the transaction number and the OTP supplied by the user * Server securely stores the user's PIN. Note that this is the only place in which the PiN is stored-it is not stored by the OTP application and is not resident in the user device memory once the OTP function has been run to produce the OTP function.

The OTP application may be supplied to the authentication system via a separate communication channel to the one used to send the OTP application and number. For example, in a mobile phone based implementation, the OTP application may be obtained from a Internet website or a WAP site and the transaction number may be sent to the user via SMS. In an embodiment the user would submit the OTP via the Internet (possibly using a different device such as a PC). The use of separate communication channels is extremely secure as it virtually impossible for both to be compromised at once.

The use of multiple communication channels enhances security yet further, as it is virtually impossible for a hacker to compromise more than one simultaneously. Even if one element of the process can be intercepted or decrypted or otherwise obtained by a hacker, without all of the elements the system has not been compromised. For example, a hacker that obtains access to the one-time password application, for example by obtaining a mobile device on which the application is stored, cannot use the application without the user identification code.

Transaction process The purpose of the transaction process is to establish the authenticity of a user by ensuring that they know the PN associated with their account and thereby authenticate the user for that transaction. In an embodiment a basic transaction process may include the following steps (see figure 4): * The OTP application is supplied with a transaction code in response to a transaction initiation step, for example a user attempt to buy a product or service on-line from a client web-site * OW application requests user to enter a secret key such as a PIN * User enters PIN into OTP application.

* OTP application uses PIN and transaction code to generate an OTP, which can be supplied to the user or directly to an element of a communication network such as an authentication server or client web-site.

* OTP is supplied to authentication server. Whether or not this is sent by the same communication channel as the one used to send the transaction number to the user will be configurable per implementation, depending on the level of security required. For example, in a mobile phone based implementation, both the transaction number and OTP may be communicated via SMS. Alternatively, the user may be required to submit the OTP via the Internet, possibly on a separate device.

* Authentication server uses the OTP function associated with this user to generate an OTP using the PIN stored at registration and the transaction number sent to the user device in respect of this transaction. Alternatively, the server uses the reverse OTP function, the received OTP and the transaction number and compares PINs, or alternatively the authentication is achieved using the stored PIN and the received OTP in the reverse OTP function and compares the resultant transaction number with the transaction number associated with that transaction.

* Server compares this OTP with the one supplied with the user and, if they match, allows the transaction to complete.

In the event that the authentication server cannot authenticate the user, because the OTP is incorrect, the server will prompt an error message and a new transaction code is sent to the application so that a further attempt can be made at authentication. However, other mechanisms for dealing with authentication failure are known and the particular process chosen will depend on the circumstances, including the type of transaction, the implementation platform and other factors. Systems may also be provided in the event that the user forgets his PIN or loses his user device on which the OTP application is resident.

The OTP application may include routines for performing other tasks, in particular, once the OTP function script has been implemented the OTP application may purge the memory of all traces of the transaction code or codes, the user identification code and any other secret keys.

Authentication System Figure 5 is a block diagram showing the functional elements of the authentication system according to an embodiment of the present invention. The figure shows schematically only those elements required for an understanding of the invention and is not intended to be limiting.

Referring now to figure 5, a user device 1, in this case a WAP enabled mobile communication device such as a mobile telephone, is connected by a network connection to a client site 2. The client site is typically a web site that requires secure access because, for example it's content is supported by subscriptions, or the site is used for payment transactions for the purposes of goods or services. The client site may also belong to a bank or other financial institution where security and user authentication is particularly important. The client site may be a single web page or more usually a series of linked pages that may be hosted on a single server or a plurality of unrelated servers connected by the Internet. The dashed line 3 represents the network connection. The connection in this embodiment is by the Internet but the connection could be by any similar network or even a peer-to-peer connection.

For example, a banking web site may require the use of the OTP in the event that the amount of the transaction is higher than 500.

The client Site 2 uses an authentication server 4 in order to authenticate users of the client site 2 before allowing access to the site or before allowing certain transactions to occur, such as purchasing goods or services. The client site 2 requests, as part of the security process, an OTP from the user, that is a pass word or pass code that is unique to that transaction. The term transaction' is not intended to be limited to a financial transaction, but to any permission, for any purpose between two parties where the second party wishes to authenticate the identity of the first party before granting the permission.

It is to be noted that the OTP may be merely part of a security process, which may include several steps and include various challenges to the user. In particular it would be common for the user of a commercial web-site to enter a user name and a password -a permanent static password -in order to logon to a website. The request for an OTP for a particular transaction may be simply an additional security step for individual transactions held between the user and the client site 2.

In figure 5 the authentication server 4 is shown as a single entity, but it is not intended to imply that all of the elements of the authentication system need be in the same location, or resident on the same computer, and distributed solutions are envisaged. For simplicity the authentication system is shown schematically as being on a single authentication server 4 in figure 5.

In most cases it will be necessary for the user to register the user device I with the authentication server 4 before the authentication process can proceed. In the case of a registered user, the authentication system 4 will have user identification information stored in a memory 5. The user identification information may include the usual details such as name and address and may include the static password used to log onto the client site. More particularly, the authentication system has access to one or more private keys known to the user of the user device 1. The private key or keys are used in the production of OTPs on the client device 1 as discussed above.

The authentication system includes a transaction code generator 6 and a transaction code distributor 7. When a transaction of the type requiring a transaction code is initiated, a controller or CPU 8 on receipt of a request from the client site 2, instructs the transaction code generator to provide a transaction code to the distributor to be provided to the user device. The transaction code may be provided to the user device by an SMS message or by any convenient communication channel. In general, the transaction code will be provided directly to the OTP application and will not be presented to the user. At least in the registration process (and in other transactions where a new application is issued to the user) the transaction code may be provided to the application before the application is provided to the user. However, where greater security is required the transaction codes and OTP application are supplied by different communication channels. Ion the present embodiment, the transaction code is provided by ands SMS message and the OTP application by a WAP push as described below.

In the present embodiment the 01? is provided to the user device by a WAP Push, which is effectively a simple SMS within the header of which is included a link to a WAP address. On receiving a WAP Push, the user device I will automatically give the user the option to access the OTP site 9. In this way the WAP Push directs the end user to a WAP address where the OTP application for that user is stored for downloading to the handset. The use of SMS messaging is not intended to be limited to such messaging on GSM networks but includes all similar communication channels including 30 networks and alternatives such as SkyMail (RTM) and NIT Docomo' s Short Mail. E-mail messaging from mobile telephones, such as NIT Docomo's i-mode and the RIM BlackBerry (RTM), also use typicall standard mail protocols such as SMTP over TCP/]P. The present invention can be implemented with whatever communication channels are available in the chosen system.

The OTP application contains one or more OTP scripts. The OTP scripts are compiled codes derived from an OTP function for implementing an OTP function on the user device 1. The OTP functions are generated by an OTP function generator 10, which will be described in more detail below. The function or functions for a particular OTP application are stored in memory 5 and associated with the user of user device 1. For any particular transaction, therefore, the transaction code, the secret keys and the OTP function are accessible to the controller 8 from memory 5. The authentication of the transaction can be made as discussed above by comparison of the OTP provided by the user device I to the client site 2 with the OTP produced by the controller 8 on the basis of the information associated with that transaction. Authentication can then be communicated to the client site 2.

The OTP application generator 11 embeds an OTP script for implementing an OTP function in an OTP application, which is supplied to the user device by the OTP application distributor 12 as discussed above. The OTP function and application are discussed in more detail below.

The OTP Function Referring now to Figure 6, which shows functional elements of the OTP application engine, including the function generator 10 and the application generator 11.

The function generator includes a pre-definition module 13, a function composition module 14 and an evaluation! validation module 15.

In the present embodiment the OTP functions are composite functions. The OTP function is an algorithm consisting of a random selection of predefined functions such as mathematical functions combined using a random selection of mathematical operators.

For example, the an OTP function may include the functions f(x) = J(x), and g(x) = x2- 5x. The operators may include addition, subtraction, multiplication, division and their domains. In order that there are sufficient possibilities for unique functions there are preferably a large number of possible functions that can be selected. However, the number of unique OTP functions is not limited because the number of arguments, that is the length of function string is not fixed.

The OTP functions may differ not only in the number of arguments but also in the number of results, different families of functions and the range of inputs and outputs.

OTP functions can include some or all of the following: a) mathematical functions and operations b) string manipulation c) date calculation d) bit manipulation (shifting, rotation, etc.) e) computer logic commands, flows, and conditions (loop, IF statements, etc.) f) embedded hard coded values; and g) data structure processing.

Other possibilities will suggest themselves to those skilled in the art.

The pre-function definition process, therefore, results in a library of function components including all of some of the above possibilities. The function composition module 14 randomly selects from the library of function components to generate a series of composite functions. Each of the composite functions is then tested by the Evaluation/Validation module 15 to ensure that the function meets various requirements. For example, the evaluation/validation module 15 may determine that the new composite function is, within certain parameters, unique, of sufficient complexity to give the desired degree of security, and whether two different functions produce the same OTP given the same inputs. Furthermore, the value or values produced by the function must be valid. The validation module ensures that each function is reversible, i.e. that it is a symmetric function.

In an embodiment of the invention the validation module ensures that each function is unique and is not presently in use in any OTP application. That is the validation module has access to all functions presently associated with all users in the system and compares the randomly generated composite function with the database of all functions.

Alternatively, the validation module 15 may ensure that the function is truly unique, by comparing the function with all functions ever issued by the application generator 11.

Where the security demands would be satisfied by less stringent demands, the validation module could be set to allow a predetermined level of reuse of OTP functions. In other embodiments the validation module may simply ensure that each batch of composite functions is unique, where the application generator II generates OTP applications for different clients (where it is not a proprietary system) the OTP application might simply ensure that each batch of OTP functions contains unique functions. The random generation of functions ensures that knowledge of one set of functions does not assist in determining another batch of functions.

A library of validated functions is then stored in database 16. When a new OTP application is to be generated by the application generator 11, a function selection module 17 selects, e.g. randomly, a function from the library of functions stored in database 16. The OTP application builder 18 receives the composite function, which is the 01? function to be embedded in the OTP application and which is associated with the user to which the OTP application will be provided. The application builder 18 will then parse the composite function and build a program script for compiling by an application compiler. The application compiler takes a basic application and embeds the OTP function script into the basic program to form the OTP application. The compiled OTP application is stored in memory 19 for subsequent provision to the application distributor 12.

In the above-described embodiment, a single OTP function is embedded in the OTP application and provided to the user device. In an alternative embodiment an OTP application provided to the user device has a plurality of different OTP functions, there is no limit on the number of functions that might be embedded in the OTP application, except in that the memory and processing power of the user device might put a practical or commercial limit on the number of OTP functions. In this case, the transaction code sent to the user device may be a code that is used by the OTP application to select one of the embedded OTP functions to be the OTP function for that transaction. In this case, there may be only one input to the OTP function, the user identification code. Of course, the OTP functions may accept further secret keys from the user. Furthermore, whilst the transaction code may be used to select the OTP function this is not the only possibility. The transaction code may be used as an input to the OTP function as in the case of the embodiment where there is a single OTP function and a separate code may be provided by the authentication server for selecting one of the OTP functions.

Thus, in the present invention, not only is it possible to have a unique OTP function for each user device or each user, but it is also possible to change the OTP fimction periodically, including selecting a new OTP function for each transaction, without installing a new OTP application. Even in the case where there is a single OTP function embedded in the OTP application the behaviour of the OTP function can be changed (for example, for reach transaction) by control codes sent by the server as inputs to the OTP function.

In the embodiment shown in Figure 5, the user is interacting with the client website via the same device which has the OTP application. With modem telecoms equipment it is possible that two or more channels of communication are provided by the same equipment. However, it is envisaged that the present invention could be used to separate the channels of communication, so that a mobile telephone for example is the user device having the OTP function but that the transaction is being performed either in person (at a bank for instance) or on a separate machine (e.g. a PC or shop terminal).

The person attempting the transaction must be in possession of the telephone in order to be able to obtain the required OTP. Whilst an unauthorised person may be able to get hold of a mobile telephone or alternatively gain access to the users PC, it is unlikely that they can gain access to the PC and to the mobile telephone and to the users PIN.

The OTP application is therefore a soft token equivalent to a hard token normally required for secure two-factor authentication. However, the same OTP application can be used to support different secure keys, e.g. two people can share a mobile phone and to authenticate themselves using different PIN numbers.

In an embodiment there is envisaged a joint account system, where multiple users each have 01? applications. In order to authorise or authenticate the transaction all of the users linked to this account need to supply their correct OTP.

The process can be used by people as well as machines, e.g. two servers can use the solution to authenticate a B2B transaction.

For less restricted security level policies we can, for example, decide to have a "Cool off period" in which the user has to send the OTP number back to the server via a different channel. For example via a separate device to the one supporting the 01? application. The cool off period can be calculated based on a time limit or the amount of the transaction.

The solution is flexible enough to support different type of security level, for example, a bank can decide to allow the OTP generated by the OTP application to be sent back to the authentication server, only via the web site for eBanking, that is the OTP application is for example on a mobile telephone and the transaction code is received via SMS. The OTP is returned by a different communication channel, that is, the Internet.

As previously stated, the present invention might be only part of a security system and might only fonn a part of the authentication process for any particular transaction. The invention can be used with other security features without any limitation. For example, the user device may be part of the GPRS system or other system providing an indication of the user device location. The authentication process may therefore include a check on the location of the user device.

It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

Whilst embodiments of the invention have been described by way of example only, modifications and equivalents will suggest themselves to those skilled in the art, without departing from the scope of the invention as defined by appended claims.

Claims

CLAIMS: I. An authentication system for granting pennission to a user

having a user device to perform a transaction, the system comprising: means for storing a user identification code associated with said user; means for generating a plurality of functions for producing a pass code based on at least one input by a user, said at least one input comprising said user identification code; means for storing at least one function and associating said function with a user; means for generating an application adapted to implement said at least one function on the user device; means for supplying the application to said user device; means for generating a transaction code associated with said transaction and for supplying the transaction code to said application; and means for receiving a pass code for said transaction from the user device and for authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction.

2. A system as claimed in claim 1, wherein said functions are symmetric functions such that at least one input can be derived from knowledge of the remainin inputs, the function and the output.

3. A system as claimed in claim I or 2, wherein at least two of said functions are functionally unique.

4. A system as claimed in claim 3, wherein said at least two functions are associated with different users.

5. A system as claimed in any one previous claims wherein said application is adapted to implement more than one of said functions 6. A system as claimed in claim 5, wherein the system is adapted to send a control code to said application to select one of said functions.

7. A system as claimed in claim 5, wherein said transaction code is used to select one of said functions to implement for said transaction.

8. A system as claimed in any one of claims I to 6, wherein the user identification code and said transaction codes are used as inputs to said function.

9. A system as claimed in any one previous claim wherein said means for generating a plurality of functions, comprises a library of function components and means for selecting randomly from said function components to provide said composite function.

10. A system as claimed in claim 9, wherein the function components comprise components selected from the group consisting of: mathematical functions, mathematical operations, string manipulation, date calculation, bit manipulation, computer logic commands, computer logic flows, computer logic conditions, embedded hard coded values, and data structure processing.

11. A system as claimed in any one preceding claim, wherein said means for generating a plurality of functions, comprises means for validating the functions.

12. A system as claimed in claim 11, wherein said means for validating the functions performs a comparison with a predetermined selection of previously generated function and rejects the generated function if a predetermined level of duplication is exceeded.

13. A system as claimed in claim 12, wherein each function in a batch of functions is unique.

14. A system as claimed in any one preceding claim, wherein the application adapted to implement said at least one function provides a user interface.

15. A system as claimed in any one preceding claim, wherein the means for supplying the application to the user device comprises means for sending an electronic message to the user device, the message including an address from which the application can be downloaded.

16. An authentication method comprising: storing a user identification code associated with said user; generating a plurality of functions for producing a pass code based on at least one input by a user, said at least one input comprising said user identification code; storing atleast one function and associating said function with a user; generating an application adapted to implement said at least one function on the user device; supplying the application to said user device; generating a transaction code associated with said transaction and supplying the transaction code to said application; and receiving a pass code for said transaction from the user device and authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction.

17. A method as claimed in claim 16, wherein said functions are symmetric functions such that at least one input can be derived from knowledge of the remaining inputs, the function and the output.

18. A method as claimed in claim 16 or 17, wherein at least two of said functions are functionally unique.

19. A method as claimed in claim 18, wherein said at least two functions are associated with different users.

20. A method as claimed in any one of claims 16 to 19, wherein said application is adapted to implement more than one of said functions.

21. A method as claimed in claim 20, comprising sending a control code to said application to select one of said functions.

22. A method as claimed in claim 20, wherein said transaction code is used to select one of said functions to implement for said transaction.

23. A method as claimed in any one of claims 16 to 21, wherein the user identification code and said transaction codes are used as inputs to said function.

24. A method as claimed in any one of claims 16 to 23, wherein said means for generating a plurality of functions, comprises a library of function components and means for selecting randomly from said function components to provide said composite function.

25. A method as claimed in claim 24, wherein the function components comprise components selected from the group consisting of: mathematical functions, mathematical operations, string manipulation, date calculation, bit manipulation, computer logic commands, computer logic flows, computer logic conditions, embedded hard coded values, and data structure processing.

26. A method as claimed in any one of claims 16 to 25, comprising validating said plurality of functions.

27. A method as claimed in claim 26, wherein said means for validating the functions performs a comparison with a predetermined selection of previously generated function and rejects the generated function if a predetermined level of duplication is exceeded.

28. A method as claimed in claim 27, wherein each function in a batch of functions is unique.

29. A method as claimed in any one preceding claim, wherein the application adapted to implement said at least one function provides a user interface.

30. A method as claimed in any one preceding claim, wherein supplying the application to the user device comprises sending an electronic message to the user device, the message including an address from which the application can be downloaded.

31. An authentication server comprising: a memory for storing a user identification code associated with said user; a function generator for generating a plurality of functions, the functions adapted to produce a pass code based on at least one input by a user, said at least one input comprising said user identification code; a memory for storing at least one function and associating said function with a user; an application generator for generating an application adapted to implement said at least one function on the user device; an application distributor for distributing the application to said user device; a transaction code generator for generating a transaction code associated with said transaction; a transaction code distributor for supplying the transaction code to said application; and a controller for receiving a pass code for said transaction from a user device and for authenticating the transaction on the basis of the received pass code, the function associated with said user, the user identification code and the transaction code associated with said transaction.

32. A carrier medium carrying computer readable code for controlling a computer to carry out the method of any one of Claims 16-30.