EP3867782A1

EP3867782A1 - Authentication system and method

Info

Publication number: EP3867782A1
Application number: EP19794229.5A
Authority: EP
Inventors: Milon VEASEY; Herve PARUIT
Original assignee: Moby4 Ltd
Current assignee: Moby4 Ltd
Priority date: 2018-10-19
Filing date: 2019-10-18
Publication date: 2021-08-25
Also published as: GB201817093D0; WO2020079451A1

Abstract

Methods, system and devices (10) for user authentication are disclosed. A user interaction test for discriminating between human and automated interaction may be performed. A code-input session for receiving a user input of a secret authentication code, such as a PIN, is initialised. A cryptographic function to generate an authentication request, the cryptographic function encrypting the user-inputted code is generated, and the authentication request is sent. An authentication response is received verifying the authenticity of the user on the basis of the authentication code.

Description

Authentication system and method

Field of the invention

The present invention relates to a system, device and method of electronic authentication. In particular, the present invention relates to an improved means by which user authentication data can be collected via a mobile electronic device, especially for the purpose of verifying the identity of a user.

Background to the invention

Existing user authentication and identity verification, for example for the purpose of KYC (Know Your Client) procedures can be relatively onerous, requiring a user to provide government-issued identity documents as proof of their identity. Such documents need to be scrutinised manually by those wishing to verify the identity of the user. Thus, there is a general desire in the art to automate authentication of identity. However, most existing solutions require bespoke technical arrangements that have inhibited their proliferation.

One possible way of automating identity authentication is via interaction with existing and highly-secured technology platforms, such as those employed in banking systems. These system are relatively widespread, and are generally up-to-date and trusted holders of user identity. Furthermore, they can provide mechanisms by which users and third parties can interact with those systems in a way that can signal whether a purported identity of a user is genuine. For example, use of a payment card and a PIN (Personal Identification Number) can provide relatively secure means by which a user can verify their identity to, for example, a merchant - and indeed provide payment for goods and services as is well- known.

Ultimately, in such a payment or identity authentication transaction, the PIN is assumed to be known only to the genuine user, and securely stored by a trusted authority (such as a banking card issuer). Naturally, the trusted authority also stores other personal identity information about a user, such as an address, a date of birth, name. Thus, a successful PIN validation and a successful transaction proves the identity of the user.

It is imperative that the PIN is kept a secret. The means by which a PIN is collected must therefore be secured to prevent interception by a malicious third party.

This is a significant a challenge where PIN input is via a personal electronic user device such a smart-phone, and especially when PIN input is provided via a virtual keypad displayed on a touch-sensitive display screen. Such user devices are not designed specifically and exclusively for the purpose of PIN entry, and are often able to download and execute a variety of different programs and applications ("apps"). Accordingly, a security flaw may be introduced to such a device via an app which allows a malicious third party to intercept PIN entry. For example, malicious code may be installed on the device without a user's knowledge.

Whilst a trusted program or app may in itself be encrypted and secured against direct observation or interference via such malicious code, there are other mechanisms by which a PIN may be determined indirectly. Devices such as smartphones incorporate a set of sensors that make these devices particularly prone to such an indirect attack.

For example, one malicious PIN interception method involves installing a data-logging routine that captures relatively unrefined data from the sensors resident on such a mobile device. Unrefined data captured from sensors such as an accelerometer or touch- sensitive component of a display screen can be used to subsequently reveal a likely sequence of coordinates pressed by a user on the display screen. Accordingly, where a virtual keypad has a familiar layout, for example, with "1 " positioned at the top-left region of a screen, and "9" positioned bottom-right, a PIN can be readily inferred from the raw sensor data.

It is possible to address this issue by randomly scrambling the position of keys on a virtual keyboard. However, this presents a user with a highly unfamiliar key layout, and so significantly reduces convenience and the speed at which a user is able to enter their PIN. Scrambling the key layout may also lead to incorrect PIN entry which can be highly inconvenient.

Another vulnerability relates to man-in-the-middle (MITM) attacks. A malicious third party, acting between a PIN entry component of the user device and the trusted authority may secretly relay and alter communication between these two parties.

It is against this background that the present invention has been conceived.

Summary of the invention

According to a first aspect of the present invention there is provided a user authentication method for verifying the identity of a user, the method comprising at least one of the steps of:

performing a user interaction test for discriminating between human and automated interaction; initialising a code-input session for receiving a user input of a secret authentication code;

applying a cryptographic function to generate an authentication request, the cryptographic function encrypting the user-inputted code;

sending the authentication request; and

receiving an authentication response verifying the authenticity of the user on the basis of the authentication code.

Preferably, the authentication request is sent to, and/or the authentication response is received from a trusted authority. Naturally, other user information may be contained within the authentication request. For example, other user information may include personal identity data that can be matched, together with the code, with data held by trusted authority. Accordingly, the identity of a user can be verified.

Preferably, the code-input session comprises at least one of the steps of:

o displaying a virtual code-input mechanism having input interface elements each

representing a character of a code to be inputted;

o positioning each input interface element at an absolute position that changes for each code-input session;

o maintaining each input interface element at a predetermined position relative to the other displayed input interface elements; and

o permitting user interaction with a sequence of the input interface elements to specify a corresponding sequence of characters, thereby receiving from the user input of their secret authentication code.

Preferably, the step of displaying the virtual code-input mechanism, positioning input interface elements of the code-input mechanism, and/or permitting user interaction with a sequence of the input interface elements are carried out on or via a touch-sensitive display screen of an electronic user input device. Ideally, the input device is a mobile device, such as a mobile telecommunications device.

Advantageously, positioning input interface element on a screen at an absolute position that changes for each code-input session minimises the chance that the code can be inferred indirectly from the input device.

Preferably, the input interface elements display a unique character of the code to be inputted. Preferably, the code to be inputted is a PIN (Personal Identification Number). Accordingly, there may be ten input interface elements, each representing one numerical character from 0 to 9, of a PIN code to be inputted.

Preferably, the code-input session further comprises displaying, ideally on the screen of the device, movement in the absolute position of each input interface element prior to the step of permitting user interaction with those input interface elements to specify the user input code.

Advantageously, this provides a user with an intuitive way to understand where each input interface element is finally located prior to code entry. Displaying movement firstly signals to the user that the input interface elements positions are being randomised (as so to be mindful of code entry), and secondly provides feedback about how the input interface element positions have changed.

Preferably, movement of each input interface element comprises translational movement, ideally along a path. Preferably, the translational movement is along a common path, common to all user interface elements. Preferably, the path is an endless path, such as a circular path.

Preferably, movement in the absolute position of each input interface element occurs for a movement period, the length of the period being randomised over multiple code-input sessions.

Preferably, the speed of movement of the input interface elements is randomised over multiple code-input sessions.

Preferably, the relative position between input interface elements is maintained so that the same predetermined input interface elements are positioned adjacent to one another over multiple code-input sessions.

Preferably, the code-input session comprises displaying, at each user input element, a respective numerical character of a code to be inputted, the relative position between input interface elements being maintained so that input interface elements that represent numerically adjacent characters are positioned adjacent to one another over multiple code-input sessions. For example, it is preferred that a user input element representative of the numeral "1 " is adjacent to that representative of the numeral "2", and that in turn is adjacent to the input interface element representative of the numeral "3", and so forth.

Preferably, the code-input session comprises displaying, at each user input element, a respective character of a code to be inputted, the displayed characters conforming to a predetermined orientation. Moreover, the predetermined orientation is ideally with reference to the orientation of the screen of the user input device.

Preferably, the predetermined orientation of the displayed characters is maintained over multiple code-input sessions, and irrespective of the absolute position and/or movement of the displayed characters.

Preferably, the electronic user input device comprises an orientation detector for detecting the orientation of the device. Thus, the orientation to which the displayed characters conform may be predetermined with reference to an orientation signal from the orientation detector.

Preferably, the code-input mechanism comprises a target region, and user interaction with each input interface element to specify a respective character of the secret authentication code comprises registering a drag interaction that follows a path starting at that input interface element, and ending at the target region. Preferably, the drag interaction is a drag-touch interaction as registered by the screen of the user input device.

Preferably, the input interface element moves along the path during the drag-touch interaction, the position over time of the input interface element coinciding with the position of touch.

Preferably, the target region comprises a perimeter within which the path of the drag- touch interaction must end to specify a respective character of the secret authentication code.

Advantageously, a drag interaction - especially a drag-touch interaction - is superior to traditional "tap" or "click" interactions to specify a user code via input interface elements. Firstly, due to the variable nature of the path traced by a user, such a drag interaction is far less susceptible to malicious attack via sensor inference. Secondly, such a drag interaction is less likely to cause inadvertent code entry. In particular, a user is less likely to accidentally perform a drag interaction with a touch-sensitive display screen as compared with a simple "tap" interaction.

Preferably, the user interaction test checks for human interaction via the touch-sensitive display screen of the electronic user input device. Moreover, the user interaction test is ideally configured to discriminate between human and automated interaction. Ideally, failure of the user interaction test is a determination of automated interaction, and a pass of the user interaction test is a determination of human interaction. Preferably, the user interaction test comprises at least one of:

o assigning to each of a plurality of images a predetermined category;

o registering one of those categories to be selected by a user in order to pass the user interaction test;

o displaying the plurality of images on the screen of the electronic user input device; o issuing a prompt, via the electronic user input device, to select one of the displayed images, the prompt notifying the user of the registered category;

o receiving a user selection of at least one of those images; and

o determining a pass of the user interaction test if the user-selected image is assigned to the registered category.

Moreover, the user interaction test may comprises at least one of:

o displaying, on the touch-sensitive display screen of the electronic user input device, a first set of images, each image being preassigned to a category unique within the first set;

o registering, via the touch-sensitive display screen of the electronic user input device, a user selection of one of the first set of images;

o displaying, on the touch-sensitive display screen of the electronic user input device, a second, different set of images, one of which is preassigned to a category matching the unique category to which the user-selected image is preassigned;

o registering, via the touch-sensitive display screen of the electronic user input device, a user selection of one of the second set of images; and

o determining a pass of the user interaction test if the user-selected images from the first and second set are preassigned to a common category.

Failure of the user authentication test may prevent carrying out of at least one subsequent method step. Repeated failure (for example, after a predetermined number of failures) of the user authentication test may prevent carrying out of any of the method steps. In other words, "lock-out" after X attempts. This can prevent brute-force attack.

Preferably, the user interaction test is carried out prior to initialising the code-input session. However, in principle, the test may be carried out at any time prior to sending an authentication response. Moreover, it is preferred that the authentication response is sent only if the user interaction test has been performed, and ideally passed. However, a negative authentication response may be sent if the user interaction test has been performed and failed.

Further aspects of the present invention may reside in a device and/or a system for carrying out the method of the first aspect. Accordingly, a second aspect of the invention may reside in a computer-implemented user authentication system, the system comprising at least one of:

an electronic user input device;

an identity verification server;

a trusted authority;

a network; and

a querying party.

Preferably, the system comprises an electronic user input device in the form of a mobile device having a touch-sensitive display screen. Preferably, the mobile device further comprises a communication module such as a wireless communication module.

Moreover, the mobile device is ideally operable to download an application via the wireless communication module, and execute the application, the executed application controlling the mobile device to:

perform a user interaction test for discriminating between human and automated interaction;

initialise a code-input session for receiving a user input of a secret authentication code, such as a PIN;

apply a cryptographic function to generate an authentication request, the cryptographic function encrypting the user-inputted secret authentication code; send the authentication request (e.g. to a trusted authority); and/or receive (e.g. from the trusted authority) an authentication response verifying the authenticity of the user on the basis of the secret authentication code.

Naturally, the code-input session initialised by the mobile device may include the features and advantages as discussed above, in relation to the first aspect of the present invention. In particular, the code-input session may comprise at least one of:

displaying, on the touch-sensitive display screen of the mobile device, a virtual code-input mechanism having input interface elements each representing a character of a code to be inputted;

positioning each input interface element on the display screen of the mobile device at an absolute position that changes for each code-input session, but maintains a predetermined position relative to the other displayed input interface elements; and

permitting user interaction, via the display screen, with a sequence of the input interface elements to specify a corresponding sequence of characters, thereby receiving from the user input of their secret authentication code.

The system may comprise a plurality of user input devices. The identity verification server of the system may be configured to participate in a user interaction test with the or each of those electronic user input devices. Ideally, the identity verification server of the system is configured to validate (e.g. in conjunction with a trusted authority) secret authentication codes received from the or each electronic user input device determined to have been user operated to pass the user interaction test.

Preferably, the identity verification server is configured to participate in a user interaction test with the or each of those electronic user input devices by:

transmitting, to the or each electronic user input device, the plurality of images assigned to a predetermined category;

registering, for the or each device, one of those categories to be selected by a user in order to pass the user interaction test;

receiving, from the or each respective device, a user selection of at least one of those images; and

determining a pass of the user interaction test in respect of the or each of those devices where the user-selected image is assigned to the category registered against that device.

Preferably, the or each electronic user input device is configured to:

generate a Public-Private key pair (Kpr, Kpu), the public key being made available to an identity verification server of the system; and

receive a symmetric encryption key from the identity verification server, the symmetric encryption key being encrypted by the identity verification server using said public key, and decrypted by the electronic user input device using its respective private key. Preferably, the cryptographic function comprises encrypting the user-inputted secret authentication code using the symmetric encryption key.

Preferably, encryption key exchange between an electronic user input device and an identity verification server of the system occurs simultaneously, at least in part, with a user interaction test.

It will be understood that features and advantages of different aspects of the present invention may be combined or substituted with one another where context allows.

For example, the features of the method described in relation to the first aspect of the present invention may be provided as part of the system (or parts thereof) described in relation to the second aspect of the present invention. Furthermore, such features may themselves constitute further aspects of the present invention. By way of example, a further aspect may reside in a user interaction test for discriminating between human and automated interaction.

By way of additional example, the features of the code-input session or code-input mechanism may themselves constitute further aspects of the present invention, independent to the general authentication method. For example, a further aspect of the present invention may reside in methods and/or system for receiving from a user, a secret authentication code. Such further aspects may comprise displaying a virtual code-input mechanism having input interface elements each representing a character of a code to be inputted, positioning each input interface element on the screen at an absolute position that changes for each code-input session but maintains a predetermined position relative to the other displayed input interface elements, and permitting user interaction with a sequence of the input interface elements to specify a corresponding sequence of characters, thereby receiving from the user input of their secret authentication code.

Brief description of the drawings

In order for the invention to be more readily understood, embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is schematic overview of a system according to a first embodiment of the present invention;

Figure 2 is a schematic block diagram of a mobile device of the system of Figure 1 ;

Figures 3 to 11 , 14 and 15 show pages of a graphical user interface (Ul) as displayed on a screen of the mobile device of Figure 2, the Ul being generated by an application executed by the mobile device;

Figures 12 and 13 each show in isolation a PIN input mechanism of the Ul of Figure 11 ; and

Figure 16 is a flow diagram of information exchange between a mobile device and an identity verification server of the system of Figure 1.

Specific description of the preferred embodiments

Figure 1 is a schematic overview of a system 1 of an embodiment of the present invention. The system 1 comprises an identity verification server 2, an application hosting platform 2a, a trusted authority 3, a querying party 4, and a mobile user input device 10 each communicatively interlinked to one another via a communications network 5. The mobile device 10 is in the form of a smartphone having a touch-sensitive display screen 11 on which can be displayed interface elements, and via which a user can interact with those interface elements. It will be understood that, in practice, the system 1 will have a plurality components of the same type. For example, there could be many mobile devices, possibly numbering in the thousands or millions, or more. However, for clarity, a single system component type (e g. mobile device 10) is depicted in Figure 1 , and representative of each of the potentially multiple components of that type.

Figure 2 is a schematic block diagram of the mobile device 10 of Figure 1. The mobile device 10 further comprises a wireless communication module 12 for interfacing with the network 5, a processing module 13, and a memory module 14. The mobile device 10 also comprises a sensor set 17, a camera 18 and an NFC (Near-Field Communication) module 19. In the present embodiment, the mobile device also comprises a Trusted Execution Environment (TEE) module 13a within the processing module 13 which guarantees the security, integrity and confidentiality of the data handled by the processing module 13.

The memory module 14 comprises a transient memory 15 such as a cache, for transiently storing data, and a persistent memory 16 within which an operating system, file system and applications of the mobile device 10 are stored and executed via the processing module 13 at run-time.

The mobile device 10 further comprises other components that are typically common in smart-phone and tablet devices, but are not necessarily shown in the drawings. By way of non-limiting example, these other components include: a compass, an orientation detector, an accelerometer, a battery, a timer, audio transducers, tactile transducers (e.g. vibration transducer), a clock, and a GPS positioning device. The components of the mobile device 10 are functionally and communicatively linked to one another as schematically indicated by the dotted lines in Figure 2. The mobile device 10 may also comprise additional communication modules (e.g. BLE/Bluetooth, cellular etc), to allow communication with other components or sub-components of the system 1.

The identity verification server 2 is configured to make an application (or "app") available for download on to the mobile device. The app provides the functionality of the enhanced method of user authentication, as will be described in greater detail below. The provision of the app is ideally via the network 5 from a third-party application hosting platform 2a, for example, an Android or iOS "app store" as is well-known in the art. In this case, the identity verification server 2 may provide a hyperlink or similar to guide the mobile device to the location of the appropriate application hosted by the app hosting platform 2a. In alternatives, the querying party 4 may provide a copy or version of the app.

Furthermore, the app of the present embodiment may be embedded within, or called specifically from another 3^rd party application, or via a hyperlink, optionally provided by the querying party 4. Thus 3^rd party mobile applications can make use of the functionality provided by the app, as will be described, to verify the identity of a user.

The app 9, when run or managed by the mobile device 10, in conjunction with the hosting platform 2a, is configured to automatically detect when the application requires updating, and either auto-update, or prompt a user to affirm that an update should take place.

The identity verification server 2 also is arranged to enter into communication with user mobile devices 10 to prompt updating of the app, set up a user account, exchange information relating to an identity verification transaction, and also act as an intermediary between the user mobile devices and the trusted authority 3. It should be noted that in various embodiment the identity verification server 2 may perform at least part of the function of the trusted authority 3 (and vice-versa) but, in the present embodiment these two identities are represented individually in the interests of clarity.

Moreover, the identity verification sever 2 may act as a gateway to multiple trusted authorities, each with different data sets ad functions relating to the authentication of user. Nonetheless, the trusted authority 3 exemplified in Figure 1 is embodied by systems of a banking authority 3 which has conducted a rigorous check of the identity of a user and has securely issued to that user a payment card 8 and a PIN (Personal Identity Number) known only to that user and the banking authority 3. A credit or banking account may be opened in the name of the user by the banking authority 3, and standard use by the user of the payment card 8 in conjunction with the PIN can provide a way for that user to authorise payment from that account for goods or services. The payment card 8 is of a "Chip-and-PIN" type meaning that a secure processing element 80 - the "chip" 80 - is supported on the card 8. Payment terminals interfacing with the chip 80 of the card 8 allow a user to provide an offline PIN which is validated by the chip 80, or an online PIN which is validated by the banking card issuer and used to generate a validation code upon provision of a correct PIN, that validation code being used to confirm overall

success/failure of a payment transaction.

In alternatives, the payment card 8 may not necessarily be provided with a secure processing element 80, but may be provided with another machine-readable component (e.g. a magnetic strip) which can allow an online PIN-based payment transaction to occur.

In addition to conducting standard payment transactions, the banking authority can verify the identity of the user. As will be described in further detail below, this can be achieved by using user information that has been generated, collected or otherwise in the possession of the banking authority, at least one component of which is secret information such as a PIN associated with the payment card. This is used in conjunction with other user information that relates to the identity of the user. For example, such user information may be information that is unhidden - such as that borne on the payment card. Such unhidden is generally physically borne on the front of the payment card.

User information may include a payment card number 81 , payment card validity dates 82, and a name of the user 83. Other user-specific information (e.g. stored on the chip 80 or held by the trusted authority 3) may include, but is not limited to, a postal address, email address and telephone number.

In the present embodiment, the querying party 4 includes the systems of a third party that wishes to query the identity of the user from the trusted authority 3. For example, this may be necessary as part of a customer or consumer registration process, or KYC (Know Your Customer) procedures necessary to prevent fraudulent transactions between the querying party and unknown users. For example, the querying party 4 may be associated with a provider of legal or financial services - for example a solicitor or insurance provider - and before entering into a contract for service with a customer or client, the identity of the that client must be verified.

To do this, the querying party 4 can request a user of the mobile device 10 to download and interact with the app through which the identity of that user can be independently verified via the identity verification server 2 and trusted authority 3.

An overview of an exemplary user identity verification process is shown in Figure 1. The steps of this identify verification process generally involve communication between members of the system 1 , and are represented by double-headed dashed-line arrows 1a to 1 g.

Step 1a involves conferring the mobile device 10 with access to the app 9. In the present example, this is prompted by the querying party 4.

As part of this first step, there is communication between the mobile device 10 and the querying party 4. In this example, the querying party 10 wishes to have the identity of the user of the mobile independently verified, and so sends a hyperlink to the mobile device. As mentioned, the hyperlink may point to an electronic resource located via a third-party hosting platform. However, in the present example, the app is located at the system of the querying party 4, the app being modified to be proprietary to the querying party 4 - for example, bearing the branding of the querying party 4, and providing additional functionality appropriate for the performance of the service to be provided by the querying party to the user of the mobile device 10.

User selection of the hyperlink causes the mobile device 10 to access the relevant resource hosted by the querying party 4, and download the app 9 for subsequent execution.

Step 1 b involves the mobile device 10 acquiring and executing the app 9. In the present example, the app 9 is at least partially executed within the TEE module 13a. During this step, the app is configured to receive user input to collect user information so as to set up an account with the identity verification server 2.

In Step 1c the mobile device 10 establishes secure communication with the identity verification server 2. Moreover, the mobile device 10 is configured by the app 9 to acquire further user information, including a secret authentication code such as a PIN, to be used in the verification of the identity of the user. The mobile device 10 is configured by the app to transfer to the identity verification server 2 an encrypted package including the user information that has been provided by the user (including the PIN). It should be noted that some parts of Step 1 b and 1c may occur concurrently, or in a different order as stated.

In Step 1d the encrypted package is processed by the identity verification server 2 - for example decrypting it, and then re-encrypting it as part of the separate and secure communication between the identity verification server 2 and the trusted authority 3.

Thus, a second encrypted package is sent from the identity verification server 2 to the trusted authority 3, the second encrypted package containing the secret authentication code, together with additional user information. Various other transactional parameters may also pass between the trusted authority 3 and the identity verification server 2.

In Step 1e the trusted authority 3 receives and decrypts the second encrypted package, and determines whether the secret authentication code is correct (when cross-referenced with the additional user information), and in response sends a positive or negative confirmation message back to the identity verification server 2 that confirms respectively whether or not the secret authentication code paired together with the additional user information matches that which is held by the trusted authority 3.

In Step 1f receipt of a positive verification message from the trusted authority 3 by the identity verification server 2 is deemed to be representative of the verified identity of the user. This verification can be transmitted by the identity verification server 2 back to the mobile device 10, for example for the purpose of unlocking otherwise restricted functionality resident in the app 9. In Step 1g the verified identity of the user is transmitted to the querying party 4 thereby providing independent verification of the identity of the user of the mobile device 10 to the querying party 4. To this end, a token may be provided by the identity verification server 2 to the mobile device 10 to pass on to the querying party 4. Alternatively, during a transaction between the mobile device 10 and the identity verification server 2, the mobile device 10 may provide to the identity verification server 2 an electronic address of the querying party 4 (e.g. an IP address, URL, email, etc). This allows the identity verification server 2 to communicate directly with the querying party 4 following the outcome of a determination of the identity of the user of the mobile device 10.

All communication between the different members of the system 1 are shown

schematically in Figure 1 to be via the network 5, but it will be appreciated that the network 5 may have different parts and functions. In particular, secure communication between the identity verification server 2 and the trusted authority 3 is preferably via a separate secure communication channel within the network, with at least one layer (e.g. physical layer, data-link layer etc.) being unconnected with the part of the network used for communication between other components of the system 1 .

A more detailed account of Steps 1 b and 1 c in particular are shown with reference to Figures 3 to 15 which are screenshots of pages of (or parts of) a graphical user interface (Ul) as generated by the app 9 for display on the screen 11 of the mobile device 10 running the app 9.

As the screen 11 is a touch-sensitive electronic screen 11 , it is able to receive a user touch input, such as a drag interaction for example, to manipulate and select certain Ul elements. For the avoidance of doubt, a simple touch input such as a tap interaction involves a user tapping a region of a screen, typically to select an underlying displayed user interface element such as a button. By contrast, a drag interaction involves a user maintaining contact with the screen 11 whilst tracing path on it. "Drag and drop" involves releasing that contact at the end of the path.

Figure 3 shows an initial page of the Ul presenting three user-selectable options or "buttons". These are represented by three regions occupied by the text: "New user?", "Sign-in" and "Clear data", and each can be selected via a tap interaction.

Selecting the latter option clears from the persistent and transient memory 15, 16 any previously entered user data. Selecting the "Sign-in" option relies on a user having previously entered their user data, and set up an account with the identity verification server 2, for example via previously selecting the "New user?" option. Selecting the "New user?" option leads to a set of pages represented by Figures 4 to 6 of the Ul within which a user is guided to enter their details into the appropriate fields of the Ul. As is well-known in the art, these fields can be populated by selecting the region occupied by those fields, and then entering characters using a virtual keyboard (not shown).

As can be seen in these drawings, the details collected relate to user information such as: first name, last name, date of birth, nationality, phone number, postal address, email address, password, security question, security answer and account currency. Any one or a combination of these features may be used for the purposes of identity verification. However, these details are primarily for the purpose of setting up an account with the identity verification server 2.

The account holds the user information for the convenience of the user so that in subsequent use of the app, it is not necessary to re-enter most of the user information again. Assuming a user has already provided their details and set up an account, selecting the "Sign in" option from the initial page simply further requires the provision by the user of the user's email (as a username) and password to log into an account already established at the identity verification server 2.

More sensitive information may also be collected, in particular relating to the unhidden data borne and visually presented by the payment card 8, such as the payment card number 81 , payment card validity dates 82 and name 83.

Referring to Figure 8a, for ease of entering these details, the camera 18 may be enabled by the app 9 to capture a temporary image of the payment card 8 and subject that image to optical character recognition to extract the visually recognisable data on the payment card 8. Character position analysis can be used to determine which fields that data represents. For example, a centrally-located row of fourteen to sixteen numerals is indicative of a the payment card number 81.

Furthermore, a user may be prompted to enter other data - for example, that on the reverse of the payment card 8, such as a card verification code (CVC). Additional data may also be collected from the payment card 8 via the NFC (near field communication) module 19 of the mobile device 10 - assuming the payment card supports NFC communication.

Naturally, communication of such user information from the mobile device 10 to the identity verification server 2, is carried out via a secure communication means, even though the user information being communicated may not necessarily be as sensitive as a user's payment card PIN.

A PIN is presumed to be sensitive information that demands a particularly robust and secure exchange between the mobile device 10 and the identity verification server 2. This is because an encrypted representation of the PIN associated with the payment card 8 is passed from the mobile device 10 to the identity verification server 2, and this provides a highly reliable means by which the identity of the user of the mobile device 10 can be independently verified. Accordingly, a exceptionally secure exchange is needed to protect the secrecy of the PIN.

Figures 8 to 15 depict that which is presented by the Ul of the app 9 to a user of the mobile device 10 during such a secure exchange.

A first stage of the secure exchange between the mobile device 10 and the identity verification server 2 relates to securing the mobile device 10 (see Figure 8). This may include disabling any non-essential and concurrently-running processes on the mobile device 10 - for example, other applications which may otherwise gain access to the data handled by the app of the present embodiment, and even sensors which may be maliciously exploited to infer sensitive data. Alternatively, securing the mobile device 10 may simply be achieved by running the app (or part thereof) within the TEE which isolates sensitive data from other components of the mobile device 10. (It should also be noted that the collection of sensitive data, such as that relating to Figure 8a, may be collected after securing the mobile device 10).

A second stage comprises a combined image and key exchange process between the mobile device 10 and the identity verification server 2. This not only ensures the security of the data passing between the mobile device 10 and identity verification server 2, but also improves the security of the system 1 as a whole, making it more difficult for a malicious third party to flood the system 1 with multiple automated PIN guesses. In particular, a user interaction test is employed for discriminating between human and automated operation (e.g. uses of the app and/or requests directed at the identity verification server). Automated operation can be indicative of a malicious attack, and so the user interaction test can be used to indicate and secure against this.

From the perspective of the user, and as shown in Figure 9, a first set of nine images are obtained from the identity verification server 2 and presented via the Ul of the app 9 to the user for selection. The app 9 is arranged to receive via the screen 1 1 a user touch input to select one of the nine images. Information relating to the selected image is sent back to the identity verification server 2. Thereafter, as shown in Figure 10, a second set of nine images are obtained from the identity verification server 2, and presented via the III of the app 9 to the user for selection. The user is guided upon presentation of the second set of images to select an image that shows the same object as that in the previous selection. Again, the app 9 is arranged to receive a further user touch input to select one of the second set of nine images, and information relating to the selected image from the second set is sent to the identity verification server 2. Advantageously, selection of the same image type twice also ensures that the control of user input to the app 9 has not been hijacked by a malicious actor between each image selection process.

Each image of every set that is transmitted from the identity verification server 2, and displayed via the Ul of the app belongs to a specific category. In the present example, these categories relate to an object that a user viewing the image can see (e.g. from Figure 9 in order: a car, boat, cat, fish, ball, face, dog, flower and aeroplane). As can be seen in Figure 9, images within the same set belong to a different categories. However, an image in one set generally belongs to the same category as a corresponding image in a different set. i.e. the second set shown in Figure 10 also show images each belonging to one of the categories: car, boat, cat, fish, ball, face, dog, flower and aeroplane.

However, these images are not shown in the same category order.

It should be noted that different image categories aren't necessarily restricted to objects, and, in other embodiments, may extend to subjects (e.g. sport, science, weather etc.), actions (e.g. jumping, diving, etc.), or more generally to concepts (e.g. high, hot, sleepy, etc.). Furthermore, images may notionally belong to multiple categories. This can represent a challenge to the preferred requirement that there is an unambiguous 1 : 1 mapping between the images of the first set and the images of the second set.

For example, if one of the images from the first set is of a jumping animal, and if one of the images from the second set is of a sitting animal, and another image of the second set is a jumping person, this introduces an ambiguity about which of those two images from the second set is a correct match for the image of the first set.

To overcome this challenge, it is preferable to employ an image-choosing process to ensure that there is an unambiguous relationship between an image chosen from the first set, and a corresponding image from the second set. In particular, if the image chosen from the first set belongs to multiple categories, the process ensures that only one of the images from the second set can belong to a matching category. To this end, an image database is maintained, the image database referencing each image with multiple tags, each tag representing a category. The image categories that are chosen are those which are relatively straightforward for a human to recognise and distinguish between, but are relatively difficult for an automated system to recognise. Accordingly, this part of the process ensures that it is difficult for a malicious third party to automate an attack on the system 1 - e.g. via a rapid PIN guessing routine. To further minimise the likelihood of automating such a PIN guessing routine, the identity verification server 2 may limit the period allowed for a user to select a first and/or second image from the two sets presented. These measures improve the security of the system 1 as a whole.

Assuming successful selection by the user of two images of the same category, the app 9 is arranged to initialise a code-input session for receiving a user input of the PIN associated with the payment card 8.

In other embodiments, different user interaction tests may be used. However, there is a particular advantage associated with user interaction tests that use categorised images, in that they are known to be particularly resistant to automated attacks. Generalising the above-described user interaction test, embodiments may involve assigning to each of a plurality of images a predetermined category, and then registering one of those categories as that which needs to be selected by a user in order to pass the user interaction test. Naturally, in alternatives, a different number of images may be used.

In the specific example provided above, the registration of the category to be selected is triggered by the selection of one of the first set of images - i.e. the category associated with that selected image is the registered category which must be selected again by the user via the second set of images in order to pass the user interaction test. For example, the selection of an image of a dog from the first set of images registers the category as "dog". Thus, to pass the test, the user is prompted to select an image of a dog from the second category. However, an alternative user interaction test may simply be to prompt a user to select the (or every) image displayed that shows a dog. Alternatively, the user may be prompted to select every image that "shows the same animal". In such a case, selection of multiple images may be necessary to conduct the user interaction test.

In any case, the test involves registering a category that needs to be selected by a user in order to pass the user interaction test, and then determining whether the user interaction test has been passed if the user-selected image is assigned to that registered category.

To maximise the security of the system, registration of the category, and then determining a pass of the test is carried out extrinsically to the app 9 and mobile device 10, and specifically at the identity verification server 2. In any case, a pass of the user interaction test leads to the app 9 initialising a code-input session.

Figure 11 shows a PIN input page as displayed via the Ul of the app 9 during such a code-input session. The Ul displays on the screen 1 1 a virtual PIN input mechanism 30 having ten input interface elements 40-49, each bearing one of each numeral from 0 to 9, from which a PIN can be composed. The PIN input mechanism 30 further comprises a bucket element 31.

The bucket element 31 , and each of the input interface elements 40-49 comprise a circular component. The circular component of the bucket element 31 has a larger perimeter than that of the interface elements 40-49. The bucket element 31 is centrally- located relative to the input interface elements 40-49 which are distributed around the bucket element 31 broadly following a circular path to match the outer perimeter of the circular component of the bucket element 31. Adjacent input interface elements are spaced equally from one another in a regular arrangement.

The bucket element 31 is configured as a target region to which input interface elements 40-49 can be sequentially dragged to allow a user to specify a sequence of numbers corresponding to a PIN.

However, to counteract the above-described malicious PIN interception method, prior to accepting a user interaction to specify their PIN, the absolute position of the interface elements 40-49 is altered by the app for each code-input session. Note that "absolute position" here can be also defined as position relative to a boundary defined by the screen and/or to the position of the central "bucket".

This is achieved by the app being configured to move the interface elements 40-49 along a path encircling the bucket element 31 , with the final absolute position of the interface elements 40-49 being effectively randomised.

This can be achieved in a number of different ways. In one example, the starting position, prior to movement, of the interface elements 40-49 may be predetermined by the app.

The final position however can be effectively randomised by varying the distance the interface elements are moved. In another example, the starting position is randomised also. Furthermore, the speed at which the interface elements move, and/or the time they take to reach their final position may also be randomised.

However, an important advantage is retained by PIN input mechanism, in that the position of the of the interface elements 40-49 relative to one another is not changed, and so this improves a user's familiarity with the input layout without being detrimental to security. Thus a user is able to enter their PIN relatively quickly and without mistake.

A further cognitive aid to a user operating the PIN input mechanism 30 is provided by positioning the input interface elements so that the values of the numerals that they bear are arranged in order (i.e. with 0 adjacent to 1 , 1 adjacent to 2, etc). Thus, input interface elements that represent numerically adjacent characters are positioned adjacent to one another over multiple code-input sessions.

Referring to Figures 12 and 13, the PIN input mechanism 30 of Figure 11 is shown in isolation with each drawing showing the PIN input mechanism 30 in two further configurations in which the interface elements 40-49 are at different absolute positions.

This is achieved by the app controlling the interface elements 40-49 to move along a path encircling the bucket element 31 , with the absolute final position of the interface elements 40-49 being effectively randomised. It should be noted that whilst the input interface elements 40-49 may appear notionally to "rotate" around the bucket element 31 of the PIN entry mechanism 30, the movement in the present embodiment is a translational movement. Importantly, the orientation of the numerals borne by the interface elements 40-49 is maintained - i.e. upright so as to facilitate reading of those numeral by a user.

To this end, if the device comprises an orientation detector, input from this can be used to maintain a convenient orientation of the numerals (and the Ul in general). However, the orientation detector may be disabled prior to PIN input.

After a period of random positioning of the interface elements 40-49, the app is configured to permit user interaction with the PIN input mechanism 30 so as to specify a sequence of numbers corresponding to the PIN of a user's payment card. As shown, a prompt in the form of a written instruction 50 is provided to the user on the PIN input page of Figure 11 to " Drag and drop your PIN digits to the bucket' at the same time as displaying the PIN input mechanism 30.

To input each PIN digit, a user makes contact with the screen at the location of a corresponding input interface element 40-49, traces a path to "drag" the input interface element within the perimeter of the circular component of the bucket element 31 , and then releases contact with the screen to "drop" it into the bucket element 31.

Thus, the app is configured to register a drag touch interaction with each input interface element 40-49. If the drag touch interaction follows a path beginning at an input interface element 40-49, and ending at the bucket element 31 , then the app is configured to append the numeral associated with that input interface element 40-49 to the PIN sequence. This "drag-and-drop" method of PIN digit selection is particularly advantageous compared, for example, to simple keypad touch selection. It prevents accidental digit selection, and also provides increased resilience against malicious PIN inference, for example via detection of response from sensors such as the accelerometer in the event that they cannot be disabled.

Referring back to Figure 11 , the user is provided feedback about the generation and length of the PIN sequence via a PIN entry indicator 51 which indicates when digits are entered using the PIN entry mechanism 30. The PIN entry indicator 51 is configured to alter the appearance of indicia in response to each PIN digit entry so that the user is provided feedback about how many digits have been entered (or remain to be entered). A spot is displayed over each one of a row of four indicators zones, with the number of spots displayed corresponding to the number of PIN digits entered.

It should be noted that, in alternatives, the PIN entry indicator may be adapted to accommodate for PINs or code of different lengths. For example, a different number of spots and indicator zones may be displayed and updated.

Also presented on this page of the III, is three user-selectable options, as represented by three regions occupied by the text: "Cancel", "Enter" and "Clear". These are configured to receive a user touch input to respectively cancel the PIN entry process, submit an entered PIN sequence, or clear the PIN sequence (for example, as a result of inadvertent entry, allowing re-entry).

Submission of an entered PIN sequence initiates step 1 c as mentioned above, during which the app causes the mobile device 10 to establish a secure communication with identity verification server 2, and transfers to it the encrypted package that includes the entered PIN sequence together with other user information.

During this process, a further processing transaction page of the Ul is displayed to the user as shown in Figure 14. This provides processing status feedback to the user via a rotating circular arrangement of arrowheads. This signals to a user to wait for the further transaction verification steps (e.g. steps 1 d, 1 e and 1f) to complete, and the non-static nature of this provides reassurance that the mobile device 10 is still operating as intended as hasn't suffered a processing error, or crashed.

Assuming successful completion of step 1f to independently verify the identity of the user, a further success verification page of the Ul is displayed to the user as shown in Figure 15. Additional functionality may thereafter be provided - for example, granting a user access to a service that was previously disabled. Referring to Figure 16, a flow diagram of one example of a detailed information exchange via the network 5 between the mobile device 10 and the identity verification server 2 is shown. This relates primarily to Steps 1 c to 1 e as discussed above.

A first stage of this information exchange relates to account set up. The app 9 is configured to receive user input to gather user information as discussed above, and then the app 9 is configured to transmit a selection of that user information to the identity verification server 2 to create a user account on the identity verification server 2.

Alternatively, if a user has already created an account, then the request sent to the identity verification server 2 can simply be in the form of typical login credentials (i.e. username and password).

In response to receiving a request to create or log into an account, the identity verification server 2 checks its database to verify that the request is valid - for example checking the credentials provided from the mobile device 5. If the request is valid, the identity verification server 2 sends a response to the mobile device 10 that includes a GUID (Global Unique Identifier). The GUID is used to identify communication that occurs specifically between the identity verification server 2 and the mobile device 10, and distinguishing it from other communications and transactions that may occur between the identity verification server 2 and other mobile devices, especially as many of these may be occurring concurrently.

The app 9 configures the mobile device 10 to react to the response containing the GUID from the identity verification server 2 by generating a further user-specific GUID (U.GUID) which may be a derivation of the GUID received from the identity verification server 2. For example, the U.GUID may be the output of an information processing function taking the GUID as an input. This may be as simple as appending additional characters to the GUID. Alternatively, the U.GUID may be generated from the GUID via a cryptographic process.

In any case, the U.GUID is formulated in a way that allows verification that the U.GUID has been derived or generated from the GUID, thereby evidencing it originated from the mobile device 10. This promotes the reliability of the communication link between the identity verification server 2 and the mobile device 10, especially if a cryptographic process is used for the derivation.

Thus, the app 9 configures the mobile device 10 to transmit the U.GUID back to the identity verification server 2. The identity verification server 2 checks that the U.GUID is authorised, and if so, generates a transaction GUID (T.GUID). Again, this may be generated as a derivation of the received U.GUID, and again, this may be achieved by applying a cryptographic function using the U.GUID as an input, and yielding the T.GUID as an output.

Furthermore, nine image GUIDs (I. GUID 1..9) are generated by the identity verification server 2, with each I. GUID uniquely identifying an image of a first set of nine images. The first set of nine I. GUIDs form a first I. GUID List which is sent together with the T.GUID back to the mobile device 10.

It should be noted that the I. GUIDs uniquely identify, but do not necessarily form part of an image data file. The image data files - for example, in JPEG, PNG or another suitable image format - are accessible to both the identity verification server 2 and the mobile device 10. Both entities are able to match an I. GUID with a specific image, but the image files themselves are not necessarily transmitted together with the I. GUIDs from the identity verification server 2 to the mobile device. This can promote the security of

communications between the identity verification server 2 and the mobile device 10.

The image data files themselves can be acquired by the mobile device 10 and the identity verification server 2 via a separate process - for example, via accessing an encrypted image database. This may be hosted by the identity verification server 2. In other alternatives, a bank of images may be pre-loaded on to the persistent memory 16 of the mobile device 10 by the app 9, the appropriate images fetched by using the I. GUIDs as a reference.

The app 9 configures the mobile device 10 to receive the T.GUID and I. GUID list - and also the associated image files is they are not already resident in the memory of the mobile device 10. The T.GUID is checked to ensure that it validly originated from the identity verification server 2, and if so, the first set of nine images associated with the I. GUID list are presented - such as that described above with reference to Figure 9. As described, the app 9 is configured to enable user selection of one of those images, and from this a Selected Image GUID (SI. GUID) is generated. As before, this may be a derivation of the I. GUID associated with the selected image, and that derivation may be via an encryption function.

The app 9 configures the mobile device to then transmit the SI. GUID back to the identity verification server 2 together with the T.GUID.

In response to receipt of a valid SI. GUID and T.GUID combination, the identity verification server 2, generates a second set of image GUIDs (I. GUID 10..18). As before, each I.GUID uniquely identifies an image of a second set of nine images. The second set of nine I.GUIDs form a second I.GUID List which is send together with the T.GUID back to the mobile device 10.

Again, the app 9 configures the mobile device 10 to receive the T.GUID and the second

1.GUID List. The associated image files are also fetched if they are not already resident in the memory of the mobile device 10.

Assuming validity of the T.GUID the second set of nine images associated with the second I.GUID list are presented - such as that described above with reference to Figure 10. As described, the app 9 is configured to enable user selection of one of those images, and from this a second Selected Image GUID (SI_2.GUID) is generated. As before, this may be a derivation of the I.GUID associated with the selected image, and that derivation may be via an encryption function.

In addition to this, the mobile device 10 is configured by the app 9 to prepare a Public- Private key pair (Kpr, Kpu), and further configures the mobile device 10 to transmit the public key (Kpu), the T.GUID and the SI_2.GUID of the second selected image to the identity verification server 2. Notably, as the public key (Kpu) is transmitted

simultaneously with that which represents a user selection of an image used in the user interaction test, this provides a particularly secure way to prevent against an automated malicious attack.

It should also be noted that the images to which the I.GUIDs refer belong to specific categories, as described above. For example, each I.GUID refers to an image depicting an object or concept. The identity verification server 2 keeps track of the categories associated with each I.GUID, as sent to the mobile device 10. Firstly, this is so that the second I.GUID list and associated second set of images can include one image that belongs to a category common to at least the first image selected by the user.

Furthermore, on receipt of both selected image GUIDs (i.e. SI. GUID and SI_2.GUID) , the identity verification server 2 is able to carry out a check to determine whether both selected GUIDs relate to images belonging to the same category. As mentioned above, these measures improve the security of the system 1 as a whole, and are especially useful against resisting an automated brute-force attack on the identity verification server

2.

Upon receipt of the T.GUID, the SI_2.GUID and the Kpu, the identity verification server 2 is configured to perform checks to determine that the T.GUID is valid, and the SI_2.GUID is associated with the same category as the SI.GUID received earlier as part of the same transaction (as identified by the T.GUID).

Assuming such checks are satisfactory, the identity verification server 2 generates an Rijndael key (RK) which is a symmetrical encryption key. In alternative embodiments, other types of symmetrical keys may be generated by the identity verification server 2.

The symmetrical key may be an AES key, for example.

The Rijndael key (RK) itself is encrypted by the identity verification server 2 using the public key (Kpu) received by the identity verification server 2 from the mobile device 10. This forms part of an encrypted package (ERK) that is then sent back to the mobile device 10 together with the T.GUID.

The mobile device 10 is then configured by the app 9 to: receive the encrypted package (ERK), encrypted by the Kpu, the package containing an encryption key (RK) that has been provided by the identity verification server 2; decrypt the encrypted packaged (ERK) using the private key (Kpr) to obtain the encryption key (RK) that has been provided by the identity verification server 2;

generate a transaction data package (TD) including:

- the T.GUID;

user information such as unhidden payment card data (e.g. that which is physically borne on the front of the payment card, such as validity dates and name). As mentioned, these may be scanned into the app via a card-scanning process, or manually entered by user via character input into relevant fields; and

- the PIN, as entered by user via PIN-entry process explained above with

reference to Figures 11 to 13; and then

encrypt the transaction data package (TD) using the symmetrical encryption key (RK) to create an Encrypted Transaction Data (ETD) package; and

- transmit the ETD to the identity verification server 2.

As the ETD is encrypted using a symmetrical key, the identity verification server 2 is able to decrypt the ETD with the same Rijndael key (RK) to decrypt and extract the transaction data package (TD), including the PIN entered by the user during the code-input session.

The transaction data package (TD), or part thereof, can be encrypted again as part of a second encrypted package that is transmitted to the trusted authority 3 as part of Steps 1 d and 1 e already described above with reference to Figure 1. A positive or negative confirmation message then prompts the identity verification server 2 to send a transaction result back to the mobile device 2. The transaction result thus reflects trusted authority verification of authentication on the basis of the received TD - i.e. via verification that the PIN is correct. Furthermore, the pairing of a correctly-submitted PIN together with other identity data (e.g. user information such as unhidden payment card data) permits the verification of the identity of the user.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art.

For example, the embodiment described discusses the input and handling of secret information associated with a payment card, such as a PIN. However, in other embodiments of the invention, other secret authentication codes may be handled in a similar manner. For example, the PIN input mechanism 30 may be a different code input mechanism. Input interface elements representative of a different set of characters may be used (e.g. alphanumerical characters).

In other alternatives, components of the system may be substituted with other functionally- similar components. For example, whilst the invention is particularly applicable for use with a mobile device, other electronic user input devices may be used instead (e.g. tablets or other such computing devices). Notably, it is not essential that the means by which the application is acquired by the computing device is a wireless telecommunication module. Other ways of downloading the application are possible (e.g. via a wired connection, or via "side-loading"). Similarly, communication via the network 5 with other components of the system may be achieved via a communication module other than the wireless

telecommunication module.

Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the scope of the appended claims.

Claims

1. A user authentication method for verifying the identity of a user, the method

comprising the steps of:

performing a user interaction test for discriminating between human and automated interaction;

initialising a code-input session for receiving a user input of a secret authentication code, such as a PIN;

sending the authentication request; and

receiving an authentication response verifying the authenticity of the user on the basis of the authentication code;

wherein the code-input session comprises:

displaying, on a touch-sensitive display screen of an electronic user input device, a virtual code-input mechanism having input interface elements each representing a character of a code to be inputted;

positioning each input interface element on the screen at an absolute position that changes for each code-input session, but maintains a predetermined position relative to the other displayed input interface elements; and permitting user interaction with a sequence of the input interface elements to specify a corresponding sequence of characters, thereby receiving from the user input of their secret authentication code.

2. The method of claim 1 , wherein the code-input session further comprises displaying, on the screen of the device, movement in the absolute position of each input interface element prior to the step of permitting user interaction with those input interface elements to specify the user input code.

3. The method of claim 2, wherein movement of each input interface element comprises translational movement along a path.

4. The method of claim 2, wherein the translational movement is along a common path.

5. The method of claim 3 or claim 4, wherein the path is an endless path, such as a circular path.

6. The method of any one of claims 2 to 5, wherein movement in the absolute position of each input interface element occurs for a movement period, the length of the period being randomised over multiple code-input sessions.

7. The method of any one of claims 2 to 5, wherein the speed of movement of the input interface elements is randomised over multiple code-input sessions.

8. The method of any preceding claim, wherein the relative position between input

interface elements is maintained so that the same predetermined input interface elements are positioned adjacent to one another over multiple code-input sessions.

9. The method of claim 8, wherein the code-input session comprises displaying, at each user input element, a respective numerical character of a code to be inputted, the relative position between input interface elements being maintained so that input interface elements that represent numerically adjacent characters are positioned adjacent to one another over multiple code-input sessions.

10. The method of any preceding claim, wherein the code-input session comprises

displaying, at each user input element, a respective character of a code to be inputted, the displayed characters conforming to a predetermined orientation.

11. The method of claim 10, wherein the predetermined orientation of the displayed

characters is maintained over multiple code-input sessions, and irrespective of the absolute position and/or movement of the displayed characters.

12. The method of claim 10 or claim 11 , wherein the electronic user input device

comprises an orientation detector for detecting the orientation of the device, and the orientation to which the displayed characters conform is predetermined with reference to an orientation signal from the orientation detector.

13. The method of any preceding claims, wherein the code-input mechanism comprises a target region, and user interaction with each input interface element to specify a respective character of the secret authentication code comprises registering, via the screen, a drag-touch interaction that follows a path starting at that input interface element, and ending at the target region.

14. The method of claim 13, wherein the input interface element moves along the path during the drag-touch interaction, the position over time of the input interface element coinciding with the position of touch.

15. The method of claim 13 or claim 14, wherein the target region comprises a perimeter within which the path of the drag-touch interaction must end to specify a respective character of the secret authentication code.

16. The method of any preceding claim, wherein the user interaction test checks for human interaction via the touch-sensitive display screen of the electronic user input device.

17. The method of claim 16, wherein the user interaction test comprises:

assigning to each of a plurality of images a predetermined category; registering one of those categories to be selected by a user in order to pass the user interaction test;

displaying the plurality of images on the screen of the electronic user input device;

issuing a prompt, via the electronic user input device, to select one of the displayed images, the prompt notifying the user of the registered category; receiving a user selection of at least one of those images; and

determining a pass of the user interaction test if the user-selected image is assigned to the registered category.

18. The method of claim 16 or claim 17, wherein the user interaction test comprises:

displaying, on the touch-sensitive display screen of the electronic user input device, a first set of images, each image being preassigned to a category unique within the first set;

registering, via the touch-sensitive display screen of the electronic user input device, a user selection of one of the first set of images;

displaying, on the touch-sensitive display screen of the electronic user input device, a second, different set of images, one of which is preassigned to a category matching the unique category to which the user-selected image is preassigned;

registering, via the touch-sensitive display screen of the electronic user input device, a user selection of one of the second set of images; and

determining a pass of the user interaction test if the user-selected images from the first and second set are preassigned to a common category.

19. The method of any preceding claim, wherein failure of the user authentication test prevents carrying out of at least one subsequent method step.

20. A computer-implemented user authentication system for carrying out the method of any preceding claim.

21. A computer-implemented user authentication system, the system comprising an

electronic user input device in the form of a mobile device having a touch-sensitive display screen and a wireless communication module, the mobile device being operable to download an application via the wireless communication module, and execute the application, the executed application controlling the mobile device to:

apply a cryptographic function to generate an authentication request, the cryptographic function encrypting the user-inputted secret authentication code; send the authentication request to a trusted authority; and

receive from the trusted authority an authentication response verifying the authenticity of the user on the basis of the secret authentication code;

wherein the code-input session comprises:

displaying, on the touch-sensitive display screen, a virtual code input mechanism having input interface elements each representing a character of a code to be inputted;

positioning each input interface element on the screen at an absolute position that changes for each code-input session, but maintains a predetermined position relative to the other displayed input interface elements; and

permitting user interaction with a sequence of the input interface elements to specify a corresponding sequence of characters, thereby receiving from the user input of their secret authentication code.

22. The system of claim 20 or claim 21 , further comprising an identity verification server and a plurality of electronic user input devices, the identity verification server being configured to:

participate in a user interaction test with each of those electronic user input devices; and

validate secret authentication codes received from electronic user input devices determined to have been user operated to pass the user interaction test.

23. The system of claim 22, wherein the identity verification server is configured to participate in a user interaction test with each of those electronic user input devices by:

transmitting, to each electronic user input device, the plurality of images assigned to a predetermined category;

registering, for each device, one of those categories to be selected by a user in order to pass the user interaction test;

receiving, from each respective device, a user selection of at least one of those images; and

determining a pass of the user interaction test in respect of those devices where the user-selected image is assigned to the category registered against that device.

24. The system of any one of claims 20 to 23, wherein the electronic user input device is configured to:

generate a Public-Private key pair (Kpr, Kpu), the public key being made available to an identity verification server of the system;

receive a symmetric encryption key from the identity verification server, the symmetric encryption key being encrypted by the identity verification server using said public key, and decrypted by the electronic user input device using the private key;

wherein the cryptographic function comprises encrypting the user-inputted secret authentication code using the symmetric encryption key.

25. The system of any one of claims 20 to 24, wherein encryption key exchange between an electronic user input device and an identity verification server of the system occurs simultaneously, at least in part, with a user interaction test.