COMMUNICATIONS SYSTEMS

Technical Field

The invention relates generally to the field of communications. One aspect of the invention relates to techniques for user authentication in communications systems. Another aspect of the invention relates to techniques for validating communications. Yet another aspect of the invention relates to a security module and client application implemented on a client device for providing assertions to a server device for authentication or validation. The invention is particularly, although not exclusively, applicable to the authentication or validation of user assertions during financial transactions over a communications network.

Background

In communications systems, a user of a client device is frequently required to provide authentication information over a communications network, in order to communicate and perform online transactions with a server device. Authentication information is used to verify the identity of the user, in order to verify that the user is genuine and is authorised to access the server device and perform a transaction. Authentication of a user may be necessary for transactions that allow access to confidential data over the communications network, transactions that authorise financial payment over the communications network and so on. Authentication information can be in the form of traditional user credentials, such as a username and a password known only to the user. However, traditional user credentials are vulnerable to theft, being cracked and other forms of attack. Thus, authentication techniques that rely solely on user credentials do not reliably verify a user, for example with a desired level of confidence. More sophisticated authentication techniques require the user to enter a one-time password (OTP), which is sent in real time by the server device to the user's device, to provide a second level of user authentication. However, authentication techniques that rely on an OTP may be vulnerable to hijack by fraudulent devices and applications.

Thus, existing authentication techniques may not be able to verify a user with sufficient reliability or confidence for some purposes, such as communications involving higher value transactions or transactions on user accounts that are considered to require enhanced security, such as transactions at high risk of fraudulent activity.

Summary

Aspects of the invention are as set out in the independent claims. Some optional features are defined in the dependent claims.

Implementation of the techniques disclosed herein may provide significant technical advantages. In particular, the techniques lead to more reliable user authentication and validation of security information for improved security in communications systems and networks.

In example implementations, a security module of a client application on a client device leads to more reliable user authentication by performing biometric authentication as a prerequisite to the generation of user messages. The message payload is signed by generating a digital signature using a private key of a public- private signature key pair, which can only be accessed after successful biometric authentication. This creates a binding association between the biometric information of the user and the cryptographic signature key pair used to confirm the sender of the message and verify the integrity thereof. An authentication and security module of a server device, for example an authentication server, is able to authenticate the sender of the message with a greater degree of confidence, simply by validating the signature attached to the message payload using the public signature key of the signature key pair. Further, use of a third level security mechanism such as an encryption mechanism using an application-specific key as described below which makes use of an obfuscated encryption key may help to guarantee to provide validation that the message originated from a genuine security module associated with the application with a greater degree of confidence, and may reduce the risk of fraudulent apps hijacking the authentication processes.

In some implementations, the digital signature is generated in a secure environment, such as a Trusted Execution Environment, of the client device. Access to the private signature key is limited solely to the secure environment of the communications device. This further enhances the security and integrity of user messages sent by the client device.

In example implementations, the security module of the client application encrypts user messages with an encryption key, prior to sending to the server device. Successful decryption of a received user message by the authentication server using the corresponding decryption key enables validation that the message originated from a genuine security module associated with the application with a greater degree of confidence.

Accordingly, in at least some implementations, the techniques disclosed herein facilitate improved user authentication and security information validation, leading to improved security in communications systems compared to existing techniques, by implementing a three-stage procedure in a client application running on a client device. Further details are described below.

In implementations, the functionality of the techniques disclosed herein may be implemented in software running on a handheld communications device, such as a mobile phone (herein also referred to as "user device" or "client device"). The software which implements the functionality of the techniques disclosed herein may be contained in a client application known as an "app" - a computer program, or computer program product - which the user has downloaded from an online store. When running on the, for example, user's mobile telephone, the hardware features of the mobile telephone may be used to implement the functionality described below, such as using the mobile telephone's transceiver components to establish a communications channel with an authentication server as described herein.

Brief Description of the Drawings

Implementations of the present disclosure will now be described, by way of example only, and with reference to the accompanying drawings in which:

Figure 1 is a schematic block diagram illustrating a communications system comprising a server device for authenticating a user of a client device in accordance with example implementations of the present disclosure;

Figure 2 is a schematic block diagram illustrating a client device comprising a secure client application in accordance with example implementations of the present disclosure;

Figure 3 is a schematic block diagram illustrating a server device comprising secure authentication functionality in accordance with example implementations of the present disclosure;

Figure 4 is a flow diagram illustrating a method for enrolment of a user of a secure client application in a client device in accordance with example implementations of the present disclosure;

Figure 5 is a flow diagram illustrating a method for enrolment of a user of a secure client application in a server device in accordance with example implementations of the present disclosure;

Figure 6 is a flow diagram illustrating a method for authentication of a user of a secure client application in a client device in accordance with example implementations of the present disclosure; and Figure 7 is a flow diagram illustrating a method for authentication of a user of a secure client application in a server device in accordance with example implementations of the present disclosure.

In the drawings, similar reference signs are used to denote similar features.

Detailed Description

Referring first to Figure 1, a communications system 100 is illustrated. Communications system 100 comprises communications server apparatus (server device) 102, a first client communications apparatus (first client device) 104 and a second client communication apparatus (second client device) 106 connected to a communications network 108 (for example the Internet) through respective communications links 110, 112, 114 implementing, for example, internet or other data communications protocols. Communications network 108 may comprise any wired and/or wireless communications network or combination of networks. Thus, client devices 104, 106 may be able to communicate with server device 102 through various communications networks, such as public switched telephone networks (PSTN networks), mobile cellular communications networks (3G, 4G or LTE networks), local wired and wireless networks (LAN, WLAN, WiFi networks) and the like.

Server device 102 may be a single server as illustrated schematically in Figure 1, or its functionality may be distributed across multiple servers. For example, server device 102 may comprise multiple servers including, for example, an authentication server for providing user authentication/security functionality, an account server for providing user account management functionality and a web server for providing user transaction processing functionality. One such arrangement is illustrated in Figure 3, which is discussed in further detail below. In the example of Figure 1, server device 102 may comprise a number of individual components including, but not limited to, one or more microprocessors 116, a memory 118 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 120, the executable instructions defining the functionality of the server 102 carries out under control of the processor 116. Server device 102 also comprises an input/output (I/O) module 122 allowing the server to communicate over the communications network 108.

User interface 124 is provided for user control and may comprise, for example, computing peripheral devices such as display monitors, computer keyboards and the like. Server device 102 may also comprise a database 126, the purpose of which will become readily apparent from the following discussion.

First client device 104 may comprise a number of individual components including, but not limited to, one or more microprocessors 128, a memory 130 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 132, the executable instructions defining the functionality the client device 104 carries out under control of the processor 128. First client device 104 also comprises an I/O module 134 allowing the client device 104 to communicate over the communications network 108. User interfaces 136 are provided for user control. If the first client device 104 is, say, a portable communications device such as a smart phone or tablet device, the user interfaces 136 will have a touch panel display as is prevalent in many smart phone and other handheld devices. Alternatively, if the first client device is, say, a desktop or laptop computer, the user interface may have, for example, computing peripheral devices such as display monitors, computer keyboards and the like. User interfaces 136 may also comprise a microphone and the like.

Second client device 106 may be, for example, a smart phone or tablet device with the same or a similar hardware architecture to that of first client device 104. In example implementations, first client device 104 may be a user device of a consumer of a service associated with server device 102, and second client device 106 may be a user device of a service provider of a service associated with server device 102. In other example implementations, first and second client devices 102, 104 may be user devices of the same or different categories of user associated with one or more functionalities of the server device 102.

Figure 2 illustrates a client device 204 in accordance with example implementations of the present disclosure. For example, client device 204 may be used as first client device 106 or second client device 106 of the communications system 100 illustrated in Figure 1. Client device 204 comprises processing unit 228, memory unit 230, I/O unit 234 and user interfaces 236, as described above in relation to Figure 1. In addition, client device 204 may comprise other components (not shown) typically included in a portable communications device, such as a voice communications module, a camera, an accelerometer, a position locator (e.g., global navigation satellite system module) and the like.

Memory unit 230 stores a plurality of instruction modules 232 comprising executable instructions including operating system 234 and client applications ("apps") 236. In addition, memory unit 230 stores user and device data 238. Operating system 234 manages the overall operation of the client device 204 and provides common services for client applications 236. In accordance with the present disclosure, operating system 234 comprises biometric authentication functionality for device security, which limits access to the client device 204, for example, to a single biometrically authenticated user that has provided their biometric information on setup or subsequently. Examples of biometric authentication functionality of operating system 234 include fingerprint recognition, facial recognition, iris/retina recognition and the like. A user may initially provide biometric information using, for example, a camera of the client device 204 or a touchscreen of the client device 204 incorporating a fingerprint scanner. Mobile operating systems, such as Android and iOS of Apple Inc., typically include at least one biometric authentication functionality in addition to a traditional authentication functionality based on user credentials for security of the client device 204. Client device 204 further comprises a secure element 239, discussed in further detail below. While secure element 239 can be implemented in either hardware or software, in the example of Figure 2, it is implemented in hardware.

Client applications 236 may comprise individual mobile applications that provide specific user functions in client device 204. Client applications 236 may also comprise web applications that communicate with a server device (not shown in this Figure) over a network to provide specific user functions that may involve secure communications, online transactions and the like as described herein. Client applications 236 may be pre-installed in client device 236 by the vendor, or may be downloaded and installed by the user from a so-called "App store".

During operation of client device 204, processing unit 228 executes instructions of operating system 234 and may execute one or more client applications 236, launched by the user and running on client device 204, under the control of operating system 234. Processing unit 228 may include one or more central processors, such as a microprocessor, including a Trusted Execution Environment (TEE) 225. TEE 225 comprises an isolated execution environment that provides security features as known in the art. Processing unit 228 may also comprise other processors such as a graphics processor, image processor and so on (not shown).

The illustrated client device 204 is installed with a secure application 250, which is typically downloaded and installed by a user as described above, in accordance with the present disclosure. In particular, secure application 250 comprises app functions module 252 and security module 254. App functions module 252 comprises instructions for executing the functionality of the client application (i.e., app functions), which includes data communications with an associated server device (not shown in this Figure) via I/O unit 234 over network 208. Examples of app functions include online shopping applications, online service booking applications, online banking applications and the like. Security module 254 comprises an integrated security engine that executes instructions that provide dedicated security functionality for secure application 250. In the illustrated secure application 250, security module 254 implements a three-layered security mechanism for the provision of user authentication and security information in data communications sent to the server device. In particular, biometric challenge module 262 provides a first level security mechanism, payload signature module 264 provides a second level security mechanism and message encryption module 266 provides a third level security mechanism. Biometric challenge module 262, payload signature module 264 and message encryption module 266 comprise data and instructions as described below. In an alternative arrangement, the third level security mechanism can be provided by application of a second digital signature. This may be a preferable solution if confidentiality of the user message - as may be provided if the third level security mechanism is an encryption mechanism - is not required.

Security module 254 implements a secure authentication procedure when a user operates secure application 250, and, in particular, sends an application transaction request or similar communication to the associated server device requiring user authentication. In particular, app functions module 252 may initiate the generation of a transaction request message in response to user entered data relating to the requested transaction. For example, the transaction may seek to order a service at a particular time and location, and so a user may enter data specifying the required service, time and location. App functions module 252 may determine that the particular transaction request message requires secure authentication before the transaction request is sent to the associated server device. Accordingly, app functions module 252 may trigger the secure authentication procedure of security module 254.

In a first stage of the authentication procedure, biometric challenge module 262 provides a biometric challenge to the user of the client device 204. In particular, biometric challenge module 262 may invoke the biometric authentication functionality of operating system 234, as described above. The biometric authentication functionality may provide a graphical user interface (GUI) requesting the user to provide biometric information, compare the biometric information provided by the user with prestored biometric information, and, if there is a match, validate the identity of the user. If the identity of the user is validated, the authentication procedure proceeds to a second stage.

In the second stage of the authentication procedure, payload signature module 264 provides a payload of the transaction request to the TEE 225. The payload includes data provided by the app functions module 252. The payload may further include additional data for enhanced security, including a key reference (as described below) and a combination of other user-specific data, such as a login token, that is unique to the user/secure application 250. TEE 225 adds a nonce and timestamp to the payload and securely signs the payload with a private "signature key", such as a private key of an Elliptic Curve Cryptography (ECC) private-public key pair or the like. The private ECC key is unique to the secure application 250 and is generated during an initial user enrolment procedure with the server device that provides the abovementioned key reference. The enrolment procedure is described in further detail below. The private ECC key is stored in a secure element of the client device 204. As is known, a secure element 239 comprises a secure component associated with a Trusted Execution Environment. The private ECC key/secure element is only accessible to the TEE 225 after successful biometric authentication in the first stage. Thus, the private ECC key is not accessible to any part of the secure application 250, including the payload signature module 264. The TEE 225 provides the signed payload to the message encryption module 266 for a third stage.

In the third stage of the authentication procedure, the message encryption module 266 encrypts the signed payload provided by TEE 225 with an "encryption key", such as a first key of an encryption key pair associated with the server device. The encryption key is included in the secure application 250 downloaded to the client device 204, and so may be considered as a "service encryption key". In example implementations, the service encryption key is obfuscated in the secure application 250 by suitable stenographic encoding techniques for securely encoding secret data. Thus, the service encryption key used for encryption by message encryption module 266 is not readily accessible from the code of the secure application 250 or vulnerable to attackers. As the skilled person will appreciate, the service encryption key is therefore secret, but is common to all genuine instances of secure application 250 running on different client devices for encrypting messages sent to the associated server device.

Upon completion of the third stage of the authentication procedure, the signed and encrypted transaction request message is sent by secure application 250 to associated server device for reliable authentication of the user and validation of the client device 204 and/or the secure application 250 as described herein.

Accordingly, the authentication procedure carried out by security module 254 in accordance with the described example implementations provides enhanced security for user transaction requests sent by secure application 250. In particular, the first stage authenticates the user by validating identity based on biometric information using operating system functionality of the client device 204. Thus, biometric information is securely retained on the client device 204, and a trust association is created between the user, client device 204 and secure application 250. The second stage may add unique user and/or device data to the payload, and the TEE 225 gains access to a secure private ECC key and signs the payload. Thus, the second stage provides hardware backed security to the signed payload after authentication of the user. The third stage encrypts the signed message using an obfuscated service encryption key. This guarantees that the message can only come from a genuine secure application 250, and reduces the risk of fraudulent apps hijacking the authentication processes. Figure 3 illustrates a server device 302 in accordance with example implementations of the present disclosure. For example, server device 302 may be associated with the secure application 250 of the client device 204 illustrated in Figure 2. Server device 302 comprises processing unit 316, memory unit 318, I/O unit 322, user interfaces 324 and database 326, as described above in relation to Figure 1.

Memory unit 318 stores a plurality of instruction modules 320 comprising executable instructions for performing server operations that process data communications, such as user transaction request messages, received from secure applications running on client devices (not shown in this figure) over network 308 via I/O unit 322. In particular, instruction modules 320 include transaction processing module 342, account management module 344 and authentication and security module 360.

During operation of server device 302, processing unit 316 executes instructions of transaction processing module 342, account management module 344 and authentication and security module 360 in response to user transaction request messages and other communications received from client devices (not shown in this figure) via I/O unit 322 over network 308. Processing unit 316 may include one or more central processors, such as a microprocessor.

Transaction processing module 342 performs processing associated with communications including user transaction requests received from secure applications, and generates transaction responses, accordingly. Account management module 342 performs processing to create and manage user accounts, which are stored in database 326. For example, account management module 344 may perform processing to create and/or manage a user account, such as during an enrolment procedure as described below with reference to Figure 4. In addition, account management module 344 may associate information relating to received user transaction requests and other communications with user accounts, as described below with reference to Figure 5. Authentication and security module 360 may perform processing associated with authentication and security functions in relation to received user transaction requests. For example, authentication and security module 360 may verify login credentials associated with the user. In addition, authentication and security module 360 may perform further authentication and security processes on received user transaction requests, as described herein.

In accordance with the present disclosure, authentication and security module 360 implements a security procedure for validating authentication and security information in data communications, such as user transaction requests, received from a secure application running on a client device as described herein. In particular, authentication and security module 360 implements the security procedure when receiving certain transaction requests requiring user authentication and validation. For example, such a transaction request may be generated by secure application 250 of client device 204 of Figure 2, which has been processed in accordance with the first, second and third stages of the above described authentication procedure carried out by security module 254.

Accordingly, the security procedure of authentication and security module 360 of server device 302 mirrors aspects of the three-stage authentication procedure of security module 254 of the secure application 250 of client device 204. In particular, authentication and security module 360 comprises message decryption module 376, user identification module 372, signature verification module 374 and security validation module 378.

When the server device 302 receives a communication for validating authentication and security information, such as an encrypted and signed user transaction request, the message is passed to authentication and security module 360 for performing the security procedure.

IB In a first stage of the security procedure, message decryption module 376 decrypts the message with the second key of the encryption key pair described above, which is known only to the server device 320. The second key may be considered as a "service decryption key", as it is used for decrypting messages received from all instances of the associated secure application running on different client devices. Successful decryption of the message payload provides a guarantee that the message came from a genuine secure application, since the service encryption key used for encryption is obfuscated. The decrypted payload includes security data including a key reference. The decrypted payload may include one or more other user specific data, such as a login token, that is unique to the user/secure application, as described above.

In a second stage of the security procedure, signature verification module 374 looks up the public signature key, such as the public key of an Elliptic Curve Cryptography (ECC) private-public key pair described above, and verifies the signature applied to the payload. Signature verification confirms that the private ECC key signed the message payload. Furthermore, in implementations described herein, signature verification confirms that the payload was securely signed by the TEE using a secure element of the client device, as described below. Thus, signature verification verifies the client device and secure application that signed the message, and, in consequence, reliably authenticates the user due to the trust in the biometric authentication procedure necessarily performed by the secure application of the client device prior to signature.

In a third stage of the security procedure, which may occur at any time after the first stage, user identification module 372 may verify the user, and thus identify the user's account, for example from the decrypted user specific data such as login tokens, the identity of the secure application and/or client device. In a fourth stage of the security procedure, which may also occur at any time after the first stage, security module 378 may perform other security checks such as checking the validity of the nonce, and the freshness of the message using the timestamp, included in the signed message payload.

In the above implementations, two key pairs are used for secure data communications between a secure application running on a client device and the associated server device. One of the key pairs is the above described "signature key" pair (typically an asymmetric key pair) and the other key pair is the above described "service/encryption key" pair (a symmetric or asymmetric key pair). One of the two key pairs - the "service" key pair - is predetermined and included in the secure client application, and the other one of the two key pairs - the "signature" key pair - is generated by the client device during an enrolment procedure as described below.

Figure 4 is a flow diagram illustrating a method 400 for enrolment with a server device associated with a secure client application in accordance with example implementations of the present disclosure. For example, the method 400 may be performed by secure application 250 running on client device 204 of Figure 2.

The enrolment method 400 is performed after installation of the secure application ("app") on the client device and before first use by the user. As indicated above, the secure application may be pre-installed on the client device or downloaded from an app store. In accordance with example implementations, secure application includes the service encryption key, which is obfuscated as described above, to be used by the secure application to encrypt data communications sent to the server device.

For ease of description, in the following example, it is assumed that the user has already set up a user account with the server device associated with the secure application, and so is able to gain access to the account using conventional login credentials. The method 400 starts at step 405. For example, method 400 may start in response to a user launching the secure application on the client device for the first time and interacting with a graphical user interface (GUI) of an enrolment screen of the secure application.

At step 410, the user logs in to their user account with the associated server device. For example, the user may enter login credentials, such as a username and password, which may be verified by an account management module associated with the server device. In addition, a one-time password may be sent to the user and successfully entered to complete the login procedure. Upon successful completion of the login procedure, the method proceeds to step 420.

At step 420, the user provides information for second factor authentication, for the purpose of validating presence of the user. In particular, the user may provide second factor identification information sufficient to assert that a user is present, such as entering a unique personal identification number (PIN) known only to the user or taking a "selfie" photograph. This may be used as a second level authentication to biometric authentication as described herein.

At step 430, the user performs biometric authentication on the client device in order to enrol for biometric authentication as described herein. In particular, the user is asked to provide biometric authentication information to a biometric authentication process of the operating system of the client device as described above. If biometric authentication is successful, the method proceeds to step 440.

At step 440, the method generates an asymmetric "signature key" pair, such as an ECC key pair as described above. Step 440 stores the private ECC key in a secure element of the client device, which is only accessible to the TEE of the client device following successful biometric authentication and is not accessible to other components of the client device. The private ECC key/secure element is stored for the purposes of signing a message payload. In example implementations, the private ECC key/secure element is invalidated if any of the security properties of the client device are changed, such as the device PIN and user biometric information used to gain access to the client device.

At step 450, the method generates an enrolment request message. Enrolment request message includes a payload comprising the public ECC key generated in step 440 and the second factor identification information provided by the user in step 420. The payload may include additional information such as a nonce and a timestamp.

At step 460, the method encrypts the enrolment message with the (obfuscated) service encryption key, and sends the encrypted enrolment request to the associated server device for enrolment processing.

The server device comprises an authentication server which performs a security procedure, for validating authentication and security information, as part of the enrolment processing. In particular, the authentication server may perform the method described below with reference to Figure 5. Briefly, the authentication server decrypts the payload using the private encryption key. The decrypted payload may be validated, for example by checking the nonce and timestamp, and validating the second factor authentication information for the user. The server device then stores the public ECC key with other user data, for example in the existing user account, and generates a corresponding "key reference" that uniquely identifies the signature ECC key pair. The service device them generates an encryption enrolment response message including the key reference. In implementations, the encryption enrolment response message may be encrypted using the private/service encryption key known only to the server device. At step 470, the method receives the encryption enrolment response from the server device, and, if appropriate, may perform decryption of the message payload using the encryption key.

At step 470, the method stores the key reference for the ECC key pair contained in the encryption enrolment response message for use in subsequent instances of the authentication processes by the client device. The method then ends at step 485.

Figure 5 is a flow diagram illustrating a method 500 for enrolment of a user of a secure client application by a server device in accordance with example implementations of the present disclosure. For example, the method 500 may be performed by authentication and security module 360 of server device 302 of Figure 3. In the following description, for ease of reference, authentication and security module 360 is called an authentication server. The method 500 may be performed by the server device in conjunction with the method 400 of Figure 4 performed by a client device. The method 500 performs a security procedure as part of the enrolment processing.

The method 500 starts at step 505. The method 500 may start in response to a server device receiving an enrolment request message from an associated secure application running on the client device, and passing the request to the authentication server.

At step 510, the authentication server decrypts the payload of the received enrolment request message using the service decryption key.

Step 520 considers whether the decryption in step 510 was successful. If step 520 determines that decryption was successful, the received enrolment request message originated from a genuine secure application on a client device and the method proceeds to step 530. Otherwise, the received request message fails the security procedure and the method ends at step 565.

At step 530, the authentication server validates the decrypted payload. For example, authentication server may check the validity of the nonce and freshness of the timestamp. Authentication server may validate second factor authentication information for the user.

Step 540 considers whether all validation checks performed in step 530 were successful such that the payload is validated. If step 540 determines that the decrypted payload is validated by all the validation checks in step 530, the received message passes the security procedure and the method proceeds to step 550. Otherwise, the received request fails the security procedure and the method ends at step 565.

At step 550, the authentication server stores the public ECC key contained in the decrypted payload, with other user data for the user, for example in the user account. In particular, the public ECC key is stored as the public signature key for validating the user/client device as described herein. In addition, the server generates a corresponding "key reference" that uniquely identifies the signature (ECC) public-private key pair. This completes the enrolment of the user and the secure application for use with biometric authentication as described herein.

At step 560, the authentication server generates an encryption enrolment response message including the key reference in the message payload, and sends the response to the client device. In implementations, the encryption enrolment response message may be encrypted using the service encryption key. The method ends at step 565. Figure 6 is a flow diagram illustrating a method 600 for authentication of a user with a server device associated with a secure client application in accordance with example implementations of the present disclosure. For example, the method 600 may be performed by secure application 250 running on client device 204 of Figure 2. The method 600 may be performed when the secure application sends data communications, such as transaction requests and other messages that require authentication and validation, to the associated server device after the enrolment procedure of Figure 4.

The method 600 starts at step 605. For example, method 600 may start in response to the user launching the secure application on the client device, logging in to the user account and entering user data for a transaction request (i.e., transaction information) using a graphical user interface (GUI) of an associated screen of the secure application. In some implementations, method 600 may be triggered by certain types of user transactions, such as all or relatively high value financial transactions (e.g., the use authorises a financial payment). In other implementations, method 600 may be triggered for some or all user transactions of a user or client device that has been identified as requiring additional security, such as having a high risk of fraud. Thus, step 605 may include receiving user input transaction information for forming at least part of a payload of a transaction request message.

At step 610, the user performs biometric authentication. In particular, the user is asked by the secure application to provide biometric authentication information to a biometric authentication process of the operating system of the client device as described above.

At step 620, the method determines whether the biometric authentication in step 610 was successful. If step 620 determines that the biometric authentication in step 610 was successful, the method proceeds to step 630. However, if step 630 determines that the biometric authentication in step 610 was not successful, the user may be notified that the transaction request is cancelled and the method ends at step 665.

At step 630, the secure application creates a transaction request message payload and provides it to the TEE of the client device. In particular, the secure application creates a payload including the user input transaction information and the above described key reference. The payload may include additional information such as the user's primary login information and optionally second factor authentication information entered by the user. In example implementations, the payload includes a combination of user-data, such as a login token, that is unique to the user secure application, as described above.

At step 640, the TEE may add a nonce and a timestamp to the payload and securely signs the payload with a private signature (ECC) key stored in a secure element of the client device. For example, TEE may generate a digital signature by hashing the message payload to create a hash value and encrypting the hash value with the private (ECC) signature key/secure element, and may add the digital signature to securely sign the message. Since step 620 determined that the biometric authentication in step 610 was successful, TEE is able to gain access to the private ECC key/secure element of the client device as described above. In some implementations, the key reference is added to the message payload after the TEE has generated the digital signature of the message payload. The method then proceeds to step 650.

At step 650, the secure application encrypts the signed transaction request message with the service encryption key, and sends the encrypted request to the associated server device for processing the transaction request. The server device may comprise an authentication server which performs a security procedure as part of the transaction request processing. In particular, the authentication server may perform the method described below with reference to Figure 7. Briefly, the authentication server decrypts the payload using the decryption key (i.e., the service decryption key). Since the decrypted payload includes the key reference, the server can look up the associated public signature key and validate the signature. The authentication server may perform other security processes using other information in the decrypted payload, such as checking the nonce and timestamp, and validating any primary or second factor authentication against an associated identifier for the user. Upon successful completion of the security procedure, the authentication server may generate a token that is returned to the secure application of the client device (or, alternatively, change the session state accordingly). The server device is then able to proceed to process the transaction request.

At step 660, the secure application may receive a response from the server device, confirming successful authentication. The method then ends at step 665.

Accordingly, there is provided a client communications device for generating a user message comprising an assertion for verification by a remote server device. The communications device comprises a processor and a memory. The communications device is configured, under control of the processor, to execute instructions stored in the memory to: receive payload data for the user message; perform biometric authentication of the user, the biometric authentication comprising receiving input biometric information from the user and validating the input biometric information against biometric information for the user previously stored in the memory; in response to successful biometric authentication of the user, generate a digital signature based on the message payload, wherein the digital signature is generated using a private signature key stored in a secure element of the communications device, wherein the private key is accessible only when the biometric authentication of the user is successful, and generate the user message for sending to the remote device, the user message comprising the message payload and the digital signature. A corresponding method is also provided.

Figure 7 is a flow diagram illustrating a method 700 for authenticating and validating transaction requests of a user of a secure client application by a server device in accordance with example implementations of the present disclosure. For example, the method 700 may be performed by authentication and security module 360 of server device 302 of Figure 3. In the following description, for ease of reference, authentication and security module 360 is called an authentication server. The method 700 may be performed by the server device in conjunction with the method 600 of Figure 6 performed by a client device. The method 700 performs a security procedure prior to processing a received transaction request.

The method 700 starts at step 705. The method 700 may start in response to a server device receiving a transaction request message from an associated secure application running on the client device, and passing the request to an authentication server.

At step 710 the authentication server decrypts the message payload of the received transaction request message using the service decryption key.

Step 720 considers whether the decryption in step 710 was successful. If step 720 determines that decryption in step 710 was successful, the received transaction request message originated from a genuine secure application on a client device and the method proceeds to step 730. Otherwise, the received request message fails the authentication and security procedure and the method ends at step 775.

At step 730, the authentication server uses the key reference included in the decrypted message payload to look up the associated public signature ECC key and validates the signature of the signed payload. For example, the authentication server may generate a digital signature using the public ECC key based on the message payload, and compare the generated signature with the received signature in the signed payload; if the comparison indicates a match, the signature in the message is valid.

Step 740 considers whether the signature was validated in step 730. If step 740 determines that the signature is valid, the method can trust that the user has been biometrically authenticated at the client device and the method proceeds to step 750. Otherwise, the received request message fails the authentication and security procedure and the method ends at step 775.

At step 750, the authentication server validates the decrypted payload. For example, the authentication server may check the validity of the nonce and freshness of the timestamp, and may validate second factor authentication information and the like for the user.

Step 760 considers whether all validation checks performed in step 750 were successful such that the payload is validated. If step 760 determines that the decrypted and signature-verified payload is validated by all the validation checks in step 750, the received request message passes the security procedure and the method proceeds to step 770. Otherwise, the received request fails the security procedure and the method ends at step 575.

At step 770, the authentication server generates a token, which may be returned to the secure application of the client device, indicating that the received message has passed the authentication and security checks (or, alternatively, the session state is changed accordingly). The server device is then able to proceed to process the transaction request. The method then ends at step 775. Accordingly, there is provided a server communications device for verifying an assertion in a user message received from a remote client device. The communications device comprises a processor and a memory. The communications device is configured, under control of the processor, to execute instructions stored in the memory to: validate a digital signature in the payload of the received user message, using a public signature key and the message payload, and if the digital signature is validated, determine that the user of the remote device has been biometrically authenticated at the remote device. In example implementations, the communications device is further configured, under control of the processor, to execute instructions stored in the memory to: identify a key reference in the payload of the received user message, and look up the public signature key corresponding to the key reference stored in memory of the communications device.

In summary, a client communications device and method for generating a user message comprising an assertion for verification by a remote server device is described. Payload data for the user message is received. Biometric authentication of the user is performed. If biometric authentication of the user is successful, a digital signature is generated based on the message payload. The digital signature is generated using a private signature key stored in a secure element of the client device. In implementations, the digital signature is generated in a secure environment of the client device which has sole access to the secure element after successful biometric authentication. The user message comprising the message payload and the digital signature is generated for sending to the remote server device. A corresponding server communications device and method is also described.

The example implementations of the present disclosure described herein enable improved security in communication systems. In particular, a binding association is created between biometric authentication of the user and a signature of a signed assertion (message payload), since a valid signature can only be applied upon successful biometric authentication. Thus, a server can trust that the user has been biometrically authenticated merely upon successful validation of the signature applied to the assertion (message payload). The use of biometric authentication provides a simpler, more secure and low-cost solution in authentication scenarios, by leveraging existing functionality of the client device. Any form of biometric authentication is possible, which may be selected by the user during enrolment. Thus, the described secure application may be implemented on any type of client device from entry-level to high-end, provided at least one form of biometric authentication mechanism is available. The use of biometric authentication is more convenient to the user since it does not rely on remembering detailed user credentials. The binding association is additionally hardware backed, since assertions are signed in a secure environment, such as the TEE, of the client device.

Furthermore, signed assertions such as user transaction request messages are encrypted prior to communication. Encryption security is enhanced since the encryption key is obfuscated; non-genuine applications are therefore unable to validly perform encryption without being detected by the server device.

Finally, some example implementations include other security features, such as a nonce and/or timestamp, and/or a combination of data that is unique to the user/secure application, in the message payload for verification. This enhances security against fake applications/devices and banned users, which can be automatically detected by the security procedure performed at the server device. Thus, the three-level security mechanism in accordance with the present disclosure more robustly prevents improper access to user accounts and minimises the possibility of successful account takeover by attackers.

Aspects of the present disclosure are described herein with reference to flow diagrams. It will be understood that the steps in the illustrated implementations are by way of example. The steps may be carried out in any suitable order, and some of the steps may be omitted accordingly to application requirements. It will be understood that the steps of the flow diagrams, and combinations of steps, can be implemented by computer readable program instructions. It will be appreciated that the invention has been described by way of example only. Various modifications may be made to the techniques described herein and their equivalents without departing from the spirit and scope of the appended claims. The disclosed techniques comprise techniques which may be provided in a stand-alone manner, or in combination with one another. Therefore, features described with respect to one technique may also be presented in combination with another technique.