WO2012117253A1 - An authentication system - Google Patents

An authentication system Download PDF

Info

Publication number
WO2012117253A1
WO2012117253A1 PCT/GB2012/050468 GB2012050468W WO2012117253A1 WO 2012117253 A1 WO2012117253 A1 WO 2012117253A1 GB 2012050468 W GB2012050468 W GB 2012050468W WO 2012117253 A1 WO2012117253 A1 WO 2012117253A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
authentic
key
data
authentication system
Prior art date
Application number
PCT/GB2012/050468
Other languages
French (fr)
Inventor
Richard Hurley
Lance KEAY
Original Assignee
Digitalle Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digitalle Limited filed Critical Digitalle Limited
Publication of WO2012117253A1 publication Critical patent/WO2012117253A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key

Definitions

  • the present invention relates to an authentication method, apparatus, and system for authenticating and validating access by devices over a communications network to resources relating to digital content and/or other information such as restricted resources accessible over a communications network.
  • the term 'Restricted resources' refers to resources including any information such as digital content or information in digital form including text, data, sound recordings, photographs and images, motion pictures, software, digital documents and/or files, information resources, transactions, and/or other computing resources that are protected from unauthorised access.
  • the login credentials, username and password are entered by the user when first logging-in to a computer system or server (also known as a resource server) providing access to restricted resources or content.
  • a computer system or server also known as a resource server
  • This type of authorisation is commonly used for access to many types of stand-alone computer terminals, personal devices, closed systems such as intranets, libraries, or secure database facilities and the like, but where the authorised user is usually physically present.
  • This type of authorisation has now also been adapted for systems where users have remote access to the restricted resources over a communications network, e.g. a wireless network or the internet. It is also common for resource providers or servers to allocate authorisation credentials to users, so they may gain access to the restricted resources. Examples of such resource providers are libraries, information repositories, and even online publishers like the IEEE Online Journal and other scientific journals or The Financial Times and other news providers that provide access to restricted resources such as journal and news articles.
  • the protection typically employed by resource and content management systems is username and password. There is no protection against multiple or simultaneous abuse and use of authenticated login credentials and no system for monitoring such illicit activity. This can give un-metered and/or un-policed access to restricted resources for anyone having access to "legitimate" login credentials, e.g. a user name and password, or authenticated tokens contained within transmitted cookies or session identifiers.
  • the object of the present invention is to provide an additional layer of authentication and validation for resource servers/systems/providers to overcome the issues associated with rapidly ensuring authentic users or devices have access to restricted resources over a communications network, e.g. such as the internet or a wireless mobile network. That is, to prevent abuse of authentic login credentials when a device accesses restricted content or resources.
  • a communications network e.g. such as the internet or a wireless mobile network.
  • a continuous dynamic authentication and validation system for securing device access to resources and/or restricted resources over a communications network.
  • a method and apparatus for an authentication system to provide an indication that a device requesting access to restricted resources from a resource system is authentic.
  • the method includes receiving an authentication request from a resource system, the authentication request including data representative of a dynamic key transmitted by the device, determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information in relation to the authentic device, wherein the stored historical information includes one or more previously generated dynamic keys in relation to the authentic device, and transmitting the indication that the device is the authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
  • the apparatus includes a receiver unit for receiving an authentication request from the resource system, the authentication request including data representative of a dynamic key transmitted by the device, a processing unit for determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information corresponding to previously generated dynamic keys in relation to the device, and a transmitter unit for transmitting the indication of the likelihood that the device is an authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
  • the data representing a dynamic key includes a first portion of data generated by the authentication system that is representative of a device key or the identity of the device, and a second portion of data generated by the
  • generating the further dynamic key comprises:
  • the step of determining the indication or indication value includes determining whether the received dynamic key corresponds with a dynamic key generated by the authentication system in response to the previous authentication request message in relation to the authentic device.
  • the authentication system can rapidly determine whether the device is an authentic device by comparing the received dynamic key(s) with those previously generated for the authentic device.
  • the authentication request further includes data representative of device information related to the identity of the device and the stored historical information further includes data representative of device information related to the identity of the authentic device.
  • the device information, or combinations of it becomes in effect the device's "fingerprint" and should be relatively unique to each device. This provides an extra layer of security to the resource and authentication systems.
  • the device information can take any characteristic, or combination of characteristics, of the device that substantially uniquely identifies the device.
  • determining the indication further comprises accumulating one or more scores based on the similarity of portions of the received device information with corresponding portions of stored historical device information of the authentic device. This provides the advantage that a decision can be made as to whether the device is most likely an authentic device, despite some changes in the device information.
  • the device information of an authentic device can change over time, and these changes can be monitored and stored by the authentication system, while still allowing the device to be authenticated without requiring re-registration.
  • Figure 1 illustrates a communications system 10 for controlling access of a device 12 to restricted resources from a resource system 14 via an authentication system 16;
  • Figure 2a illustrates an embodiment of an initialisation, registration or re-registration procedure of device 12 that is performed on the authentication system 16 of figure 1 ;
  • Figure 2b illustrates an embodiment of the authentication process for authenticating a device 12 performed at the authentication system 16 of figure 1 for providing an indication of an authentic device following a request for restricted resources from the resource system 14;
  • Figure 2c illustrates a continuation of the embodiment of the authentication process initiated in Figure 2b performed at the authentication system 16;
  • Figure 3 illustrates an embodiment of an access grant process performed by the resource system 14 of figure 1 when a device 12 makes a request for restricted resources
  • Figure 4 illustrates an embodiment of a process performed on a device 12 of Figure 1 for requesting restricted resources from the resource system 14.
  • a communications system 10 for controlling access for at least one device 12 to restricted resources from a resource system 14.
  • the communications system 10 includes one or more devices 12 in communication over a communications network with the one or more resource systems 14, and an authentication system 16.
  • the communication system 10 uses resource systems 14 and authentication system 16 the communication system 10 performs a continuous dynamic authentication and validation of each of the devices 12, allowing the devices 12 to secure access to restricted resources over corresponding communications network(s).
  • a device 12 has at least one or more of the following capabilities:
  • a resource system 14 has at least one or more of the following capabilities:
  • an authentication system 16 has at least one or more of the following capabilities:
  • the device 12 transmits one or more resource request message(s) to the resource system 14.
  • the message(s) include(s) data representing a request for a restricted resource(s), identifying information or device information of the device 12, and if present data representative of one or more dynamic data key(s) generated and previously provided to the device 12 by the authentication system 16 via resource system 14.
  • the dynamic data key(s) are used by the authentication system 16 to identify whether the device 12 is authentic and determine that the request for the restricted resources has not been usurped or sent by an
  • the resource system 14 On receiving the resource request message(s) from device 12, the resource system 14 transmits an authentication request message(s) to the authentication system 16.
  • the authentication request message(s) include(s) the dynamic data key(s) if present and/or the identifying information of the device 12.
  • the authentication system 16 On receiving the authentication request message(s), the authentication system 16 performs a risk assessment by determining the risk that the device 12 that is requesting access to the restricted resources is authentic.
  • the risk assessment is determined from, but is not limited to, a) the dynamic data key(s), b) the identifying device information, and/or c) a stored and evolving history of the device 12 that is related to accessing the restricted resources from the resource system 14.
  • the risk assessment or indication is then transmitted to the resource system 14 to enable it to determine whether the device 12 should have access to the restricted resources. It is to be appreciated that the risk assessment can be determined from at least the dynamic data key(s) and/or a stored and evolving history of the dynamic data key(s) generated by the authentication system 16 in relation to device 12.
  • the dynamic data keys are generated and stored by the authentication system 16. This allows the authentication system 16 to control and track the sequence of requests for restricted resources made by the device 12.
  • the authentication system 16 transmits one or more of the dynamic data key(s) to device 12 via the resource system 14.
  • the authentication system 16 controls the generation of the dynamic data key(s) and when necessary it regenerates one or more of the dynamic data key(s) as a replacement for a previously generated data key in order to establish and maintain a stored and evolving history relating to the identity and activity of device 12 which is used by the authentication system 16 in its calculations for generating an indication of the authenticity of a device 12.
  • Regenerating and replacing/storing the dynamic data key(s) allows the authentication system 16 to monitor a sequence of requests for restricted resources made by the device 12.
  • the replacement dynamic data key(s) are transmitted back to the device 12 from authentication system 16 via resource system 14 for use by the device 12 in subsequent requests for restricted resources from the resource system 14.
  • the device key there are two dynamic data keys, a device key that is used to identify the device 12 and a request key that is used to identify a legitimate request for restricted resources within a sequence of requests for the restricted resources.
  • a device key that is used to identify the device 12
  • a request key that is used to identify a legitimate request for restricted resources within a sequence of requests for the restricted resources.
  • the device key uniquely identifies a registered device
  • the authentication system 16 can immediately detect that the device 12 may not be legitimate and that the authentication credentials and/or other information of the device 12 may have been usurped and/or compromised. This will affect the risk assessment of the device 12 by the authentication system 16.
  • the authentication system 16 can immediately detect that the device 12 might not be legitimate or that the authorisation credentials of the device 12 and/or other information has been usurped and/or compromised. This will also affect the risk assessment of the device 12 by the authentication system 16. Although the authentication system 16 could simply make a risk assessment based only on the dynamic data key(s) within a sequence of request messages, it is to be appreciated that further tests can be applied in the risk assessment made by the authentication system 16. In this example, if the device 12 does transmit the required dynamic data key(s) in the sequence that is expected, the authentication system 16 continues to perform a risk assessment of device 12 based on other data sent to the
  • the authentication system 16 and which is stored in relation to the device 12.
  • the risk assessment is applied to the data representing the identifying information or device information of device 12.
  • the device 12 also transmits this information to the authentication system 16 in addition to the dynamic data keys via the resource system 14.
  • the identifying information or device information of the device 12 is based on information such as, but not limited to, the software/hardware set-up of device 12, for example, an IP address of device 12, a serial number of device 12, and/or a media access control address of a network interface of device 12, and/or a SIM card serial number of device 12, and/or the type of operating system used by device 12, and/or information representative of the hardware/software configuration of device 12, and/or the date and time of the request of device 12, and/or the location of device 12 etc., or any other information that can be used to identify device 12.
  • the software/hardware set-up of device 12 for example, an IP address of device 12, a serial number of device 12, and/or a media access control address of a network interface of device 12, and/or a SIM card serial number of device 12, and/or the type of operating system used by device 12, and/or information representative of the hardware/software configuration of device 12, and/or the date and time of the request of device 12, and/or the location of device 12 etc., or any other information
  • This information becomes in effect the fingerprint of the device 12, which should be distinctive for each device, and relatively unique.
  • This information can change over time (e.g. the IP address changes when a device 12 connects to the internet at home or in a cafe) and is useful to the authentication system 16 to determine whether the device 12 is authentic or not. This depends on how much change occurs in the device information of a device 12 between each request for restricted resources that the device 12 requests from the resource system 14.
  • the device 12 Each time the device 12 requests access to restricted resources, in addition to the dynamic data key(s) sent by the device 12, the device 12 also sends information relating to the device, i.e. the device "fingerprint" via the resource system 14. This allows the authentication system 16 to perform a series of tests on the current authentication request message's device information and the stored historical device information that the authentication system 16 has accumulated over time.
  • the historical device information stored by the authentication system 16 is based on the device information of the device 12 that was initially submitted to the authentication system 16 and previous requests for restricted resources made by the device 12 from the resource system 14. In the requests for resources, the device information is transmitted to the resource system 14 from the device 12. This information is also transmitted from the resource system 14 to the authentication system 16 for storage and later use in authenticating the device 12.
  • the 'current' device information of the device 12 is the current device information contained within the resource request message which is sent from the device 12 to the resource system 14 when requesting restricted resources, and which is further transmitted to the authentication system 16 as part of the
  • authentication request message This is stored by the authentication system 16 and used in its risk assessment tests and calculations.
  • the authentication system 16 then performs a risk assessment consisting of a series of tests and calculations which use data including, but not limited to the current device information, the stored and evolving historical device information of device 12, the device key, and the request key (if either or both are present) to determine an indication representing the likelihood that device 12 is authentic.
  • Each test in this group of risk assessment tests outputs a value.
  • the value may take into account both the importance of the test (in comparison to the other tests) and the result of the test used to determine the likelihood that the device 12 is authentic. After the required tests are complete, the values are then accumulated and/or weighted to give an overall indication of whether the device 12 is authentic. If the test indication indicates that device 12 is NOT authentic, the
  • the authentication system 16 will invalidate the device key and request key, and store this invalidation event. In the case of subsequent attempts to use these invalid data keys, the attempts are logged against the activity record of the device 12 as part of a stored and evolving historical device information of device 12, to assist in identifying future attempts from un-authentic devices 12.
  • This indication of authenticity is transmitted from the authentication system 16 to the resource system 14.
  • the resource system 14 decides whether to allow the device 12 access to the restricted resources. Should the risk assessment require the resource system 14 to restrict access to restricted resources for device 12, the device 12 may be told to undergo a re-authorisation or re-registration procedure at the resource system 14 in order to continue accessing the restricted resources provided by the resource system 14. This helps to ensure future requests for restricted resources are only made by authentic or legitimate devices 12.
  • the re-authorisation process performed at the resource system 14 may use one or more methods of identity validation. These may include (but are not limited to):
  • a security token (or sometimes a hardware token, hard token, authentication token, USB token, cryptographic token, or key fob) may be a physical device that an authorized user of computer services is given to enable authentication.
  • the authentication system 16 can perform or execute a set or series of tests or rules based on the information provided in the fingerprint of the device 12 and the historical device information stored by the authentication system 16.
  • Each test or rule may output a score or value that is then accumulated and/or weighted to provide an overall value representing an indication of the risk that the device 12 is not authentic.
  • the indication of risk is transmitted to the resource system 14, which uses it to determine whether or not access to the restricted resource is given to device 12.
  • the resource system 14 may compare the indication of risk value with one or more threshold level(s). If the indication of risk is beyond a certain threshold, then the request for the restricted resource(s) may be denied and/or the device 12 may be required to obtain re-authorisation from the resource system 14. There may be more than one threshold that provides varying levels of service/access to the device 12, e.g. further restricted access, requesting additional authorisation or unique information (e.g. a unique phrase) from device 12, or simply denial of the restricted resource(s) and the requirement of device 12 to re-initialise its authorisation and authentication with resource system 14 and authentication system 16, respectively.
  • a threshold level There may be more than one threshold that provides varying levels of service/access to the device 12, e.g. further restricted access, requesting additional authorisation or unique information (e.g. a unique phrase) from device 12, or simply denial of the restricted resource(s) and the requirement of device 12 to re-initialise its authorisation and authentication with resource system 14 and authentication system 16, respectively.
  • the authentication system 16 decides whether to (re)generate and replace one or more of the dynamic data keys for use by the device 12 in subsequent requests for further restricted resources from the resource system 14. This also allows the authentication system 16 to monitor the sequence of requests made by a device 12 and rapidly identify other unauthorised or unauthenticated devices 12 accessing the restricted resources of resource system 14.
  • the decision to generate further dynamic data keys may depend on one or more indication thresholds set within the Authentication System 16. For example, if the indication of risk falls beyond a certain indication threshold, then the indication of risk falls beyond a certain indication threshold.
  • authentication system 16 may not generate a replacement dynamic request key, thus forcing the device 12 to break the sequence of requests and ensuring that the device 12 will need to at least re-authorise with the resource system 14 or have its authorisation credentials, sequence or requests, and other identifying information (e.g. the device information) rechecked and/or re-initialised.
  • the initialisation process occurs on the authentication system 16 and is triggered by a request for restricted resources by a device 12 from the resource system 14.
  • the initialisation occurs when the authentication system 16 detects either:
  • the device key has recently been invalidated on a previous request and a replacement device key has not yet been issued to the device 12.
  • a device 12 subscribes to or becomes a member of a resource system 14 such as a journal or news publisher via their website
  • the device 12 typically uses login credentials such as an email and/or user name and password and the website creates a user account providing permissions on the articles and/or resources they can access etc.
  • the resource system 14 will pass on the device information, i.e. the fingerprint of the device, and further data which might include user account information, along with the request for authentication, to authentication system 16.
  • the request for authentication may also contain data relating to one or more previously generated dynamic data keys.
  • the authentication system 16 Upon receipt of the authentication request message from the resource system 14, the authentication system 16 will then perform the initialisation process in order to begin or continue tracking the behaviour and activity of the device 12 with respect to its requests for restricted resources from the resource system 14. The authentication system 16 may then generate and store one or more dynamic keys that are then associated with the device information of the device 12. These dynamic data keys are stored on the authentication system 16 and then transmitted back to the device 12 via the resource system 14 for use in subsequent requests for restricted resources. This begins the monitoring by the authentication system 16 of the sequence of requests by the device 12 for restricted resources from the resource system 14.
  • initialisation/registration and/or re-registration process 200 that is performed by the authentication system 16 to allow monitoring and risk assessment of a device 12 when it requests access to restricted resources from resource system 14.
  • step 202 the authentication system 16 determines, from information it has received as described below with reference to Figure 2b, whether it should register or re-register the device 12.
  • the data representing the device information for the device 12 is transmitted in one or more authentication request message(s) from the resource system 14 to the authentication system 16.
  • step 204 the authentication system 16 checks for the existence of a device key relating to the device 12 in the authentication request message transmitted by the resource system 14 to the authentication system 16.
  • step 206 the authentication system 16 detects that there is no device key in the authentication request message, and generates data representing a dynamic device key which is used to identify the device 12 in subsequent requests for restricted resources, and to assist in identifying subsequent requests for restricted resources that the device 12 makes from the resource system 14.
  • the authentication system 16 stores data representing the device key for the device 12, in addition to the device information, i.e. the device fingerprint, to establish a stored and evolving history for use in future requests for restricted resources from the resource system 14.
  • the authentication system 16 detects the existence of a device key that has been invalidated, and, in response, generates a replacement device key, which is used to identify the device 12 in subsequent requests and to assist in identifying subsequent requests that the device 12 makes from the resource system 14.
  • the authentication system 16 stores the invalidated device key as a new entry in a device key blacklist.
  • the device key blacklist is a list of previously generated and invalidated device keys relating to a device 12 that have been identified by the authentication system 16 as having been compromised. During the authentication processing procedure, any device key found to exist on the device blacklist will immediately return an unfavourable indication to the resource system 14.
  • the authentication system 16 stores data representative of the new replacement device key, including the device information, i.e. the device fingerprint, as part of the evolving history of the device 12 and which is used in determining the authenticity of device 12 in future requests.
  • the authentication system 16 transmits the new or replacement device key to the authentication system 16 for further internal use, e.g.
  • authentication processing which once complete will be transmitted back to the device 12 via the resource system 14 for use by the device 12 in subsequent requests for restricted resources from the resource system 14.
  • FIG. 2b there is illustrated an embodiment of a procedure 220 that is performed at the authentication system 16 for use in authenticating the device 12 when it requests access to restricted resources from the resource system 14.
  • the authentication system 16 For each device 12, the authentication system 16 generates and associates data representative of two dynamic keys, a device key and a request key. These keys are transmitted from the authentication system 16 to the device 12 via the resource system 14 for use in subsequent requests for access to restricted resources from the resource system 14.
  • the device 12 has already registered with resource system 14 and that the authentication system 16 may already have, or has just begun, a historical account or an evolving history of the device keys, request keys, and the device information, i.e. the device fingerprint, of the device 12.
  • the evolving history may also include other identifying information of the device 12 as previously described with reference to figure 1 .
  • the historical device information i.e. the historical device fingerprint
  • the authentication system 16 is stored and maintained by the authentication system 16 and is updated each time the authentication system 16 receives further device information related to the device 12 from the resource system 14.
  • the device 12 is the legitimate authentic device 12 and that it has received data representing a current set of dynamically generated data keys, i.e. at least a device key and/or a request key, from the authentication system 16.
  • a current set of dynamically generated data keys i.e. at least a device key and/or a request key
  • the device key is used by the authentication system 16 to rapidly identify the device 12 and its associated historical device information and/or associated activity.
  • the request key is used by the authentication system 16 to monitor or track a sequence of requests for restricted resources made by device 12 to the resource system 14.
  • the authentication system 16 receives one or more
  • Each authentication request message includes, but is not limited to, data
  • the authentication system 16 keeps track of the requests for restricted resources made by the device 12 from the resource system 14 in order to create and/or maintain a stored and evolving history of resource requests made by device 12.
  • step 224 the authentication system 16 checks the authentication request message for the existence of a device key.
  • step 226 it is assumed that the device 12 is either an unregistered device
  • the authentication system 16 then initiates the registration or re-registration process as outlined in figure 2a, in order to register or re-register device 12.
  • step 230 it is assumed that the device key exists.
  • the authentication system 16 determines if the device key has been invalidated, either previously by authentication system 16, or whether it matches the expected device key in a sequence of device keys previously generated and stored in the evolving history by authentication system 16. An invalid device key will route the authentication request message to step 226 in order to initiate the re-registration process. A valid device key will route the authentication request message directly to step 228 in order to perform the authentication processing procedure.
  • the authentication system 16 performs authentication processing based on the data representing the received device key, the request key if present, and device information i.e. the device fingerprint and the stored historical data and activity of device 12 held within the authentication system 16.
  • the authentication processing procedure determines how likely it is that the device 12 is authentic. Further examples of the authentication processing procedure are described in more detail below.
  • the authentication processing procedure may utilise tests based on: a) the received data in the authentication request message(s) representing the device key and device information, i.e. the device fingerprint and if present, the request key; and b) historical (evolving) device information and/or previously generated sequences of device and request keys related to previous requests for restricted resources made by the device 12 stored and maintained by the authentication system 16.
  • a) the received data in the authentication request message(s) representing the device key and device information i.e. the device fingerprint and if present, the request key
  • FIG. 2c there is illustrated a procedure 240 which is a continuation of the procedure 220 described in Figure 2b, which is performed by the authentication system 16 for use in authenticating the device 12 when it requests access to restricted resources from the resource system 14.
  • step 242 the authentication system 16 performs a test to determine if the indication generated by the authentication processing procedure represents an authenticated device 12. This can be implemented by comparing the indication value with a threshold or set of thresholds, which are used by the authentication system 16 to determine the authenticity of the device 12.
  • step 244 it has been determined in step 242 by authentication system 16 that the device 12 is NOT authentic.
  • the authentication system 16 stores the authentication request message including the device key, device information, i.e. the device fingerprint, the request key if present, and the indication value generated by the authentication processing procedure. This information is stored in order to establish a stored and evolving history of the requests for restricted resources made by the device 12 from the resource system 14. This information is for use in future tests or processes performed by the authentication system 16 when determining the authenticity of the device 12.
  • step 246 the authentication system 16 transmits only the indication or data representative of an indication value to the resource system 14.
  • the indication transmitted to the resource system 14 also contains data informing the resource system 14 that the device 12 should not be granted access to the restricted resources requested. Instead, this information should be interpreted by the resource system 14 to force the device 12 to re-initiate the authorisation process at the resource system 14. This will allow the device 12 to continue requesting further access to restricted resources from the resource system 14. This re-initialisation process was also briefly described with respect to figure 1 and figures 2a and 2b.
  • step 248 it has been determined in step 242 by the authentication system
  • the authentication system 16 that the device 12 is authentic.
  • the authentication system 16 then performs a test or process to determine if the authentication request message contains a request key. If a request key is present, then this indicates that the device 12 needs a replacement request key for a subsequent request. If the request key is not present, then this indicates that this is the first request for restricted resources that the device 12 has made since initialisation or re-registration.
  • step 250 the authentication system 16 has determined at step 248 that a request key is present in the authentication request message.
  • the authentication system 16 then generates a replacement request key for the device 12 to use in further requests for restricted resources from the resource system 14.
  • step 252 the authentication system 16 has determined at step 248 that a request key is not present in the authentication request message. The authentication system 16 then generates a new request key for the device 12 to use in further requests.
  • the authentication system 16 stores the authentication request message, the request key, the device key, the device information, i.e. the device fingerprint, and the indication information, in order to establish and/or maintain a stored and evolving history of the requests for restricted resources made by the device 12.
  • the authentication system 16 transmits the authentication response message to the resource system 14 in response to the original authentication request message. It is assumed that a device key or request key is unique and is transmitted by the authentication system 16 only once to the resource system 14.
  • the authentication response message transmitted will contain data representative of the indication or indication value that device 12 is authentic, and either a) data representative of the replacement request key for use in subsequent requests by the device 12 to the resource system 14, or b) data representative of a new device key and the new request key for use in subsequent requests by the device 12 to the resource system 14, or c) data representative of the replacement device key and the replacement request key for use in subsequent requests by the device 12 to the resource system 14.
  • Figure 3 illustrates an embodiment of a request for restricted resources 320 by a device 12 from the perspective of the resource system 14 using the
  • Each resource request message includes data representative of the device information, i.e. the device fingerprint, and if present a request key and a device key.
  • the resource system 14 sends this information to the authentication system 16 in order to authenticate the device 12 and to allow the resource system 14 to determine whether it should grant the device 12 access to the restricted resources.
  • the device key and request key were generated by the authentication system 16 and then communicated to the device 12 via the resource system 14.
  • the device key and request key used by the device 12 in the resource request message(s) should be the latest, i.e. the current device key and request key that the authentication system 16 has issued to the device 12. Any keys used by device 12 that are not the current key will cause the device 12 to incur a penalty during the authentication processing procedure, or even an indication that the device 12 is not authentic.
  • the resource system 14 receives a request for restricted resources from a device 12.
  • the request includes data representative of the device information, i.e. the device fingerprint, and if present, the device key and the request key which have been previously transmitted to the device 12 from the authentication system 16, and stored on the device 12.
  • the resource system 14 determines whether it needs to further authenticate the device 12 in order to grant the device 12 access.
  • the resource system 14 may not require the device 12 to be authenticated, and may simply grant access. However, if the resource system 14 determines that the device 12 should be authenticated, it transmits an authentication request message to the authentication system 16.
  • the authentication request message sent by the resource system 14 to the authentication system 16 includes data representing the device information, i.e. the device fingerprint, and if present data representing the device key and/or the request key as outlined in Figure 2b, in step 222.
  • the authentication system 16 then performs an authentication procedure or risk assessment, as previously described with respect to figures 1 , 2a to 2c and further described below.
  • the authentication system 16 determines an indication or score, of whether the device 12 is an authentic device 12.
  • the indication is contained within the authentication response message which is transmitted to the resource system 14 by the authentication system 16.
  • the authentication response message includes data representative of information relating to the authenticity of the device 12. This information is used by the resource system 14 in determining whether it should grant the device 12 access to the restricted resources or whether it should re-initiate/register the authorisation of the device 12. This has been described with reference to figures 1 to 2c.
  • the resource system 14 receives the authentication response message from the authentication system 16. It is assumed that a device key or request key is unique and is transmitted by the authentication system 16 only once to the resource system 14. As described with reference to figures 1 to 2c, the authentication response message transmitted will contain a) the indication on the authenticity of the device 12 and data representative of the replacement request key for use in subsequent requests for restricted resources from the resource system 14, or b) the indication about authenticity, and data representative of the new device key, and the new request key for use in subsequent requests for restricted resources from resource system 14, or c) the indication about authenticity, and data representative of the replacement device key, and the replacement request key for use in subsequent requests for restricted resources from resource system 14 or d) simply the indication (this may indicate that device 12 is not an authentic device).
  • the resource system 14 determines from the indication included within the authentication response message transmitted by the authentication system 16, whether to grant access to the device 12 for the restricted resources.
  • the determination of whether to grant access to the device 12 can depend on threshold values set at the resource system 14 which are compared to the indication (or an indication value) sent from the authentication system 16 to decide on resource access by the device 12.
  • the indication may simply be a data flag, e.g. '1 ' indicating an authentic device and '0' indicating a non-authentic device.
  • the resource system 14 determines whether to grant/authorise the device 12 access to the requested resources.
  • the resource system 14 has determined in step 328 that the device 12 is an authentic device 12 and that access to restricted resources can be granted.
  • the resource system 14 will then transmit data to the device 12 including either a) the replacement request key, or b) the new device key and the new request key, or c) the replacement device key and the replacement request key. It is assumed the device 12 will store the data received from the resource system 14 for use in subsequent requests for restricted resources from the resource system 14 as outlined in Figure 4.
  • step 332 the resource system 14 has determined in step 328 that the device 12 is NOT an authentic device 12, or that the device 12 is potentially compromised, so that access to restricted resources should not be granted. The resource system 14 will then force the next request from the device 12 through the authorisation or re-authorisation procedure.
  • the purpose of this step is to prevent an imposter or non-authentic device 12 that may have cloned or illicitly used the credentials of the authentic device 12 from receiving the new information such as the replacement device key and the replacement request key, or accessing the requested resources.
  • This process will enable the authentication system 16 to detect an imposter device 12 in subsequent requests for restricted resources, as the imposter device 12 would not have the expected set of dynamic data keys transmitted with its next request to the resource system 14.
  • the resource system 14 may instruct the device 12 to re-authorise with the resource system 14 and if successful, then a new device key may be sent to the device 12 for subsequent requests.
  • Figure 4 shows the procedure 420 performed on a device 12 during a request for restricted resources from the resource system 14, where the resource system 14 requests authentication of the device 12 from the authentication system 16.
  • the device 12 transmits data representing the device information, i.e. the device fingerprint, and if present, the device key and the request key to the resource system 14. As previously described, this data is ultimately used by the authentication system 16 for determining whether the device 12 is authentic.
  • the device 12 receives data relating to either a) the replacement request key for use in subsequent requests for restricted resources from the resource system 14, or b) the new device key and the new request key for use in subsequent requests, or c) the replacement device key and the replacement request key for use in subsequent requests, or d) a notification of restricted access and/or a request for re-authorisation/re-registration of the device 12 with the resource system 14 as has been described with reference to figures 1 to 3.
  • step 428 device 12 stores data representative of either: a) the replacement request key, or b) the new device key and the new request key, c) the replacement device key and the replacement request key. This data is used in subsequent requests for restricted resources from the resource system 14.
  • the authentication system 16 has stored historical device information, i.e. the device fingerprint related to device 12; it has also stored the sequence of
  • the historical device information for the device 12 is retrieved from the storage mechanism/medium (e.g. memory) for use in the tests to be performed on the authentication request message data.
  • the device 12 may transmit any data useful to uniquely identify itself to the authentication system 16 via the resource system 14, in this example the information that the device 12 transmits to the authentication system 16 via resource system 14 contains, but is not limited to, the IP address of the device 12, and/or the location of device 12 (e.g. geo-location of device 12 based on global positioning system co-ordinates or other means), and/or the type and version of the operating system of device 12.
  • other device information that can be used to identify the device 12 is also applicable.
  • the authentication system 16 receives the authentication request message from the resource system 14 in response to the request from the device 12.
  • the authentication request message includes data representing the device information of device 12, i.e. the device fingerprint, the device key and the request key.
  • the authentication system 16 On receiving the authentication request message and the data it contains, the authentication system 16 performs a test on the authentication request message data to determine or identify whether the received request key from the device 12 matches the most recent request key in the stored sequence of request keys in relation to the device 12.
  • the stored sequence of request keys is generated and maintained over time by the authentication system 16; each request key is unique, and has been issued to the device 12 via the resource system 14 as a result of a previous request for restricted resources by the device 12; a request key can only be presented once to the authentication system 16, otherwise a compromised use is detected.
  • the device 12 If the request key does NOT match the most recent request key of the request key sequence, then the device 12 is declared to be a compromised device 12 and given an unfavourable indication value or score representing a compromised device. Simply put, if the device key or request key information supplied by the resource system 14 in relation to the device 12 does not match the data expected by the authentication system 16, then the device 12 should not be considered an authentic device 12. An authentic device 12 should already have the most up-to-date device and request keys, i.e. the current set of keys stored at the authentication system 16.
  • the authentication system 16 proceeds to process 1 ) the received data representing the device information, i.e. the device fingerprint; and 2) the stored data representing the historical device information for device 12; to determine whether the device 12 is most likely the authentic device as represented by the record and historical device information stored by the authentication system 16.
  • the authentication system 16 then performs a series of tests on the received device information contained within the authentication request message data, i.e. the device fingerprint for device 12, in this example the received device information consisting of the IP address of the device 12, the location of the device 12, and the type and version of the operating system residing on the device 12.
  • the device fingerprint for device 12 in this example the received device information consisting of the IP address of the device 12, the location of the device 12, and the type and version of the operating system residing on the device 12.
  • the result of each test or determination in relation to processing the device information, device key and/or request key is given a value or a score. These scores are accumulated and/or weighted and combined to provide an indication value or an indication on the authenticity of the device 12.
  • a threshold can be set to a value that indicates that the device 12 has been compromised. The accumulated score can be compared with this threshold at the end of each test. If the accumulated score reaches and/or goes beyond the threshold then it can be determined that the device 12 is most likely compromised.
  • the authentication system 16 may choose to abort the authentication test sequence, i.e. the authentication processing, early and notify the resource system 14 that the device 12 has been compromised or is not authentic.
  • the authentication system 16 may proceed with further tests, as these might take the accumulated score away from the threshold value such that the device 12 may be considered by the authentication system 16 to NOT be
  • the first test compares the historic IP address sequence with the current IP address contained within the authentication request message. If the current IP address is not found in the historic IP address sequence, the authentication system 16 may score the resultant indication unfavourably. IP addresses may change frequently, especially for mobile devices. However, the authentication system 16 determines an indication or likelihood that the change in IP address is possible for the device 12. For example, has a new IP address simply been allocated with a different address space within the same network (dynamic IP address), or has the device 12 moved between two different networks e.g. has the device 12 roamed from a cafe to a nearby office.
  • the authentication system 16 determines the general location of the device 12 from the IP address.
  • the IP address can reveal the country the device 12 is operating in and even which town or network provider. So even if the previous and current IP addresses differ, the authentication system 16 determines whether it is possible for the device 12 to have moved between the locations identified by the different IP addresses.
  • a user of a device 12 on a previous request for restricted resources may have been in a cafe on a free Wi-Fi connection, then walked back to work and made the current request for resources using the device 12 which now is using an IP address allocated in the office. This would be acceptable. But, it would be impossible for a user of a device 12 to request content or restricted resources from a United Kingdom IP address and then make another request 20 minutes later from an Australian or Philippine IP address. This would indicate that the device 12 has been compromised, for example it has been cloned or stolen. By determining generally where the IP addresses originate from, and the passage of time between IP address changes, the authentication system 16 may be able to determine that the change in IP address is acceptable and provide a score or indication accordingly.
  • the next test compares the historic operating system of device 12 stored in authentication system 16 with the operating system details supplied in the authentication request message. If the current authentication request message's operating system configuration details for device 12 is not an exact match to that which is stored in the historic operating system configuration sequence of the device 12, the authentication system 16 will score the resultant indication unfavourably. The authentication system 16 then determines the likelihood that the change in operating system configuration details is potentially legitimate, for example if the device 12 has upgraded the operating system, such as a device 12 may upgrade from Microsoft Windows Vista to Windows 7 (trade marks). Conversely, if a mobile device 12 with a history of Apple iOS4 changed to an Android OS that would be extremely unlikely, and therefore trigger a very unfavourable score.
  • the final step within this first example of the authentication procedure is the calculation of a value or indication from the accumulated values generated by the tests. This will result in an indication value of whether the authentication system 16 considers the device 12 to be authentic.
  • a second more detailed example of the authentication processing procedure is now provided. Although the steps are described in a particular order, any variation on this order is also applicable.
  • the authentication system 16 has stored historical device information, i.e. the device fingerprint related to the device 12; it has also stored the sequence of authentication request messages generated by the resource system 14 in response to requests from the device 12.
  • the device 12 may transmit any data which may be used to uniquely identify itself to the authentication system 16 via the resource system 14, in this more detailed example the information that device 12 transmits to the authentication system 16 via the resource system 14 contains but is not limited to the device key, the request key, the device information, i.e. the device fingerprint including the IP address of the device 12 and/or the location of the device 12 (e.g. geo-location of the device 12 based on global positioning system co-ordinates or other means), and the type and version of the operating system of device 12.
  • the device key i.e. the device fingerprint including the IP address of the device 12 and/or the location of the device 12 (e.g. geo-location of the device 12 based on global positioning system co-ordinates or other means)
  • the device information i.e. the device fingerprint including the IP address of the device 12 and/or the location of the device 12 (e.g. geo-location of the device 12 based on global positioning system co-ordinates or other means), and the type and version of the operating system of device 12.
  • the device "fingerprint" On receiving the authentication request message from the resource system 14 the device "fingerprint", the device key and the request key are provided to the authentication system 16 for processing.
  • step 1 the authentication system 16 performs a test on the authentication request message data to identify whether the received device key from the device 12 matches the most recent device key issued from the
  • step 2) of the procedure the authentication system 16 performs a test as to whether the received request key from the device 12 matches the most recent request key, i.e. the current request key. If the device key or request key information supplied in relation to the device 12 does not match the data expected by the authentication system 16, then the device 12 should not be considered an authentic device 12.
  • the score may be weighted such that no matter what scores are given in other tests, the accumulated score results in the device 12 being considered as compromised. In this case, the authentication system 16 could inform the resource system 14 that device 12 is compromised.
  • the authentication system 16 processes the received data representing the device information, i.e. the device fingerprint, and the stored data representing the historical device information for device 12 to determine whether the device 12 is most likely authentic.
  • the authentication system 16 performs further tests on the data contained within the authentication request message, i.e. the device fingerprint for the device 12, such as whether the request for resources made by the device 12 is from a permitted location.
  • the authentication system 16 can compare the authentication request message location data against an historical list of permitted locations which are stored by the authentication system 16.
  • the authentication system 16 can score the test unfavourably; these unfavourable scores can also be weighted against specific values, e.g. a particular country.
  • the authentication system 16 can return a favourable score for use in determining the ultimate indication value.
  • the authentication system 16 can perform further tests on the data provided in the authentication request message, such as whether the request has been made during a permitted time of day. An authentication request message received outside of the permitted time of day will return an unfavourable score.
  • the authentication system 16 can perform other tests on the data provided in the authentication request message, such as whether the device 12 may be an automated or artificial device. For example, does the device 12 make too many requests for restricted resources in a given time interval, such that it is outside a specified parameter. For example, a device 12 that performs multiple and/or simultaneous requests for restricted resources within a defined time period will return an unfavourable score.
  • the resource system 14 may not permit an automated agent to access restricted resources in order for it to scrape or harvest the restricted resources or content, as may be used by a spider in indexing processes.
  • the authentication system 16 then performs a series of tests on the received device information contained within the authentication request message data, i.e. the device fingerprint for the device 12.
  • the received device information consists of the IP address, the location of the device 12, and the type and version of the operating system on the device 12.
  • the device information, i.e. the device fingerprint is then compared against device information from the last successful authentication request message stored at the authentication system 16. If the device information is not an exact match, the indication returned will NOT be favourable. That is, the indication value would indicate that the device 12 is most likely not authentic if the majority of the device information does not match the stored evolving history of the device information in relation to device 12.
  • the transmitted device information is not an exact match to a previous successful request for resources then the following, as example tests, can be performed:
  • Test a A comparison of the logical location history is performed to determine if the device 12 has been successfully used in this location in the past.
  • the logical location is derived from the device information, i.e. the device fingerprint.
  • An example of a logical location would be the Internet Protocol address (the IP address) provided by a device 12 communicating over the internet.
  • Test b) Compare physical locations of the device 12 using geo-location to decide if the device information, i.e. the device fingerprint data from the new location is physically possible for the device 12 to make.
  • An example of a physical location comparison would be the city detected from the device information, i.e. the fingerprint, taking into account the time taken to travel from one city to another. For example, if the device 12 requests restricted resources from the resource system 14 and is detected as coming from London UK at 08:00 and then the next request is detected as coming from wholesome Aires Brazil at 08:05, the authentication system 16 can determine that the requests did not originate from the same device 12. As such, the indication returned would be unfavourable or a value indicating that the device 12 is compromised and is most likely not authentic.
  • Test c Compare software details to historic and previous successful requests stored on authentication system 16 to determine if the software is potentially similar.
  • Comparisons are made based on the software (operating system etc.) installed on the device 12 and/or software versions of the software on the device 12.
  • the authentication system 16 will score the difference accordingly, i.e. a completely different operating system might be scored unfavourably, whereas a closely similar operating system, such as an upgraded version, would score more favourably.
  • step 7) of the procedure the authentication system 16 performs a calculation based on the tests performed in steps above 1 ) to 6).
  • the calculation can be performed by weighting/scoring the output for each of the above steps and accumulating the weighted outputs to result in an indication value representing the likelihood that the device 12 represented in the authentication request message relates to an authentic device 12.
  • the indication value is then used by the authentication system 16 and the resource system 14 as described with reference to figures 1 to 4.
  • the authentication system 16 so far described is an intrinsic part of a continuous dynamic authentication and validation system for securing access to restricted resources over a communications network.
  • the authentication system 16 provides a continuously updated authentication and validation system for monitoring and policing requests for restricted resources by a device 12 from the resource system 14.
  • the authentication system 16 By performing a series of checks and tests on a combination of data and information relating to the device 12, and data generated and stored over time by the authentication system 16 including but not limited to dynamically generated keys which are transmitted back to device 12 via the resource system 14, the
  • authentication system 16 can determine whether the device 12 is authentic, or whether device 12 might be cloned or compromised. This enables the resource system 14 to control access to restricted resources at a granular level, i.e. to the specific device 12 and/or the specific restricted resource being requested.
  • the resource can be made the subject of a set of controls, tests and/or conditions that need to be met in order for the resource to be accessed.
  • the authentication system 16 can have these controls and conditions set to authenticate and run match sequences against a range of factors available from the requesting device 12 or the resource system 14, such as geo- location positioning and historic IP address monitoring (e.g. determining if it is possible for the device 12 to make a request from multiple different locations over a set period of time), operating system changes and version changes, etc.
  • the authentication system 16 can perform the authentication and validation control as often or as infrequently as the resource system 14 requires, doing so only when requested to do so by the resource system 14. This may be for every resource such as a document, link or web page requested by the device 12, or alternatively for every 10 requests for restricted resources, or every 10 documents, links or web pages requested by the device 12, or even in terms of actual time elapsed.
  • the authentication system 16 can use a combination of unique identifiers generated by the authentication system 16 and stored both on the device 12 and in the authentication system 16, together with system information accessible or obtainable from the device 12. This information forms a dynamic set of continuously updated and evolving device history that creates an identity record that is intended to be unique to a specific device 12.
  • This device history contains data keys dynamically generated and stored by the authentication system 16 which act as a unique, random password that can be updated as often as is required, and which can be used automatically alongside the simple credentials such as login credentials (username and password) of the device 12. Other than storing the transmitted data keys, the device 12 does not need to become involved in the identity authentication or validation process.
  • the device 12 When requesting restricted resources from a resource system 14, the device
  • the authentication request message flows through the authentication system
  • authentication system 16 which performs a series of tests on the information contained within the authentication request message, including information such as the device on record, or the geo-location. Many of these tests can be fine-tuned using a set of controls or thresholds giving authentication system 16 the ability to choose how to deal with a specific range of scores or messages.
  • the thresholds and settings can be tuned for use against specific users and/or devices. For example, this may allow a desirable bot such as the Google spider access to specific content, but deny access to unauthorised or restricted content.
  • the authentication system 16 would be able to assist the resource system 14 in determining whether to prevent an unauthorised scraping agent or bot entering a resource system 14 (for example, a content provider's website or "App") and attempting to copy the restricted resources or content.
  • resource system 14 may have been described, for simplicity, with reference to a single processing system/database such as a server, it is to be appreciated that the resource system 14 could be a centralised processing system such as a data centre or data warehouse with multiple servers etc., or it may correspond to a de-centralised/distributed processing system such that it is spread across multiple servers or data centres/data warehouses in multiple regions, or even any computing system or combination of computing systems.
  • the authentication system 16 is described as a single processing system or entity, or as a centralised processing system such as a server, it is to be appreciated that the authentication system 16 could be a centralised processing system such as a data centre with multiple servers etc., or it may correspond to a de- centralised/distributed processing system such that it is spread across multiple servers, or multiple data centres, or over in multiple regions/countries, or even any computing system or combination of computing systems.
  • Suitable programming means can include any means for directing a computer system to execute the steps of the method of the invention. This can include, for example, systems comprised of processing units and arithmetic-logic circuits coupled to a computer memory or computer readable medium such that the computer memory includes stored data and/or program instructions, which when executed on the processing units, performs steps of the method, tests, procedures or processes of the invention.
  • the methods, tests, procedures or processes of the invention can be embodied in a computer program product or computer readable medium, such as a diskette or other recording medium, for use with any suitable data processing system, such that the computer program product includes software or program code or instructions, which when executed on a processor, performs the steps of the methods, tests, procedures or processes of the invention or as described herein.
  • the authentication system 16 has been described for simplicity as having two dynamic data keys, namely a device key which is used to identify a specific device 12, and a request key, which is used for creating a historical sequence of resource requests by the authentication system 16.
  • a device key which is used to identify a specific device 12
  • a request key which is used for creating a historical sequence of resource requests by the authentication system 16.
  • the system could be
  • a single dynamic data key may involve the authentication system 16 generating and storing a single dynamic data key for each request for restricted resources, as opposed to two or more dynamic data keys.
  • This single dynamic data key may represent both the identity of the device 12 and the request number.
  • the single dynamic key is issued to device 12 via resource system 14.
  • the single dynamic data key could contain portions of information which are used to identify both the device 12 and each request for restricted resources. If it represents the identity of device 12, then the authentication system 16 may need to store this identity so that it can keep track of an authentic device's device key and quickly locate the stored historical information related to the authentic device.
  • authentication system 16 either in part, (e.g. specific portions of the key data), or as a whole, to identify the device 12, the resource request and/or any other piece of additional information or resources that may be included within a request for restricted resources.
  • the multiple dynamic data keys may be issued and/or transmitted to device 12 simultaneously, or one at a time etc. This adds a further layer of security when Device 12 requests restricted resources because device 12 should transmit the pertinent dynamic data keys (possibly simultaneously or in a particular order or sequence etc.) when it requests access to restricted resources from resource system 14.
  • the authentication system 16 would expect to receive the pertinent dynamic data keys transmitted from the device 12, otherwise it will determine that the device 12 may be compromised.
  • a further implementation of a system as outlined above could use multiple dynamic data keys containing data used to identify the device 12 and/or the specific request for restricted resources and be encrypted to prevent tampering by un- authentic devices 12.
  • the authentication system 16 has been described as generating or regenerating the data representing the one or more dynamic key(s) such as the device key and a request key. It is to be appreciated that the data representing the dynamic key(s) or each portion of the dynamic key(s) can be generated or regenerated using a pseudo-random number generator, or even selected from a sequence of numbers determined by the authentication system 16.
  • the authentication system 16 may also generate or derive each dynamic key or portions of the dynamic key based on using globally unique identifiers (GUIDs) or universally unique identifiers (UUIDs). These are unique reference numbers that can be used as an identifier. The number of unique GUIDs is so large that the probability of the same number being generated twice is extremely small, which is very useful for use in determining portions of the dynamic key(s) e.g. the device key and the request key data portions may be generated based on different portions of the same GUID or based on different GUIDs.
  • GUIDs globally unique identifiers
  • UUIDs universally unique identifiers
  • the present invention does not involve distribution of an authentication token (of the type which is taken to authenticate a client's entitlement to access the resources).
  • Information which is sent back to the resource system 14 and hence back to the device 12 for use in subsequent requests does not contain any identifying information or time stamps (as such items may be intercepted and subsequently manipulated to gain illegitimate access).
  • the present invention operates on the assumption that the device 12 may not be authentic on each occasion that it makes a request from the resource system 14, so the authenticity must be proved on each occasion that the device 12 seeks access. This is achieved by confirming the identity of the device 12 through keys and through fingerprinting of the device 12, taking into account expected changes; and sending on the resulting indication to the resource system 14.
  • the present invention is particularly suited to use with devices 12 which are mobile, such as mobile phones, and as explained above can accommodate changes in location of the device 12, and updates of its operating system.

Abstract

An authentication system (16) and a method suitable for indicating that a device (12) requesting access to restricted resources from a resource system (14) is authentic. The authentication system (16) and method include receiving an authentication request from the resource system (14), the authentication request including data representative of a dynamic key transmitted by the device (12), determining an indication that the device (12) corresponds to an authentic device based on the received dynamic key and stored historical information in relation to the authentic device, where the stored historical information includes one or more previously generated dynamic keys in relation to the authentic device, and transmitting the indication that the device (12) is the authentic device to the resource system (14) for use by the resource system (14) in determining whether to provide access to the device (12) for the requested resources.

Description

AN AUTHENTICATION SYSTEM
The present invention relates to an authentication method, apparatus, and system for authenticating and validating access by devices over a communications network to resources relating to digital content and/or other information such as restricted resources accessible over a communications network.
INTRODUCTION Conventional access to restricted resources such as digital content, information resources, transactions, and/or computing resources usually require authorised users or machines to undergo an authorisation procedure. This may be a simple username/password challenge, a 2 factor authentication, a hardware security token, identification card or other method.
The term 'Restricted resources' refers to resources including any information such as digital content or information in digital form including text, data, sound recordings, photographs and images, motion pictures, software, digital documents and/or files, information resources, transactions, and/or other computing resources that are protected from unauthorised access.
For example, the login credentials, username and password, are entered by the user when first logging-in to a computer system or server (also known as a resource server) providing access to restricted resources or content. This type of authorisation is commonly used for access to many types of stand-alone computer terminals, personal devices, closed systems such as intranets, libraries, or secure database facilities and the like, but where the authorised user is usually physically present.
This type of authorisation has now also been adapted for systems where users have remote access to the restricted resources over a communications network, e.g. a wireless network or the internet. It is also common for resource providers or servers to allocate authorisation credentials to users, so they may gain access to the restricted resources. Examples of such resource providers are libraries, information repositories, and even online publishers like the IEEE Online Journal and other scientific journals or The Financial Times and other news providers that provide access to restricted resources such as journal and news articles.
It is primarily the combination of user name and password that is relied upon by resource servers to authorise and authenticate users and devices in order to grant access to restricted resources. However, unauthorised access to restricted resources and/or content can be achieved if users share their login name and passwords with each other. More importantly though, with identity fraud becoming more common and with the increasing popularity of the "everywhere" and "anywhere" style of communication (e.g. mobile communications, telecommuting, or cloud computing), login credentials can also be stolen or phished by an eavesdropper over the communications network. For example, cheap/free unsecure public Wi-Fi hot spots in cafes are a prime location for login credentials to be stolen or phished and then used by an eavesdropper to gain unauthorised access to restricted resources, systems, documents, and/or content.
The protection typically employed by resource and content management systems is username and password. There is no protection against multiple or simultaneous abuse and use of authenticated login credentials and no system for monitoring such illicit activity. This can give un-metered and/or un-policed access to restricted resources for anyone having access to "legitimate" login credentials, e.g. a user name and password, or authenticated tokens contained within transmitted cookies or session identifiers.
The object of the present invention is to provide an additional layer of authentication and validation for resource servers/systems/providers to overcome the issues associated with rapidly ensuring authentic users or devices have access to restricted resources over a communications network, e.g. such as the internet or a wireless mobile network. That is, to prevent abuse of authentic login credentials when a device accesses restricted content or resources.
SUMMARY OF THE INVENTION
Thus the present invention can be summarised as: A continuous dynamic authentication and validation system for securing device access to resources and/or restricted resources over a communications network.
According to a first aspect of the present invention there is provided a method and apparatus for an authentication system to provide an indication that a device requesting access to restricted resources from a resource system is authentic.
The method includes receiving an authentication request from a resource system, the authentication request including data representative of a dynamic key transmitted by the device, determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information in relation to the authentic device, wherein the stored historical information includes one or more previously generated dynamic keys in relation to the authentic device, and transmitting the indication that the device is the authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
The apparatus includes a receiver unit for receiving an authentication request from the resource system, the authentication request including data representative of a dynamic key transmitted by the device, a processing unit for determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information corresponding to previously generated dynamic keys in relation to the device, and a transmitter unit for transmitting the indication of the likelihood that the device is an authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
Preferably, the data representing a dynamic key includes a first portion of data generated by the authentication system that is representative of a device key or the identity of the device, and a second portion of data generated by the
authentication system that is representative of a request key for use by the device when making a subsequent request for restricted resources. This provides the advantage that the device must present the most up-to-date dynamic key data to the authentication system that relates to the device's identity but also to the current issued request. Preferably, generating the further dynamic key comprises:
a) regenerating the second portion of data if the device is determined to be the authentic device; or
b) generating the first portion of data and generating the second portion of data if it is determined that the device is requesting resources for the first time; or
c) regenerating the first portion of data and regenerating the second portion of data if it is determined that the device is compromised.
Preferably, the step of determining the indication or indication value includes determining whether the received dynamic key corresponds with a dynamic key generated by the authentication system in response to the previous authentication request message in relation to the authentic device. As the dynamic key(s) are generated by the authentication system, the authentication system can rapidly determine whether the device is an authentic device by comparing the received dynamic key(s) with those previously generated for the authentic device. Preferably, the authentication request further includes data representative of device information related to the identity of the device and the stored historical information further includes data representative of device information related to the identity of the authentic device. The device information, or combinations of it, becomes in effect the device's "fingerprint" and should be relatively unique to each device. This provides an extra layer of security to the resource and authentication systems. The device information can take any characteristic, or combination of characteristics, of the device that substantially uniquely identifies the device. Preferably, determining the indication further comprises accumulating one or more scores based on the similarity of portions of the received device information with corresponding portions of stored historical device information of the authentic device. This provides the advantage that a decision can be made as to whether the device is most likely an authentic device, despite some changes in the device information. The device information of an authentic device can change over time, and these changes can be monitored and stored by the authentication system, while still allowing the device to be authenticated without requiring re-registration.
Other aspects of the invention provide computer readable media including program instructions stored thereon, which when executed on at least one processor of an authentication system or resource system, perform the methods, processes, and/or procedures as described herein.
The invention will now be further and more particularly described by way of example only and with reference to the accompanying drawings, in which:
Figure 1 illustrates a communications system 10 for controlling access of a device 12 to restricted resources from a resource system 14 via an authentication system 16; Figure 2a illustrates an embodiment of an initialisation, registration or re-registration procedure of device 12 that is performed on the authentication system 16 of figure 1 ; Figure 2b illustrates an embodiment of the authentication process for authenticating a device 12 performed at the authentication system 16 of figure 1 for providing an indication of an authentic device following a request for restricted resources from the resource system 14;
Figure 2c illustrates a continuation of the embodiment of the authentication process initiated in Figure 2b performed at the authentication system 16;
Figure 3 illustrates an embodiment of an access grant process performed by the resource system 14 of figure 1 when a device 12 makes a request for restricted resources; and Figure 4 illustrates an embodiment of a process performed on a device 12 of Figure 1 for requesting restricted resources from the resource system 14.
DETAILED DESCRIPTION
Referring to Figure 1 , a communications system 10 is illustrated for controlling access for at least one device 12 to restricted resources from a resource system 14. The communications system 10 includes one or more devices 12 in communication over a communications network with the one or more resource systems 14, and an authentication system 16. Using resource systems 14 and authentication system 16 the communication system 10 performs a continuous dynamic authentication and validation of each of the devices 12, allowing the devices 12 to secure access to restricted resources over corresponding communications network(s).
It is assumed that a device 12 has at least one or more of the following capabilities:
1 . Communicate with resource system 14 using agreed protocols over a communications link.
2. Transmit messages that contain the resource requested and device hardware and software information to resource system 14.
3. A way to store persistent data returned from resource system 14.
It is assumed that a resource system 14 has at least one or more of the following capabilities:
1 . Communicate with the device 12 using agreed protocols over a
communication link.
2. Communicate with the authentication system 16 using agreed protocols over a communication link.
3. Receive a request for restricted resources from the device 12.
4. Ability to authorise the device 12 for access to restricted resources.
5. Forward information contained in the request for restricted resources from the device 12 onto the authentication system 16.
6. Submit a request for authentication to the authentication system 16.
7. Receive the authentication response message returned from the
authentication system 16.
8. Decide how to respond to the device 12 by intelligently interpreting the indication or score contained within the authentication response message from the authentication system 16. 9. Respond to the request from the device 12 for restricted resources, after interpreting the authentication response message sent from the authentication system 16.
10. Ability to deliver restricted resources to the device 12.
1 1 . Ability to deliver data that should be stored and persisted by the device 12.
It is assumed that an authentication system 16 has at least one or more of the following capabilities:
1 . Communicate with a resource system 14 using agreed protocols over a communication link.
2. Persist the authentication request message to a data storage mechanism.
3. Persist information about the device 12 to a data storage mechanism.
4. Process the authentication request message and return an indication of the authenticity of the device 12.
5. Return the indication to the resource system 14 as part of the authentication response message.
In operation, the device 12 transmits one or more resource request message(s) to the resource system 14. The message(s) include(s) data representing a request for a restricted resource(s), identifying information or device information of the device 12, and if present data representative of one or more dynamic data key(s) generated and previously provided to the device 12 by the authentication system 16 via resource system 14. The dynamic data key(s) are used by the authentication system 16 to identify whether the device 12 is authentic and determine that the request for the restricted resources has not been usurped or sent by an
eavesdropper.
On receiving the resource request message(s) from device 12, the resource system 14 transmits an authentication request message(s) to the authentication system 16. The authentication request message(s) include(s) the dynamic data key(s) if present and/or the identifying information of the device 12.
On receiving the authentication request message(s), the authentication system 16 performs a risk assessment by determining the risk that the device 12 that is requesting access to the restricted resources is authentic. The risk assessment is determined from, but is not limited to, a) the dynamic data key(s), b) the identifying device information, and/or c) a stored and evolving history of the device 12 that is related to accessing the restricted resources from the resource system 14. The risk assessment or indication is then transmitted to the resource system 14 to enable it to determine whether the device 12 should have access to the restricted resources. It is to be appreciated that the risk assessment can be determined from at least the dynamic data key(s) and/or a stored and evolving history of the dynamic data key(s) generated by the authentication system 16 in relation to device 12. The dynamic data keys are generated and stored by the authentication system 16. This allows the authentication system 16 to control and track the sequence of requests for restricted resources made by the device 12. The authentication system 16 transmits one or more of the dynamic data key(s) to device 12 via the resource system 14. The authentication system 16 controls the generation of the dynamic data key(s) and when necessary it regenerates one or more of the dynamic data key(s) as a replacement for a previously generated data key in order to establish and maintain a stored and evolving history relating to the identity and activity of device 12 which is used by the authentication system 16 in its calculations for generating an indication of the authenticity of a device 12.
Regenerating and replacing/storing the dynamic data key(s) allows the authentication system 16 to monitor a sequence of requests for restricted resources made by the device 12. The replacement dynamic data key(s) are transmitted back to the device 12 from authentication system 16 via resource system 14 for use by the device 12 in subsequent requests for restricted resources from the resource system 14.
In this example, there are two dynamic data keys, a device key that is used to identify the device 12 and a request key that is used to identify a legitimate request for restricted resources within a sequence of requests for the restricted resources. Alternatively, it is to be appreciated that there could be one or more dynamic data key(s) that could be used to identify the device 12 and the request for the restricted resource(s). In the current example, the device key uniquely identifies a registered device
12 against the stored history of device 12 accessing restricted resources from resource system 14. If the device key does not match the expected device key for a device 12, the authentication system 16 can immediately detect that the device 12 may not be legitimate and that the authentication credentials and/or other information of the device 12 may have been usurped and/or compromised. This will affect the risk assessment of the device 12 by the authentication system 16.
If the device 12 does not send the dynamic request key that is within the sequence of request messages expected by the authentication system 16, the authentication system 16 can immediately detect that the device 12 might not be legitimate or that the authorisation credentials of the device 12 and/or other information has been usurped and/or compromised. This will also affect the risk assessment of the device 12 by the authentication system 16. Although the authentication system 16 could simply make a risk assessment based only on the dynamic data key(s) within a sequence of request messages, it is to be appreciated that further tests can be applied in the risk assessment made by the authentication system 16. In this example, if the device 12 does transmit the required dynamic data key(s) in the sequence that is expected, the authentication system 16 continues to perform a risk assessment of device 12 based on other data sent to the
authentication system 16 and which is stored in relation to the device 12. In particular, the risk assessment is applied to the data representing the identifying information or device information of device 12. The device 12 also transmits this information to the authentication system 16 in addition to the dynamic data keys via the resource system 14.
The identifying information or device information of the device 12 is based on information such as, but not limited to, the software/hardware set-up of device 12, for example, an IP address of device 12, a serial number of device 12, and/or a media access control address of a network interface of device 12, and/or a SIM card serial number of device 12, and/or the type of operating system used by device 12, and/or information representative of the hardware/software configuration of device 12, and/or the date and time of the request of device 12, and/or the location of device 12 etc., or any other information that can be used to identify device 12.
This information, or combinations of it, becomes in effect the fingerprint of the device 12, which should be distinctive for each device, and relatively unique. This information can change over time (e.g. the IP address changes when a device 12 connects to the internet at home or in a cafe) and is useful to the authentication system 16 to determine whether the device 12 is authentic or not. This depends on how much change occurs in the device information of a device 12 between each request for restricted resources that the device 12 requests from the resource system 14.
Each time the device 12 requests access to restricted resources, in addition to the dynamic data key(s) sent by the device 12, the device 12 also sends information relating to the device, i.e. the device "fingerprint" via the resource system 14. This allows the authentication system 16 to perform a series of tests on the current authentication request message's device information and the stored historical device information that the authentication system 16 has accumulated over time. The historical device information stored by the authentication system 16 is based on the device information of the device 12 that was initially submitted to the authentication system 16 and previous requests for restricted resources made by the device 12 from the resource system 14. In the requests for resources, the device information is transmitted to the resource system 14 from the device 12. This information is also transmitted from the resource system 14 to the authentication system 16 for storage and later use in authenticating the device 12.
The 'current' device information of the device 12 is the current device information contained within the resource request message which is sent from the device 12 to the resource system 14 when requesting restricted resources, and which is further transmitted to the authentication system 16 as part of the
authentication request message. This is stored by the authentication system 16 and used in its risk assessment tests and calculations.
The authentication system 16 then performs a risk assessment consisting of a series of tests and calculations which use data including, but not limited to the current device information, the stored and evolving historical device information of device 12, the device key, and the request key (if either or both are present) to determine an indication representing the likelihood that device 12 is authentic.
Each test in this group of risk assessment tests outputs a value. The value may take into account both the importance of the test (in comparison to the other tests) and the result of the test used to determine the likelihood that the device 12 is authentic. After the required tests are complete, the values are then accumulated and/or weighted to give an overall indication of whether the device 12 is authentic. If the test indication indicates that device 12 is NOT authentic, the
authentication system 16 will invalidate the device key and request key, and store this invalidation event. In the case of subsequent attempts to use these invalid data keys, the attempts are logged against the activity record of the device 12 as part of a stored and evolving historical device information of device 12, to assist in identifying future attempts from un-authentic devices 12.
This indication of authenticity is transmitted from the authentication system 16 to the resource system 14. On receiving the risk assessment/indication, the resource system 14 decides whether to allow the device 12 access to the restricted resources. Should the risk assessment require the resource system 14 to restrict access to restricted resources for device 12, the device 12 may be told to undergo a re-authorisation or re-registration procedure at the resource system 14 in order to continue accessing the restricted resources provided by the resource system 14. This helps to ensure future requests for restricted resources are only made by authentic or legitimate devices 12.
For example, the re-authorisation process performed at the resource system 14 may use one or more methods of identity validation. These may include (but are not limited to):
a) A username & pass-phrase challenge over a network connection.
b) A telephone conversation with an automated agent.
c) A telephone conversation with a human agent.
d) An SMS message transmitted to the mobile telephone number registered to the user.
e) The use of a third party validation system or service.
f) A message transmitted to a registered address via a network requiring verification by following an embedded hyperlink.
g) A security token (or sometimes a hardware token, hard token, authentication token, USB token, cryptographic token, or key fob) may be a physical device that an authorized user of computer services is given to enable authentication.
For example, the authentication system 16 can perform or execute a set or series of tests or rules based on the information provided in the fingerprint of the device 12 and the historical device information stored by the authentication system 16.
Each test or rule may output a score or value that is then accumulated and/or weighted to provide an overall value representing an indication of the risk that the device 12 is not authentic. The indication of risk is transmitted to the resource system 14, which uses it to determine whether or not access to the restricted resource is given to device 12.
To do this, the resource system 14 may compare the indication of risk value with one or more threshold level(s). If the indication of risk is beyond a certain threshold, then the request for the restricted resource(s) may be denied and/or the device 12 may be required to obtain re-authorisation from the resource system 14. There may be more than one threshold that provides varying levels of service/access to the device 12, e.g. further restricted access, requesting additional authorisation or unique information (e.g. a unique phrase) from device 12, or simply denial of the restricted resource(s) and the requirement of device 12 to re-initialise its authorisation and authentication with resource system 14 and authentication system 16, respectively.
In addition to the indication calculated by the authentication system 16, the authentication system 16 also decides whether to (re)generate and replace one or more of the dynamic data keys for use by the device 12 in subsequent requests for further restricted resources from the resource system 14. This also allows the authentication system 16 to monitor the sequence of requests made by a device 12 and rapidly identify other unauthorised or unauthenticated devices 12 accessing the restricted resources of resource system 14.
The decision to generate further dynamic data keys may depend on one or more indication thresholds set within the Authentication System 16. For example, if the indication of risk falls beyond a certain indication threshold, then the
authentication system 16 may not generate a replacement dynamic request key, thus forcing the device 12 to break the sequence of requests and ensuring that the device 12 will need to at least re-authorise with the resource system 14 or have its authorisation credentials, sequence or requests, and other identifying information (e.g. the device information) rechecked and/or re-initialised.
The initialisation process or registration process to allow device 12 to get access to restricted resources from resource system 14 will now be described.
The initialisation process occurs on the authentication system 16 and is triggered by a request for restricted resources by a device 12 from the resource system 14. The initialisation occurs when the authentication system 16 detects either:
a) a missing device key and missing request key, or
b) the device key has recently been invalidated on a previous request and a replacement device key has not yet been issued to the device 12.
For example, when a device 12 subscribes to or becomes a member of a resource system 14 such as a journal or news publisher via their website, the device 12 typically uses login credentials such as an email and/or user name and password and the website creates a user account providing permissions on the articles and/or resources they can access etc. When the device 12 attempts to access the resources defined as restricted by resource system 14, the resource system 14 will pass on the device information, i.e. the fingerprint of the device, and further data which might include user account information, along with the request for authentication, to authentication system 16. The request for authentication may also contain data relating to one or more previously generated dynamic data keys.
Upon receipt of the authentication request message from the resource system 14, the authentication system 16 will then perform the initialisation process in order to begin or continue tracking the behaviour and activity of the device 12 with respect to its requests for restricted resources from the resource system 14. The authentication system 16 may then generate and store one or more dynamic keys that are then associated with the device information of the device 12. These dynamic data keys are stored on the authentication system 16 and then transmitted back to the device 12 via the resource system 14 for use in subsequent requests for restricted resources. This begins the monitoring by the authentication system 16 of the sequence of requests by the device 12 for restricted resources from the resource system 14.
Referring to Figure 2a, there is illustrated an embodiment of an
initialisation/registration and/or re-registration process 200 that is performed by the authentication system 16 to allow monitoring and risk assessment of a device 12 when it requests access to restricted resources from resource system 14.
In step 202, the authentication system 16 determines, from information it has received as described below with reference to Figure 2b, whether it should register or re-register the device 12. The data representing the device information for the device 12 is transmitted in one or more authentication request message(s) from the resource system 14 to the authentication system 16.
In step 204, the authentication system 16 checks for the existence of a device key relating to the device 12 in the authentication request message transmitted by the resource system 14 to the authentication system 16.
In step 206, the authentication system 16 detects that there is no device key in the authentication request message, and generates data representing a dynamic device key which is used to identify the device 12 in subsequent requests for restricted resources, and to assist in identifying subsequent requests for restricted resources that the device 12 makes from the resource system 14.
In step 208, the authentication system 16 stores data representing the device key for the device 12, in addition to the device information, i.e. the device fingerprint, to establish a stored and evolving history for use in future requests for restricted resources from the resource system 14. In step 210, the authentication system 16 detects the existence of a device key that has been invalidated, and, in response, generates a replacement device key, which is used to identify the device 12 in subsequent requests and to assist in identifying subsequent requests that the device 12 makes from the resource system 14.
In step 212, the authentication system 16 stores the invalidated device key as a new entry in a device key blacklist. The device key blacklist is a list of previously generated and invalidated device keys relating to a device 12 that have been identified by the authentication system 16 as having been compromised. During the authentication processing procedure, any device key found to exist on the device blacklist will immediately return an unfavourable indication to the resource system 14. In step 214 the authentication system 16 stores data representative of the new replacement device key, including the device information, i.e. the device fingerprint, as part of the evolving history of the device 12 and which is used in determining the authenticity of device 12 in future requests. In step 216 the authentication system 16 transmits the new or replacement device key to the authentication system 16 for further internal use, e.g.
authentication processing, which once complete will be transmitted back to the device 12 via the resource system 14 for use by the device 12 in subsequent requests for restricted resources from the resource system 14.
Referring to Figure 2b, there is illustrated an embodiment of a procedure 220 that is performed at the authentication system 16 for use in authenticating the device 12 when it requests access to restricted resources from the resource system 14. In this embodiment, for each device 12, the authentication system 16 generates and associates data representative of two dynamic keys, a device key and a request key. These keys are transmitted from the authentication system 16 to the device 12 via the resource system 14 for use in subsequent requests for access to restricted resources from the resource system 14.
It is assumed that the device 12 has already registered with resource system 14 and that the authentication system 16 may already have, or has just begun, a historical account or an evolving history of the device keys, request keys, and the device information, i.e. the device fingerprint, of the device 12. The evolving history may also include other identifying information of the device 12 as previously described with reference to figure 1 .
The historical device information, i.e. the historical device fingerprint, is stored and maintained by the authentication system 16 and is updated each time the authentication system 16 receives further device information related to the device 12 from the resource system 14.
For the purposes of this illustration, it is also assumed that the device 12 is the legitimate authentic device 12 and that it has received data representing a current set of dynamically generated data keys, i.e. at least a device key and/or a request key, from the authentication system 16.
The device key is used by the authentication system 16 to rapidly identify the device 12 and its associated historical device information and/or associated activity. The request key is used by the authentication system 16 to monitor or track a sequence of requests for restricted resources made by device 12 to the resource system 14. In step 222, the authentication system 16 receives one or more
authentication request message(s) from the resource system 14 in relation to the device 12. The authentication request message is sent in response to the resource system 14 receiving a resource request for restricted resources from the device 12. Each authentication request message includes, but is not limited to, data
representing the device information, i.e. the device fingerprint, and if the device 12 has made previous requests for restricted resources from the resource system 14, the device key and the request key. The authentication system 16 keeps track of the requests for restricted resources made by the device 12 from the resource system 14 in order to create and/or maintain a stored and evolving history of resource requests made by device 12.
In step 224, the authentication system 16 checks the authentication request message for the existence of a device key. In step 226, it is assumed that the device 12 is either an unregistered device
12 or a device 12 that has had its device key invalidated. The authentication system 16 then initiates the registration or re-registration process as outlined in figure 2a, in order to register or re-register device 12. In step 230, it is assumed that the device key exists. The authentication system 16 determines if the device key has been invalidated, either previously by authentication system 16, or whether it matches the expected device key in a sequence of device keys previously generated and stored in the evolving history by authentication system 16. An invalid device key will route the authentication request message to step 226 in order to initiate the re-registration process. A valid device key will route the authentication request message directly to step 228 in order to perform the authentication processing procedure. In step 228, the authentication system 16 performs authentication processing based on the data representing the received device key, the request key if present, and device information i.e. the device fingerprint and the stored historical data and activity of device 12 held within the authentication system 16. The authentication processing procedure determines how likely it is that the device 12 is authentic. Further examples of the authentication processing procedure are described in more detail below.
The authentication processing procedure may utilise tests based on: a) the received data in the authentication request message(s) representing the device key and device information, i.e. the device fingerprint and if present, the request key; and b) historical (evolving) device information and/or previously generated sequences of device and request keys related to previous requests for restricted resources made by the device 12 stored and maintained by the authentication system 16. Although examples of authentication processing performed by authentication system 16 are described with respect to figures 1 to 4, it is to be appreciated that there are myriad ways in which the authentication system 16 can process the authentication request message data for determining an indication that the device 12 is an authentic device 12 or that device 12 is authorised by resource system 14 to access restricted resources.
Referring to Figure 2c, there is illustrated a procedure 240 which is a continuation of the procedure 220 described in Figure 2b, which is performed by the authentication system 16 for use in authenticating the device 12 when it requests access to restricted resources from the resource system 14.
In step 242, the authentication system 16 performs a test to determine if the indication generated by the authentication processing procedure represents an authenticated device 12. This can be implemented by comparing the indication value with a threshold or set of thresholds, which are used by the authentication system 16 to determine the authenticity of the device 12.
In step 244, it has been determined in step 242 by authentication system 16 that the device 12 is NOT authentic. The authentication system 16 stores the authentication request message including the device key, device information, i.e. the device fingerprint, the request key if present, and the indication value generated by the authentication processing procedure. This information is stored in order to establish a stored and evolving history of the requests for restricted resources made by the device 12 from the resource system 14. This information is for use in future tests or processes performed by the authentication system 16 when determining the authenticity of the device 12.
In step 246, the authentication system 16 transmits only the indication or data representative of an indication value to the resource system 14. At this point, as the device 12 has been determined NOT to be an authentic device 12, the indication transmitted to the resource system 14 also contains data informing the resource system 14 that the device 12 should not be granted access to the restricted resources requested. Instead, this information should be interpreted by the resource system 14 to force the device 12 to re-initiate the authorisation process at the resource system 14. This will allow the device 12 to continue requesting further access to restricted resources from the resource system 14. This re-initialisation process was also briefly described with respect to figure 1 and figures 2a and 2b. In step 248, it has been determined in step 242 by the authentication system
16 that the device 12 is authentic. The authentication system 16 then performs a test or process to determine if the authentication request message contains a request key. If a request key is present, then this indicates that the device 12 needs a replacement request key for a subsequent request. If the request key is not present, then this indicates that this is the first request for restricted resources that the device 12 has made since initialisation or re-registration.
In step 250, the authentication system 16 has determined at step 248 that a request key is present in the authentication request message. The authentication system 16 then generates a replacement request key for the device 12 to use in further requests for restricted resources from the resource system 14.
In step 252, the authentication system 16 has determined at step 248 that a request key is not present in the authentication request message. The authentication system 16 then generates a new request key for the device 12 to use in further requests.
In step 254, the authentication system 16 stores the authentication request message, the request key, the device key, the device information, i.e. the device fingerprint, and the indication information, in order to establish and/or maintain a stored and evolving history of the requests for restricted resources made by the device 12. In step 256, the authentication system 16 transmits the authentication response message to the resource system 14 in response to the original authentication request message. It is assumed that a device key or request key is unique and is transmitted by the authentication system 16 only once to the resource system 14. The authentication response message transmitted will contain data representative of the indication or indication value that device 12 is authentic, and either a) data representative of the replacement request key for use in subsequent requests by the device 12 to the resource system 14, or b) data representative of a new device key and the new request key for use in subsequent requests by the device 12 to the resource system 14, or c) data representative of the replacement device key and the replacement request key for use in subsequent requests by the device 12 to the resource system 14.
Figure 3 illustrates an embodiment of a request for restricted resources 320 by a device 12 from the perspective of the resource system 14 using the
authentication system 16.
When the device 12 requests access to restricted resources from the resource system 14 it will send one or more resource request messages for the restricted resources to the resource system 14. Each resource request message includes data representative of the device information, i.e. the device fingerprint, and if present a request key and a device key. The resource system 14 sends this information to the authentication system 16 in order to authenticate the device 12 and to allow the resource system 14 to determine whether it should grant the device 12 access to the restricted resources.
As has been previously described with respect to figures 1 , 2a to 2c, if present, the device key and request key were generated by the authentication system 16 and then communicated to the device 12 via the resource system 14. The device key and request key used by the device 12 in the resource request message(s) should be the latest, i.e. the current device key and request key that the authentication system 16 has issued to the device 12. Any keys used by device 12 that are not the current key will cause the device 12 to incur a penalty during the authentication processing procedure, or even an indication that the device 12 is not authentic.
Referring to figure 3, in step 322, the resource system 14 receives a request for restricted resources from a device 12. The request includes data representative of the device information, i.e. the device fingerprint, and if present, the device key and the request key which have been previously transmitted to the device 12 from the authentication system 16, and stored on the device 12.
In step 324, since the request made by the device 12 relates to restricted resources, the resource system 14 determines whether it needs to further authenticate the device 12 in order to grant the device 12 access. The resource system 14 may not require the device 12 to be authenticated, and may simply grant access. However, if the resource system 14 determines that the device 12 should be authenticated, it transmits an authentication request message to the authentication system 16. The authentication request message sent by the resource system 14 to the authentication system 16 includes data representing the device information, i.e. the device fingerprint, and if present data representing the device key and/or the request key as outlined in Figure 2b, in step 222.
The authentication system 16 then performs an authentication procedure or risk assessment, as previously described with respect to figures 1 , 2a to 2c and further described below. The authentication system 16 determines an indication or score, of whether the device 12 is an authentic device 12.
The indication is contained within the authentication response message which is transmitted to the resource system 14 by the authentication system 16. The authentication response message includes data representative of information relating to the authenticity of the device 12. This information is used by the resource system 14 in determining whether it should grant the device 12 access to the restricted resources or whether it should re-initiate/register the authorisation of the device 12. This has been described with reference to figures 1 to 2c.
In step 326, the resource system 14 receives the authentication response message from the authentication system 16. It is assumed that a device key or request key is unique and is transmitted by the authentication system 16 only once to the resource system 14. As described with reference to figures 1 to 2c, the authentication response message transmitted will contain a) the indication on the authenticity of the device 12 and data representative of the replacement request key for use in subsequent requests for restricted resources from the resource system 14, or b) the indication about authenticity, and data representative of the new device key, and the new request key for use in subsequent requests for restricted resources from resource system 14, or c) the indication about authenticity, and data representative of the replacement device key, and the replacement request key for use in subsequent requests for restricted resources from resource system 14 or d) simply the indication (this may indicate that device 12 is not an authentic device).
At step 328 the resource system 14 determines from the indication included within the authentication response message transmitted by the authentication system 16, whether to grant access to the device 12 for the restricted resources. The determination of whether to grant access to the device 12 can depend on threshold values set at the resource system 14 which are compared to the indication (or an indication value) sent from the authentication system 16 to decide on resource access by the device 12. Alternatively, the indication may simply be a data flag, e.g. '1 ' indicating an authentic device and '0' indicating a non-authentic device. In any event, the resource system 14 determines whether to grant/authorise the device 12 access to the requested resources.
At step 330, the resource system 14 has determined in step 328 that the device 12 is an authentic device 12 and that access to restricted resources can be granted. The resource system 14 will then transmit data to the device 12 including either a) the replacement request key, or b) the new device key and the new request key, or c) the replacement device key and the replacement request key. It is assumed the device 12 will store the data received from the resource system 14 for use in subsequent requests for restricted resources from the resource system 14 as outlined in Figure 4.
In step 332, the resource system 14 has determined in step 328 that the device 12 is NOT an authentic device 12, or that the device 12 is potentially compromised, so that access to restricted resources should not be granted. The resource system 14 will then force the next request from the device 12 through the authorisation or re-authorisation procedure.
The purpose of this step is to prevent an imposter or non-authentic device 12 that may have cloned or illicitly used the credentials of the authentic device 12 from receiving the new information such as the replacement device key and the replacement request key, or accessing the requested resources.
This process will enable the authentication system 16 to detect an imposter device 12 in subsequent requests for restricted resources, as the imposter device 12 would not have the expected set of dynamic data keys transmitted with its next request to the resource system 14.
As described with reference to figures 1 to 2c, the resource system 14 may instruct the device 12 to re-authorise with the resource system 14 and if successful, then a new device key may be sent to the device 12 for subsequent requests.
Figure 4 shows the procedure 420 performed on a device 12 during a request for restricted resources from the resource system 14, where the resource system 14 requests authentication of the device 12 from the authentication system 16.
In step 424, the device 12 transmits data representing the device information, i.e. the device fingerprint, and if present, the device key and the request key to the resource system 14. As previously described, this data is ultimately used by the authentication system 16 for determining whether the device 12 is authentic.
In step 426, the device 12 receives data relating to either a) the replacement request key for use in subsequent requests for restricted resources from the resource system 14, or b) the new device key and the new request key for use in subsequent requests, or c) the replacement device key and the replacement request key for use in subsequent requests, or d) a notification of restricted access and/or a request for re-authorisation/re-registration of the device 12 with the resource system 14 as has been described with reference to figures 1 to 3. In step 428 device 12 stores data representative of either: a) the replacement request key, or b) the new device key and the new request key, c) the replacement device key and the replacement request key. This data is used in subsequent requests for restricted resources from the resource system 14. Several examples of the authentication processing procedure performed at the authentication system 16 are now further described. These procedures are performed at the authentication system 16 when it is requested to authenticate a device 12 by the resource system 14. In these examples, it is assumed that the authentication system 16 is receiving data representing the device information related to the device 12 from the resource system 14 in response to a resource request by device 12 for restricted resources from the resource system 14, i.e. the device fingerprint, a device key and a request key.
The authentication system 16 has stored historical device information, i.e. the device fingerprint related to device 12; it has also stored the sequence of
authentication request messages generated by the resource system 14 in response to requests for restricted resources by the device 12. In addition, the historical device information for the device 12 is retrieved from the storage mechanism/medium (e.g. memory) for use in the tests to be performed on the authentication request message data. Whilst the device 12 may transmit any data useful to uniquely identify itself to the authentication system 16 via the resource system 14, in this example the information that the device 12 transmits to the authentication system 16 via resource system 14 contains, but is not limited to, the IP address of the device 12, and/or the location of device 12 (e.g. geo-location of device 12 based on global positioning system co-ordinates or other means), and/or the type and version of the operating system of device 12. However, other device information that can be used to identify the device 12 is also applicable.
The authentication system 16 receives the authentication request message from the resource system 14 in response to the request from the device 12. The authentication request message includes data representing the device information of device 12, i.e. the device fingerprint, the device key and the request key.
A first example of the authentication processing procedure or method is now provided. Although these method steps are described in a particular order, any variation on this order can be applied. On receiving the authentication request message and the data it contains, the authentication system 16 performs a test on the authentication request message data to determine or identify whether the received request key from the device 12 matches the most recent request key in the stored sequence of request keys in relation to the device 12. The stored sequence of request keys is generated and maintained over time by the authentication system 16; each request key is unique, and has been issued to the device 12 via the resource system 14 as a result of a previous request for restricted resources by the device 12; a request key can only be presented once to the authentication system 16, otherwise a compromised use is detected. If the request key does NOT match the most recent request key of the request key sequence, then the device 12 is declared to be a compromised device 12 and given an unfavourable indication value or score representing a compromised device. Simply put, if the device key or request key information supplied by the resource system 14 in relation to the device 12 does not match the data expected by the authentication system 16, then the device 12 should not be considered an authentic device 12. An authentic device 12 should already have the most up-to-date device and request keys, i.e. the current set of keys stored at the authentication system 16.
If the request key does match the most recently issued request key, then the authentication system 16 proceeds to process 1 ) the received data representing the device information, i.e. the device fingerprint; and 2) the stored data representing the historical device information for device 12; to determine whether the device 12 is most likely the authentic device as represented by the record and historical device information stored by the authentication system 16.
The authentication system 16 then performs a series of tests on the received device information contained within the authentication request message data, i.e. the device fingerprint for device 12, in this example the received device information consisting of the IP address of the device 12, the location of the device 12, and the type and version of the operating system residing on the device 12.
During the authentication processing procedure, the result of each test or determination in relation to processing the device information, device key and/or request key, is given a value or a score. These scores are accumulated and/or weighted and combined to provide an indication value or an indication on the authenticity of the device 12. A threshold can be set to a value that indicates that the device 12 has been compromised. The accumulated score can be compared with this threshold at the end of each test. If the accumulated score reaches and/or goes beyond the threshold then it can be determined that the device 12 is most likely compromised. The authentication system 16 may choose to abort the authentication test sequence, i.e. the authentication processing, early and notify the resource system 14 that the device 12 has been compromised or is not authentic.
Alternatively, the authentication system 16 may proceed with further tests, as these might take the accumulated score away from the threshold value such that the device 12 may be considered by the authentication system 16 to NOT be
compromised. The first test compares the historic IP address sequence with the current IP address contained within the authentication request message. If the current IP address is not found in the historic IP address sequence, the authentication system 16 may score the resultant indication unfavourably. IP addresses may change frequently, especially for mobile devices. However, the authentication system 16 determines an indication or likelihood that the change in IP address is possible for the device 12. For example, has a new IP address simply been allocated with a different address space within the same network (dynamic IP address), or has the device 12 moved between two different networks e.g. has the device 12 roamed from a cafe to a nearby office.
The authentication system 16 then determines the general location of the device 12 from the IP address. The IP address can reveal the country the device 12 is operating in and even which town or network provider. So even if the previous and current IP addresses differ, the authentication system 16 determines whether it is possible for the device 12 to have moved between the locations identified by the different IP addresses.
In a further example of this type of test, a user of a device 12 on a previous request for restricted resources may have been in a cafe on a free Wi-Fi connection, then walked back to work and made the current request for resources using the device 12 which now is using an IP address allocated in the office. This would be acceptable. But, it would be impossible for a user of a device 12 to request content or restricted resources from a United Kingdom IP address and then make another request 20 minutes later from an Australian or Philippine IP address. This would indicate that the device 12 has been compromised, for example it has been cloned or stolen. By determining generally where the IP addresses originate from, and the passage of time between IP address changes, the authentication system 16 may be able to determine that the change in IP address is acceptable and provide a score or indication accordingly.
The next test compares the historic operating system of device 12 stored in authentication system 16 with the operating system details supplied in the authentication request message. If the current authentication request message's operating system configuration details for device 12 is not an exact match to that which is stored in the historic operating system configuration sequence of the device 12, the authentication system 16 will score the resultant indication unfavourably. The authentication system 16 then determines the likelihood that the change in operating system configuration details is potentially legitimate, for example if the device 12 has upgraded the operating system, such as a device 12 may upgrade from Microsoft Windows Vista to Windows 7 (trade marks). Conversely, if a mobile device 12 with a history of Apple iOS4 changed to an Android OS that would be extremely unlikely, and therefore trigger a very unfavourable score. The final step within this first example of the authentication procedure is the calculation of a value or indication from the accumulated values generated by the tests. This will result in an indication value of whether the authentication system 16 considers the device 12 to be authentic. A second more detailed example of the authentication processing procedure is now provided. Although the steps are described in a particular order, any variation on this order is also applicable.
It is assumed that the authentication system 16 has stored historical device information, i.e. the device fingerprint related to the device 12; it has also stored the sequence of authentication request messages generated by the resource system 14 in response to requests from the device 12.
Whilst the device 12 may transmit any data which may be used to uniquely identify itself to the authentication system 16 via the resource system 14, in this more detailed example the information that device 12 transmits to the authentication system 16 via the resource system 14 contains but is not limited to the device key, the request key, the device information, i.e. the device fingerprint including the IP address of the device 12 and/or the location of the device 12 (e.g. geo-location of the device 12 based on global positioning system co-ordinates or other means), and the type and version of the operating system of device 12.
On receiving the authentication request message from the resource system 14 the device "fingerprint", the device key and the request key are provided to the authentication system 16 for processing.
In step 1 ) of the procedure, the authentication system 16 performs a test on the authentication request message data to identify whether the received device key from the device 12 matches the most recent device key issued from the
authentication system 16.
In step 2) of the procedure, the authentication system 16 performs a test as to whether the received request key from the device 12 matches the most recent request key, i.e. the current request key. If the device key or request key information supplied in relation to the device 12 does not match the data expected by the authentication system 16, then the device 12 should not be considered an authentic device 12. The score may be weighted such that no matter what scores are given in other tests, the accumulated score results in the device 12 being considered as compromised. In this case, the authentication system 16 could inform the resource system 14 that device 12 is compromised.
If the request key does match the most recently issued request key, then the authentication system 16 processes the received data representing the device information, i.e. the device fingerprint, and the stored data representing the historical device information for device 12 to determine whether the device 12 is most likely authentic. In step 3) of the procedure, the authentication system 16 performs further tests on the data contained within the authentication request message, i.e. the device fingerprint for the device 12, such as whether the request for resources made by the device 12 is from a permitted location. In this example, the authentication system 16 can compare the authentication request message location data against an historical list of permitted locations which are stored by the authentication system 16. If the data contained within the authentication request message comes from a location that is not permitted, for example from a list of banned IP addresses or other location information such as country, then the authentication system 16 can score the test unfavourably; these unfavourable scores can also be weighted against specific values, e.g. a particular country.
Conversely, if the data contained within the authentication request message comes from a location that is permitted, for example from a list of accredited or specified IP addresses or other location information such as country, then the authentication system 16 can return a favourable score for use in determining the ultimate indication value. In step 4) of the procedure, the authentication system 16 can perform further tests on the data provided in the authentication request message, such as whether the request has been made during a permitted time of day. An authentication request message received outside of the permitted time of day will return an unfavourable score. In step 5) of the procedure, the authentication system 16 can perform other tests on the data provided in the authentication request message, such as whether the device 12 may be an automated or artificial device. For example, does the device 12 make too many requests for restricted resources in a given time interval, such that it is outside a specified parameter. For example, a device 12 that performs multiple and/or simultaneous requests for restricted resources within a defined time period will return an unfavourable score.
If the number of requests for restricted resources is too frequent, this may be evidence of an automated or artificial agent or "bot" making the requests. Whilst the automated agent may be an authentic device 12, and therefore has legitimate access to restricted resources as previously described, the resource system 14 may not permit an automated agent to access restricted resources in order for it to scrape or harvest the restricted resources or content, as may be used by a spider in indexing processes.
In step 6) of the procedure, the authentication system 16 then performs a series of tests on the received device information contained within the authentication request message data, i.e. the device fingerprint for the device 12. In this example the received device information consists of the IP address, the location of the device 12, and the type and version of the operating system on the device 12. The device information, i.e. the device fingerprint is then compared against device information from the last successful authentication request message stored at the authentication system 16. If the device information is not an exact match, the indication returned will NOT be favourable. That is, the indication value would indicate that the device 12 is most likely not authentic if the majority of the device information does not match the stored evolving history of the device information in relation to device 12.
In particular, if the transmitted device information is not an exact match to a previous successful request for resources then the following, as example tests, can be performed:
Test a) A comparison of the logical location history is performed to determine if the device 12 has been successfully used in this location in the past.
In analyzing the device information, i.e. the device fingerprint from the device 12, comparisons can be made between the current logical location of the device 12 and its previous logical location(s) stored in the authentication system 16. The logical location is derived from the device information, i.e. the device fingerprint. An example of a logical location would be the Internet Protocol address (the IP address) provided by a device 12 communicating over the internet.
Test b) Compare physical locations of the device 12 using geo-location to decide if the device information, i.e. the device fingerprint data from the new location is physically possible for the device 12 to make.
That is, comparing the data relating to the physical location of the device 12 in the last successful authentication request message to the physical location indicated in the new authentication request message data, and checking if the travel time taken to move between the two locations is reasonable or if it is physically possible.
An example of a physical location comparison would be the city detected from the device information, i.e. the fingerprint, taking into account the time taken to travel from one city to another. For example, if the device 12 requests restricted resources from the resource system 14 and is detected as coming from London UK at 08:00 and then the next request is detected as coming from Buenos Aires Brazil at 08:05, the authentication system 16 can determine that the requests did not originate from the same device 12. As such, the indication returned would be unfavourable or a value indicating that the device 12 is compromised and is most likely not authentic.
Test c) Compare software details to historic and previous successful requests stored on authentication system 16 to determine if the software is potentially similar.
Comparisons are made based on the software (operating system etc.) installed on the device 12 and/or software versions of the software on the device 12. Depending on the similarity or otherwise of the device data contained within the new authentication request message with the previously stored historical device 12 information, or device fingerprint, the authentication system 16 will score the difference accordingly, i.e. a completely different operating system might be scored unfavourably, whereas a closely similar operating system, such as an upgraded version, would score more favourably. In step 7) of the procedure, the authentication system 16 performs a calculation based on the tests performed in steps above 1 ) to 6). In particular, the calculation can be performed by weighting/scoring the output for each of the above steps and accumulating the weighted outputs to result in an indication value representing the likelihood that the device 12 represented in the authentication request message relates to an authentic device 12. The indication value is then used by the authentication system 16 and the resource system 14 as described with reference to figures 1 to 4.
In summary, the authentication system 16 so far described is an intrinsic part of a continuous dynamic authentication and validation system for securing access to restricted resources over a communications network. The authentication system 16 provides a continuously updated authentication and validation system for monitoring and policing requests for restricted resources by a device 12 from the resource system 14.
By performing a series of checks and tests on a combination of data and information relating to the device 12, and data generated and stored over time by the authentication system 16 including but not limited to dynamically generated keys which are transmitted back to device 12 via the resource system 14, the
authentication system 16 can determine whether the device 12 is authentic, or whether device 12 might be cloned or compromised. This enables the resource system 14 to control access to restricted resources at a granular level, i.e. to the specific device 12 and/or the specific restricted resource being requested. FURTHER EXAMPLES
EXAMPLE 1
For every restricted resource such as a document or web page element that is to be made accessible to the device 12, the resource can be made the subject of a set of controls, tests and/or conditions that need to be met in order for the resource to be accessed. The authentication system 16 can have these controls and conditions set to authenticate and run match sequences against a range of factors available from the requesting device 12 or the resource system 14, such as geo- location positioning and historic IP address monitoring (e.g. determining if it is possible for the device 12 to make a request from multiple different locations over a set period of time), operating system changes and version changes, etc.
Additionally, the authentication system 16 can perform the authentication and validation control as often or as infrequently as the resource system 14 requires, doing so only when requested to do so by the resource system 14. This may be for every resource such as a document, link or web page requested by the device 12, or alternatively for every 10 requests for restricted resources, or every 10 documents, links or web pages requested by the device 12, or even in terms of actual time elapsed. The authentication system 16 can use a combination of unique identifiers generated by the authentication system 16 and stored both on the device 12 and in the authentication system 16, together with system information accessible or obtainable from the device 12. This information forms a dynamic set of continuously updated and evolving device history that creates an identity record that is intended to be unique to a specific device 12.
This device history contains data keys dynamically generated and stored by the authentication system 16 which act as a unique, random password that can be updated as often as is required, and which can be used automatically alongside the simple credentials such as login credentials (username and password) of the device 12. Other than storing the transmitted data keys, the device 12 does not need to become involved in the identity authentication or validation process. When requesting restricted resources from a resource system 14, the device
12 will ultimately transmit data relating to the device including the device fingerprint, and dynamic data keys, to the authentication system 16 via resource system 14 within an authentication request message. The authentication request message flows through the authentication system
16 which performs a series of tests on the information contained within the authentication request message, including information such as the device on record, or the geo-location. Many of these tests can be fine-tuned using a set of controls or thresholds giving authentication system 16 the ability to choose how to deal with a specific range of scores or messages.
If required, the thresholds and settings can be tuned for use against specific users and/or devices. For example, this may allow a desirable bot such as the Google spider access to specific content, but deny access to unauthorised or restricted content. By being able to identify whether a device 12 is authentic or not, the authentication system 16 would be able to assist the resource system 14 in determining whether to prevent an unauthorised scraping agent or bot entering a resource system 14 (for example, a content provider's website or "App") and attempting to copy the restricted resources or content.
EXAMPLE 2
Here are some examples of restricted resources that the authentication system 16 could also protect: - Web pages accessed over the internet
- Documents or files stored in a remote repository such as an "extranet"
- Media files, e.g. music, which can be stored in the "cloud" and streamed to a mobile device or devices
- Mobile devices accessed over Bluetooth
- Credit card devices accessed over a closed VPN
- Payment information transmitted between devices via Near Frequency
Communication (NFC)
- SaaS based interactions and communication between devices which require
continuous authenticated and validated access to the restricted resources
- Application based content, e.g. a newspaper App, which is accessed from a mobile device or tablet
- A content provider's website contents from automated content 'harvesting'.
- A private Peer-to-peer network accessed via microwave relay
- A computer game accessed over the internet
- "Intelligent" household appliances controlled remotely, e.g. fridge, oven etc.
FURTHER MODIFICATIONS AND/OR OTHER EXAMPLES
Although the communication system 10 as described herein and as illustrated in figure 1 has been described with reference to a device 12, resource system 14, and authentication system 16, it is to be appreciated there can be more than one device 12 that can be in communication with more than one resource system 14, and that more than one resource system 14 can be in communication with more than one authentication system 16.
Although the resource system 14 may have been described, for simplicity, with reference to a single processing system/database such as a server, it is to be appreciated that the resource system 14 could be a centralised processing system such as a data centre or data warehouse with multiple servers etc., or it may correspond to a de-centralised/distributed processing system such that it is spread across multiple servers or data centres/data warehouses in multiple regions, or even any computing system or combination of computing systems.
Although the authentication system 16 is described as a single processing system or entity, or as a centralised processing system such as a server, it is to be appreciated that the authentication system 16 could be a centralised processing system such as a data centre with multiple servers etc., or it may correspond to a de- centralised/distributed processing system such that it is spread across multiple servers, or multiple data centres, or over in multiple regions/countries, or even any computing system or combination of computing systems.
Although the embodiments and examples have been described in this specification in terms of procedures, processes, tests, or methods for authenticating a device on a communications network, it is to be appreciated that any computer system that includes suitable programming means for operating in accordance with the disclosed procedures, processes, tests, or methods also falls well within the scope of the present invention. Suitable programming means can include any means for directing a computer system to execute the steps of the method of the invention. This can include, for example, systems comprised of processing units and arithmetic-logic circuits coupled to a computer memory or computer readable medium such that the computer memory includes stored data and/or program instructions, which when executed on the processing units, performs steps of the method, tests, procedures or processes of the invention. It is also to be appreciated that the methods, tests, procedures or processes of the invention can be embodied in a computer program product or computer readable medium, such as a diskette or other recording medium, for use with any suitable data processing system, such that the computer program product includes software or program code or instructions, which when executed on a processor, performs the steps of the methods, tests, procedures or processes of the invention or as described herein.
The authentication system 16 has been described for simplicity as having two dynamic data keys, namely a device key which is used to identify a specific device 12, and a request key, which is used for creating a historical sequence of resource requests by the authentication system 16. However, the system could be
implemented using one or even more than two dynamic data keys.
For example, if a single dynamic data key were used this may involve the authentication system 16 generating and storing a single dynamic data key for each request for restricted resources, as opposed to two or more dynamic data keys. This single dynamic data key may represent both the identity of the device 12 and the request number. The single dynamic key is issued to device 12 via resource system 14. The single dynamic data key could contain portions of information which are used to identify both the device 12 and each request for restricted resources. If it represents the identity of device 12, then the authentication system 16 may need to store this identity so that it can keep track of an authentic device's device key and quickly locate the stored historical information related to the authentic device. In another example, there may be more than two dynamic data keys issued to device 12. Multiple dynamic data keys can be generated by authentication system 16 such that each time the device 12 makes a request for restricted resources from resource system 14 the key data is also sent by device 12 and used by
authentication system 16 either in part, (e.g. specific portions of the key data), or as a whole, to identify the device 12, the resource request and/or any other piece of additional information or resources that may be included within a request for restricted resources. Alternatively, the multiple dynamic data keys may be issued and/or transmitted to device 12 simultaneously, or one at a time etc. This adds a further layer of security when Device 12 requests restricted resources because device 12 should transmit the pertinent dynamic data keys (possibly simultaneously or in a particular order or sequence etc.) when it requests access to restricted resources from resource system 14. The authentication system 16 would expect to receive the pertinent dynamic data keys transmitted from the device 12, otherwise it will determine that the device 12 may be compromised.
A further implementation of a system as outlined above could use multiple dynamic data keys containing data used to identify the device 12 and/or the specific request for restricted resources and be encrypted to prevent tampering by un- authentic devices 12.
The authentication system 16 has been described as generating or regenerating the data representing the one or more dynamic key(s) such as the device key and a request key. It is to be appreciated that the data representing the dynamic key(s) or each portion of the dynamic key(s) can be generated or regenerated using a pseudo-random number generator, or even selected from a sequence of numbers determined by the authentication system 16.
Alternatively the authentication system 16 may also generate or derive each dynamic key or portions of the dynamic key based on using globally unique identifiers (GUIDs) or universally unique identifiers (UUIDs). These are unique reference numbers that can be used as an identifier. The number of unique GUIDs is so large that the probability of the same number being generated twice is extremely small, which is very useful for use in determining portions of the dynamic key(s) e.g. the device key and the request key data portions may be generated based on different portions of the same GUID or based on different GUIDs.
Although individual embodiments, examples, and/or modifications of the invention are discussed, it is to be understood that combinations of the above- mentioned features, examples, modifications, and/or individual embodiments also fall within the scope of the invention as claimed and described.
It will thus be appreciated that the present invention does not involve distribution of an authentication token (of the type which is taken to authenticate a client's entitlement to access the resources). Information which is sent back to the resource system 14 and hence back to the device 12 for use in subsequent requests does not contain any identifying information or time stamps (as such items may be intercepted and subsequently manipulated to gain illegitimate access). The present invention operates on the assumption that the device 12 may not be authentic on each occasion that it makes a request from the resource system 14, so the authenticity must be proved on each occasion that the device 12 seeks access. This is achieved by confirming the identity of the device 12 through keys and through fingerprinting of the device 12, taking into account expected changes; and sending on the resulting indication to the resource system 14. The present invention is particularly suited to use with devices 12 which are mobile, such as mobile phones, and as explained above can accommodate changes in location of the device 12, and updates of its operating system.

Claims

1 . A method for an authentication system to indicate that a device requesting access to restricted resources from a resource system is authentic, the method comprising:
receiving an authentication request from a resource system, the
authentication request including data representative of a dynamic key transmitted by the device; and
determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information in relation to the authentic device, wherein the stored historical information includes one or more previously generated dynamic keys in relation to the authentic device; and
transmitting the indication that the device is the authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
2. The method of claim 1 , wherein the step of determining the indication further includes the step of determining whether the received dynamic key corresponds with a dynamic key generated by the authentication system in response to the previous authentication request message in relation to the authentic device.
3. The method of claims 1 or 2, if the received dynamic key is associated with the previously generated dynamic key of the authentic device, the method further comprises the steps of:
updating the stored historical information with the received dynamic key;
generating data representative of one or more portions of a further dynamic key for use in a subsequent authentication request;
storing the one or more portions of the further dynamic key with the stored historical information associated with the authentic device; and
transmitting data representative of the one or more portions of the further dynamic key to the resource system for use by the device in subsequent requests for resources from the resource system.
4. The method of any preceding claim, wherein the data representing a dynamic key includes:
a first portion of data generated by the authentication system that is representative of a device key or the identity of the device; and
a second portion of data generated by the authentication system that is representative of a request key for use by the device when making a subsequent request for resources.
5. The method of claim 4, wherein the step of generating the further dynamic key comprises the steps of:
a) regenerating the second portion of data if the device is determined to be the authentic device; or
b) generating the first portion of data and generating the second portion of data if it is determined that the device is requesting resources for the first time; or c) regenerating the first portion of data and regenerating the second portion of data if it is determined that the device is compromised.
6. The method of any preceding claim, wherein the authentication request further includes data representative of device information related to the identity of the device and the stored historical information further includes data representative of device information related to the identity of the authentic device.
7. The method of claim 6, wherein the step of determining the indication further comprises the step of accumulating one or more scores based on the similarity of portions of the received device information with corresponding portions of stored historical device information of the authentic device.
8. An authentication system for providing an indication that a device requesting access to resources from a resource system is authentic, the authentication system comprising:
a receiver unit for receiving an authentication request from the resource system, the authentication request including data representative of a dynamic key transmitted by the device;
a processing unit for determining an indication that the device corresponds to an authentic device based on the received dynamic key and stored historical information corresponding to previously generated dynamic keys in relation to the device; and
a transmitter unit for transmitting the indication that the device is an authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
9. The authentication system claim 8, wherein the processing unit further includes determining the indication by determining whether the received dynamic key corresponds with a dynamic key generated by the authentication system in response to the previous authentication request message in relation to the authentic device.
10. The authentication system of claims 8 or 9, if the processing unit determines the received dynamic key is associated with the previously generated dynamic key of the authentic device, the processing unit further comprises:
updating the stored historical information with the received dynamic key;
generating data representative of one or more portions of a further dynamic key for use in a subsequent authentication request;
storing the one or more portions of the further dynamic key with the stored historical information associated with the authentic device; and
the transmitter unit further comprises transmitting data representative of the one or more portions of the further dynamic key to the resource system for use by the device in subsequent requests for resources from the resource system.
1 1 . The authentication system of any of claims 8 to 10, wherein the data representing a dynamic key includes:
a first portion of data generated by the authentication system that is representative of a device key or the identity of the device; and
a second portion of data generated by the authentication system that is representative of a request key for use by the device when making a subsequent request for resources.
12. The authentication system of claim 10, wherein generating the second dynamic key comprises:
a) regenerating the second portion of data if the device is determined to be the authentic device; or
b) generating the first portion of data and generating the second portion of data if it is determined that the device is requesting resources for the first time; or c) regenerating the first portion of data and regenerating the second portion of data if it is determined that the device is compromised.
13. The authentication system of any of claims 8 to 12, wherein the authentication request further includes data representative of device information related to the identity of the device and the stored historical information further includes data representative of device information related to the identity of the authentic device.
14. The authentication system of claim 13, wherein the means for determining the indication further comprises the means for accumulating one or more scores based on the similarity of portions of the received device information with corresponding portions of stored historical device information of the authentic device.
15. A method for an authentication system to indicate to a resource system that a device requesting access to resources from the resource system is authentic, the method comprising the steps of:
receiving an authentication request from the resource system, the
authentication request including:
data representative of a first dynamic key allocated to the device and representing the identity of the device;
data representative of a second dynamic key representing a previous request made by the device; and
data representative of device information for use in substantially identifying the device;
determining an indication that the device corresponds to an authentic device based on:
the received dynamic keys and stored historical information corresponding to previously generated dynamic keys in relation to the authentic device; and
the device information and stored historical device information corresponding to previously stored device information in relation to the authentic device;
transmitting the indication that the device is an authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
16. An authentication system for providing an indication to a resource system that a device requesting access to resources from the resource system is authentic, the authentication system comprising:
a receiver unit for receiving an authentication request from the resource system, the authentication request including:
data representative of a first dynamic key allocated to the device and representing the identity of the device;
data representative of a second dynamic key representing a previous request made by the device; and
data representative of device information for use in substantially identifying the device;
a processing unit for determining an indication that the device corresponds to an authentic device based on:
the received dynamic keys and stored historical information corresponding to previously generated dynamic keys in relation to the authentic device; and
the device information and stored historical device information corresponding to previously stored device information in relation to the authentic device; a transmitter unit for transmitting the indication that the device is an authentic device to the resource system for use by the resource system in determining whether to provide access to the device for the requested resources.
17. A communications system comprising:
at least one device;
at least one resource system in communication with the at least one device, wherein the at least one device transmits one or more requests for resources to the resource system; and
at least one authentication system according to any of claims 8 to 14 or 16, the at least one authentication system in communication with the at least one resource system for receiving one or more authentication request messages in relation to the at least one device and responding thereto.
18. A computer readable medium including computer program instructions stored thereon, which when executed on one or more processors of an authentication system, performs the method steps of claims 1 to 7.
PCT/GB2012/050468 2011-03-02 2012-03-02 An authentication system WO2012117253A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1103570.6A GB201103570D0 (en) 2011-03-02 2011-03-02
GB1103570.6 2011-03-02

Publications (1)

Publication Number Publication Date
WO2012117253A1 true WO2012117253A1 (en) 2012-09-07

Family

ID=43904449

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2012/050468 WO2012117253A1 (en) 2011-03-02 2012-03-02 An authentication system

Country Status (2)

Country Link
GB (1) GB201103570D0 (en)
WO (1) WO2012117253A1 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016049870A1 (en) * 2014-09-30 2016-04-07 宇龙计算机通信科技(深圳)有限公司 Method and system for generating dynamic login credential
WO2018178035A1 (en) * 2017-03-30 2018-10-04 British Telecommunications Public Limited Company Out-of-band challenge in a computer system
US10769292B2 (en) 2017-03-30 2020-09-08 British Telecommunications Public Limited Company Hierarchical temporal memory for expendable access control
US10853750B2 (en) 2015-07-31 2020-12-01 British Telecommunications Public Limited Company Controlled resource provisioning in distributed computing environments
US10891383B2 (en) 2015-02-11 2021-01-12 British Telecommunications Public Limited Company Validating computer resource usage
US10956614B2 (en) 2015-07-31 2021-03-23 British Telecommunications Public Limited Company Expendable access control
US11023248B2 (en) 2016-03-30 2021-06-01 British Telecommunications Public Limited Company Assured application services
US11128647B2 (en) 2016-03-30 2021-09-21 British Telecommunications Public Limited Company Cryptocurrencies malware based detection
US11153091B2 (en) 2016-03-30 2021-10-19 British Telecommunications Public Limited Company Untrusted code distribution
US11159549B2 (en) 2016-03-30 2021-10-26 British Telecommunications Public Limited Company Network traffic threat identification
US11194901B2 (en) 2016-03-30 2021-12-07 British Telecommunications Public Limited Company Detecting computer security threats using communication characteristics of communication protocols
US11341237B2 (en) 2017-03-30 2022-05-24 British Telecommunications Public Limited Company Anomaly detection for computer systems
US11347876B2 (en) 2015-07-31 2022-05-31 British Telecommunications Public Limited Company Access control
US11451398B2 (en) 2017-05-08 2022-09-20 British Telecommunications Public Limited Company Management of interoperating machine learning algorithms
US11562293B2 (en) 2017-05-08 2023-01-24 British Telecommunications Public Limited Company Adaptation of machine learning algorithms
US11586751B2 (en) 2017-03-30 2023-02-21 British Telecommunications Public Limited Company Hierarchical temporal memory for access control
US11823017B2 (en) 2017-05-08 2023-11-21 British Telecommunications Public Limited Company Interoperation of machine learning algorithms

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003073242A1 (en) * 2002-02-28 2003-09-04 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling user identities under single sign-on services
US20030177388A1 (en) * 2002-03-15 2003-09-18 International Business Machines Corporation Authenticated identity translation within a multiple computing unit environment
WO2010012220A1 (en) * 2008-08-01 2010-02-04 西安西电捷通无线网络通信有限公司 Anonymous authentication method based on pre-shared cipher key, reader-writer, electronic tag and system thereof

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003073242A1 (en) * 2002-02-28 2003-09-04 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling user identities under single sign-on services
US20030177388A1 (en) * 2002-03-15 2003-09-18 International Business Machines Corporation Authenticated identity translation within a multiple computing unit environment
WO2010012220A1 (en) * 2008-08-01 2010-02-04 西安西电捷通无线网络通信有限公司 Anonymous authentication method based on pre-shared cipher key, reader-writer, electronic tag and system thereof
EP2320348A1 (en) * 2008-08-01 2011-05-11 China Iwncomm Co., Ltd. Anonymous authentication method based on pre-shared cipher key, reader-writer, electronic tag and system thereof

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016049870A1 (en) * 2014-09-30 2016-04-07 宇龙计算机通信科技(深圳)有限公司 Method and system for generating dynamic login credential
US10891383B2 (en) 2015-02-11 2021-01-12 British Telecommunications Public Limited Company Validating computer resource usage
US11347876B2 (en) 2015-07-31 2022-05-31 British Telecommunications Public Limited Company Access control
US10853750B2 (en) 2015-07-31 2020-12-01 British Telecommunications Public Limited Company Controlled resource provisioning in distributed computing environments
US10956614B2 (en) 2015-07-31 2021-03-23 British Telecommunications Public Limited Company Expendable access control
US11159549B2 (en) 2016-03-30 2021-10-26 British Telecommunications Public Limited Company Network traffic threat identification
US11194901B2 (en) 2016-03-30 2021-12-07 British Telecommunications Public Limited Company Detecting computer security threats using communication characteristics of communication protocols
US11023248B2 (en) 2016-03-30 2021-06-01 British Telecommunications Public Limited Company Assured application services
US11128647B2 (en) 2016-03-30 2021-09-21 British Telecommunications Public Limited Company Cryptocurrencies malware based detection
US11153091B2 (en) 2016-03-30 2021-10-19 British Telecommunications Public Limited Company Untrusted code distribution
US11146589B2 (en) 2017-03-30 2021-10-12 British Telecommunications Public Limited Company Out-of-band challenge in a computer system
US10769292B2 (en) 2017-03-30 2020-09-08 British Telecommunications Public Limited Company Hierarchical temporal memory for expendable access control
US11341237B2 (en) 2017-03-30 2022-05-24 British Telecommunications Public Limited Company Anomaly detection for computer systems
WO2018178035A1 (en) * 2017-03-30 2018-10-04 British Telecommunications Public Limited Company Out-of-band challenge in a computer system
US11586751B2 (en) 2017-03-30 2023-02-21 British Telecommunications Public Limited Company Hierarchical temporal memory for access control
US11451398B2 (en) 2017-05-08 2022-09-20 British Telecommunications Public Limited Company Management of interoperating machine learning algorithms
US11562293B2 (en) 2017-05-08 2023-01-24 British Telecommunications Public Limited Company Adaptation of machine learning algorithms
US11823017B2 (en) 2017-05-08 2023-11-21 British Telecommunications Public Limited Company Interoperation of machine learning algorithms

Also Published As

Publication number Publication date
GB201103570D0 (en) 2011-04-13

Similar Documents

Publication Publication Date Title
WO2012117253A1 (en) An authentication system
CN105939326B (en) Method and device for processing message
US8862097B2 (en) Secure transaction authentication
EP3346660B1 (en) Authentication information update method and device
US20220394026A1 (en) Network identity protection method and device, and electronic equipment and storage medium
US20100211996A1 (en) Preventing phishing attacks based on reputation of user locations
CN110690972B (en) Token authentication method and device, electronic equipment and storage medium
CN109413000B (en) Anti-stealing-link method and anti-stealing-link network relation system
EP2981924B1 (en) Resilient and restorable dynamic device identification
WO2018005143A1 (en) Systems and methods for endpoint management classification
JP2004185623A (en) Method and system for authenticating user associated with sub-location in network location
JP2016524248A (en) Method and system for protecting identity information from theft or copying
CN101355556A (en) Authentication information processing device, authentication information processing method, storage medium, and data signal
EP3579595B1 (en) Improved system and method for internet access age-verification
WO2016188335A1 (en) Access control method, apparatus and system for user data
JP6564841B2 (en) Verification server, verification method and computer program
GB2511054A (en) Protecting multi-factor authentication
CN113472716A (en) System access method, gateway device, server, electronic device, and storage medium
KR101273285B1 (en) Authentification agent and method for authentificating online service and system thereof
US11677765B1 (en) Distributed denial of service attack mitigation
KR101212509B1 (en) System and method for service control
KR101879843B1 (en) Authentication mehtod and system using ip address and short message service
JP6842951B2 (en) Unauthorized access detectors, programs and methods
KR20130055116A (en) Authentification method and server
KR101195027B1 (en) System and method for service security

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12707640

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12707640

Country of ref document: EP

Kind code of ref document: A1