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
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.
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
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
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
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
1001258472
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
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
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
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
key input and a user/device identifier from the server; generate an initial rolling key using at
least said server rolling key input; save said initial rolling key and said user/device identifier 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.
The initial rolling key may be encrypted by the client-side registration module prior to
being transmitted to the server.
The user/device identifier may be received from the server in an encrypted form, the
encrypted user/device identifier encrypting both the device identifier and a user identifier.
1001258472
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
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; generate a user/device identifier; transmit said
server rolling key input and said/user device identifier to the client device; receive a rolling key;
save the rolling key to the server memory.
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; and encrypt said device identifier
together with a user identifier to generate the user/device identifier.
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 user/device identifier; if
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 said current rolling key; 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.
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
1001258472
authorisation request from a client device, the authorisation request including an authorisation
code, an authorisation code input, and a user/device identifier in respect of the client device and
a user 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 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.
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:
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.
1000070131
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
of example and with reference to the accompanying drawings.
Brief description of the drawings
Figure 1 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
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
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
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.
Figure 7 depicts an end user device displaying updated account balance information in
accordance with an embodiment of the invention.
1000070131
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
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
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
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
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
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-
server system 100. The client server system 100 includes a server system 102 which, in the
1000070131
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
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
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,
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
.0 applications, Flash etc). Programmatic clients may be stand alone applications, or be
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
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
interface 110 which may, for example, include web servers and/or an Application Program
1000070131
Interface (API) servers. Interface(s) 110 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.
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,
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
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
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
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
of storing, encoding or carrying data used by or associated with such instructions.
1000070131
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.
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
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
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
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
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
1000070131
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
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
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
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 (ISO2).
In some instances, messages between the user device and the server can be signed by the
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).
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
1000070131
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
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
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
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.
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
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
second factor authentication may involve the server 102 sending the user a one time password
1000070131
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
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
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.
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
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.
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.
1000070131
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
(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
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
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
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
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.
1000070131
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.
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
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 110.
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
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).
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
1000070131
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
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
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).
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.
In addition to the authorisation code, the authorisation request includes a SHA-1 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
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
1000070131
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
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.
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.
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
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
‘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
1000070131
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),
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
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
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.
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-1 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
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
1000070131
“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.
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
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
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
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
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).
1000070131
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.
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
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
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
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
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
processing unit of the server 102 (such as processing unit 202).
1000070131
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
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.
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.
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
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
aspects of the invention.
1001258472