Patent Description:
Electronic commerce, social media access and other forms of on-line digital activity or service usually require some form of user authentication or user identification. For example, a user wishing to access a banking website or application may be required to enter a username and password. This approach, however, is generally considered not only to be inconvenient, as it requires the user to remember his or her username and password, but also to be vulnerable to fraudulent access since the user can choose a password which is simple and/or easy to guess or find by someone other than the proper user. Added to this, the user may need many different usernames and passwords for different activities or services which makes it harder for the user to remember usernames and passwords and so making it more likely that he or she will use the same username and passwords for several services.

Security can be increased by using more than one factor, such as a password or other form of knowledge factor, and a token generator or other form of possession factor. In particular, mobile phone two-factor authentication (whereby a user's mobile phone can be used to provide one-time password) is becoming increasingly popular.

Convenience can be improved by using an approach, for example, which does not require a password or allows a single log in. For example, GSMA Mobile Connect allows a user to log into a website or application without a username or password. Further details can be found at https://mobileconnect.

<CIT> describes a system for building tolerance into authentication of a computing device, which includes a means for executing, from a computer-readable medium, computer-implementable steps of: (a) receiving and storing a first digital fingerprint of the device during a first boot of an authenticating software on the device, the first digital fingerprint based on a first set of device components, (b) receiving a second digital fingerprint from the device at a subsequent time, (c) comparing the second digital fingerprint with a plurality of stored digital fingerprints of known devices, (d) in response to the comparison indicating a mismatch between the second digital fingerprint and the plurality of stored digital fingerprints, generating a request code comprising instructions for the device to generate a third digital fingerprint using the first set of device components, (e) sending the request code to the remote device, (f) receiving the third digital fingerprint from the remote device in response to the request code, and (g) authenticating the device based on a comparison of the first and third digital fingerprints.

<CIT> discloses a system and method for securely linking a phone number and user identification code in a directory database. A computer-implemented method comprising: receiving a first request from a first user device to register with a first service, the request identifying a phone number of the user device and including a fingerprint code uniquely identifying the first user device; registering the phone number in a directory service; receiving a second request from the first user device to register with a second service, the request including a user identification code which is not a phone number and the fingerprint code; registering the user identification code in the directory service; detecting that the first request and second request are from the same mobile device using the fingerprint code; and responsively linking the phone number and the user identification code in the directory database.

<CIT> describes a system which facilitates secure communication between an authorized user device and two or more servers via two or more channels that are associated with the respective servers. For each communication channel, the system receives a device identifier for the authorized user device and links the device identifiers together via another identifier, thereby allowing the system to recognize that the different device identifiers identify the same authorized user device. The system can identify an unauthorized device masquerading as the authorized user device by determining that a communication from the unauthorized device does not include another identifier linking the two or more device identifiers and/or by determining that a device identifier computed during the registration process is different from a linked identifier.

<CIT> discloses a method and system for authenticating secure transactions between a transacting user and a secure transaction host. The system includes a mobile phone software application installed on a transacting user's mobile phone which is configured to compose a digital fingerprint uniquely associated with the specific mobile phone on which it is installed. The system further includes an authentication service provider with which users of the system may be enrolled by registering at least the digital identifiers composed by the applications installed on their mobile communication devices in an authentication database. The authentication service provider is configured to authenticate secure transactions on request from secure transaction hosts by sending transaction confirmation requests to mobile phones of enrolled users requiring them to confirm or deny secure transactions before such transactions are allowed to be finalized.

According to a first aspect of the present invention there is provided an authentication system configured, in an enrolment phase, to exchange data with an application running on a mobile terminal via a second channel so as to receive a terminal fingerprint of the mobile terminal from the application via the second channel and to exchange data with a secure element comprised in the mobile terminal via a first, different channel so as to determine, via the first channel, a secure element identifier and a hardware identifier of the mobile terminal. The authentication system is further configured, in the enrolment phase, in response to receiving, from a source, a request to enrol a user comprising a user identifier and an identifier of the mobile terminal, to transmit a first password to the source for presentation to the user and/or to the mobile terminal, in response to receiving, from the application running on the mobile terminal, a first key (K1), the first terminal fingerprint and a copy of the first password via the second channel, to link the user identifier, the identifier of the mobile terminal, the application and the mobile terminal, to transmit a random number to the secure element in the mobile terminal via the first channel, to send a second key (K2) to the secure element via the first channel, in response to receiving, from the secure element via the first channel, an encrypted message comprising a second terminal fingerprint encrypted with the second key, wherein the second terminal fingerprint comprises the secure element identifier and the hardware identifier, to transmit a second password, to the secure element via the first channel, and in response to receiving, from the application via the second channel, a copy of the second password and in dependence upon the copy of the second password matching the second password, to link the user identifier and the second terminal fingerprint or data included the second terminal fingerprint.

According to a second aspect of the present invention there is provided a mobile terminal for use in authenticating a transaction comprising a secure element and an application running on the mobile terminal, the application configured, in an enrolment phase, to exchange data with an authentication system via a second channel so as to provide a first terminal fingerprint of the mobile terminal to the authentication system via the second channel. The secure element is configured, in an enrolment phase to exchange data with the authentication system via a first, different channel so as to provide a secure element identifier and a hardware identifier of the mobile terminal to the authentication system via the first channel. The mobile terminal is further configured, in the enrolment phase, in response to the authentication system receiving, from a source, a request to enrol a user comprising a user identifier and an identifier of the mobile terminal, and the authentication system transmitting a first password to the source for presentation to the user and/or to the mobile terminal, to send a first key (K1), the first terminal fingerprint and a copy of the first password via the second channel from the application running on the mobile terminal to the authentication system, wherein the authentication system is configured to link the user identifier, the identifier of the mobile terminal, the application and the mobile terminal in response to receiving the first key, the second terminal fingerprint, and the copy of the first password, in response to the secure element receiving a random number and a second key from the authentication system via the first channel, to send an encrypted message comprising a second terminal fingerprint encrypted with the second key, wherein the second terminal fingerprint comprises the secure element identifier and the hardware identifier, from the secure element via the first channel to the authentication system, in response to the secure element receiving a second password from the authentication system via the first channel, to send a copy of the second password from the application via the second channel to the authentication system, wherein the authentication system is configured to link the user identifier and the second terminal fingerprint or data included the second terminal fingerprint in dependence upon the copy of the second password matching the second password.

Referring to <FIG>, a user <NUM> has an identity <NUM> which can be linked to a plurality of assets (or "factors") <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> which may be used to corroborate the identity <NUM> of the user <NUM> and, thus, serve to authenticate the user <NUM>.

The assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may include an application (or "app") <NUM> installed on a mobile terminal <NUM> (herein simply referred to as the "terminal") which is used as an interface for the user <NUM> to confirm transactions, the terminal <NUM>, a secure element <NUM> such as a subscriber identification module (SIM) <NUM> in the terminal <NUM>, an applet <NUM> such as a SIM applet on the secure element <NUM> (herein, the applet <NUM> is also referred to as a SIM applet), one or more biometric features <NUM>, a personal identification number (PIN) <NUM> (which does not need to be purely numeric, but which can include letters or other types of characters), a one-time password (OTP) <NUM> and location <NUM>. Example of mobile terminals <NUM> include a laptop computer, a smart phone, a tablet, a wearable device or other form of network-enabled device including an Internet-of-Things (or IoT) device or embedded device. Examples of biometric features include fingerprint, iris scan, voice recognition, gesture behaviour, etc. Herein the term "SIM" is intended to cover a Universal Subscriber Identity Module (USIM), a Universal Integrated Circuit Card (UICC), a virtual SIM (such as trusted execution environment (TEE)), and other similar types of mobile terminal secure element.

The assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may fall into one of several categories <NUM>, <NUM>, <NUM>, <NUM> which define a relationship to the user. For example, an asset <NUM>, <NUM>, <NUM>, <NUM> may be a user possession <NUM>, i.e. what the user has. An asset <NUM> may be a user physical characteristic <NUM> (herein referred to as a "biometric feature"), i.e. what the user "is". An asset <NUM>, <NUM> may be user knowledge <NUM>, i.e. what the user knows. An asset <NUM> may be user location <NUM>, i.e. where the user is.

These assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can provide n-factor authentication, where n = <NUM>, <NUM>, <NUM> or more, using at least one asset <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in each of at least two, preferably at least three, different relationship-defining categories <NUM>, <NUM>, <NUM>, <NUM>, such as the app <NUM> and the terminal <NUM>, and the PIN <NUM> and/or the biometric feature <NUM>.

Referring to <FIG>, a system <NUM> is shown.

The system <NUM> includes an authentication system <NUM> (herein also referred to as "a core identity backend") which may comprise one or more servers and which includes a database <NUM> storing a table <NUM> which includes an entry <NUM> for each user enrolled with the system. As will be explained in more detail later, an entry <NUM> includes a plurality of fields <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> related to the user and their identity-corroborating assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (<FIG>).

The authentication system <NUM> is provided with a hardware security module (HSM) <NUM> which can generate or store user-specific keys K1, K2. An example of a suitable HSM <NUM> is the Ezio Confirm Authentication Server marketed by Gemalto N. , Amsterdam, The Netherlands.

The app <NUM> which runs on the terminal <NUM> contains a corresponding software development kit (SDK) that can handle key creation, securing a connection <NUM> between the app <NUM> and the core identity backend <NUM>, detection of rooted or jailbroken device, anti-hook detection, code obfuscation, fingerprinting of the terminal on operating system (OS) side and other security features, such as disable screen capture during PIN entry, secure PIN pad, no view of pressed keys and so on. As will be explained in more detail hereinafter, a key can be used as a seed and a PIN can be used in software to generate a time-based OTP (TOTP), which is sent together with a signed payload containing a terminal fingerprint generated on the operating system side of the terminal OS side and a context of the transaction. The terminal fingerprint is a set of data which is unique to the end user mobile terminal. The context can be signed using OCRA, and the TOTP and OCRA-signed context can be sent to the backend <NUM> and checked against the calculated corresponding values.

The system <NUM> includes an identity registrar <NUM> for example which may be provided by a government office, government agency, bank or other trusted entity. As will be explained in more detail hereinafter, the identity registrar <NUM> allows an end user <NUM> (<FIG>) to transfer his or her verified identity in a secure way to the core identity backend <NUM>. The user <NUM> (<FIG>) may present proof of identity <NUM>, for example, in the form of an identity card or passport, in person, at the identity registrar <NUM>, or from a remote location to the identity registrar <NUM> (i.e. without being present at the identity registrar <NUM>) using a card reader (not shown). The proof of identity <NUM> may take the form of an electronic device, such as a smart card, which can be read by a card reader (not shown). The authentication server <NUM> and the identity registrar <NUM> communicate securely with via an interface <NUM>.

The system <NUM> includes a server provider <NUM>, such as a bank, on-line vendor etc., which may communicate with a service provider app <NUM> running on the terminal <NUM> or other device, or serve webpages to a web browser running on the terminal <NUM> or another device. The service provider <NUM> is an external partner delivering services to the end user <NUM> that integrates the authentication services provided by authentication system <NUM> including authentication, authorisation, identification and digital signature. The server provider <NUM> communicates securely with the authentication server <NUM> via an interface <NUM>. The core identity backend <NUM> and the service provider <NUM> can exchanges messages according to a suitable protocol, such as Simple Object Access Protocol (SOAP), OpenID or Security Assertion Markup Language (SAML).

The authentication system <NUM> is able to communicate with the terminal <NUM> via a public land mobile network <NUM> (herein referred to simply as a "mobile network") which comprises core mobile network systems <NUM> which include, among other things, a home location register (HLR) <NUM>, over-the-air (OTA) infrastructure <NUM> which may secure communication with a key K3, and a Short Message Service (SMS) centre <NUM> (or other messaging service centre).

The HLR <NUM> stores for each user subscribing to the mobile network, a Mobile Station International Subscriber Directory Number (MSISDN) <NUM>, an International Mobile Subscriber Identity (IMSI) <NUM> and International Mobile Equipment Identity (IMEI) <NUM>. The MSISDN <NUM> is often referred to as the mobile phone number of the end user, the IMSI <NUM> is a unique identifier of the SIM card <NUM> and the IMEI <NUM> is a unique identifier of the terminal <NUM>.

The core identity backend <NUM> and the mobile network <NUM> communicate securely via a mobile network gateway <NUM>.

The terminal <NUM> comprises a CPU-based controller <NUM>, volatile and non-volatile memory <NUM>, <NUM>, a display <NUM>, user input device(s) <NUM>, a biometric feature input device <NUM>, a positioning device <NUM> (for example in the form a GPS receiver), a mobile network interface <NUM> and wireless local area network interface <NUM>. The display <NUM> and at least one user input device <NUM> may be integrated into a touch screen display. Other input devices <NUM> may include switches. In this example, the biometric feature input device <NUM> takes the form of a fingerprint scanner for providing touch ID. For clarity and brevity, other parts of the terminal <NUM>, such a battery, speaker, microphone etc., are not described.

The terminal <NUM> runs an operating system (OS) <NUM> and can load and run other applications including the service provider app <NUM>, a browser <NUM> and the authentication app <NUM> (herein also referred to as the "Belgian Mobile ID app" or "BMID app"). The terminal <NUM> may run an iOS, Android or other operating system. The mobile terminal <NUM> may support communication using second generation enhanced data rates for GSM evolution (EDGE) communication protocols, third-generation (<NUM>) communication protocols, HSDPA communication protocols, fourth-generation (<NUM>) communication protocols and/or <NUM> LTE communication protocols and later communication protocols (such as <NUM> communication protocols).

Being a mobile terminal <NUM> which can connect to the mobile network <NUM>, the terminal <NUM> stores baseband data <NUM> which contains information used for mobile services, including, for example such as IMEI, mobile country code (MCC), mobile network code (MNC), location area code (LAC) and Cell ID (CID). One or more pieces of baseband data <NUM> can used as a location asset <NUM> (<FIG>).

The terminal <NUM> runs software <NUM> for receiving and sending SMS messages or suitable form of message which may be received from mobile network <NUM>. The terminal <NUM> also runs a secure element software development kit (SDK) <NUM> (herein referred to as a "SIM software development kit"). The terminal <NUM> contains a secure element <NUM> which can take the form of a removably insertable card of given form factor, such as a micro-SIM (3FF) or nano-SIM (4FF), or may take the form of an embedded SIM, such as an eSIM, or virtual SIM (such as TEE). The SIM <NUM> stores an elementary file (EF) file system <NUM> and a copy of the OTA key K3.

The SIM applet <NUM> can store a public-private key pair K2 and also a counter value <NUM>. As will be explained in more detail later, the counter value <NUM> can be used to generate an OTP. The SIM applet <NUM> may be installed on the secure element <NUM>, but not initialised when the user takes possession of the SIM <NUM> (for example when the user buys the terminal or a mobile phone contact). Alternatively, the SIM applet <NUM> may be downloaded and installed after the user takes possession of the secure element <NUM>.

As will be explained in more detail hereinafter, the authentication app <NUM> or operating system <NUM> may generate a fingerprint of the terminal <NUM> which is unique for the end user terminal.

The user <NUM> (<FIG>) can use the terminal <NUM> and other assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (<FIG>) to enrol with the core identity backend <NUM> and authenticate his or her identity using the core identity backend server <NUM> to secure a transaction with the service provider <NUM>.

Two different channels <NUM>, <NUM> are used in both setting up an authentication account and during authentication. In the first channel <NUM>, the SIM applet <NUM> and the core identity backend <NUM> communicate using the OTA channel of the mobile network <NUM>. In a second channel <NUM>, the BMID app <NUM> and the core identity backend <NUM> communicate via the Internet <NUM> using a WiFi or mobile data connection. Both channels <NUM>, <NUM> are secured and payloads are encrypted using application and applet keys K1, K2.

The user <NUM> (<FIG>) may enrol and/or may request a transaction using the terminal <NUM>. The user <NUM> (<FIG>) may enrol and/or may request a transaction via another device <NUM> (herein simply referred to as a "computer"), such as a desktop computer, laptop computer or tablet device, which is used in conjunction with the terminal <NUM>.

The computer <NUM> includes at least one processor <NUM>, memory <NUM>, storage <NUM> (e.g. in the form of SSD), a display <NUM>, one or more user input device(s) <NUM> and at least one network interface <NUM> (which may be wired or wireless). The computer <NUM> can run a browser <NUM> which may be used to communicate with the identity registry <NUM> and/or the service provider <NUM>.

Referring to <FIG>, the authentication system <NUM> is shown in more detail.

The core identity backend <NUM> may take the form of a server comprising at least one processor <NUM>, memory <NUM>, storage <NUM>, a display <NUM>, one or more user input device(s) <NUM> and at least one network interface <NUM>.

The core identity backend <NUM> includes an enrolment module <NUM>. The enrolment module <NUM> includes an enrolment manager <NUM>, password manager <NUM> and a table manager <NUM>. The authentication server <NUM> also includes an approval module <NUM>. The approval module <NUM> includes an approval manager <NUM>, password manager <NUM> and a table manager <NUM>. Other configurations may be used.

As will be explained in more detail hereinafter, the backend <NUM> generates two challenges, namely one for the SIM applet <NUM> and one for the app <NUM>. The SIM applet challenge is based on IMSI, IMEI and a time- or counter-based OTP. The app challenge is based on a terminal fingerprint and a transaction context, where the terminal fingerprint comprises a list of technical parameters or characteristics related to the operating system, device, app, and the like, and an application key K1, with the result being an OTP which is sent to the backend <NUM>. The challenge of the SIM applet <NUM> is sent to the core backend through the UMTS carrier (OTA/SMS). The challenge/OTP of the app is sent to the core backend through the Internet (WiFi or mobile data). Thus, there are two separate (i.e. independent) channels. The backend <NUM> checks both challenges to validate if the transaction can go through.

Referring to <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG>, an end user <NUM> enrols to use the authentication service. During enrolment, the core identity backend <NUM> links the user's identity <NUM> to a plurality of assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>.

A user initiates enrolment through an identity registrar <NUM> (step S401).

<FIG> shows an example of how the user <NUM> can enrol to use the authentication service using a browser <NUM> on a computer <NUM> and the terminal <NUM>. The user <NUM> can, however, enrol using a service provider app <NUM> running on the computer <NUM> in conjunction with the terminal <NUM> or using a service provider app <NUM> or browser <NUM> running on the terminal <NUM>, or even in person at, for example, the identity registry <NUM> using the terminal <NUM>.

In this case, a bank serves an identity registry <NUM> with which the user has at least one bank account and has previously proved their identity using an identity card <NUM> or other form of proof of identity.

In the following, an example of set of web pages <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> which are presented to the user <NUM> are shown. The web pages, including their order and content, can differ.

Referring in particular to <FIG> and <FIG>, the identity registrar server <NUM> presents the user <NUM> with a first web page <NUM> which includes a link <NUM> to a second web page <NUM>. The user may have already presented credentials to access the first web page <NUM>. The second page <NUM> includes a field <NUM> for entering a debit or credit card number, and a link <NUM> to a third web page <NUM>. The third web page <NUM> includes information <NUM> about the account(s), one or more links <NUM>, <NUM> to perform respective actions, such as transfer funds, make on-line payments, and a link <NUM> to create an authentication service account, which links to a fourth web page <NUM>. The fourth web page <NUM> includes a field <NUM> for entering the telephone number, i.e. the MSISDN <NUM>, of the terminal <NUM> possessed by the user <NUM>. The fourth web page <NUM> may include, in response to a challenge (not shown), a response <NUM>. The fourth web page <NUM> includes a link <NUM> to a fifth web page <NUM>. The fifth web page <NUM> includes a summary <NUM> of user details, a check box <NUM> for agreeing to terms and conditions, and a link <NUM> to continue.

Referring now to <FIG> and <FIG>, the identity registrar server <NUM> can present a sixth web page <NUM> to the user <NUM> which confirms the request to set up an authentication account and includes relevant information <NUM>, such as the MSISDN <NUM>, and a link <NUM> prompting the user to continue to the next page.

Referring again to <FIG>, <FIG> and <FIG>, in response to receiving agreement of terms and conditions and confirmation to continue, the identity registrar <NUM> (in this case, the bank) transmits a request <NUM> to create an authorisation account to the core identity backend <NUM> (step S402). The request <NUM> includes the user's identity <NUM> and the MSISDN <NUM>.

The core identity backend <NUM> generates an OTP <NUM> (herein referred to a "token") to secure the session between the identity registrar <NUM> and the BMID app <NUM> (step S403) and sends the token <NUM> over a secure connection to the identity registrar <NUM> (step S404). The identity registrar <NUM> presents the token <NUM> in a seventh web page <NUM> in the browser <NUM> at the computer <NUM> (step S405).

If not already done, the user acts to cause the terminal <NUM> to download and install the app <NUM> (step S406).

Referring in particular to <FIG>, <FIG> and <FIG>, the end user opens the BMID app <NUM> and enters his or her MSISDN <NUM> (step S407). On being opened for the first time, the app <NUM> can present a window <NUM> which includes a button <NUM> prompting the user to create an account. The app <NUM> prompts the user, in a screen <NUM>, to enter the MSISDN <NUM> in a field <NUM> and a link <NUM> to continue. Once the user has entered to MSISDN <NUM>, the app <NUM> may present a screen <NUM> indicating that the MSISDN <NUM> is being verified.

The app <NUM> creates a public-private key pair K1 comprising pk, sk (step S408) and sends the public key pk, together with the MSISDN <NUM>, to the core identity backend <NUM> (step S409). The core identity backend <NUM> can then link the MSISDN <NUM> to an existing session with the identity registry <NUM>. The app <NUM> creates a terminal fingerprint <NUM> on operating system side of the terminal <NUM> (step S410) and sends it to the core identity backend <NUM> to link the app <NUM> and the terminal <NUM> with the identity <NUM> and MSISDN <NUM> (step S411). Herein, the terminal fingerprint <NUM> created by the app <NUM> is referred to a "first terminal fingerprint" or "OS-side terminal fingerprint".

The app <NUM> prompts the user to enter the token <NUM> into the app <NUM> (step S412). For example, the app <NUM> presents a screen <NUM> which includes a field <NUM> into which the user can enter the token <NUM> and a button <NUM> to indicate that the user wishes to proceed. Once the user has entered the token <NUM>, the app <NUM> may present a screen <NUM> indicating that token <NUM> is being verified. The app <NUM> sends the copy of token <NUM> to the core identity backend <NUM> (step S413).

The token <NUM> is used to secure the session between identity registrar <NUM> and app <NUM> because the end user <NUM> could be connected via the computer <NUM> on the identity registrar website and to the BMID app <NUM> on his or her terminal <NUM>. If, however, the identity registrar <NUM> has an app on the same terminal <NUM> as the BMID app <NUM>, then the token <NUM> can be transferred silently and encrypted in app-to-app mode. In other words, the user need not be prompted to enter the token <NUM> into the app <NUM>.

The core identity backend <NUM> checks the MSISDN <NUM> and the token <NUM> received from the app <NUM> to determine whether an enrolment process is pending (step S414). If the transmitted token <NUM> and the received token <NUM> match, then the core identity backend <NUM> links the user's identity <NUM>, MSISDN <NUM>, app <NUM> and terminal <NUM> in the entry <NUM> in the table <NUM> (step S415).

Referring in particular to <FIG>, <FIG> and <FIG>, using the HSM <NUM>, the core identity backend <NUM> generates an initial, temporary PIN <NUM> (step S416) and sends it via SMS (or other suitable messaging service) as an SMS message <NUM> to the terminal <NUM> (step S <NUM>).

The terminal <NUM> displays the message <NUM> which includes the initial PIN <NUM> in screen <NUM> (step S418). The end user <NUM> switches to the app <NUM> and the app <NUM> prompts the user to enter the initial PIN <NUM> (step S419). For example, the app <NUM> presents a screen <NUM> which includes a field <NUM> into which the user can enter the initial PIN <NUM> and a button <NUM> to indicate that the user wishes to proceed. Once the user has entered the initial PIN <NUM>, the app <NUM> may present a screen <NUM> indicating that the initial PIN <NUM> is being verified.

The BMID app <NUM> uses the PIN <NUM> to perform a one-way encryption to generate a hash <NUM> (step S420) and the hash <NUM> is transmitted to the core identity backend <NUM> (step S421). The core identity backend <NUM> generates its own version of the hash <NUM> using the HSM <NUM> (step S422) to check whether the user-entered PIN <NUM> is correct (step S423). If correct, the core identity backend <NUM> sends a result <NUM> back to the app <NUM> (step S424).

The BMID app <NUM> prompts the user to create and confirm a new PIN <NUM> (step S425). For example, the app <NUM> presents a screen <NUM> which includes a field <NUM> into which the user can enter a new PIN <NUM> and a button <NUM> to indicate that the user wishes to proceed. The app <NUM> may present another screen (not shown) asking the user to re-enter their new PIN <NUM>. Once the new PIN <NUM> is confirmed, the app <NUM> links the new PIN <NUM> via a new hash <NUM> to the application key K1. Thus, if the PIN <NUM> is entered in the future, then another hash is generated, compared with the stored hash <NUM> and, if the hashes match, then the application key K1 is unlocked.

The BMID app <NUM> prompts the user to activate a biometric function, such as Touch ID or Fingerprint (step S426). For example, the app <NUM> presents a screen <NUM> which a first button <NUM> whereby the user can confirm he or she wishes to activate a biometric function and a second button <NUM> whereby the user declines to activate a biometric function. If the user activates a biometric function, then the terminal <NUM> prompts the user to provide biometric input, for example to press fingerprint scanner <NUM>. Once the user has provided biometric input, the app <NUM> may present a screen <NUM> indicating that biometric input is being processed.

The BMID app <NUM> activates the biometric function (step S428) and sends a confirmation message <NUM> to the core identity backend <NUM> (step S429).

The core identity backend <NUM> updates the account level field <NUM> in the table <NUM> to indicate that the authentication account has been activated with a first, low level of security (step S430). An authentication account with a low-level of security allows the user to use their terminal <NUM>, in particular the BMID app <NUM>, to authenticate low-risk or low-value transactions, for example having a value no more than EUR <NUM>.

The core identity backend <NUM> sends a message <NUM> to the identity registrar <NUM> to signal that that the authentication account has been activated (step S431).

At this point, the user's identity <NUM> has been linked to a software asset <NUM>, namely the BMID app <NUM>. Thus, only a partial degree of linking has been performed. Further binding, in particular involving other, independently accessed parts of the terminal <NUM>, is carried out to provide stronger security, as will now be described in more detail.

The core identity backend <NUM> can automatically start the process of further binding or can first check whether to perform further binding (steps S432 to S434). This may include notifying the mobile network operator that the core identity backend <NUM> intends to perform hardware binding and to check whether the applet <NUM> is already installed on the secure element <NUM> or, if not installed, whether the applet <NUM> can be installed on the secure element <NUM> (steps S432 & S434).

The core identity backend <NUM> sends a request <NUM> for the IMSI <NUM> and IMEI <NUM> of the MSISDN <NUM> via the mobile network gateway <NUM> to the core mobile network systems <NUM> (step S435). The core mobile network systems <NUM> sends a reply <NUM> which contains the IMSI <NUM> and IMEI <NUM> at the time the terminal <NUM> is connected to the mobile network <NUM> and which is linked to the given MSISDN <NUM>, which is known at that time and which is stored in the HLR <NUM>. The IMSI <NUM> and IMEI <NUM> are stored in the table <NUM>.

The core identity backend <NUM> retrieves the applet key K2 from the HSM <NUM> (step S436) and initialises the SIM applet <NUM> via the mobile network gateway <NUM> via OTA by sending a message <NUM> containing applet key K2 (steps S437 to S440). The OTA <NUM> encapsulates the message <NUM> into an OTA APDU with OTA key K3 so as to ensure that the applet key K2 is transmitted securely. After receiving and decrypting the message <NUM>, the SIM applet <NUM> stores the applet key K2 in the SIM <NUM> (step S441).

The core identity backend <NUM> then sends a request <NUM> to the SIM applet <NUM>, via the mobile network gateway <NUM>, to send a fingerprint <NUM> of the terminal <NUM> from the secure element side (step S442).

The SIM applet <NUM> retrieves the IMSI <NUM> from the EF file system <NUM> stored on the secure element <NUM> and the IMEI <NUM> of the terminal <NUM> from the baseband data <NUM> via the SIM toolkit <NUM> to create the terminal fingerprint <NUM> (step S443). Herein, the terminal fingerprint <NUM> created by the applet <NUM> is referred to as the "second terminal fingerprint" or "secure element-side terminal fingerprint". The SIM applet <NUM> encrypts the second fingerprint <NUM>, which contains the IMSI <NUM>, the IMEI <NUM> and applet version (not shown), with the applet keys K2 (step S444) and sends the encrypted fingerprint <NUM> to the core identity backend <NUM> (step S445).

The core identity backend <NUM> checks if the IMSI <NUM> and IMEI <NUM> correspond to the IMSI <NUM> and IMEI <NUM> received via the mobile network gateway <NUM> (step S446).

If there is a match, then the core identity backend <NUM> generates an OTP <NUM> (herein referred to as a "verification code") (step S447) and sends a request <NUM> containing the verification code <NUM> to the SIM applet <NUM> to display the verification code <NUM> (step S448). This helps to ensure that the app <NUM> and the SIM applet <NUM> are on the same terminal <NUM>.

The SIM applet <NUM> displays the verification code <NUM> via SIM toolkit display text API (step S449). For example, the SIM applet <NUM> displays the verification code <NUM> in screen <NUM>.

The end user switches to the app <NUM> and the app <NUM> prompts the user to enter the initial PIN <NUM> (step S450). For example, the app <NUM> presents a screen <NUM> which includes a field <NUM> into which the user can enter the verification code <NUM> and a button <NUM> to indicate that the user wishes to proceed. The app <NUM> may also prompt the user to enter their PIN. For example, the app <NUM> presents a screen <NUM> which includes a field <NUM> into which the user can enter their PIN <NUM> and a button <NUM> to indicate that the user wishes to proceed. Once the user <NUM> has provided the verification code <NUM> and, optionally, their PIN <NUM>, the app <NUM> may present a screen <NUM> indicating that the system is verifying the code <NUM>.

The BMID app <NUM> sends the user-entered verification code <NUM> to the core identity backend <NUM> (step S451). The core identity backend <NUM> checks whether the verification code <NUM> is correct (step S452) and, if so, links the IMSI <NUM> and IMEI <NUM> to the identity, for example, setting a flag <NUM> (step S453).

The core identity backend <NUM> sends a confirmation <NUM> to the BMID app <NUM> (step S454).

The BMID app <NUM> makes a call <NUM> to the applet <NUM> (step S455) that triggers another SIM toolkit screen <NUM> displaying the account was activated with the SIM security (step S456). In response to the user clicking a "continue" button <NUM>, the applet <NUM> notifies the app <NUM> with a message <NUM> (step S457). The BMID app <NUM> displays a screen <NUM> containing a message <NUM> that the link was successful (step S458) and then returns to the app home screen <NUM> which includes a menu <NUM>.

The BMID app <NUM> sends a confirmation message <NUM> to the core identity backend <NUM> (step S459). The core identity backend <NUM> updates the account level field <NUM> in the table <NUM> to indicate that the authentication account has been activated with a second, high level of security (e.g. eIDAS "high" security level) (step S460).

At this point, the user's identity <NUM> has been linked not only to the BMID app <NUM>, but also to the SIM applet <NUM> on the SIM <NUM> using first and second independent channels <NUM>, <NUM> respectively. Thus, a greater degree of linking has been performed and so the terminal <NUM> can be used to authenticate higher-value transactions.

Referring to <FIG>, <FIG> and <FIG>, an end user <NUM> (<FIG>) use the mobile authentication service to authenticate a transaction. In particular, assets <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> are used to corroborate the user's identity <NUM> (<FIG>).

The end user <NUM> requests a transaction at a service provider application (step S801). For example, the user may want to login to an application (such as banking app) or website (such as a banking website), to share identity data (for instance to create an account on an e-commerce website), to provide approval (for example, to approve a financial transaction in banking app or website, to approve transfer of medical information from doctor to insurance etc.) or to provide a qualified electronic signature or the like.

In relation to an approval, a hash can be created that is made up of part of the context that is signed (similar to a hash that is created for a bank transaction with a 3D-secure check whereby a user uses a bank card reader to type in an amount and a part of the beneficiary bank account, which then generates a challenge after which the hash is sent to the bank). In this case, however, no card reader is used. Instead, the BMID app <NUM> performs that role.

In relation to qualified electronic signature, the full context is signed with a qualified certificate. Using the process herein described, it is possible to sign meeting any of the three security levels (i.e. low, substantial and high) specified by the eIDAS regulation. <FIG> shows an example of how the user <NUM> can request a transaction using a browser <NUM> running on a computer <NUM> and can authenticate the transaction using the terminal <NUM>. In this case, a service provider is a bank.

Referring in particular to <FIG> and <FIG>, the service provider <NUM> presents the user <NUM> with a first web page <NUM> which includes a link <NUM> to sign in and a link <NUM> to sign in using a mobile number. For example, if SOAP or SAML is used, the service provider <NUM> presents a second web page <NUM> includes a field <NUM> for entering the telephone number, i.e. the MSISDN <NUM>, of the terminal <NUM> possessed by the user <NUM>. The web page <NUM> may include, in response to a challenge (not shown), a response <NUM>. The web page <NUM> includes a link <NUM> to continue. If OpenID is used, the service provider <NUM> redirects to a centralized OpenID page hosted by the core identity backend <NUM>. In case of an app running on the terminal <NUM>, the telephone number can be transferred in app-to-app mode.

The service provider <NUM> sends a request <NUM> to authenticate a transaction to the core identity backend <NUM> via the service provider interface <NUM> (step S802). The request <NUM> includes the MSISDN <NUM> and a request (not shown) for the level of security required for the transaction. Levels of security may include (<NUM>) PIN only, (<NUM>) biometric only, (<NUM>) PIN and biometric, (<NUM>) PIN and OTP via SMS, (<NUM>) PIN and biometric and OTP via SMS.

The core identity backend <NUM> retrieves the IMSI <NUM> and IMEI <NUM> of the terminal (step S803). The core identity backend <NUM> sends a request <NUM> (or "first challenge") to the SIM applet <NUM> via the first channel <NUM>, that is, via the mobile network gateway <NUM> and the OTA network, for SIM-side terminal fingerprint (step S804).

The SIM applet <NUM> retrieves the IMSI <NUM> from the SIM <NUM> and the IMEI <NUM> from the baseband data <NUM> via the SIM toolkit (step S805) and determines its location via the SIM toolkit (step S806). The SIM applet <NUM> generates a terminal fingerprint <NUM> which includes the IMSI <NUM>, IMEI <NUM>, applet version (not shown) and location (not shown) (step S807). The SIM applet <NUM> also generates an OTP <NUM>, for example using a value of counter <NUM>, and which may be signed using one-way OCRA encryption (step S808). A message <NUM> (or "first response") comprising the terminal fingerprint <NUM> and OTP <NUM> is encrypted using the SIM applet application keys K2 and by the OTA keys K3 and transmitted by the first channel <NUM> (step S809). The encrypted message <NUM> is transmitted to the core identity backend <NUM> via the second channel <NUM>, i.e. via the OTA network of the mobile network <NUM> (step S810).

The core identity backend <NUM> checks whether the terminal fingerprint <NUM> corresponds with the IMSI <NUM> and IMEI <NUM> held locally (step S811). The core identity backend <NUM> also checks whether the OTP <NUM> corresponds to one generated locally (steps S812 & S813). If the terminal fingerprint check or the OTP check fails, then the transaction is aborted.

The core identity backend <NUM> may also check the location of the terminal <NUM> (step S814). In particular, the core identity backend <NUM> may check whether the terminal <NUM> is located in an acceptable country or region of a country, is located in an unacceptable country or region of a country, or whether the login location and the location of the terminal <NUM> or the locations between two transactions differ by more than given distance or by more than given distance in a given time (e.g. login in country A and approval in country B which is over <NUM>,<NUM> away, <NUM> minutes later). Thus, location can be used as a risk parameter for fraud detection and/or can be used as an additional factor for authentication.

If the terminal fingerprint corresponds to the one obtained during the binding process, then the core identity backend <NUM> transmits a notification <NUM> to the app (step S815).

The app <NUM> sends a request <NUM> for the context of the transaction (step S816) and the core identity backend <NUM> transmits a message <NUM> ("a second challenge") via the second channel <NUM> (i.e. via the Internet) containing information <NUM> about the context of the transaction, such as the name of the service provider, the nature of the transaction (e.g. login, share id, approval, signature), time and date, information about on the transaction etc. (step S817). A standard template (such as CAP template for banking transactions) may be used.

The app <NUM> prompts the user to login on the terminal <NUM> on a first screen <NUM> (steps S818 & S819). If the user presses a continue button <NUM>, the app <NUM> presents a second screen <NUM> (a so-called "what-you-see-is-what-you-sign" or "WYSIWYS" screen) to the user which includes the information <NUM> about the context of the transaction, and options <NUM>, <NUM> to either accept or reject the transaction (step S820). If accepted (step S821), the app <NUM> presents a third screen <NUM> indicating that the transaction is being verified.

The app <NUM> then prompts the user to provide up to three (or more) types of authentication, such as PIN, OTP and biometric (steps S821 to S824).

The app <NUM> may prompt the user to enter their PIN <NUM> (step S821). For example, the app <NUM> may present a fourth screen <NUM> which includes a field <NUM> to enter the PIN <NUM> and a button <NUM> to continue. The app <NUM> presents a fifth screen <NUM> indicating that the transaction is being verified.

The app <NUM> may prompt the user for biometric input (step S823). For example, the app <NUM> may present a sixth screen <NUM> which includes a message <NUM> instructing the user, for example, to use fingerprint. The screen <NUM> may include an option to cancel <NUM>. The terminal <NUM> checks the biometric input.

The app <NUM> (in particular the Gemalto Ezio SDK) uses the PIN <NUM> to perform a one-way-encryption to generate a hash <NUM> (step S824). The app <NUM> (in particular the Gemalto Ezio SDK) checks the hash <NUM> (step S825). If correct, then app <NUM> (in particular the Gemalto Ezio SDK) generates an OTP <NUM> ("a second response") in the form of a TOTP based on a terminal fingerprint <NUM> and the received context <NUM> (step S826) and signs the payload <NUM> using OCRA using the key K1 (step S827). The OS-side terminal fingerprint <NUM> is generated by the Gemalto Ezio SDK.

The app <NUM> sends the payload <NUM> to the core identity backend <NUM> via the second channel <NUM> (step S328) where it is verified against the result of the same calculation carried out at the backend <NUM> (steps S829 & S830). In particular, the same calculation may be carried out by the HSM <NUM>.

If the results do not match, then the transaction is aborted. If the results match, then the core identity backend <NUM> sends a confirmation <NUM> to the service provider <NUM> (step S831) which presents an appropriate web page <NUM> (step S832) and a confirmation <NUM> to the app <NUM> which presents a screen <NUM> with a message <NUM> confirming that the transaction has been authorized.

It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of authentication, on-line banking and mobile communication terminals and component parts thereof and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.

The fingerprint scanning process on the OS-side of the terminal may be configurable and can be made more or less strict by activating additional or few OS parameters.

The service provider application, even if run in a browser, need not be does not need to be installed or run on terminal. It can be run on another different device, such as a personal computer IoT device.

The core identity backend may comprise one or more servers.

Claim 1:
An authentication system (<NUM>) configured, in an enrolment phase:
to exchange data with an application (<NUM>) running on a mobile terminal (<NUM>) via a second channel (<NUM>) so as to receive a first terminal fingerprint of the mobile terminal from the application via the second channel; and
to exchange data with a secure element (<NUM>) comprised in the mobile terminal via a first, different channel (<NUM>) so as to determine, via the first channel, a secure element identifier (<NUM>) and a hardware identifier (<NUM>) of the mobile terminal via the first channel;
and wherein the authentication system is further configured, in the enrolment phase:
in response to receiving, from a source (<NUM>), a request (<NUM>) to enrol a user comprising a user identifier (<NUM>) and an identifier of the mobile terminal (<NUM>, <NUM>), to transmit a first password to the source for presentation to the user and/or to the mobile terminal;
in response to receiving, from the application (<NUM>) running on the mobile terminal, a first key (K1), the first terminal fingerprint and a copy of the first password via the second channel (<NUM>), to link the user identifier, the identifier of the mobile terminal, the application and the mobile terminal, to transmit a random number (<NUM>) to the secure element (<NUM>) in the mobile terminal via the first channel (<NUM>);
to send a second key (K2) to the secure element (<NUM>) via the first channel;
in response to receiving, from the secure element (<NUM>) via the first channel, an encrypted message (<NUM>) comprising a second terminal fingerprint encrypted with the second key, wherein the second terminal fingerprint comprises the secure element identifier and the hardware identifier, to transmit a second password, to the secure element via the first channel; and
in response to receiving, from the application via the second channel, a copy of the second password and in dependence upon the copy of the second password matching the second password, to link the user identifier and the second terminal fingerprint or data included the second terminal fingerprint.