US20210264010A1 - Method and system for user authentication with improved security - Google Patents
Method and system for user authentication with improved security Download PDFInfo
- Publication number
- US20210264010A1 US20210264010A1 US17/241,986 US202117241986A US2021264010A1 US 20210264010 A1 US20210264010 A1 US 20210264010A1 US 202117241986 A US202117241986 A US 202117241986A US 2021264010 A1 US2021264010 A1 US 2021264010A1
- Authority
- US
- United States
- Prior art keywords
- authentication
- user
- session
- specific
- processing unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
- G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/606—Protecting data by securing the transmission between two devices or processes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3231—Biological data, e.g. fingerprint, voice or retina
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/63—Location-dependent; Proximity-dependent
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/63—Location-dependent; Proximity-dependent
- H04W12/64—Location-dependent; Proximity-dependent using geofenced areas
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/71—Hardware identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/72—Subscriber identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/73—Access point logical identity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2103—Challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
Definitions
- the present invention relates generally to authentication systems and methods, and more particularly to multifactor authentication systems with improved security and flexibility.
- Reliable and secure authentication of personal identity is an essential element of many online systems.
- an authorised user of an online system or service is required to provide at least a user identifier, e.g. a user name or code, and an additional ‘secret’ code, such as a password or personal identification number (PIN).
- a PIN or password is an example of a knowledge factor, whereby the user is required to prove knowledge of the secret, i.e. password, phrase or PIN, for authentication.
- Knowledge factors are susceptible to attack, e.g. by eavesdropping.
- the most basic form of eavesdropping may involve observing a user when entering a password or PIN. Observation may be performed directly, or may involve the use of a concealed camera.
- More technologically sophisticated eavesdropping techniques include so called ‘man-in-the-middle’ attacks, in which malicious software is installed in terminal equipment and/or intermediate network nodes, targeting system components in which unencrypted passwords may be accessed in transit. Users may also be deceived into revealing knowledge factors, e.g. via phishing attacks.
- Authentication methods with enhanced security include two-factor authentication, in which the user is required to provide one or more additional factors as proof of identity.
- possession factors ‘something the user has’
- possession factors include credit cards and the like, which must be presented in conjunction with a PIN in order to gain access to a transaction system.
- Other forms of possession factor include disconnected tokens, which display periodically-updated random numbers for entry by the user, and uniquely identifiable personal items, such as cellular mobile phones or smartphones.
- Possession factors significantly increase security, but are nonetheless susceptible to theft and replication (e.g. card skimming).
- such additional security is provided in a manner that is transparent to end-users, such that there is no additional inconvenience or impediment presented to legitimate, authorised, users.
- the invention provides a user authentication method comprising execution, by a distributed processing system, of the steps of:
- the first processing unit acquiring at least one item of authentication data, valid during the authentication session;
- the second processing unit transforming the authentication data using a transformation algorithm based upon one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
- the third processing unit verifying that the transformed authentication data corresponds with the user and with predetermined values of the one or more session-specific authentication factors
- the third processing unit generating an authentication result of the authentication session based upon the verification.
- the use of session-specific authentication factors in the transformation of authentication data enables information associated with a current context of the authentication session to be incorporated into user verification.
- the second processing unit may comprise instruction code executing on a processor of a portable personal device operated by the user, such as a dedicated digital access device running suitable software or, conveniently, a smartphone or other personal device having an installed application (i.e. an ‘app’) providing the required instruction code embodying an aspect of the invention.
- the current context information may comprise values corresponding with factors such as a geographic location of the device, a Service Set Identifier (SSID) of a wireless network visible to the device, and/or a unique identifier associated with the device. More generally, any context-specific information accessible to software code executing on the device may be employed as a session-specific authentication factor.
- SSID Service Set Identifier
- a secret keyword (e.g. a password or passphrase) is associated with the user, the secret keyword consisting of an ordered sequence of symbols selected from a predetermined symbol set, and wherein:
- the at least one item of authentication data includes a security matrix comprising a mapping between each symbol within the symbol set and a code value which is specific to the authentication session and which is selected from a code set which is distinct from the symbol set;
- the security matrix is transformed by the first processing unit using a transformation algorithm based upon the predetermined values of the one or more session-specific authentication factors, to generate a transformed security matrix comprising the symbol set and transformed code values;
- the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to recover the code values of the security matrix, and a user input step for receiving a sequence of code values selected from the security matrix and input by the user, the code values corresponding with the secret keyword;
- the verifying step comprises validating the sequence of code values received in the user input step by comparison with an expected sequence of code values corresponding with the secret keyword and a mapping thereof to the code values in the security matrix.
- the session-specific authentication factors are applied to ‘encode’ the mapping between symbol and code values in a keyword-based user authentication method of the type disclosed in commonly assigned U.S. Pat. Nos. 8,869,255 and 9,519,764.
- the second processing unit e.g. a portable personal device operated by the user
- the portable device i.e.
- the second processing unit will determine its own location, for example by using in-built GPS receiver hardware, and apply the resulting coordinates to decode the mapping.
- the device does not know the value of the GPS coordinates used to encode the mapping, but will only obtain the correct decoded mapping if its own location matches those coordinates. The user will thus only be able to successfully authenticate when present at the authorised location.
- the authentication data comprises a session-specific one-time code word which is encrypted by the first processing unit using a transformation algorithm parameterised by the predetermined values of the one or more session-specific authentication factors;
- the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to decrypt the session-specific one-time code word, and a cryptographic signing step wherein a private cryptographic key of the user is applied to generate the transformed authentication data which comprises a signed copy of the session-specific one-time code word;
- the verifying step comprises a cryptographic verification wherein a public cryptographic key of the user is applied to confirm that the signed copy of the session-specific one-time code word was generated by the second processing unit associated with the terminal device operated by the user.
- session-specific authentication factors may be applied independently of any requirement for the user to provide a secret keyword (e.g. password or pass phrase) in order to access a secure system.
- a user may wish to access an online service, such as a remote desktop service provided by an employer, but may be restricted from doing so other than in an approved location, such as a home office.
- the second processing unit e.g. an authentication server
- may generate a session-specific one-time code word i.e. a nonce
- a session-specific one-time code word i.e. a nonce
- a symmetric encryption algorithm in which a key is derived from a predetermined value of a session-specific authentication factor, such as the GPS coordinates of the user's home office.
- the user's portable device i.e. second processing unit
- the user's portable device will determine its own location and apply the resulting coordinates to generate a key for use in the symmetric encryption algorithm in order to decrypt the nonce.
- the device does not know the value of the GPS coordinates used to generate the original encryption key, but will only successfully decrypt the nonce if its own location matches those coordinates.
- the device By signing the resulting decrypted nonce with a stored private key, the device enables subsequent verification that it was able to successfully decrypt the nonce. The user will thus only be able to successfully authenticate when present, with their portable device, at the authorised location.
- the invention provides an authentication system comprising:
- a network interface operatively associated with the processor
- At least one computer-readable storage device accessible by the processor
- the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method comprising the steps of:
- transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors
- an authentication result may be generated for the authentication session based upon the verification.
- the instruction code executable by the processor is configured to cause the processor to implement the step of acquiring the at least one item of authentication data by:
- the transformed authentication data may be configured to enable verification by confirming that it corresponds with the session-specific one-time code word that has been cryptographically signed using a private cryptographic key of the user.
- the invention provides a portable personal authentication device comprising:
- a network interface operatively associated with the processor
- At least one computer-readable storage device accessible by the processor
- the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method, in an authentication session of a user of the authentication device, comprising the steps of:
- transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors
- an authentication result may be generated for the authentication session based upon the verification.
- the authentication data comprises an encrypted session-specific one-time code word
- the instruction code executable by the processor is configured to cause the processor to implement the step of transforming the authentication data by:
- the invention provides a tangible computer-readable medium comprising stored program instructions which, when executed by a processor of an authentication system, cause the authentication system to implement a method comprising the steps of:
- transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors
- an authentication result may be generated for the authentication session based upon the verification.
- the invention provides a tangible computer-readable medium comprising stored program instructions which, when executed by a processor of a portable personal identification device, cause the device to implement a method comprising the steps of:
- transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors
- an authentication result may be generated for the authentication session based upon the verification.
- FIG. 1 is a schematic diagram illustrating an exemplary system embodying the invention
- FIG. 2 is a flowchart of a user authentication method performed at an authentication server according to a first embodiment of the invention
- FIG. 3 is a flowchart of a user authentication method performed at an endpoint device according to the first embodiment
- FIG. 4 is a flowchart of a session-specific transformation process according to the first embodiment
- FIG. 5 is a flowchart of a process of constructing a session-specific challenge mention according to the first embodiment
- FIG. 6 is a flowchart illustrating an exemplary method for generating a session-specific transformation/encryption key according to the first embodiment
- FIG. 7 is a flowchart illustrating an exemplary session-specific inverse transformation process according to the first embodiment
- FIG. 8 is a schematic representation of a first challenge message format embodying the invention.
- FIG. 9 shows exemplary XML code embodying the message format of FIG. 8 ;
- FIG. 10 shows a timeline of communications between and endpoint device, a secure system and an authentication server according to the first embodiment
- FIG. 11 is a schematic illustration of an endpoint user authentication interface according to the first embodiment
- FIG. 12 shows an exemplary user record
- FIG. 13 shows an exemplary secure system record
- FIG. 14 is a schematic diagram illustrating an alternative user authentication system and method embodying the invention.
- FIG. 15 is a flowchart illustrating a user authentication method performed at an authentication server according to a further embodiment of the invention.
- FIG. 16 is a flowchart illustrating a user authentication method as performed at a portable device according to the further embodiment
- FIG. 17 is a flowchart illustrating a session-specific encryption process according to the further embodiment.
- FIG. 18 is a flowchart illustrating a process of constructing a session-specific challenge message according to the further embodiment
- FIG. 19 is a flowchart illustrating an exemplary method for generating a session-specific encryption/decryption key in the methods of FIGS. 15 and 16 ;
- FIG. 20 is a flowchart illustrating an exemplary process of authentication performed by the authentication server in response to receiving a response message generated by a portable device
- FIG. 21 shows a schematic representation of a challenge message format according to the further embodiment
- FIG. 22 shows exemplary XML code embodying the message format of FIG. 21 ;
- FIG. 23 shows a timeline of communications between and endpoint device, a secure system and an authentication server according to the further embodiment.
- FIG. 1 is a block diagram illustrating a system 100 embodying the present invention.
- a public communications network 102 such as the Internet, is employed for messaging between a secure system 104 , one or more user endpoint devices 106 , and an authentication server 108 .
- the user endpoint devices 106 may be any suitable computing, communications and/or processing appliances having the ability to communicate via the Internet 102 , for example using web browser software and/or other connected applications.
- Endpoint devices 106 may also comprise other types of terminal apparatus, such as cash dispensing machines (e.g. ATMs), point-of-sale (POS) terminals, vending machines, and so forth.
- cash dispensing machines e.g. ATMs
- POS point-of-sale
- exemplary system 100 comprises a single shared, insecure, network 102 for communications between all processing devices and systems
- embodiments of the invention may include other types of communications and/or transaction networks, such as financial transaction networks, private networks, virtual private networks (VPNs), cellular telephony networks, or a mix of these and/or other forms of communications systems.
- financial transaction networks private networks
- VPNs virtual private networks
- cellular telephony networks or a mix of these and/or other forms of communications systems.
- processing unit is used in this specification (including the claims) to refer to any suitable combination of hardware and software configured to perform a particular defined task, such as generating and transmitting authentication data, receiving and processing authentication data, or receiving and validating authentication data.
- a processing unit may comprise an executable code module executing at a single location on a single processing device, or may comprise cooperating executable code modules executing in multiple locations and/or on multiple processing devices.
- authentication processing may be performed entirely by code executing on authentication server 108 , while in other embodiments corresponding processing may be performed cooperatively by code modules executing on secure system 104 and authentication server 108 .
- embodiments of the invention may employ application programming interface (API) code modules, installed at the secure system 104 , or at another third-party system, configured to operate cooperatively with code modules executing on authentication server 108 in order to provide the secure system 104 with authentication services.
- API application programming interface
- Software components embodying features of the invention may be developed using any suitable programming language, development environment, or combinations of languages and development environments, as will be familiar to persons skilled in the art of software engineering.
- suitable software may be developed using the C programming language, the Java programming language, the C++ programming language, the Go programming language, and/or a range of languages suitable for implementation of network or web-based services, such as JavaScript, HTML, PHP, ASP, JSP, Ruby, Python, and so forth.
- JavaScript JavaScript
- HTML HyperText Markup Language
- PHP ASP
- JSP JavaScript
- Ruby Ruby
- Python Python
- the endpoint devices 106 each comprise a processor 110 .
- the processor 110 is interfaced to, or otherwise operably associated with, a communications interface 112 , one or more user input/output (I/O) interfaces 114 , and local storage 116 , which may comprise a combination of volatile and non-volatile storage.
- Non-volatile storage may include solid-state non-volatile memory, such as read only memory (ROM) flash memory, or the like.
- Volatile storage may include random access memory (RAM).
- the storage 116 contains program instructions and transient data relating to the operation of the endpoint device 106 .
- the endpoint device 106 may include additional peripheral interfaces, such as an interface to high-capacity non-volatile storage, such as a hard disk drive, optical drive, and so forth (not shown in FIG. 1 ).
- the endpoint device storage 116 may contain program and data content relevant to the normal operation of the device 106 . This may include operating system programs and data (e.g. associated with a Windows, Android, iOS, or MacOS operating system), as well as other executable application software generally unrelated to the present invention.
- the storage 116 also includes program instructions 118 which, when executed by the processor 110 instruct the endpoint device 106 to perform operations relating to an embodiment of the invention, for example such as are described below with reference to FIGS. 3, 6, 7, 11 and 14 .
- the authentication server 108 comprises a processor 120 .
- the processor 120 is interfaced to, or otherwise operably associated with a non-volatile memory/storage device 122 , which may be a hard disk drive, and/or may include a solid-state non-volatile memory, such as ROM, flash memory, or the like.
- the processor 120 is also interfaced to volatile storage 124 , such as RAM, which contains program instructions and transient data relating to the operation of the authentication server 108 .
- the storage device 122 maintains known program and data content relevant to the normal operation of the authentication server 108 .
- the storage device 122 may contain operating system programs and data, as well as other executable application software necessary for the intended functions of the authentication server 108 .
- the storage device 122 also contains program instructions which, when executed by the processor 120 , instruct the authentication server 108 to perform operations relating to an embodiment of the present invention, such as are described in greater detail below with reference to FIGS. 2, 4, 5 and 6 . In operation, instructions and data held on the storage device 122 are transferred to volatile memory 124 for execution on demand.
- the processor 120 is also operably associated with a communications interface 126 in a conventional manner.
- the communications interface 126 facilitates access to the data communications network 102 .
- the volatile storage 124 contains a corresponding body 128 of program instructions transferred from the storage device 122 and configured to perform processing and other operations embodying features of the present invention.
- the secure system 104 may be any computing or processing system requiring authentication of end-users prior to permitting access and/or the performance of transactions on behalf of those users.
- Secure systems that may employ the services provided by embodiments of the invention include, but are not limited to, banking systems (e.g. online banking portals), e-commerce payment portals, secure computing platforms (e.g. government or employer systems), and other systems requiring secure authentication of users.
- FIGS. 10 and 22 For present purposes, with reference to FIG. 1 , a brief overview is now provided.
- An end-user requiring access to a secure system 104 may use either an endpoint device 106 , or an alternative mechanism, to initiate an access request 1002 .
- the secure system 104 uses services provided by the authentication server 108 in order to determine whether or not to provide the end-user with the requested access. As such, an authorisation request 1004 is transmitted by the secure system 104 to the authentication server 108 .
- the authentication server 108 generates and transmits a challenge message 1006 to the endpoint device 106 .
- the challenge message may be transmitted directly from the authentication server 108 to the endpoint device 106 , or may be transmitted indirectly, for example via the secure system 104 .
- the manner of routing the challenge message 1006 is not critical to the general operation of embodiments of the invention.
- the user is prompted for input in response to the challenge message, and a corresponding response 1008 is transmitted back to the authentication server 108 .
- the authentication server 108 validates the response, and returns an authorisation result 1010 to the secure system 104 .
- the secure system 104 may transmit an access response 1012 , either granting or denying access to the end-user via the endpoint device 106 .
- the requested access may be granted via another mechanism, as described below with reference to FIG. 22 .
- FIG. 2 is a flowchart 200 showing further details of a user authentication method according to a first embodiment of the invention, from the perspective of the authentication server 108 .
- the authentication server 108 receives an authorisation request from the secure system 104 , which includes identifying information of the end-user, such as a user name or other user ID.
- the authentication server 108 generates a security matrix which is a ‘one-time’ mapping between members of a predetermined symbol set and a distinct code set.
- the symbol set comprises a plurality of symbols, from which end-users are able to construct key words or phrases, such as passwords, or other sequences of symbols from the set used for authentication purposes.
- the symbol set may comprise letters of the alphabet (upper- and/or lower-case), numerals, and/or selected punctuation and other special characters.
- the code set is a distinct plurality of code values.
- the number of members of the code set is smaller than the number of members of the symbol set.
- the code set may be, for example, the set of decimal digits zero to nine, having the advantage that all of these code values can be entered by a user using only a PIN pad or numeric keypad.
- the mapping represented by the security matrix generated at step 204 is not ‘one-to-one’, and each code value may be mapped to multiple symbols of the symbol set. Accordingly, by creating a one-time mapping, e.g. via a random or pseudorandom process, it is not possible for any eavesdropper or observer of the communications messages passing between the endpoint device 106 and the authentication server 108 , or overlooking the actions of the end-user, to uniquely determine the keyword or phrase used for user authentication in any single observation. Furthermore, since a new security matrix is generated for each authentication instance, simply re-entering a code previously entered by the authorised user will not subsequently result in successful authentication.
- the authentication server 108 transforms the code values in the security matrix based upon one or more session-specific factors. Further discussion of this step is provided below, with reference to FIG. 4 .
- the authentication server 108 constructs and transmits a challenge message comprising the transformed security matrix, and other relevant information, to the endpoint device 106 . This step is discussed in greater detail below with reference to FIG. 5 .
- the authentication server 108 receives a challenge response message from the endpoint device 106 .
- the challenge response message corresponds with input provided by the end-user.
- the endpoint device 106 has successfully inverted the transformation performed by the authentication server 108 at step 206 , and the user has then entered a correct sequence of code values, the authentication server 108 will be able to reproduce the same code sequence based upon a copy of the user's keyword held within a database accessible to the authentication server processor 120 . Further details of user records maintained in the database are discussed below with reference to FIG. 12 .
- the authentication server 108 validates the received code sequence against a corresponding locally generated code sequence. From this, an authentication result 214 is generated. In the case of a match between the received code sequence and the locally generated code sequence, a positive authentication result is generated, and transmitted to the secure system 104 . Otherwise, a negative authentication result is generated and transmitted to the secure system 104 . Based upon this authentication result, the secure system 104 is able to grant or deny access to the end-user, via the endpoint device 106 .
- FIG. 3 there is shown a flowchart 300 of a user authentication method as performed at an endpoint device embodying the invention.
- the method 300 is performed by the endpoint device 106 in order to receive and respond to the challenge message generated by the authentication server 108 at step 208 .
- the endpoint device 106 receives the challenge message including the transformed security matrix from the authentication server 108 .
- the endpoint device 106 applies the same session-specific factors employed by the authentication server 108 at step 206 in order to apply an inverse transformation to the transformed code values. Having performed this inverse transformation, the endpoint device 106 has regenerated the original mapping between symbols of the symbol set and code values of the code set, according to the original security matrix generated at step 204 .
- the original security matrix is presented to the user, for example via a display of the I/O devices 114 of the endpoint device 106 .
- the user is enabled to respond to the displayed security matrix, which is typically accompanied by a suitable prompt, by entering a sequence of code values corresponding with the mappings and the user's personal keyword (password, passphrase, or other sequence of symbols selected from the symbol set).
- User input is received by the endpoint device 106 at step 308 , which then generates and transmits a message containing the entered code sequence back to the authentication server 108 . This message is received at step 210 , as discussed above with reference to FIG. 2 .
- FIG. 4 shows a flowchart 400 illustrating a session-specific transformation process, e.g. as carried out by the authentication server 108 at step 206 , according an embodiment of the invention.
- the input to the process 400 is the security matrix 402 , as generated at step 204 .
- one or more session-specific factors 404 is identified and selected or retrieved.
- the session-specific factors typically depend upon the requirements of the secure system 104 . Accordingly, the session-specific factors may be retrieved from a database record that is associated with the secure system 104 .
- the session-specific factors may also depend upon other characteristics of the current session, such as the particular user, the location of the endpoint device, the time/date, and/or any other identifiable properties of the session.
- one or more session-specific factors are retrieved from a record 406 matching the predefined properties of the present session.
- corresponding values of the session-specific factors are retrieved, or determined, for use in the transformation method 400 .
- factor types and values that may be employed in embodiments of the invention include, but are not limited to:
- the factor values retrieved or determined at step 404 are combined to form a session-specific transformation/encryption key.
- Any suitable algorithm may be used to combine the factors.
- the combined factors may comprise a concatenation of values of one or more session-specific factors, a hash generated from the values of the one or more session-specific factors, or any other suitable function producing an output that is based upon all of the input session-specific factor values.
- the combined result may further be employed in any suitable manner in order to transform the code values of the security matrix 402 .
- the combined value may be used as an encryption key in a symmetric encryption algorithm applied to the code values.
- a simple symmetric transformation/encryption algorithm is to compute a transformed code sequence by a bitwise exclusive OR (XOR) operation between the code values and the key value.
- More sophisticated symmetric ciphers include DES, 3DES, AES-256, AES-512, and Blowfish.
- Suitable keys for use with such ciphers may be derived from combined session-specific factors values by use of a suitable hashing function, such as—without limitation—SHA-256 or SHA-512.
- a symmetric algorithm is employed, so that the endpoint device 106 is able to reverse the transformation after generating the same transformation/encryption key from combined values of the session-specific factors.
- An eavesdropper will be unable to perform the reverse transformation, without knowledge of the values of the session-specific factors that are shared by the authentication server 108 and the endpoint device 106 , but never transmitted via the network 102 .
- the key comprising the combined, and optionally hashed, values of the session-specific factors are applied to the code values of the security matrix 402 resulting in the transformed security matrix 412 , which is provided for use at the transmission step 208 .
- FIG. 5 is a flowchart 500 illustrating a process of constructing a session-specific challenge message for transmission in the transmission step 208 .
- the input to the process 500 is the transformed security matrix 412 .
- a symbol set part of the message is generated, based upon the symbol set included in the security matrix 412 .
- a transformed code set part of the message is generated based upon the transformed code values within the transformed security matrix 412 .
- a valid code part is generated at step 506 .
- the purpose of the valid code part of the message is to communicate to the endpoint device 106 the complete set of valid code values, for example the decimal digits zero to nine.
- the way in which this information may be employed by the endpoint device 106 is described in greater detail below with reference to FIG. 7 .
- a factor selection part of the message is generated, to inform the endpoint device 106 of the session-specific factor types that are to be used for reversing the transformation of the code values.
- the values of the session-specific factors are not in the message constructed by the process 500 , but instead comprise shared ‘secret’ information between the authentication server 108 and the endpoint device 106 .
- step 510 the message parts are combined in order to construct the complete challenge message, which is then transmitted at step 512 .
- FIG. 6 there is shown a flowchart 600 illustrating an exemplary method for generating a session-specific transformation/encryption key based upon one or more session-specific factors.
- the method 600 may be used at step 408 of the transformation process 400 in the authentication server 108 , and may then similarly be employed by the endpoint device 106 in order to generate the key for performing the corresponding inverse transformation.
- storage for containing the generated key is initialised. This may involve clearing a corresponding block of memory, or initialising a block of memory to some other value known to both the authentication server 108 and the endpoint device 106 .
- the initialisation value may itself be session-specific, e.g. based upon a unique session ID, or upon network addresses of the authentication server 108 and endpoint device 106 .
- an iterative algorithm is used to combine multiple session-specific factor values. Accordingly, at decision step 604 a check is performed to determine whether there are further factor values still to be combined. If so, the next factor is selected at step 606 , and the corresponding factor value is retrieved or determined at step 608 . At step 610 , the new factor value is combined, e.g. by concatenation or other algorithmic method, into the transformation key. Control then returns to the decision step 604 , to determine whether there are more factor values to be determined and combined.
- a finalisation step may comprise computing a hash value of concatenated factor values to produce a key of known length to be used as part of the transformation or encryption process applied to the code values in the security matrix 402 .
- FIG. 7 is a flowchart 700 illustrating a session-specific inverse transformation process that may be performed at an endpoint device 106 , according to embodiments of the invention.
- the transformation key which is obtained according to the same process 600 as was employed by the authorisation server 108 , is applied to the transformed code values in an inverse transformation, in order to generate candidate code values. Note that these are identified as ‘candidate code values’, since any mismatch between the session-specific factor values applied by the authentication server 108 and by the endpoint device 106 (e.g. in the case of an attempted fraudulent authentication) will result in the generation of incorrect and/or invalid code values.
- an incorrect transformation key in the inverse transformation process may result in one or more candidate code values that are invalid code values. For example, if code values are limited to the decimal digits zero to nine, an invalid inverse transformation may result in other characters or symbols being generated. A check is performed for any such invalid code values, at step 704 .
- the invalid code part of the challenge message, generated at step 506 may be used by the endpoint device 106 in order to identify such invalid code values. If invalid values are present, they are replaced at step 706 with valid codes selected from the valid code part of the challenge message. The selection may be random, or performed via any other suitable method. As a result of this replacement step, the user will always be presented with a security matrix that appears valid, and will therefore be unaware of the possibility that a fraudulent authentication attempt has been detected and thwarted.
- FIG. 8 shows a schematic representation 800 of a challenge message format according to the first embodiment of the invention.
- the exemplary challenge message 800 comprises a number of fields, corresponding with the message parts constructed as described above with reference to FIG. 5 .
- the message format 800 comprises a symbol set 802 , a transformed code set 804 , a valid code set 806 , and a session-specific factor list 808 .
- the session-specific factor list 808 comprises one or more subfields identifying the session-specific factors, e.g. 808 a , 808 b , employed in generating the transformation/encryption key, e.g. as described above with reference to FIG. 6 .
- FIG. 9 shows exemplary XML code 900 embodying a challenge message according to the format 800 .
- the symbol set 902 comprises 26 letters of the alphabet, in upper case.
- the transformed code set 904 is the result of applying the transformation process 400 to a corresponding set of 26 code values.
- the transformed code set 904 comprises 26 eight-bit values, each of which is represented as two hexadecimal digits.
- the XML code 900 further comprises the set of valid code values 906 , which in this example consist of the decimal digits zero to nine.
- An XML element 908 encloses the list of session-specific factors 910 , 912 , 914 .
- three factors are identified, in which ‘ID’ represents an identifier of the current user, ‘GPS:4’ defines a factor consisting of the GPS coordinates of the endpoint device, to four decimal places of precision, and ‘PSK’ represents a factor consisting of a pre-shared key known to both the endpoint device 106 and the authentication server 108 .
- the transformed code set 904 will be converted back to the correct original code set if:
- FIG. 10 there is shown a timeline 1000 of communications between the endpoint device 106 , the secure system 104 , and an authentication server 108 embodying the invention.
- An access request 1002 is transmitted from the endpoint device 106 to the secure server 104
- a corresponding authorisation request 1004 which may include a user ID or other identifying information provided by the endpoint device user, is transmitted from the secure system 104 to the authentication server 108 .
- the authentication server 108 is able to identify both the particular secure system 104 to which access is requested, and the user requesting access via the endpoint device 106 .
- a session-specific challenge message 1006 is then transmitted from the authentication server 108 to the endpoint device 106 .
- the session-specific challenge message 1006 has the general message format 800 , and in particular may comprise XML code such as the code 900 illustrated in FIG. 9 .
- the endpoint device 106 then inverts the transformation in order to recover the original sequence of code values, and displays the security matrix comprising pairs of keyword symbols and code values to the user of the endpoint device.
- the user enters code values corresponding with the user keyword, and a corresponding session-specific challenge response 1008 is transmitted from the endpoint device 106 to the authentication server 108 .
- the authentication server 108 then performs validation of the code sequence entered by the user, and generates and transmits an authorisation result message 1010 to the secure system 104 .
- the authorisation result message 1010 will indicate whether or not the user successfully authenticated.
- a corresponding access response message 1012 indicating whether the endpoint device 106 is granted or denied access to the secured system 104 , is then transmitted.
- the timeline 1000 may be interpreted more generally as a representation of communications between three processing units, independently of the specific combinations of location, hardware and software used to implement each unit.
- a first processing unit corresponds with the authentication server 108 , which receives the request comprising a unique identifier of the user requiring authentication, generates session-specific authentication data (i.e. the challenge), and transmits the authentication data to a second processing unit corresponding with the endpoint device 106 .
- the second processing unit generates transformed authentication data that is characteristic of the authentication session and of the user, and transmits this to a third processing unit for verification.
- the third processing unit is an executable code module which executes on the same authentication server hardware platform 108 as the first processing unit, however in general this function may reside wholly or partially elsewhere, such as with an API code module executing on the secure system 104 , or on another trusted platform.
- FIG. 11 is a schematic illustration of an endpoint user authentication interface 1100 embodying the invention.
- the exemplary interface 1100 includes a prompt 1102 , e.g. the text ‘please enter the digits corresponding with your password using PIN pad’.
- the security matrix 1104 is displayed below the prompt 1102 .
- the security matrix 1104 comprises paired symbol values and corresponding code values. In the example 1100 , there are 30 symbol values comprising 26 letters of the alphabet and four special characters, which are paired with code values comprising the decimal digits zero to nine.
- the user can enter the code values corresponding with the symbol values of the user's password via the PIN pad, or numeric keypad 1106 .
- the keypad 1106 may be a physical device, or may be generated on a touchscreen display. Alternative forms of user input may be employed, such as voice recognition, or other means of data entry.
- the authentication server 108 also maintains one or more databases, for example within non-volatile storage 122 , or other persistent storage accessible to the processor 120 .
- One or more databases maintained by the authentication server 108 include a database comprising user records, and a database comprising secure system records.
- User records correspond with users who may be permitted access to one or more secure systems, e.g. 104 .
- Secure system records correspond with one or more secure systems, e.g. 104 , for which the authentication server 108 provides authentication services.
- FIG. 12 shows schematically the contents of an exemplary user record 1200 , which may be maintained in a database by the authentication server 108 .
- the exemplary user record 1200 comprises a user identifier field 1202 , and a field 1204 containing the user's keyword/password.
- the keyword/password filed 1204 may be encrypted until the user's keyword is required by the authentication server 108 for authentication of attempted access by the user to a secure system 104 .
- the user record 1200 may contain one or more user information fields 1206 .
- Additional user information fields 1206 may include personal information, such as the user's real name, contact details, and so forth, and/or may contain other system-specific information, such as authorisation expiry dates or any other information that may be required in a specific implementation of the invention. Also shown is a field 1208 for storing one or more public cryptographic keys of the user. While these public keys are not required in the present embodiment, an application of user public keys is described in greater detail below with respect to a further embodiment of the invention and with reference to FIGS. 15 to 22 .
- FIG. 13 illustrates schematically a secure system record 1300 .
- a secure system record 1300 may comprise a system identifier 1302 , corresponding with a particular secure system 104 , and may further comprise authentication information 1304 .
- Authentication information 1304 may comprise, for example, a password, public key, or other information that can be used by the authentication server 108 in order to identify and verify requests from a secure system, e.g. 104 .
- Each secure system record 1300 further contains one or more factor lists 1306 .
- a factor list 1306 may comprise selection criteria 1308 .
- a particular factor list may be employed for a particular endpoint device or location, a particular user, or at particular times of day.
- An appropriate factor list may therefore be selected by the authentication server 108 , in relation to a corresponding secure system 104 , by matching parameters of the current authentication request and/or context against the selection criteria 1308 .
- Each factor list 1306 comprises one or more factor entries, e.g. 1310 a , 1310 b .
- Each factor entry comprises a factor type (e.g. ‘ID’, ‘GPS:4’, ‘PSK’, as exemplified in FIG. 9 ).
- a factor entry may also comprise a factor value corresponding with the factor type.
- Factor values may comprise, for example, a permitted user ID, an authorised endpoint location, or the value (optionally encrypted for additional security) of a pre-shared key.
- An authentication server 108 which maintains secure system records 1300 may be configured for a very wide variety of different use cases.
- the secure system 104 may provide access to critical records which are to be available only within a particular secure building. This can be implemented by using a location factor with a value corresponding with the building location. If the location of the endpoint device 106 does not match the corresponding factor value, authentication will fail and access will be denied.
- Alternative factor lists may be provided for use in association with fixed terminals that are physically located within the building. For example, for each such fixed terminal a factor list may be provided having one or more factor types corresponding with physical parameters of the terminal such as MAC address, and/or other unique hardware component identifier. Accordingly, attempts to access the secure system 104 from such terminals can be successfully authenticated, even though the fixed terminals may not generally have the ability to independently determine their location.
- a secure system 104 may be a secure computing platform, e.g. an office server, to which access may only be permitted from authorised, business-supplied, endpoint devices. For example, an employee may be permitted to access the server 104 from a company laptop based upon a MAC address of the laptop, and/or other unique hardware identification numbers.
- the authentication server 108 may regulate access to the secure system 104 based upon unique hardware signatures of endpoint devices 106 , even if a malicious user attempts to spoof the system, e.g. by changing the MAC address of a network interface on an unauthorised device.
- FIG. 14 there is shown a schematic diagram 1400 illustrating an alternative user authentication system and method embodying the invention.
- an endpoint device 1402 is distinct from a user device 1404 .
- the user device 1404 may be, for example, a portable device such as a smartphone or tablet.
- the fixed endpoint device 1402 includes a display 1406 .
- the session-specific challenge message 1006 is converted by the endpoint device 1402 into a machine-readable code, such as a QR code.
- the user scans the machine-readable code, which is decoded by the application.
- the application then implements the inverse transformation of the transformed code values, and displays the resulting security matrix to the user.
- the user enters the sequence of code values corresponding with their keyword into the portable device 1404 .
- the resulting session-specific response 1008 comprising the code entered by the user, is transmitted to the authentication server 108 .
- the application on the user device 1404 may be configured with identifying information of the authentication server or may obtain the relevant identifying information from the code acquired from the endpoint device display 1406 . In the event that authentication is successful, the user is then provided with access to the secure system 104 via the endpoint device 1402 .
- the embodiment 1400 accordingly has the advantage of providing ‘arm's length’ authentication, via a user's personal device 1404 , wherein the user enters authentication information only into their own device 1404 , and never into the endpoint device 1402 .
- This arrangement enables enhanced multifactor authentication, depending upon something the user has (their portable device 1404 ), something the user knows (their keyword), along with any further factors that may be defined in a factor list corresponding with the secure system 104 that the user is attempting to access.
- a further enhancement to multifactor authentication, based upon a portable digital device as a ‘possession factor’ of a user, will now be described by way of a further exemplary embodiment of the invention, with reference to FIGS. 15 to 22 .
- the general system configuration of this further embodiment remains as shown 100 in FIG. 1 , however the endpoint device 106 is now a portable personal device such as a dedicated digital access device running suitable software or, conveniently, a smartphone or other personal device having an installed application (i.e. an ‘app’) providing the required instruction code embodying required functionality of the invention.
- the device 106 may be operated by the user to request access to a secure system, an access request may be generated independently of the device.
- the user may request access to an online system from a web browser executing on a desktop computer by entering only a unique identifier, such as a user name, thereby triggering a remote secure system 104 to generate an authentication request to a remote authentication server 108 .
- Communications with the portable device 106 as described in more detail below with reference to FIG. 22 , then carry out the authentication method to enable an authentication result to be generated by or to the secure system 104 .
- FIG. 15 is a flowchart 1500 showing further details of a user authentication method according to the further embodiment of the invention, from the perspective of the authentication server 108 .
- the authentication server 108 receives an authorisation request from the secure system 104 , which includes identifying information of the end-user, such as a user name or other user ID.
- the authentication server 108 generates a session-specific one-time code word, commonly known in the art as a ‘nonce’, which may be, for example, a random number of an appropriate length, e.g. 256 or 512 bits.
- the authentication server 108 generates an encryption key based upon one or more session-specific factors. Further discussion of this step is provided below, with reference to FIG. 17 .
- the encryption key is used to encrypt the nonce at step 1506 , for example using a symmetric cipher such as DES, 3DES, AES-256, AES-512 or Blowfish.
- a challenge message comprising the encrypted nonce, and other relevant information, is then transmitted to the portable device 106 , as discussed in greater detail below with reference to FIG. 18 .
- the authentication server 108 receives a challenge response message from the portable device 106 , which comprises a digitally signed copy of the original, decrypted, nonce.
- the authentication server 108 will be able to validate the nonce and verify the signature using a public key 1208 of the user at step 1514 . From this, an authentication result 1516 is generated.
- FIG. 16 there is shown a flowchart 1600 of a user authentication method as performed at a portable device 106 , such as a smartphone executing an app comprising code embodying the invention.
- the device 106 receives the challenge message including the encrypted nonce from the authentication server 108 .
- the device 106 applies the same session-specific factors employed by the authentication server 108 at step 1506 in order to replicate the symmetric encryption/decryption key used to encrypt the nonce.
- this key is used to decrypt the nonce.
- the decrypted nonce is then signed, at step 1608 , using a private key of the user that is held securely within the portable device.
- the signing step may be carried out securely using features provided by the Android Keystore System, the iOS Keychain Services, or equivalent functionality supported under other operating systems and hardware platforms.
- the resulting decrypted and signed nonce is then transmitted to the authentication server 108 at step 1610 .
- FIG. 17 shows a flowchart 1700 illustrating a session-specific encryption process, e.g. as carried out by the authentication server 108 at steps 1506 and 1508 , according an embodiment of the invention.
- the input to the process 1700 is the nonce 1702 , as generated at step 1704 .
- one or more session-specific factors 1704 is identified and selected or retrieved, in like manner to the first embodiment as described previously with reference to FIGS. 4 and 13 .
- the factor values retrieved or determined at step 1706 are combined to form a session-specific encryption key, which is used at step 1710 to generate the encrypted nonce 1712 .
- FIG. 18 is a flowchart 1800 illustrating a process of constructing a session-specific challenge message for transmission in the step 1510 .
- the input to the process 1800 is the encrypted nonce 1712 .
- a factor selection part of the message is generated, to inform the portable device 106 of the session-specific factor types that are to be used in generation of the decryption key.
- the ‘correct’ values of the session-specific factors are not in the message constructed at step 1804 by the process 1800 , but instead comprise shared ‘secret’ information between the authentication server 108 and the portable device 106 .
- the completed challenge message is transmitted.
- FIG. 19 there is shown a flowchart 1900 illustrating an exemplary method for generating a session-specific encryption/decryption key based upon one or more session-specific factors.
- the method 1900 may be used at step 1506 of the transformation process 1500 in the authentication server 108 , and may then similarly be employed by the portable device 106 at step 1604 of the response generation process 1600 .
- storage for containing the generated key is initialised.
- an iterative algorithm i.e. steps 1904 - 1910 , is used to combine multiple session-specific factor values in a similar manner to the steps 604 - 610 in the process 600 .
- a finalisation step 1912 is then executed, which may typically comprise computing a hash value of the combined factor values to produce a key of known length to be used as part of the encryption/decryption process applied to the nonce 1702 .
- FIG. 20 is a flowchart 2000 illustrating a process of authentication performed by the authentication server 108 in response to receiving 2002 a message comprising the decrypted and signed nonce generated by the portable device 106 .
- the decrypted nonce is compared with the originally-generated nonce 1702 . If found to match, at decision step 2006 , the authentication server 108 proceeds to verify that the signature is valid, by applying the user's public key 1208 stored in the user record 1200 . If found to match, at decision step 2010 , then authentication is deemed successful 2012 . If there is a mismatch in either the value of the decrypted nonce, at decision 2006 , or in the digital signature, at decision 2010 , then authentication fails 2014 .
- FIG. 21 shows a schematic representation 2100 of a challenge message format according to the present embodiment of the invention.
- the exemplary challenge message 2100 comprises fields corresponding with the message parts constructed as described above with reference to FIG. 18 .
- the message format 2100 comprises the encrypted nonce 2102 , and a session-specific factor list 2104 which, in turn, comprises one or more subfields identifying the session-specific factors, e.g. 2104 a , 2104 b , employed in generating the encryption/decryption key.
- FIG. 22 An equivalent exemplary XML-format message content 2200 is illustrated in FIG. 22 .
- the encrypted nonce 2202 comprises a 512-bit value, represented as 64 8-bit hexadecimal numbers.
- a list 2204 of session-specific factors is also present, in the same format as has been described previously with reference to FIG. 9 .
- FIG. 23 there is shown a timeline 2300 of communications between the portable device 106 , the secure system 104 , and the authentication server 108 , according to the present embodiment of the invention.
- An access request 2302 is received by the secure server 104 , and a corresponding authorisation request 1004 , which may include a user ID or other identifying information requestor, is transmitted from the secure system 104 to the authentication server 108 .
- a session-specific challenge message 1006 is then transmitted from the authentication server 108 to the portable device 106 .
- the session-specific challenge message has the general message format 2100 , and in particular may comprise XML code such as the code 2200 illustrated in FIG. 22 .
- the endpoint device 106 then applies the session-specific factors (FL) to generate a decryption key to decrypt the encrypted nonce (N), signs the resulting value, and transmits a corresponding session-specific challenge response 1008 to the authentication server 108 .
- the authentication server 108 then performs validation of the signed nonce, as described previously with reference to FIG. 20 , and generates and transmits an authorisation result message 1010 to the secure system 104 .
- the secure system 104 uses this result to determine whether or not to grant access 2312 to the requesting user.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Life Sciences & Earth Sciences (AREA)
- Biodiversity & Conservation Biology (AREA)
- Computing Systems (AREA)
- Bioethics (AREA)
- Telephonic Communication Services (AREA)
- Collating Specific Patterns (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Burglar Alarm Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A user authentication method in a distributed processing system commences by receiving, at a first processing unit (108), a request (1004) to initiate an authentication session, wherein the request includes a unique identifier of a user requiring authentication. The first processing unit acquires at least one item of authentication data (412, 1712), which is valid during the authentication session. The authentication data is transmitted (1006) to a second processing unit (106) which is associated with a terminal device operated by the user. The second processing unit transforms the authentication data using a transformation algorithm based upon one or more session-specific authentication factors (404, 1704), to generate transformed authentication data that is characteristic of the authentication session and of the user. The transformed authentication data is transmitted (1008) to a third processing unit (108) which verifies that the transformed authentication data corresponds with the user and with predetermined values of the one or more session-specific authentication factors. The third processing unit generates an authentication result (1010) of the authentication session based upon the verification.
Description
- The present invention relates generally to authentication systems and methods, and more particularly to multifactor authentication systems with improved security and flexibility.
- Reliable and secure authentication of personal identity is an essential element of many online systems. Commonly, an authorised user of an online system or service is required to provide at least a user identifier, e.g. a user name or code, and an additional ‘secret’ code, such as a password or personal identification number (PIN). A PIN or password is an example of a knowledge factor, whereby the user is required to prove knowledge of the secret, i.e. password, phrase or PIN, for authentication.
- Knowledge factors are susceptible to attack, e.g. by eavesdropping. The most basic form of eavesdropping may involve observing a user when entering a password or PIN. Observation may be performed directly, or may involve the use of a concealed camera. More technologically sophisticated eavesdropping techniques include so called ‘man-in-the-middle’ attacks, in which malicious software is installed in terminal equipment and/or intermediate network nodes, targeting system components in which unencrypted passwords may be accessed in transit. Users may also be deceived into revealing knowledge factors, e.g. via phishing attacks.
- Authentication methods with enhanced security include two-factor authentication, in which the user is required to provide one or more additional factors as proof of identity. For example, possession factors (‘something the user has’) are most commonly used, in addition to knowledge factors. Examples of possession factors include credit cards and the like, which must be presented in conjunction with a PIN in order to gain access to a transaction system. Other forms of possession factor include disconnected tokens, which display periodically-updated random numbers for entry by the user, and uniquely identifiable personal items, such as cellular mobile phones or smartphones. Possession factors significantly increase security, but are nonetheless susceptible to theft and replication (e.g. card skimming).
- Improvements in the security of knowledge factors, providing additional protection against eavesdropping, are disclosed in the present inventor's commonly assigned U.S. Pat. Nos. 8,869,255 and 9,519,764, both of which are incorporated herein in their entirety by reference. Such systems may be further enhanced through the use of additional factors, such as possession factors. However, there remains scope for further improvement to authentication systems and methods. For example, it may be desirable to control or restrict access to a secure system based on factors other than user identity. For example, it may be desirable to ensure that users can only access a secure system using authorised devices, and/or to ensure that access can only be gained while the user is in a secure location. At the same time, it may be desirable to ensure that user credentials and other factors cannot be acquired by eavesdropping, such as man-in-the-middle attacks. Preferably, such additional security is provided in a manner that is transparent to end-users, such that there is no additional inconvenience or impediment presented to legitimate, authorised, users.
- It is, accordingly, an object of the present invention to address the foregoing need for enhanced authentication systems and methods.
- In one aspect, the invention provides a user authentication method comprising execution, by a distributed processing system, of the steps of:
- receiving, at a first processing unit, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
- the first processing unit acquiring at least one item of authentication data, valid during the authentication session;
- transmitting the authentication data to a second processing unit which is associated with a terminal device operated by the user;
- the second processing unit transforming the authentication data using a transformation algorithm based upon one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
- transmitting the transformed authentication data to a third processing unit;
- the third processing unit verifying that the transformed authentication data corresponds with the user and with predetermined values of the one or more session-specific authentication factors; and
- the third processing unit generating an authentication result of the authentication session based upon the verification.
- Advantageously, the use of session-specific authentication factors in the transformation of authentication data enables information associated with a current context of the authentication session to be incorporated into user verification. For example, the second processing unit may comprise instruction code executing on a processor of a portable personal device operated by the user, such as a dedicated digital access device running suitable software or, conveniently, a smartphone or other personal device having an installed application (i.e. an ‘app’) providing the required instruction code embodying an aspect of the invention. Accordingly, the current context information may comprise values corresponding with factors such as a geographic location of the device, a Service Set Identifier (SSID) of a wireless network visible to the device, and/or a unique identifier associated with the device. More generally, any context-specific information accessible to software code executing on the device may be employed as a session-specific authentication factor.
- In some embodiments, a secret keyword (e.g. a password or passphrase) is associated with the user, the secret keyword consisting of an ordered sequence of symbols selected from a predetermined symbol set, and wherein:
- the at least one item of authentication data includes a security matrix comprising a mapping between each symbol within the symbol set and a code value which is specific to the authentication session and which is selected from a code set which is distinct from the symbol set;
- the security matrix is transformed by the first processing unit using a transformation algorithm based upon the predetermined values of the one or more session-specific authentication factors, to generate a transformed security matrix comprising the symbol set and transformed code values;
- the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to recover the code values of the security matrix, and a user input step for receiving a sequence of code values selected from the security matrix and input by the user, the code values corresponding with the secret keyword; and
- the verifying step comprises validating the sequence of code values received in the user input step by comparison with an expected sequence of code values corresponding with the secret keyword and a mapping thereof to the code values in the security matrix.
- In such embodiments, the session-specific authentication factors are applied to ‘encode’ the mapping between symbol and code values in a keyword-based user authentication method of the type disclosed in commonly assigned U.S. Pat. Nos. 8,869,255 and 9,519,764. The second processing unit (e.g. a portable personal device operated by the user) must therefore determine and apply the same context-based values of the session-specific authentication factors in order to correctly ‘decode’ the mapping. For example, if a location-based authentication factor is applied, the first processing unit will use a predetermined value of this factor, such as the GPS coordinates of a location at which the user may be successfully authenticated, to encode the mapping. The portable device (i.e. second processing unit) will determine its own location, for example by using in-built GPS receiver hardware, and apply the resulting coordinates to decode the mapping. The device does not know the value of the GPS coordinates used to encode the mapping, but will only obtain the correct decoded mapping if its own location matches those coordinates. The user will thus only be able to successfully authenticate when present at the authorised location.
- In alternative embodiments, the authentication data comprises a session-specific one-time code word which is encrypted by the first processing unit using a transformation algorithm parameterised by the predetermined values of the one or more session-specific authentication factors;
- the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to decrypt the session-specific one-time code word, and a cryptographic signing step wherein a private cryptographic key of the user is applied to generate the transformed authentication data which comprises a signed copy of the session-specific one-time code word;
- the verifying step comprises a cryptographic verification wherein a public cryptographic key of the user is applied to confirm that the signed copy of the session-specific one-time code word was generated by the second processing unit associated with the terminal device operated by the user.
- A particular advantage of such embodiments is that session-specific authentication factors may be applied independently of any requirement for the user to provide a secret keyword (e.g. password or pass phrase) in order to access a secure system. In an exemplary scenario, a user may wish to access an online service, such as a remote desktop service provided by an employer, but may be restricted from doing so other than in an approved location, such as a home office. Upon an attempt by the user to log in to the service, the second processing unit (e.g. an authentication server) may generate a session-specific one-time code word (i.e. a nonce) such as, for example, a 256-bit or 512-bit random number. It may then encrypt the nonce using a symmetric encryption algorithm in which a key is derived from a predetermined value of a session-specific authentication factor, such as the GPS coordinates of the user's home office. Upon receiving the resulting authentication data, the user's portable device (i.e. second processing unit) will determine its own location and apply the resulting coordinates to generate a key for use in the symmetric encryption algorithm in order to decrypt the nonce. The device does not know the value of the GPS coordinates used to generate the original encryption key, but will only successfully decrypt the nonce if its own location matches those coordinates. By signing the resulting decrypted nonce with a stored private key, the device enables subsequent verification that it was able to successfully decrypt the nonce. The user will thus only be able to successfully authenticate when present, with their portable device, at the authorised location.
- In another aspect, the invention provides an authentication system comprising:
- a processor;
- a network interface, operatively associated with the processor; and
- at least one computer-readable storage device, accessible by the processor,
- wherein the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method comprising the steps of:
-
- receiving, via the network interface, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
- acquiring at least one item of authentication data, valid during the authentication session;
- transmitting, via the network interface, the authentication data to a processing unit associated with a terminal device operated by the user; and
- receiving, via the network interface, transformed authentication data generated by the processing unit associated with the terminal device operated by the user, wherein the transformed authentication data is characteristic of the authentication session and of the user,
- wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
- whereby an authentication result may be generated for the authentication session based upon the verification.
- In some embodiments, the instruction code executable by the processor is configured to cause the processor to implement the step of acquiring the at least one item of authentication data by:
- generating a session-specific one-time code word;
- retrieving, from the at least one computer-readable storage device, the predetermined values of the one or more session-specific authentication factors; and
- encrypting the one-time code word using a transformation algorithm parameterised by the predetermined values of the one or more session-specific authentication factors.
- The transformed authentication data may be configured to enable verification by confirming that it corresponds with the session-specific one-time code word that has been cryptographically signed using a private cryptographic key of the user.
- In yet another aspect, the invention provides a portable personal authentication device comprising:
- a processor;
- a network interface, operatively associated with the processor; and
- at least one computer-readable storage device, accessible by the processor,
- wherein the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method, in an authentication session of a user of the authentication device, comprising the steps of:
-
- receiving, via the network interface from an authentication system, authentication data that is valid during the authentication session;
- transforming the authentication data using a transformation algorithm based upon one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
- transmitting, via the network interface to the authentication system, the transformed authentication data,
- wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
- whereby an authentication result may be generated for the authentication session based upon the verification.
- In embodiments of the invention, the authentication data comprises an encrypted session-specific one-time code word, and the instruction code executable by the processor is configured to cause the processor to implement the step of transforming the authentication data by:
- determining values of the one or more session-specific authentication factors that are based upon a current context of the portable personal authentication device;
- applying an algorithm parameterised by the determined values of the one or more session-specific authentication factors to decrypt the authentication data and recover the session-specific one-time code word; and
- applying a private cryptographic key of the user, which is held in secure storage of the portable personal authentication device, to generate a signed copy of the of the session-specific one-time code word for transmission to the authentication system.
- In a further aspect, the invention provides a tangible computer-readable medium comprising stored program instructions which, when executed by a processor of an authentication system, cause the authentication system to implement a method comprising the steps of:
- receiving, via a network interface of the authentication system, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
- acquiring at least one item of authentication data, valid during the authentication session;
- transmitting, via the network interface, the authentication data to a processing unit associated with a terminal device operated by the user; and
- receiving, via the network interface, transformed authentication data generated by the processing unit associated with the terminal device operated by the user, wherein the transformed authentication data is characteristic of the authentication session and of the user,
- wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
- whereby an authentication result may be generated for the authentication session based upon the verification.
- In still another aspect, the invention provides a tangible computer-readable medium comprising stored program instructions which, when executed by a processor of a portable personal identification device, cause the device to implement a method comprising the steps of:
- receiving, via a network interface of the device from an authentication system, authentication data that is valid during the authentication session;
- transforming the authentication data using a transformation algorithm based upon one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
- transmitting, via the network interface to the authentication system, the transformed authentication data,
- wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
- whereby an authentication result may be generated for the authentication session based upon the verification.
- Further aspects, advantages, and features of embodiments of the invention will be apparent to persons skilled in the relevant arts from the following description of various embodiments. It will be appreciated, however, that the invention is not limited to the embodiments described, which are provided in order to illustrate the principles of the invention as defined in the foregoing statements and in the appended claims, and to assist skilled persons in putting these principles into practical effect.
- Embodiments of the invention will now be described with reference to the accompanying drawings, in which like reference numerals indicate like features, and wherein:
-
FIG. 1 is a schematic diagram illustrating an exemplary system embodying the invention; -
FIG. 2 is a flowchart of a user authentication method performed at an authentication server according to a first embodiment of the invention; -
FIG. 3 is a flowchart of a user authentication method performed at an endpoint device according to the first embodiment; -
FIG. 4 is a flowchart of a session-specific transformation process according to the first embodiment; -
FIG. 5 is a flowchart of a process of constructing a session-specific challenge mention according to the first embodiment; -
FIG. 6 is a flowchart illustrating an exemplary method for generating a session-specific transformation/encryption key according to the first embodiment; -
FIG. 7 is a flowchart illustrating an exemplary session-specific inverse transformation process according to the first embodiment; -
FIG. 8 is a schematic representation of a first challenge message format embodying the invention; -
FIG. 9 shows exemplary XML code embodying the message format ofFIG. 8 ; -
FIG. 10 shows a timeline of communications between and endpoint device, a secure system and an authentication server according to the first embodiment; -
FIG. 11 is a schematic illustration of an endpoint user authentication interface according to the first embodiment; -
FIG. 12 shows an exemplary user record; -
FIG. 13 shows an exemplary secure system record; -
FIG. 14 is a schematic diagram illustrating an alternative user authentication system and method embodying the invention; -
FIG. 15 is a flowchart illustrating a user authentication method performed at an authentication server according to a further embodiment of the invention; -
FIG. 16 is a flowchart illustrating a user authentication method as performed at a portable device according to the further embodiment; -
FIG. 17 is a flowchart illustrating a session-specific encryption process according to the further embodiment; -
FIG. 18 is a flowchart illustrating a process of constructing a session-specific challenge message according to the further embodiment; -
FIG. 19 is a flowchart illustrating an exemplary method for generating a session-specific encryption/decryption key in the methods ofFIGS. 15 and 16 ; -
FIG. 20 is a flowchart illustrating an exemplary process of authentication performed by the authentication server in response to receiving a response message generated by a portable device; -
FIG. 21 shows a schematic representation of a challenge message format according to the further embodiment; -
FIG. 22 shows exemplary XML code embodying the message format ofFIG. 21 ; and -
FIG. 23 shows a timeline of communications between and endpoint device, a secure system and an authentication server according to the further embodiment. -
FIG. 1 is a block diagram illustrating asystem 100 embodying the present invention. Apublic communications network 102, such as the Internet, is employed for messaging between asecure system 104, one or moreuser endpoint devices 106, and anauthentication server 108. Generally speaking, theuser endpoint devices 106 may be any suitable computing, communications and/or processing appliances having the ability to communicate via theInternet 102, for example using web browser software and/or other connected applications.Endpoint devices 106 may also comprise other types of terminal apparatus, such as cash dispensing machines (e.g. ATMs), point-of-sale (POS) terminals, vending machines, and so forth. Furthermore, while theexemplary system 100 comprises a single shared, insecure,network 102 for communications between all processing devices and systems, embodiments of the invention may include other types of communications and/or transaction networks, such as financial transaction networks, private networks, virtual private networks (VPNs), cellular telephony networks, or a mix of these and/or other forms of communications systems. - In this specification, terms such as ‘processor’, ‘computer’, and so forth, unless otherwise required by the context, should be understood as referring to a range of possible implementations of devices, apparatus and systems comprising a combination of hardware and software. This includes single-processor and multi-processor devices and apparatus, including portable devices, desktop computers, and various types of server systems, including cooperating hardware and software platforms that may be co-located or distributed. Hardware may include conventional personal computer architectures, or other general-purpose hardware platforms. Software may include commercially available operating system software in combination with various application and service programs. Alternatively, computing or processing platforms may comprise custom hardware and/or software architectures. For enhanced scalability, computing and processing systems may comprise cloud computing platforms, enabling physical hardware resources to be allocated dynamically in response to service demands. While all of these variations fall within the scope of the present invention, for ease of explanation and understanding the exemplary embodiments described herein are based upon single-processor general-purpose computing platforms, commonly available operating system platforms, and/or widely available consumer products, such as desktop PCs, notebook or laptop PCs, smartphones, tablet computers, and so forth.
- In particular, the term ‘processing unit’ is used in this specification (including the claims) to refer to any suitable combination of hardware and software configured to perform a particular defined task, such as generating and transmitting authentication data, receiving and processing authentication data, or receiving and validating authentication data. Such a processing unit may comprise an executable code module executing at a single location on a single processing device, or may comprise cooperating executable code modules executing in multiple locations and/or on multiple processing devices. For example, in some embodiments of the invention authentication processing may be performed entirely by code executing on
authentication server 108, while in other embodiments corresponding processing may be performed cooperatively by code modules executing onsecure system 104 andauthentication server 108. For example, embodiments of the invention may employ application programming interface (API) code modules, installed at thesecure system 104, or at another third-party system, configured to operate cooperatively with code modules executing onauthentication server 108 in order to provide thesecure system 104 with authentication services. - Software components embodying features of the invention may be developed using any suitable programming language, development environment, or combinations of languages and development environments, as will be familiar to persons skilled in the art of software engineering. For example, suitable software may be developed using the C programming language, the Java programming language, the C++ programming language, the Go programming language, and/or a range of languages suitable for implementation of network or web-based services, such as JavaScript, HTML, PHP, ASP, JSP, Ruby, Python, and so forth. These examples are not intended to be limiting, and it will be appreciated that convenient languages or development systems may be employed, in accordance with system requirements.
- In the
exemplary system 100, theendpoint devices 106 each comprise aprocessor 110. Theprocessor 110 is interfaced to, or otherwise operably associated with, acommunications interface 112, one or more user input/output (I/O) interfaces 114, andlocal storage 116, which may comprise a combination of volatile and non-volatile storage. Non-volatile storage may include solid-state non-volatile memory, such as read only memory (ROM) flash memory, or the like. Volatile storage may include random access memory (RAM). Thestorage 116 contains program instructions and transient data relating to the operation of theendpoint device 106. In some embodiments, theendpoint device 106 may include additional peripheral interfaces, such as an interface to high-capacity non-volatile storage, such as a hard disk drive, optical drive, and so forth (not shown inFIG. 1 ). - The
endpoint device storage 116 may contain program and data content relevant to the normal operation of thedevice 106. This may include operating system programs and data (e.g. associated with a Windows, Android, iOS, or MacOS operating system), as well as other executable application software generally unrelated to the present invention. Thestorage 116 also includesprogram instructions 118 which, when executed by theprocessor 110 instruct theendpoint device 106 to perform operations relating to an embodiment of the invention, for example such as are described below with reference toFIGS. 3, 6, 7, 11 and 14 . - As also shown in
FIG. 1 , theauthentication server 108 comprises aprocessor 120. Theprocessor 120 is interfaced to, or otherwise operably associated with a non-volatile memory/storage device 122, which may be a hard disk drive, and/or may include a solid-state non-volatile memory, such as ROM, flash memory, or the like. Theprocessor 120 is also interfaced tovolatile storage 124, such as RAM, which contains program instructions and transient data relating to the operation of theauthentication server 108. - In a conventional configuration, the
storage device 122 maintains known program and data content relevant to the normal operation of theauthentication server 108. For example, thestorage device 122 may contain operating system programs and data, as well as other executable application software necessary for the intended functions of theauthentication server 108. Thestorage device 122 also contains program instructions which, when executed by theprocessor 120, instruct theauthentication server 108 to perform operations relating to an embodiment of the present invention, such as are described in greater detail below with reference toFIGS. 2, 4, 5 and 6 . In operation, instructions and data held on thestorage device 122 are transferred tovolatile memory 124 for execution on demand. - The
processor 120 is also operably associated with acommunications interface 126 in a conventional manner. Thecommunications interface 126 facilitates access to thedata communications network 102. - In use, the
volatile storage 124 contains acorresponding body 128 of program instructions transferred from thestorage device 122 and configured to perform processing and other operations embodying features of the present invention. - The
secure system 104 may be any computing or processing system requiring authentication of end-users prior to permitting access and/or the performance of transactions on behalf of those users. Secure systems that may employ the services provided by embodiments of the invention include, but are not limited to, banking systems (e.g. online banking portals), e-commerce payment portals, secure computing platforms (e.g. government or employer systems), and other systems requiring secure authentication of users. - Broken lines shown in the
system 100 represent communications between anendpoint device 106, asecure system 104, and anauthentication server 108, embodying the present invention. Details of these communications are provided below, and particularly with reference toFIGS. 10 and 22 . For present purposes, with reference toFIG. 1 , a brief overview is now provided. - An end-user requiring access to a
secure system 104 may use either anendpoint device 106, or an alternative mechanism, to initiate anaccess request 1002. Thesecure system 104 uses services provided by theauthentication server 108 in order to determine whether or not to provide the end-user with the requested access. As such, anauthorisation request 1004 is transmitted by thesecure system 104 to theauthentication server 108. - The
authentication server 108 generates and transmits achallenge message 1006 to theendpoint device 106. The challenge message may be transmitted directly from theauthentication server 108 to theendpoint device 106, or may be transmitted indirectly, for example via thesecure system 104. The manner of routing thechallenge message 1006 is not critical to the general operation of embodiments of the invention. - The user is prompted for input in response to the challenge message, and a
corresponding response 1008 is transmitted back to theauthentication server 108. Theauthentication server 108 validates the response, and returns anauthorisation result 1010 to thesecure system 104. Depending upon the authorisation result, thesecure system 104 may transmit anaccess response 1012, either granting or denying access to the end-user via theendpoint device 106. Alternatively, in some embodiments the requested access may be granted via another mechanism, as described below with reference toFIG. 22 . -
FIG. 2 is aflowchart 200 showing further details of a user authentication method according to a first embodiment of the invention, from the perspective of theauthentication server 108. Atstep 202 theauthentication server 108 receives an authorisation request from thesecure system 104, which includes identifying information of the end-user, such as a user name or other user ID. - At
step 204, theauthentication server 108 generates a security matrix which is a ‘one-time’ mapping between members of a predetermined symbol set and a distinct code set. In general, the symbol set comprises a plurality of symbols, from which end-users are able to construct key words or phrases, such as passwords, or other sequences of symbols from the set used for authentication purposes. For example, the symbol set may comprise letters of the alphabet (upper- and/or lower-case), numerals, and/or selected punctuation and other special characters. - In general, the code set is a distinct plurality of code values. Preferably, the number of members of the code set is smaller than the number of members of the symbol set. The code set may be, for example, the set of decimal digits zero to nine, having the advantage that all of these code values can be entered by a user using only a PIN pad or numeric keypad.
- In general, therefore, the mapping represented by the security matrix generated at
step 204 is not ‘one-to-one’, and each code value may be mapped to multiple symbols of the symbol set. Accordingly, by creating a one-time mapping, e.g. via a random or pseudorandom process, it is not possible for any eavesdropper or observer of the communications messages passing between theendpoint device 106 and theauthentication server 108, or overlooking the actions of the end-user, to uniquely determine the keyword or phrase used for user authentication in any single observation. Furthermore, since a new security matrix is generated for each authentication instance, simply re-entering a code previously entered by the authorised user will not subsequently result in successful authentication. - The above method of authentication using one-time security matrices is also employed in the systems disclosed in the present inventor's commonly assigned U.S. Pat. Nos. 8,869,255 and 9,519,764, both of which are incorporated herein in their entirety by reference.
- At
step 206, theauthentication server 108 transforms the code values in the security matrix based upon one or more session-specific factors. Further discussion of this step is provided below, with reference toFIG. 4 . - Following transformation of the code values, the
authentication server 108 constructs and transmits a challenge message comprising the transformed security matrix, and other relevant information, to theendpoint device 106. This step is discussed in greater detail below with reference toFIG. 5 . - At
step 210, theauthentication server 108 receives a challenge response message from theendpoint device 106. The challenge response message corresponds with input provided by the end-user. In the event that theendpoint device 106 has successfully inverted the transformation performed by theauthentication server 108 atstep 206, and the user has then entered a correct sequence of code values, theauthentication server 108 will be able to reproduce the same code sequence based upon a copy of the user's keyword held within a database accessible to theauthentication server processor 120. Further details of user records maintained in the database are discussed below with reference toFIG. 12 . - Accordingly, at
step 212 theauthentication server 108 validates the received code sequence against a corresponding locally generated code sequence. From this, anauthentication result 214 is generated. In the case of a match between the received code sequence and the locally generated code sequence, a positive authentication result is generated, and transmitted to thesecure system 104. Otherwise, a negative authentication result is generated and transmitted to thesecure system 104. Based upon this authentication result, thesecure system 104 is able to grant or deny access to the end-user, via theendpoint device 106. - Turning now to
FIG. 3 , there is shown aflowchart 300 of a user authentication method as performed at an endpoint device embodying the invention. Themethod 300 is performed by theendpoint device 106 in order to receive and respond to the challenge message generated by theauthentication server 108 atstep 208. - In particular, at
step 302 theendpoint device 106 receives the challenge message including the transformed security matrix from theauthentication server 108. Atstep 304, theendpoint device 106 applies the same session-specific factors employed by theauthentication server 108 atstep 206 in order to apply an inverse transformation to the transformed code values. Having performed this inverse transformation, theendpoint device 106 has regenerated the original mapping between symbols of the symbol set and code values of the code set, according to the original security matrix generated atstep 204. - At
step 306, the original security matrix is presented to the user, for example via a display of the I/O devices 114 of theendpoint device 106. The user is enabled to respond to the displayed security matrix, which is typically accompanied by a suitable prompt, by entering a sequence of code values corresponding with the mappings and the user's personal keyword (password, passphrase, or other sequence of symbols selected from the symbol set). User input is received by theendpoint device 106 atstep 308, which then generates and transmits a message containing the entered code sequence back to theauthentication server 108. This message is received atstep 210, as discussed above with reference toFIG. 2 . -
FIG. 4 shows aflowchart 400 illustrating a session-specific transformation process, e.g. as carried out by theauthentication server 108 atstep 206, according an embodiment of the invention. The input to theprocess 400 is thesecurity matrix 402, as generated atstep 204. In particular, atstep 406 one or more session-specific factors 404 is identified and selected or retrieved. The session-specific factors typically depend upon the requirements of thesecure system 104. Accordingly, the session-specific factors may be retrieved from a database record that is associated with thesecure system 104. The session-specific factors may also depend upon other characteristics of the current session, such as the particular user, the location of the endpoint device, the time/date, and/or any other identifiable properties of the session. - According to the presently described embodiment of the invention, therefore, one or more session-specific factors are retrieved from a
record 406 matching the predefined properties of the present session. In particular, corresponding values of the session-specific factors are retrieved, or determined, for use in thetransformation method 400. Examples of factor types and values that may be employed in embodiments of the invention include, but are not limited to: -
- the present user, represented by the user ID;
- endpoint device location, represented by GPS coordinates determined to a specified precision;
- a predetermined device- or user-specific key, which has been pre-agreed and stored at both the
endpoint device 106 and theauthentication server 108, such as a digital certificate, or a random value generated during a user or device registration process; - one or more unique identifying values associated with the
endpoint device 106, such as a network interface (MAC) address, a Wi-Fi station ID, an Internet protocol version 6 (IPv6) address, a mobile telephony number, SIM identifier, or other hardware device (e.g. CPU) serial number; - a changing value generated according to an algorithm shared by the
endpoint device 106 and theauthentication server 108, such as a pseudorandom sequence based upon a seed generated during a user or device registration process; - one or more Service Set Identifiers (SSIDs) of wireless networks visible to the
endpoint device 106, and/or a number of visible SSIDs; - an SSID of a wireless network to which the
endpoint device 106 is presently connected; - identifying information of a mobile cellular carrier to which the
endpoint device 106 is connected; - time and/or date;
- data provided by a local beacon or network-attached device accessible to the
endpoint device 106 at the time/place of authentication; - biometric data, e.g. from a fingerprint reader of the
endpoint device 106 and/or facial identification/classification data obtained from an image captured by a camera of theendpoint device 106;
- At
step 408, the factor values retrieved or determined atstep 404 are combined to form a session-specific transformation/encryption key. Any suitable algorithm may be used to combine the factors. For example, the combined factors may comprise a concatenation of values of one or more session-specific factors, a hash generated from the values of the one or more session-specific factors, or any other suitable function producing an output that is based upon all of the input session-specific factor values. - The combined result may further be employed in any suitable manner in order to transform the code values of the
security matrix 402. For example, the combined value may be used as an encryption key in a symmetric encryption algorithm applied to the code values. For example, a simple symmetric transformation/encryption algorithm is to compute a transformed code sequence by a bitwise exclusive OR (XOR) operation between the code values and the key value. More sophisticated symmetric ciphers include DES, 3DES, AES-256, AES-512, and Blowfish. Suitable keys for use with such ciphers may be derived from combined session-specific factors values by use of a suitable hashing function, such as—without limitation—SHA-256 or SHA-512. Preferably, a symmetric algorithm is employed, so that theendpoint device 106 is able to reverse the transformation after generating the same transformation/encryption key from combined values of the session-specific factors. An eavesdropper, however, will be unable to perform the reverse transformation, without knowledge of the values of the session-specific factors that are shared by theauthentication server 108 and theendpoint device 106, but never transmitted via thenetwork 102. - Accordingly, at
step 410 the key comprising the combined, and optionally hashed, values of the session-specific factors are applied to the code values of thesecurity matrix 402 resulting in the transformedsecurity matrix 412, which is provided for use at thetransmission step 208. -
FIG. 5 is aflowchart 500 illustrating a process of constructing a session-specific challenge message for transmission in thetransmission step 208. The input to theprocess 500 is the transformedsecurity matrix 412. At step 502 a symbol set part of the message is generated, based upon the symbol set included in thesecurity matrix 412. Similarly, at step 504 a transformed code set part of the message is generated based upon the transformed code values within the transformedsecurity matrix 412. - In accordance with the presently described embodiment, a valid code part is generated at
step 506. The purpose of the valid code part of the message is to communicate to theendpoint device 106 the complete set of valid code values, for example the decimal digits zero to nine. The way in which this information may be employed by theendpoint device 106 is described in greater detail below with reference toFIG. 7 . - At
step 508, a factor selection part of the message is generated, to inform theendpoint device 106 of the session-specific factor types that are to be used for reversing the transformation of the code values. Note that the values of the session-specific factors are not in the message constructed by theprocess 500, but instead comprise shared ‘secret’ information between theauthentication server 108 and theendpoint device 106. - At
step 510, the message parts are combined in order to construct the complete challenge message, which is then transmitted atstep 512. - Turning now to
FIG. 6 , there is shown aflowchart 600 illustrating an exemplary method for generating a session-specific transformation/encryption key based upon one or more session-specific factors. Themethod 600 may be used atstep 408 of thetransformation process 400 in theauthentication server 108, and may then similarly be employed by theendpoint device 106 in order to generate the key for performing the corresponding inverse transformation. - At
step 602, storage for containing the generated key is initialised. This may involve clearing a corresponding block of memory, or initialising a block of memory to some other value known to both theauthentication server 108 and theendpoint device 106. In some cases, the initialisation value may itself be session-specific, e.g. based upon a unique session ID, or upon network addresses of theauthentication server 108 andendpoint device 106. - In the
exemplary process 600 an iterative algorithm is used to combine multiple session-specific factor values. Accordingly, at decision step 604 a check is performed to determine whether there are further factor values still to be combined. If so, the next factor is selected atstep 606, and the corresponding factor value is retrieved or determined atstep 608. Atstep 610, the new factor value is combined, e.g. by concatenation or other algorithmic method, into the transformation key. Control then returns to thedecision step 604, to determine whether there are more factor values to be determined and combined. - Once all factor values have been incorporated, an
optional finalisation step 612 is executed. For example, a finalisation step may comprise computing a hash value of concatenated factor values to produce a key of known length to be used as part of the transformation or encryption process applied to the code values in thesecurity matrix 402. -
FIG. 7 is aflowchart 700 illustrating a session-specific inverse transformation process that may be performed at anendpoint device 106, according to embodiments of the invention. Atstep 702 the transformation key, which is obtained according to thesame process 600 as was employed by theauthorisation server 108, is applied to the transformed code values in an inverse transformation, in order to generate candidate code values. Note that these are identified as ‘candidate code values’, since any mismatch between the session-specific factor values applied by theauthentication server 108 and by the endpoint device 106 (e.g. in the case of an attempted fraudulent authentication) will result in the generation of incorrect and/or invalid code values. - In particular, the application of an incorrect transformation key in the inverse transformation process may result in one or more candidate code values that are invalid code values. For example, if code values are limited to the decimal digits zero to nine, an invalid inverse transformation may result in other characters or symbols being generated. A check is performed for any such invalid code values, at
step 704. The invalid code part of the challenge message, generated atstep 506, may be used by theendpoint device 106 in order to identify such invalid code values. If invalid values are present, they are replaced atstep 706 with valid codes selected from the valid code part of the challenge message. The selection may be random, or performed via any other suitable method. As a result of this replacement step, the user will always be presented with a security matrix that appears valid, and will therefore be unaware of the possibility that a fraudulent authentication attempt has been detected and thwarted. -
FIG. 8 shows aschematic representation 800 of a challenge message format according to the first embodiment of the invention. Theexemplary challenge message 800 comprises a number of fields, corresponding with the message parts constructed as described above with reference toFIG. 5 . In particular, themessage format 800 comprises asymbol set 802, a transformed code set 804, a valid code set 806, and a session-specific factor list 808. The session-specific factor list 808 comprises one or more subfields identifying the session-specific factors, e.g. 808 a, 808 b, employed in generating the transformation/encryption key, e.g. as described above with reference toFIG. 6 . -
FIG. 9 showsexemplary XML code 900 embodying a challenge message according to theformat 800. In the example shown, the symbol set 902 comprises 26 letters of the alphabet, in upper case. The transformed code set 904 is the result of applying thetransformation process 400 to a corresponding set of 26 code values. In theexemplary XML message 900, the transformed code set 904 comprises 26 eight-bit values, each of which is represented as two hexadecimal digits. - The
XML code 900 further comprises the set of valid code values 906, which in this example consist of the decimal digits zero to nine. - An
XML element 908 encloses the list of session-specific factors endpoint device 106 and theauthentication server 108. - In the example represented by the
XML code 900, the transformed code set 904 will be converted back to the correct original code set if: -
- the correct user ID is being used on the endpoint device;
- the location of the endpoint device as represented by GPS coordinates with four decimal place precision, matches an authorised location known to the
authentication server 108; and - the pre-shared key employed by the endpoint device matches the key employed by the authentication server, e.g. the software installed on the endpoint device is from a legitimate, trusted and authorised source.
- Turning now to
FIG. 10 , there is shown atimeline 1000 of communications between theendpoint device 106, thesecure system 104, and anauthentication server 108 embodying the invention. Anaccess request 1002 is transmitted from theendpoint device 106 to thesecure server 104, and acorresponding authorisation request 1004, which may include a user ID or other identifying information provided by the endpoint device user, is transmitted from thesecure system 104 to theauthentication server 108. At this point, it may be assumed that theauthentication server 108 is able to identify both the particularsecure system 104 to which access is requested, and the user requesting access via theendpoint device 106. - A session-
specific challenge message 1006 is then transmitted from theauthentication server 108 to theendpoint device 106. The session-specific challenge message 1006 has thegeneral message format 800, and in particular may comprise XML code such as thecode 900 illustrated inFIG. 9 . - The
endpoint device 106 then inverts the transformation in order to recover the original sequence of code values, and displays the security matrix comprising pairs of keyword symbols and code values to the user of the endpoint device. The user enters code values corresponding with the user keyword, and a corresponding session-specific challenge response 1008 is transmitted from theendpoint device 106 to theauthentication server 108. - The
authentication server 108 then performs validation of the code sequence entered by the user, and generates and transmits anauthorisation result message 1010 to thesecure system 104. Theauthorisation result message 1010 will indicate whether or not the user successfully authenticated. A correspondingaccess response message 1012, indicating whether theendpoint device 106 is granted or denied access to thesecured system 104, is then transmitted. - The
timeline 1000 may be interpreted more generally as a representation of communications between three processing units, independently of the specific combinations of location, hardware and software used to implement each unit. A first processing unit corresponds with theauthentication server 108, which receives the request comprising a unique identifier of the user requiring authentication, generates session-specific authentication data (i.e. the challenge), and transmits the authentication data to a second processing unit corresponding with theendpoint device 106. The second processing unit generates transformed authentication data that is characteristic of the authentication session and of the user, and transmits this to a third processing unit for verification. In the embodiment represented by thetimeline 1000, the third processing unit is an executable code module which executes on the same authenticationserver hardware platform 108 as the first processing unit, however in general this function may reside wholly or partially elsewhere, such as with an API code module executing on thesecure system 104, or on another trusted platform. -
FIG. 11 is a schematic illustration of an endpointuser authentication interface 1100 embodying the invention. Theexemplary interface 1100 includes a prompt 1102, e.g. the text ‘please enter the digits corresponding with your password using PIN pad’. Below the prompt 1102, thesecurity matrix 1104 is displayed. Thesecurity matrix 1104 comprises paired symbol values and corresponding code values. In the example 1100, there are 30 symbol values comprising 26 letters of the alphabet and four special characters, which are paired with code values comprising the decimal digits zero to nine. - Accordingly, the user can enter the code values corresponding with the symbol values of the user's password via the PIN pad, or
numeric keypad 1106. Thekeypad 1106 may be a physical device, or may be generated on a touchscreen display. Alternative forms of user input may be employed, such as voice recognition, or other means of data entry. - As has been mentioned previously, the
authentication server 108 also maintains one or more databases, for example withinnon-volatile storage 122, or other persistent storage accessible to theprocessor 120. One or more databases maintained by theauthentication server 108 include a database comprising user records, and a database comprising secure system records. User records correspond with users who may be permitted access to one or more secure systems, e.g. 104. Secure system records correspond with one or more secure systems, e.g. 104, for which theauthentication server 108 provides authentication services. -
FIG. 12 shows schematically the contents of anexemplary user record 1200, which may be maintained in a database by theauthentication server 108. Theexemplary user record 1200 comprises auser identifier field 1202, and afield 1204 containing the user's keyword/password. For additional security, the keyword/password filed 1204 may be encrypted until the user's keyword is required by theauthentication server 108 for authentication of attempted access by the user to asecure system 104. Theuser record 1200 may contain one or more user information fields 1206. Additionaluser information fields 1206 may include personal information, such as the user's real name, contact details, and so forth, and/or may contain other system-specific information, such as authorisation expiry dates or any other information that may be required in a specific implementation of the invention. Also shown is afield 1208 for storing one or more public cryptographic keys of the user. While these public keys are not required in the present embodiment, an application of user public keys is described in greater detail below with respect to a further embodiment of the invention and with reference toFIGS. 15 to 22 . -
FIG. 13 illustrates schematically asecure system record 1300. Asecure system record 1300 may comprise asystem identifier 1302, corresponding with a particularsecure system 104, and may further compriseauthentication information 1304.Authentication information 1304 may comprise, for example, a password, public key, or other information that can be used by theauthentication server 108 in order to identify and verify requests from a secure system, e.g. 104. - Each
secure system record 1300 further contains one or more factor lists 1306. Afactor list 1306 may compriseselection criteria 1308. For example, a particular factor list may be employed for a particular endpoint device or location, a particular user, or at particular times of day. An appropriate factor list may therefore be selected by theauthentication server 108, in relation to a correspondingsecure system 104, by matching parameters of the current authentication request and/or context against theselection criteria 1308. - Each
factor list 1306 comprises one or more factor entries, e.g. 1310 a, 1310 b. Each factor entry comprises a factor type (e.g. ‘ID’, ‘GPS:4’, ‘PSK’, as exemplified inFIG. 9 ). Where required, a factor entry may also comprise a factor value corresponding with the factor type. Factor values may comprise, for example, a permitted user ID, an authorised endpoint location, or the value (optionally encrypted for additional security) of a pre-shared key. - An
authentication server 108 which maintainssecure system records 1300 may be configured for a very wide variety of different use cases. - In one exemplary use case, the
secure system 104 may provide access to critical records which are to be available only within a particular secure building. This can be implemented by using a location factor with a value corresponding with the building location. If the location of theendpoint device 106 does not match the corresponding factor value, authentication will fail and access will be denied. Alternative factor lists may be provided for use in association with fixed terminals that are physically located within the building. For example, for each such fixed terminal a factor list may be provided having one or more factor types corresponding with physical parameters of the terminal such as MAC address, and/or other unique hardware component identifier. Accordingly, attempts to access thesecure system 104 from such terminals can be successfully authenticated, even though the fixed terminals may not generally have the ability to independently determine their location. - In another exemplary use case, a
secure system 104 may be a secure computing platform, e.g. an office server, to which access may only be permitted from authorised, business-supplied, endpoint devices. For example, an employee may be permitted to access theserver 104 from a company laptop based upon a MAC address of the laptop, and/or other unique hardware identification numbers. By combining a number of hardware-based factors, theauthentication server 108 may regulate access to thesecure system 104 based upon unique hardware signatures ofendpoint devices 106, even if a malicious user attempts to spoof the system, e.g. by changing the MAC address of a network interface on an unauthorised device. - Turning to
FIG. 14 there is shown a schematic diagram 1400 illustrating an alternative user authentication system and method embodying the invention. In theembodiment 1400 anendpoint device 1402 is distinct from auser device 1404. Theuser device 1404 may be, for example, a portable device such as a smartphone or tablet. The fixedendpoint device 1402 includes adisplay 1406. When the user requests access, the session-specific challenge message 1006 is converted by theendpoint device 1402 into a machine-readable code, such as a QR code. - Using an application installed on the
portable device 1404, the user scans the machine-readable code, which is decoded by the application. The application then implements the inverse transformation of the transformed code values, and displays the resulting security matrix to the user. The user enters the sequence of code values corresponding with their keyword into theportable device 1404. The resulting session-specific response 1008, comprising the code entered by the user, is transmitted to theauthentication server 108. The application on theuser device 1404 may be configured with identifying information of the authentication server or may obtain the relevant identifying information from the code acquired from theendpoint device display 1406. In the event that authentication is successful, the user is then provided with access to thesecure system 104 via theendpoint device 1402. - The
embodiment 1400 accordingly has the advantage of providing ‘arm's length’ authentication, via a user'spersonal device 1404, wherein the user enters authentication information only into theirown device 1404, and never into theendpoint device 1402. This arrangement enables enhanced multifactor authentication, depending upon something the user has (their portable device 1404), something the user knows (their keyword), along with any further factors that may be defined in a factor list corresponding with thesecure system 104 that the user is attempting to access. - A further enhancement to multifactor authentication, based upon a portable digital device as a ‘possession factor’ of a user, will now be described by way of a further exemplary embodiment of the invention, with reference to
FIGS. 15 to 22 . The general system configuration of this further embodiment remains as shown 100 inFIG. 1 , however theendpoint device 106 is now a portable personal device such as a dedicated digital access device running suitable software or, conveniently, a smartphone or other personal device having an installed application (i.e. an ‘app’) providing the required instruction code embodying required functionality of the invention. Furthermore, while thedevice 106 may be operated by the user to request access to a secure system, an access request may be generated independently of the device. For example, the user may request access to an online system from a web browser executing on a desktop computer by entering only a unique identifier, such as a user name, thereby triggering a remotesecure system 104 to generate an authentication request to aremote authentication server 108. Communications with theportable device 106, as described in more detail below with reference toFIG. 22 , then carry out the authentication method to enable an authentication result to be generated by or to thesecure system 104. -
FIG. 15 is aflowchart 1500 showing further details of a user authentication method according to the further embodiment of the invention, from the perspective of theauthentication server 108. Atstep 1502 theauthentication server 108 receives an authorisation request from thesecure system 104, which includes identifying information of the end-user, such as a user name or other user ID. Atstep 1504, theauthentication server 108 generates a session-specific one-time code word, commonly known in the art as a ‘nonce’, which may be, for example, a random number of an appropriate length, e.g. 256 or 512 bits. - At
step 1506, theauthentication server 108 generates an encryption key based upon one or more session-specific factors. Further discussion of this step is provided below, with reference toFIG. 17 . The encryption key is used to encrypt the nonce atstep 1506, for example using a symmetric cipher such as DES, 3DES, AES-256, AES-512 or Blowfish. A challenge message comprising the encrypted nonce, and other relevant information, is then transmitted to theportable device 106, as discussed in greater detail below with reference toFIG. 18 . Subsequently, at step 152, theauthentication server 108 receives a challenge response message from theportable device 106, which comprises a digitally signed copy of the original, decrypted, nonce. In the event that theendpoint device 106 has successfully replicated the key generation performed by theauthentication server 108 atstep 1506, and has applied the user's private key for signing, theauthentication server 108 will be able to validate the nonce and verify the signature using apublic key 1208 of the user atstep 1514. From this, anauthentication result 1516 is generated. - Turning now to
FIG. 16 , there is shown aflowchart 1600 of a user authentication method as performed at aportable device 106, such as a smartphone executing an app comprising code embodying the invention. In particular, atstep 1602 thedevice 106 receives the challenge message including the encrypted nonce from theauthentication server 108. At step 1604, thedevice 106 applies the same session-specific factors employed by theauthentication server 108 atstep 1506 in order to replicate the symmetric encryption/decryption key used to encrypt the nonce. Atstep 1606 this key is used to decrypt the nonce. The decrypted nonce is then signed, atstep 1608, using a private key of the user that is held securely within the portable device. For example, in the that case the portable device is a smartphone, the signing step may be carried out securely using features provided by the Android Keystore System, the iOS Keychain Services, or equivalent functionality supported under other operating systems and hardware platforms. The resulting decrypted and signed nonce is then transmitted to theauthentication server 108 at step 1610. -
FIG. 17 shows aflowchart 1700 illustrating a session-specific encryption process, e.g. as carried out by theauthentication server 108 atsteps process 1700 is the nonce 1702, as generated atstep 1704. In particular, atstep 1706 one or more session-specific factors 1704 is identified and selected or retrieved, in like manner to the first embodiment as described previously with reference toFIGS. 4 and 13 . Atstep 1708, the factor values retrieved or determined atstep 1706 are combined to form a session-specific encryption key, which is used atstep 1710 to generate theencrypted nonce 1712. -
FIG. 18 is aflowchart 1800 illustrating a process of constructing a session-specific challenge message for transmission in thestep 1510. The input to theprocess 1800 is theencrypted nonce 1712. Atstep 1802, a factor selection part of the message is generated, to inform theportable device 106 of the session-specific factor types that are to be used in generation of the decryption key. As in the first embodiment described above, the ‘correct’ values of the session-specific factors are not in the message constructed atstep 1804 by theprocess 1800, but instead comprise shared ‘secret’ information between theauthentication server 108 and theportable device 106. Atstep 1806, the completed challenge message is transmitted. - Turning now to
FIG. 19 , there is shown aflowchart 1900 illustrating an exemplary method for generating a session-specific encryption/decryption key based upon one or more session-specific factors. Themethod 1900 may be used atstep 1506 of thetransformation process 1500 in theauthentication server 108, and may then similarly be employed by theportable device 106 at step 1604 of theresponse generation process 1600. Atstep 1902, storage for containing the generated key is initialised. In theexemplary process 1900 an iterative algorithm, i.e. steps 1904-1910, is used to combine multiple session-specific factor values in a similar manner to the steps 604-610 in theprocess 600. Once all factor values have been incorporated, afinalisation step 1912 is then executed, which may typically comprise computing a hash value of the combined factor values to produce a key of known length to be used as part of the encryption/decryption process applied to thenonce 1702. -
FIG. 20 is aflowchart 2000 illustrating a process of authentication performed by theauthentication server 108 in response to receiving 2002 a message comprising the decrypted and signed nonce generated by theportable device 106. Firstly, atstep 2004, the decrypted nonce is compared with the originally-generatednonce 1702. If found to match, atdecision step 2006, theauthentication server 108 proceeds to verify that the signature is valid, by applying the user'spublic key 1208 stored in theuser record 1200. If found to match, atdecision step 2010, then authentication is deemed successful 2012. If there is a mismatch in either the value of the decrypted nonce, atdecision 2006, or in the digital signature, atdecision 2010, then authentication fails 2014. -
FIG. 21 shows aschematic representation 2100 of a challenge message format according to the present embodiment of the invention. Theexemplary challenge message 2100 comprises fields corresponding with the message parts constructed as described above with reference toFIG. 18 . In particular, themessage format 2100 comprises theencrypted nonce 2102, and a session-specific factor list 2104 which, in turn, comprises one or more subfields identifying the session-specific factors, e.g. 2104 a, 2104 b, employed in generating the encryption/decryption key. - An equivalent exemplary XML-
format message content 2200 is illustrated inFIG. 22 . In the example shown, theencrypted nonce 2202 comprises a 512-bit value, represented as 64 8-bit hexadecimal numbers. A list 2204 of session-specific factors is also present, in the same format as has been described previously with reference toFIG. 9 . - Turning now to
FIG. 23 , there is shown atimeline 2300 of communications between theportable device 106, thesecure system 104, and theauthentication server 108, according to the present embodiment of the invention. Anaccess request 2302 is received by thesecure server 104, and acorresponding authorisation request 1004, which may include a user ID or other identifying information requestor, is transmitted from thesecure system 104 to theauthentication server 108. A session-specific challenge message 1006 is then transmitted from theauthentication server 108 to theportable device 106. In this embodiment, the session-specific challenge message has thegeneral message format 2100, and in particular may comprise XML code such as thecode 2200 illustrated inFIG. 22 . Theendpoint device 106 then applies the session-specific factors (FL) to generate a decryption key to decrypt the encrypted nonce (N), signs the resulting value, and transmits a corresponding session-specific challenge response 1008 to theauthentication server 108. Theauthentication server 108 then performs validation of the signed nonce, as described previously with reference toFIG. 20 , and generates and transmits anauthorisation result message 1010 to thesecure system 104. Thesecure system 104 uses this result to determine whether or not to grantaccess 2312 to the requesting user. - It should be appreciated that while particular embodiments and variations of the invention have been described herein, further modifications and alternatives will be apparent to persons skilled in the relevant arts. In particular, the examples are offered by way of illustrating the principles of the invention, and to provide a number of specific methods and arrangements for putting those principles into effect. In general, embodiments of the invention rely upon providing technical arrangements whereby a verification code can be independently generated in two remote locations, and a corresponding transformation/encryption key can also be independently generated, e.g. at an authentication server location and at an endpoint device location. The transformation/encryption key is dependent upon one or more session-specific factors, such that attempts to access a secure system without authority can be thwarted based on a wide range of criteria. Such criteria include, but are not limited to, endpoint device location, an endpoint device hardware signature, time of day, and so forth.
- Accordingly, the described embodiments should be understood as being provided by way of example, for the purpose of teaching the general features and principles of the invention, but should not be understood as limiting the scope of the invention, which is as defined in the appended claims.
Claims (16)
1-15. (canceled)
16. A user authentication method comprising execution, by a distributed processing system, of the steps of:
receiving, at a first processing unit, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
the first processing unit acquiring at least one item of authentication data, valid during the authentication session;
transmitting the authentication data to a second processing unit which is associated with a terminal device operated by the user;
the second processing unit automatically transforming the authentication data using a transformation algorithm parameterised by context-dependent values of one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
transmitting the transformed authentication data to a third processing unit;
the third processing unit verifying that the transformed authentication data corresponds with the user and with predetermined values of the one or more session-specific authentication factors; and
the third processing unit generating an authentication result of the authentication session based upon the verification.
17. The method of claim 16 wherein a secret keyword is associated with the user, the secret keyword consisting of an ordered sequence of symbols selected from a predetermined symbol set, and wherein:
the at least one item of authentication data includes a security matrix comprising a mapping between each symbol within the symbol set and a code value which is specific to the authentication session and which is selected from a code set which is distinct from the symbol set;
the security matrix is transformed by the first processing unit using a transformation algorithm based upon the predetermined values of the one or more session-specific authentication factors, to generate a transformed security matrix comprising the symbol set and transformed code values;
the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to recover the code values of the security matrix, and a user input step for receiving a sequence of code values selected from the security matrix and input by the user, the code values corresponding with the secret keyword; and
the verifying step comprises validating the sequence of code values received in the user input step by comparison with an expected sequence of code values corresponding with the secret keyword and a mapping thereof to the code values in the security matrix.
18. The method of claim 16 wherein:
the authentication data comprises a session-specific one-time code word which is encrypted by the first processing unit using a transformation algorithm parameterised by the predetermined values of the one or more session-specific authentication factors;
the transformation algorithm of the second processing unit includes an inverse transformation algorithm configured to decrypt the session-specific one-time code word, and a cryptographic signing step wherein a private cryptographic key of the user is applied to generate the transformed authentication data which comprises a signed copy of the session-specific one-time code word;
the verifying step comprises a cryptographic verification wherein a public cryptographic key of the user is applied to confirm that the signed copy of the session-specific one-time code word was generated by the second processing unit associated with the terminal device operated by the user.
19. The method of claim 16 wherein the one or more session-specific authentication factors comprises at least one of:
a geographic location of the terminal device operated by the user;
one or more Service Set Identifiers (SSIDs) of wireless networks visible to the terminal device operated by the user;
an SSID of a wireless network to which the terminal device is connected;
identifying information of a mobile cellular carrier to which the terminal device is connected
a unique identifier associated with the terminal device operated by the user;
the unique identifier of the user;
a predetermined device- or user-specific key value;
a changing value generated according to a predetermined algorithm;
time and/or date;
data provided by a local beacon or network-attached device accessible to the terminal device; and
biometric data of the user.
20. The method of claim 16 wherein:
the first processing unit comprises instruction code executing on a processor of a service provider computer system and/or a processor of an authentication server system; and
the second processing unit comprises instruction code executing on a processor of the terminal device operated by the user.
21. The method of claim 20 wherein the terminal device operated by the user is a portable device carried by the user.
22. The method of claim 16 wherein the third processing unit comprises instruction code executing on a processor of a service provider computer system and/or a processor of an authentication server system.
23. An authentication system comprising:
a processor;
a network interface, operatively associated with the processor; and
at least one computer-readable storage device, accessible by the processor,
wherein the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method comprising the steps of:
receiving, via the network interface, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
acquiring at least one item of authentication data, valid during the authentication session;
transmitting, via the network interface, the authentication data to a processing unit associated with a terminal device operated by the user; and
receiving, via the network interface, transformed authentication data
automatically generated, using a transformation algorithm parameterised by context-dependent values of one or more session-specific authentication factors, by the processing unit associated with the terminal device operated by the user, wherein the transformed authentication data is characteristic of the authentication session and of the user,
wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
whereby an authentication result may be generated for the authentication session based upon the verification.
24. The system of claim 23 wherein the instruction code executable by the processor is configured to cause the processor to implement the step of acquiring the at least one item of authentication data by:
generating a session-specific one-time code word;
retrieving, from the at least one computer-readable storage device, the predetermined values of the one or more session-specific authentication factors; and
encrypting the one-time code word using a transformation algorithm parameterised by the predetermined values of the one or more session-specific authentication factors.
25. The system of claim 24 wherein the transformed authentication data is configured to enable verification by confirming that it corresponds with the session-specific one-time code word that has been cryptographically signed using a private cryptographic key of the user.
26. A portable personal authentication device comprising:
a processor;
a network interface, operatively associated with the processor; and
at least one computer-readable storage device, accessible by the processor,
wherein the storage device comprises instruction code executable by the processor and configured to cause the processor to implement a method, in an authentication session of a user of the authentication device, comprising the steps of:
receiving, via the network interface from an authentication system,
authentication data that is valid during the authentication session;
automatically transforming the authentication data using a transformation algorithm parameterised by context-dependent values of one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
transmitting, via the network interface to the authentication system, the transformed authentication data,
wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
whereby an authentication result may be generated for the authentication session based upon the verification.
27. The portable personal authentication device of claim 26 wherein the authentication data comprises an encrypted session-specific one-time code word, and the instruction code executable by the processor is configured to cause the processor to implement the step of transforming the authentication data by:
determining the context-dependent values of the one or more session-specific authentication factors that are based upon a current context of the portable personal authentication device;
applying an algorithm parameterised by the determined context-dependent values of the one or more session-specific authentication factors to decrypt the authentication data and recover the session-specific one-time code word; and
applying a private cryptographic key of the user, which is held in secure storage of the portable personal authentication device, to generate a signed copy of the session-specific one-time code word for transmission to the authentication system.
28. The portable personal authentication device of claim 27 wherein the one or more session-specific authentication factors comprises at least one of:
a geographic location of the portable personal authentication device operated by the user;
one or more Service Set Identifiers (SSIDs) of wireless networks visible to the portable personal authentication device operated by the user;
an SSID of a wireless network to which the portable personal authentication device is connected;
identifying information of a mobile cellular carrier to which the portable personal authentication device is connected
a unique identifier associated with the portable personal authentication device operated by the user;
the unique identifier of the user;
a predetermined device- or user-specific key value;
a changing value generated according to a predetermined algorithm;
time and/or date;
data provided by a local beacon or network-attached device accessible to the portable personal authentication device; and
biometric data of the user.
29. A tangible computer-readable medium comprising stored program instructions which, when executed by a processor of an authentication system, cause the authentication system to implement a method comprising the steps of:
receiving, via a network interface of the authentication system, a request to initiate an authentication session, the request comprising a unique identifier of a user requiring authentication;
acquiring at least one item of authentication data, valid during the authentication session;
transmitting, via the network interface, the authentication data to a processing unit associated with a terminal device operated by the user; and
receiving, via the network interface, transformed authentication data automatically generated, using a transformation algorithm parameterised by context-dependent values of one or more session-specific authentication factors, by the processing unit associated with the terminal device operated by the user, wherein the transformed authentication data is characteristic of the authentication session and of the user,
wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
whereby an authentication result may be generated for the authentication session based upon the verification.
30. A tangible computer-readable medium comprising stored program instructions which, when executed by a processor of a portable personal authentication device, cause the device to implement a method comprising the steps of:
receiving, via a network interface of the device from an authentication system, authentication data that is valid during the authentication session;
automatically transforming the authentication data using a transformation algorithm parameterised by context-dependent values of one or more session-specific authentication factors, to generate transformed authentication data that is characteristic of the authentication session and of the user;
transmitting, via the network interface to the authentication system, the transformed authentication data,
wherein the transformed authentication data is configured to enable verification that it corresponds with the user and with predetermined values of the one or more session-specific authentication factors,
whereby an authentication result may be generated for the authentication session based upon the verification.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/241,986 US20210264010A1 (en) | 2016-03-18 | 2021-04-27 | Method and system for user authentication with improved security |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2016901019A AU2016901019A0 (en) | 2016-03-18 | Method and system for user authentication with improved security | |
AU2016901019 | 2016-03-18 | ||
PCT/AU2017/050240 WO2017156590A1 (en) | 2016-03-18 | 2017-03-17 | Method and system for user authentication with improved security |
US201816085768A | 2018-09-17 | 2018-09-17 | |
US17/241,986 US20210264010A1 (en) | 2016-03-18 | 2021-04-27 | Method and system for user authentication with improved security |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/AU2017/050240 Continuation WO2017156590A1 (en) | 2016-03-18 | 2017-03-17 | Method and system for user authentication with improved security |
US16/085,768 Continuation US11017067B2 (en) | 2016-03-18 | 2017-03-17 | Method and system for user authentication with improved security |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210264010A1 true US20210264010A1 (en) | 2021-08-26 |
Family
ID=59850010
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/085,768 Active 2037-06-12 US11017067B2 (en) | 2016-03-18 | 2017-03-17 | Method and system for user authentication with improved security |
US17/241,986 Abandoned US20210264010A1 (en) | 2016-03-18 | 2021-04-27 | Method and system for user authentication with improved security |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/085,768 Active 2037-06-12 US11017067B2 (en) | 2016-03-18 | 2017-03-17 | Method and system for user authentication with improved security |
Country Status (16)
Country | Link |
---|---|
US (2) | US11017067B2 (en) |
EP (1) | EP3430554A4 (en) |
JP (1) | JP2019512961A (en) |
KR (1) | KR20180117715A (en) |
CN (1) | CN109074437A (en) |
AU (1) | AU2017233545A1 (en) |
BR (1) | BR112018068884A2 (en) |
CA (1) | CA3017533A1 (en) |
EA (1) | EA201892109A1 (en) |
HK (1) | HK1258980A1 (en) |
IL (1) | IL261810B2 (en) |
MA (1) | MA45323A (en) |
PH (1) | PH12018501983A1 (en) |
SG (1) | SG11201807995TA (en) |
WO (1) | WO2017156590A1 (en) |
ZA (1) | ZA201806243B (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230048912A1 (en) * | 2021-08-10 | 2023-02-16 | Keyless Technologies Srl | Authentication processing services for generating high-entropy cryptographic keys |
WO2024108281A1 (en) * | 2022-11-25 | 2024-05-30 | Clovis Golfetto | System and method for unique user authentication |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2565282B (en) * | 2017-08-02 | 2021-12-22 | Vnc Automotive Ltd | Remote control of a computing device |
US10834170B2 (en) * | 2018-03-19 | 2020-11-10 | Citrix Systems, Inc. | Cloud authenticated offline file sharing |
US10693648B2 (en) * | 2018-03-26 | 2020-06-23 | Ca, Inc. | System and method for dynamic grid authentication |
US10999081B2 (en) * | 2018-04-12 | 2021-05-04 | Microsoft Technology Licensing, Llc | Dynamic certificate management for a distributed authentication system |
CN108833117B (en) * | 2018-07-25 | 2020-11-10 | 海南新软软件有限公司 | Private key storage and reading method and device and hardware equipment |
US11134084B1 (en) * | 2018-08-22 | 2021-09-28 | Hid Global Corporation | Diversified authentication and access control |
US11336430B2 (en) * | 2018-09-07 | 2022-05-17 | Sap Se | Blockchain-incorporating distributed authentication system |
WO2020096739A1 (en) * | 2018-11-09 | 2020-05-14 | Carrier Corporation | Geographically secure access to container controller |
CN114513330A (en) * | 2019-04-24 | 2022-05-17 | 华为技术有限公司 | Parameter sending method and device |
KR102259764B1 (en) * | 2019-09-06 | 2021-06-02 | 주식회사 엘핀 | Apparatus for performing multi factor authentication and operation method thereof |
US20220376933A1 (en) * | 2019-09-25 | 2022-11-24 | Commonwealth Scientific And Industrial Research Organisation | Cryptographic services for browser applications |
US11146954B2 (en) | 2019-10-08 | 2021-10-12 | The Toronto-Dominion Bank | System and method for establishing a trusted session |
US11722312B2 (en) * | 2020-03-09 | 2023-08-08 | Sony Group Corporation | Privacy-preserving signature |
CN112615834B (en) * | 2020-12-08 | 2023-04-07 | 北京北信源软件股份有限公司 | Security authentication method and system |
CN112579566B (en) * | 2020-12-14 | 2023-03-31 | 浪潮云信息技术股份公司 | Distributed ID generation method and device |
US11539689B2 (en) * | 2021-01-19 | 2022-12-27 | Visa International Service Association | System, method, and apparatus for authenticating a user device |
CN113014386B (en) * | 2021-03-30 | 2023-06-02 | 宋煜 | Cryptographic system based on multiparty collaborative computing |
US20240005312A1 (en) * | 2022-07-01 | 2024-01-04 | Bank Of America Corporation | Multi-Factor User Authentication Using Blockchain Tokens |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5592553A (en) * | 1993-07-30 | 1997-01-07 | International Business Machines Corporation | Authentication system using one-time passwords |
US20110197266A1 (en) * | 2005-12-09 | 2011-08-11 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20130124292A1 (en) * | 2010-07-29 | 2013-05-16 | Nirmal Juthani | System and method for generating a strong multi factor personalized server key from a simple user password |
US20140040628A1 (en) * | 2012-08-03 | 2014-02-06 | Vasco Data Security, Inc. | User-convenient authentication method and apparatus using a mobile authentication application |
US20140222955A1 (en) * | 2013-02-01 | 2014-08-07 | Junaid Islam | Dynamically Configured Connection to a Trust Broker |
US8869255B2 (en) * | 2010-11-30 | 2014-10-21 | Forticom Group Ltd | Method and system for abstracted and randomized one-time use passwords for transactional authentication |
US9949115B2 (en) * | 2014-06-10 | 2018-04-17 | Qualcomm Incorporated | Common modulus RSA key pairs for signature generation and encryption/decryption |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104517094A (en) * | 2013-09-30 | 2015-04-15 | 阿里巴巴集团控股有限公司 | Identity authentication method and identity authentication device |
-
0
- MA MA045323A patent/MA45323A/en unknown
-
2017
- 2017-03-17 JP JP2018549219A patent/JP2019512961A/en active Pending
- 2017-03-17 EA EA201892109A patent/EA201892109A1/en unknown
- 2017-03-17 KR KR1020187030011A patent/KR20180117715A/en unknown
- 2017-03-17 US US16/085,768 patent/US11017067B2/en active Active
- 2017-03-17 CN CN201780025080.8A patent/CN109074437A/en active Pending
- 2017-03-17 WO PCT/AU2017/050240 patent/WO2017156590A1/en active Application Filing
- 2017-03-17 EP EP17765582.6A patent/EP3430554A4/en not_active Withdrawn
- 2017-03-17 BR BR112018068884A patent/BR112018068884A2/en not_active Application Discontinuation
- 2017-03-17 CA CA3017533A patent/CA3017533A1/en not_active Abandoned
- 2017-03-17 AU AU2017233545A patent/AU2017233545A1/en not_active Abandoned
- 2017-03-17 SG SG11201807995TA patent/SG11201807995TA/en unknown
-
2018
- 2018-09-14 PH PH12018501983A patent/PH12018501983A1/en unknown
- 2018-09-16 IL IL261810A patent/IL261810B2/en unknown
- 2018-09-17 ZA ZA2018/06243A patent/ZA201806243B/en unknown
-
2019
- 2019-01-28 HK HK19101464.4A patent/HK1258980A1/en unknown
-
2021
- 2021-04-27 US US17/241,986 patent/US20210264010A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5592553A (en) * | 1993-07-30 | 1997-01-07 | International Business Machines Corporation | Authentication system using one-time passwords |
US20110197266A1 (en) * | 2005-12-09 | 2011-08-11 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20130124292A1 (en) * | 2010-07-29 | 2013-05-16 | Nirmal Juthani | System and method for generating a strong multi factor personalized server key from a simple user password |
US8869255B2 (en) * | 2010-11-30 | 2014-10-21 | Forticom Group Ltd | Method and system for abstracted and randomized one-time use passwords for transactional authentication |
US20150040204A1 (en) * | 2010-11-30 | 2015-02-05 | Forticom Group Ltd | Method and system for abstracted and randomized one-time use passwords for transactional authentication |
US20140040628A1 (en) * | 2012-08-03 | 2014-02-06 | Vasco Data Security, Inc. | User-convenient authentication method and apparatus using a mobile authentication application |
US20140222955A1 (en) * | 2013-02-01 | 2014-08-07 | Junaid Islam | Dynamically Configured Connection to a Trust Broker |
US9949115B2 (en) * | 2014-06-10 | 2018-04-17 | Qualcomm Incorporated | Common modulus RSA key pairs for signature generation and encryption/decryption |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230048912A1 (en) * | 2021-08-10 | 2023-02-16 | Keyless Technologies Srl | Authentication processing services for generating high-entropy cryptographic keys |
US11936775B2 (en) * | 2021-08-10 | 2024-03-19 | Keyless Technologies Srl | Authentication processing services for generating high-entropy cryptographic keys |
WO2024108281A1 (en) * | 2022-11-25 | 2024-05-30 | Clovis Golfetto | System and method for unique user authentication |
Also Published As
Publication number | Publication date |
---|---|
MA45323A (en) | 2019-01-23 |
CA3017533A1 (en) | 2017-09-21 |
US20190034612A1 (en) | 2019-01-31 |
US11017067B2 (en) | 2021-05-25 |
KR20180117715A (en) | 2018-10-29 |
ZA201806243B (en) | 2019-07-31 |
BR112018068884A2 (en) | 2019-01-22 |
EA201892109A1 (en) | 2019-02-28 |
SG11201807995TA (en) | 2018-10-30 |
CN109074437A (en) | 2018-12-21 |
JP2019512961A (en) | 2019-05-16 |
IL261810A (en) | 2018-10-31 |
PH12018501983A1 (en) | 2019-07-01 |
HK1258980A1 (en) | 2019-11-22 |
AU2017233545A1 (en) | 2018-10-04 |
IL261810B2 (en) | 2023-06-01 |
EP3430554A1 (en) | 2019-01-23 |
EP3430554A4 (en) | 2019-09-04 |
WO2017156590A1 (en) | 2017-09-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210264010A1 (en) | Method and system for user authentication with improved security | |
US11647023B2 (en) | Out-of-band authentication to access web-service with indication of physical access to client device | |
CN105850073B (en) | Information system access authentication method and device | |
US11336641B2 (en) | Security enhanced technique of authentication protocol based on trusted execution environment | |
US8661254B1 (en) | Authentication of a client using a mobile device and an optical link | |
US9722794B2 (en) | System and method for remote access, remote digital signature | |
US10523441B2 (en) | Authentication of access request of a device and protecting confidential information | |
US20160205098A1 (en) | Identity verifying method, apparatus and system, and related devices | |
US20170085561A1 (en) | Key storage device and method for using same | |
US9445269B2 (en) | Terminal identity verification and service authentication method, system and terminal | |
US20200021448A1 (en) | Public-private key pair account login and key manager | |
US20180025332A1 (en) | Transaction facilitation | |
WO2019226115A1 (en) | Method and apparatus for user authentication | |
CN109981665B (en) | Resource providing method and device, and resource access method, device and system | |
RU2698424C1 (en) | Authorization control method | |
CA2904646A1 (en) | Secure authentication using dynamic passcode | |
KR101705293B1 (en) | Authentication System and method without secretary Password | |
Chen et al. | Biometric-based remote mutual authentication scheme for mobile device | |
US11343078B2 (en) | System and method for secure input at a remote service | |
Fietkau et al. | Secure Authentication for Everyone! Enabling 2nd-Factor Authentication Under Real-World Constraints |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FORTICODE LIMITED, AUSTRALIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMALES, ANTONY;REEL/FRAME:056059/0126 Effective date: 20180920 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |