Field of Invention

The present invention relates to a method and apparatus for user authentication, in particular, involving use of keys of a digital certificate for a cryptographic challenge in a push notification process of a push notification server.

Background

Two factor authentication (2 FA) or Multi-Factor Authentication (MFA) has been widely used across many applications that require an additional layer of security, such as banking. The use of just a username and a password (password refers to one factor - something you know) is deemed as the lowest form of security in today’s threat landscape. 2FA or MFA improves on username/password by requiring a second (or multiple) factors. There are three classes of factors - 1 ) something you KNOW (e.g. password), 2) something you HAVE (e.g. One-Time-Password (OTP) token or PIN via Short Message Service (SMS)) and 3) something you ARE (biometric). One cannot use more than one factor from each class, so password and/or fingerprint are okay or password and/or SMS/OTP PIN are okay, but two passwords are regarded as just one factor. Three factors would require one factor from each of the three classes, e.g. password, OTP/SMS PIN and fingerprint.

Passwords are not viable, as there are many ways to capture or harvest them from online systems (e.g. mass credential harvesting from a server by getting a copy of the username/password database, or capturing the password as it is typed with a Trojan). It is also very difficult for users to create and manage good passwords, and even with strong ones, they can be captured in various ways. This is a problem especially if a user uses the same password over and over - compare with OTP - One Time Password from an SMS that is used only once.

With simple username/password authentication, users will enter their username (or user ID) and a password that only they know. The server has a database of valid username/password pairs. When users submit their username and password to the server, it looks up the username in the database and compares the corresponding password with the submitted one. If it matches, the user is allowed to proceed. It is possible to disguise the password in the username/password database by "hashing with salt”, but if a hacker captures the entire username/password database, they can recover the passwords from this scheme. Generally, users have big problems creating "strong” passwords (ones difficult to crack or guess) and even forgetting them (and thus requiring reset by admin or an out-of-band process like answering several questions that only the user should know the answers to). Also, passwords need to be changed frequently and this complicates the process for the user. If 2FA is used, after username and password are submitted, the users are challenged to enter a second factor (e.g. PIN from SMS or OTP token). If the password is one of the factors, the other factor is not strong enough to secure the login. It is noted that SMS and even OTP tokens can be cracked. OTP tokens are usually small, fragile, easily lost and have some cost. They increase operation costs and cause undue inconvenience to the users. In addition, hardware security tokens that work with biometric information is very expensive (for instance, over USD 100 per token) and so are not practical for large scale use. As for SMS-2FA implementation, there will be a cost for each SMS sent to the user and it is not secure as it seems. Security experts have warned about the vulnerability of SMS-2FA because a hacker can intercept text messages in transit, particularly if a phone number of the user is obtained. The US National Institute of Standards and Technology (NIST) at one point depreciated use of SMS for authentication and recommended another technology called push notification. They have since rescinded this deprecation due to pushback from users but still recommend against it.

A push notification does not go through a phone’s Telco service provider. It is transmitted via the Internet instead. One push service provider can work for all mobile devices, regardless of which Telco provides voice and/or data service to the mobile device but a data plan or WiFi access to the Internet is required.

There are a number of companies using push notification as a second factor for mobile device authentication, in addition to a first factor that usually use of password. Some techniques adopted in push notification simply accept a response by a mobile device owner, for instance, using an "Accept” button, to authenticate the mobile device owner. Such technique is a weak form of authentication. If another user has access to the mobile device, he or she could obtain unauthorised user access through the simple "Accept” authentication. Even if the push notification requires a fingerprint, this is still only one factor in addition to password.

Summary According to an example of the present disclosure, there are provided a method and apparatus as claimed in the independent claims. Some optional features are defined in the dependent claims.

Brief description of drawings

In the drawings, the same reference numerals generally relate to the same parts throughout different views, unless otherwise specified. Embodiments of the invention will be better understood and readily apparent to one skilled in the art from the following written description, by way of example only and in conjunction with the drawings, in which;

Figure 1 A illustrates a registration process between a device, an apparatus and a server apparatus according to an example of the present disclosure.

Figure 1 B illustrates another registration process between a device, an apparatus and a server apparatus according to an example of the present disclosure.

Figure 2A illustrates a user authentication process involving a cryptographic challenge according to an example of the present disclosure.

Figure 2B is a continuation of the user authentication process of Figure 2A according to an example of the present disclosure.

Figure 2C is an alternative to Figure 2B that continues after the user authentication process of Figure 2A according to an example of the present disclosure.

Figure 3 illustrates a user authorization process involving a cryptographic challenge according to an example of the present disclosure.

Figure 4 shows a schematic diagram of an apparatus, a device and a server apparatus used for authentication and/or authorization according to an example of the present disclosure.

Detailed Description

An example of the present disclosure is an improvement to the push notification technology. “Push notification” is a technique used for sending messages to one or more user devices through internet, for instance, through infrastructure at Google and Apple. Typically, the user devices are mobile devices. For details on push notification technologies, refer to, for instance, Google’s Firebase system and Firebase Cloud Messaging (FCM).

In a typical push notification setup, if a target mobile device wants to return a response to a node sending a push request, the push request must contain information on where to send the response. For example, the information must contain information on whether the sending application sending the push request is a web application and if so, a Uniform Resource Locator (URL) of the web application. A reply or response can then be sent from the target mobile device using the information contained in the push request to that URL with a HTTP push. The push request typically comprises a unique message ID, which is also included in the mobile device’s response so that the sending application sending the push request can associate the incoming response from the mobile device with the push request that was sent. After the response message from the mobile device is received, the web application then handles or reacts based on the incoming response message. The web application can be one running on a remote server hosting a website having the URL.

To enable push notification, typically, a client, user or mobile device application on the client, user or mobile device has to be first registered with a push service or notification provider. The provider keeps track of how to connect to that device application and the device, and returns a “Registration ID” that allows other push applications to send a push notification to that device application on that device via an Application Programming Interface (API). The device application can reply to the push notification, and the push application that sent the push notification will receive the response from the device application.

Typically, each device application / device pair must register with the push service provider (e.g. Firebase) via an API. The push service provider supplies information needed to direct a push notification to that device application on that device. This results in a“Registration ID” that must be provided to the push service provider when a request for a push notification is be sent to the device. The Registration ID may be an opaque and approximately 150 character ASCII string. The Registration ID is also known herein as a user identifier or user’s registration ID.

It is possible to send one push notification to multiple devices, but in the present example that improves on the push notification technology, a given push message or notification is sent to just one device application on one device registered with the push service provider. For example, in the case that the device is a smartphone, the device application is a mobile application. Every push notification request contains the Registration ID of the targeted node (effectively, the Registration ID is the device’s“address”). In other examples, it could be that there are multiple registered applications on a single device, but each registered application would have a distinct Registration ID. In further examples, it could also be that the same application is registered on multiple devices and each device can be distinguished by its unique International Mobile Equipment Identity (IMEI). However, in the present example that improves on the push notification technology, each application on a device would require a separate Registration ID. This is to prevent a push notification being sent to all registered devices, when a user registers multiple devices with one particular application. In this manner, in the present example, a push notification will only be sent to one application on one device that is registered with the push service provider, and this prevents other applications and/or other device from having access to the unauthorised push notification.

There are existing APIs, for instance, from both Google and Apple, for various operation systems used in a device, such as Windows, MacOS, Android, iOS, web, and the like that can be used to request a push notification to be sent to a specific application/device. During a push process where a given push notification (push message) is sent from the push service provider after receiving a push request from an application server, there is only a connection from the push service provider to the mobile device registered with the push service provider and paired with the specific application. This means that there is no traceable connection from a node requesting the push notification (i.e. a requesting node) to the mobile device registered with the push service provider. Consequently, even if someone has access to the requesting node (including traffic between the node requesting a push notification via API call and the push provider) and has knowledge of a Registration ID associated with the specific application, he cannot determine or work out an identity of the device that is a recipient of the push notification. In order to determine the identity of the recipient of the push notification, one would require access to protected information that is usually not available to the public at the push service provider. Using a push notification as a MFA or a 2FA authentication is desirable because it provides isolation between a sending application and a mobile device, and prevents interception and/or modification of the push notification. However, if a hacker knows a phone number or a caller identifier of a user logging into a sending application, for example, a web application, it is possible, at least in theory, that the hacker could hack into that phone or device and watch for the arrival of the push notification (or push message). This may cause some security problems since neither the push notification nor the response to the push notification sent via HTTP is encrypted. It may also be possible that someone monitoring the sending application, which in this example is the web application, could see a response arriving at a device sent via HTTP, and could easily determine an IP address of the mobile device sending the response.

However, in the present example that improves on the push notification technology, there is a feature that a portion of the content for a push message is created as a random text string when a push request is sent to the push notification server. This means that the push message may comprise of a random string or an encrypted random string and other data, such as user information, contact data of an application server that a user is accessing for services, and/or transaction information used to notify a user. The user information, such as name, telephone number, preferred display name and/or transaction information may be obscured during transmission. In one example, the other data may be encrypted using a public key of digital certificate associated with the user. In another example, the other data may not be encrypted and sent out in clear text. Therefore, since a portion of the content of the push message is randomized, a message ID usually found in the push notification message is difficult to determine by a hacker or eavesdropper and the eavesdropper or hacker would be unable to make use of the message ID to steal information. There is also no way for the eavesdropper or hacker to tamper with the challenge response in a way that would match the random string. Advantageously, by sending a random string as a portion of the push notification message, it can enhance the security of the communication between the application server and the mobile device. More details on the random message will be provided later.

Note that if a push request is being sent from a node that also acts as an authentication device, it will be fairly simple for a hacker to identify the authentication device from the push request. Therefore, for better security, it is desirable to have a requesting node (e.g. application server, which includes a web server) that is different from an authentication node (e.g. mobile device), which is the case in the present example described. In other words, if a user is requesting for services on the Internet that requires authentication or authorization on one computing or mobile device, it is desirable to use a different device as a token for granting the authentication or authorization. However, for convenience, it could be implemented that the user device used for requesting the services on the Internet is the same as the one used as the token for granting the authentication or authorization.

In one arrangement, key material (including private key) is stored on the user’s device locally. In another arrangement, the key material can be stored in a hardware token, such as a MicroSD card. It should be appreciated that in the present example that improves on the push notification technology, the use of an additional hardware token can be eliminated and replaced by other means of authentication such as fingerprint/iris scanning since more and more mobile devices are equipped with biometrics readers such as fingerprint reader and/or iris scanners. Specifically, improvement to the push notification technology can be achieved by adding features directed to the cryptographic challenge and involving use of Personal Identification Number (PIN) or Biometrics (e.g. fingerprint, iris etc.) to access key material (including private key). More details are provided below.

In an example of the present disclosure, a cryptographic challenge (i.e. randomized string) configured to be accomplished by a public/private key pair in the push notification mechanism is arranged such that a private key for proof of identity is stored locally on a user’s device (e.g. a mobile device such as smartphone). Access to the private key is allowed only after successful user verification with a passphrase/PIN or biometric mechanism (e.g. fingerprint, iris etc.). Using an additional passphrase or biometric mechanism to lock the private key greatly improves the security of the authentication and hence, can be used to replace use of just username/password authentication. Advantageously, this eliminates the need for users to create and manage passwords, to enter a password on a keyboard, to send passwords over the Internet, or to maintain a username/password database on the application server. That is, mass credential harvesting can be prevented because the 2FA authentication method of some examples disclosed herein can do away with entering user password for user authentication at login to, for instance, an application server to access services provided by the application server.

There are techniques that use a FIPS 140-2 certificate hardware token (e.g. Feitian ePass2003) with a client computer for authentication. The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer security standard used to approve cryptographic modules.

In one example, the user may select an X.509 client certificate to be uploaded to a web application, with proof of identity provided via a cryptographic challenge using a private key stored in the hardware token. The private key corresponds to a public key from the user’s client certificate. Such arrangement provides for a Transport Layer Security (TLS) strong client authentication. In this example, the user stores its client certificate and private key (collectively known as key material) in a hardware token, which allows applications to use Public-Key Cryptography Standards (PKCS) #11 to perform cryptographic operations using the key material in the token.

However, hardware tokens can be misplaced or lost easily, and the cost would be higher if a hardware token includes a fingerprint reader. The hardware token also requires an interface (e.g. USB, Flash Memory slot and the like) and a driver installed on the client computer before the token can be used. Hence, in an example of the present disclosure that improves on push notification technology, using push notification with public-key cryptography can turn a user’s device (e.g. smartphone and the like) into a token and eliminate the need for a separate hardware token. In this case, a client certificate and a private key are installed on the user’s device (e.g. smartphone and the like). This key material (i.e. client certificate and/or private key) can be obtained by a user for the user’s device via an Identity Registration Protocol (IRP) server discussed in International Patent Publication No. PCT/SG2016/050015, or downloaded to the user's device as a PKCS12 file that is encrypted with a passphrase. Once the key material is stored into the user’s device, the client certificate can be validated every time it is used in the methodology of the example of the present disclosure. The key material can be stored in a memory of the user’s device in a secured PKCS12 container and/or encrypted with a 3DES key derived from a passphrase known only to the user, or encrypted via known encryption techniques such as asymmetric-key encryption. The key material can be, for instance, accessed by the user for decrypting a push notification message (previously encrypted with the public key of the client certificate) from a push notification server via a PIN, passphrase, fingerprint scanner or iris scanner of the user’s device. The private key may be arranged to be unlocked or decrypted for a duration between a user unlocking or decrypting the private key to the decryption of the crypto challenge by the private key. This means that the private key is locked or encrypted at all other durations.

Although in some examples described in the present disclosure, the user’s device can act as a token, it is appreciated that in other examples of the present disclosure, separate hardware tokens can still be use for enhanced security. Hence, alternatively, the key material can be stored, for instance, in a hardware cryptographic token, on the user’s device (e.g. a FIPS-140-2 certified MicroSD card), for higher level of security. The token may be protected by a PIN or passphrase, or a biometric mechanism (e.g. fingerprint, iris etc.) that can be provided only by the user. Note that in cryptography, Triple DES (3DES), officially known as the Triple Data Encryption Algorithm (TDEA or Triple DEA), is a symmetric-key block cipher, which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block. In this manner, even when the user’s device is stolen, one would not be able to easily access the key material as the PIN or passphrase.

In one scenario of the example that improves on the push notification technology, a user wishes to use services of an application server and the application server would like to authenticate the user before providing the user with access to its services. The user first logins through a webpage hosted by the application server and the application server obtains a client certificate of the user. The client certificate can be obtained from a certificate server or certification authority, optionally via use of Identity Registration Protocol (!RP). The client certificate can also be requested by initiating a push notification exchange, and obtaining the user’s client certificate from a push notification response (see Figure 2, step S162 or 7,“client certificate").

Next, the application server activates a web application, to generate a random string (i.e. a cryptographic challenge) to be sent as a push request to a push notification server along with contact data of the application server and a user's registration identifier (ID). More details on the contact data of the application server and the user’s registration identifier (ID) will be discussed later.

In one example, the web application may be configured to generate as the random string a short random string with a cryptographically secure pseudo random number generator, or a hardware random number generator (see Figure 2, step S264 or 8).

As an example, a short random string can be generated as follow:

Thereafter, the web application is configured to encrypt the random string generated by the random number generator using an asymmetric algorithm (e.g. RSA-2048) and the public key of the user’s digital certificate (e.g. a X.509 client certificate of the user that Is made available to the web application, or obtainable from a server, a certification authority or optionally through an IRP server) to produce the cryptographic challenge. In the present example, the cryptographic challenge depicted in base64 encoding below is sent to the user's device via push notification mechanism as a push message.

Sending the cryptographic challenge via push notification mechanism refers to sending the cryptographic challenge along with the contact data of the application server and the user's registration ID to a push notification server, which then forwards the cryptographic challenge and the contact data of the application server to the user's device. The user's device has to be installed with the responsible application to manage such push notification comprising the cryptographic challenge.

The user’s registration identifier (ID) is an identifier provided by the push notification server to the user's device upon the user’s registration with the push notification service provided by the push notification server. The user’s registration ID has to be provided by the web application to the push notification server in order for the push notification server to identify the user and forward the cryptographic challenge along with the contact data of the application server to the user's device. The user's registration identifier (ID) is appended in the aforementioned push message created by the web application. The user's registration ID can be provided to the web application by the user when the user logins to a webpage hosted by the server, or it can be obtained by the web application from any suitable server (herein known as’’certificate server"), a certification authority (CA) and the like. An example of a suitable server is an Identity Registration Protocol (IRP) server pre-stored with the user's registration ID (i.e. the user pre-stores the user's registration ID at the certificate server, CA or IRP server). The web application is configured to know the source to obtain the user's registration ID based on the user's login details provided when the user logins to the webpage.

Advantageously, the aforementioned push message created by the web application does not need to be encrypted during communication because it is mainly containing a random string (along with the user’s registration ID and the contact data of the application server) encrypted by the public key of the user’s client certificate. This push message also does not need to be digitally signed because if it is tampered with, the authentication will fail.

The user's device that receives the push message containing the random string is configured to decrypt this cryptographic challenge with the private key associated with the user’s client certificate. A passphrase (PIN) or biometric authentication may be used to permit the user's device to access the user's private key. Using a PIN or biometric authentication prevents anyone else from using the user's private key. Once the private key is successfully obtained, a challenge response can be generated. In the present example, the challenge response would be as follows:

The challenge response Is then sent to the web application as a push notification response. Similar to the cryptographic challenge that is sent as the push notification message, there is no need to encrypt the challenge response because it is mainly containing a random string (along with the contact data of the application server). There is no need to digitally sign the challenge response because if it is tampered with, the authentication will fail.

If it is determined at the web application that the challenge response is the same as the original random string encrypted with the public key of the client certificate by the web application, this establishes that the user's device has the private key corresponding to the public key in the client certificate. The security levei of the present authentication method is very high because any other private key would not have successfully decrypted the cryptographic challenge.

The contact data of the application server discussed earlier may be a web address (i.e. URL). The purpose of the contact data is to enable the user's device to send a cryptographic response to the application server. Alternatively, the contact data of the application server may be an identifier to locate a web address of the application server from a plurality of web addresses (e.g. lookup table or list) stored at the user's device. Furthermore, each of the plurality of web addresses may correspond to one identifier and the identifier may be changed periodically for enhanced security to prevent a hacker from obtaining the contact data of the application server through the cryptographic challenge in the example that changes the identifier periodically, a responsible application at the user's device for user authentication/authorization and the web application have to synchronise and be updated with the same identifiers. This synchronization ensures that the identifier in the cryptographic challenge sent by the application server can locate the right web address of the application server. This synchronization can be achieved by updating the web application and the responsible application at the user's device concurrently. In another arrangement, the contact data of the application server appended to the random string may be encrypted by the web application as well and decrypted through the private key associated with the user’s client certificate.

In the present example, note that the passphrase/PlN and/or biometric information for unlocking the private key at the user's device is not sent to any web or sending application for enhanced security. It is only used locally at the user’s device to permit access to the private key, which is used to create the challenge response to the web application. As discussed earlier, the challenge response does not need to be secured by encryption or digital signature. This means that no key agreement is required between the web application and the user’s device. Alternatively, in another example, the private key may be made available/known to the certificate server or certification authority to facilitate user recovery of lost private key in the user’s device. However, the security level of such approach is lower.

Advantageously, the present example that improves on the push notification technology provides convenience to a user. The user may surf to a web application site and enter his or her user Identifier on his device. The user may or may not be required to enter any password during the login request. The inputted user identifier is then used to retrieve a Registration ID previously obtained from a push notification server and pre-stored at a certificate server, for instance, an IRP server. A cryptographic chailenge subsequently appears on the user’s device as a push notification through the help of the responsible application installed on the user’s device. The push notification can be taken to be a request for the user to enter the PIN or pass phrase or biometric information, such as a finger print, an iris scan, and the like to enable access to the private key stored on the device. Once a response to the cryptographic challenge is sent and authenticated by the web application, the web application will then provide its services to the user. In this manner, a hardware token becomes optional and, from the user’s perspective, the user only needs to login to the web application and unlock the private key to complete the authentication to gain access to services provided by the website hosted by the server running the web application.

Optionally, the push notification request for the user to enter the PIN or pass phrase or biometric information may be configured so as to seek user authorization to proceed (e.g. to allow or not to allow) with one or more transaction or action by entering the PIN or pass phrase or biometric information. Such user authorization is useful if another party/user that is not the authorising user is requesting for access to services provided by the application server or web application such as to proceed with a certain transaction or action. This request for user authorization is a check in place to protect the user from processing unintended transactions/actions initiated by the other party/user. In another arrangement, user authorization may be required from more than one users. Hence, the web application may be configured to obtain more than one user authorization through sending more than one corresponding cryptographic challenges via push notifications to more than one corresponding user devices. In this case, the transactions/actions initiated by one or more of the users involved will proceed only upon obtaining more than one user authorization.

Specifically, the authentication method of the example described above could be used to authorize individual transactions. In some way, this is similar to how a One Time Password (OTP) received through an SMS notification works for a banking transaction today. However, the described authentication method provides more ease and an enhanced security level to the user.

To further illustrate the authentication method, in one example, a user may enter into a transaction through a web application, such as“Pay $500 To XYZ corp.”. A push message would appear on the user device, such as“OK to pay XYZ Corp $500? Enter PIN or fingerprint to authorize”. Upon authorizing the transaction, the transaction would be carried out after successful authentication via the authentication method. More details on the authorization method will be provided later.

The example of the present disclosure described earlier can involve several components:

1. Push notification service provider, for example, Apple or Google (e.g. Firebase). A user has to register with a push notification server managed by the push notification service provider in order to receive push notifications/m essages . A user registration ID will be issued for a user’s device upon registration with the push notification server.

2. User device at user’s site that is capable of connecting to the Internet. In the example of the present disclosure, the device should have a PKI public key certificate and a private key of, for example, a digital certificate, pre-installed or created. Optionally, the device may include a hardware token (e.g. MicroSD card) that securely holds the private key. Alternatively, the private key can be kept as a secured file locally at the device. The private key can be accessed when the user enters a PIN, passphrase or biometric details.

3. Public Key Infrastructure (PKI) server that stores and/or creates digital certificates.

The PKI server may be configured to have a decentralized structure such that a private key never leaves a device (i.e. not disclosed to any parties). For instance, a decentralized PKI server, such as the IRP server, described in PCT/SG2016/050015 may be accessible by the device (e.g. a smartphone) to request and retrieve a digital certificate. In the case that the IRP server or another decentralized PKI server is used, the public and private key pair is first created by an application on the device. Thereafter, a Certificate Signing Request (CSR) request is created from user information entered to the application on the device and the public key that was created. The CSR request is then signed by the private key that was created and sent to the IRP server for the creation of a digital certificate. The IRP server then obtains a digital certificate for the device and saves a copy of the digital certificate for retrieval by any party that wants to obtain the public key of the digital certificate. For instance, as discussed earlier, the web application authenticating the user’s login can retrieve the public key of the digital certificate from the IRP server and use the public key to encrypt the random string created by the web application.

Alternatively, in another example of the present disclosure, it is possible to create a public and private key pair and a digital certificate using a centralized PKI server and distribute the digital certificate and public and private key pair subsequently to the device. However, this is less preferred since the private key would be present on the centralized PKI server and there is higher risk of it being stolen.

4. Server hosting a web page or providing a specific application that a user wishes to gain access via the user’s device to use services provided by the specific application or the server. This server may have a web application for obtaining a public key of a digital certificate of a user from user details provided by the user to the web page or to the specific application. The user details may contain a user identifier and optionally, a user login password. The server may login to a certificate server such as an IRP server with the user identifier and optionally, the user login password to retrieve a pre-stored user registration ID provided by a push notification server upon user registration, and the public key of a digital certificate previously issued to the user’s device.

It is noted that since the cryptographic challenge described in the aforementioned examples comprises a simple text message that does not comprise any sensitive information, it provides privacy protection to a user, and to prevent the push notification servers from analyzing the text images and sharing the information to others. In other examples, instead of text, a message containing data other than text is also possible. For instance, a random image, video or audio file encrypted by the public key at the application server that is to be decrypted by the private key at the user’s device. Figures 1 and 2 illustrate an example with the aforementioned components and the message flow between them for system setup, typical authentication, and typical transaction authorization.

A“registration ID” in the disclosure of examples as follows refers to an identifier between a specific application on a device and the particular device registered with a push service provider so that the push service provider can identify the particular device to send a push notification that is initiated by the specific application. The registration ID is shared with the specific application and can be distributed so that a party can provide the registration ID to the push service provider in a request to the push service provider to forward/send a push notification to the device.

A“cryptographic challenge” in the disclosure of examples as follows refers to a random string encrypted with a user’s public key from the user’s digital certificate and sent as a push notification to a user device for decryption using the user’s private key at the user device. The private key may only be accessed after successful authentication by a PIN, passphrase or via biometric mechanisms such as a fingerprint scan. This would keep the private key safe when it is not being used to respond to the cryptographic challenge.

“Authentication” in the disclosure of examples as follows refers to an approval of a user that logs into the specific application by establishing the user’s identity.“Authorization” in the disclosure of examples as follows refers to an approval of a specific transaction or action in an application after an identity of a user is authenticated.

Figure 1 shows a data communication flow between three apparatuses, namely, a device 110, a certificate server 112 and a push notification server 114. In the present example, the device 110 is a user mobile device, for example, a smartphone, a tablet personal computer, a laptop, and the like. The certificate server 112 in the present example has access to a database, which is known herein as a certificate manager database. An example of the certificate server 112 is an Identity Registration Protocol (IRP) Server. The push notification server in the present example may, for example, be the Firebase Cloud Messaging Server, Apple Push notification server, Parse Server and the like.

In summary, Figures 1 A and 1 B illustrate use of the user device 110 for user registration with the certificate server 112 and the creation of a digital certificate at the user device 110 facilitated by the certificate server 112. The user device 110 is installed with an application hereinafter known as “SixToken” or“SixToken app” to facilitate the user registration process.

As illustrated in Figure 1A, the user device 110 is used to register with the push notification server 114, which provides a registration ID (RegJD; also known herein as user identifier), to the user device 110 after the registration. The user device 110 then updates the certificate server 112 with the user identifier. The step of updating the user identifier with the certificate server 112 is a key step for the user authentication technique discussed in the present disclosure.

The step for user registration of the user device 110 with the certificate server 112 to obtain a client certificate and collective steps for user registration of the user device 110 with the push notification server 114 to obtain the RegJD and subsequent updating of the Reg JD with the certificate server 112 are described as follows. The step for user registration of the user device 110 with the certificate server 112 to obtain a client certificate and/or the collective steps for user registration of the user device 110 with the push notification server 114 and subsequent updating of the RegJD with the certificate server 112 can be initiated by a user scanning a QR code or barcode, or selecting an activation link (e.g. hyperlink), through an application installed on the user device 110, and the like. For instance, after the client certificate is obtained, the collective steps may include scanning a QR code to register the user device 110 with the certificate server 112. The step for user registration of the user device 110 with the certificate server 112 to obtain a client certificate and to generate a key pair for the client certificate may be initiated through an application installed on the user device 110.

A user account is first created at a step S150 with the certificate server 112. There are several ways in which a user account can be created at the step S150.

In one example, the user account is created by an administrator of the certificate server 112 without requiring a user to request for the user account to be created. For instance, a user database of an application server (not shown in Figure 1A) may be shared with the administrator of the certificate server 112 so that user accounts, which include the user account mentioned in step S150, can be created with the certificate server 112 for each user recorded in the user database. For better security, this sharing may be done offline. Optionally, each user may be notified of successful creation of user account with the certificate server 112.

In another example, with reference to Figure 1 B, the step S150 in Figure 1A is replaced by steps S151 to S165 in Figure 1 B. In the example of Figure 1 B, a user account with the certificate server 112 is created by a user independently by requesting for a QR code, barcode, or activation link (e.g. hyperlink) comprising information for the user account creation. Such QR code, barcode, or activation link (e.g. hyperlink) comprising information for the user account creation may be requested through a web application accessed by the user after the user logins to a web server 204 (which can also be an application server) through a web browser 202. Upon receiving the QR code, barcode, activation link (e.g. hyperlink), the QR code or barcode may be scanned or the activation link (e.g. hyperlink) may be selected to begin the user account creation process.

In more detail, with reference to Figure 1 B, a user may interact with the web server 204 through the web browser 202 by logging in to a web page displayed on the web browser 202 at a step S151. In the present example, the user inputs a registered username and associated password at the login webpage displayed on the web browser 202. For instance, the user may be logging into his online bank account that he has pre-registered for and the web server 204, which belongs to the bank, has the user’s information. After successful authentication of the user by the web server 204, the user requests the web server 204 to create a user account with the certificate server 112, for instance, by clicking on a button or a hyperlink on the web browser 202. In the example of Figure 1 B, the certificate server 112 is an IRP server. In one arrangement, the user may be required to enter a onetime password issued by the web server 204 to the user device 110 to authenticate the user after the request to create the user account with the certificate server 112.

After successful user authentication, the web server 204 logins to the certificate server 112 and requests for creation of user account through a web API service at a step S153. The certificate server 112 then creates a user account for the user in the certificate manager database, which in the present example is a public key infrastructure (PKI) database. The PKI database is configured to store PKI details of a plurality of users who have registered with the certificate server 112. Subsequently, the certificate server generates and sends a QR code 123 containing temporary user credentials to the web server 204 at a step S155. In the present example, only a seed of a password for logging into the certificate server 112 is provided in the QR code. The web server 204 then displays the QR code 123 on the web browser 202 at a step S157.

The user scans the QR code 123 with the SixToken app at a step S159 on the user device 110, which the user wishes to use as an authentication or authorization token. The SixToken app on the user device decodes the QR code 123 at a step S161 , and obtains a user identifier and domain (i.e. IRP domain details) from the QR code 123. The SixToken app on the user device also generates a Usernam e/Password Authentication (UPA) password from the seed of the password provided in the QR code 123.

Through the obtained domain, the SixToken app determines the domain of the certificate server 112 to connect with, and performs a UPA login to the certificate server using the obtained user identifier and the generated UPA password at a step S163. Once the UPA login to the certificate server 1 12 is successful, a success signal 125 will be sent from the certificate server 112 to the user device 110 at a step S165. After the step S165, if a digital certificate of the user of the user device 110 is not available, the SixToken app on the user device 110 then obtains user information from the PKI database through the certificate server 112, generates a key pair and a Client Signing Request (CSR) and obtains a digital certificate from a Certificate Authority through the certificate server 112 These steps after the step S165 will be discussed in detail with reference to Figure 1 A, in particular steps S152 to S162of Figure 1A later.ln yet another example (not illustrated in any of the Figures), a user account with the certificate server 112 is created through another application that is different from the SixToken app installed on the user device 110. This application (hereinafter known as “transaction application”) that is different from the SixToken app can, for example, be a bank mobile application in the case that the user device 110 is a smartphone. The transaction application may also be a web application running on a browser. In the present example, a user is able to create a user account with the certificate server 112 using the same user device 110 that is used to login to the web server 204 through the transaction application. In order for the user to login to the web server 204 through the transaction application, the user must pre-register with the Webserver 204 to set up UPA credentials for logging into the web server 204 through the transaction application. The creation of the user account is initiated by the transaction application installed on the user device 110 through a Uniform Resource Identifier (URI) scheme in which the SixToken app is configured to use. The user can execute the transaction application on the user device 110 and use it to request for a QR code. The QR code may be generated in a similar manner as discussed in steps S153 to S157 of Figure 1 B after the web server 204 has validated the user’s login UPA credentials. However, instead of the web server 204 displaying the QR Code on the web browser 202 like in the case of Figure 1 B, the QR Code obtained by the web server 204 is sent to the transaction application. It is optional whether the QR Code is displayed to the user on the user device 110. Once the QR code is sent to the transaction application, the content of the QR code will be passed to the SixToken app through the URI scheme of the SixToken app. For example, the SixToken app can be instructed by the transaction application with a command“SixToken://<usercredentials>”, which includes the temporary user credentials in the QR code, to automatically launch the SixToken app. Like step S161 in Figure 1 B, the SixToken app obtains a user identifier and domain (i.e. IRP domain details) from the temporary user credentials in the QR code. The SixToken app also generates a Username/Password Authentication (UPA) password from a seed of the password provided in the QR code.

Through the obtained domain, the SixToken app determines the domain of the certificate server 112 to connect with, and performs a UPA login to the certificate server using the obtained user identifier and the UPA password generated from the seed of the password provided in the QR code like the step S163 of Figure 1 B. Once the UPA login to the certificate server 112 is successful, a success signal 125 will be sent from the certificate server 112 to the user device 110 like the step S165 of Figure 1 B. Thereafter, if a digital certificate of the user of the user device 110 is not available, the SixToken app proceeds with the steps of obtaining user information from the PKI database through the certificate server 112, generating a key pair and a Client Signing Request (CSR) and obtaining a digital certificate from a Certificate Authority through the certificate server 112. These steps will be discussed in detail with reference to Figure 1A, in particular steps S152 to S162 of Figure 1A as follows.

S152 to S162 of Figure 1 A will now be described. Turning back to Figure 1A, the certificate server 112 is configured to store into the certificate manager database user information that was entered to create the user account. The user information may include one or more public key of one or more digital certificates pertaining to the user device 110. Subsequently, the user device 110 may send a request through a link 120 to obtain user information that is pre-stored by the certificate server 112 at a step S152. If the certificate server 112 is an IRP server, the command for the request to obtain user information is“get_user_jnfo”. The link 120 may be a secure Transport Layer Security link authenticated via Strong Client Authentication. The certificate server 112 is configured to access the certificate manager database to obtain the user information. After the request at S152, user information 142 is returned from the certificate server 112 via a secure message 122 at a step S154. The reason for requesting the user information 142 may be to create a digital certificate.

To create a digital certificate, the user device 110 is configured to create a public and private key pair and a certificate signing request (CSR) using the created public key at a step S156. The created CSR may be signed with the created private key. The term“public and private key pair” is used herein to refer to a public key that can be used to encrypt a piece of data and a private key that can be used to decrypt the data. Note that the private key generated at the user device 110 is not disclosed to anyone or dispatched to any external service provider. This means that the private key is only stored locally at the user device 110 or an external hardware token connectable to the user device 110. The term “certificate signing request” is used herein as a request to be sent to a certificate authority to apply for a digital certificate. The digital certificate usually contains the public key, identifying information (such as a domain name) and integrity protection (e.g. a digital signature).

A CSR is sent from the user device 110 to the certificate server 112 through a message 124 at a step S158. If the certificate server 112 is an IRP server, the command for the CSR is“put_csr”. The certificate server 112 then facilitates the process of digital certificate creation. The certificate server 112 may create the digital certificate creation itself or send the CSR to a certification authority to create the digital certificate. Once the CSR is approved, a digital certificate 144 specific or associated to the user device 110 is created at a step S160. A success signal 126 is sent to the user device 110 at a step S162 to indicate that the digital certificate 144 specific to the user device 110 has been successfully created. Once the user device 110 is notified that the digital identity certificate 144 is successfully created, the user device 110 will initiate a request 128 to the certificate server 112 to obtain the digital identity certificate 144 at a step S164. If the certificate server 112 is an IRP server, the command to be sent with the request 128 is“get_certificate”. Upon receipt of such request 128, the certificate server 112 will arrange for the digital identity certificate 144 specific to the user device 110 to be sent to the user device 110 via a message 130 at a step S166.

It is noted that steps S152 to S162 take place when the user needs to create a digital certificate for the user device 110 to be stored at the certificate server 112. In the case where creation of a digital certificate is not required and there is already an existing digital certificate, a user may use the user device 110 to get an existing digital certificate 144 via the step S164 and receive the digital certificate 144 via the step S166. Steps S152 to S162 can be performed independently of steps S164 and S166.

At a step S168, the user device 110 is configured to obtain full key material i.e. the public key and private key associated with the digital certificate 144 received at the step S166. Furthermore, optionally, the private key and/or the full key material can be encrypted at the step S168. In one example, the private key and/or the full key material can be kept in a secured Public-Key Cryptography Standards (PKCS) #12 container. The private key and/or full key material may be encrypted with a 3DES key derived from a passphrase known only to the user, or encrypted with known encryption techniques, such as asymmetric-key encryption, symmetric encryption and the like. Optionally, the private key and/or full key material can be stored in a hardware token, which may specifically be a hardware cryptographic token, on the phone (e.g. a FIPS-140-2 certified MicroSD card), for higher security. The hardware token can also be protected by a PIN or passphrase known only to the user or a biometric mechanism requiring a fingerprint or iris scan for user authentication. The hardware token may be a built-in circuit in the user device 110.

In the steps described above, the public key and private key are created at the user device 110 and the private key never leaves the user device 110. Such steps relate to a decentralised PKI server structure. In another example relating to a centralised PKI server structure, the private key is created outside of the user device 110 and can be obtained through a request to, for instance, a request to the certificate server 112, by the user device 110 and the certificate server 112 will send the private key to the user device 1 10.

In the present example, to push notifications from the push notification server 114 to the user device 110, the application installed on the user device 110 and the user device 110 are registered as a pair with the push notification server 114. A request 132 is sent from the device 110 to the push notification server 114 at a step S170 to register the application and information of the user device 110. Such request 132 may be initiated by a user scanning a QR code, barcode, activation link (e.g. hyperlink), through the application installed on the user device 1 10, and the like as discussed earlier. The push notification server 114 generates a unique registration identifier (ID; i.e. RegJD) 146 at a step S172. The generated unique registration identifier 146 is sent to the user device 110 in a message 134 at a step S174. The application then initiates to send this generated unique registration identifier 146 from the user device 110 to the certificate server 112 in a message 136 at a step S176. This unique registration identifier 146 is updated as part of user information stored in the certificate server 112 at a step S178. Thereafter, at a step S180, a success signal 138 is sent from the certificate server 112 to the user device 110 to indicate to the user device 110 that the user information has been updated with the unique registration identifier 146.

Note that steps S170 to S180 in Figure 1 relates to a process of obtaining a unique registration identifier 146 that can be used to push notifications to the user device 110. They can be performed independently of the steps S150 to S168. Furthermore, steps S170 to S174 can be completed independently of the steps S150-S168 and the steps S176 to S180.

Figure 2A shows a data communication flow between the device 110, an application server 204, a certificate server 112 and a push notification server 114 during user authentication. The steps of Figure 2A are continued in Figure 2B or 2C dependent or user decision. The reference numerals in Figure 1 are re-used in Figures 2A, 2B and 2C to refer to the common elements found in Figures 1 , 2A, 2B and 2C.

The certificate server 112 in the present example has access to a database, which is known herein as certificate manager database. An example of the certificate server 112 is an Identity Registration Protocol (IRP) Server. The push notification server 114 may, for example, be a Firebase Cloud Messaging Server, Apple Push notification server, Parse Server and the like. The application server 204 can host a web application on the internet, for example, the Apache Server, Internet Information Server, and the like. The application server 204 can be a web server, part of a web server or work with a web server. The application server 204 may be remote to a user, and typically uses HTTP (Hypertext T ransfer Protocol) to process incoming network requests. In the present example, the primary function of the application server 204 is to store, process and deliver web pages to users, in response to the user’s requests.

In the example illustrated in Figure 2A, the user of Figure 1 is browsing a website, for example, a bank login page, on a browser 202. The website could be anywhere on the Internet that is hosted by the application server 204, which uses a web application to facilitate authentication of the user, and the website requires user authentication for the user to gain access to services provided by the application server 204, for example, personal banking services.

At step S250, the user initiates a login request 220 to the website hosted by the application server 204 by entering a user identifier (e.g. username). Optionally, the user may enter a password in the website as well to be verified for the login request 220. In one example, the user identifier and a one time password (e.g. provided via SMS to the user’s device) for logging into the certificate server 112 may be pre-issued by an administrator of the application server 204 for the user to login. For user authentication to take place, the application server 204, running the web application needs a client or digital certificate associated with the user device 110 and the unique registration identifier 146 of the user device 110 for sending a push notification to the user device 110 through the push notification server 114. In the present example, the application server 204 is configured to log in to the certificate server 112 using the entered user identifier and optionally the entered user password if the user is required to enter such user password at a step S252 to retrieve the client certificate pre-stored in the certificate manager database accessible to the certificate server 112. An example of the step of storing the client certificate at the certificate server 112 is the step S 160 of Figure 1, which is the step of creation of the digital certificate. In the present example, the user identifier and the password are required for the login request 222 by the application server 204 to the certificate server 112. In the case that the user password is required, the user password entered in the website may be stored at the certificate server 112 when it is provided by the application server 204 at the first instance. For future logins by the application server 204 using the user identifier and optionally the user password, it can be configured that the user password is not required again by the certificate server 112 so as to simplify the authentication process. At a step S254, upon successful authentication, a signal 224 indicating that the application server 204 has successfully logged into the certificate server 112 is sent back to the application server 204. If authentication is unsuccessful, the application server 204 may indicate to the user that authentication is unsuccessful.

Once the application server 204 is logged into the certificate server 112, the application server 204 is configured to send a request 226 to obtain user information from the certificate server 112 at a step S256. In the case that the certificate server 112 is an IRP server, the command “get_user_info” is used in the request 226. Thereafter, at a step S2S8, user information 142 comprising the user registration ID 146 Is retrieved from the certificate server 112 and sent to the application server 204 in a message 228. In the present example, the user registration ID 146 was previously stored at the certificate manager database by the certificate server 112 at the request of the user device 110 at the step S176 of Figure 1. The application server 204 is configured to send a request 230 to obtain the digital certificate 144 associated with the user device 110 at a step S260. In the case that the certificate server 112 is an IRP server, the command "get_certificate” is used in the request 230. Upon receipt of the request 230, the digital certificate 144 associated to the user device 110 is retrieved from the certificate manager database by the certificate server 112 and sent to the application server 204 in a message 232 at a step S262. Although it is illustrated in Figure 2 that the get_user_info request 226 is made before the get._certificate request 230, it should be appreciated that the order of these requests can be reversed.

Once the application server 204 obtains the digital certificate 144 and the user Registration ID 146, the application server 204 can authenticate the user by sending to the user device 110 a cryptographic challenge through push notification to the user device 110. At a step S264, the application server 204 is configured to generate a random string 290. The random string 290 may be generated by a Cryptographically Secure Pseudo Random Number Generator or a hardware random number generator. In one example, the generated random string 290 is

The application server 204 then encrypts the generated random string 290 using, for example, an asymmetric algorithm (e.g. RSA-2048) with the public key retrieved from the obtained digital certificate 144 to produce a cryptographic challenge. In one example, after encryption of the generated random string 290 , the encrypted random string in base64 encoding would be as follow:

The application server 204 is configured to send the encrypted random string to the push notification server 114 along with the username that is used for logging into the web browser 202, the retrieved user registration identifier 146 and contact data of the application server 204, which can be a URL 208 i.e. a web address (also known herein as“response URL 208”), for sending a response to the application server 204 (if required) at a step S264 in a message 234. It should be appreciated that although it is illustrated in Figure 2A that a username that is used for logging into the web browser 202 is sent to the push notification server, this is an optional feature. The username that is sent with the push request from the application server 204 to the push notification server 114 is used to inform the user of the user device 110 that someone with the username has requested for authentication. This enables the user of the user device 110 to check that this someone is an authorised person. It could be that this someone is the user himself.

The URL 208 is appended to the encrypted random string and may be encrypted by the public key along with the random string 290. The application server 204 can be considered as a requesting node initiating a push request. Alternatively, instead of the response URL 208, an server identifier 210 (also known herein as“server identifier 210”,“server ID 210” or“svr ID 210”) may be sent along with the retrieved user registration identifier 146 for enhanced security. The server identifier 210 is a unique identifier that is matched, corresponded or associated with the response URL 208. The server identifier 210 enables a sending application on a user device 110 to locate the corresponding response URL 208 and send a push response to the application server that initiates the push request based on the corresponding response URL 208. In one example, one or more of the server identifier 210 may be associated with one or more corresponding response URL 208 and are downloaded with the sending application on the user device 110 to the user device 110.

The sending application may be, for instance, a mobile application downloaded and installed to the user device 110, in the case that the user device 110 is a smartphone or mobile tablet device. The sending application may be software downloadable from the Internet in the case that the user device 1 10 is a personal computer or laptop.

There may be present a plurality of the URL 208 and corresponding server identifiers 210 that may be stored in a form of a table or list and such table or list may be constantly updated at the user device 110 should there be changes or additions to the table or list. Each URL 208 is associated with or corresponds to a specific server identifier 210. The plurality of the URL 208 and the corresponding server identifiers 210 may be periodically updated by updating the version of the sending application installed on the user device 110. For instance, if a user device 110 is a mobile device, the sending application can be a mobile application that has to be updated through an application store.

A URL 208 of a particular application server 204 and a corresponding server identifier 210 may also be updated in the table or list in a step inserted in the collective steps described earlier with reference to Figure 1 for user registration of the user device 110 with the push notification server 114 and subsequent updating of the RegJD with the certificate server 112. Such updating can be initiated by a user scanning a QR code, barcode, activation link (e.g. hyperlink), through the sending application installed on the user device 110, and the like. For example, a new URL 208 and a new corresponding server identifier 210 are added into the table or list when, for instance, a user scans a QR code. In this case, the aforementioned collective steps may include a step to obtain the URL 208 of the application server 204 and/or server identifier 210 associated with the URL 208.

In addition, each server identifier 210 may be changed periodically during each update for enhanced security. That is, for example, the server identifier 210 for a particular URL 208 never remains for longer than a predetermined time period. The server identifier 210 changes during an update of the version of the sending application installed at the user device 110 or as initiated by a user scanning a QR code, barcode, activation link (e.g. hyperlink), through the sending application installed on the user device 110, and the like. In the examples in which the server identifier 210 changes periodically during each update, it is appreciated that the records of such server identifier 210 at the user device 110 and at the web application on the application server 204 have to be updated concurrently so that the right server identifier 210 will be sent in the push request.

In an example where the contact data of the application server 204 is the server identifier 210 instead of the response URL 208, the server identifier 210 may likewise be appended to the randomised string 290 in the push message content like in the case of the response URL 208. It is difficult for an eavesdropper or a hacker to steal information from the server identifier 210 (or the response URL 208 in the case that the contact data is the response URL 208) because it is appended to the random string 290 that does not make sense. Furthermore, in the case that the contact data is the server identifier 210, it is even more difficult for an eavesdropper or a hacker to steal information because the URL 208 of the application server 204 can only be located by the server identifier 210 by referring to the table or list at the user device 110.

Once the push notification server 114 receives a push request along with the encrypted random string, the response URL 208 or server ID 210, and the user registration identifier 146, the push notification server 1 14 is configured to identify the user device 110 using the user registration identifier 146. A cryptographic challenge comprising the encrypted random string from the push notification server 114 along with the username that is used for logging into the web browser 202 and the response URL 208 or the server ID 210 is then generated and sent to the identified user device 110 as a push message 236 at a step 266.

The push message 236 will be displayed on a display screen communicatively coupled to the user device 110 with, for instance, a simple text message indicating the purpose for requesting user authentication at a S267. For example, the simple text message for requesting user authentication can be in the form of "Steven Gerard is attempting to authenticate to XYZ Bank Service - Click accept if you are Steven Gerard and you have requested to be authenticated to use XYZ Bank Services". In another example, it could be as simple as“<Usemame> wants to login to <appname>", wherein the field username is the username received from the push notification server 114 and the appname can also be included in the push message 236 to the user device 110 as well·.

In one example of the push message 236 received at the user device 110 at the step S267, the push message 236 displayed on the display screen of the user device 110 may include an approval (e.g. OK) button and a disapproval (e.g. Cancel, Abort or Terminate) button for the user to select. This push message 236 constitutes an authentication request. The subsequent processes or steps relating to the user's approval and disapproval will be described with reference to Figures 2B and 2C respectively.

With reference to Figure 2B, if It is determined by the user device 110 that the user selects to disapprove or deny the authentication request, the login sequence will be aborted at a step S268, and a command 237 may be sent to the web browser 202 to refresh the web page.

With reference to Figure 2C, If it is determined by the user device 110 that the user selects to approve or allow the authentication request at a step S269, the user device 110 decrypts the encrypted random string of the cryptographic challenge with the private key associated with the digital certificate 144 stored locally in the user device 110 or in a hardware token that may specifically be a hardware cryptographic token connectable to the user device 110.

In the same example as discussed above, after decryption of the encrypted random string using the private key, the decrypted random string would be as follow:

The above decrypted random string is then used to generate a cryptographic challenge response.

The private key used to decrypt the encrypted random string of the cryptographic challenge may be encrypted or locked and requires user authentication to decrypt or unlock it for the decryption of the encrypted random string. In this case, after it is determined by the user device 110 that the user selects to approve or allow the authentication request, the user may be requested to additionally enter a predefined password or passphrase only known to the user at the step S269 to authenticate his or her identity to decrypt or unlock the private key for use. In another example, the user may be requested to authenticate using biometric Information of the user at the step S269, such as a fingerprint or an Iris scan, to authenticate his or her Identity to decrypt or unlock the private key for use. In yet another alternative, both the password or passphrase and biometric information are required for the authentication.

For enhanced security, the application (i.e. the“SixToken" application mentioned earlier) installed in the user device 110 that is Involved in the current steps described may be configured to store the biometric information in a different manner from user biometric Information stored by other application installed In the user device 110. The other application installed in the user device 110 may be a built-in application of an operating system of the user device 110 that is known to be used for obtaining and storing user biometric Information. For example, in the case of mobile applications In mobile devices, most mobile applications uses the biometric information stored by the built-in application of the operating system of the mobile device If some form of user biometric verification Is required. In one example of the present disclosure, the biometric information may be arranged to be saved by the SixToken in a memory folder/location different from a memory folder/location also comprising biometric information of other application in the user device 110. The stored biometric information may also be encrypted with a PKCI #5 protocol or in a manner different from known encryption techniques used by the other application Installed In the user device 110.

The private key may be stored In a secured PKCS12 container encrypted with a 3DES key derived from a passphrase known to the user locally at the user device 110 or in a hardware token (e.g. a FIPS-140-2 certified MicroSD card) connectable to the user device 110. The hardware token may be a flash memory card or Subscriber Identity Module (SIM) card and may have security features (e.g. contents are encrypted, break-in proof etc.) for enhanced security. One example of a secure hardware token that has a form factor of a flash memory card (e.g. secure MicroSD) is a Go-Trust SDencrypter Micro SD card. Another example of a secure hardware token in a form of a SIM card is Gemalto encrypted SIM card. Likewise, the biometric information of the user, swipe pattern, passphrase and/or password used for decrypting or unlocking the private key may also be stored in a secured PKCS12 container locally at the user device 110 or in the hardware token. Having a hardware token is advantageous because the private key is not stored in the user device 110, and this prevents a hacker from stealing the private key by checking a swap file that may exist in the user device 110.

The private key may be arranged to be locked or encrypted at all time, except during a time duration between when a user provides a PIN, passphrase or biometric information to unlock or decrypt the private key to when the crypto challenge is decrypted by the private key. In the example where the private key is stored in the hardware token, there are two methods in which the encrypted random string in the cryptographic challenge can be decrypted. In the first method, the hardware token is configured to be unlocked by a pin that is decrypted by a registered fingerprint or passphrase. Once the hardware token is unlocked, the private key is retrieved from the hardware token and used to decrypt the encrypted string in the crypto challenge at the user device 110. Upon decryption of the encrypted string in the crypto challenge, the hardware cryptographic token is locked again. The first method can be said to adopt a“soft token” approach because the private key can leave hardware token. In one example of the soft token approach, the device (e.g. user device 110) acting as an authorization/authentication token stores the private key locally. In this example, it is preferred that the device acting as the authorization/authentication token is different from the device that is used to initiate an authorization/authentication request that leads to the need for the use of the private key for decryption of a random string. This is to ensure hardware separation, and greatly minimizes the risk of a hacker stealing the private key.

In the second method, upon successful verification of the registered fingerprint or passphrase, a command together with the encrypted string in the cryptographic response may be sent to the hardware token for decryption within the hardware token. This means that only the decrypted string is returned by the hardware token to the user device 1 10. The command may be sent from the SixToken app on the user device 1 10 and the decrypted string is sent to the user application. For enhanced security, the communication between the hardware token and the device may be secured based on PKCS#11. Advantageously, for the second method, the private key never leaves the hardware token and thus, as compared to the first method, the private key is stored in a more secured way. The second method can be said to adopt a“hard token” approach because the private key never leaves the hardware token. If out of convenience, a user prefers to have the device (e.g. user device 110) acting as authorization/authentication token to be the same as the device that is used to initiate an authorization/authentication request that leads to the need for the use of the private key for decryption of a random string, the hard token approach is preferred for better security.

It should be appreciated that if a new client certificate is created, a new public/private key pair has to be created. Although the private key of the key pair may be stored locally in the user device 110 or in a hardware token connectable to the user device 110 for enhanced security, the private key may also be stored with a third party (e.g. administrator of the application server 204) and supplied to the user device 110 upon user request for a system with lower security level. In this case, it can be configured that the private key may only be unlocked or decrypted for use by a user with the correct biometric information.

At a step 270, the cryptographic challenge response (i.e. the decrypted random string) is sent from the user device 110 to the application server 204 as a reply 238 to the push notification received at the user device 110 based on the received response URL 208 or server ID 210. At a step S272, the application server 204 compares the decrypted random string in the cryptographic challenge response with the random sting 290 previously generated at the step S264. If it is determined that the two respective random strings are identical at the step S272, the application server 204 will at a step S274 issue a command 239 to the web browser 202 to allow the user to access services provided by web browser 202.

However, if it is determined at the step 272 that the two respective random strings are not identical, the application server 204 will issue a command 240 to the web browser 202 to deny the user’s access to the services provided and notify the owner of the user device 110. The process then ends at a step S273.

After the user’s identity is authenticated, and access to the services of the application server 204 that is provided through the web browser 202 is allowed for the user, it may be configured that the web application on the application server 204 allows the user to access the services under a username that is a user identifier retrieved from the digital certificate at a step S176. The user identifier can be part of the user information 142 retrieved at the step 258. In this manner, there is no need for the application server 204 to store and manage user accounts. As the user identifier is from the digital certificate managed by the certificate server 112, it can be said that the user accounts are actually managed by the certificate server 112. It Is noted that allowing user access to services provided by the application server 204 includes allowing user access to a service to authorise a particular transaction to take place, for instance, the user relies on a service provided to authorise payment to a particular merchant via electronic funds transfer. In addition, it should be appreciated that when transacting with the application server 204, authorization by the user using similar process as described in Figures 2A to 2C may be required. Details of such authorization will be briefly described with reference to Figure 3 in the following paragraph. Details that are similar to the authentication process described in Figures 2A to 2C are o itted.

Figure 3 shows a data communication flow between the device 110, the first server 204 and the push notification server 114 during user authorization. The reference numerals in Figure 1 are reused in Figure 3 to refer to the common elements found in Figures 1 and 3. The push notification server 114 may for example, be the Firebase Cloud Messaging Server, Apple Push notification server, Parse Server and the like. The application server 204 can host a web application on the internet, for example, the Apache Server, Internet Information Server, and the like. The application server 204 can be a web server, part of a web server or work with a web server. The application server 204 may be remote to a user, and typically uses HTTP (Hypertext T ransfer Protocol) to process incoming network requests. In the present example, the primary function of the application server 204 is to store, process and deliver web pages to users, in response to the user’s requests.

In the exa ple illustrated in Figure 3, the user of Figure 1 is browsing a website, for example, a bank web page, on a browser 202. The website could be anywhere on the Internet that is hosted by the application server 204, which uses a web application to facilitate authentication of the user. After the user authentication process is completed as discussed with respect to Figures 2A to 2C, the user is able to gain access to services provided by the application server 204, for example, personal banking or remittance services. It may be required for the user to authorize one or more transactions to be processed by the application server 204, for example, authorise payment to a particular merchant via electronic funds transfer. Optionally, such authorization of transaction may occur without the user going through the elaborate user authentication process discussed with respect to Figures 2A to 2C. For instance, a user may request to initiate a transaction after login with UPA credentials, which may involve issuance of a One-Time Password, and the client certificate required is retrieved based on the UPA credentials. In this case, the user has to pre-register with a certificate server (e.g. certificate server 112) and have a client certificate created before the transaction request.

In the example of Figure 3, the user initiates a transaction, for example, to pay a payee $500, through the browser 202 at a step S310. Consequently, a command 350 is sent to the application server 204. The application server 204 retrieves the client certificate 144 and the user Registration ID 146 of the user device 110 that are obtained during the earlier registration process as described with reference to Figure 1. Once the application server 204 obtains the digital certificate 144 and the user Registration ID 146, the application server 204 can authorize a transaction by sending to the user device 110 a cryptographic challenge through push notification to the user device 110. At a step S314, the application server 204 is configured to generate a random string 291. The random string 291 may be generated by a Cryptographically Secure Pseudo Random Number Generator or a hardware random number generator. The application server 204 then encrypts the generated random string 291 using, for example, an asymmetric algorithm (e.g. RSA-2048) with the public key retrieved from the obtained digital certificate 144 to produce a cryptographic challenge.

The application server 204 is configured to send the encrypted random string to the push notification server 114 along with the retrieved user registration identifier 146, username, transaction information (i.e. in this case, to pay a payee $500) and contact data of the application server 204, which can be a response URL 208 or server identifier (ID) 210, at step S316 in a message 352. It should be appreciated that although it is indicated that a username that is used for logging into the application server 204 is sent to the push notification server 114, this is an optional feature. The username that is sent with the push request from the application server 204 to the push notification server 114 is used to inform the user of the user device 110 that someone with the username has requested for transaction authorization. This enables the user of the user device 110 to check that the username refers to someone that is authorised. It could be that this someone is the user himself. The response URL 208 is the URL of the application server 204 and is referred by the user device 110 to send a response to the application server 204 (if required) at a step S328 in a message 358. The application server 204 can be considered as a requesting node initiating a push request. Alternatively, for enhanced security, the server identifier 210 may be sent along with the retrieved user registration identifier 146, instead of the response URL 208. The server identifier 210 is a unique identifier associated with a URL of the application server 204 at the user device 204 and the associated URL is referred by the user device 110 to send a response to the application server 204 (if required) at a step S328 in a message 358. There may be a table or list stored at the user device 204 for matching the server identifier 210 with the associated URL.

Once the push notification server 114 receives a push request along with the encrypted random string, the user registration identifier 146, the username that is used for logging into the web browser 202, contact data of the application server 204, and the transaction information, the push notification server 114 is configured to identify the user device 110 using the user registration identifier 146. A cryptographic challenge comprising the encrypted random string from the push notification server 114 along with the username, transaction information, and contact data of the application server 204, is then generated and sent to the identified user device 110 as a push message 354 at a step 318.

The push message 354 will be displayed on a display screen communicatively coupled to the user device 110 with, for instance, a simple text message indicating the purpose for requesting user authorization of a transaction at a S320. For example, the simple text message for requesting user authentication can be in the form of“User Alicia Stones to Pay $1000 to Merchant Amazon” - Click accept if you are Alicia Stones and you authorise to pay $1000 to Merchant Amazon”. In another example, it could be as simple as “<Username> wants to pay <payee><transaction_amount>”, wherein the fields username, and transaction information including payee details and transaction amount can be retrieved from the push message 354. For better security, the username and transaction information can be encrypted using the public key with the random string 291 as well by the application server 204 and they would be decrypted with a private key at the user device 110.

In one example of a push message received at the user device 110 at step S320, the push message displayed on the display screen of the user device 110 may include an approval (e.g. OK) button and a disapproval (e.g. Cancel, Abort or Terminate) button for the user to select. If it is determined by the user device 110 that the user selects to disapprove or deny the transaction, the transaction will be aborted at a step S322, and a command 356 may be sent to the web browser 202 to refresh the web page. However, a session for accessing the services provided by the application server 204 may remain active (provided that the application server 204 determines that the session has not timed out), and the user can continue with other transactions.

If it is determined by the user device 110 that the user selects to approve or allow the transaction at a step S324, the user device 110 proceeds to decrypt the encrypted random string of the cryptographic challenge with the private key associated with the digital certificate 144 stored locally in the user device 110 or in a hardware token connectable to the user device 110. At a step S326, the decryption of the cryptographic challenge is performed by prompting the user to enter a PIN or passphrase that is known only by the user or to verify the user’s biometric information such as a finger print or iris scan. Hence, after the user selects to approve or allow the transaction at the step S324, the user would be requested to enter the passphrase or input his biometric information such as finger print or perform an iris scan in order for the authorization to take place.

After decryption of the encrypted random string using the private key, the user device 110 will obtain a decrypted random string and use it to generate a cryptographic challenge response to the application server 204. At a step S328, the cryptographic challenge response (i.e. the decrypted random string) is sent from the user device 110 to the application server 204 as a reply 358 to the push notification received at the user device 110 based on the received contact data of the application server 204, which can be the response URL 208 or server ID 210. At a step S330, the application server 204 compares the decrypted random string in the cryptographic challenge response with the random sting 291 previously generated at the step S314. If it is determined that the two respective random strings are identical at the step S330, the application server 204 will at a step S332 issue a command 360 to the web browser 202 to allow the user to refresh a webpage on the web browser 202, for instance, to indicate that the user transaction authorization is successful.

However, if it is determined at the step 360 that the two respective random strings are not identical, the application server 204 will issue a command to the web browser 202 to refresh a webpage on the web browser 202, for instance, to indicate that the user transaction authorization is unsuccessful. Optionally, the application server 204 may be configured to send a push notification to the mobile device to notify the user of an error. This is to alert the user of unintentional phishing of sensitive information

In another example that improves on the push notification technology for authorization of a transaction, an application server (e.g. 204 in Figure 3) may be configured to authorize a transaction performed by the application server after more than one user devices have successfully decrypted the encrypted random string sent to the more than one user devices via push notification. In this example, more than one user registration identifiers (e.g. 146 in Figure 3) issued to more than one corresponding user devices have to be sent with the encrypted random string (e.g. the encrypted random string generated at the step S316 in Figure 3) to the push notification server (e.g. 114 in Figure 3. Such authentication method allows more than one users to have control over one particular user’s access to the services provided by the application server 204. For example, in a case of two users in a dual control scenario, access to a service by one of the two users is allowed only if both users have successfully decrypted the encrypted random string (e.g. the encrypted random string generated at the step S316 in Figure 3) on their respective user devices. In this manner, both users have to give permission for one user to approve of a transaction, for instance, to electronically transfer funds to a merchant. This is beneficial because transactions unauthorised by one of the users will be terminated before a transaction is performed. Note that the process as illustrated in Figure 3 may occur concurrently between the two users, or the steps of S314 to S360 are repeated after a first successful authorization by one of the users.

For instance, a parent is able to authorize a transaction that has been approved by a child before the transaction is processed and completed by the application server. In such an example, a push notification may be sent to the parent’s device that is registered with a certificate server 112 and the application server 204 after the S360, such as“Jane Fernando has approved to pay SGD 1000 to Amazon. Do you allow this transaction?” along with a second cryptographic challenge for authorization using a private key stored at the parent's device when access to the private key is allowed by the parent by inputting his fingerprint or passphrase. It should be appreciated that the second cryptographic challenge is different from a first cryptographic challenge that is sent to the child’s device. The second cryptographic challenge may be generated based on a portion of a generated random string used in the first cryptographic challenge. It is also possible that a push request comprising the second cryptographic challenge, to the parent’s device, is initiated from the child’s device, instead of the application server 204.

In another instance, a plurality of pre-registered authorizers, such as two managing directors of a company, may have to approve a transaction before the transaction can be completed. In such an example, the push notification service provider 114 would be instructed to send two separate push notifications, wherein a first push notification containing the first cryptographic challenge would be sent to one of the two pre-registered authorizers (i.e. the two managing directors) and a second push notification containing the second cryptographic challenge would be sent to the other of the two preregistered authorizers. The application server 204 may be configured to operate such that the transaction is completed if the two cryptographic challenge responses are received within a predetermined duration and the respective decrypted random strings have been verified. If only one cryptographic challenge response is received and subsequently determined to be authorized within the predetermined duration, the transaction will be terminated. A notification may be sent to the plurality of pre-registered authorizers to inform them that the transaction is cancelled.

The user device 110 in Figure 1 may be a computing or mobile device 400 schematically shown in Figure 4. There may be provided software, such as one or more computer programs being executed within the computing device 400, and instructing the computing device 400 to connect and communicate with a second computing or mobile device 434 according to the operations described with reference to the earlier figures. The system architecture of the second computing or mobile device 434 can be the same as that of the computing device 400 and vice versa and not limited to what is described herein. There may be provided software, such as one or more computer programs being executed within the second computing or mobile device 434, and instructing the second computing or mobile device 434 to connect and communicate with the computing or mobile device 400 according to the operations described with reference to the earlier figures.

The application servers (such as server 204 in Figure 2), push notification servers (such as server 114 in Figures 1 and 2), certificate servers (such as server 1 12 in Figures 1 and 2) and other servers (such as third party servers that creates digital certificates) as disclosed herein may also be a server apparatus 450 shown in Figure 4. There may be provided software, such as one or more computer programs being executed within the server apparatus 450 to carry out the operations of the respective servers as well.

The server apparatus 450 may be a single server as illustrated schematically in Figure 3, or have functionality performed by the server apparatus 450 distributed across multiple server components. In the example of Figure 4, the server apparatus 450 may comprise a number of individual components including, but not limited to, microprocessor 456, a memory 458 (e.g. a volatile memory such as a Random Access Memory (RAM)) for the loading of executable instructions 460, the executable instructions defining the functionality the server apparatus 450 carries out under control of the processor 456. The server apparatus 450 also comprises a network module 452 allowing the server to communicate over the communications network 412 (for example the internet). User interface 462 is provided for user interaction and may comprise, for example, conventional computing peripheral devices such as display monitors, computer keyboards and the like. The server apparatus 450 may also comprises a database 454. It should also be appreciated that the database 454 may not be local to the server apparatus 450. The database 454 may be a cloud database.

The computing device 400 can comprise a processing unit 402 for processing the one or more computer programs. The processing unit 402 is connected to input/output devices such as a computer mouse 436, keyboard/keypad 404, a display 408, headphones or microphones 426, a video camera 440 and the like via Input/Output (I/O) interfaces 424. The processing unit 402 may include a processor 418, a Random Access Memory (RAM) 420 and a Read Only Memory (ROM) 422. The components of the processing unit 402 typically communicate via an interconnected bus 428 and in a manner known to the person skilled in the relevant art.

The processing unit 402 may be connected to the network 412, for instance, the Internet, via a suitable transceiver device 414 (i.e. a network interface) or a suitable wireless transceiver 432, to enable access to e.g. the Internet or other network systems such as a wired Local Area Network (LAN) or Wide Area Network (WAN). The processing unit 402 of the computing device 400 may also be connected to one or more external wireless communication enabled electronic devices 434 or the server 450 through the respective communication links 480, 482, 484 via the suitable wireless transceiver device 432 e.g. a WiFi transceiver, Bluetooth module, Mobile telecommunication transceiver suitable for Global System for Mobile Communication (GSM), 3G, 3.5G, 4G telecommunication systems, or the like.

The second computing or mobile device 434 may be, for example, smart phones, tablet devices, and other handheld devices. The one or more second computing or mobile device 434 may be able to communicate through other communications network, such as, wired network, mobile telecommunication networks, but these are omitted from Figure 4 for the sake of clarity. Instead of the system architecture described above for the computing or mobile device 400, the computing or mobile device 400 may have the system architecture of the second computing or mobile device 434.

The second computing or mobile device 434 may comprise a number of individual components including, but not limited to, microprocessor 476, a memory 448 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 470, the executable instructions defining the functionality the second computing or mobile device 434 carries out under control of the processor 476. The second computing or mobile device 434 also comprises a network module 472 allowing the second computing or mobile device 434 to communicate over the communications network 412. User interface 492 is provided for user interaction and control that may be in the form of a touch panel display and presence of a keypad as is prevalent in many smart phone and other handheld devices. The second computing or mobile device 434 may comprise a finger print scanner, iris scanner, camera used for face recognition and the like. The second computing or mobile device 434 may comprise a card reader for insertion of an external storage card (e.g. a FIPS-140-2 certified MicroS D card). The second computing or mobile device 434 may also comprise a database 474. It should also be appreciated that the database 474 may not be local to the second computing or mobile device 334. The database 474 may be a cloud database. The second computing or mobile device 434 may include a number of other Input/Output (I/O) interfaces as well but they may be for connection with headphones or microphones 494, Subscriber identity module (SIM) card 496, flash memory card 498, USB based device 499, and the like, which are more for mobile device usage.

The software and one or more computer programs may include, for example, an client application such as a banking application, a web application (e.g. Safari, Chrome) and an personal server application as discussed in PCT/SG2016/050340, and may further include one or more software applications for e.g. instant messaging platform, audio/video playback, internet accessibility, operating the computing or mobile device 400 (i.e. operating system) or the second computing or mobile device 434, network security, file accessibility, database management, which are applications typically equipped on a desktop or portable (mobile) device. The software and. one or more computer programs may be supplied to the user of the computing or mobile device 400 or the second computing or mobile device 434 encoded on a data storage medium such as a CD-ROM, on a flash memory carrier or a Hard Disk Drive, and are to be read using a corresponding data storage medium drive of for instance, a data storage device 430 in Figure 4. Such application programs may also be downloaded from the network 412. The application programs are read and controlled in its execution by the processor 418 or microprocessor 476. Intermediate storage of program data may be accomplished using RAM 420 or 448.

Furthermore, one or more of the steps of the computer programs or software may be performed in parallel rather than sequentially. One or more of the computer programs may be stored on any machine or computer readable medium that may be non-transitory in nature. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer or mobile device. The machine or computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the Wireless LAN (WLAN) system . The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus (e.g. 110, 112, 204, 400, 434 in the respective Figures) that implements the steps of the computing methods in examples herein described.

In summary, examples of the present disclosure may have the following features. There may be provided a method for user authentication, the method comprising:

(a) receiving a user request from a user at an application server (e.g. S250 of Figure 2A, S310 of Figure 3);

(b) generating at the application server a random string and encrypting the generated random string with a public key of a digital certificate associated with the user (e.g. S264 of Figure 2A, S314 of Figure 3);

(c) sending the encrypted random string along with a user identifier and contact data of the application server from the application server to a push notification server (e.g. S264 of Figure 2A, S316 of Figure 3);

(d) sending a cryptographic challenge comprising the encrypted random string and the contact data of the application server from the push notification server to a user device after identifying the user device from the user identifier (e.g. S266 of Figure 2A, S318 of Figure 3);

(e) decrypting at the user device the encrypted random string of the cryptographic challenge with a private key associated with the digital certificate associated with the user (e.g. S269 of Figure 2C, S326 of Figure 3);

(f) sending a cryptographic challenge response comprising the decrypted random string of the cryptographic challenge from the user device to the application server, wherein the user device sends the cryptographic challenge response according to the contact data of the application server received at the user device (e.g. S270 of Figure 2C, S328 of Figure 3);

(g) comparing at the application server the decrypted random string in the cryptographic challenge response with the random string that was generated by the application server (e.g. S272 of Figure 2C, SS330 of Figure 3); and

(h) providing the user with one or more services of the application server if the decrypted random string in the cryptographic challenge response matches with the generated random string (e.g.S276 of Figure 2C, S332 of Figure 3).

The user request may be a request for a transaction authorization (e.g. S310 of Figure 3) and the one or more services includes performing the transaction.

The user request may be a user login request (e.g. 250 of Figure 2A) and the method may comprise obtaining at the application server (e.g. 204 of Figures 1 B, 2A to 2C, and 3) a user identifier (e.g. 146 of Figures 1A, 2A and 3) from user input entered during the user login request; and obtaining at the application server the digital certificate (e.g. 144 of Figures 1A, 2A and 3) associated with the user identifier.

Optionally, this method may comprise receiving a second user request (e.g. S310 of Figure 3) from the user and the steps (b) to (h) are repeated, wherein the second user request is a request for a transaction authorization.

The method may comprise logging in (e.g. S252 of Figure 2A) to a certificate server (e.g. 112 of Figures 1A to 1 B and 2A) comprising the digital certificate by using the user input entered during the user login (e.g. S250 of Figure 2A); and obtaining the user identifier by requesting for user information (e.g. S260 of Figure 2B) recorded in a database accessible to the certificate server, wherein the user information (e.g. 142 of Figure 1A and Figure 2A) comprises the user identifier.

The user device (e.g. 110 of Figures 1A to 1 B, 2A to 2C and 3) may be configured to obtain the user identifier (e.g. 146 of Figure 1A, Figure 2A and Figure 3) by registering with the certificate server and update the user information recorded in the database with the user identifier.

The user device may be configured to register with the certificate server (e.g. S150 of Figure 1 A, S153 of Figure 1 B) to create a user account containing the user information that is recorded in the database and to obtain the digital certificate associated with the user identifier through the certificate server.

The user device may be configured to create the private key associated with the obtained digital certificate and to encrypt the private key (S168 of Figure 1 A).

The method may comprise obtaining the digital certificate associated with the user identifier through the certificate server (e.g. S164 of Figure 1A).

The method may comprise sending user information associated with the user input entered during the user login request to the push notification server along with the cryptographic challenge (e.g. S264 of Figure 2C); and displaying the user information at the user device (e.g. S267 of Figure 2C).

The private key used to decrypt the cryptographic challenge may be obtained after successful user authentication at the user device (e.g. S269 of Figure 2C).

Successful user authentication at the user device may occur when a user entered password has been verified (e.g. S269 of Figure 2C).

Successful user authentication at the user device may occur through successful verification of user biometric information (e.g. S269 of Figure 2C).

An application installed in the user device may be configured to store the user biometric information for the verification in a different manner from user biometric information stored by other application installed in the user device.

The user biometrics information for the verification obtained by the application may be different from the user biometric information obtained by other application installed in the user device.

The private key may be stored in a hardware token and the private key is accessible by the user device for decryption upon the successful user authentication.

The private key may be stored in a hardware token and the method may comprise sending from the user device to the hardware token the encrypted random string of the cryptographic challenge for decryption at the hardware token using the private key; and sending from the hardware token to the user device the decrypted random string of the cryptographic challenge.

Optionally, this method may further comprise: generating at the application server a second random string and encrypting the second random string with a public key of an obtained digital certificate associated with a second user (e.g. S314 of Figure 3); sending the encrypted second random string along with a second user identifier of the second user and contact data of the application server from the application server to a push notification server (e.g. S316 of Figure 3); sending a second cryptographic challenge with the encrypted second random string from the push notification server to the second user device after identifying a second user device based on the second user identifier (e.g. S318 of Figure 3); decrypting at the second user device the encrypted second random string of the second cryptographic challenge with a private key of the digital certificate associated with the second user device (e.g. S326 of Figure 3); sending a decrypted second random string of the second cryptographic challenge as a second cryptographic challenge response from the second user device to the application server (e.g. S328 of Figure 3); comparing at the application server the decrypted second random string in the second cryptographic challenge response with the second random string that was generated by the application server (e.g. S330 of Figure 3); and providing the user with one or more services of the application server if the decrypted random string in the cryptographic challenge response matches with the generated random string and the decrypted second random string in the second cryptographic challenge response matches with the generated second random string (e.g. S332 of Figure 3).

The hardware token may be in a form of a Subscriber Identification Module (SIM) card.

The hardware token may be has a form factor of a flash memory card. Optionally, the hardware token may be a secured microSD card.

The user device may have a built-in circuit that functions as a hardware token for storing the private key.

The private key may be arranged to be locked or encrypted at all time, except during a time duration between a user unlocking or decrypting the private key to the decryption of the crypto challenge by the private key.

The cryptographic challenge may be a text string.

The contact data of the application server may be a web address (e.g. 208 of Figure 2A and Figure 3).

The contact data of the application server may be an identifier (e.g. 210 of Figure 2A and Figure 3) to locate a web address of the application server from a plurality of web addresses.

Each of the plurality of web addresses may correspond to one identifier and the identifier may be changed periodically.

There may be provided an apparatus (e.g. 204 of Figure 1 B, Figures 2A to 2C and 3, 450 of Figure 4) for user authentication, the apparatus comprising: a memory (e.g. 458 of Figure 4); and a processor (e.g. 456 of Figure 4) configured to execute instructions (e.g. 460 of Figure 4) in a memory to operate the apparatus to: receive a user request from a user; generate a random string (e.g. 290 of Figure 2A, 291 of Figure 3) and encrypting the generated random string with a public key of a digital certificate (e.g. 144 of Figures 1A, 2A to 2C and 3) associated with the user; send the encrypted random string along with a user identifier (e.g. 146 of Figures 1A, 2A to 2C and 3) and contact data (e.g. 208 or 210 of Figures 2A and 3) of the apparatus to a push notification server(e.g. 114 of Figures 1A, 2A to 2C and 3), wherein the push notification server is configured to send a cryptographic challenge comprising the encrypted random string and the contact data of the application server to a user device {e.g. 110 of Figures 1 A to 1 B, 2A to 2C and 3) and the user device is configured to initiate decryption of the encrypted random string of the cryptographic challenge with a private key associated with the digital certificate; receive a cryptographic challenge response comprising the decrypted random string of the cryptographic challenge sent from the user device, wherein the user device sends the cryptographic challenge response according to the contact data of the apparatus received at the user device; compare the decrypted random string in the cryptographic challenge response with the random string that was generated; and provide to the user with one or more services if the random string in the message matches with the random string that was generated.

There may be provided a device (e.g. 110 of Figures 1A to 1 B, 2A to 2C, and 3, 434 of Figure 4) for user authentication, the device comprising: a memory (e.g. 448 of Figure 3); a processor (e.g. 476 of Figure 4) configured to execute instructions (e.g. 470 of Figure 4) in a memory to operate the device to: receive from a server (e.g. 204 of Figures 1 B, 2A to 2C and 3, 450 of Figure 4) a cryptographic challenge comprising a random string (e.g. 290 in Figure 2A and 291 in Figure 3) encrypted by the apparatus with the public key of the digital certificate (e.g. 144 of Figures 1A, 2A to 2C and 3); decrypt the encrypted random string of the cryptographic challenge with a private key associated with the digital certificate; send a cryptographic challenge response comprising the decrypted random string of the cryptographic challenge to the apparatus, wherein the user device sends the cryptographic challenge response according to the contact data (e.g. 208 or 210 of Figures 2A and 3) of the apparatus received at the user device.

Some advantages of examples of the present disclosure are as follows.

Strong Client Authentication (i.e. submitting a client certificate instead of a password; in short “SCA”) that may be used in examples of the present disclosure is a strong authentication method and requires issuing a digital certificate to every user via a Public Key Infrastructure (PKI). It may also require providing a way to check for certificate revocation. SCA is rather complex. Furthermore, SCA may require a user to know how to obtain and use the certificate, and possibly even require using a hardware token, like a smartcard or USB cryptographic token for enhanced security. However, smartcards and USB tokens can be easily lost or left at home and in an example of the present disclosure, it is proposed to just use key material in a user’s device such as a smartphone. Hardware tokens for smartphones (like a MicroSD chip or secure SIM as described above) are useful for enhanced security but even keeping key material on the smartphone with the private key kept encrypted most of the time, as proposed for some examples of the present disclosure, is secure enough for most applications.

As described in an example of the present disclosure, a“cryptographic challenge” involves, for instance, a server creating a random string (e.g. 16 characters), and encrypting with a user’s public key (from their certificate). The encrypted random string (the“cryptographic challenge”) is sent to the user, and only they can decrypt it using their private key. The decrypted challenge is returned to the server, which compares it against the original random string. If it matches, that is proof that the user has possession of and ability to use their private key, which authenticates them. An advantage of this approach is that no password is required.

In examples of the present disclosure, embedding the cryptographic challenge in a push notification, and using, for instance, Identity Registration Protocol (IRP), to obtain the key material on a user’s device such as a smartphone, allows the complexity of Strong Client Authentication to be hidden from the user. When users login to the server, they may only supply their username. This allows retrieval or selection of their certificate on the server. The certificate may be validated in PKI to make sure it is trusted, has not expired and has not been revoked. The public key from the certificate can be used to encrypt the random string to create the cryptographic challenge, which is sent to the user. The user must decrypt the cryptographic challenge with their private key. If using a“soft token” (e.g. a file locally stored on a smartphone), the private key can be kept encrypted most of the time, and only decrypted long enough to decrypt the challenge, triggered by providing a PIN or fingerprint. If using a“hard token” (e.g. a key in a hardware cryptographic token), biometric verification such as fingerprint can be used to lookup or decrypt the PIN needed to enable access to the private key in the token.

Such scheme described above is inherently two factor, even without a password - the first factor is something the user HAS (e.g. their smartphone and key material) and the second factor is something they ARE (e.g. fingerprint) or something they KNOW (e.g. PIN) if there is no biometric reader on their user device such as smartphone. This PIN they KNOW is different from a password because it is not sent to the server via the Internet. It is only used locally on the user device to enable access to the private key. Soft token is easy to deploy and secure enough for most purposes. For high transaction amounts or very sensitive information, a hard token in the user device such as smartphone is recommended (e.g. MicroSD chip or secure SIM). The scheme described above works equally well with soft or hard token. A hard token in the user device provides key material for many purposes, in addition to authentication or authorization (e.g secure messaging, digitally signing documents, decrypting files, etc).

Throughout this specification and claims which follow, unless the context requires otherwise, the word“comprise”, and variations such as“comprises” or“comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

While the invention has been described in the present disclosure in connection with a number of embodiments and implementations, the invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims. Although features of the invention are expressed in certain combinations among the claims, it is contemplated that these features can be arranged in any combination and order.