AU2012244214B2

AU2012244214B2 - Remote device authentication system and method

Info

Publication number: AU2012244214B2
Application number: AU2012244214A
Authority: AU
Inventors: Ben VANCE; Steve Willoughby
Original assignee: Commonwealth Bank of Australia
Current assignee: Commonwealth Bank of Australia
Priority date: 2011-10-25
Filing date: 2012-10-25
Publication date: 2016-05-12
Anticipated expiration: 2032-10-25
Also published as: WO2013059866A1; AU2012244214A1

Abstract

A client-side registration module for registering a client device with a server is provided. The client-side registration module includes computer readable instructions executable by a computer processor of the client device to generate a registration request including user 5 credentials provided by a user of the client device, and transmit the registration request to the server using a communications interface of the client device. If registration by the server is successful, a server rolling key input is received from the server, and an initial rolling key is generated using at least said server rolling key input. The initial rolling key is saved to a memory of the client device and transmitted back to the server using the communications interface. 100 -108 - 104 Client Interface Database Application Database server server ---------------------------- Figure 1 204 206 208 210 Processing Volatile Non-volatile Display unit memory memory device(s) Input Device Audio Communications device(s) interface(s) device(s) interface(s) 212 214 216 218 Figure 2

Description

P100/01 1 Regulation 3.2 AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Invention Title: Remote device authentication system and method The following statement is a full description of this invention, including the best method of performing it known to us: 2 Remote device authentication system and method Field of the invention The present invention relates to systems and methods for authenticating a remote device. Background of the invention 5 As telecommunications and computing technologies advance, so to does the demand for remote access to data and services. Such remote access is often achieved using a client-server type framework in which a client device (operated by an end user) sends a request over a communications network to a server, and in response the server undertakes some action and/or sends data back to the client. 10 Given the data relating to client-server communications is typically transmitted over public networks, security is often a significant issue. One security concern is that the party or parties to the communications are properly identified and authenticated, and that information/services are provided to the intended party. By way of example, a smart phone user (the client) may wish to access details of their bank account from their bank (the server) and/or 15 perform a financial transaction remotely. The communications network used for such a request/transaction may (again by way of example) be a wireless cellular network, the Internet (which may, of course, be wired or wireless), or a combination of both. In such communications it is imperative that the end-points of the communications (i.e. the client and server) are properly authenticated. At the server side, the bank needs to be sure that the client requesting the 20 information/transaction is who they say they are. On the other hand, the client needs to know that any sensitive information being sent as part of their request is being communicated to their bank and not a third party pretending to be the bank. A wide variety of security protocols for remote authentication exist. There is, however, a constant battle between those seeking to provide secure authentication measures, and those 25 seeking ways to compromise such measures. For example, and with particular reference to smart phone devices, pdf attacks, the prevalence of 'jail broken' operating systems, malicious device cloning, targeted social attacks, application compromises (particularly in open application market models, e.g. Google's Android OS), can leave users devices compromised, controlled by malicious users and therefore make secure authentication difficult. Typical implementation will 3 use either a static secret such as a password the user enters or a static key such as a private key corresponding to a respective public key, such items are easily cloned. It would be desirable to provide an authentication system or method that provides for secure identification of a device without requiring user input. In addition, or in the alternative, it 5 would be desirable to provide a useful alternative to existing authentication systems and methods. Reference to any prior art in the specification is not, and should not be taken as, an acknowledgment or any form of suggestion that this prior art forms part of the common general knowledge in Australia or any other jurisdiction or that this prior art could reasonably be 10 expected to be ascertained, understood and regarded as relevant by a person skilled in the art. Summary of the invention Aspects of the invention provide systems and methods for the automatic authentication of a user device by a server. In one aspect the present invention provides a client-side registration module for 15 registering a client device with a server, the client-side registration module including computer readable instructions executable by a computer processor of the client device to: generate a registration request including user credentials provided by a user of the client device; transmit the registration request to the server using a communications interface of the client device; if registration by the server is successful, receive via the communications interface a server rolling 20 key input from the server; generate an initial rolling key using at least said server rolling key input; save said initial rolling key to a memory of the client device; and transmit said initial rolling key back to the server using the communications interface. The initial rolling key may be generated using both said server rolling key input and a device rolling key input generated by the client registration module. 25 The initial rolling key may be encrypted by the client-side registration module prior to being transmitted to the server.

4 The client-side registration module may further include instructions executable by the computer processor of the client device to receive a device identifier from the server and save said device identifier to the memory of the client device. The device identifier may be received from the server in an encrypted user/device 5 identifier, the encrypted user/device identifier encrypting both the device identifier and a user identifier. In a second aspect the present invention provides a server-side registration module for registering a client device with a server, the server-side registration module including computer readable instructions executable by a computer processor of the server to: receive, via a server 10 communications interface, a registration request from the client device, the registration request including user credentials; authenticate the user credentials by reference to credentials for the user stored on a server accessible memory; wherein if authentication of the user credentials is successful: generate a server rolling key input; transmit said server rolling key input to the client device; receive a rolling key; save the rolling key to the server memory. 15 The rolling key may be encrypted, and the server-side registration module may decrypt the rolling key before saving the rolling key to the sever memory. The server-side registration module may further include computer readable instructions executable by the computer processor of the server to: generate a device identifier for the client device from which the registration request was received; save said device identifier to the server 20 memory; and transmit said device identifier to the client device. The device identifier may be encrypted together with a user identifier to generate a user/device identifier; saving the device identifier to memory may involve saving the user/device identifier to memory; and transmitting the device identifier to the client device may involve transmitting the user/device identifier to the client device. 25 In a further aspect the present invention provides a client-side automatic authentication module including instructions executable by a computer processor of a client device to: generate an authorisation code based on a current rolling key stored on a memory of the device and an authorisation code input; transmit an authorisation request to a server, the authorisation request including the authorisation code, the authorisation code input, and a device identifier; if 5 authentication by the server is successful, receive a rolling key input from the server; generate a new rolling key using said rolling key input; and save said new rolling key to the memory of the device as a new current rolling key, the new current rolling key usable in subsequent authentication procedures. 5 The device identifier may be included in a user/device identifier which includes both a user identifier and the device identifier. The authorisation code input may be derived from date/time information. In a further aspect the present invention provides a server-side automatic authentication module including instructions executable by a computer processor of a server to: receive an 10 authorisation request from a client device, the authorisation request including an authorisation code, an authorisation code input, and a device identifier in respect of the client device; retrieve from a server accessible memory a current rolling key associated with the device identifier; verify the authorisation code using the authorisation code input and current rolling key; wherein if verification of the authorisation code using the current rolling key is successful: generate a 15 new rolling key input; generate a new current rolling key using the new rolling key input and the current rolling key; save the current rolling key to the server accessible memory as a previous rolling key associated with the device identifier; save the new current rolling key to the server accessible memory as the current rolling key associated with the device identifier; and transmit the new rolling key input to the client device. 20 If verification of the authorisation code using the current rolling key is not successful, the module may further include instructions executable by the computer processor of the server to: retrieve from the server accessible memory a previous rolling key associated with the device identifier; verify the authorisation code using the authorisation code input and previous rolling key; wherein if verification of the authorisation code using the previous rolling key is successful: 25 generate a new rolling key input; generate a new current rolling key using the new rolling key input and the previous rolling key; save the new current rolling key to the server accessible memory as the current rolling key associated with the device identifier; and transmit the new rolling key input to the client device. In a further aspect the present invention provides a user device including a client-side 30 registration module and/or a client-side automatic authentication module as outlined above.

6 In a further aspect the present invention provides a server including a server-side registration module and/or a server-side automatic authentication module as outlined above. Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way 5 of example and with reference to the accompanying drawings. Brief description of the drawings Figure I is a diagram of a system in which embodiments of the invention may be implemented. Figure 2 is a block diagram of a computer device within which a set instructions, for 10 causing the machine to perform any one or more of the methodologies discussed herein, may be executed. Figure 3 provides an overview of communications that occur between client application and server during a registration process in accordance an embodiment of the present invention. Figure 4A is a flow chart depicting client operations relevant to the registration process 15 depicted in Figure 3. Figure 4B is a flow chart depicting server operations relevant to the registration process depicted in Figure 3. Figure 5 provides an overview of communications that occur between client application and server during an authentication process in accordance an embodiment of the present 20 invention. Figure 6A is a flow chart depicting client operations relevant to the registration process depicted in Figure 5. Figure 6B is a flow chart depicting server operations relevant to the registration process depicted in Figure 5. 25 Figure 7 depicts an end user device displaying updated account balance information in accordance with an embodiment of the invention.

7 Detailed description of the embodiments The present invention generally relates to methods and systems for authenticating a remote computing device during a communication session between the remote computing device and a server. Embodiments of the invention are of particular use in applications where, over 5 time, a number of discrete communication sessions with the server are initiated (either at the explicit request of the user or automatically by the application itself), with each communication session requiring the user device to be authenticated by the server. In such applications a secure authentication process which does not involve direct user input can be advantageous. By way of one example, the application in question may be a banking application. One 10 specific function provided by the banking application is to periodically request certain bank account details from a bank server (e.g. balance information), and display the updated account details on the user device. While such information is sensitive, and therefore needs to be protected, the point of an automatic update is that it is automatic - i.e. does not require the user to input a username or password. Under embodiments of the present invention, when such a 15 function is enabled, the application automatically authenticates the device when sending the request for updated information without requiring user input. A depiction of such an application is provided in Figure 7, showing a user device 108 (such as a smart phone) with a display 210 on which a balance 704 for a user account 706 is shown. When active, an application running on the device 108 automatically makes requests to a server to authenticate itself and, on successful 20 authentication by the server, obtain and display up-to-date balance information. Alternative functions offered by such a banking application may be of higher security importance. For example, functions allowing for financial transactions such as the transfer of money between bank accounts or bill payment. For such user-initiated operations, and in addition to the automatic device authentication mentioned above, the server may require the user 25 to actively submit further identification/verification information (e.g. a password or similar). For the purposes of illustration the invention will be described in the context of such a banking application. System architecture Figure 1 is a network diagram depicting various components that form part of a client 30 server system 100. The client server system 100 includes a server system 102 which, in the 8 context of the banking application referred to above, would be the (or part of) the bank's computing environment. The server 102 provides server-side functionality to one or more clients, such as client 104, via one or more communications networks 106. Communications network 106 may include a variety of different networks (of the same or 5 different types) having wired and/or wireless communications links or channels, with communications governed by a variety of communication protocols. By way of non-limiting example, such networks may include the Internet, local area networks, wide area networks, cellular voice/data networks. Relevantly, however, communications network 106 allows for communication of data between two endpoints (e.g. client 104 and server 102) regardless of the 10 number of individual networks, and/or the various different types of networks, included in network 106 and interoperating to provide for this communication. Client 104 will typically be a software client being executed by an end user computing device 108. A variety of clients capable of interacting with the workflow system 102 are possible. These may include, for example, web clients such as the Internet Explorer, Firefox, 15 Mozilla, Safari, and Chrome web browser applications. Clients may also include programmatic clients. Programmatic clients are developed specifically for interaction with the server 102 and may include, for example, programmatic clients developed for specific computing devices and/or operating systems (e.g. Microsoft Windows clients, Apple OS clients, Apple iOS clients, HTML 5.0 applications, Flash etc). Programmatic clients may be stand alone applications, or be 20 provided as part of larger applications (e.g. accounting applications, email applications etc) which allow the larger application to interact directly with the server system 102. The end user computing device 108 itself, on which the client 104 runs, may be any device with appropriate computer processing and communications components (such as some or all of those discussed below in relation to the generic computing device of Figure 2). By way of 25 example, the end user computing device may be a mobile telephone (or smart phone), a tablet type computing device, a laptop type computing device, a netbook type computing device, a desktop type computing device, a PDA type computing device. Server 102 will also be a computing device such as (for example) that described below in relation to Figure 2. At a logical/functional block level, the server 102 includes at least one 30 interface 110 which may, for example, include web servers and/or an Application Program 9 Interface (API) servers. Interface(s) I10 provide web and/or programmatic access to one or more application servers 112 which, in this case, include a security application server which will be discussed in further detail below. The application server(s) 112 are, in turn, coupled to one or more databases servers 114 that facilitate access to one or more databases 116. 5 Computing system/device Figure 2 provides a block diagram of one example of a computing system 200. Computer system 200 includes a variety of components which communicate with each other using a communications bus 202. The components of the illustrated computing system 200 include: a processing unit 204, 10 which may include one or more general microprocessor (or other computational) devices, together (in some instances) with one or more processors dedicated to a specific task (for example a graphics processing unit); one or more memory units, which in this case include a volatile main memory 206 (e.g. random access memory including one or more DRAM modules) and a non-volatile memory 208 (e.g. one or more hard disk drives, solid state disk drives, and/or 15 ROM devices such as one or more EPROMs); one or more display units 210 which could, for example, a LCD, LED, CRT, or other type of display; one or more input devices 212, such as a touch screen, a keyboard, a pointing device (e.g. mouse, trackball); one or more device interfaces 214 allowing connection, for example, to further devices such as HDDs, SSDs, CD drives, DVD drives, Blu-ray drives, flash memory devices; an audio output device 216 such as a speaker; and 20 at least one communications interface 218, allowing for wired and/or wireless transmission of data to (and receipt of data from) one or more types of networks as discussed above. In one embodiment, various aspects of the invention are embodied in computer software programs/applications. The programs include computer-readable instructions and associated data which when executed by a processing unit (such as unit 204) cause the computer system 200 to 25 perform the relevant function. Instructions and data (i.e. software) may be stored on the volatile and/or non-volatile memory 206 and 208 (or, indeed, on an external machine readable medium accessible by the one or more drive interfaces 216 or ports 218). The term "machine-readable medium" as used herein is intended to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by a computer processing unit, or that is capable 30 of storing, encoding or carrying data used by or associated with such instructions.

10 The instructions may be conveyed to the relevant terminal/server by means of a data signal in a transmission channel. Examples of such transmission channels include wired or wireless network connections enabled by the communications interface 220 and various communications protocols. 5 As will be appreciated, the various components of the system 200 described above and depicted in Figure 2 are relatively standard, and some or all of those components will typically be present in both the server 102 and end user device 108 described above. It will also be appreciated, however, that not all computing devices/systems will include all components illustrated/described, and that some devices/systems will include additional and or alternative 10 components. Client application As discussed above, in one embodiment of the invention the application is a banking application allowing an end user to access financial information and perform transactions from a remote device 108. In a very specific (and non-limiting) embodiment, the user device 108 may 15 be an iPhone or other smart phone device. In order to provide access to the server 102, one embodiment of the invention requires one or more specific applications to be installed on the user device 108 (i.e. the client application 104). The client application includes data and instructions which, when executed, cause the user device to provide typical client-side functionality - e.g. the ability to enter data (using user input 20 device(s) such as 212) and view data (using display device(s) such as 210), transmit data to/receive data from the server 102 over the communications network 106 (using a communications interface such as 218). As discussed in further detail below, the client application 104 also includes a registration module (instructions which provide for registration of the device 108/user), and an automatic 25 authentication module (instructions for performing an authorisation process by which the device is able to be authorised by the server without user input). The client application also includes a key generation algorithm/module - i.e. instructions for generating a key based on an input (e.g. a key seed or other session related data). In one embodiment the key generation algorithm/module generates a key using a random number 1 generator which uses seed data as an input. The purpose of the seed data is to ensure that the random number generator produces a result which is not determinable without exact knowledge of the state of the random number generator and any inputs provided to it at the time. Once the key is generated it is transmitted to the server (e.g. the bank) by encrypting it 5 with the Bank's Public Key using RSA or a similar asymmetric encryption algorithm. The actual public key may be embedded within the client application or downloaded at run-time. The client application also includes an authorisation code generation algorithm module which generates an authorisation code for authenticating a session between the user device and the server. In one embodiment the authorisation code is generated by use of a One Time 10 Password algorithm such as that specified in IETF RFC TOTP 6238 (Time-Based One-Time Password Algorithm). A key difference between the implementation of the present embodiment and TOTP is that TOTP is primarily designed for disconnected devices it uses a static non rolling key and does not transmit the authorisation code input Vector (e.g. time) to the server. The client application 104 also includes an encryption module - instructions which allow 15 for the encryption/decryption data being communicated to/received from the server 102. Keys for protecting data at the application level are generated using rolling keys (discussed below) together with bank provided input (e.g. seeds/vectors) which are input into a key generation algorithm such as KDF2 (ISO-18033-2). In some instances, messages between the user device and the server can be signed by the 20 relevant Key stored on the device using the transaction data as an additional input into key generation process. This means that if the transaction data is changed somewhere between the device and the Bank server then the AUTH code would no longer verify the instant transaction. The client application 104 also includes instructions/data allowing for various specific services offered by the server 102 to be used (once the user has been successfully authenticated). 25 In the case of a banking application, these services may include (for example) obtaining account balance information, transferring money between accounts, and paying bills. By way of alternative example, in an email application the services may allow the user to read emails sent to the user and compose and send emails to other users. Server application 12 The server 102 will also include one or more applications (i.e. instructions for execution by the server 102) providing for the operation of the server 102. In addition to instructions allowing the server to perform typical server tasks, the server application also includes a registration module (instructions for registering a new client device), an automatic authentication 5 module (instructions for authenticating a client device), a key generation module (instructions for generating keys (as described above)), and an encryption module (instructions for encrypting/decrypting data (as described above)). The server will also include code for synchronising keys between the server and user devices, and detecting if keys have been duplicated and are being used by more than one device 10 to enable the server to take appropriate action to protect transactions. Registration process When the client application 104 is installed on the device 108, and the user first seeks to make use of the application, the registration module of the client application is called to implement an initial registration process. Broadly speaking the initial registration process serves 15 to identify and authenticate the end user/user device 108 to the server 102. The device registration process will first be described generally in relation to Figure 3 (which provides an overview of the communications between the client application 104 and the server 102 during this registration process). Operations occurring at each of the user device 108 and the server 102 will then be described with reference to Figures 4A and 4B respectively. 20 On launching the application on their device 108, the client application 104 prompts the user to submit user credentials to the server 102. The user credentials may, for example, include an existing user name and password known to both the user and the server 102. The user credentials are sent to the server 102 (or in particular, the server interface 110) over the communications network 106 where they are received and passed to the security application 25 server 112 for authentication. In some cases, successful validation of the user credentials may be deemed sufficient to identify and authenticate the user. Where security is of concern, however, additional authentication steps will be warranted and the server 102 will implement a second factor authentication procedure (not shown in Figure 3). By way of one, non-limiting, example, the 30 second factor authentication may involve the server 102 sending the user a one time password 13 via a separate communication channel/to a separate address, and require the user submit that one time password via the client application 104 being run on the user device 108. For example, on verifying the user credentials at if the server 102 may send a code to an email address or phone number (e.g. via SMS) associated with the user, and prompt the user to submit the code back to 5 the server 102 via the application running on the device 108. On receiving the numeric code, the user can then enter the code and submit this to the server 102, where it is validated and (if validation is successful) the user is authenticated. Once the user is authenticated, the security application 112 generates a server rolling key input for transmission to the client. In one embodiment the server rolling key input is a random 10 number generated using a random number generator. The server rolling key input is transmitted to the user device 108 (via the interface 110) where it is received by the client application 104. When the customer is authenticated by the server 102, the server 102 also generates a specific device identifier for the device 108 relevant to the registration procedure. The server 102 then encrypts the device identifier, together with a user identifier relevant to the registration (e.g. 15 a user name or similar provided by the user in the user credentials initially sent to the server 102), to create a user/device identifier. The user/device identifier is also sent to the client 104. This may be sent together with the initial rolling key input as illustrated in Figure 3, though could of course be sent in an alternative message. At the device 108, the client application 104 uses the server rolling key input, together 20 with an additional device/client application generated input (e.g. randomly generated number), to generate a current rolling key. The current rolling key is saved locally (either in encrypted or unencrypted form) on the device 108 (e.g. on memory 208). Application 104 also stores the user/device identifier received by from the server to memory which (as discussed below) is used with the current rolling key for future authentication purposes. 25 At the device 108 the client application 104 also encrypts the current rolling key (e.g. with a public key of the server 102) and sends the encrypted rolling key back to the server 102. On receipt the server 102 decrypts the encrypted current rolling key (e.g. with its private key) and stores the current rolling key for the device in a secure record with other user details in the database 116.

14 Once the user's current rolling key is received and stored by the server 102, the initial registration process is complete. Registration process - client side Figure 4A is a flow chart 400 setting out operations that take place at the user device 108 5 (i.e. by the registration module of the client application 104) to effect the initial registration process in accordance with one embodiment of the invention. At step 402 the registration process is initiated, for example by the user launching the client application 104 for the first time. At step 404 the client application 104 prompts the user to enter their user credentials and at step 406 these credentials (as input by the user) are sent to the server 102. The user credentials 10 may, for example, include a user name and password already known to the user and by the server 102. At step 408, provided the user credentials are successfully validated by the server 102, the client application 104 receives from the server 102 a server rolling key input and a user/device identifier. At step 410 the client application uses the server rolling key input received 15 in step 408, together with a device rolling key input (e.g. a random number generated by the device client application 104) to generate a current rolling key. As discussed above, generation of the rolling key is achieved by a key generation module which forms part of the client application 104. At step 412 the current rolling key generated at step 410 is stored to a memory of the user device 108 (e.g. non-volatile memory 208) by the client application 104. The 20 user/device identifier received is also stored to a memory of the device. At step 414 the client application 104 encrypts the current rolling key generated at step 408 to produce an encrypted current rolling key (using the encryption module as described above), and at step 416 the encrypted current rolling key is transmitted to the server 102. Registration process - server side 25 Figure 4B is a flow chart 450 setting out operations that take place at the server 102 to effect the initial registration process in accordance with one embodiment of the invention. At the logical level, the bulk of the processing is performed by the security application server 112, which receives and sends data via the server interface 110, and stores/retrieves data from the database 116 via database server 114.

15 At step 452 the server 102 receives a registration request from the user device 110 which includes the user credentials. At step 454 the server 102 authenticates the user credentials. This involves, for example, the server 102 checking whether the credentials submitted by the user match those stored on the server database 116. 5 If authentication of the user credentials at step 454 is successful, the server 102 may optionally instigate a second factor authentication process as described above (step 455). On successful authentication (whether by single or multi factor authentication), the sever 102 generates a server rolling key input at step 456. The server rolling key input may, for example, be a random number of a pre-determined length generated by a random number 10 generator. The server also generates a user/device identifier taking into account the user credentials (or part thereof) received at step 452 together with a device identifier generated by the server 102 for the specific device. At step 458 the server 102 transmits the rolling key input and the user/device identifier (in encrypted form) to the user device 1 10. 15 At step 460 the server 102 receives an encrypted current rolling key from the user device 110. At step 462 the server 102 decrypts the encrypted current rolling key (using the decryption module as described above) to obtain the current rolling key. The current rolling key is then saved to the server database 116 at step 464. Authentication process 20 Once the registration process is complete the user device 108 and server 102 both have the user device's current rolling key stored in their local memory (e.g. device memory 208 and database 116). At various times/stages further authentication of the user device may be desired. At times it will be advantageous for such authentication to be automatic (i.e. without requiring user input). 25 For example, and as discussed above, in one embodiment the client application provides a function which (when enabled) involves the client automatically requesting certain bank account information from the server and then displaying that information on the user device. On each request the server requires the client application to identify the user device, which the client 16 application does transparently to the user (i.e. without requiring the user to actively submit further information). The authentication process will be described generally in relation to Figure 5 (which provides an overview of the communications between the client application 104 and the server 5 102 during this process). Operations occurring at each of the user device 108 and the server 102 (handled by their respective authentication modules) will then be described with reference to Figures 6A and 6B respectively. When authentication is required (for example, on the client application 104 requesting updated balance information from the server 102) the client application 104 generates an 10 authorisation request to send to the server 102. The authorisation request includes an authorisation code which is generated by the client application 104 with reference to both the current rolling key stored on the client device 108, and an authorisation code input. In one embodiment the authorisation code input is derived from time and/or date information, though alternative inputs could of course be used (e.g. a randomly generated number). 15 In an alternative embodiment, the authorisation code input may be transaction information used in combination with time or a transaction counter. By inputting the transaction information into the authentication function it not only authenticates the user has the key but also binds the actual transaction data into the context of the transaction making the authorisation code only valid for the specific transaction at that specific time. 20 In addition to the authorisation code, the authorisation request includes a SHA-l HMAC, the authorisation code input, and the user/device identifier (as provided to the device 108 by the server 102 during the registration process). On receipt of the authorisation request the security application server 112 decrypts the user/device identifier to retrieve the user identifier and the device identifier. These can then be 25 used to retrieve the user's current rolling key from the database 116, as well as (where available) a previous rolling key of the user. Using the authorisation code input (from the authorisation request) and the user's current rolling key (retrieved from the database), the security application server 112 attempts to verify the authorisation code submitted by the client application 104. If verification of the authorisation 17 code using the user's current rolling key is not successful, the server tries to verify the authorisation code using the user's previous rolling key (provided a previous rolling key exists). If verification of the authorisation code is still not successful, the transaction will not proceed and the user will be provided with an appropriate error message such as one advising the 5 user to contact customer service. In addition the credential may be locked out permanently or for a period of time depending on the current policy desired. If verification of the authorisation code is successful (using either the current or previous rolling key), the user device is authenticated and is able to interact with the server 102 accordingly. 10 In addition, on successful verification of the authorisation code the security application server 112 generates a new rolling key input (which may, again, be a random number). This new rolling key input is used by the server 102, together with the user's current or previous rolling key as retrieved from the database (depending on which of these was used to successfully verify the authorisation code), to generate a new rolling key for the user. 15 The user details stored in database 116 are then updated with the new rolling key. If the authorisation code was verified using the "current" rolling key, the database 116 is updated by saving "current" rolling key stored for the user in the database as the user's previous rolling key, and saving the newly generated rolling key as the user's current rolling key. Alternatively, if the authorisation code is verified using the user's previous rolling key, the newly created rolling key 20 is saved in the server database 116 as the current rolling key and the "previous" rolling key is not changed (serving to re-align the user's 'current' and 'previous' rolling keys stored in the server database 116 with the rolling keys previously used and newly sent to the client application 104). The sever 102 also sends the new rolling key input to the client application 104. On receiving the new rolling key input, the client application 104 uses this (together with the 25 'current' rolling key stored on the device 108 itself) to generate its own new rolling key. The new rolling key is then stored on the user device as the current rolling key in preparation for the next time authentication is required. As both the client application 104 and server security server application 102 generate the new rolling key on the same information, the "current" rolling key stored at the server 116 and 18 on the client device memory 208 will, provided transmission of the new rolling key input to the client application 104 is successful, be the same. As will be appreciated, however, the only information that has been transmitted between the client and server during the authentication process is the original authorisation code and vector (sent from the client 104 to the server 102), 5 and the rolling key seed (sent from the server 102 to the client 104). Interception of these communications alone, therefore, will not provide a third party with information necessary to authenticate themselves as the user. Authentication process - client side Turning to Figure 6A, a flow chart 600 is provided which depicts automatic 10 authentication operations that take place at the user device 108 (e.g. by the automatic authentication module of the client application 104) in accordance with one embodiment of the invention. At step 602 the authentication process is initiated. This may, for example, be on the client application 104 automatically requesting a balance update from the server 102. At step 604 the client application 104 retrieves the current rolling key from the device 15 memory (e.g. memory 208). At step 606, the current rolling key is used together with an authorisation code input to generate an authorisation code. The authorisation code input is determined by the client application 104 and may, for example, be a vector derived from date/time information. At step 608 the user/device identifier is retrieved from memory. 20 At step 610 the client application 104 sends an authorisation request to the server 102. The authorisation request includes the authorisation code generated at step 606, the authorisation code input, a SHA-I HMAC, and the user/device identifier. At step 612 an authorisation response is received from the server 102. If verification has failed, the authorisation response will indicate that access to the server is denied (as indicated at 25 step 614). If verification is successful, the authorisation response from the server 102 will indicate such, and include a new rolling key input (step 616). At step 618 the client application 104 generates a new rolling key based on the new rolling key input received from the server and the 19 "current" rolling key retrieved at step 606. The new rolling key is then saved as the current rolling key at step 620. Authentication process - server side Figure 6B is a flow chart 650 setting out operations that take place at the server 102 (e.g. 5 by the automatic authentication module of the server102) to effect the authentication process in accordance with one embodiment of the invention. Once again, while the flow chart will be discussed with reference to the steps being undertaken by the server 102 in general, the actual processing will typically performed by the security application server 112, which receives and sends data via the server interface 110, and stores/retrieves data from the database 116 via 10 database server 114. At step 652 the server 102 receives an authorisation request from the user device 110. The authorisation request includes a user/device identifier, an authorisation code, a SHA-1 HMAC, and an authorisation code input. At step 654 the server decrypts the user/device identifier in order to identify the user and 15 device 110 and retrieve the current and previous (if extant) rolling keys relevant to that device 110 from the database 116. At step 656 the server 102 attempts to verify the authorisation code using the authorisation code input and the user's current rolling key. Verification of the authorisation code is achieved by the security application server 110 generating its own authorisation code based on 20 the authorisation code input received from the client application 104 (as part of the authorisation request received at step 652) and the user's current rolling key (as retrieved from the server's own database 116 at step 654). If the authorisation code generated by the server matches that received from the client application 104, verification is successful. If verification of the authorisation code using the user's current rolling key (and 25 initialisation vector) is successful, the server 102 generates a new rolling key input (e.g. a random number) at step 658. At step 660 a new rolling key is generated with reference to the new rolling key input (from step 658) and the user's current rolling key (as retrieved from the database at step 654).

20 At step 662 the server 102 updates the database 116 with the new rolling input. This involves the server 102 saving the 'current' rolling key retrieved from the database at step 654 as the users previous rolling key, and saving the newly generated rolling key (generated at step 660) as the user's current rolling key. 5 If the server 102 cannot verify the authorisation code using the user's current rolling key, and a previous rolling key exists for the user, the server 102 attempts to verify the authorisation code using the user's previous rolling key at step 664. If verification of the authorisation code using the user's previous rolling key is successful, the server 102 generates a new rolling key input (e.g. a random number) at step 666. At step 668 the server 102 then generates a new rolling 10 key with reference to the new rolling key input (from step 664) and the user's previous rolling key (as retrieved from the database at step 654). At step 670 the server 102 updates the database 116 with the new rolling key. As the authorisation verification (and the generation of the new rolling key) was based on the user's 'previous' rolling key, the server 102 updates the database by simply saving the newly generated 15 rolling key (generated at step 668) as the user's current rolling key. The user's previous rolling key in this case is not changed. At step 672 the server 102 transmits the new rolling key input (generated at step 658 or step 666 depending on whether verification of the authorisation code was based on the user's current or previous rolling key) to the user device 108, together with a message that authorisation 20 was successful. If the authorisation code cannot be verified using either the current or previous rolling key, the server 102 sends an authorisation message to the client device 108 indicating that authentication has failed (step 674). The operations set out in Figures 4A and 6A are facilitated by computer readable 25 instructions and/or data of one or more software programs which are stored on a memory of the user device 108 (such as memory 208) and executed by a processing unit of the user device 108 (such as processing unit 202). Similarly, the operations set out in Figures 4B and 6B are facilitated by computer readable instructions and/or data of one or more software programs which are stored on a memory of the server 102 (such as memory 208) and executed by a 30 processing unit of the server 102 (such as processing unit 202).

21 Additional authentication measures The automatic authentication process discussed above (i.e. that does not require user input) will provide sufficient security for certain functions provided to the client application by the server. As one example, a function for which the automatic authentication procedures is 5 sufficient may be an application/widget that periodically requests certain account information for display. Other functions, however (such as funds transfers or bill payments) may require additional security. In this case additional security steps may be performed either instead of or in conjunction with the automatic authentication procedure described above. 10 In one embodiment of the invention, functions requiring "additional" security will make use of both the automatic authorisation procedure as well as an additional authentication process which may require, for example, the user to submit a password or similar. In this case the additional authentication process may occur before, after, or during the automatic authentication procedure. 15 Although the embodiments of the invention above have been described in relation to a banking/financial services type scenario, it will be appreciated that the registration and/or authorisation procedures discussed herein could equally be applied in any number of scenarios/applications where secure authentication of a remote device by a server is required or advantageous. Such services may include, for example, electronic mail services, social 20 networking services, flight/hotel/other booking services, services offering remote access to network resources etc. It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative 25 aspects of the invention.

Claims

1. A client-side registration module for registering a client device with a server, the client-side registration module including computer readable instructions executable by a computer processor of the client device to: 5 generate a registration request including user credentials provided by a user of the client device; transmit the registration request to the server using a communications interface of the client device; if registration by the server is successful, receive via the communications interface a 10 server rolling key input from the server; generate an initial rolling key using at least said server rolling key input; save said initial rolling key to a memory of the client device; and transmit said initial rolling key back to the server using the communications interface.

2. The client-side registration module according to claim 1, wherein the initial 15 rolling key is generated using both said server rolling key input and a device rolling key input generated by the client registration module.

3. The client-side registration module according to claim 1 or claim 2, wherein the initial rolling key is encrypted by the client-side registration module prior to being transmitted to the server. 20

4. The client-side registration module according to any one of claims I to 3, further including instructions executable by the computer processor of the client device to receive a device identifier from the server and save said device identifier to the memory of the client device.

5. The client-side registration module according to claim 4, wherein the device 25 identifier is received from the server in an encrypted user/device identifier, the encrypted user/device identifier encrypting both the device identifier and a user identifier. 23

6. A server-side registration module for registering a client device with a server, the server-side registration module including computer readable instructions executable by a computer processor of the server to: receive, via a server communications interface, a registration request from the client 5 device, the registration request including user credentials; authenticate the user credentials by reference to credentials for the user stored on a server accessible memory; wherein if authentication of the user credentials is successful: generate a server rolling key input; transmit said server rolling key input to the client device; 10 receive a rolling key from the client device; save the rolling key to the server memory.

7. A server-side registration module according to claim 6, wherein the rolling key is encrypted, and wherein the server-side registration module decrypts the rolling key before saving the rolling key to the sever memory. 15

8. A server-side registration module according to claim 6 or claim 7, further including computer readable instructions executable by the computer processor of the server to: generate a device identifier for the client device from which the registration request was received; save said device identifier to the server memory; and 20 transmit said device identifier to the client device.

9. A server-side registration module according to claim 8, wherein the device identifier is encrypted together with a user identifier to generate a user/device identifier, and wherein: saving the device identifier to memory involves saving the user/device identifier to 25 memory; and 24 transmitting the device identifier to the client device involves transmitting the user/device identifier to the client device.

10. A client-side automatic authentication module including instructions executable by a computer processor of a client device to: 5 generate an authorisation code based on a current rolling key stored on a memory of the device and an authorisation code input; transmit an authorisation request to a server, the authorisation request including the authorisation code, the authorisation code input, and a device identifier; if authentication by the server is successful, receive a rolling key input from the server; 10 generate a new rolling key using said rolling key input; and save said new rolling key to the memory of the device as a new current rolling key, the new current rolling key usable in subsequent authentication procedures.

11. The client-side automatic authentication module according to claim 10, wherein the device identifier is included in a user/device identifier which includes both a user identifier 15 and the device identifier.

12. The client-side automatic authentication module according to claim 10 or claim 11, wherein the authorisation code input is derived from date/time information.

13. A server-side automatic authentication module including instructions executable by a computer processor of a server to: 20 receive an authorisation request from a client device, the authorisation request including an authorisation code, an authorisation code input, and a device identifier in respect of the client device; retrieve from a server accessible memory a current rolling key associated with the device identifier; 25 verify the authorisation code using the authorisation code input and current rolling key; wherein if verification of the authorisation code using the current rolling key is successful: 25 generate a new rolling key input; generate a new current rolling key using the new rolling key input and the current rolling key; save the current rolling key to the server accessible memory as a previous rolling key 5 associated with the device identifier; save the new current rolling key to the server accessible memory as the current rolling key associated with the device identifier; and transmit the new rolling key input to the client device.

14. The server-side automatic authentication module according to claim 13, wherein 10 if verification of the authorisation code using the current rolling key is not successful, the module further includes instructions executable by the computer processor of the server to: retrieve from the server accessible memory a previous rolling key associated with the device identifier; verify the authorisation code using the authorisation code input and previous rolling key; 15 wherein if verification of the authorisation code using the previous rolling key is successful: generate a new rolling key input; generate a new current rolling key using the new rolling key input and the previous rolling key; save the new current rolling key to the server accessible memory as the current rolling 20 key associated with the device identifier; and transmit the new rolling key input to the client device.

15. A user device including a client-side registration module according to any one of claims 1 to 5.

16. A user device including a client-side automatic authentication module according 25 to any one of claims 10 to 12. 26

17. A user device including a client-side registration module according to any one of claims I to 5 and a client-side automatic authentication module according to any one of claims 10 to 12.

18. A server including a server-side registration module according to any one of 5 claims 6 to 9.

19. A server including a server-side automatic authentication module according to either claim 13 or claim 14.

20. A server including a server-side registration module according to any one of claims 6 to 9 and a server-side automatic authentication module according to either claim 13 or 10 claim 14.