GB2541449A

GB2541449A - Restricted service access method

Info

Publication number: GB2541449A
Application number: GB1514858.8A
Authority: GB
Inventors: Kalenda Zdenek; Rudy Van Zoelen Willem
Original assignee: Elephant Talk Europe Holding Bv
Current assignee: Elephant Talk Europe Holding Bv
Priority date: 2015-08-20
Filing date: 2015-08-20
Publication date: 2017-02-22
Anticipated expiration: 2035-08-20
Also published as: GB2541449B; GB201514858D0

Abstract

The method of accessing a restricted service 510 comprises demonstrating by a first electronic device 100 to an authentication server 105 at the time of seeking access to a restricted service that the first electronic device stores a shared secret shared with the authentication server. The authentication server determines whether the first electronic device stores the shared secret; and if it does and a renewal time for the shared secret has not expired, the authentication server transmits confirmation to the restricted service that access to the restricted service is allowed. The shared secret is obtained by a person providing biometric authentication data to the authentication server at a point in time before requiring access to the restricted service. The shared secret can be used to gain access using a second device.

Description

RESTRICTED SERVICE ACCESS METHOD

[0001] The present invention relates to a method of accessing a restricted service. In particular, certain embodiments of the invention involved authenticating a person seeking access to a restricted service.

BACKGROUND

[0002] Many services are provided remotely, for instance through an internet or intranet connection. Additionally, those services may relate to confidential information. There is a need to ensure that a person (or a user identity associated with that person) accessing a service or confidential information is authorised to access that service or information.

[0003] An example of a service offering remote access to confidential information is accessing a service provided through a corporate network. It is necessary to develop methods by which a person attempting to utilise a service provided by a corporate network can be authenticated. Once a person is authenticated, it can be determined whether they are authorised to access that service. For example, in a typical corporate environment, authentication may comprise a person providing a username and a password associated with a user identity or other secret authentication information known only to an authorised person. However, accessing a service via a network connection suffers from inherent security issues. For example, a third party may be able to obtain confidential information by intercepting the supplied username and password, or other secret authentication information. Additionally, such traditional security techniques are vulnerable to error, including falling prey to phishing attacks or simply forgetting the authentication information.

[0004] It is known to improve upon the traditional use of passwords, one option being to use One Time Passwords (OTPs) to access confidential information provided by a service (referred to in this document as a restricted service). As one example, an OTP may be provided to the person for instance by being sent to the person’s mobile device by a Short Messaging Service (SMS) message. The person may then enter the OTP into a field provided in a login screen on a separate computing device used to access the restricted service. In some instances, the same mobile device which receives the OTP via the SMS message may also be used to access the restricted service, for instance via a separate browser page or application. The provision of the OTP via a different communication channel may be referred to as providing the OTP Out Of Band (OOB). OOB communication for the provision of OTPs has the security advantage that the OTPs may be harder to intercept. While more secure than conventional username and passwords, OTPs are not always easy to use as they require the person to read and manually transfer the OTP to the separate computing device or separate browser page or application.

[0005] One example of an OTP algorithm is HOTP: HMAC-based OTP, where HMAC refers to a keyed-Hash Message Authentication Code. HMAC is a cryptographic hash function based upon the use of a secret cryptographic key and any cryptographic hash function. HOTP was standardised by the Internet Engineering Task Force (IETF) in December 2005 as Request For Comments (RFC) 4226, which may be referenced here: https://tools.ietf.org/htmi/rfc4226. Through the use of HOTP, if a first party is in possession of a secret key, K, shared with a second party then a counter, C, may be hashed using the HMAC algorithm for transmission to the second party along with the counter. The second party may then confirm that the first party is authenticated (through knowledge of the key) by the second party themself hashing the same counter using the same key. An extension to HOTP is Time-based OTP (TOTP) in which a timestamp (usually increasing in 30 s increments) is used in place of a counter, which avoids the need to transmit the counter. TOTP was standardised by IETF in May 2011 as RFC 6238, which may be referenced here: https://tools.ietf.org/html/rfc6238. More generally, an OTP or a TOTP may be considered to be a form a cryptographic hash that demonstrates knowledge of a shared secret such a cryptographic key.

[0006] In view of the problems discussed above for authentication based upon security information known or accessible to the person seeking to access the service, additional authentication methods have been provided for existing remotely accessed restricted services. Biometric authentication systems involve the identification of humans by their characteristic traits. Biometric identifiers are the distinctive, measureable characteristics used to label and describe individual people. A frequently used example of a biometric identifier is a person’s voice. The process of authenticating a person based upon a voice sample is referred to as voice authentication or speaker recognition. Voice authentication requires that a voice sample from the person seeking authentication is captured. The voice sample may be compared to a stored voice sample or voice model generated from at least one previous voice sample from the same person.

[0007] However, while voice authentication may be intuitive, and does not require the person to remember any security information, current implementations of voice authentication may be slow: a total time of 25 s or more is not uncommon. Additionally, using voice authentication to access restricted services may require voice authentication to be performed in situations where it is unpleasant, embarrassing or inconvenient to be speaking out loud. Furthermore, voice authentication can fail altogether in noisy environments.

SUMMARY OF THE INVENTION

[0008] It is an aim of certain embodiments of the present invention to provide an improved method for accessing restricted services that is more convenient for a person seeking to access the restricted service. Certain embodiments of the present invention involved a person providing biometric authentication data to an authentication server ahead of the point in time at which they wish to access the restricted service. In particular, it is an aim of certain embodiments of the present invention to enable pre-authentication of a person using biometric authentication, for instance voice authentication. Certain embodiments may be more secure than known authentication methods that are currently implemented to control remote access to restricted services. Advantageously, certain embodiments of the present invention may not require the person to remember username or password information for accessing restricted services. Furthermore, certain embodiments of the present invention allow the same authentication method to be used to access multiple restricted services without suffering from the security problem of password reuse.

[0009] According to a first aspect of the present invention there is provided a method of accessing a restricted service comprising: demonstrating by a first electronic device to an authentication server at the time of seeking access to a restricted service that the first electronic device stores a shared secret shared with the authentication server; determining at the authentication server whether the first electronic device stores the shared secret; and if the authentication server determines that the first electronic device stores the shared secret and a renewal time has not expired, transmitting confirmation from the authentication server to the restricted service that access to the restricted service is allowed.

[0010] The first electronic device may comprise a mobile device.

[0011] The method may further comprise: transmitting authentication data, from the first electronic device to the authentication server; verifying the authentication data at the authentication server; transmitting a new shared secret from the authentication server to the first electronic device if the authentication data is verified at the authentication server; and storing the shared secret at the first electronic device.

[0012] The authentication data may comprise biometric authentication data obtained from a person. The biometric authentication data may comprise a voice sample obtained from the person.

[0013] The method may further comprise: transmitting the renewal time from the authentication server to the first electronic device along with the shared secret.

[0014] The method may further comprise: determining at the first electronic device whether the renewal time has expired at the time of seeking access to a restricted service; and demonstrating by the first electronic device to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret only if it is determined that the renewal time has not expired.

[0015] If the authentication server transmits confirmation to the restricted service that access to the restricted service is allowed, the method may further comprise: the authentication server setting the renewal time to an expired value; and transmitting the renewal time from the authentication server to the first electronic device.

[0016] If the authentication server determines that the first electronic device does not store the shared secret or that a renewal time has not expired, the method may further comprise: the authentication server setting the renewal time to an expired value; and transmitting the renewal time from the authentication server to the first electronic device.

[0017] If the authentication server determines that the first electronic device stores the shared secret, the method may further comprise determining at the authentication server whether the person is authorised to access the restricted service and only sending confirmation to the restricted service if the person is authorised.

[0018] Demonstrating to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret may comprise sending, from the first electronic device to the authentication server, information indicating demonstrating that the shared secret is stored at the first electronic device.

[0019] Sending, from the first electronic device to the authentication server, information demonstrating indicating that the shared secret is stored at the first electronic device may comprise: generating at the first electronic device a cryptographic hash using the shared secret; and transmitting the cryptographic hash from the first electronic device to the authentication server; wherein verifying at the authentication server whether the first electronic device stores the shared secret may comprise: generating at the authentication server a cryptographic hash using the shared secret; and comparing, at the authentication server, the received cryptographic hash and the cryptographic hash generated by the authentication server.

[0020] Sending, from the first electronic device to the authentication server, information demonstrating that the shared secret is stored at the first electronic device may comprise: generating at the first electronic device a cryptographic hash using the shared secret; identifying information to be sent to the authentication server; encrypting at least part of the information to be sent to the authentication server using the cryptographic hash; and transmitting the encrypted information from the first electronic device to the authentication server; and verifying at the authentication server whether the first electronic device stores the shared secret may comprise: generating at the authentication server a cryptographic hash using the shared secret; and decrypting the encrypted information received by the authentication server.

[0021] Generating the cryptographic hash may comprise generating a One Time Password, OTP, or a Time-based OTP, TOTP, using the shared secret and a counter value or a time value.

[0022] The method may further comprise: obtaining at the first electronic device a session identifier from the restricted service; sending the session identifier from the first electronic device to the authentication server when demonstrating that the first electronic device stores the shared secret; and using, by the authentication server, the session identifier to determine the restricted service to which confirmation is to be sent that the person to authorised access the restricted service.

[0023] The method may further comprise providing authentication data to the restricted service and only receiving the session identifier if the authentication data is verified by the restricted service.

[0024] The method may further comprise connecting to the restricted service through the first electronic device and receiving the session identifier from via a secure application server providing the restricted service.

[0025] Communication with the authentication server and storing of the shared secret at the first electronic device may be performed by an authentication application which is separate from a secure application server used to access the restricted service; and wherein the session identifier is passed to the authentication application in response to a user input to the separate service application or web browser.

[0026] The method may further comprise connecting to the restricted service through a separate, second electronic device; wherein obtaining at the first electronic device a session identifier from the restricted service comprises obtaining the session identifier from the second electronic device.

[0027] Obtaining the session identifier from the second electronic device may comprise: displaying a visual representation of the session identifier on a screen within or connected to the second electronic device; and capturing the visual representation of the session identifier through a camera within or connected to the first electronic device.

[0028] The method may further comprise performing local authentication to the restricted service or the first electronic device and only demonstrating that the first electronic device stores the shared secret in response to successful local authentication.

[0029] The method may further comprise sending a person identifier or a service name identifier from the first electronic device to the authentication server when demonstrating that the first electronic device stores the shared secret; and determining, at the authentication server, the shared secret for that person using the person identifier or service name identifier prior to verifying that the first electronic device stores the shared secret.

[0030] The method may further comprise selecting at the first electronic device one of a plurality of service name identifiers and sending the selected service name identifier to the authentication server when demonstrating that the first electronic device stores the shared secret; wherein if the authentication server verifies that the first electronic device stores the shared secret, the method further comprises the authentication server determining whether that service name identifier is authorised to access the restricted service.

[0031] According to a second aspect of the present invention there is provided a method of operating a first electronic device to access a restricted service, the method comprising: demonstrating by the first electronic device to an authentication server at the time of seeking access to a restricted service that the first electronic device stores a shared secret shared with the authentication server; wherein if the demonstration is verified by the authentication server, access to the restricted service is allowed.

[0032] The method may further comprise: transmitting authentication data, from the first electronic device to the authentication server; receiving a new shared secret from the authentication server if the authentication data is verified at the authentication server; and storing the shared secret at the first electronic device.

[0033] The method may further comprise: receiving a renewal time from the authentication server along with the shared secret; determining at the first electronic device whether the renewal time has expired at the time of seeking access to a restricted service; and demonstrating by the first electronic device to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret only if it is determined that the renewal time has not expired.

[0034] According to a third aspect of the present invention there is provided a method of operating an authentication server to access a restricted service, the method comprising: determining at the authentication server whether a first electronic device stores a shared secret shared with the authentication server from a demonstration by the first electronic device at the time of seeking access to a restricted service that the first electronic device stores the shared secret; and if the authentication server determines that the first electronic device stores the shared secret and a renewal time has not expired, transmitting confirmation from the authentication server to the restricted service that access to the restricted service is allowed.

[0035] Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which: [0037] Figure 1 shows an enrolment system in accordance with an embodiment of the present invention; [0038] Figure 2 shows an enrolment process in accordance with an embodiment of the present invention; [0039] Figure 3 shows a pre-authentication system in accordance with an embodiment of the present invention; [0040] Figure 4 shows a pre-authentication process in accordance with an embodiment of the present invention; [0041] Figure 5 shows a login system in accordance with an embodiment of the present invention; [0042] Figure 6 shows a login process in accordance with an embodiment of the present invention; [0043] Figure 7 is a screen shot showing a QR code displayed by an electronic device as part of a login to a restricted service according to an embodiment of the present invention; [0044] Figure 8 is a screen shot showing the selection of a servicelD within an authentication application operating upon a mobile device according to an embodiment of the present invention; [0045] Figure 9 is a screen shot showing a process of local authentication to an authentication application operating upon a mobile device according to an embodiment of the present invention; and [0046] Figure 10 is a screen shot showing a QR code being scanned as part of a login to a restricted service according to an embodiment of the present invention.

DETAILED DESCRIPTION

[0047] The capabilities of modern electronic devices, including mobile devices, allow a number of different biometric identifiers to be determined or captured. This is especially convenient, as it means a person may provide samples of a given biometric identifier while they are mobile, instead of being constrained to certain locations where the appropriate apparatus is located. In particular, a mobile device is typically able to receive a voice sample from a person. However, the present invention is not limited to this. In the following exemplary embodiment, the biometric identifier to be used as part of the present invention is taken to be a voice sample for simplicity of description, though at each instance an alternative biometric identifier, for instance a retina scan, may be substituted.

[0048] The voice sample may be used to provide voice data to a server. In a mobile device, a microphone is typically provided alongside an apparatus or built into the apparatus for converting the received sound signal, in this case the voice sample, from an analogue signal to a digital signal. The digital signal may then be stored in a memory included in the mobile device. In addition to or as an alternative to storing the digital signal, the digital signal may be transmitted to another location such as another electronic device or a server. This storage may only be intended to be short-term, and so the voice sample may be stored in a buffer memory, cache memory, random access memory (RAM) or similar. In the following description, reference to a voice sample may relate to either the analogue signal or the converted, digital signal. It will of course be understood that were other forms of biometric information is used then other forms of sensors are required, for instance a camera for facial recognition.

[0049] It will be appreciated that the mobile device may be a laptop, smartphone, or any other type of electronic device, in particular including other types of mobile devices, though the present invention is not restricted to the use of mobile devices and can be implemented using fixed electronic devices such as a desktop computer. In the following description, the term “mobile device” is used for simplicity. Embodiments of the present invention are particular advantageous for mobile devices as they do not require any further equipment to authenticate a person seeking to access a restricted service. Additionally, it will be appreciated that the mobile device may connect to the Internet via a wired or wireless connection depending on the state of the mobile device.

[0050] To address the problems identified in the introduction regarding voice authentication being inconvenient to use, according to certain embodiments of the invention voice biometric is used periodically to authenticate a person to a server using a first electronic device. This may be referred to as pre-authentication. Typically, the first electronic device will be a mobile device, for instance a smart phone, and for simplicity the term mobile device will be used throughout. The scope of the invention should not be considered to be limited to a mobile device, though this is a typical deployment scenario. Any form of electronic device capable of receiving a voice sample either directly or via connected equipment may be used. According to other embodiments of the invention a different form of biometric authentication may take place, for instance a retina scan. The only requirement placed upon the electronic device is that it is capable of receiving a biometric sample.

[0051] The server may be referred to in this document as an authentication server or an authentication and authorisation server. After successful voice authentication a shared secret, for instance a cryptographic key, is generated by the server and securely transmitted to the mobile device. Specifically, the voice authentication is performed by an authentication application running on the mobile device and the application receives the key from the server and securely stores the key. This key can subsequently be used to access restricted services provided through a second electronic device or provided through a separate application or browser page running on the same mobile device.

[0052] For the purposes of the present application, the voice authentication may be considered to authenticate a person: that is, a natural person. The term “person” is used in this document in preference to the term “user”. This is because while each person is associated with a unique personID (person identifier ID) in a one to one relationship, each person ID may be associated with more than one servicelD (service identifier, or service name identifier). A servicelD may be considered to be equivalent to the conventional term “user ID”. That is, while a single person is authenticated through the voice authentication, that person may have multiple servicelDs used to access different services or to access the same service in different capacities (for instance, general user or administrator), though in each case authentication is of the person. This nomenclature will be used herein to avoid the confusion which may otherwise occur regarding multiple user IDs being associated with a single person. The terms personID and servicelD are discussed in greater detail below.

[0053] The shared secret (typically, a key) may be valid for a configurable, limited period of time under the control of the authentication server. When the shared secret is no longer valid, the person must authenticate themselves again using the mobile device to perform voice authentication to obtain a new shared secret. Advantageously, this means that the person does not have to perform voice authentication each time they wish to access a restricted service. The validity period for the shared secret may be set according to the required level of security, but may typically be multiple hours, days or weeks (or longer). By using voice authentication to obtain a shared secret, then stored in the mobile device, the person enters into a trust relationship with the mobile device in that possession of the mobile device be used to access restricted services. However, as discussed below additional levels of authentication may be required either performed using the mobile device or the second electronic device (if applicable) at the time of accessing a restricted service such that possessing the mobile device storing the shared secret may not be sufficient to access a restricted service. Advantageously, this prevents a stolen mobile device has been pre-authenticated being used to access a restricted service. Additional authentication performed at the mobile device may be referred to as local authentication. In one embodiment the application may be accessed without local authentication, but local authentication may be needed when a “critical” choice is made from the menu. This prevents unnecessary connections to the authentication server if the authentication application is opened accidentally. The local authentication may be fingerprint recognition, if this is supported by the mobile device. A further option for local authentication may be facial recognition which is supported by many mobile devices. In the absence of support for biometric authentication, a knowledge based form of local authentication may be used, for instance a Personal Identification Number (PIN). It will be appreciated that these examples of local authentication are non-limiting and many further options will be known to the skilled person.

[0054] To access a restricted service, the person must authenticate themselves to the restricted service using the mobile device. This authentication may alternatively be referred to as login to the restricted service. For restricted services accessed via the Internet the first step may be for the person to access a web service URL or open an application associated with the restricted service. However, the present invention is not restricted to WWW services. For the purposes of this initial description it is assumed that according to one embodiment of the invention the web service URL or application is accessed via a second, separate electronic device, and the converse where the same mobile device is used will be described later. A restricted service in accordance with this embodiment of the invention with which the person has one or more registered servicelDs may be accessed through a serviceURL (which may simply be the normal and readable URL of a web server hosting the restricted service). A web server may be considered to be just one example of a secure application server capable of providing access to restricted services, typically access via separate devices. In certain other embodiments the serviceURL may alternatively identify the location or how to access a secure application server. Each restricted service may also be uniquely identified through a serviceURLJD. The serviceURLJD may comprise a shortened name or nickname, or could be an encrypted version of the serviceURL in the event that the identity of the restricted service that the person wishes to access is to be kept confidential. In the following description the servicellRLJD is used to reference the service which is being accessed through the serviceURL. In certain embodiments of the invention the serviceURLJD may be redundant and not used if the serviceURL in fact uniquely identifies the restricted service and there is no requirement to preserve the confidentiality of the restricted service identity, in which case references to the serviceURLJD in the following description should be taken to refer alternatively to the serviceURL.

[0055] To access a restricted service a session for that service must be established. A session may be uniquely identified through a session identifier which may be referred to herein as a sessionID. The sessionID may be a system wide identifier that uniquely identifies the session amongst all sessions initiated by restricted services using the authentication service. Where the restricted service is provided as a web service the sessionID is distinct from any conventional web session identifier. The sessionID may be established by the restricted service (that is, by the web server or secure application service hosting the service) or this may be requested from the authentication server which shares the secret key with the mobile device. For the latter option, the sessionID is received ultimately from the authentication server via the restricted service, and specifically via the secure application server that implements the restricted service. The sessionID must then be passed to the mobile device and one suitable mechanism is to present the sessionID as a Quick Response (QR) code or other suitable visual representation. QR codes were standardised by the International Standards Organisation (ISO) as 18004:2006 on 1 September 2006, and available here: http://www.iso.org/iso/iso cataiogue/catalogue tc/catalogue detail.htm?csnumber=43655. However, the skilled person will appreciate that the present invention is not limited to any particular form of visual representation of a sessionID. The QR code may be generated either by the secure application server, or by the authentication server.

[0056] The QR code is generic: it contains a unique/new sessionID such that no two persons receive the same sessionID, but the QR code does not contain any information which is specific to any particular person. As such, there is less need to securely transmit the sessionID. The sessionID may be composed in such a way that both the serviceURLJD and the session within the restricted service can be derived. Alternatively, the QR code may also contain the serviceURLJD.

[0057] The QR code may be captured by a camera built into the mobile device and accessed through the authentication application running the authentication service upon the mobile device. The authentication application may then generate a TOTP using the shared secret and the current time. The authentication application then passes the TOTP, the sessionID and the servicelD to the authentication server. Optionally, the personID and/or additional parameters may also be passed to the authentication server. The transfer of the TOTP, the sessionID and the servicelD is OOB. This is clearly the case where the restricted service is being accessed via a second electronic device. Even where the restricted service is being accessed via the same mobile device running the authentication application, the communication with the authentication server remains OOB as is via a separate channel and has a separate end point compared to the secure application server or application server running the restricted service.

[0058] The TOTP, the sessionID and the servicelD may be encrypted to protect against interception (also referred to as Man in the Middle, MitM attacks) and that encryption may be separate from any encryption protecting access to the restricted service. The skilled person will appreciate that there are a wide range of suitable techniques for providing a cryptographically secured data channel. One suitable mechanism for encrypting the OTP, the sessionID and the servicelD is Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS), though the skilled person will appreciate that the present invention is not restricted to this. HSTS was published by the IETF as RFC 6797 on 19 November 2012 and is available here: https://tools.ietf.org/html/rfc6797. HSTS serves to ensure that traffic uses a HTTP over Transport Layer Security, TLS, (HTTPS) connection, which uses bidirectional encryption. A known problem with HSTS is that conventionally the initial request to use HSTS is unencrypted, however certain embodiments of the present invention address this by the authentication application and the authentication server being preconfigured with the necessary data to establish a HSTS connection prior to first ever connection between the authentication application and the authentication server. This configuration information may be supplied to the authentication application as part of an enrolment process, which is described below. Advantageously, this preconfigured, secure OOB channel between the authentication application and the authentication server allows for the secure transmission of the shared secret to generate the OTP and the secure transmission of the OTP, the sessionID and the servicelD.

[0059] No further interaction is required from the person seeking to access the restricted service. Upon receipt of the OTP and the sessionID the authentication server can generate the OTP for itself using the sessionID received with the OTP and the shared secret. The appropriate shared secret may be identified using the servicelD and/or the personID transmitted with the OTP. The authentication server can then compared the received OTP and the locally generated OTP to authenticate the mobile device, and hence to authenticate the person. Once authenticated the authentication service will inform the secure application server or the application server providing the restricted service that the person is correctly authenticated. The authentication server may also provide the servicelD to the secure application server or application server.

[0060] The present invention will now be described in greater detail in accordance with three key processes: enrolment, pre-authentication and login to a restricted service.

[0061] It will be appreciated that before the above described method can be used to preauthenticate a person and then the person use the mobile device to login to a restricted service (that is, to authenticate themself to the restricted service) it is necessary for that person to be enrolled in the authentication service. Enrolment may be considered to be the process of adding a new personID to the authentication server, installing and configuring the authentication application on the person’s mobile device and registering a voice sample to be used for voice authentication during pre-authentication. Enrolment will now be described in connection with Figures 1 and 2.

[0062] Figures 1 and 2 illustrate an enrolment system and process that may be suitable for use in a corporate environment as part of an authentication system for providing access to restricted corporate services. In part therefore this requires the involvement of an administrator who is a person responsible for ensuring that the person undergoing enrolment is indeed who they say they are and is entitled to access the restricted services for which they are to be authenticated. While this process is suitable for a corporate involvement, the present invention is not restricted to this and may be modified in ways that will be readily apparent to the skilled person for other situations. For instance, in a banking embodiment where the person is a customer seeking access to online banking facilities, the role of the administrator may be performed by a bank employee who verifies the identity of the customer. Alternatively, and for access to other forms of restricted services, verification of identity may be performed differently, for instance by posting documents to a home address, or may be omitted entirely. If verification of identity is omitted, for instance when enrolment takes place remotely across a network, then the enrolment may simply bind a person, through their voice, to a particular mobile device such that it can be ensured that the person accessing restricted services is the same person each time, even if their true identity cannot be ascertained.

[0063] An enrolment process that follows less strict security rules may arise for instance when migrating from user ID and password authentication used in a web forum or blog site. In such a situation it is only necessary to ensure that the same person is signing in and modifying the content. As such the enrolment may be implemented without any administrator intervention as follows. Firstly, the person receives an invitation for voice enrolment. The person visits the enrolment page and authenticates as usual using their user ID and password. That person is then prompted to download the authentication application and guided through the voice training process as described below. Once complete, that person can use the secure application to access restricted services as described in the remainder of this document. Optionally, the existing user ID and password access mechanism may be preserved in parallel, perhaps initiated through a different serviceURL. For low security services the involvement of a human administrator may not be justified. As a further example, a human administrator may not be required when the user uses a federated login process from a trusted social media service or public web service, for instance Facebook, Google or Apple.

[0064] Referring to Figure 1, this shows a person 110 who is seeking enrolment to the authentication service. The person 110 is in possession of a mobile device 100, which they may own or may be issued to them (which may be particularly appropriate to a corporate environment). Figure 1 further shows an administrator 120 who may be a specified employee within the corporation responsible for enrolling new persons into the authentication service. As noted above, part of securely enrolling a new person 110 requires the administrator 120 to carefully follow procedural rules to ascertain the person’s identity and to correctly identify services to which they are entitled to access.

[0065] Referring also to Figure 2, at step 200 the person 110 is selected for enrolment into the authentication service and presents themself in person to the administrator 120. The administrator may confirm their identity, for instance by checking a passport or other documentation and identifying through corporate records that they are to be enrolled, and which services they are entitled to access. In an alternative embodiment of the invention there may be no requirement for the person 110 and the administrator 120 to meet in person. For instance, the enrolment process may be initiated by telephone (which of course requires that the administrator 120 must recognise the person’s voice, or their identity must be confirmed in some other way.

[0066] The administrator 120 may directly access the authentication server 105, though more typically they may access the authentication server 105 through an administration terminal computer 125 which is connected to the authentication server 105 through a wired or wireless connection or across a network 115. At step 205 the administrator 120 uses the administration terminal to generate a new personID within a database controlled by or stored at the authentication server 105. The personID may be stored with appropriate identifying data for person 110, which may include their name, an organisation identifier (which may be appropriate in a situation in which an authentication service is provided to a group of organisations, for instance a parent company and subsidiaries) and an employee number or other identifier used by the company. A personID creation date may also be stored.

[0067] At step 210 the administrator 120 identifies the restricted services that the person 110 is entitled to access and generates (or causes the authentication server to generate) one or more pairs of servicelD and associated servicellRLJD. The serviceURLJD may be selected from a preconfigured list. The servicelD may be generated either automatically by the authentication server or manually.

[0068] Associated with each personID is a shared secret field and information regarding renewal of that shared secret. However, the shared secret is not transmitted to the person’s mobile device 105 until the step of pre-authentication and so this will be described in greater detail below in association with the pre-authentication step by reference to Figures 3 and 4.

[0069] At step 215 the administrator 120 assists the person 110 with downloading and installing an authentication application 130 to their mobile device 100. For instance, this may be obtained from an application store 155 in a conventional fashion across network 115, or for instance the authentication application 130 may be obtained from the authentication server 105. There may be multiple versions of the authentication application 130 suitable for differing operating systems of the mobile device 100. In a situation where enrolment does not involve an administrator, downloading and installing the authentication application 130 may comprise the first step of the process requiring the active involvement of person 110.

[0070] At step 220 local configuration of the authentication application may be required. The authentication application 130 may require initial configuration, for instance to enter an organisation identifier. However, in some embodiments each authentication application 130 may be preconfigured with this basic information and may be tailored to a particular company or for access to particular restricted services. Additionally, for embodiments of the present invention where local authentication of the person 110 by the authentication application 130 is required before critical actions such as pre-authentication or login can be performed, local configuration may include setting a PIN, recording a fingerprint using an inbuilt fingerprint scanner 135 (if available) or setting some other form of local authentication.

[0071] At step 225 the administrator 120 requests the authentication server 105 to create an initial configuration for the newly generated personID. The initial configuration includes details of personID, servicelD / serviceURLJD pairs and the further data described above in connection with the personID. Additionally, to secure future communications between the authentication application 130 and the authentication server 105, the configuration information may include information required to initiate a cryptographically secured data channel, for instance a HSTS connection, or other encrypted communication channel, for the exchange of information during pre-authentication and login. In order for this configuration information to be transmitted to the mobile device 100, the authentication server may generate a QR code containing a URL where the configuration for the initial configuration can be obtained. The configuration information may comprise a configuration file that can be downloaded and installed, but the present invention is not restricted to any particular file structure for the configuration information. The URL may contain a Globally Unique Identifier (GUID) pointing to the configuration. The GUID may be based on the Universally Unique Identifier (UUID) standard published by the IETF as RFC 4122 in 19 July 2005 and available here: https://tools.ietf.org/html/rfc4122. The QR code may be displayed upon a screen 140 within or coupled to the administrator terminal 125 or directly upon the authentication server, if appropriate.

[0072] At step 230 the configuration is downloaded to the authentication application 130. This may be achieved by the person 110 (or the administrator 120) opening the authentication application 130 and selecting a menu option, for instance “Setup” which prompts the application to use a camera 145 within the mobile device 100 to scan the QR code. Upon scanning the QR code the authentication application 130 can obtain the GUID and connect to the authentication server 105 (or some other location where the configuration is stored) and start the download of the configuration. The configuration may also contain the URL of the actual authentication server 105 where this person 110 should be enrolled for voice authentication in the event that the authentication service includes more than one authentication server or the authentication server does not perform the above steps. Preferably, once the configuration fie is downloaded, this URL cannot be accessed again. It will be appreciated that the use of QR codes for passing information is entirely exemplary and alternatives may be used, including displaying the GUID for the person 110 to enter into the authentication application, and short range wireless communications such as Near Field Communication (NFD). However, the use of QR codes is particularly advantageous given the prevalence of cameras in mobile devices and the fact that the same mechanism may be used for passing sessionIDs when accessing restricted services through essentially any other electronic device so long as that electronic device includes a screen.

[0073] As a further alternative, a minimal configuration, for instance restricted only to the personID, may be passed to the authentication application, with the remainder of the required configuration information being manually configured or supplied later.

[0074] Following step 230, the authentication application is fully configured, but the person 110 is not yet enrolled into a voice authentication service. Enrolment into the voice authentication service binds the person 110 (specifically, their voice) to the personID. It will be appreciated that alternative forms of biometric authentication similarly serve to bind a real person to their corresponding personID. It will be appreciated that a wide range for voice authentication services are known or commercially available and that the details of their enrolment may differ widely. The following explanation is exemplary for a single voice enrolment process.

[0075] At step 235 the person 110 may access an “Enrol Voice” option through the authentication application 130 upon their mobile device 100. This causes the authentication application 130 to contact the authentication server 105 identified within the configuration previously downloaded at step 230. The authentication application 130 enters a voice enrolment mode in which voice enrolment is performed at step 240. This may, for instance, involved the authentication application 130 prompting the person 110 to speak a predetermined word or phrase, optionally repeated multiple times. In other embodiments the person may not be required to speak predetermined words or phrases and any sample of speech or group of samples of speech will be sufficient to complete voice enrolment. Voice enrolment techniques will be familiar to the skilled person and the present invention is not restricted to any one technique. The mobile device 100 captures one or more voice samples using a microphone 150. Those voice samples are then communicated to the authentication server 105. The voice samples may be securely transmitted using a cryptographically secured data channel, for instance using a HSTS protected channel set up according to the parameters passed to the authentication application as part of the configuration. At step 245 the administrator 120 must confirm the person 110 who provided the voice sample or voice samples. As noted above, in certain embodiments of the invention enrolment may be performed by a remotely located administrator 120. For them to confirm that the voice sample is indeed provided by the correct person may require that they know the person’s voice. As discussed above, such remote enrolment may preclude a check of a passport or other document. For yet further embodiments of the invention, the role of the administrator may be removed entirely, the enrolment process serving only to bind the voice of a person to a personID, without any absolute knowledge of the identity of that person. This may suffice for publically accessible, yet restricted, services such as email services, where it is necessary to restrict access only to the person who initially creates the account.

[0076] Based on the or each voice sample, the authentication server 105 may, at step 250, generate a voice model for the person 110, which may be stored in association with the personID for that person 110. The voice model may then be used to authenticate the person 110 as part of the pre-authentication procedure described below. The details of how the voice model is generated may be entirely conventional.

[0077] As noted above, during pre-authentication once a person 110 has been authenticated, a shared secret used to generate OTPs during login is generated by the authentication server 105 and securely transmitted to the authentication application 130 using a cryptographically secured data channel, for instance a HSTS channel (as well as being stored locally at the authentication server). The shared secret may comprise a TOTP key (alternatively referred to as a seed) defined by RFC 6238 and RFC 4226 described above. Upon initial enrolment of the person 110 the shared secret field within the configuration for the personID at the authentication server 105 is blank. A shared secret is not generated and transmitted to the authentication application 130 until the first pre-authentication takes place. Pre-authentication therefore refers to the process of the authentication server 105 authenticating the person 110, generating a shared secret and transmitting the shared secret to the authentication application 130 in relation to a particular personID.

[0078] Additionally, the configuration includes a further field defining a renewal interval. The renewal interval defines the maximum period of time between successive preauthentications. It will be appreciated that this therefore defines the validity period for the shared secret. The person 110 may optionally choose to initiate pre-authentication more frequently. The renewal interval may be set for a corporation using the authentication service and may be further modified (for instance, shortened) for one or more personIDs. If the shared secret is invalid due to the renewal interval being exceeded then the authentication server 105 will not allow login to take place, without the person first undergoing pre-authentication. The configuration further includes a Time To Renew (TTR) value which indicates the time at which the current renewal interval expires. This may alternatively be referred to as a renewal time or a shared secret renewal time. It will be appreciated that in alternative embodiments, rather than set a TTR a renewal timer may be started which may either count up to a predetermined value or count down to zero, that is the renewal timer measures a period of time. References below and in the claims to determining if a renewal time or a TTR has expired are expressly consider to include implementations in which a timer is set instead of comparing the TTR to a current time. If the TTR is less than the current time then pre-authentication must be performed before the person can login to a restricted service. Upon enrolment of the person 110, the TTR is set to zero which has the effect that pre-authentication must be performed. If the TTR is zero or less than the current time, this may have the effect of greying out or otherwise disabling all options in the authentication application 130 other than pre-authentication, so the need for this is apparent to the person 110. Similarly, prior to the completion of enrolment, all options other than “Enrol Voice” may be greyed out. Preferably, the administrator 120 may assist the user with their first pre-authentication and login (that is, accessing a restricted service). Pre-authentication is described below in connection with Figures 3 and 4.

[0079] Preferably the authentication application is arranged to minimise or avoid user interaction wherever possible to provide for a streamlined user experience. As an example of this, where the authentication application communicates with the person, this may be done by displaying a message screen that disappears automatically after a predetermined period of time, with no requirement for the person to acknowledge the displayed message, such as by pressing an “OK” button.

[0080] Referring now to Figures 3 and 4, the process of pre-authentication will now be described. Pre-authentication essentially requires communication between the mobile device 100 and the authentication server 105. At step 400 the process starts with the person 110 opening the authentication application 130. At step 405 the authentication application checks the TTR. If the TTR is zero (indicating that the person 110 is newly enrolled and pre-authentication is yet to take place for the first time) or the TTR has expired (that is, the TTR is less than the current time indicating that the shared secret is no longer valid) then pre-authentication is mandatory. All other options may be greyed out to force the person 110 to select pre-authentication (or exit the application). The person 110 may opt to perform pre-authentication at any time while the shared secret remains valid, for instance to renew TTR by performing pre-authentication at a time when it is convenient to perform voice authentication). If the TTR is later than the current time then the authentication application 130 may display addition menu options, for instance a settings option or the option to select a servicelD for login (explained below in connection with Figures 5 and 6).

[0081] At step 410 the person 110 selects a “Pre-authentication” menu option. As noted above, in certain embodiments local authentication at the mobile device 100 may be required at step 415 before proceeding with any option that initiates communication with the authentication server 105. Advantageously, this prevents inadvertent contact to the authentication server 105. Local authentication may include providing a fingerprint using the fingerprint scanner 135 and which may be compared to the stored fingerprint provided during enrolment. Alternatively, a PIN code may be provided, or some other form of authentication information provided. Local authentication may be required each time a change of configuration, login or pre-authentication action is requested.

[0082] At step 420 the authentication application 130 connects to the authentication server 105 using a cryptographically secured data channel, for instance a HSTS connection. It will be appreciated that the precise nature of the encrypted connection is not critical to the present invention. At step 425 the authentication server 105 may check the version of the authentication application 130 (using an indication of the version supplied as part of the connection request). If the version is not supported the preauthentication process may end and the reason may be shown to the person 110. The person 110 may then select an alternative menu option to download a supported version of the authentication application 130. Given that the person 110 may elect to perform preauthentication at a time that is convenient to them, it is likely that this would also prove a suitable opportunity to update the application. Alternatively, the version update may not be time critical, and there may be a migration window.

[0083] At step 430 the time at the authentication server 105 and the authentication application 130 may be compared. This step may not be implemented in all embodiments. Comparing the times allows a time-delta to be calculated. The time-delta comprises the difference between the time (for instance according to a network time protocol) of the authentication server 105 and the local time at the mobile device 100. Preferably, this should be zero. The time-delta may be used in certain time critical computations noted below. The time-delta may be stored and used for future time critical tasks, especially the generation of the TOTP during login which is valid only for a limited period of time (for instance 30 s). The time-delta may be taken into account when generating the TOTP to prevent a mismatch with the TOTP generated by the authentication server 105. The time-delta may also be taken into account when checking the TTR to determine whether the shared secret is still valid. In both cases, the time-delta may be used to correct the local time of the mobile device 100 to match the time of the authentication server 105.

[0084] At step 435 the person 110 provides a voice sample using the microphone 150. The authentication application 130 may provide suitable prompting or guidance for providing the voice sample. At step 440 the voice sample (for instance in the form of an audio stream Binary Large Object, BLOB, or .mp3 file) is sent to the authentication server 105. At step 445 the authentication server performs voice authentication. It will be appreciated that this may be entirely conventional, and so will not be further described here. At step 450 the authentication server 105 determines whether the voice authentication has been passed or failed. If the voice authentication has been failed then at step 455 the pre-authentication process is aborted and the TTR is set to zero with the result that the person 110 will be obliged to undergo pre-authentication again, even if the previous pre-authentication process was undergone voluntarily and the TTR was not previously less than the current time. An error message may be displayed to inform the person 110. As before, in addition to undergoing pre-authentication the person 110 may also be able to access setup options within the authentication application 130. The failure of the voice authentication may be logged by the authentication server 105. If repeated failures occur then optionally further action may be taken, for instance requiring the person 110 re-enrol according to the process of Figure 2.

[0085] Alternatively, if at step 450 the voice authentication is determined to have been passed then at step 460 the authentication server 105 generates a new shared secret and stores this in association with the personID for person 110. The authentication server 105 also sets a new TTR based on the renewal interval for that personID. At step 465 the shared secret and the TTR are transmitted securely through a cryptographically secured data channel, for instance through the HSTS channel described above. At step 470 the authentication application 130 securely stores the shared secret within the mobile device 100 such that it can only be accessed by the authentication application. Suitable techniques for this will be apparent to the skilled person and typically embodiments of the present invention would select the best available technique. It is necessary to secure the shared secret such that it can only be accessed by the authentication application 130 to protect the authentication service from an attack directed at the mobile device 100, which may be less securely physically protected than the authentication server 105. As one example of how the shared secret may be secured, some mobile devices support a standardised High Security Module (HSM), which may be used. Alternatively, the shared secret may be kept in an environment protected by the operating system on the mobile device. The read and write rules for the shared secret may be set in such a way that they are only available for the authentication application (and the system itself). This means that any other program, or user, for instance using a file browser or other application from the user space group is unable to see the shared secret as the file browser or other application would be running under different privileges.

[0086] At step 475 the authentication application 130 may perform a hash over the configuration stored within the application, using the shared secret. This is sent to the authentication server 105 which can separately perform the same hash. If there is a mismatch the authentication server 105 can send a new configuration to the authentication application 130, thereby ensuring that they are automatically synchronised. Alternatively, it may only be that only parts of the configuration (for example, the servicelD and servicellRLJD pairs) are hashed.

[0087] At step 480, optionally the person 110 may be given the option to set a “Wake-Up Call” in order to be warned in time (and at a convenient time) to perform the next preauthentication process. This will make it possible for the person 110 to perform preauthentication in a quiet, suitable moment during the day.

[0088] The authentication application 130 may return to a main menu, which if appropriate now shows the login option as being available (if it were not already available). If pre-authentication was performed voluntarily, the only changes will be the resetting of the TTR and the refreshing of the shared secret.

[0089] Referring now to Figures 5 and 6, the process of login to a restricted service (that is, authenticating a user to a restricted service) will now be described. As discussed above, for each person 110 the authentication server 105 stores one or more pairs of servicelD and servicellRLJD (which are replicated on the authentication device). Each servicelD may appear in one or more pair. The ability of a person 110 to login to particular services can be enabled to disabled by an administrator 120. As noted above, the servicelD and servicellRLJD pairs stored in the authentication application 130 are synchronised each time pre-authentication is performed.

[0090] Additionally, the authentication service according to embodiments of the present invention, and in particular the use of pre-authentication to enable a trust relationship with a mobile device 100, is modular and does not preclude (or require) additional authentication actions. As noted above, certain embodiments of the present invention may include local authentication at the mobile device 100, for instance through entering a PIN or providing a fingerprint reading, which will be described below in connection with login, though this is not essential. Further levels of authentication may enhance security at the cost of reduced ease of use for the person 110 (the end user).

[0091] An embodiment of the present invention will now be described in which the person 110 seeks to access a restricted service using a second electronic device 500 separate from the mobile device 100. However, the present invention is not limited to this and an alternative in which the same mobile device 100 which runs the authentication application 130 is used to access the restricted service is described afterwards.

[0092] At step 600 the person 110 uses the second electronic device to open the restricted service. For instance, where the restricted service is accessed through a web browser, this may involve the person 110 navigating to the serviceURL associated with the service.

[0093] At step 605, as an example of a further level of authentication, the person may be required to supply or provide authentication data to the restricted service. For instance, this may include the person supplying a password or some other form of conventional authentication credential. This provision of a password or other form of conventional authentication credential may effectively comprise including a conventional login procedure for a web service into the overall authentication scheme. This may be particularly suitable in the event that the authentication service of the present invention is used to bolster existing security provisions already in place for restricted services. The existing login procedure could optionally be disabled. Advantageously, the authentication credential presented to the restricted service may not provide any indication of the identity of the person. The identity of the person is separately confirmed to the authentication server according to the present invention in an OOB mechanism which is separate from the restricted service. If the authentication data provided to the restricted service is not verified by the restricted service then the sessionID may not be provided, for instance via the QR code, as described below. Verification may simply comprise the restricted service confirming that authentication data, e.g. a password, has been received, without confirming its veracity.

[0094] In one embodiment, upon receipt of authentication data from the person, the restricted service, for instance the secure application server implementing the restricted service, may supply the authentication data to the authentication server at the time of requesting the QR code including the sessionID (or data including the sessionID to generate the QR code using a library available to the restricted service). As described below, the mobile device, and more particularly the authentication application, then separately provides the personID, sessionID and, if appropriate, the servicelD to the authentication server when demonstrating knowledge of the shared secret. After verifying that the mobile device stores the shared secret the authentication server may then provide the servicelD and the received authentication data (e.g. the password entered by the person to the restricted service) back to the restricted service. The restricted service may then proceed with a conventional login procedure in which for instance the servicelD and the authentication data are mapped to a username and password combination and verified as normal by the restricted service. A key difference from convention techniques for accessing restricted services is that the servicelD (the username) is provided by a completely separate channel to the authentication data (the password) and the servicelD (or personID if this alone is used) is independently verified by the authentication server owing to the pre-authentication phase which ties the individual user to the mobile device.

[0095] As well as increased security through another level of authentication, this optional provision of authentication credentials to the restricted service provides further benefits. Firstly, it gives better protection against Denial of Service (DoS) attacks against the authentication server 105. This is because where a QR code is generated by the authentication server 105 as part of the login procedure (as described below) the QR code is only generated, and indeed the authentication server is only contacted, when valid authentication credentials are provided to the restricted service. The restricted service may be accessed through the second electronic device 500 and provided by a secure application server 510. In certain embodiments the secure application server 510 may comprise a web server which is accessed by the second device 505 in a conventional fashion, in which case the web server is responsible for determining whether the authentication server 105 should be accessed according the supplied authentication credentials. The skilled person will appreciate that the present invention is equally applicable for login to restricted services provided other than by World Wide Web (WWW) servers. A further advantage of providing authentication credentials to the restricted service is that it gives resistance against BOTS that do not follow the <meta name="robots" content-'nofollow" /> convention. This prevents leakage of information as otherwise BOTS that did not follow the convention would collect a QR code and possible further information. While not containing any sensitive information, it is preferable not to provide any information contained in a QR code, such as the format as sessionIDs except to locally authenticated persons. Finally, the provision of a username / password combination adds "something you know" to the authentication service, in addition to the use of voice authentication (“something that you are”), and optionally the use of a fingerprint (described below), and the possession of the mobile device (“something that you have”). This satisfies high security demands and standards by providing for three-factor authentication.

[0096] If the correct authentication credentials are provided to the restricted service, the restricted service connects to the authentication server 105 at step 610. Specifically, the restricted service calls an API on the authentication server 105 passing for input a sessionID and the servicellRLJD. Further data may be passed, including the organisation identifier. The authentication server 105 returns a QR code and the second electronic device 500 displays the QR code on screen 505 at step 615. The QR code contains at least the sessionID, which is required by the authentication application 130 to generate the OTP. Further data may also be included, for instance the servicellRLJD. In an alternative embodiment of the present invention, the secure application server 510 may itself generate the sessionID and the QR code. The QR code may contain a random filler functioning to reserve space for extensions to the authentication service, for instance to trigger a reset of the shared secret after each login by changing the TTR to zero. The sessionID (and optionally the servicellRLJD) may also be displayed in clear text. An example of a restricted service login in which a QR code 700 and clear text sessionID 705 are displayed on a second electronic device is shown in the screen show of Figure 7. In an alternative embodiment, an iframe may be used which enables the authentication server 105 to directly display the QR code. The QR code may be displayed for a limited period of time, for instance 30 s. The display period of time may be set by the authentication server 105. Communication between the restricted service (secure application server 510) and the authentication server 105 may be performed via a cryptographically secured data channel, for instance using Transport Layer Security (TLS) or any other suitable technique known to the skilled person, though it will be appreciated that no information specific to a user is passed.

[0097] At step 620 the person 110 opens the authentication application 130. It will be appreciated that this may take place in parallel to, before or following steps 600 to 615. As discussed above in connection with Figures 3 and 4, the TTR is checked and if the shared secret is no longer valid the option to perform login is greyed out. Otherwise, at step 625 the person 110 selects “Login”. This displays a screen as shown in Figure 8 in which the user can select from one or more servicelDs 800 or select the default (preselected) servicelD 805 at step 630. It will be understood that the person 110 must select an appropriate servicelD for the restricted service that they wish to access, and for which they know (or suspect) that they are pre-registered (through a servicelD and serviceURLJD pair being preconfigured). In some cases there may only be a single servicelD available, such that the unique personID for that person 110 corresponds uniquely to that servicelD. In some cases there may be more than one servicelD paired to a single serviceURLJD for that restricted service: for instance a person 110 may be able to login in a personal capacity or in an administrator capacity. If a servicelD is selected that is inappropriate for the restricted service then the subsequent login will fail.

[0098] At step 635 person 110 selects an “Authenticate” menu option 810 triggering local authentication at the mobile device 100. As for during pre-authentication, this local authentication is not mandatory for all embodiments of the invention. Again, one option is for local authentication to be achieved using a fingerprint scanner 135 embedded in the mobile device 100, though many alternatives will be readily apparent. Selection of the “Authenticate” menu option 810 may cause the display of the screen shown in Figure 9 in which a pop-up window 900 prompts the person 110 to perform local authentication, for instance by providing a fingerprint or to entering a password (or a PIN).

[0099] On successful local authentication, at step 640 the authentication application enables the mobile device camera 145 for scanning the QR code. This causes the screen of Figure 10 to be displayed in which a window 1000 is displayed showing the view captured by the camera 145. This assists the person 110 in aligning the camera 145 to scan the QR code. Successful scanning of the QR code transfers the information contained within the QR code to the authentication application 130. As noted above, the QR code contains at least the sessionID, and optionally the serviceURLJD. As noted above, this information may be transferred in other ways, for instance by typing into the authentication application 130 the displayed cleartext.

[00100] The information shared with the authentication application 130 through the QR code does not contain any information unique to a user, for instance a personID or a servicelD. No shared secret information is exchanged. Regardless, to guard against replay attacks, as noted above the QR code may only be displayed for a short period of time and the sessionID may only be valid for limited time period, for instance 5-30 s. If a QR code is not scanned within a predetermined period of time (for instance 30-60 s) the camera 145 may be disabled and the authentication application may return to the screen shot of Figure 8 requiring reselection of a servicelD. Similarly, after expiry of the QR code, in one embodiment the person 110 may be required to again provide authentication credentials to the restricted service. Alternatively, there may be an option to request a new QR code, and hence a new sessionID.

[00101] Once in possession of the sessionID from the QR code, at step 645 the authentication application calculates a new TOTP. At step 650 the TOTP is passed to the authentication server 105 through the encrypted channel previously configured. The TOTP is generated as described above based on the current time (which may be a time based counter, for instance incrementing every 30 s or the correct local time) and the shared secret. The TOTP serves to prove to the authentication server 105 that the authentication application 130 possesses the shared secret. The authentication application 130 passes the sessionID and the servicelD to the authentication server 105 along with the TOTP. At step 655 the authentication server 105 separately computes the TOTP for comparison to the TOTP received from the authentication application 130. When both TOTPs match that is proof of correct pre-authentication of the person 110. The authentication server 105 is able to identify the appropriate shared secret to use to locally generate the TOTP from the servicelD (and optionally also the personID) transmitted to the authentication server 105. Optionally, the authentication application 130 may transmit an organisation identifier and a serviceURLJD to the authentication server 105. The serviceURLJD allows the authentication server 105 to identify the restricted service which the person 110 is attempting to access (if this is not discernable from the sessionID alone). In some embodiments the serviceURLJD may not be necessary if the authentication server 105 has a record of the matching restricted service for which the sessionID and the QR code was generated. As noted above, in generating the TOTP the authentication application may take account of the time-delta in order to synchronise the time at the mobile device 100 with the time at the authentication server 105. This serves to ensure that the TOTPs correctly match and may assist in guarding against replay attacks against the authentication service.

[00102] At step 660 the authentication server determines whether the TOTPs match and whether the person 110 is entitled to access the restricted service. This may include checking if the combination of servicelD and the servicellRLJD is valid for this personID. Also the authentication server 105 checks if the shared secret is still valid in time by reference to the TTR. If one of these checks fails, or the TOTPs do not match, an error message may be sent and the login process aborted at step 665. The error message sent to the mobile device may include a value of the TTR, for instance zero, that causes preauthentication to be necessary before login can be attempted again. Otherwise, at step 670 the authentication server contacts the secure application server 510 for the servicellRLJD and passes the servicelD used for login and the sessionID. The authentication server testifies to the secure application server 510 implementing the restricted service that the personID for that person 110 and matching the servicelD has been voice authenticated within the necessary renewal interval and has presented an appropriate TOTP. This information may be additionally signed by the authentication server 105 and time stamped by a time authority to prove its authenticity. This information may be passed using a previously established and cryptographically secured OOB connection, for instance one which is secured by server and client x.509 certificates. The restricted service may then allow the person 110 full access. A confirmation message is also transmitted to the authentication application 130, which may optionally be displayed to the person 110.

[00103] As an alternative to the transmission of the TOTP to the authentication server, according to an alternative embodiment of the present invention the TOTP (or indeed any other form of cryptographic hash that may be used as part of the present invention) is not sent to the authentication server at all. Instead, the TOTP (or other hash) is used to encrypt at least part of the information that is transmitted from the mobile device 100 to the authentication server 105. As noted above, at the time of demonstrating that the mobile device 100 stores the shared secret, the sessionID and the servicelD, and optionally further information, is transmitted to the authentication server. At least part of the information that is identified for transmission to the authentication server may be encrypted using the TOTP. As one example, it may be the sessionID that is encrypted. Any suitable encryption algorithm may be used. By not sending the TOTP itself this prevents against a race condition attack whereby an attacker could seek to slowdown the connection between the first electronic device and the authentication server and themselves transmit the TOTP generated by the mobile device (and which they have intercepted) to the authentication server. While the TOTP is not transmitted, the authentication server may compute the TOTP as described above, for instance from knowledge of the servicelD or personID to identify the appropriate shared secret, and use this to decrypt the encrypted portion of the received information to verify that the mobile device stores the shared secret.

[00104] According to certain embodiments of the invention a shared secret may only be used a single time before requiring the person to undergo pre-authentication to obtain a new shared secret. This may readily be achieved by the authentication server sending to the mobile device a value of the TTR, for instance zero, that causes pre-authentication to be necessary before login can be attempted again.

[00105] As noted above, the primary described embodiment of the invention concerns a situation in which the person 110 wishes to login to a restricted service accessed via an electronic device such as a PC, laptop or another mobile device, which is separate from the mobile device upon which runs the authentication application 130. However, this separation is not a mandatory feature of the present invention. Indeed for mobile users, it may frequently be the case that they wish to access restricted services via the same mobile device used to run the authentication application. Indeed, in such a situation, the mobile device 100 providing the authentication application 130 may suitably be a laptop or any other mobile device. The restricted service may be accessed through a web browser or an application which is separate from the authentication application 130. Communication with a web browser providing the restricted service therefore continues to be via a separate channel, which is OOB, compared to communication between the authentication application 130 and the authentication server 105. This is despite the fact that the same air interface or wired interface is used to access the network. The OOB communication is maintained in view of the separate termination point of communications sent to the authentication server 105 and the separate encryption used to maintain the security of communications with the authentication server 105 through a cryptographically secured data channel, for instance the configured HSTS channel described above.

[00106] Clearly, where a restricted service is accessed on the same mobile device 100 it is not possible for the sessionID and the serviceURLJD information to be passed to the authentication application via a displayed QR code and the use of a camera. In this instance, the restricted service may display a button or other user interface element (optionally following the provision of authentication credentials to the restricted service) which when selected causes the authentication application to be opened and the sessionID and the serviceURLJD information to be directly passed. The button therefore provides a URL to a local resource: specifically, it points to the authentication application. The skilled person will be well aware of techniques whereby a user interface element within a displayed page may be used to invoke a local service or application. Other than this difference, the authentication service may proceed in the same fashion and order as the embodiment of the invention described above.

[00107] It will be appreciated that embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention.

[00108] Accordingly, embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.

Claims

CLAIMS:

1. A method of accessing a restricted service comprising: demonstrating by a first electronic device to an authentication server at the time of seeking access to a restricted service that the first electronic device stores a shared secret shared with the authentication server; determining at the authentication server whether the first electronic device stores the shared secret; and if the authentication server determines that the first electronic device stores the shared secret and a renewal time has not expired, transmitting confirmation from the authentication server to the restricted service that access to the restricted service is allowed.

2. A method according to claim 1, further comprising: transmitting authentication data, from the first electronic device to the authentication server; verifying the authentication data at the authentication server; transmitting a new shared secret from the authentication server to the first electronic device if the authentication data is verified at the authentication server; and storing the shared secret at the first electronic device.

3. A method according to claim 2, wherein the authentication data comprises biometric authentication data obtained from a person.

4. A method according to claim 3, wherein the biometric authentication data comprises a voice sample obtained from the person.

5. A method according to any one of the preceding claims, further comprising: transmitting the renewal time from the authentication server to the first electronic device along with the shared secret.

6. A method according to any one of the preceding claims, further comprising: determining at the first electronic device whether the renewal time has expired at the time of seeking access to a restricted service; and demonstrating by the first electronic device to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret only if it is determined that the renewal time has not expired.

7. A method according to claim 6, wherein if the authentication server transmits confirmation to the restricted service that access to the restricted service is allowed, the method further comprises: the authentication server setting the renewal time to an expired value; and transmitting the renewal time from the authentication server to the first electronic device.

8. A method according to claim 6 or claim 7, wherein if the authentication server determines that the first electronic device does not store the shared secret or that a renewal time has expired, the method further comprises: the authentication server setting the renewal time to an expired value; and transmitting the renewal time from the authentication server to the first electronic device.

9. A method according to any one of the preceding claims, wherein if the authentication server determines that the first electronic device stores the shared secret, the method further comprises determining at the authentication server whether the person is authorised to access the restricted service and only sending confirmation to the restricted service if the person is authorised.

10. A method according to any one of the preceding claims, wherein demonstrating to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret comprises sending, from the first electronic device to the authentication server, information demonstrating that the shared secret is stored at the first electronic device.

11. A method according claim 10, wherein sending, from the first electronic device to the authentication server, information demonstrating that the shared secret is stored at the first electronic device comprises: generating at the first electronic device a cryptographic hash using the shared secret; and transmitting the cryptographic hash from the first electronic device to the authentication server; and wherein verifying at the authentication server whether the first electronic device stores the shared secret comprises: generating at the authentication server a cryptographic hash using the shared secret; and comparing, at the authentication server, the received cryptographic hash and the cryptographic hash generated by the authentication server.

12. A method according claim 10, wherein sending, from the first electronic device to the authentication server, information demonstrating that the shared secret is stored at the first electronic device comprises: generating at the first electronic device a cryptographic hash using the shared secret; identifying information to be sent to the authentication server; encrypting at least part of the information to be sent to the authentication server using the cryptographic hash; and transmitting the encrypted information from the first electronic device to the authentication server; and wherein verifying at the authentication server whether the first electronic device stores the shared secret comprises: generating at the authentication server a cryptographic hash using the shared secret; and decrypting the encrypted information received by the authentication server.

13. A method according to claim 11 or claim 12, wherein generating the cryptographic hash comprises generating a One Time Password, OTP, or a Time-based OTP, TOTP, using the shared secret and a counter value or a time value.

14. A method according to any one of the preceding claims, further comprising: obtaining at the first electronic device a session identifier from the restricted service; sending the session identifier from the first electronic device to the authentication server when demonstrating that the first electronic device stores the shared secret; and using, by the authentication server, the session identifier to determine the restricted service to which confirmation is to be sent that the person to authorised access the restricted service.

15. A method according to claim 14, further comprising providing authentication data to the restricted service and only receiving the session identifier if the authentication data is verified by the restricted service.

16. A method according to claim 14 or claim 15, further comprising connecting to the restricted service through the first electronic device and receiving the session identifier via a secure application server providing the restricted service.

17. A method according to claim 16, wherein communication with the authentication server and storing of the shared secret at the first electronic device is performed by an authentication application which is separate from a secure application server used to access the restricted service; and wherein the session identifier is passed to the authentication application in response to a user input to the separate service application or web browser.

18. A method according to claim 14 or claim 15, further comprising connecting to the restricted service through a separate, second electronic device; wherein obtaining at the first electronic device a session identifier from the restricted service comprises obtaining the session identifier from the second electronic device.

19. A method according to claim 18, wherein obtaining the session identifier from the second electronic device comprises: displaying a visual representation of the session identifier on a screen within or connected to the second electronic device; and capturing the visual representation of the session identifier through a camera within or connected to the first electronic device.

20. A method according to any one of the preceding claims, further comprising performing local authentication to the first electronic device and only demonstrating that the first electronic device stores the shared secret in response to successful local authentication.

21. A method according to any one of the preceding claims, further comprising sending a person identifier or a service name identifier from the first electronic device to the authentication server when demonstrating that the first electronic device stores the shared secret; and determining, at the authentication server, the shared secret for that person using the person identifier or service name identifier prior to verifying that the first electronic device stores the shared secret.

22. A method according to claim 21, further comprising selecting at the first electronic device one of a plurality of service name identifiers and sending the selected service name identifier to the authentication server when demonstrating that the first electronic device stores the shared secret; wherein if the authentication server verifies that the first electronic device stores the shared secret, the method further comprises the authentication server determining whether that service name identifier is authorised to access the restricted service.

23. A method of operating a first electronic device to access a restricted service, the method comprising: demonstrating by the first electronic device to an authentication server at the time of seeking access to a restricted service that the first electronic device stores a shared secret shared with the authentication server; wherein if the demonstration is verified by the authentication server, access to the restricted service is allowed.

24. A method according to claim 23, further comprising: transmitting authentication data, from the first electronic device to the authentication server; receiving a new shared secret from the authentication server if the authentication data is verified at the authentication server; and storing the shared secret at the first electronic device.

25. A method according to claim 24, further comprising: receiving a renewal time from the authentication server along with the shared secret; determining at the first electronic device whether the renewal time has expired at the time of seeking access to a restricted service; and demonstrating by the first electronic device to the authentication server at the time of seeking access to a restricted service that the first electronic device stores the shared secret only if it is determined that the renewal time has not expired.

26. A method of operating an authentication server to access a restricted service, the method comprising: determining at the authentication server whether a first electronic device stores a shared secret shared with the authentication server from a demonstration by the first electronic device at the time of seeking access to a restricted service that the first electronic device stores the shared secret; and if the authentication server determines that the first electronic device stores the shared secret and a renewal time has not expired, transmitting confirmation from the authentication server to the restricted service that access to the restricted service is allowed.