WO2019028493A1

WO2019028493A1 - Method, system and computer readable medium for user authentication

Info

Publication number: WO2019028493A1
Application number: PCT/AU2018/000132
Authority: WO
Inventors: Philip Anthony Frederick CUFF; Kamil KREISER
Original assignee: Token One Pty Ltd
Priority date: 2017-08-08
Filing date: 2018-08-08
Publication date: 2019-02-14

Abstract

A method performed by a server processing system including: (a) generating and transferring indexed keys for storage by a user device, including: generating and storing indexed keys; transferring the indexed keys to the user device for storage; generating and storing indexed expected codes determined using a user's personal identifier and a respective key; generating and storing indexed hash values of the expected codes; deleting temporary data from the server accessible memory including the indexed keys; (b) receiving an authentication request to authenticate the user; (c) attempting to authenticate the user by: receiving a user submitted code based on a selected key presented by the user device and the user's personal identifier; determining a hash value of the user submitted code; and determining an authentication result based on a comparison of the hash values of the user submitted code and the expected code based on an index for the selected key.

Description

METHOD, SYSTEM AND COMPUTER READABLE MEDIUM FOR USER AUTHENTICATION

Related Applications

[0001 ] The current application claims priority from Australian provisional patent application No. 2017903139 and Australian provisional patent application No. 2018901845. The contents of Australian provisional patent application No. 2017903139 and Australian provisional patent application No. 2018901845 are herein incorporated by reference in their entirety.

Field of Invention

[0002] The present invention relates to a server processing system, method, computer readable medium, and system for user authentication.

Background

[0003] Generally when a user requires access to a secure environment, such as a secure webpage, authentication of the user is required prior to granting access to the secure

environment. A number of methods currently exist.

[0004] A very common technique is to request the user to provide a user identity and password. In most instances, the user identity and password are encrypted and transferred to a server processing system for user authentication. Problems exist with this type of authentication technique. For example, malicious software (i.e. keylogging software) operating on a terminal can log the user input, wherein the captured user identity and password can be maliciously used in later fraudulent activities.

[0005] Biometric authentication techniques have also been used to authenticate a user requesting access to a secure environment. However, data representative of a biometric is also susceptible to capture and reuse and, as biometric features of a user may be difficult to alter, there are significant drawbacks in the event that the biometric feature(s) of the user has been

compromised. [0006] Physical tokens such as smart cards and the like have also been used as a means to authenticate a user requesting access to a secure environment. However, such devices are inconvenient to a user who may not carry the device with them at all times, and generally do not actually confirm that the user presenting the physical token is actually the correct user requesting authentication, merely that the device was present at the moment of authentication.

[0007] The current Applicant disclosed in PCT/AU2014/050024 an authentication system including a server processing system configured to receive an authentication request to authenticate the user attempting to access the secure environment. The server processing system transferred, to the user or a user device associated with the user, an index corresponding to a selected key from a plurality of keys. The plurality of keys are stored by both the user device and the server accessible memory. The server processing system receives data indicative of a code which is based on the selected key presented by a user device and a personal identifier. The server then determines, using the code, whether the user is authenticated. The Applicant has identified improvements to the system disclosed by PCT/AU2014/050024.

Summary

[0008] It is an object of the present invention to substantially overcome or at least ameliorate one or more disadvantages of existing arrangements.

[0009] In a first aspect there is provided a method for authenticating a user, wherein the method includes, in a server processing system, steps of:

(a) generating and transferring a plurality of keys to be stored by a user device associated with the user, including steps of:

generating and storing a plurality of keys, wherein the plurality of keys are indexed;

transferring the plurality of keys to the user device for storage, wherein the plurality of keys stored by the user device are indexed;

generating and storing a plurality of expected codes which are indexed, each expected code being determined using a personal identifier of the user and a respective key from the plurality of keys;

generating and storing in server accessible memory a plurality of hash values of the expected codes, wherein the plurality of hash values of the expected codes are indexed;

deleting, from the server accessible memory and prior to receiving an authentication request, the plurality of keys, the personal identifier of the user, and the plurality of expected codes;

(b) receiving the authentication request to authenticate the user; and

(c) attempting to authenticate the user including steps of:

receiving data indicative of a user submitted code, wherein the user determines the user submitted code based on a selected key presented by the user device and the personal identifier;

determining a hash value of the user submitted code; and

determining an authentication result based on a comparison of the hash value of the user submitted code against the corresponding hash value of the expected code based on an index for the selected key.

[0010] In certain embodiments, the authentication request is received from a secure

environment processing system controlling access to a secure environment, wherein the method includes the server processing system transferring an authentication response to the secure environment processing system, wherein the authentication response is indicative of the authentication result indicating whether the user is authenticated for accessing the secure environment.

[0011] In certain embodiments, the method includes the server processing system performing steps of:

receiving a registration request from the user device;

transferring registration key data indicative of a registration key to the user device; receiving, from the user, a registration code which is based on the registration key and the personal identifier of the user; and

determining the personal identifier using the registration key and the registration code; wherein after the generation of the plurality of hash values of the expected codes, the registration key data and the registration code are deleted from server accessible memory.

[0012] In certain embodiments, the method includes the server processing system performing steps of:

receiving a registration request from the user device; transferring registration key data indicative of a first registration key and second registration key to the user device;

receiving, from the user, a first registration code which is based on the first registration key and the personal identifier of the user;

receiving, from the user, a second registration code which is based on the second registration key and the personal identifier of the user; and

determining and confirming the personal identifier using the first registration key, the second registration key, the first registration code and the second registration code;

wherein after the generation of the plurality of hash values of the expected codes, the first and second registration codes are deleted from server accessible memory.

[0013] In certain embodiments, the registration request is indicative of a unique device profile identifying the user device, wherein, prior to transferring the registration key data, the method includes the server processing system generating a user account, wherein the user device is associated with the user account based on the unique device profile.

[0014] In certain embodiments, the registration request is indicative of identity data which attempts to prove the identity of the user, wherein, prior to transferring the registration key data, the method includes the server processing system performing steps of:

facilitating verification of the identity of the user based on the identity data; and

generating the user account based on a positive verification of the identity of the user.

[0015] In certain embodiments, the method includes the server processing system associating, with the user account, data indicative of the identity of the user indicated by a digital certificate of the user.

[0016] In certain embodiments, after generating a user account the method includes the server processing system associating the plurality of hash values of the expected codes with the user account.

[0017] In certain embodiments, the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

facilitating verification of the user's identity; and in response to successful verification:

generating and transferring reset key data indicative of a reset key to the user device;

receiving, from the user, a reset code, wherein the user determines the reset code based on the reset key presented by the user device and a new personal identifier;

determining the new personal identifier using the reset code and the reset key; generating and storing in server accessible memory a plurality of new keys, wherein the plurality of new keys are indexed;

generating and storing a plurality of new expected codes which are indexed, each new expected code being determined using the new personal identifier of the user and a respective key from the plurality of new keys;

generating and storing in server accessible memory a plurality of hash values of the new expected codes, wherein the plurality of hash values of the new expected codes are indexed;

transferring the plurality of new keys to the user device for storage, wherein the plurality of new keys stored by the user device are indexed; and

deleting the reset key data, the reset code, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

[0018] In certain embodiments, the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

generating and transferring reset key data indicative of a first and second reset key to the user device;

receiving, from the user, a first reset code, wherein the user determines the first reset code based on the first reset key presented by the user device and a new personal identifier; receiving, from the user, a second reset code, wherein the user determines the second reset code based on the second reset key presented by the user device and the new personal identifier;

determining and confirming the new personal identifier using the first reset code, the second reset code, the first reset key and the second reset key;

generating and storing in server accessible memory a plurality of new keys, wherein the plurality of new keys are indexed;

generating and storing in server accessible memory a plurality of hash values of the new expected codes, wherein the plurality of hash values of the new expected codes are indexed; transferring the plurality of new keys to the user device for storage, wherein the plurality of new keys stored by the user device are indexed; and

deleting the reset key data, the first and second reset code, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

[0019] In certain embodiments, the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

facilitating verification of the user's identity; and

in response to successful verification:

receiving, from the user, a first reset code, wherein the user determines the first reset code based on the first reset key presented by the user device and a new personal identifier;

receiving, from the user, a second reset code, wherein the user determines the second reset code based on the second reset key presented by the user device and the new personal identifier;

determining and confirm the new personal identifier using the first reset code, the second reset code, the first reset key and the second reset key;

generating and storing a plurality of new keys, wherein the plurality of new keys are indexed;

transferring the plurality of new keys to the user device for storage, wherein the plurality of new keys stored by the user device are indexed; and deleting from server accessible memory the reset key data, the first and second reset codes, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

[0020] In certain embodiments, the method includes the server processing system receiving, from the user device or user, an index selection request, and facilitating provision, to the user device or the user, the selected index in response to receiving the index selection request, wherein the selected index is used by the user device for presenting the selected key.

[0021] In certain embodiments, the user device is configured to store encrypted data with a plurality of layers of encryption, wherein the user device or a processing system separate to the user device includes an executable application for facilitating at least one of encryption and decryption, wherein in response to the server processing system successfully authenticating the user, the method includes:

transferring, from the server processing system to the user device, a server provisioned cryptographic key;

determining, by the user device, a user device cryptographic key based on a unique device profile identifying the user device; and

at least one of:

decrypting the layers of encryption of the encrypted data stored by the user device using the server provisioned cryptographic key, the user device cryptographic key and the executable application; and

encrypting data with the plurality of layers of encryption using the executable application, the user device cryptographic key and the server provisioned cryptographic key.

[0022] In certain embodiments, the executable application enables transfer of cryptocurrency to an entity using a private key stored by the user device, wherein the executable application enables selection of the entity from a whitelist presented in a user interface displayed by the user device or the processing system, wherein the whitelist is indicative of verified entities stored in the server accessible memory.

[0023] In certain embodiments, the executable application enables transfer of cryptocurrency to an entity, wherein the method includes: the executable application transferring data indicative of the entity to the server processing system;

the server processing system comparing the entity against a whitelist of verified entities stored in the server accessible memory; and

transferring, from the server processing system, to the user device or processing system executing the executable application, an indication of a result of the comparison of the entity against the whitelist.

[0024] In certain embodiments, the method includes the server processing system generating and storing the plurality of expected codes after the user is provisioned with the user device, wherein the user device has stored therein the plurality keys at the time of the user device being provisioned to the user.

[0025] In certain embodiments, the method includes the server processing system receiving the user submitted code and the respective index of one of the plurality of keys used by the user for determining the user submitted code.

[0026] According to a second aspect there is provided a computer readable medium for configuring a server processing system to authenticate a user, wherein the computer readable medium includes executable instructions which, upon execution, configure the server processing system to perform the method according to the first aspect.

[0027] According to a third aspect there is provided a server processing system for

authenticating a user, wherein the server processing system is configured to perform a method according to the first aspect.

[0028] According to a fourth aspect there is provided a system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

the server processing system is configured according to any one of claims 1 to 15; and the user device is configured to:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

present the selected key to the user via a display;

receive, via an input device, the user submitted code based on the selected key and the personal identifier of the user; and

transfer, to the server processing system via a communication device, the data indicative of the user submitted code.

[0029] In certain embodiments, the user device is configured to determine if the user device is unable to communicate with the server processing system, wherein in response the user device is configured to display a prompt requesting the user to input via an input device a selected index received by the user from the server processing system, wherein the user device is configured to retrieve from memory, using the selected index, the selected key and display the selected key to the user via the display.

[0030] According to a fifth aspect there is provided a system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

the server processing system is configured according to embodiments of the first aspect; and

the user device is configured to:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

receive, via an input device of the user device, the corresponding index of the selected key; and

present, via a display of the user device, the selected key.

[0031] According to a sixth aspect there is provided a system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

the server processing system is configured according to certain embodiments of the first aspect: and

the user device is configured to:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

receive, via an input device of the user device, a key selection request;

select, from the memory of the user device, one of the keys from the plurality of keys as the selected key; and

present, via a display of the user device, the selected key and the corresponding index of the selected key. [0032] In certain embodiments, the user device has no operational communication device when provided to the user.

[0033] In certain embodiments, the display is an electronic paper display to present the selected key to the user.

[0034] In certain embodiments, the display and input device is a touch sensitive electronic paper display.

[0035] According to a seventh aspect there is provided a system for authenticating a user, wherein the system includes a server processing system and a software application, wherein: the server processing system configured to:

(a) generate and transfer a plurality of keys to be stored by a user device associated with the user, wherein the server processing system is configured to:

generate and store a plurality of keys, wherein the plurality of keys are indexed; transfer the plurality of keys to the user device for storage, wherein the plurality of keys stored by the user device are indexed;

generate and store a plurality of expected codes which are indexed, each expected code being determined using a personal identifier of the user and a respective key from the plurality of keys;

generate and store in server accessible memory a plurality of hash values of the expected codes, wherein the plurality of hash values of the expected codes are indexed; delete, from server accessible memory and prior to receiving an authentication request, the plurality of keys, the personal identifier of the user and the plurality of expected codes;

(b) receive an authentication request to authenticate the user; and

(c) attempt to authenticate the user, wherein the server processing system is configured to:

transfer, to the user or the user device, an index for a selected key from the plurality of keys;

receive data indicative of a user submitted code, wherein the user determines the user submitted code based on the selected key presented by the user device and the personal identifier;

determine a hash value of the user submitted code; and

determine an authentication result based on a comparison of the hash value of the user submitted code against the corresponding hash value of the expected code based on an index for the selected key; and

the software application is executable by the user device to configure the user device to: receive the plurality of keys;

store the plurality of keys; and

present the selected key to the user.

[0036] According to an eighth aspect there is provided a server processing system for enabling a user to reset a personal identifier used for authenticating a user, wherein the server processing system is configured to:

receive, from the user, a reset personal identifier request;

generate and store a plurality of new keys, wherein the plurality of new keys are indexed;

transfer reset key data indicative of a reset key, selected from the plurality of new keys, to the user device;

receive and store, from the user, a reset code, wherein the user determines the reset code based on the reset key presented by the user device and a new personal identifier;

determine the new personal identifier using the reset code and the reset key, wherein the new personal identifier is stored;

generate and store a plurality of new expected codes which are indexed, each new expected code being determined using the new personal identifier of the user and a respective key from the plurality of new keys;

generate and store in server accessible memory a plurality of hash values of the new expected codes, wherein the plurality of hash values of the new expected codes are indexed; transfer the plurality of new keys, excluding the reset key, to the user device for storage, wherein the plurality of new keys stored by the user device are indexed; and

delete, from the server accessible memory and prior to receiving an authentication request, the reset key data, the reset code, the new personal identifier, the plurality of new keys, and the plurality of new expected codes. [0037] According to a ninth aspect there is provided a method for resetting a personal identifier for authenticating a user, wherein the method includes a server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

transferring reset key data indicative of a reset key, selected from the plurality of new keys, to the user device;

receiving, from the user, a reset code which is stored, wherein the user determines the reset code based on the reset key presented by the user device and a new personal identifier; determining the new personal identifier using the reset code and the reset key, wherein the new personal identifier is stored;

generating and storing a plurality of hash values of the new expected codes, wherein the plurality of hash values of the new expected codes are indexed;

transferring the plurality of new keys, excluding the reset key, to the user device for storage, wherein the plurality of new keys stored by the user device are indexed; and

deleting, from server accessible memory prior to receiving an authentication request, the reset key data, the reset code, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

[0038] According to a tenth aspect there is provided a computer readable medium for configuring a server processing system for enabling a user to reset a personal identifier used for authenticating a user, wherein the computer readable medium includes executable instructions which, upon execution, configure the server processing system to perform the method of the eighth aspect.

[0039] Other aspects and embodiments will be realised throughout the detailed description. Brief Description of the Figures

[0040] Example embodiments should become apparent from the following description, which is given by way of example only, of at least one preferred but non-limiting embodiment, described in connection with the accompanying figures.

[0041] Figure 1 illustrates a functional block diagram of an example processing system that can be utilised to embody or give effect to a particular embodiment;

[0042] Figure 2 illustrates an example network infrastructure that can be utilised to embody or give effect to a particular embodiment;

[0043] Figure 3 illustrates a system diagram of an example system for authenticating a user attempting to access a secure environment;

[0044] Figure 4 illustrates a flow chart representing an example method performed by the server processing system to authenticate a user attempting to access a secure environment;

[0045] Figure 5 illustrates a flow chart representing an example method of user registering to use an authentication service offered by the server processing system;

[0046] Figure 6A illustrates an example of a plurality of keys;

[0047] Figure 6B illustrates an example user interface including a graphical representation of a key and an identifier reference;

[0048] Figure 7 illustrates a flow chart representing an example method of a user resetting a personal identifier for use in authenticating the user;

[0049] Figure 8 illustrates a system diagram of a further example system for authenticating a user attempting to access a secure environment;

[0050] Figure 9 illustrates a flowchart representing a further method of user registering to use an authentication service offered by the server processing system of Figure 8; [0051] Figure 10 is a schematic of another example of a user device presenting a graphical representation of a key and an identifier reference;

[0052] Figure 11 is a block diagram schematic of an example user device;

[0053] Figure 12 is a system diagram using the user device of Figure 1 1 ;

[0054] Figure 13 is a block diagram schematic of a further example user device;

[0055] Figure 14 is a flowchart representing an example method of authenticating a user for using the user device of Figure 13; and

[0056] Figure 15 is a flowchart representing an example method of authenticating a user using the user device of Figure 13.

Description of the Preferred Embodiments

[0057] The following modes, given by way of example only, are described in order to provide a more precise understanding of the subject matter of a preferred embodiment or embodiments. In the figures, incorporated to illustrate features of an example embodiment, like reference numerals are used to identify like parts throughout the figures.

[0058] A particular embodiment can be realised using a processing system, an example of which is shown in Fig. 1. In particular, the processing system 100 generally includes at least one processor 102, or processing unit or plurality of processors, memory 104, at least one input device 106 and at least one output device 108, coupled together via a bus or group of buses 1 10. In certain embodiments, input device 106 and output device 108 could be the same device. An interface 112 also can be provided for coupling the processing system 100 to one or more peripheral devices, for example interface 1 12 could be a PCI card or PC card. At least one storage device 1 14 which houses at least one database 1 16 can also be provided. The memory 104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The processor 102 could include more than one distinct processing device, for example to handle different functions within the processing system 100. [0059] Input device 106 receives input data 118 and can include, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice controlled activation such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, etc.. Input data 1 18 could come from different sources, for example keyboard instructions in conjunction with data received via a network. Output device 108 produces or generates output data 120 and can include, for example, a display device or monitor in which case output data 120 is visual, a printer in which case output data 120 is printed, a port for example a USB port, a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, etc.. Output data 120 could be distinct and derived from different output devices, for example a visual display on a monitor in conjunction with data transmitted to a network. A user could view data output, or an

interpretation of the data output, on, for example, a monitor or using a printer. The storage device 114 can be any form of data or information storage means, for example, volatile or nonvolatile memory, solid state storage devices, magnetic devices, etc..

[0060] In use, the processing system 100 is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, the at least one database 1 16 and/or the memory 104. The interface 1 12 may allow wired and/or wireless communication between the processing unit 102 and peripheral components that may serve a specialised purpose. The processor 102 receives instructions as input data 118 via input device 106 and can display processed results or other output to a user by utilising output device 108. More than one input device 106 and/or output device 108 can be provided. It should be appreciated that the processing system 100 may be any form of terminal, server, specialised hardware, or the like.

[0061] The processing device 100 may be a part of a networked communications system 200, as shown in Fig. 2. Processing device 100 could connect to network 202, for example the Internet or a WAN. Input data 1 18 and output data 120 could be communicated to other devices via network 202. Other terminals, for example, thin client 204, further processing systems 206 and 208, notebook computer 210, mainframe computer 212, PDA 214, pen-based computer 216, server 218, etc., can be connected to network 202. A large variety of other types of terminals or configurations could be utilised. The transfer of information and/or data over network 202 can be achieved using wired communications means 220 or wireless communications means 222. Server 218 can facilitate the transfer of data between network 202 and one or more databases 224. Server 218 and one or more databases 224 provide an example of an information source. [0062] Other networks may communicate with network 202. For example, telecommunications network 230 could facilitate the transfer of data between network 202 and mobile or cellular telephone 232 or a PDA-type device 234, by utilising wireless communication means 236 and receiving/transmitting station 238. Satellite communications network 240 could communicate with satellite signal receiver 242 which receives data signals from satellite 244 which in turn is in remote communication with satellite signal transmitter 246. Terminals, for example further processing system 248, notebook computer 250 or satellite telephone 252, can thereby communicate with network 202. A local network 260, which for example may be a private network, LAN, etc., may also be connected to network 202. For example, network 202 could be connected with ethernet 262 which connects terminals 264, server 266 which controls the transfer of data to and/or from database 268, and printer 270. Various other types of networks could be utilised.

[0063] The processing device 100 is adapted to communicate with other terminals, for example further processing systems 206, 208, by sending and receiving data, 118, 120, to and from the network 202, thereby facilitating possible communication with other components of the networked communications system 200.

[0064] Thus, for example, the networks 202, 230, 240 may form part of, or be connected to, the Internet, in which case, the terminals 206, 212, 218, for example, may be web servers, Internet terminals or the like. The networks 202, 230, 240, 260 may be or form part of other

communication networks, such as LAN, WAN, ethernet, token ring, FDDI ring, star, etc., networks, or mobile telephone networks, such as GSM, CDMA or 3G, 4G, 5G, etc., networks, and may be wholly or partially wired, including for example optical fibre, or wireless networks, depending on a particular implementation.

[0065] Referring to Figure 3 there is shown a system diagram representing an example system 300 for authenticating a user 350 attempting to access a secure environment 325.

[0066] In particular, the system 300 includes a server processing system 310 in data

communication, via a data communication network, with a secure environment processing system 320. The server processing system 310 has associated therewith memory in the form of server accessible memory 315, preferably provided in the form of a database, which stores account data for authenticating the user 350. The secure environment processing system 320 controls access to the secure environment 325 which is restricted to authorised users. The secure environment processing system 320 may be a server processing system which can be provided in the form of processing system 100. Examples of the secure environment 325 may include digital environments such as secure websites, secure server services, and the like, or potentially physical environments such as a security door in a building or the like.

[0067] The system 300 can also include a user processing system 340 that is in data

communication, via the network, with the secure environment processing system 320. The user 350 interacts with the user processing system 340 to transfer a request to the secure environment processing system 320 in order to gain access to the secure environment 325. Examples of the user processing system 340 may include a desktop terminal, a laptop, a tablet computer, or the like. The user processing system 340 may be provided in the form of processing system 100.

[0068] The system 300 also includes a user device 330, independent to the user processing system 340, which is associated with the user 350 and is in data communication, via the network, with the server processing system 310. The user device 330 is preferably a portable processing system associated with the user 350, such as a mobile telephone (i.e. such as a "smart phone"), a wearable processing system (i.e. such as Google Glass™), or any other interactive device which is separate to the user processing system 340 and associated with the user 350. The user device 330 has stored in memory a software application 335 (commonly referred to as an "app") which presents an interface to the user for authentication.

[0069] In one form, the user processing system 340 is not required. In particular, the user can interact with the user device 330 to transfer a request to the secure environment processing system 320 in order to gain access to the secure environment 325.

[0070] Referring to Figure 4 there is shown a flowchart representing an example method 400 of a user 350 registering with the server processing system 310 for authenticating the user 350 when accessing the secure environment 325 controlled by the secure environment processing system 320.

[0071] In particular, at step 405, the method 400 includes the user 350 transferring a registration request to the server processing system 310. The registration request may be transferred from the user device 330 and/or a user processing system 340 operated by the user 350. In particular, in the event that the registration request is submitted at least partially using the user device 330, this may be in response to the user installing the software application 335 on the user device 330, launching the software application 335, and then the user interacting with the software application 335 to submit the registration request. The registration request can be indicative of identity data which attempts to prove the identity of the user 350, and a unique device identifier indicative of the user device 330. The identity data may be indicative of credit card numbers, passport numbers, utility bills, addresses and other like information. In particular embodiments, the unique device identifier is a unique device profile which is generated by the software application 335. The software application 335 determines a number of characteristics of the user device 330 and uses the determined characteristics to generate the unique device profile. The determined characteristics may include one or more characteristics of hardware of the user device 330 (such as the CPU, memory), a MAC address of the user device 330, a software profile which may be indicative of a digital certificate associated with the user and one or more identifiers associated with the user device 330. The software application 335 applies a hashing algorithm to the determined characteristics to generate the unique device profile in the form of a hash value. The unique device profile is then transferred to the server processing system 310 for storage. The unique device profile acts as a device signature to uniquely identify the user device 330 based on multiple characteristics of the user device 330. In particular embodiments, the unique device profile is also stored in memory of the user device 330 and may be used for implementing a security check as will be explained in further detail later herein.

[0072] At step 410, the method 400 includes the server processing system 310 facilitating verification of the identity of the user 350 based on the identity data. In particular, a server processing system 310 may utilise an identity verifier (IDV) in an attempt to verify that the set of information is associated with a single user. In response to a positive verification, the method 400 proceeds to step 415. Otherwise the server processing system 310 may request further identification information from the user 350.

[0073] At step 415, the method 400 includes the server processing system 310 generating a user account in the memory 315 associated with the server processing system 310. The memory 315 is preferably a database accessible by the server processing system 310. The server processing system 310 associates the user device 330 with the user account based on the unique device identifier which in particular embodiments is the unique device profile. [0074] At step 420, the method 400 includes the server processing system 310 generating a plurality of keys. The plurality of keys are stored temporarily in server accessible memory 315.

[0075] At step 425, the method 400 includes the server processing system 310 transferring one of the keys to user device 330 for storage in memory. The key that is transferred is referred to as a registration key for convenience, however it will be appreciated that the registration key is one of the plurality of keys. The registration key preferably has associated therewith an index.

[0076] At step 430, the method includes the user device storing the received registration key in memory. The registration key preferably has associated therewith an index which is the same index used by the server processing system 310.

[0077] At step 435, the method 400 includes the server processing system 310 receiving a personal identifier registration request from the user 350. The personal identifier registration request may be received from the user processing system 340 or the user device 330. In response, the server processing system 310 transfers to the user processing system 340 or the user device 330, a code request interface for presentation to the user requesting that the user input a code indirectly representing the desired personal identifier. The code request interface may be presented via a web-browser, web-enabled application or the like. The code request interface may be a webpage or a portion of a webpage that is presented to the user 350. For example, the code request interface may be a frame or window located within a webpage hosted by the secure environment processing system 320, wherein the code request interface can be generated and hosted by the server processing system 325. As will be discussed in detail below, the code that is input by the user 350 into the code request interface is transferred to the server processing system 310.

[0078] At step 440, the server processing system 310 transfers an index of the registration key to the user. The index may be transferred via the user device 330 or via the user processing system.

[0079] At step 445, the user device retrieves the registration key from its memory using the index of the registration key received from the server processing system 310.

[0080] At step 450, the method 400 includes the user device 330 generating and displaying a user interface 640 on the user device 330, wherein the user interface 640 of the software application 335 presents a graphical representation of the registration key 620 corresponding to the index and an identifier reference 650. Referring to Figure 6B, there is shown an example user interface 640 which presents the identifier reference 650 as a numerical display including ten keys for the digits 0 to 9 in ascending order. As shown in Figure 6B, the registration key 620 can include a corresponding number of random alphabetic characters. Preferably, as shown in Figure 6, the user interface 640 presents each registration key portion 630 adjacent a

corresponding identifier reference portion 660 such that each digit of the identifier reference 650 aligns with and is adjacent to the corresponding key portion 630 of the key 620. It will be appreciated that other configurations of alphanumerical data can be used for the key 620 and the identifier reference 650. It will also be appreciated that various alternative identifier reference portions could be used other than digits, for example numbers, symbols or the like.

[0081] At step 455, the method 400 includes the user 350 determining the registration code using the presented registration key and the desired personal identifier. In one form, the user can visually inspect the interface 640 presented and determine the registration code. For example, for each digit of the desired personal identifier, the user 350 identifies the key portion 630 which corresponds to this identifier reference portion 660 in the identifier reference 650. The key portions 630 are concatenated together by the user to form the registration code. Based on the interface presented in Figure 6B, if the user's desired personal identifier is " 1032", the code for the user 350 is "QRSL". In the event that the user 350 is using the user device 330 to set the personal identifier, the user can interact with an input device of the user device 330 to input the registration code into the code request interface wherein the code indirectly represents the desired personal identifier. Alternatively, if the user is using the user processing system 340 to obtain access to the secure environment 325, the user can input, using an input device of the user processing system 340, the registration code into the code request interface presented by the user processing system 340.

[0082] At step 460, the method 400 includes the user device 330 or the user processing system 340 transferring, to the server processing system 310, a response indicative of the registration code input by the user 350 into the code request interface. The code request interface presented by the user device 330 or user processing system 340 can include a submit button, wherein the registration code can be transferred from the user device 330 or user processing system 340 to the server processing system 310 via user selection of the submit button [0083] At step 465, the method 400 includes the server processing system 310 determining the personal identifier using the registration key stored temporarily. The personal identifier is temporarily stored by the server processing system for a very brief period of time until hashed values of expected codes have been created.

[0084] At step 470, the method 400 includes the server processing system 310 generating, using the personal identifier, an expected code for each key of the plurality of keys which are stored temporarily. Each expected code has a corresponding index which corresponds with the corresponding key from the plurality of keys. As such, the index provides correspondence between each key and each expected code.

[0085] At step 475, the method 400 includes the server processing system 310 generating a hash value for each expected code of the plurality of codes. In particular, each expected code is provided to a hashing algorithm together with a salt value associated with the user 350, wherein the hashing algorithm is executed by the server processing system 310 to generate each hash value of each expected code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5 or variants thereof. It will be appreciated that the hashing algorithm can utilise commutative cipher techniques such that the personal identifier does not need to be identified by the server processing system 310.

[0086] At step 480 the method 400 includes the server processing system 310 storing the hash values of the expected codes in the server accessible memory 315, preferably associated with the user account in the database. Advantageously, the server processing system 310 never permanently stores the personal identifier of the user, nor does the server processing system 310 receive data directly indicative of the personal identifier, thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access.

[0087] At step 485, the method 400 includes the server processing system 310 transferring the remaining plurality of keys (i.e. the plurality of keys excluding the registration key) to the user device for storage in memory of the user device. The plurality of keys are stored in association with the plurality of indexes to form a plurality of indexed keys. [0088] At step 490, the method 400 includes deleting, from the server accessible memory 315 and prior to receiving a request to authenticate the user, the plurality of keys, the plurality of expected codes, the personal identifier and the registration code. In particular, the plurality of keys, the plurality of expected codes, the registration code and the personal identifier are permanently deleted from memory which is accessible by the server processing system 310. This contrasts to PCT/AU2014/050024 where at least the plurality of keys were maintained in the server accessible memory. The portions of memory which stored this temporary data is written over with zeros in order to ensure the permanent deletion of these data items. By deleting this data, it is not possible for people who have access to the server processing system, such as an employee, to determine the personal identifier of the user as no data stored by the server processing system can be used to reversely determine the personal identifier of the user.

[0089] The indexes of the plurality of keys stored in memory of the user device 330 and the indexes of the expected responses have a one-to-one correspondence or mapping. As such, the respective sets of indexes act as a link between the plurality of keys stored only by the user device 330 and the expected responses stored in a hashed manner only by the server processing system 310 in server accessible memory 315. This configuration is highly advantageous as it allows for the personal identifier of the user and the plurality of keys to be deleted and never stored by server processing system after registration. Furthermore, the plurality of keys and the personal identifier are not stored in server accessible memory 315, even temporarily, during the authentication process, making the system 300 extremely secure from security breaches by malicious users who may have access to the server accessible memory 315 during the authentication process. Furthermore, this arrangement ensures that duplicated copies of the plurality of keys do not exist in the system but rather only a single instance of the plurality of keys is stored in memory of the user device. As will be described in more detail below, due to the plurality of keys and the hashed values of the expected responses being distributed and never stored on the same device after registration is complete, significant security advantages are achieved. If the server processing system 310 is compromised, it is still not possible for a malicious entity to determine the user's personal identifier based solely on the stored hashed values of the expected responses. Furthermore, even if an entity were able to obtain access to both the user submitted response and the expected response stored in server accessible memory 315, it would still not be possible for the malicious entity to determine the user's personal identifier based on this data due to the distributed storage of the plurality of keys and the hashed values of the expected responses between the memory of the user device 330 and the server accessible memory 315.

[0090] It will be appreciated that the server processing system 310 may provide a first and second registration key with respective indexes to the user device 330 and then repeat steps 440 to 460 to enable two registration codes to be transferred to the server processing system 310. In particular, the server processing system 310 can transfer to the user device 330 (or the user via the user processing system 340 if the user device 330 is not in communication with the server processing system 310) another index 610 which is different to the initial index. The server processing system 310 then determines, using the first and second registration keys temporarily stored in memory, that the personal identifier matches for each registration code. The first and second registration codes are then permanently deleted from the server accessible memory in step 490 in this particular embodiment. In the event that the personal identifiers do not match, this indicates that the user 350 has incorrectly indicated non-congruent desired personal identifiers. The registration process thereby ends or the user 350 is requested to repeat the registration process again.

[0091] Referring to Figure 5 there is shown a flowchart representing an example method 500 of the server processing system 310 authenticating a user 350 attempting to access the secure environment 325 hosted by the secure environment processing system 320.

[0092] In particular, at step 505, the method 500 includes the user 350 operating the user processing system 340 or the user device 330 to transfer a request to access the secure environment 325 from the secure environment processing system 320. The request may be submitted via a web-browser, web-enabled application or the like.

[0093] At step 510, the method 500 includes the secure environment processing system 320 transferring an authentication request to the server processing system 310 to authenticate the user 350. The authentication request is indicative of the user requesting access to the secure environment. In a preferable form, the secure environment processing system 320 may digitally sign the request using a digital certificate verifying the identity of the secure environment processing system 320 to the server processing system 310. The server processing system 310 may then facilitate verification of the identity of the secure environment processing system 320 based on the digitally signed request to ensure the request has been received from an identifiable entity. The server processing system 310 records in the database 315 that an authentication request has been received for the user 350 and associates a timestamp with this request.

[0094] In response to the request to access the secure environment 325 from the secure environment processing system 320, the secure environment processing system 320 transfers to the requesting device 330 or 340 an interface including the code request interface hosted by the server processing system 310. The code request interface may be presented via a web-browser, web-enabled application or the like.

[0095] As step 515, the method 500 includes the user 350 interacting with the software application 335 of user device 330 to transfer an index request to the server processing system 310, such that the server processing system selects of an index 610 of a key 620 from the plurality of keys 600 stored only in memory of the user device for authenticating the user 350. In a preferable form, the server processing system 310 is required to receive the index request from the user 350 within a temporal threshold period, otherwise the server processing system 310 will send an authentication response to the secure environment processing system 320 indicating that the user 350 is not authenticated to access the secure environment 325. To send the request, the user 350 may launch the software application 335 on the user device 330 to initiate the transfer of the index request. At this time, the user device 330 may also digitally sign the index request by using a private key of the user's digital certificate to enable the server processing system 310 to verify the user's identity using the corresponding public key. In the event that the digital signature does not successfully verify the identity of the user 350, the server processing system 310 can transfer an authentication response to the secure environment processing system 320 indicating that the user 350 is not authenticated to access the secure environment 325.

[0096] At step 520, the method 500 includes the secure environment processing system 320 transferring, to the software application of the user device 330 associated with the user 350, data indicative of the index 610 of the selected key 620 from the plurality of keys only stored in memory of the user device 330. The server processing system 310 records in the user account a challenge being issued indicative of the selected index 610. As discussed previously, in the event that the user device 330 is not in data communication with the server processing system 310, the server processing system 310 can transfer data indicative of the selected index 610 to the user processing system 340 for presentation to the user 350. The user 350 can then manually input into a prompt displayed by the software application 335 the presented index via an input device of the user device 330 such that the user device 330 has successfully received the index. The user 350 may be required to interact with the user processing system 340 to request transfer of the index 610 to the user processing system 340.

[0097] Optionally at step 522, the method 500 includes the user device 330 performing a security check. In particular, the software application 335 determines the one or more user device characteristics to generate the user device profile as previously discussed earlier in this document. The software application 335 then compares the newly generated user device profile against the user device profile stored in memory of the user device 330. In the event of a successful comparison, the method proceeds to step 525, otherwise the method ends. This process can identify if tampering has occurred to the user device 330.

[0098] At step 525, the method 500 includes the software application 335 of the user device 330 retrieving from local memory the key 620 corresponding to the received index 610.

[0099] At step 530, the method 500 includes the software application 335 of the user device 330 generating and displaying a user interface 600 on the user device 330, wherein the user interface 600 presents a graphical representation of the key 620 and the identifier reference 650. This process is performed similarly to step 450 discussed above

[0100] At step 535, the method 500 includes the user 350 using the user interface 640 of the software application 335 presented by user device 330 to determine the code. The step is performed similarly to step 455 discussed above except the user inputs, via the code request interface, key portions that correspond to the portions of the set personal identifier rather than the desired personal identifier.

[0101] At step 540, the method 500 includes the user processing system 340 or the user device 330 transferring, via the code request interface and to the server processing system 310, data indicative of the code input by the user 350. For clarity, the code input by the user is referred to as the user submitted code.

[0102] The server processing system 310 may be configured to determine if the challenge response has been received within a temporal threshold period of the initial authentication request being received and/or the challenge request being issued. In the event that the response has not been received within the temporal threshold period, the server processing system 310 may transfer an authentication response to the secure environment processing system 320 indicating that the user is not authenticated for accessing the secure environment 325.

[0103] At step 545, the method 500 includes the server processing system 310 determining a hash value of the user submitted code. In particular, the server processing system 310 provides input variables of the received user submitted code and a salt value associated with the user 350 into a hashing algorithm executed by the server processing system 310 to generate the hash value of the user submitted code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5 or variants thereof. It will be appreciated that the hashing algorithm can utilise commutative cipher techniques such that the personal identifier does not need to be identified by the server processing system 310.

[0104] At step 550, the method 500 includes the server processing system 310 comparing the determined hash value of the user submitted code against the respective stored hash value, from the plurality of stored hash values, of the expected code based on the respective index 610. Advantageously, the server processing system 310 never obtains or receives the personal identifier of the user thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access. Furthermore, advantageously the server accessible memory 315 does not store the plurality of keys whilst attempting to authenticate the user. This is highly advantageous. For example, if malware could infect the server processing system, it may be possible to attempt to determine the personal identifier of the user using the plurality of keys in combination with the user submitted code. As the plurality of keys are deleted from the server accessible memory 315 at the end of the registration process and prior to the server processing system 310 receiving an authentication request, the plurality of hashed values of the expected codes stored in the server accessible memory cannot be used in combination with the user submitted code to determine the user's personal identifier. As the user device also does not store the personal identifier in memory, the user device being compromised (e.g. infected by malware) does not result in the personal identifier being reverse engineered. Furthermore, this arrangement ensures that duplicated copies of the plurality of keys do not exist in the system but rather only a single instance of the plurality of keys is stored in memory of the user device 330. Due to the plurality of keys and the hashed values of the expected responses being distributed and never stored on the same device after registration is complete, significant security advantages are achieved. If the server processing system 310 is compromised, it is still not possible for a malicious entity to determine the user's personal identifier based solely on the stored hashed values of the expected responses. Furthermore, even if an entity were able to obtain access to both the user submitted response and the expected response stored in server accessible memory 315, it would still not be possible for the malicious entity to determine the user's personal identifier based on this data due to the distributed storage of the plurality of keys and the hashed values of the expected responses between the memory of the user device 330 and the server accessible memory 315.

[0105] At step 555, the method 500 includes the server processing system 310 generating and transferring an authentication response to the secure environment processing system 320, wherein the authentication response is indicative of whether the user 350 is authenticated to access to the secure environment 325 based upon the comparison in step 550. In particular, in the event that the hash value of the user-submitted code does not match the stored hash value of the expected code in step 550, the server processing system 310 generates and transfers an authentication response indicating that the user 350 should not be granted access to the secure environment 325 controlled by the secure environment processing system 320. However, in the event that the hash values match in the comparison performed in step 560, the server processing system 310 generates and transfers an authentication response indicating that the user 350 should be granted access to the secure environment 325 controlled by the secure environment processing system 320.

[0106] At step 560, the method 500 includes the server processing system 310 recording in the user account that the challenge response has been received and the authentication response has been transferred to the secure environment processing system 320.

[0107] It will be appreciated that if the user 350 incorrectly enters the code via the user processing system 340, the server processing system 310 may re-issue one or more further challenge requests, wherein a unique and different index 610 is transferred in each challenge request. Upon a threshold number of incorrect codes being identified by the server processing system 310 for the single authentication request by the secure environment processing system 320, the server processing system 310 can generate and transfer an authentication response to the secure environment processing system 320 indicating that the user 350 should not be granted access to the secure environment 325.

[0108] It will be appreciated that the user can be authenticated multiple times for multiple sessions where authentication is required. Each time the user needs to be authenticated to access the secure environment, a new index is selected by the server processing system to transfer to the user. Each index is preferably used only once. Thus, the server processing system maintains a record of the indexes that have been used such that no index is reused.

[0109] In an optional form, the server processing system 310 does not necessarily transfer the index of the selected key to the user device 330. For example, the user may be told, for example over the telephone or other communications device, the selected key by a computer or representative of the authentication system. The user can then input the index which they are told into the application 335 of the user device 330, wherein the user device 330 retrieves from its memory the selected key based on the input index. The selected key is then presented within the interface per Figure 6B as described earlier.

[0110] In a further optional form, the user may provide the code together with the index to the server processing system 310 via a telephone or other communication device. For example, the user may be presented with a key, from the plurality of keys, and the index by the user device 330 as per Figure 6B. The user may then determine the code as previously discussed. The user may then communicate the determined code together with the index which is then provided to the server processing system 310. In one form, an operator or a voice recognition system may receive the code together with the index which are then input to the server processing system for authentication as described above.

[0111] Referring to Figure 7 there is shown a flowchart representing a method 700 of a user 350 transferring a reset request to the server processing system 310.

[01 12] In particular, at step 705, the method includes the user 350 transferring a reset request to the server processing system 310 to reset the user's personal identifier. The reset request can be sent from the user processing system 340 or the user device 330 potentially via the software application 335. The reset request can include data which can be used by the server processing system 310, or the 1DV, to verify the identity of the user. [0113] At step 710, the server processing system 310 facilitates verification of the user's identity. In response to successful verification of the user's identity, a code request interface, hosted by the server processing system 310, is presented to the user 350 via the user device 330 or the user processing system 340 and the method 700 proceeds to step 712, otherwise the resetting process ends.

[0114] At step 715, the method 700 includes the server processing system 310 generating a plurality of new keys. The plurality of new keys are stored temporarily in memory 315 accessible by the server processing system 310. Each new key has a corresponding index.

[0115] At step 720, the method 700 includes the server processing system transferring to the user device data indicative of a selected one of the new keys which is stored in the memory 315 accessible by the server processing system 310. For the purposes of clarity, the selected key is referred to as a reset key. The data transferred to the user device is also indicative of the index of the reset key.

[0116] At step 725, the method 700 includes the user device 330 storing the reset key and associated index in memory of the user device 330.

[0117] At step 730, the user 350 transfers an index request to the server processing system 340. In one form, the index request may be transferred via the user interaction with the software application 335 of the user device 335. Alternatively, the index request can be transferred to the secure environment processing system 320 via the user processing system 340 which is then relayed to the server processing system 310.

[01 18] At step 735, the method 700 includes the server processing system 310 transferring, to the user device 330, the index 610 of the reset key 620. As discussed previously, in the event that the user device 330 is not in data communication with the server processing system 310, the server processing system 310 can transfer data indicative of the index 610 of the reset key 620 to the user processing system 340 for presentation to the user 350. The user 350 can then manually input the presented index 610 via an input device of the user device 330 into the software application 335 such that the user device 330 has successfully received the index 610. The user may be required to interact with the user processing system 340 to request transfer of the index 610 to the user processing system 340. [0119] The server processing system 310 can store in the server accessible memory 315 a record of the reset request being received and the index 610 being transferred to the user, wherein a timestamp is recorded in the database 315 indicative of the time which each of these events occurred.

[0120] At step 740, the method 700 includes the software application 335 of the user device 330 retrieving from local memory the reset key 620 corresponding with the received index 610 stored in the memory of the user device 330.

[0121 ] At step 745, the method 700 includes the user device 330 generating and displaying a user interface 600 on the user device 330, wherein the user interface 600 presents a graphical representation of the reset key 620 and the identifier reference 650. This step is performed similarly to step 450 discussed above.

[0122] At step 750, the method 700 includes the user 350 using the user interface presented by the user device to determine the reset code. For example, for each digit/character/symbol of the new personal identifier, the user 350 identifies each key portion 630 which corresponds to the respective digit/character/symbol in the identifier reference 650 and concatenates the

corresponding key portions 630 together to form the reset code. Based on the interface presented in Figure 6B, if the user's new personal identifier is "5732", the reset code input by the user 350 is "XKSL".

[0123] At step 755, the method 700 includes the user processing system 340 or the user device transferring, to the server processing system 310 via the code request interface, a response indicative of the reset code submitted by the user 350.

[0124] The server processing system 310 may be configured to determine if the reset code has been received within a temporal threshold period of the reset request or the transfer of the index. In the event that the reset code has not been received within the temporal threshold period, the server processing system 310 may refuse to reset the personal identifier based on the received reset code.

[0125] At step 760, the method 700 includes the server processing system 310 determining the new personal identifier using the reset key temporarily stored in memory accessible by the server processing system 310. [0126] At step 765, the method 700 includes the server processing system 310 generating and temporarily storing in memory 315 a plurality of new expected codes corresponding to the plurality of new keys, excluding the reset key, based on the new personal identifier.

[0127] At step 770, the method 700 includes the server processing system 310 generating and storing in server accessible memory 315 a plurality of hash values of the plurality of new expected codes. In particular, for each new expected code, the server processing system 310 provides input variables of the new expected code and a salt value associated with the user 350 into a hashing algorithm executed by the server processing system 310 to generate the hash value of the respective new expected code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5, or variants thereof. The plurality of hash values of the plurality of expected codes is associated with the user account, wherein each hash value of one of the plurality of expected codes is associated with the respective index used for the corresponding key. It is also possible that the previous has values of the expected codes are marked as to no longer being available for use or can be deleted from memory.

[0128] At step 775, the method 700 includes the server processing system 310 transferring the new plurality of keys (excluding the reset key) to the user device 330 for storage in memory. The plurality of keys are indexed.

[0129] At step 780, the method 700 includes the server processing system 310 deleting the data stored temporarily in the server accessible memory 315. In particular, the new personal identifier, the plurality of keys and the plurality of expected codes are permanently deleted from memory which is accessible by the server processing system 310. The portions of memory 315 which stored this temporary data is written over with zeros by the server processing system 310 in order to ensure the permanent deletion of these data items.

[0130] Advantageously, the server processing system 310 never permanently stores the new personal identifier of the user, nor does the server processing system 310 receive data in the future directly indicative of the new personal identifier, thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access. Furthermore, this arrangement ensures that duplicated copies of the plurality of new keys do not exist in the system but rather only a single instance of the plurality of new keys is stored in memory of the user device 330. As will be described in more detail below, due to the plurality of new keys and the hashed values of the expected responses being distributed and never stored on the same device after registration is complete, significant security advantages are achieved. If the server processing system 310 is compromised, it is still not possible for a malicious entity to determine the user's personal identifier based solely on the stored hashed values of the expected responses. Furthermore, even if an entity were able to obtain access to both the user submitted response and the expected response stored in server accessible memory 315, it would still not be possible for the malicious entity to determine the user's personal identifier based on this data due to the distributed storage of the plurality of keys and the hashed values of the expected responses between the memory of the user device 330 and the server accessible memory 315.

[0131] It will be appreciated that steps 735 to 755 may be repeated in order to confirm the user 350 has indirectly identified the same new personal identifier. In the event that the new personal identifier determined based on a first and second reset code match, the hash values of the new expected codes is generated and stored in the user account.

[0132] It will be appreciated that although parts of the above process have been described in relation to the user interacting with a user processing system 340, it is possible that the user may use the user device 330 to perform the same steps.

[0133] Referring to Figure 8 there is shown a further system diagram of an example system 800 for authenticating a user attempting to access a secure environment. For the purposes of clarity, like components between system 800 and system 300 use the same reference numbers in order to avoid reduplicating the functional description. System 800 differs from system 300 with the provision of a hardware security module (HSM) 810 which is in communication with the database 315 and server processing system 310. Due to the tamper-proof nature of the hardware security module, the temporary storage of data during registration is handled by the hardware security module 810.

[0134] Referring to Figure 9 there is shown a flowchart illustrating a method for user registration using the system 800. In particular, step 905, 910 and 915 of method 900 are performed the same as steps 405, 410 and 415. [0135] At step 920, the method 900 includes the server processing system 310 instructing the hardware security module 810 to generate a plurality of keys for the user.

[0136] At step 922, the method 900 includes the hardware security module 810 generating the plurality of keys for the user. The plurality of keys are stored temporarily by the hardware security module 810. The plurality of keys are indexed such that each key has an associated index.

[0137] At step 924, the method 900 includes the hardware security module 810 transferring one of the plurality of keys with the associated index to the server processing system 330. The key that is transferred to the server processing system 330 is the registration key.

[0138] At step 925, the method 900 includes the server processing system 310 transferring the registration key and preferably the associated index to user device 330 for storage in memory.

[0139] The method 900 then proceeds to steps 930, 935, 940, 945, 950, 955, 960 which are performed the same as steps 430, 435, 440, 445, 450, 455, 460.

[0140] At step 962, the method 900 includes the server processing system 310 instructing the hardware security module to generate a plurality of expected responses based on the registration code which is forwarded to the hardware security module 810.

[0141 ] At step 965, the method 900 includes the hardware security module 810 determining the personal identifier using the registration key stored temporarily by the hardware security module. The personal identifier is temporarily stored by the hardware security module 810 for a very brief period of time until hashed values of expected codes have been created.

[0142] At step 970, the method 900 includes the hardware security module 810 generating, using the personal identifier, an expected code for each key of the plurality of keys which are stored temporarily by the hardware security module 810. Each expected code has a

corresponding index which corresponds with the corresponding key from the plurality of keys. As such, the index provides a correspondence or link between each key and each expected code.

[0143] At step 975, the method 900 includes the hardware security module 310 generating a hash value for each expected code. In particular, each expected code is provided to a hashing algorithm together with a salt value associated with the user 350, wherein the hashing algorithm is executed by the hardware security module 810 to generate each hash value of each expected code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5 or variants thereof.

[0144] At step 980 the method 900 includes the hardware security module 810 storing the hash values of the expected codes in the user account in the server accessible memory 315.

Advantageously, the hardware security module 810 never permanently stores the personal identifier of the user, nor does the server processing system 310 receive data directly indicative of the personal identifier, thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access.

[0145] At step 983, the method 900 includes the hardware security module 810 forwarding the remaining of plurality of indexed keys (i.e. the plurality of indexed keys excluding the registration key) to the server processing system 310.

[0146] At step 985, the method 900 includes the server processing system 310 transferring the remaining plurality of indexed keys (the plurality of indexed keys excluding the registration key) to the user device for storage in memory of the user device. The plurality of keys are stored in association with the plurality of indexes, wherein each index of a respective key corresponds to the index of the hash valued of the respective expected response for the respective key.

[0147] At step 990, the method 900 includes deleting the plurality of keys, the plurality of expected codes, the personal identifier and the registration code from memory of the server processing system and the hardware security module. In particular, the plurality of keys, the plurality of expected codes, the registration code and the personal identifier are permanently deleted. This contrasts to PCT/AU2014/050024 where at least the plurality of keys were maintained in the server accessible memory after registration. The portions of memory which stored this temporary data is written over with zeros in order to ensure the permanent deletion of these data items. By deleting this data, it is not possible for people who have access to the server processing system, such as an employee, to determine the personal identifier of the user as no data stored by the server processing system or in the hardware security module can be used to reversely determine the personal identifier of the user.

[0148] In a particular variation on the authentication process described with relation to Figure 5 and method 500, it is possible that instead of the server processing system 310 transferring an index of a selected key to the user 350 or the user device 330, the user 350 can determine a code presented by the user device 330 and transfer both the determined code and the index of the presented key to the server processing system 310, preferably in a single transaction. For example, the user may interact with the user device 330 requesting random selection of an available key from the plurality of available keys stored in memory of the user device 330. In one particular form, the user could open the application 335 and press a user interface button which initiates receipt of a key selection request by the user device 330 resulting in the user device 330 randomly selecting one of the keys from the plurality of keys which has not been previously used. The key randomly selected by the user device 330 is the selected key. As a result, the user device 330 presents the interface as shown in Figure 6B which may also present the index of the selected key. The user then determines the user submitted code as previously described and transfers to the server processing system 310, potentially via the secure environment processing system 320, the determined user submitted code and the index of the randomly selected key that was selected and presented via the user device 330. In one example, the user submitted code and the index of the selected key can be input via the code request interface presented by the user processing system 340 and transferred to the server processing system 310. The server processing system 310 can then use the received corresponding index of the selected key to identify the corresponding hashed value stored in server accessible memory 315 for use in attempting to authenticate the user per the steps previously outlined in method 500.

[0149] Referring to Figure 10 there is shown a schematic of another example of a user device 330 presenting a graphical representation of a key and an identifier reference. The user device 330 is a computerised device having a processor 1010, a memory, 1020, an input device 1030 and an output device 1040 coupled together by a bus 1070 as shown in Figure 1 1.

[0150] The user device 330 also comprises a power source 1050 such as a battery which can be rechargeable via a recharging interface 1055. The recharging interface 1055 can include a physical port which allows a recharging cable or connector to couple with the user device 330 to allow recharging of the power source 1050. In one form, the user device 330 may be coupled to a dock which includes a recharging connector for recharging the power source 1050. In one form, the recharging port may be provided in the form of a Universal Serial Bus (USB) port although other types of ports can be used. As discussed below, the recharging port can also act as a communication port for receiving and transferring data via a wired medium such as a USB cable or the like. In another option, the power source 1050 can be recharged via Near Field Communication (NFC) which is convenient if the user device 330 is located proximate a user processing system, such as a smart phone, with FC capability.

[0151] The embodiment of the user device 330 shown in Figure 11 further comprises a communication interface 1060. In one form, the communication interface 1060 can include one or more wireless communication devices to enable short range communication. The one or more wireless communication devices can communicate using Bluetooth (e.g. Bluetooth v 5.0), Near Field Communication, Wi-Fi, and ZigBee (i.e. IEEE 802.15.4). The communication interface 1060 can additionally or alternatively include one or more physical communication ports. As discussed above, the user device 330 can include a USB port which a USB cable can couple thereto to enable communication to the user processing system 340.

[0152] The user device 330 can include a microcontroller providing the processor 1010, memory 1020 and the communication interface 1060. In one form, the microcontroller is provided in the form of a system on a chip (SOC) assembly. One example includes the nRF52840 available from Nordic Semiconductor ASA. A specification of the nRF52840 is available at http://infocenter.nordicsemi.eom/pdf/nRF52840_OPS_vO.5.pdf which is herein incorporated by reference. Preferably, the microcontroller includes an additional processor provided in the form of a cryptographic co-processor. The nRF52840 available from Nordic Semiconductor ASA implements an ARM® CryptoCell-310 cryptographic co-processor on-chip for building trustworthy applications with robust industry grade levels of security.

[0153] The memory 1020 of the user device 330 can include volatile and non-volatile computer storage medium. In one form, the non-volatile computer storage medium can comprise flash memory.

[0154] The display 1040 of the user device 330 preferably extends a majority of a face of the user device 330. In one form, the display 1040 can be provided in the form of an electronic paper display in order to minimise power consumption. The input device 1030 of the user device 330 can include one or more buttons. However, in a preferably form, the display 1040 can dually act as an input device 1030, wherein the display is touch sensitive. In one form, the input device and display 1030, 1040 are provided in the form of a touch sensitive electronic paper display.

[0155] In one form, the user device 330 can have the size of a credit card and have a thickness less than 1 centimetre and preferably less than 5 millimetres. In one form, the casing of the user device can include a hole or coupling element or mechanism to allow the user device 330 to be tethered or coupled to a lanyard or the like.

[0156] Figure 12 is a system diagram comprising the user device 330 of Figure 1 1. In one form, the user device 330 is in communication with the server processing system 310 via the user processing system 340 which acts as an intermediary processing system. The user processing system 340 is a physically separate device to the user device 330 but can be in data

communication via the communication interface 1060. The user processing system 340 can be a laptop processing system, a traditional personal computer, a tablet processing system, a smart phone device or the like. The user processing system 340 can have stored in memory a companion application to provide network connectivity to communicate with the server processing system 340.

[0157] The user device 330 of Figures 11 and 12 can be registered in the manner described in relation to Figure 4 representing method 400. However, it will be appreciated that as the user device 330 has a short-range communication capability, data received and transferred by the user device 330 is via the user processing system 340.

[0158] Furthermore, the user device 330 of Figures 11 and 12 can be used to authenticate the user 350 as described in relation to Figure 5 representing method 500. However, it will be appreciated that as the user device 330 has a short-range communication capability, data received and transferred by the user device 330 is via the user processing system 340 which can be in data communication with the server processing system via one or more networks which can include the Internet. [0159] Furthermore, the user device 330 of Figures 11 and 12 can be used in the method 700 to reset the personal identifier of the user 350. However, it will be appreciated that as the user device 330 has a short-range communication capability, data received and transferred by the user device 330 is via the user processing system 340.

[0160] In one form, the user device 330 is configured to store encrypted data with a plurality of layers of encryption. The user device 330 or the user processing system 340 includes an executable application for facilitating at least one of encryption and decryption. In response to the server processing system 310 successfully authenticating the user using the above described authentication method 400, the server processing system 310 can transfer to the user device 310, a server provisioned cryptographic key. The user device 330 also determines a user device cryptographic key based on the unique device profile identifying the user device 330. In the event that data is to be decrypted, the method includes decrypting the layers of encryption of the encrypted data stored by the user device 330 using the server provisioned cryptographic key, the user device 330 cryptographic key and the executable application. In the event that data is to be encrypted and stored in the user device 330, the method includes encrypting data with the plurality of layers of encryption using the executable application, the user device cryptographic key and the server provisioned cryptographic key.

[0161] The executable application may relate to any form of application which requires cryptographic functionality. For example the executable application may relate to a

cryptocurrency wallet, a password vault/manager, a U2F Security Key, and/or encrypted storage.

[0162] In one form, the executable application enables transfer of cryptocurrency to another entity using a private key stored by the user device 330. The executable application enables selection of the entity from a whitelist presented in a user interface displayed by the user device 330 or the user processing system 340. The whitelist is indicative of verified entities stored in the server accessible memory 315. In an alternate arrangement, the executable application transfers data indicative of the entity to the server processing system 310. The server processing system 310 compares the entity against the whitelist of verified entities stored in the server accessible memory 315. The server processing system 310 then transfers to the user device 330 or the user processing system 340 executing the executable application, an indication of a result of the comparison of the entity against the whitelist. [0163] Figure 13 is a block diagram schematic of a further example user device330. A majority of the components of the user device 330 represented by Figure 13 are the same as that discussed in Figure 12. Therefore, for the purposes of clarity, these components will not be redescribed, but it should be appreciated that those components shown in both Figure 12 and 13 operate in the same manner. The user device 330 of Figure 13 does not include an operational communication device. As such, the non-volatile memory of the user device 330 has stored therein the plurality of keys prior to the user device 330 being provided to the user. In one form, the user device 330 initially includes an operational communication interface having a i/o interface or physical communication port, such as a USB port. The plurality of keys are generated by the server processing system 310 as described above and transferred to the user device 330 for storage in the non-volatile memory 1020, wherein the temporary data described previously is deleted from the server accessible memory 315. The communication functionality of the user device 330 is then disabled. In one form, this may include filling the communication port with a curable substance. The user device 330 is encased and sealed in a hard case so as to prevent enabling the communication interface of the user device 330. The user device 330 can then be provided to a user for registration.

[0164] A method of registering the user device described in relation to Figure 13 will now be described in relation to the flowchart shown in Figure 14.

[0165] Referring to Figure 14 there is shown a flowchart representing an example method 400 of a user 350 registering with the server processing system 310 for authenticating the user 350 when accessing the secure environment 325 controlled by the secure environment processing system 320. It will be appreciated that method 1400 relates to the registration of the user device 350 which is preloaded with the plurality of keys.

[0166] In particular, at step 1405, the method 1400 includes the user 350 transferring a registration request to the server processing system 310. The registration request may be transferred user processing system 340 operated by the user 350. The registration request can be indicative of identity data which attempts to prove the identity of the user 350, and a unique device identifier indicative of the user device 330. The identity data may be indicative of credit card numbers, passport numbers, utility bills, addresses and other like information. In particular embodiments, the unique device identifier may be generated by a software application 335 stored in memory of the user device 330 when in an unregistered mode. The software application 335 determines a number of characteristics of the user device 330 and uses the determined characteristics to generate the unique device profile. The determined characteristics may include one or more characteristics of hardware of the user device 330 (such as the CPU, memory), a MAC address of the user device 330, a software profile which may be indicative of a digital certificate associated with the user and one or more identifiers associated with the user device 330. The software application 335 applies a hashing algorithm to the determined characteristics to generate the unique device profile in the form of a hash value. The unique device profile is then displayed via the display of the user device. The user then provides the unique device profile to the user processing system 340 which is forwarded to the server processing system 310 for storage. The unique device profile acts as a device signature to uniquely identify the user device 330 based on multiple characteristics of the user device 330. In particular embodiments, the unique device profile is also stored in memory of the user device 330 and may be used for implementing a security check.

[0167] At step 1410, the method 1400 includes the server processing system 310 facilitating verification of the identity of the user 350 based on the identity data. In particular, the server processing system 310 may utilise an identity verifier (IDV) in an attempt to verify that the set of information is associated with a single user. In response to a positive verification, the method 1400 proceeds to step 1415. Otherwise the server processing system 310 may request further identification information from the user 350.

[0168] At step 1415, the method 1400 includes the server processing system 310 generating a user account in the memory 315 associated with the server processing system 310. The memory 315 is preferably a database accessible by the server processing system 310. The server processing system 310 associates the user device 330 with the user account based on the unique device identifier which in particular embodiments is the unique device profile.

[0169] At step 1420, the method 1400 includes the server processing system 310 transferring a code request to the user processing system 340. The code request can include a code request interface for presentation to the user requesting that the user input a code indirectly representing the desired personal identifier. The code request interface may be presented via a web-browser, web-enabled application or the like. The code request interface may be a webpage or a portion of a webpage that is presented to the user 350. For example, the code request interface may be a frame or window located within a webpage hosted by the secure environment processing system 320, wherein the code request interface can be generated and hosted by the server processing system 325. As will be discussed in detail below, the code that is input by the user 350 into the code request interface is transferred to the server processing system 310. In an optional form, the server processing system 310 may be configured to randomly select a key (herein a registration key) from the plurality of keys stored in server accessible memory 315, wherein the code request is indicative of the corresponding index of the registration key. The index of the registration key can then be presented via the display of the user device 330 to the user 350. However, as discussed below, it is possible that the code request does not require an index to complete registration.

[0170] At step 1425, the user interacts with the user device 330 to request presentation of the registration key from the plurality of keys stored in non -volatile memory 1020 of the user device 330. As discussed above, the code request may be indicative of the index of the selected key to be treated as the registration key. In this event, the user may input, via the input device 1030 of the user device 330, the index, wherein the processor 1010 of the user device 330 retrieves from memory 1020 the registration key using the input index and displays the registration key via the display. However, if no index is input to the user device 330, the user device 330 can randomly select a key from the plurality of keys and present the index of the registration key via the display as discussed in the next step.

[0171] The user device 330 may display the registration key in a user interface 640 on the user device 330, wherein the user interface 640 includes a graphical representation of the registration key 620 corresponding to the index and an identifier reference 650. Referring to Figure 6B, there is shown an example user interface 640 which presents the identifier reference 650 as a numerical display including ten keys for the digits 0 to 9 in ascending order. As shown in Figure 6B, the registration key 620 can include a corresponding number of random alphabetic characters. Preferably, as shown in Figure 6, the user interface 640 presents each registration key portion 630 adjacent a corresponding identifier reference portion 660 such that each digit of the identifier reference 650 aligns with and is adjacent to the corresponding key portion 630 of the key 620. It will be appreciated that other configurations of alphanumerical data can be used for the key 620 and the identifier reference 650. In the event that a registration key was selected at random by the user device 330, the user interface also presents the index of the registration key. [0172] At step 1430, the method 1400 includes the user 350 determining the registration code using the presented registration key and the desired personal identifier. In one form, the user can visually inspect the interface 640 presented and determine the registration code. For example, for each digit/character/symbol of the desired personal identifier, the user 350 identifies the key portion 630 which corresponds to this identifier reference portion 660 in the identifier reference 650. The key portions 630 are concatenated together by the user to form the registration code. Based on the interface presented in Figure 6B, if the user's desired personal identifier is " 1032", the code for the user 350 is "QRSL". In the event that the user 350 is using the user device 330 to set the personal identifier, the user can interact with an input device of the user device 330 to input the registration code into the code request interface wherein the code indirectly represents the desired personal identifier. Alternatively, if the user is using the user processing system 340 to obtain access to the secure environment, the user can input, using an input device of the user processing system 340, the registration code into the code request interface presented by the user processing system 340.

[0173] At step 1435, the method 1400 includes the user processing system 340 transferring, to the server processing system 310, a response indicative of the registration code input by the user 350 into the code request interface. The code request interface presented by the user processing system 340 can include a submit button, wherein the registration code can be transferred from the user processing system 340 to the server processing system 310 via user selection of the submit button. In the event, that the code request did not include an index of the registration key, the user can input via the code request interface displayed by the user processing system 340 the index of the registration key which is displayed by as part of the user interface on the display of the user device.

[0174] At step 1440, the method 1400 includes the server processing system 310 determining the personal identifier using the registration key which is stored temporarily in the server accessible memory 315. In the event that the index of the registration key was transferred to the server processing system 310, the server processing system 310 uses the received index to determine the registration key from the plurality of keys stored in the server accessible memory 315, which then enables the personal identifier to be determined and temporarily stored. The personal identifier is temporarily stored by the server processing system 310 for a very brief period of time until hashed values of expected codes have been created. [0175] At step 1445, the method 1400 includes the server processing system 310 generating, using the personal identifier, an expected code for each key of the plurality of keys which are stored temporarily. Each expected code has a corresponding index which corresponds with the corresponding key from the plurality of keys. As such, the index provides a correspondence between each key and each expected code.

[0176] At step 1450, the method 1400 includes the server processing system 310 generating a hash value for each expected code. In particular, each expected code is provided to a hashing algorithm together with a salt value associated with the user 350, wherein the hashing algorithm is executed by the server processing system 310 to generate each hash value of each expected code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5 or variants thereof. It will be appreciated that the hashing algorithm can utilise commutative cipher techniques such that the personal identifier does not need to be identified by the server processing system 310.

[0177] At step 1455 the method 1400 includes the server processing system 310 storing the hash values of the expected codes in the user account in the server accessible memory 315 which can be provided in the form of a database. Advantageously, the server processing system 310 never permanently stores the personal identifier of the user, nor does the server processing system 310 receive data directly indicative of the personal identifier, thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access.

[0178] At step 1460, the method 1400 includes deleting the plurality of keys, the plurality of expected codes, the personal identifier and the registration code from memory of the server processing system. In particular, the plurality of keys, the plurality of expected codes, the registration code and the personal identifier are permanently deleted from memory which is accessible by the server processing system 310. This contrasts to PCT/AU2014/050024 where at least the plurality of keys were maintained in the server accessible memory. The portions of memory which stored this temporary data is written over with zeros in order to ensure the permanent deletion of these data items. By deleting this data, it is not possible for people who have access to the server processing system, such as an employee, to determine the personal identifier of the user as no data stored by the server processing system can be used to reversely determine the personal identifier of the user.

[0179] At step 1465, the method 1400 includes the server processing system 310 generating and transferring a registration confirmation identifier to the user processing system 340.

[0180] At step 1470, the method 1400 includes the user inputting, via the input device 1030 of the user device 330, the registration confirmation identifier.

[0181] At step 1475, the method 1400 includes the user device 330 storing the registration confirmation number in the non-volatile memory 1020.

[0182] It will be appreciated that a first and second registration key may be presented such that steps 1420 to 1435 to enable two registration codes to be transferred to the server processing system 310. In particular, the server processing system 310 can transfer to the user device 330 (or the user via the user processing system if the user device 330 is not in communication with the server processing system 310) another index 610 which is different to the initial index. The server processing system 310 then determines, using the first and second registration keys temporarily stored in memory 315, that the personal identifier matches for each registration code. The first and second registration codes are then permanently deleted from the server accessible memory 315 in step 1460 in this particular embodiment. In the event that the personal identifiers do not match, this indicates that the user 350 has incorrectly indicated non-congruent desired personal identifiers. The registration process thereby ends or the user 350 is requested to repeat the registration process again.

[0183] Referring to Figure 15 there is shown a flowchart representing an example method of the server processing system 310 authenticating a user 350 attempting to access the secure environment 325 hosted by the secure environment processing system 320. The method 1500 is described with the user using the user device described in relation to Figure 13.

[0184] In particular, at step 1505, the method 1500 includes the user 350 operating the user processing system 340 to transfer a request to access the secure environment 325 from the secure environment processing system 320. The request may be submitted via a web-browser, web-enabled application or the like. [0185] At step 1510, the method 1500 includes the secure environment processing system 320 transferring an authentication request to the server processing system 310 to authenticate the user 350. The authentication request is indicative of the user requesting access to the secure environment. In a preferable form, the secure environment processing system 320 may digitally sign the request using a digital certificate verifying the identity of the secure environment processing system 320 to the server processing system 310. The server processing system 310 may then facilitate verification of the identity of the secure environment processing system 320 based on the digitally signed request to ensure the request has been received from an identifiable entity. The server processing system 310 records in the database 315 that an authentication request has been received for the user 350 and associates a timestamp with this request.

[0186] At step 1515, in response to the request to access the secure environment 325 from the secure environment processing system 320, the secure environment processing system 320 transfers to the user processing system 340 an interface including the code request interface hosted by the server processing system 310. The code request interface may be presented via a web-browser, web-enabled application or the like. In one form, the code request interface is indicative of an index selected by the server processing system for the user authentication process. The user 350 can then manually input the presented index via an input device of the user device 330 such that the user device 330 has successfully received the index. The user 350 may be required to interact with the user processing system 340 to request transfer of the index 610 to the user processing system 340.

[0187] Optionally at step 1520, the method 1500 includes the user device 330 performing a security check. In particular, the software application 335 executed by the user device 330 determines the one or more user device characteristics to generate the user device profile as previously discussed earlier in this document. The software application 335 then compares the newly generated user device profile against the user device profile stored in memory 1020 of the user device 330. In the event of a successful comparison, the method proceeds to step 525, otherwise the method ends. This process can identify if tampering has occurred to the user device 330.

[0188] At step 1525, the method 1500 includes the software application 335 of the user device 330 retrieving from local memory the key 620 corresponding to the received index 610. However, if the server processing system 310 did not provide an index for the selected key, the software application 335 randomly selected a key from the plurality of keys.

[0189] At step 1530, the method 1500 includes the software application 335 of the user device 330 generating and displaying a user interface 600 on the user device 330, wherein the user interface 600 presents a graphical representation of the key 620 and the identifier reference 650. This process is performed similarly to step 450 discussed above.

[0190] At step 1535, the method 1500 includes the user 350 using the user interface 640 of the software application 335 presented by user device 330 to determine the code. The step is performed similarly to step 455 discussed above except the user inputs, via the code request interface, key portions that correspond to the portions of the set personal identifier rather than the desired personal identifier.

[0191] At step 1540, the method 500 includes the user processing system 340 transferring, via the code request interface and to the server processing system 310, data indicative of the code input by the user 350. For clarity, the code input by the user is referred to as the user submitted code. In the event that the index for selecting one of the keys from the plurality of keys was not provided to the user processing system 340, the index of the key randomly selected by the user device is also input by the user into the code request interface and transferred to the server processing system 310.

[0192] The server processing system 310 may be configured to determine if the challenge response has been received within a temporal threshold period of the initial authentication request being received and/or the challenge request being issued. In the event that the response has not been received within the temporal threshold period, the server processing system 310 may transfer an authentication response to the secure environment processing system 320 indicating that the user is not authenticated for accessing the secure environment 325.

[0193] At step 1545, the method 1500 includes the server processing system 310 determining a hash value of the user submitted code. In particular, the server processing system 310 provides input variables of the received user submitted code and a salt value associated with the user 350 into a hashing algorithm executed by the server processing system 310 to generate the hash value of the user submitted code. Preferably, the hashing algorithm is a one-way hashing algorithm such as SHA-3, MD5 or variants thereof. It will be appreciated that the hashing algorithm can utilise commutative cipher techniques such that the personal identifier does not need to be identified by the server processing system 310

[0194] At step 1550, the method 1500 includes the server processing system 310 comparing the determined hash value of the user submitted code against the stored hash value of the expected code. Advantageously, the server processing system 310 never obtains or receives the personal identifier of the user thereby providing significant security benefits. These security benefits include, in some embodiments, an outcome where the user 350 knows their personal identifier but no one else is able to determine the personal identifier, not even an employee of the secure environment 325 which the user 350 is attempting to access.

[0195] At step 1555, the method 1500 includes the server processing system 310 generating and transferring an authentication response to the secure environment processing system 320, wherein the authentication response is indicative of whether the user 350 is authenticated to access to the secure environment 325 based upon the comparison in step 550. In particular, in the event that the hash value of the user-submitted code does not match the stored hash value of the expected code in step 550, the server processing system 310 generates and transfers an authentication response indicating that the user 350 should not be granted access to the secure environment 325 controlled by the secure environment processing system 320. However, in the event that the hash values match in the comparison performed in step 560, the server processing system 310 generates and transfers an authentication response indicating that the user 350 should be granted access to the secure environment 325 controlled by the secure environment processing system 320.

[0196] At step 1560, the method 1500 includes the server processing system 310 recording in the user account that the challenge response has been received and the authentication response has been transferred to the secure environment processing system 320.

[0197] It will be appreciated that for the user device 300 described in relation to Figures 14 and 15, the user device 330 includes no exposed or operational communication device. Therefore, in one method as previously described, the user can interact with the input device of the user device 330 to submit a key selection request. The user device 330 selects, preferably randomly, one of the plurality of keys which has not previously been used. The user device 330 presents the key and the corresponding index via the display of the user device 330. The user can then determine the user submitted code as previously discussed using the presented key, and then arrange for transfer of the user submitted code together with the corresponding index of the selected key to the server processing system 310. In an alternate form as previously discussed, the user may obtain the index of the server-selected key from the server processing system 310. For example, the index may be provided to the user via the user processing system 340 or via alternate means such as over a telephone call. The user inputs the index into a prompt presented by the display of the user device 330. The user device 330 uses the index input via the input device to select from memory the corresponding selected key which is presented via the display of the user device 330. The user submitted code can then be determined by the user as previously described using the presented key. The user submitted code can then be transferred to the server processing system 310 for authentication. This may be achieved via the user interacting with the user processing system 340 but could be achieved via other means such as via a telephone call.

[0198] It will be appreciated that the system illustrated in Figure 3 only depicts a single user 350 and a single secure environment processing system 320. It will be appreciated that the server processing system 310 is preferably in data communication with a plurality of secure environment processing systems 320, wherein each secure environment processing system 320 controls user access to a respective secure environment 325.

[0199] It will also be appreciated that the server processing system 310 is preferably in data communication with a plurality of user devices 330 associated with a respective plurality of users 350, wherein the memory 325 associated with the server processing system 310 stores a plurality of user accounts in order to authenticate the plurality of users 350.

[0200] It will be appreciated that the server processing system 310 may be provided in the form of a distributed processing system or a single dedicated processing system.

[0201 ] It will be appreciated that data transferred between various components of the system may utilise encryption and digital signature techniques.

[0202] It will be appreciated that other hashing processes can be applied by the server processing system 310. In particular, the server processing system 310 may alternatively determine the user's personal identifier by reversely applying the selected key associated with the index sent in the request to the user device 330. Upon determination, the server processing system 310 may immediately hash the user's personal identifier. The user's personal identifier can then be immediately purged from RAM of the server processing system 310 so that no data is stored by the server processing system 310 which is directly indicative of the user's personal identifier.

[0203] It will be appreciated that the IDV may be part of the server processing system 310 or a separate processing system in data communication with the server processing system 310.

[0204] Whilst the keys and personal identifiers have been exemplified above as a series alphabetic characters and/or numerical digits, it is possible that other forms of data could be used, such as unique graphical icons, shapes, colours, audible sounds, and the like.

[0205] Whilst the security checking process performed at step 522 has been described in relation to the authentication process, it is possible that the security checking process is also performed in methods 400 and 700 to ensure that no malicious tampering has occurred to the user device.

[0206] The above embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment, firmware, or an embodiment combining software and hardware aspects.

[0207] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention.

Claims

CLAIMS:

1. A method for authenticating a user, wherein the method includes, in a server processing system, steps of:

(b) receiving the authentication request to authenticate the user; and

(c) attempting to authenticate the user including steps of:

determining a hash value of the user submitted code; and

2. The method according to claim 1 , wherein the authentication request is received from a secure environment processing system controlling access to a secure environment, wherein the method includes the server processing system transferring an authentication response to the secure environment processing system, wherein the authentication response is indicative of the authentication result indicating whether the user is authenticated for accessing the secure environment.

3. The method according to claim 1 or 2, wherein the method includes the server processing system performing steps of:

receiving a registration request from the user device;

transferring registration key data indicative of a registration key to the user device;

receiving, from the user, a registration code which is based on the registration key and the personal identifier of the user; and

4. The method according to any one of claims 1 to 3, wherein the method includes the server processing system performing steps of:

receiving a registration request from the user device;

transferring registration key data indicative of a first registration key and second registration key to the user device;

5. The method according to claim 3 or 4, wherein the registration request is indicative of a unique device profile identifying the user device, wherein, prior to transferring the registration key data, the method includes the server processing system generating a user account, wherein the user device is associated with the user account based on the unique device profile.

6. The method according to claim 5, wherein the registration request is indicative of identity data which attempts to prove the identity of the user, wherein, prior to transferring the registration key data, the method includes the server processing system performing steps of: facilitating verification of the identity of the user based on the identity data; and generating the user account based on a positive verification of the identity of the user.

7. The method according to claim 6, wherein the method includes the server processing system associating, with the user account, data indicative of the identity of the user indicated by a digital certificate of the user.

8. The method according to any one of claims 5 to 7, wherein after generating a user account the method includes the server processing system associating the plurality of hash values of the expected codes with the user account.

9. The method according to any one of claims 1 to 8, wherein the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

facilitating verification of the user's identity; and

in response to successful verification:

10. The method according to any one of claims 1 to 9, wherein the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

1 1 . The method according to any one of claims 1 to 9, wherein the method includes the server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

facilitating verification of the user's identity; and

in response to successful verification:

deleting from server accessible memory the reset key data, the first and second reset codes, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

12. The method according to any one of claims 1 to 11, wherein the method includes the server processing system receiving, from the user device or user, an index selection request, and facilitating provision, to the user device or the user, the selected index in response to receiving the index selection request, wherein the selected index is used by the user device for presenting the selected key.

13. The method according to any one of claims 1 to 12, wherein the user device is configured to store encrypted data with a plurality of layers of encryption, wherein the user device or a processing system separate to the user device includes an executable application for facilitating at least one of encryption and decryption, wherein in response to the server processing system successfully authenticating the user, the method includes:

determining, by the user device, a user device cryptographic key based on a unique device profile identifying the user device; and at least one of:

14. The method according to claim 13, wherein the executable application enables transfer of cryptocurrency to an entity using a private key stored by the user device, wherein the executable application enables selection of the entity from a whitelist presented in a user interface displayed by the user device or the processing system, wherein the whitelist is indicative of verified entities stored in the server accessible memory.

15. The method according to claim 13, wherein the executable application enables transfer of cryptocurrency to an entity, wherein the method includes:

the executable application transferring data indicative of the entity to the server processing system;

16. The method according to claim 1 to 8, wherein the method includes the server processing system generating and storing the plurality of expected codes after the user is provisioned with the user device, wherein the user device has stored therein the plurality keys at the time of the user device being provisioned to the user.

17. The method according to claim 16, wherein the method includes the server processing system receiving the user submitted code and the respective index of one of the plurality of keys used by the user for determining the user submitted code.

18. A computer readable medium for configuring a server processing system to authenticate a user, wherein the computer readable medium includes executable instructions which, upon execution, configure the server processing system to perform the method of any one of claims 1 to 17.

19. A server processing system for authenticating a user, wherein the server processing system is configured to perform a method according to any one of claims 1 to 17.

20. A system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

present the selected key to the user via a display;

21. The system according to claim 20, wherein the user device is configured to determine if the user device is unable to communicate with the server processing system, wherein in response the user device is configured to display a prompt requesting the user to input via an input device a selected index received by the user from the server processing system, wherein the user device is configured to retrieve from memory, using the selected index, the selected key and display the selected key to the user via the display.

22. A system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

the server processing system is configured according to any one of claims 1 to 8, 16 or

17:

the user device is configured to:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

present, via a display of the user device, the selected key.

23. A system for authenticating a user, wherein the system includes a server processing system and a user device, wherein:

the server processing system is configured according to claim 17:

the user device is configured to:

receive the plurality of keys;

store the plurality of keys in memory of the user device;

receive, via an input device of the user device, a key selection request;

present, via a display of the user device, the selected key and the corresponding index of the selected key.

24. The system according to any one of claims 20 to 22, wherein the user device has no operational communication device when provided to the user.

25. The system according to any one of claims 20 to 24, wherein the display is an electronic paper display to present the selected key to the user.

26. The system according to claim 20 to 25, wherein the display and input device is a touch sensitive electronic paper display.

27. A system for authenticating a user, wherein the system includes a server processing system and a software application, wherein:

the server processing system configured to:

(b) receive an authentication request to authenticate the user; and

determine a hash value of the user submitted code; and

store the plurality of keys; and

present the selected key to the user.

28. A server processing system for enabling a user to reset a personal identifier used for authenticating a user, wherein the server processing system is configured to:

receive, from the user, a reset personal identifier request;

determine the new personal identifier using the reset code and the reset key, wherein the new personal identifier is stored; generate and store a plurality of new expected codes which are indexed, each new expected code being determined using the new personal identifier of the user and a respective key from the plurality of new keys;

delete, from the server accessible memory and prior to receiving an authentication request, the reset key data, the reset code, the new personal identifier, the plurality of new keys, and the plurality of new expected codes.

29. A method for resetting a personal identifier for authenticating a user, wherein the method includes a server processing system performing steps of:

receiving, from the user, a reset personal identifier request;

30. A computer readable medium for configuring a server processing system for enabling a user to reset a personal identifier used for authenticating a user, wherein the computer readable medium includes executable instructions which, upon execution, configure the server processing system to perform the method of claim 29.