US20160182500A1 - Systems and methods for anonymous authentication using multiple devices - Google Patents
Systems and methods for anonymous authentication using multiple devices Download PDFInfo
- Publication number
- US20160182500A1 US20160182500A1 US14/788,152 US201514788152A US2016182500A1 US 20160182500 A1 US20160182500 A1 US 20160182500A1 US 201514788152 A US201514788152 A US 201514788152A US 2016182500 A1 US2016182500 A1 US 2016182500A1
- Authority
- US
- United States
- Prior art keywords
- user
- user devices
- authentication challenge
- computing device
- response
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 80
- 230000004044 response Effects 0.000 claims abstract description 153
- 230000015654 memory Effects 0.000 claims description 30
- 230000008569 process Effects 0.000 claims description 19
- 238000010200 validation analysis Methods 0.000 claims description 7
- 230000001413 cellular effect Effects 0.000 claims description 2
- 230000005540 biological transmission Effects 0.000 claims 3
- 239000002253 acid Substances 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 19
- 238000004891 communication Methods 0.000 description 16
- 239000004984 smart glass Substances 0.000 description 14
- 238000013461 design Methods 0.000 description 4
- 230000007812 deficiency Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008867 communication pathway Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
-
- 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
-
- 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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
Definitions
- a traditional method of authentication can involve prompting a user for a username and password.
- a method of authentication can be prone to error and can require the user to recall hard-to-remember passwords.
- Another traditional method of authentication can involve receiving a unique property of the user, such as a fingerprint, to identify a user.
- a unique property of the user such as a fingerprint
- Such a method of authentication can be vulnerable to discovery of the user property. For example, an attacker who obtains a fingerprint of a user (or a facsimile thereof) can then falsely log in as the actual user.
- Another traditional method of authentication can involve presentation of a token (e.g., smart card) issued to the authorized user.
- a token e.g., smart card
- Such a method of authentication can be attacked by stealing the token.
- the present invention provides a system and method for authentication of an associated set of users which overcomes the deficiencies of the prior art authentication systems by requiring that at least two registered user devices be utilized in the authentication process, wherein access is granted to the associated set of user devices. Requiring more than one device for user authentication and granting access to an associated set of user devices instead of an individual user device of the set of user devices, provides increased security and anonymity by eliminating the possibility of unauthorized access through the use of a single registered user device and by preventing the authentication system from knowing which of the users has been granted access to the system.
- a method of authentication using at least two devices includes, receiving, at an authenticator computing device, a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the one device requesting access to the resource registered to more than one user. The method continues by generating an authentication challenge at the authenticator computing device in response to the request and transmitting the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource.
- the authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset,
- the method continues by generating at least one response to the authentication challenge at one or more user devices of the subset of user devices and transmitting the at least one response to the authenticator computing device.
- the method continues by determining, at the authenticator computing device, if the at least one response constitutes a valid response to the authentication challenge and granting any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received at the authenticator computing device constitutes a valid response to the authentication challenge.
- a forwarding policy for the authenticator computing device and a forwarding policy for each of the user devices of the associated set of user devices can be used to determine the subset of user devices that will receive the authentication challenge. Additionally, each of the user devices of the associated set of user devices may utilize a response policy to determine whether or not the user device is required to generate a response to a received authentication challenge and the authenticator computing device may utilize a validation policy to determine which responses are required to be valid to grant access to the associated set of user devices.
- one or more non-transitory computer-readable media having computer-executable instructions for performing a method of running a software program on a computing device, the method including issuing instructions from the software program.
- the instructions may include, receiving, at an authenticator computing device, a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the one device requesting access to the resource registered to more than one user.
- the instructions may further include, generating an authentication challenge at the authenticator computing device in response to the request and transmitting the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource.
- the authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset.
- the instructions may additionally include, generating at least one response to the authentication challenge at one or more user devices of the subset of user devices and transmitting the at least one response to the authenticator computing device.
- the instruction may also include, determining, at the authenticator computing device, if the at least one response constitutes a valid response to the authentication challenge and granting any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received at the authenticator computing device constitutes a valid response to the authentication challenge.
- an authentication system including, an authenticator computing device configured to receive a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the device requesting access to the resource registered to more than one user, to generate an authentication challenge in response to the request and to transmit the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource.
- the authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset.
- the authenticator computing device of the authentication system is further configured to receive at least one response to the authentication challenge from one or more user devices of the subset of user devices, to determine if the at least one response constitutes a valid response to the authentication challenge and to grant any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received constitutes a valid response to the authentication challenge.
- the present invention provides a system and method for anonymous authentication of a user device requesting access to a resource by authenticating an associated set of user devices, utilizing two or more registered user devices of an associated set of users devices, wherein the user device requesting access to the resource is registered to more than one user, wherein authentication decisions for the associated set of user devices are based on receipt of at least one valid response from a user device in response to at least one authentication challenge sent to a subset of user devices that includes at least one user device other than the requesting user device.
- the present invention thus overcomes the deficiencies of the authentication systems and methods currently known in the art.
- FIG. 1 is a block diagram illustrating a design overview of various embodiments of an authentication system implemented in a networked environment, in accordance with an embodiment of the present invention.
- FIG. 2 is a block diagram illustrating a design overview of various embodiments of an authentication system implemented in a networked environment, in accordance with an embodiment of the present invention.
- FIG. 3 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 4 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 5 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 6 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 7 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 8 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 9 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 10 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention.
- FIG. 11 is a schematic block diagram illustrating an exemplary device employed in the networked environment of the authentication system, in accordance with an embodiment of the present invention.
- the present disclosure describes systems and methods for authenticating “users” (which can be human users, devices, processes, clients, etc.). Authentication decisions can be based on the existence of cryptographic signatures from some set of devices (sometimes referred to as “tokens”) associated with the user, During registration, the authenticator (e.g., an “authentication server”) can associate devices with users and/or each other. This description therefore uses the term “registered” to mean “associated”; the devices “registered” with a user are “associated” with that user and/or with each other. Each device can have one or more associated cryptographic keys (which, in some embodiments, can be shared with the authenticator and/or other devices).
- tokens some set of devices
- the authenticator can associate a plurality of devices with each user, the associated devices need not store any data indicating or identifying the existence of other devices associated with the same user. Instead, the authenticator can associate multiple devices with each user and can thereafter require a valid cryptographic signature (or MACs, message authentication codes, or other valid responses) from some subset of a user's associated devices before authenticating that user.
- a valid cryptographic signature or MACs, message authentication codes, or other valid responses
- the association of multiple devices with each user can prevent theft of devices.
- a theft-based attack can require the attacker to steal all the devices in the subset. For example, if a smart phone and smart watch are associated with a particular user and the verifier requires signatures from both of these devices before an access can be granted, then a theft-based attack would require stealing both the smart phone and smart watch.
- the present disclosure describes systems and methods for verifying (i.e., authenticating) a device (i.e., the device's user) using at least one other device associated with the user.
- a device i.e., the device's user
- the present disclosure describes various embodiments of an authentication system that can comprise a verifier and at least two user devices, where the verifier and the user devices can communicate, in one embodiment, the authentication of the requesting device is performed using another device of the user that is in close proximity to the requesting device.
- the authentication system described herein can comprise a multitude of different user devices that are available in a networked environment and can be configured to be authenticated.
- the authentication system can transmit an authentication challenge to a first device associated with a user.
- An authentication challenge can be a task, involving a second device, required to be completed in order to authenticate the first device.
- the authentication challenge can comprise randomly generated data (i.e., a nonce) that the user must transmit to at least one other device, in order to be authenticated.
- a prover can refer to an entity who is executing the authentication challenge to prove the identity or validity of the first device. In other words, the prover can be the at least one other user device used to authenticate the requesting device.
- a system for authenticating devices can comprise a verifier configured to receive a registration for multiple computing devices associated with a user and to determine whether to authenticate the requesting device.
- the authenticator can be, for example, a secure server comprising a data store configured to store the registration of multiple devices associated with multiple respective users.
- the verifier can be used to verify the identity of a user.
- a user can register a first device by entering a user credential, such as an email address of the user, and a name for the first device.
- the user can also register a second device by entering the same user credential for the user and a name for the second device.
- the user can register multiple devices to be associated with the user credential.
- Each device registered with the user can be stored in the data store of the verifier.
- the system can require the user to register the second device within a predetermined time period to prevent security attacks during the registration phase.
- the authentication system can receive a request from the first device to access one or more resources, where a “resource” can, for example, be an application, file, process, port, service (such as opening a physical lock or connecting to a web service), network bandwidth, device, memory, and/or processor time.
- the system can determine if there are at least two devices registered with the user to perform the multiple device authentication.
- the verifier can send an authentication challenge, possibly encrypted, to the first device desiring to access the resource.
- the authentication challenge can be dynamically generated random data (e.g., a cryptographic nonce) that the second device can receive to authenticate the first device.
- the first device can send, possibly by broadcasting, the authentication challenge to the second device registered with the user.
- the second device can receive the authentication challenge from the first device.
- the second device can take a picture of the authentication challenge that is displayed on the screen of the first device (e.g., as a barcode, such as a QR code).
- the second device having received the authentication challenge, can transmit a response to the verifier.
- the verifier can then determine whether the second device is registered with the user. For example, the verifier can determine that the second device is registered under the same email address as the first device.
- the verifier can determine whether the response received from the second device is valid with respect to the authentication challenge transmitted to the first device.
- the authentication system can authorize access to the resource to the first device.
- the authentication challenge transmitted to the first device is a nonce encrypted using the first device's cryptographic public key
- a valid response from the second device is a version of said nonce signed with the second device's cryptographic private key.
- a valid response from the second device requires participation of both the first and second devices' private keys (the first device's private key being necessary to decrypt the nonce, so that the nonce can be transmitted to, and then encrypted and/or signed by, the second device).
- a theft-based attack on the authentication system requires theft of both devices.
- each device can store only its own private key.
- Other embodiments may incorporate additional devices, nonces, encryptions, decryptions, and signatures, as should be appreciated, to provide secure communications while assuring that a plurality of devices participate in the authentication of a first device.
- multiple devices can be associated with a user and the user may be required to use the devices to be authenticated and gain access to a resource. However, the user does not necessarily need to utilize all of the associated devices to gain access to a resource.
- n devices can be associated with the user, a subset of in devices can be required to participate in responding to an authentication challenge (participation may include forwarding, decrypting, signing, and/or transmitting a challenge and/or response). In general, it is required that 2 ⁇ m ⁇ n, wherein both n and m need to be greater than or equal to 2 and m needs to be less than or equal to n.
- Device association can also be shared among users, and a device can be associated with multiple users.
- a first user can be associated with a first smart phone and a first smart watch and a second user can be associated with the first smart phone and a second smart watch. Both the first user and the second user can access the authentication system by using the shared first smart phone and their respective associated devices. As such, even if an attacker has access to the first smart phone, they will still be unable to authenticate as the first user and as the second user.
- a system and method are provided for anonymously authenticating a user requesting access to a resource.
- the authenticator e.g., an “authentication server”
- the authenticator can establish an associated set of user devices and can associate each of the user devices of the associated set of user devices with more than one user.
- the authenticator can then grant access to a requested resource to any user associated with the associated set of user devices using at least two user devices of the associated set of user devices.
- anonymous authentication is provided to a user requesting access to a resource by granting access to all of the users within the associated set of user devices.
- a device has the same access level as allowed for any device in the associated set.
- This method provides anonymity and plausible deniability to the user because the authenticator does not know exactly which user has been authenticated, only that multiple of the devices in one associated set of devices successfully responded to the authentication challenges.
- multiple devices could be associated with multiple users.
- any one of the users can access the system by using these devices.
- the system doesn't know which specific user requested or was granted access, so the authentication becomes anonymized, and the authenticated user device has plausible deniability.
- Anonymous authentication requiring two user devices of an associated set of user devices can be useful in various scenarios, such as for the purpose of verifying that a user is a member of a neighborhood crime reporting group, without specifically identifying the neighbor, to allow for the anonymous reporting of crime tips.
- Anonymous authentication has additional practical application in similar scenarios involving company or government whistleblower or anonymous sources for news, undercover agent reporting without specific identification of the agent and anonymous feedback from students, employees, etc.
- Additional practical applications include providing services to authenticated members of organizations, such as companies or universities providing free shuttle or bus services to their employees or students, without tracking or ever determining the specific individuals using those services.
- the systems and methods disclosed herein can avoid the cost of general security tokens by using devices already possessed by the user. Therefore, the systems and methods disclosed herein can be easily deployable. All devices registered with a user can be granted a private key, or can create their own private key, during the registration phase. In this regard, if one device registered with a user is stolen, the attacker still needs the private key of at least one other device registered by the user to authenticate the stolen device.
- the authentication system 100 can comprise an authenticator computing device 103 , a requesting client device 105 A, a verifier client device 105 B, network 109 , and/or other components.
- the requesting client device 105 A and the verifier client device 105 B, also referred to hereinafter as devices 105 can each belong to a user. That is to say, the devices 105 can be trusted devices registered with the authentication system 100 .
- the authenticator computing device 103 can comprise a validator 115 , an authentication challenge generator 118 , and/or other elements, such as other hardware and software, for implementing processes or algorithms.
- the validator 115 can be configured to perform the actual validation test. That is to say, the validator 115 can be configured to determine whether an authentication challenge sent to the requesting client device 105 A matches a response received from the verifying client device 105 B. Based on the result of that determination, the validator 115 can determine whether or not to authenticate the requesting client device 105 A.
- the authentication challenge generator 118 can be configured to generate the authentication challenge sent to the requesting client device 105 A. Either the authentication challenge generator 118 and/or the validator 115 can be configured to store the authentication challenge 127 sent and received in the data store 112 along with a corresponding verified device identifier 130 .
- the authenticator computing device 103 can also comprise a data store 112 configured to store user credentials 124 , authentication challenges 127 , verified device identifiers 130 , and/or other data values.
- the user credentials 124 can comprise data regarding the devices 105 associated with each user.
- user credentials 124 can comprise a username, password, email address, security questions and answers, and/or any other data related to a user with a registered client device 105 .
- the authentication challenges 127 can comprise the authentication challenges sent to the requesting client device 105 A and received from the verifying client device 105 B.
- the authentication challenges 127 can comprise encrypted and/or plaintext data that have been sent to the requesting client device 1054 and/or received from one or more verifying client devices 105 B
- the verified device identifiers 130 can comprise data regarding devices 105 that a user has registered with the authenticator computing device 103 . For example, when a user registers a device 105 , the user can be prompted to enter a device name. The device name can be stored as a verified device identifier 130 in the data store 112 .
- the components of the authenticator computing device 103 can be distributed among several devices, which combine to perform the actions of the authenticator computing device 103 .
- the components of a requesting client device 1054 can be distributed among several devices, which combine to act as a requesting device 1054 and the components of a verifying client device 105 B can be distributed among several devices, which combine to act as a verifying client device 105 B.
- the requesting client device 105 A can be the device requesting authentication to access an application.
- the verifying client devices 105 B can be the device(s) that the requesting client device 105 A must communicate with to authenticate the requesting client device 105 A.
- the client devices 105 must be in proximity to one another to complete authentication successfully. Alternatively, the client devices 105 must only be able to communicate with one another to successfully complete authentication.
- the requesting client device 105 A and the verifying client device 105 B may belong to an associated set of client devices 160 .
- anonymous authentication of a user of a client device of the associated set of client devices 160 is provided by associating the client devices with multiple users and by using two or more of the client devices in the associated set of client devices 160 to anonymously authenticate the user.
- FIG. 2 shown is another block diagram illustrating a design overview and communication pathway of various embodiments of an authentication system 100 implemented in a networked environment.
- the requesting client device 105 A and the verifying client device 105 B can perform a task, otherwise referred to herein as a authentication challenge, which includes a particular interaction between the requesting client device 105 A and the verifying client device 105 B to prove the identity of the user and/or the requesting client device 105 A.
- the authenticating computing device 103 can be a secure system which the user of requesting client device 105 A and the verifying client device 105 B can access.
- the requesting client device 105 A, the verifying client device 105 B, and the authenticator computing device 103 can communicate over a network in the networked environment, as shown in FIG. 1 and FIG. 2 .
- the requesting client device 105 A, the verifying client device 105 B, and the authenticator computing device 103 can be configured to communicate without a network.
- the requesting client device 105 A and the verifying client device 105 B can together be embodied as the prover 260 of the authentication system 100 .
- each of the devices 105 can comprise a processor-based system, such as a computer system, a server computer, or any other system providing computing capability.
- the devices 105 and the authenticator computing device 103 can be employed or arranged, for example, in one or more server banks, computer banks, or other arrangements.
- the devices 105 can comprise various components configured to be executed on the device 105 .
- the components executed on the device 105 can include applications, services, processes, systems, engines, or other functionality.
- Each device 105 can include a display, such as, liquid crystal display (LCD) screens, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electronic ink displays, or other types of display devices, etc.
- LCD liquid crystal display
- OLED organic light emitting diode
- the devices 105 can be embodied in the form of a laptop computer, personal digital assistants, cellular telephones, smart phones, music players, web pads, tablet computer systems, game devices, electronic book readers, or other devices 105 with like capability.
- the devices 105 can also be embodied as any mechanical structure comprising a processor-based system.
- the devices 105 can be configured to connect to a network.
- the device 105 can be a vehicle, such as a car, that can connect to a network to access the authentication system 100 .
- the device 105 can be a lock on a door of a car, room, or house that comprises a processor-based system that can connect to a network.
- the device 105 can be a garage door or a road gate that comprises a processor-based system that can connect to a network.
- the device 105 can be a smart wearable device, such as a smart watch, a smart ring, smart glasses, or any smart apparel that a user can wear as an item of clothing or accessory that comprises a processor-based system and can connect to a network.
- the device 105 can be jewelry/apparel, including rings, necklaces, glasses, watches, earrings, shirts, pants, coats, handkerchiefs, hats, bracelets, scarves, hairclips, shoes, or belts.
- the authentication system 100 can require the user to perform an authentication challenge.
- This authentication challenge can be, for example, to transmit a particular random number from the requesting client device 105 A to the verifying client device 105 B.
- This pseudo random number can be generated by the challenge generator 118 , and then transmitted from the authenticator computing device 103 to the requesting client device 105 A.
- the pseudo random number can then be transmitted to the verifying client device 105 B and back to validator 115 of the authenticator computing device 103 .
- the validator 115 can determine whether the number received from the verifying client device 105 B matches the number transmitted to the requesting client device 105 A.
- This random number can be dynamically generated, such as a nonce or a one-time password (OTP).
- OTP one-time password
- the resource that the user of the requesting client device 105 A is requesting access to can require a pre-determined number of verifying client devices 105 B to be used in authenticating the requesting client device 105 A.
- the application can require that the user of the requesting client device 105 A have three or more registered verifying client devices 105 B capable of communicating with the requesting client device 105 A that the user wants to access with the application.
- a user can register any number of devices 105 with the system.
- the prover can include an n number of trusted devices 105 associated with a user (where n is at least two). Therefore, an application can also require any number of verifying client devices 105 B to be used in response to the authentication challenge presented for authentication.
- the authentication system 100 can be an efficient method of authenticating a user for applications that require frequent re-authentication. For example, suppose a user opens a loan repayment application on a mobile device of the user. The application can require the user to frequently re-authenticate the mobile device due to the sensitive nature of the information displayed by the application. In this way, the user can easily re-authenticate the mobile device using another registered verifying client device 105 B. In the same way, multiple device authentications via the authentication system 100 is relatively more secure than traditional methods of re-authentication, also known as continuous authentication, because it requires multiple devices 105 registered to a user to be able to communicate with each other during the entire session. In one embodiment, the authentication system 100 can require multiple devices 105 registered with a user to be in proximity to each other during the entire session.
- the authenticator computing device 103 can lock out and force the use of a recovery path (to re-register device(s)) after a pre-defined threshold number of consecutive bad attempts.
- the pre-defined threshold number of consecutive bad attempts can depend on the reason an attempt was bad, e.g., “took too long to reply” or “didn't reply” or “returned invalid response to authentication challenge”. In one embodiment, the pre-defined threshold number of consecutive bad attempts can be higher for “taking too long to reply” or “didn't reply.” in another embodiment, the pre-defined threshold number of consecutive bad attempts can be smaller for “returned invalid response to authentication challenge.”
- a user can register the at least two devices 105 belonging to the user with the authentication system 100 .
- the user can register a pair of smart glasses by first entering an email address of the user and a device name of the smart glasses via a user interface of the smart glasses.
- the user interface of the smart glasses will prompt the user to register at least one verifying client device 105 B belonging to the user within a defined time limit, for example, of about five minutes. In this way, the user has five minutes to register another device 105 .
- the user can, fir example, register a smart watch belonging to the user by entering the email address of the user and a device name for the smart watch via a user interface of the smart watch within the defined time limit.
- the authentication system 100 can store the device names of the smart glasses and the smart watch in association with the email address of the user in a data store, for example, in the authenticator computing device 103 .
- the user wishes to access an application on the smart watch of the user where the application requires the user to login.
- the application can execute the login via the authentication system 100 .
- the authenticator computing device 103 can automatically send an authentication challenge to the smart watch.
- the user can request an authentication challenge from the authenticator computing device 103 via a user interface on the smart watch.
- the application can prompt the user to login by broadcasting the authentication challenge data (e.g., a nonce) to the paired device (smart glasses) via the display of the smart watch.
- the authentication challenge data can be displayed as a QR code on the screen of the smart watch, for example.
- the user can take a picture of the QR code displayed on the smart watch using a camera of the smart glasses.
- the smart glasses can receive the broadcasted in any manner of communication enabled between the smart watch and the smart glasses.
- the smart glasses can then automatically transmit the picture of the authentication challenge data to the authenticator computing device 103 to verify the identity of the user of the smart watch. If the authenticator computing device 103 determines that the response received from the smart glasses matches an expected response for the authentication challenge sent to the smart watch, then the user can be granted access to the application. In this way, the user will have successfully logged into the application.
- the smart glasses can comprise an application to facilitate the authentication process.
- the user can initiate an application configured to automatically transmit a received authentication challenge, as a response, to the authenticator computing device 103 .
- the user can manually transmit a received authentication challenge, as a response, to the authenticator computing device 103 .
- the smart ring that comprises a near field communication (“NFC”) antenna, NFC transmitter, NFC chip, and/or any other component such that the smart ring is capable of NFC.
- NFC near field communication
- the user also owns a mobile telephone also comprising an NFC antenna, NFC transmitter, NFC chip, and/or any other component such that the mobile telephone is capable of NFC. Therefore, the smart ring and the mobile telephone can communicate with each other via NFC.
- the user can register both the smart ring and the mobile telephone in accordance with the process described herein.
- the mobile telephone of the user can comprise an application that is capable of authenticating the user via the authentication system 100 .
- the user of the mobile telephone can open the application which requires the user to login.
- the mobile telephone can comprise a user interface displaying a randomly generated authentication challenge received from the authenticator computing device 103 that can be broadcasted to the smart ring via NFC. If the user is wearing the smart ring while the user is trying to log in to the application on the mobile telephone, the user can simply open up the authentication application on the smart ring, if necessary, and receive the broadcasted authentication challenge data on the smart ring via NFC.
- the authentication application on the smart ring can automatically transmit the authentication challenge data received in the smart ring to the authenticator computing device 103 .
- the smart ring can transmit a signed version of the authentication challenge data to the smart phone, which then forwards the signed authentication challenge data to the authenticator computing device 103 .
- the authenticator computing device 103 can compare the authentication challenge sent to the mobile telephone to the response received from the smart ring and/or smart phone. If the response is valid for the authentication challenge (e.g., the response is determined to be an appropriately signed version of the authentication challenge data), then the user will be logged into the application on the mobile telephone and granted access to the requested resource. If the response is not valid for the authentication challenge (e.g., the response is determined not to be an appropriately signed version of the authentication challenge data), then the user can be notified of an authentication failure on the user interface of the mobile telephone.
- a user can have access to all registered devices 105 on his or her person (e.g., a phone, ring, watch, etc.).
- a lock e.g., hotel room, car door, office door, garage door, etc.
- the data communication can happen automatically.
- the lock can be embodied as the requesting client device 105 A
- at least one of the registered devices 105 on his or her person can be embodied as the verifying client device 105 B.
- one of the registered devices 105 on the user can automatically initiate communication with the lock once the devices 105 come within a threshold proximity to the lock. Once the communication is initiated, the authentication protocol can automatically be executed with or without any user involvement.
- the user wearing the verifying client device 105 B can simply hold the verifying client device 105 B and/or stand within the threshold proximity of the lock as the authentication challenge data is transmitted from the authenticator computing device 103 , to the lock, to the verifying client device 105 B, and back to the authenticator computing device 103 .
- the lock can act as the authenticator 103 , in a system in which the user is in possession of a plurality of devices (e.g., a smart ring and a smart military necklace, a smart “dog tag”) on his or her person.
- a smart ring may initiate the authentication protocol with the lock by requesting access (i.e., requesting that the lock be opened).
- the lock sends an authentication challenge to the smart ring.
- the smart ring then sends the authentication challenge to the smart necklace, which may then respond directly to the lock (or indirectly via the smart ring).
- the protocol may execute automatically, without user involvement, based on proximity to the lock.
- the smart ring acts as the requesting client device 105 A
- the smart necklace acts as the verifying client device 105 B.
- a theft-based attack in this embodiment would require stealing both the ring and necklace.
- the authentication system and methods described herein can be used between two or more drones that are in proximity to one another. For example, suppose one drone, embodied as the requesting client device 105 A, is requesting access to a resource that requires authentication using another verifying client device 105 B. Therefore, if another registered device, for example another drone, is within a threshold proximity of the drone requesting access to the application, then the drones may automatically perform the authentication challenge to authenticate the requesting drone.
- a set of users/entities can access a resource as one group, wherein each entity is itself a device.
- the group can be authenticated through response from a subset of these entities and the authentication can proceed absent human intervention.
- Yet another embodiment can relate to theft security of devices 105 and/or accessing data from devices 105 .
- the car can contain an in-car navigation or in-car entertainment system, for example, that requires the smart phone for access.
- the in-car navigation or in-car entertainment system can comprise sensitive information regarding the user.
- the in-car navigation or in-car entertainment system can be set up such that it has to be authenticated with another device 105 of the user, such as the smart phone, prior to operation. Therefore, a thief will not be able to authenticate the in-car navigation or in-car entertainment system unless the thief also stolen the user's smart phone.
- the in-car navigation or in-car entertainment stores private data of the user, such as a home and work address, times of day when the victim is not home, etc.
- implementing multiple device 105 authentications can protect such sensitive information.
- the user can be required to first register at least two different devices 105 in a defined time interval to prevent attacks during the registration process.
- the time between registering each of the devices 105 must be less than the defined time interval.
- the system can require the user to enter a minimum amount of information, such as a user credential and a device name.
- the user credential can be an email address that identifies a particular user in the database.
- the number of devices 105 a user registers can be a choice based on the requirements of the authenticator, which may base its requirements on the particular resources that may be accessed.
- registering a device 105 can only be performed one time, and a user cannot unregister a device 105 . For example, when a user registers two devices 105 , none of them can be deleted from the system.
- the registered devices can be removed and new devices can be associated (registered) with a user.
- in-band or out-of-band communications could be used.
- the in-band communication channel a user can login to the system and then unregister or add devices.
- the out-of-band communication channel a user can unregister or add devices similarly to the registration phase, i.e., through other channels, such as calling or visiting a registration specialist in-person.
- the authentication system can be utilized to implement parental controls into a device. For example, gaining access to a television can be subject to an authentication to allow only authorized users. As such, access to some television channels can also require an authentication, such as the presence of a parent's smart ring. Similar concepts apply to various other parental-control systems.
- a device registration process may be initiated.
- the device registration process can occur by prompting the user via a user interface to enter an email address (the validity of this email is checked by a regular-expression pattern) and a device name (or identifier).
- the email address can be stored in the user credentials 124 of the data store 112
- the device name can be stored in the verified device identifiers 130 of the data store 112 .
- Emails are unique and can represent the users in the system and the device names are used to identify user's devices.
- the authentication system 100 can require the use of the defined time interval, which forces the user to register a verifying client device 105 B within a certain amount of time, according to one embodiment. If the user does not register the verifying client device 105 B within the defined time interval, the email will be invalid and will be unusable.
- the verifying client device 105 B needs to be registered with the same email and a different device name which can allow the authenticator computing device 103 to identify the user's different devices 105 . If the device name is the same as the previous one, the device 105 cannot be registered.
- the server then creates a randomly generated nonce or One-Time Password (OTP) and sends it to the email address provided by the user. The user can be prompted to enter this password via the user interface in order to register the verifying client device 105 B.
- OTP One-Time Password
- the authentication system 100 assumes that the two devices 105 paired belong to the same user because the user got the OTP by accessing the email of the user corresponding to the email address. In this way, the user already has access to the email account given, and the two devices 105 paired.
- the authenticator computing device 103 can check whether the email address is already registered. In particular, the authenticator computing device 103 can search through the data store within the authenticator computing device 103 , for example, to determine whether the email address received from the device 105 requesting access to the application is stored. Second, the authenticator computing device 103 can determine whether the devices 105 have been registered in association with that email address. Third, the authenticator computing device 103 can determine whether the signatures and/or or names of the devices 105 stored in association with that email address corresponds to the name of the device 105 received from the device 105 requesting access to the application.
- the authenticator computing device 103 can retrieve the user credentials 124 and verified device identifiers 130 associated with each device 105 that the user is registering. For each registered device 105 , a pair of private/public keys can be generated by that device.
- the authentication system 100 can use the public key of each of the devices 105 in order to identify which device 105 is accessing the system and also to encrypt the data sent to, and decrypt the data received from, these devices 105 .
- the user need not previously register any devices with the authentication system 100 .
- the authentication system 100 can be configured to automatically determine that a user associated with the requesting client device 105 A is the same user that is associated with the verifying client devices 105 B.
- the authenticator computing device 103 can be configured to automatically retrieve user data from the requesting client device 105 A and the verifying client devices 105 B. Thereafter, the authenticator computing device 103 can compare the data to determine whether the user associated with the requesting client device 105 A is the same user that is associated with the verifying client device 105 B.
- the registration and the authentication phases of the authentication system 100 can happen simultaneously. For example, when a user has not previously registered any devices with the authentication system 100 , a requesting client device 105 A may be prompted to enter user credentials and a device name upon requesting access to a resource. Thereafter, the verifying client device 105 B, upon sending a response back to the authenticator computing device 103 , can also be prompted to enter user credentials and a device name. In this situation, the authenticator computing device 103 can be configured to first determine whether the user credentials match before determining whether the authentication challenge sent and the response(s) received match.
- the authentication system 100 can be configured such that any device can be used as the verifying client device 105 B, regardless of whether the verifying client device 105 B belongs to the requesting user, as long as that device 105 B can be associated (i.e., registered) with the requesting user.
- a user can be authenticated via the authentication system 100 .
- the server can generate a random value (nonce) and compute a QR code of this value.
- This QR code can be sent to the user requiring access.
- the user can take a picture of this QR code by using the verifying client device 105 B which will send back the value, the name of the device 105 , and the user's email address to the authenticator computing device 103 . If everything sent matches with the data on the authenticator computing device 103 , the user is granted access to the system.
- the requesting client device 105 A and the verifying client device 105 B may be members of an associated set of client devices 160 and each of the client devices in the associated set of client devices is associated with more than one user.
- the requesting client device 105 A sends a request to access to an authenticator computing device 103 .
- the authenticator computing device 103 does not know which user has requested access to the resource because more than one user is associated with the requesting client device 105 A.
- the authenticator 103 responds to the request by sending an authentication challenge to the requesting client device 105 A.
- the requesting client device 105 A then forwards the challenge to the verifying client device 105 B and the verifying client device 105 B sends the response to the authenticator 103 . If the authenticator 103 determines that the response from the verifying client device 105 B is a valid response, then the authenticator authenticates the associated set of client device 160 . With this method, anonymity of the requesting client device 105 A is maintained.
- FIG. 3 shown is a flow chart that provides one example of functionality that may be implemented in the authenticator computing device 103 , according to an embodiment of the present disclosure.
- the flow chart of FIG. 3 can be viewed as depicting steps of an example of a method implemented in the authenticator computing device 103 to authenticate the requesting client device 105 A using the verifying client device 105 B.
- the flow chart depicted in FIG. 3 shows how the authenticator computing device 103 determines whether to grant the requesting client device 105 A access to resources.
- the method of the present invention may include receiving a request to access a resource from a user device of a plurality of user devices at an authenticator computing device 300 .
- the method may then continue by determining whether the request from the user device is valid 305 . If the request is not valid, the user device may be denied access to the resource 345 . If the request is valid, the authenticator computing device may generate an authentication challenge in response to the request 310 .
- the authentication challenge may then be transmitted to a subset of user devices of the plurality of devices associated with the requesting device and/or its user 315 , and a timer may be started 320 .
- the subset of user devices comprises at least one user device that is not the user device requesting access to the resource.
- the authenticator computing device may determine whether a response to the authentication challenge has been received 330 from any of the user devices in the subset of user devices. If a response has not been received, then the authenticator computing device determines whether the timer has elapsed 325 and if the time has elapsed, the user device requesting access, or another user device of the plurality of users devices, may be denied access to the resource 345 . Alternatively, if a response to the authentication challenge has been received from one of the user devices in the subset of user devices, then the authenticator computing device will determine whether the response is a valid response to the authentication challenge 335 .
- the user device requesting access, or another user device may be denied access to the resource 345 .
- the authenticator computing device may determine whether all required responses have been received and validated 340 . If all the responses have not been received and validated, then the authenticator computing system will continue to wait until all the required responses have been received and validated or until the maximum time for the responses has expired. Alternatively, if all the responses have been received and validated, then the user device requesting access, or another user device, may be granted access to the resource 350 .
- a forwarding policy for the authenticator computing device and a forwarding policy for each of the plurality of user devices can be used to determine the subset of user devices that will receive the authentication challenge.
- the forwarding policy of the authenticator computing device may cause the authenticator computing device to forward the authentication challenge to each of the user devices in the subset of user devices, or alternatively, the forwarding policy may cause the authenticator computing device to forward the authentication challenge to only some of the user devices in the subset.
- the forwarding policy of each of the user devices may cause the user device to forward a received authentication challenge to other user devices.
- each of the plurality of user devices may utilize a response policy to determine whether or not the user device is required to generate a response to a received authentication challenge.
- a response policy of the user device may determine whether or not the user device is required to generate a response to the authentication challenge.
- the authenticator computing device may utilize a validation policy to determine which responses are required to be valid to grant access to the user devices.
- the validation policy of the authenticator computing device may determine which responses from the subset of user devices are required to be valid to constitute a valid response to the authentication challenge. Accordingly, the validation policy may cause the authenticator computing device to ignore the responses from some of the user devices and to require valid responses from other user devices.
- the requesting client device 105 A is associated with more than one user and the requesting device is a member of an associated set of user devices. In this embodiment, access to the resource is granted or denied to the associated set of user devices if the responses are determined to be valid responses.
- FIG. 4 shown is a flow chart that provides one example of functionality implemented in the requesting client device 105 A.
- the flow chart of FIG. 4 can be viewed as depicting steps of an example of a method implemented in the requesting client device 105 A to authenticate the requesting client device 105 A using at least one verifying client 105 B.
- the requesting application 155 of the first device client device 105 A
- the authenticator computing device 103 the request to access a resource 400 .
- the authenticator computing device 103 In response to the request from the requesting client device 105 A, the authenticator computing device 103 generates an authentication challenge and transmits the authentication challenge to either the requesting client device 105 A or the verifying client device 105 B.
- the requesting client device may proceed by transmitting the authentication challenge to at least one verifying client device 410 .
- the requesting client device would not be required to forward the authentication challenge to other devices and the requesting client device 105 A may wait to receive notification of access granted or denied 445 based upon the authentication challenge responses from the other verifying client devices 105 B.
- the authentication challenge may instead be transmitted directly from the authenticator computing device 103 to the verifying client device 105 B.
- the method proceeds at step 410 , where it is determined whether the requesting client device 105 A or the verifying client device 105 B needs to forward the authentication challenge to another device before responding to the authentication challenge.
- the requesting client device 105 A and/or the verifying client device 105 B can be required to transmit the authentication challenge to multiple devices at varying times to receive access to the resources. If it is determined that the requesting client device 105 A or the verifying client device 105 B needs to send the authentication challenge to another device, the requesting client device 105 A or the verifying client device 1059 forwards the authentication challenge to another device 415 .
- the authenticator computing device 103 determines whether or not to grant access to the requesting client device 105 A and notifies the requesting client device 105 A that access has been denied or granted 445 .
- the requesting client device 105 A is associated with more than one user and the requesting device is a member of an associated set of user devices.
- access to the resource is granted or denied 445 to all of the users of the associated set of user devices if the responses are determined to be valid responses.
- FIG. 5 shown is a flow chart that provides one example of functionality implemented in the verifying client device 105 B.
- the flow chart of FIG. 5 can be viewed as depicting steps of an example of a method implemented in the verifying client device 1059 to authenticate the requesting client device 105 A.
- the verifying client device can receive the authentication challenge 500 , wherein the authentication challenge may be received from the authenticator computing device 103 or from the requesting client device 105 A.
- the method continues by determining whether the authentication challenge should be forwarded to any other devices from the verifying client device 505 .
- the method continues by determining whether any other devices should receive the authentication challenge 530 . Alternatively, if it is determined that that the verifying client device 1059 needs to respond to the authentication challenge, then a response is generated 520 and then transmitted to the authenticator computing device 525 . The method then continues by determining whether any additional devices should receive the authentication challenge 530 and sending the authentication challenge to additional devices, if appropriate 535 . The process continues until all of the appropriate devices have received the authentication challenge.
- the process then ends and the authenticator computing device notifies the requesting client device 105 A whether or not access has been granted based at least in part on the method performed within the verifying client device 1059 .
- multiple verifying client devices 105 B can be required to receive and/or send the authentication challenge at various times to authenticate the requesting client device 105 A.
- the requesting client device 105 A is associated with more than one user and the requesting device is a member of an associated set of user devices.
- the process ends and the authenticator computing device notifies the associated set of user devices 160 whether or not access to the resource is granted or denied to all of the users of the associated set of user devices if the responses are determined to be valid responses.
- FIG. 6 shown is a diagram illustrating an example of an authentication protocol implemented as a portion of the embodiment of the authentication system.
- the requesting client device 105 A and verifying client device 105 B shown in FIG. 6 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A and the verifying client device 1059 are registered to more than one user and the requesting client device 105 A and the verifying client device 105 B are members of an associated set of user devices.
- a requesting application in the requesting client device 105 A sends an access request 615 to the authenticator computing device 103 to access a resource.
- the authenticator 103 sends an authentication challenge 620 to the requesting client device 105 A after which the requesting client device 105 A sends the authentication challenge 620 to a verifying client device 1059 .
- the verifying client device 1059 sends a response 630 back to the authenticator computing device 103 .
- the authenticator computing device 103 determines that the response 630 is valid for the issued authentication challenge 620
- the authenticator computing device 103 grants the requesting client device 105 A access 635 to the resource.
- the authenticator computing device 103 grants any one or more of the user devices of the associated set of user devices 160 access to the resource.
- FIG. 7 shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system.
- the devices 105 A and 1059 shown in FIG. 7 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A and the verifying client device 105 B are registered to more than one user and the requesting client device 105 A and the verifying client device 1059 are members of an associated set of user devices.
- FIG. 7 shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system.
- the devices 105 A and 1059 shown in FIG. 7 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A and the verifying client device 105 B are registered to more than one user and the requesting client device 105 A and the verifying client device 1059 are members of an associated set of user devices.
- the authenticator computing device 103 sends the authentication challenge 720 to the verifying client device 10511 .
- the verifying client device 105 B sends the authentication challenge 720 to the requesting client device 105 A, after which the requesting client device 105 A sends a response 730 back to the authenticator computing device 103 .
- the authenticator computing device 103 determines that the response 730 is valid for the issued authentication challenge 720
- the authenticator computing device 103 grants the requesting client device 105 A access 735 to the resource.
- the authenticator computing device 103 grants any one or more of the user devices of the associated set of user devices 160 access to the resource.
- FIG. 8 shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system.
- the requesting client device 105 A, first verifying device 105 B and second verifying client device 105 B, shown in FIG. 8 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are registered to more than one user and the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are members of an associated set of user devices. As shown in FIG.
- the requesting client device 105 A sends an access request 820 to the authenticator computing device 103 .
- the requesting client device 105 A that requests access to a resource receives the authentication challenge 825 from the authenticator computing device 103 .
- a first verifying client device 10511 receives the authentication challenge 825 from the requesting client device 105 A.
- the first verifying client device 105 B sends a response 840 back to the authenticator computing device 103 .
- the first verifying client device 105 B sends the authentication challenge 825 to a second verifying client device 105 B.
- the second verifying client device 105 B then sends a response 845 back to the authenticator computing device 103 .
- the authenticator computing device 103 determines that the responses 840 , 845 received from the first and second verifying client devices 105 B are valid for the issued authentication challenge 825 , the authenticator computing device 103 sends an access grant 850 to the requesting client device 105 A thereby granting the requesting client device 105 A access to the resource.
- the authenticator computing device 103 determines that the response 630 is valid for the issued authentication challenge 620 , the authenticator computing device 103 grants any one or more of the user devices of the associated set of user devices 160 access to the resource.
- FIG. 9 shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system.
- the requesting client device 105 A, first verifying device 105 B and second verifying client device 105 B, shown in FIG. 9 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are registered to more than one user and the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are members of an associated set of user devices. As shown in FIG.
- the requesting client device 105 A sends an access request 920 to the authenticator computing device 103 .
- the requesting client device 105 A sends the authentication challenge 925 to the first verifying client device 105 B, after which the first verifying client device 105 B sends a response 935 to the authenticator computing device 103 .
- the requesting client device 105 A then sends the authentication challenge 925 to the second verifying client device 105 B.
- the second verifying client device 105 B then sends a response 945 back to the authenticator computing device 103 .
- the authenticator computing device 103 determines that the responses 935 , 945 received from the first and second verifying client devices 105 B are valid for the issued authentication challenge 925 , the authenticator computing device 103 send an access grant 950 to the requesting client device 105 A, thereby granting access to the resource.
- the authenticator computing device 103 determines that the response 630 is valid for the issued authentication challenge 620 , the authenticator computing device 103 grants any one or more of the user devices of the associated set of user devices 160 access to the resource.
- FIG. 10 shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system 100 .
- the requesting client device 105 A, first verifying device 105 B and second verifying client device 105 B, shown in FIG. 10 are associated and/or registered to the same user.
- at least one of the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are registered to more than one user and the requesting client device 105 A the first verifying client device 105 B and the second verifying client device 105 B are members of an associated set of user devices. As shown in FIG.
- the requesting client device 105 A first sends an access request 1020 to the authenticator computing device 103 .
- the requesting computing device 105 A then receives an authentication challenge 1025 and sends the authentication challenge 1025 to the first verifying client device 105 B, then to the second verifying client device 105 B, after which both the first and the second verifying client devices 105 B send a response 1040 , 1045 to the authenticator computing device 103 .
- the authenticator computing device 103 determines that the responses 1040 , 1045 received from the first and second verifying client devices 105 B are valid for the issued authentication challenge 1025 , the authenticator computing device 103 sends an access grant 1050 to the requesting client device 105 A thereby granting the requesting client device 105 A access to the resource.
- the authenticator computing device 103 determines that the response 630 is valid for the issued authentication challenge 620 , the authenticator computing device 103 grants any one or more of the user devices of the associated set of user devices 160 access to the resource.
- a nonce and/or a OR-code version of this nonce can be generated by the server.
- the QR code can be generated.
- the server can send the created QR code to the device 105 requesting access to the application.
- the authentication challenge can only be valid for about 15 seconds. It should be appreciated that the authentication challenge can be limited to being valid for any pre-determined amount of time.
- All the communications between the authenticator computing device 103 and the devices 105 can be signed, encrypted, and/or contain a timestamp. There can be a time window (determined from the timestamp) within which the receiver of a message will accept a message.
- the timestamp and the digital signature can facilitate ensuring the authenticity, integrity, and non-repudiation of the message.
- the encryption can facilitate ensuring the confidentiality of the message.
- an email address or other identifier can be used to identify the user and the signature to differentiate the two devices 105 .
- the interaction between the requesting client device 105 A and the verifying client device 105 B can be modified to suit different purposes.
- the authentication challenge data could be sent as a sound wave instead of a QR code.
- different forms of authentication challenges can be transmitted to the device 105 A requesting access to the application and received from the devices 105 B interacting with the requesting device 105 A to authenticate the requesting device 1054 .
- the authentication challenge can be a nonce and may be communicated in the form of a sound wave, NFC, images, infrared rays, vibration, Bluetooth, the state of a memory device such as a USB drive or magnetic tape, or any form of communication between devices 105 that can be received via the devices 105 .
- the time limit set to perform the authentication challenge, and a timestamp that may optionally be included in all the communications, can improve the security of the present invention. If the communication of the authentication challenge is delayed by a third party (perhaps because the attacker is in possession of the requesting client device 1054 , while a verifying client device 105 B is in possession of a legitimate user, and the attacker uses social engineering or spear phishing to send the authentication challenge data to said verifying client device 105 B), timestamps can reveal that delay.
- continuous authentication can be provided, wherein, after a requesting client device 1054 gains access to the resource, the requesting client device 1054 is stolen, which would allow an attacker to gain access to the resource.
- the authenticator computing device 103 can send a challenge to the requesting device 1054 in a fixed or random time interval.
- the user of the requesting device 105 A is then required to respond to the authentication challenges in order to continue being authenticated.
- the authentication system can require the challenge to be performed in a relatively small time interval, requiring the user to continuously respond to the authentication challenge in order to stay authenticated.
- the authentication system can generate different challenges, and/or it can request responses from a different subset of the devices associated with the user.
- one of the client devices 105 is unable to communicate directly with the authenticator computing device 103 , it is possible to use one of the other client devices 105 , that can communicate with the authenticator computing device 103 , to act as a relay for the communication between the authenticator computing device 103 and the client device 105 unable to communicate directly with the authenticator computing device 103 .
- the authenticator computing device 1103 includes at least one processor circuit, for example, having a processor 1105 and a memory 1120 , both of which are coupled to a local interface 1110 .
- the authenticator computing device 1103 can comprise, for example, at least one server computer.
- the local interface 1110 can comprise, for example, a data bus with an accompanying address/control bus or other bus structure as can be appreciated.
- Stored in the memory 1120 are both data and several components that are executable by the processor 1105 .
- stored in the memory 1120 and executable by the processor 1105 are the authentication challenge generator 1118 , validator 1115 , and potentially other applications.
- Also stored in the memory 1120 can be a data store 1112 and other data.
- an operating system can be stored in the memory 1120 and executable by the processor 1105 .
- any one of a number of programming languages can be employed such as, for example, C, C++, C#, Objective C, ML, Erlang, F#, x86, ARM, Java, JavaScript, Perl, PHP, Visual Basic, Python, Ruby, Delphi, Matlab, or other programming languages.
- executable means a program file that is in a form that can ultimately be run by the processor 1105 .
- executable programs can be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory 1120 and run by the processor 1105 , source code that can be expressed in proper format such as Object code that is capable of being loaded into a random access portion of the memory 1120 and executed by the processor 1105 , or source code that can be interpreted by another executable program to generate instructions in a random access portion of the memory 1120 to be executed by the processor 1105 , etc.
- An executable program can be stored in any portion or component of the memory 1120 including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.
- RAM random access memory
- ROM read-only memory
- hard drive solid-state drive
- USB flash drive USB flash drive
- memory card such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.
- CD compact disc
- DVD digital versatile disc
- the memory 1120 is defined herein as including both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power, Thus, the memory 1120 can comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, or a combination of any two or more of these memory components.
- RAM random access memory
- ROM read-only memory
- hard disk drives solid-state drives
- USB flash drives USB flash drives
- memory cards accessed via a memory card reader floppy disks accessed via an associated floppy disk drive
- optical discs accessed via an optical disc drive magnetic tapes accessed via an appropriate tape drive
- other memory components or a combination
- the RAM can comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices.
- the ROM can comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.
- the processor 1105 can represent multiple processors 1105 and the memory 1120 can represent multiple memories 1120 that operate in parallel processing circuits, respectively.
- the local interface 1110 can be an appropriate network that facilitates communication between any two of the multiple processors 1105 , between any processor 1105 and any of the memories 1120 , or between any two of the memories 1120 , etc.
- the local interface 1110 can comprise additional systems designed to coordinate this communication, including, for example, performing load balancing.
- the processor 1105 can be of electrical or of some other available construction.
- authentication challenge generator 1118 validator 1115 , and other various systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits having appropriate logic gates, or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.
- each block can represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s).
- the program instructions can be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as a processor 1105 in a computer system or other system.
- the machine code can be converted from the source code, etc.
- each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s).
- FIGS. 3-5 show a specific order of execution, it is understood that the order of execution can differ from that which is depicted.
- the order of execution of two or more blocks can be scrambled relative to the order shown.
- two or more blocks shown in succession in FIGS. 1 and 2 can be executed concurrently or with partial concurrence.
- one or more of the blocks shown in FIGS. 1 and 2 can be skipped or omitted.
- any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.
Abstract
Description
- This application claims priority to currently pending U.S. patent application Ser. No. 14/693,490, entitled “Systems and Method for Authentication Using Multiple Devices”, having a filing date of Apr. 22, 2015, which claims priority to U.S. Provisional Patent Application No. 62/095,137, entitled “Systems and Method for Authentication Using Multiple Devices”, having a filing date of Dec. 22, 2014, both of which are hereby incorporated by reference.
- A traditional method of authentication can involve prompting a user for a username and password. However, such a method of authentication can be prone to error and can require the user to recall hard-to-remember passwords.
- Another traditional method of authentication can involve receiving a unique property of the user, such as a fingerprint, to identify a user. However, such a method of authentication can be vulnerable to discovery of the user property. For example, an attacker who obtains a fingerprint of a user (or a facsimile thereof) can then falsely log in as the actual user.
- Another traditional method of authentication can involve presentation of a token (e.g., smart card) issued to the authorized user. However, such a method of authentication can be attacked by stealing the token.
- Additionally, the traditional methods of authentication do not provide anonymity for a user requesting authentication.
- Accordingly, what is needed in the art is a system and method for anonymous user authentication which overcomes the deficiencies of the authentication systems and methods currently known in the art.
- The present invention provides a system and method for authentication of an associated set of users which overcomes the deficiencies of the prior art authentication systems by requiring that at least two registered user devices be utilized in the authentication process, wherein access is granted to the associated set of user devices. Requiring more than one device for user authentication and granting access to an associated set of user devices instead of an individual user device of the set of user devices, provides increased security and anonymity by eliminating the possibility of unauthorized access through the use of a single registered user device and by preventing the authentication system from knowing which of the users has been granted access to the system.
- In one embodiment, a method of authentication using at least two devices is provided which includes, receiving, at an authenticator computing device, a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the one device requesting access to the resource registered to more than one user. The method continues by generating an authentication challenge at the authenticator computing device in response to the request and transmitting the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource. The authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset, Upon receipt of the authentication challenge, the method continues by generating at least one response to the authentication challenge at one or more user devices of the subset of user devices and transmitting the at least one response to the authenticator computing device. After the responses to the authentication challenge have been generated and transmitted to the authenticator computing device, the method continues by determining, at the authenticator computing device, if the at least one response constitutes a valid response to the authentication challenge and granting any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received at the authenticator computing device constitutes a valid response to the authentication challenge.
- In a particular embodiment, a forwarding policy for the authenticator computing device and a forwarding policy for each of the user devices of the associated set of user devices can be used to determine the subset of user devices that will receive the authentication challenge. Additionally, each of the user devices of the associated set of user devices may utilize a response policy to determine whether or not the user device is required to generate a response to a received authentication challenge and the authenticator computing device may utilize a validation policy to determine which responses are required to be valid to grant access to the associated set of user devices.
- In an additional embodiment, one or more non-transitory computer-readable media having computer-executable instructions for performing a method of running a software program on a computing device, the method including issuing instructions from the software program, are provided. The instructions may include, receiving, at an authenticator computing device, a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the one device requesting access to the resource registered to more than one user. The instructions may further include, generating an authentication challenge at the authenticator computing device in response to the request and transmitting the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource. The authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset. The instructions may additionally include, generating at least one response to the authentication challenge at one or more user devices of the subset of user devices and transmitting the at least one response to the authenticator computing device. The instruction may also include, determining, at the authenticator computing device, if the at least one response constitutes a valid response to the authentication challenge and granting any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received at the authenticator computing device constitutes a valid response to the authentication challenge.
- In another embodiment, an authentication system may be provided including, an authenticator computing device configured to receive a request to access a resource from one user device of an associated set of user devices, each of the user devices registered to at least one user and the device requesting access to the resource registered to more than one user, to generate an authentication challenge in response to the request and to transmit the authentication challenge to a subset of user devices of the associated set of user devices, wherein the subset of user devices comprises at least one device other than the one user device requesting access to the resource. The authentication challenge may be transmitted to the subset of user devices directly from the authenticator computing device, or alternatively, the authentication challenge may be transmitted from the authenticator computing device to the user device requesting access to the resource and the user device requesting access to the resource may subsequently transmit the authentication challenge to one or more of the other user devices in the subset. The authenticator computing device of the authentication system is further configured to receive at least one response to the authentication challenge from one or more user devices of the subset of user devices, to determine if the at least one response constitutes a valid response to the authentication challenge and to grant any one or more of the user devices of the associated set of user devices access to the resource if the at least one response received constitutes a valid response to the authentication challenge.
- Accordingly, the present invention provides a system and method for anonymous authentication of a user device requesting access to a resource by authenticating an associated set of user devices, utilizing two or more registered user devices of an associated set of users devices, wherein the user device requesting access to the resource is registered to more than one user, wherein authentication decisions for the associated set of user devices are based on receipt of at least one valid response from a user device in response to at least one authentication challenge sent to a subset of user devices that includes at least one user device other than the requesting user device. The present invention thus overcomes the deficiencies of the authentication systems and methods currently known in the art.
- Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
-
FIG. 1 is a block diagram illustrating a design overview of various embodiments of an authentication system implemented in a networked environment, in accordance with an embodiment of the present invention. -
FIG. 2 is a block diagram illustrating a design overview of various embodiments of an authentication system implemented in a networked environment, in accordance with an embodiment of the present invention. -
FIG. 3 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 4 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 5 is a flow diagram illustrating an example functionality implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 6 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 7 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 8 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 9 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 10 is a diagram illustrating an example of authentication protocols implemented as a portion of the authentication system, in accordance with an embodiment of the present invention. -
FIG. 11 is a schematic block diagram illustrating an exemplary device employed in the networked environment of the authentication system, in accordance with an embodiment of the present invention. - The present disclosure describes systems and methods for authenticating “users” (which can be human users, devices, processes, clients, etc.). Authentication decisions can be based on the existence of cryptographic signatures from some set of devices (sometimes referred to as “tokens”) associated with the user, During registration, the authenticator (e.g., an “authentication server”) can associate devices with users and/or each other. This description therefore uses the term “registered” to mean “associated”; the devices “registered” with a user are “associated” with that user and/or with each other. Each device can have one or more associated cryptographic keys (which, in some embodiments, can be shared with the authenticator and/or other devices). Although the authenticator can associate a plurality of devices with each user, the associated devices need not store any data indicating or identifying the existence of other devices associated with the same user. Instead, the authenticator can associate multiple devices with each user and can thereafter require a valid cryptographic signature (or MACs, message authentication codes, or other valid responses) from some subset of a user's associated devices before authenticating that user.
- According to some embodiments, the association of multiple devices with each user can prevent theft of devices. In particular, because some subset of devices associated with a user must participate in the authentication of the user, a theft-based attack can require the attacker to steal all the devices in the subset. For example, if a smart phone and smart watch are associated with a particular user and the verifier requires signatures from both of these devices before an access can be granted, then a theft-based attack would require stealing both the smart phone and smart watch.
- Accordingly, the present disclosure describes systems and methods for verifying (i.e., authenticating) a device (i.e., the device's user) using at least one other device associated with the user. In particular, the present disclosure describes various embodiments of an authentication system that can comprise a verifier and at least two user devices, where the verifier and the user devices can communicate, in one embodiment, the authentication of the requesting device is performed using another device of the user that is in close proximity to the requesting device. The authentication system described herein can comprise a multitude of different user devices that are available in a networked environment and can be configured to be authenticated.
- According to various embodiments, the authentication system can transmit an authentication challenge to a first device associated with a user. An authentication challenge can be a task, involving a second device, required to be completed in order to authenticate the first device. Similarly, the authentication challenge can comprise randomly generated data (i.e., a nonce) that the user must transmit to at least one other device, in order to be authenticated. A prover can refer to an entity who is executing the authentication challenge to prove the identity or validity of the first device. In other words, the prover can be the at least one other user device used to authenticate the requesting device.
- According to various embodiments, a system for authenticating devices can comprise a verifier configured to receive a registration for multiple computing devices associated with a user and to determine whether to authenticate the requesting device. The authenticator can be, for example, a secure server comprising a data store configured to store the registration of multiple devices associated with multiple respective users. The verifier can be used to verify the identity of a user. In some embodiments, a user can register a first device by entering a user credential, such as an email address of the user, and a name for the first device. The user can also register a second device by entering the same user credential for the user and a name for the second device. To this end, the user can register multiple devices to be associated with the user credential. Each device registered with the user can be stored in the data store of the verifier. In one embodiment, the system can require the user to register the second device within a predetermined time period to prevent security attacks during the registration phase.
- According to some embodiments, the authentication system can receive a request from the first device to access one or more resources, where a “resource” can, for example, be an application, file, process, port, service (such as opening a physical lock or connecting to a web service), network bandwidth, device, memory, and/or processor time. The system can determine if there are at least two devices registered with the user to perform the multiple device authentication. In response to determining that there are at least two devices associated with the user, the verifier can send an authentication challenge, possibly encrypted, to the first device desiring to access the resource. For example, the authentication challenge can be dynamically generated random data (e.g., a cryptographic nonce) that the second device can receive to authenticate the first device. The first device can send, possibly by broadcasting, the authentication challenge to the second device registered with the user.
- In some embodiments, the second device can receive the authentication challenge from the first device. For example, the second device can take a picture of the authentication challenge that is displayed on the screen of the first device (e.g., as a barcode, such as a QR code). The second device, having received the authentication challenge, can transmit a response to the verifier. The verifier can then determine whether the second device is registered with the user. For example, the verifier can determine that the second device is registered under the same email address as the first device. After determining that the second device is registered with the user, the verifier can determine whether the response received from the second device is valid with respect to the authentication challenge transmitted to the first device. Upon determining that the response received from the second device is valid with respect to the authentication challenge transmitted to the first device, the authentication system can authorize access to the resource to the first device.
- In one embodiment, the authentication challenge transmitted to the first device is a nonce encrypted using the first device's cryptographic public key, and a valid response from the second device is a version of said nonce signed with the second device's cryptographic private key. In such an embodiment, a valid response from the second device requires participation of both the first and second devices' private keys (the first device's private key being necessary to decrypt the nonce, so that the nonce can be transmitted to, and then encrypted and/or signed by, the second device). By requiring participation of both devices' private keys, a theft-based attack on the authentication system requires theft of both devices. In one embodiment, each device can store only its own private key. Other embodiments may incorporate additional devices, nonces, encryptions, decryptions, and signatures, as should be appreciated, to provide secure communications while assuring that a plurality of devices participate in the authentication of a first device.
- Additionally, multiple devices can be associated with a user and the user may be required to use the devices to be authenticated and gain access to a resource. However, the user does not necessarily need to utilize all of the associated devices to gain access to a resource. While n devices can be associated with the user, a subset of in devices can be required to participate in responding to an authentication challenge (participation may include forwarding, decrypting, signing, and/or transmitting a challenge and/or response). In general, it is required that 2≦m≦n, wherein both n and m need to be greater than or equal to 2 and m needs to be less than or equal to n. As such, if an attacker is successful in acquiring m−1 devices, they will be unable to gain access to the resource or system, yet the user will still be able to gain access using only m devices. For example, assuming m=2 and n=3, a user having a smart phone, a smart ring, and a smart watch can forget the smart phone at the office, yet still be able to gain access to their house by authenticating to the house's smart lock using the smart ring and smart watch. At the same time, an attacker who steals the user's smart phone will not have the required m=2 devices needed to open the house's smart lock. Thus, a level of robustness of usability, resulting from the redundancy of devices, is provided, and by choosing m and n appropriately, users can obtain both usability and security.
- While more than two devices can be associated with a user, instead of using all associated devices, the user can use a specific set of devices during the authentication process. Therefore, the authentication system can request responses from different subsets of associated devices at each authentication attempt.
- Device association can also be shared among users, and a device can be associated with multiple users. For example, a first user can be associated with a first smart phone and a first smart watch and a second user can be associated with the first smart phone and a second smart watch. Both the first user and the second user can access the authentication system by using the shared first smart phone and their respective associated devices. As such, even if an attacker has access to the first smart phone, they will still be unable to authenticate as the first user and as the second user.
- In a specific embodiment of the invention, a system and method are provided for anonymously authenticating a user requesting access to a resource. In this embodiment, during registration, the authenticator (e.g., an “authentication server”) can establish an associated set of user devices and can associate each of the user devices of the associated set of user devices with more than one user. The authenticator can then grant access to a requested resource to any user associated with the associated set of user devices using at least two user devices of the associated set of user devices. In this way, anonymous authentication is provided to a user requesting access to a resource by granting access to all of the users within the associated set of user devices. Once authenticated, a device has the same access level as allowed for any device in the associated set. This method provides anonymity and plausible deniability to the user because the authenticator does not know exactly which user has been authenticated, only that multiple of the devices in one associated set of devices successfully responded to the authentication challenges. In other words, instead of associating multiple user devices with one user, multiple devices could be associated with multiple users. In a multi-user environment, any one of the users can access the system by using these devices. Hence, the system doesn't know which specific user requested or was granted access, so the authentication becomes anonymized, and the authenticated user device has plausible deniability.
- Anonymous authentication requiring two user devices of an associated set of user devices can be useful in various scenarios, such as for the purpose of verifying that a user is a member of a neighborhood crime reporting group, without specifically identifying the neighbor, to allow for the anonymous reporting of crime tips. Anonymous authentication has additional practical application in similar scenarios involving company or government whistleblower or anonymous sources for news, undercover agent reporting without specific identification of the agent and anonymous feedback from students, employees, etc.
- Additional practical applications include providing services to authenticated members of organizations, such as companies or universities providing free shuttle or bus services to their employees or students, without tracking or ever determining the specific individuals using those services.
- The systems and methods disclosed herein can avoid the cost of general security tokens by using devices already possessed by the user. Therefore, the systems and methods disclosed herein can be easily deployable. All devices registered with a user can be granted a private key, or can create their own private key, during the registration phase. In this regard, if one device registered with a user is stolen, the attacker still needs the private key of at least one other device registered by the user to authenticate the stolen device.
- With reference to
FIG. 1 , shown is a block diagram illustrating design overviews of various embodiments of anauthentication system 100 implemented in a networked environment. Theauthentication system 100 can comprise anauthenticator computing device 103, a requestingclient device 105A, averifier client device 105B,network 109, and/or other components. The requestingclient device 105A and theverifier client device 105B, also referred to hereinafter as devices 105, can each belong to a user. That is to say, the devices 105 can be trusted devices registered with theauthentication system 100. - The
authenticator computing device 103 can comprise avalidator 115, anauthentication challenge generator 118, and/or other elements, such as other hardware and software, for implementing processes or algorithms. Thevalidator 115 can be configured to perform the actual validation test. That is to say, thevalidator 115 can be configured to determine whether an authentication challenge sent to the requestingclient device 105A matches a response received from the verifyingclient device 105B. Based on the result of that determination, thevalidator 115 can determine whether or not to authenticate the requestingclient device 105A. In addition, theauthentication challenge generator 118 can be configured to generate the authentication challenge sent to the requestingclient device 105A. Either theauthentication challenge generator 118 and/or thevalidator 115 can be configured to store the authentication challenge 127 sent and received in thedata store 112 along with a corresponding verifieddevice identifier 130. - The
authenticator computing device 103 can also comprise adata store 112 configured to store user credentials 124, authentication challenges 127, verifieddevice identifiers 130, and/or other data values. The user credentials 124 can comprise data regarding the devices 105 associated with each user. For example, user credentials 124 can comprise a username, password, email address, security questions and answers, and/or any other data related to a user with a registered client device 105. The authentication challenges 127 can comprise the authentication challenges sent to the requestingclient device 105A and received from the verifyingclient device 105B. In one embodiment, the authentication challenges 127 can comprise encrypted and/or plaintext data that have been sent to the requesting client device 1054 and/or received from one or moreverifying client devices 105B, The verifieddevice identifiers 130 can comprise data regarding devices 105 that a user has registered with theauthenticator computing device 103. For example, when a user registers a device 105, the user can be prompted to enter a device name. The device name can be stored as a verifieddevice identifier 130 in thedata store 112. - The components of the
authenticator computing device 103 can be distributed among several devices, which combine to perform the actions of theauthenticator computing device 103. Similarly, the components of a requesting client device 1054 can be distributed among several devices, which combine to act as a requesting device 1054 and the components of a verifyingclient device 105B can be distributed among several devices, which combine to act as a verifyingclient device 105B. - In some embodiments, the requesting
client device 105A can be the device requesting authentication to access an application. The verifyingclient devices 105B can be the device(s) that the requestingclient device 105A must communicate with to authenticate the requestingclient device 105A. In one embodiment, the client devices 105 must be in proximity to one another to complete authentication successfully. Alternatively, the client devices 105 must only be able to communicate with one another to successfully complete authentication. - In a specific embodiment, the requesting
client device 105A and the verifyingclient device 105B may belong to an associated set ofclient devices 160. In this embodiment, anonymous authentication of a user of a client device of the associated set ofclient devices 160 is provided by associating the client devices with multiple users and by using two or more of the client devices in the associated set ofclient devices 160 to anonymously authenticate the user. - With reference to
FIG. 2 , shown is another block diagram illustrating a design overview and communication pathway of various embodiments of anauthentication system 100 implemented in a networked environment. The requestingclient device 105A and the verifyingclient device 105B can perform a task, otherwise referred to herein as a authentication challenge, which includes a particular interaction between the requestingclient device 105A and the verifyingclient device 105B to prove the identity of the user and/or the requestingclient device 105A. The authenticatingcomputing device 103 can be a secure system which the user of requestingclient device 105A and the verifyingclient device 105B can access. In some embodiments, the requestingclient device 105A, the verifyingclient device 105B, and theauthenticator computing device 103 can communicate over a network in the networked environment, as shown inFIG. 1 andFIG. 2 . Alternatively, the requestingclient device 105A, the verifyingclient device 105B, and theauthenticator computing device 103 can be configured to communicate without a network. As shown inFIG. 2 , the requestingclient device 105A and the verifyingclient device 105B can together be embodied as theprover 260 of theauthentication system 100. - In particular, each of the devices 105 can comprise a processor-based system, such as a computer system, a server computer, or any other system providing computing capability. The devices 105 and the
authenticator computing device 103 can be employed or arranged, for example, in one or more server banks, computer banks, or other arrangements. The devices 105 can comprise various components configured to be executed on the device 105. For example, the components executed on the device 105 can include applications, services, processes, systems, engines, or other functionality. Each device 105 can include a display, such as, liquid crystal display (LCD) screens, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electronic ink displays, or other types of display devices, etc. - In some embodiments, the devices 105 can be embodied in the form of a laptop computer, personal digital assistants, cellular telephones, smart phones, music players, web pads, tablet computer systems, game devices, electronic book readers, or other devices 105 with like capability. The devices 105 can also be embodied as any mechanical structure comprising a processor-based system. In one embodiment, the devices 105 can be configured to connect to a network. For example, the device 105 can be a vehicle, such as a car, that can connect to a network to access the
authentication system 100. As another illustrative example, the device 105 can be a lock on a door of a car, room, or house that comprises a processor-based system that can connect to a network. As another illustrative example, the device 105 can be a garage door or a road gate that comprises a processor-based system that can connect to a network. As another illustrative example, the device 105 can be a smart wearable device, such as a smart watch, a smart ring, smart glasses, or any smart apparel that a user can wear as an item of clothing or accessory that comprises a processor-based system and can connect to a network. For example, the device 105 can be jewelry/apparel, including rings, necklaces, glasses, watches, earrings, shirts, pants, coats, handkerchiefs, hats, bracelets, scarves, hairclips, shoes, or belts. - According to some embodiments, when a user wants to access a resource from the requesting
client device 105A, theauthentication system 100 can require the user to perform an authentication challenge. This authentication challenge can be, for example, to transmit a particular random number from the requestingclient device 105A to the verifyingclient device 105B. This pseudo random number can be generated by thechallenge generator 118, and then transmitted from theauthenticator computing device 103 to the requestingclient device 105A. The pseudo random number can then be transmitted to the verifyingclient device 105B and back tovalidator 115 of theauthenticator computing device 103. Thevalidator 115 can determine whether the number received from the verifyingclient device 105B matches the number transmitted to the requestingclient device 105A. This random number can be dynamically generated, such as a nonce or a one-time password (OTP). In the embodiment shown inFIG. 1 andFIG. 2 , the set of devices 105 which can be used to perform the authentication per user has been reduced to two devices 105 for simplicity. - In some embodiments, the resource that the user of the requesting
client device 105A is requesting access to can require a pre-determined number of verifyingclient devices 105B to be used in authenticating the requestingclient device 105A. For example, if the user of the requestingclient device 105A is requesting access to a mobile application that displays confidential information related to a bank account of a user, the application can require that the user of the requestingclient device 105A have three or more registeredverifying client devices 105B capable of communicating with the requestingclient device 105A that the user wants to access with the application. To this end, a user can register any number of devices 105 with the system. In one embodiment, the prover can include an n number of trusted devices 105 associated with a user (where n is at least two). Therefore, an application can also require any number of verifyingclient devices 105B to be used in response to the authentication challenge presented for authentication. - Moreover, the
authentication system 100 can be an efficient method of authenticating a user for applications that require frequent re-authentication. For example, suppose a user opens a loan repayment application on a mobile device of the user. The application can require the user to frequently re-authenticate the mobile device due to the sensitive nature of the information displayed by the application. In this way, the user can easily re-authenticate the mobile device using another registered verifyingclient device 105B. In the same way, multiple device authentications via theauthentication system 100 is relatively more secure than traditional methods of re-authentication, also known as continuous authentication, because it requires multiple devices 105 registered to a user to be able to communicate with each other during the entire session. In one embodiment, theauthentication system 100 can require multiple devices 105 registered with a user to be in proximity to each other during the entire session. - In some embodiments, the
authenticator computing device 103 can lock out and force the use of a recovery path (to re-register device(s)) after a pre-defined threshold number of consecutive bad attempts. The pre-defined threshold number of consecutive bad attempts can depend on the reason an attempt was bad, e.g., “took too long to reply” or “didn't reply” or “returned invalid response to authentication challenge”. In one embodiment, the pre-defined threshold number of consecutive bad attempts can be higher for “taking too long to reply” or “didn't reply.” in another embodiment, the pre-defined threshold number of consecutive bad attempts can be smaller for “returned invalid response to authentication challenge.” - Next, a general description of the operation of the various components of the networked environment comprising the devices 105 is provided. In an embodiment where a user registers at least two devices, a user can register the at least two devices 105 belonging to the user with the
authentication system 100. For example, the user can register a pair of smart glasses by first entering an email address of the user and a device name of the smart glasses via a user interface of the smart glasses. In one embodiment, once the user registers the smart glasses with theauthentication system 100, the user interface of the smart glasses will prompt the user to register at least one verifyingclient device 105B belonging to the user within a defined time limit, for example, of about five minutes. In this way, the user has five minutes to register another device 105. The user can, fir example, register a smart watch belonging to the user by entering the email address of the user and a device name for the smart watch via a user interface of the smart watch within the defined time limit. Once the user has registered these two devices 105, theauthentication system 100 can store the device names of the smart glasses and the smart watch in association with the email address of the user in a data store, for example, in theauthenticator computing device 103. - Suppose that at a later time, the user wishes to access an application on the smart watch of the user where the application requires the user to login. The application can execute the login via the
authentication system 100. In one embodiment, theauthenticator computing device 103 can automatically send an authentication challenge to the smart watch. Alternatively, the user can request an authentication challenge from theauthenticator computing device 103 via a user interface on the smart watch. In either case, the application can prompt the user to login by broadcasting the authentication challenge data (e.g., a nonce) to the paired device (smart glasses) via the display of the smart watch. The authentication challenge data can be displayed as a QR code on the screen of the smart watch, for example. - The user can take a picture of the QR code displayed on the smart watch using a camera of the smart glasses. It should be appreciated that the smart glasses can receive the broadcasted in any manner of communication enabled between the smart watch and the smart glasses. The smart glasses can then automatically transmit the picture of the authentication challenge data to the
authenticator computing device 103 to verify the identity of the user of the smart watch. If theauthenticator computing device 103 determines that the response received from the smart glasses matches an expected response for the authentication challenge sent to the smart watch, then the user can be granted access to the application. In this way, the user will have successfully logged into the application. - In this regard, the smart glasses can comprise an application to facilitate the authentication process. For example, the user can initiate an application configured to automatically transmit a received authentication challenge, as a response, to the
authenticator computing device 103. Alternatively, the user can manually transmit a received authentication challenge, as a response, to theauthenticator computing device 103. - As another illustrative example, suppose the user owns a smart ring that comprises a near field communication (“NFC”) antenna, NFC transmitter, NFC chip, and/or any other component such that the smart ring is capable of NFC. Suppose the user also owns a mobile telephone also comprising an NFC antenna, NFC transmitter, NFC chip, and/or any other component such that the mobile telephone is capable of NFC. Therefore, the smart ring and the mobile telephone can communicate with each other via NFC. The user can register both the smart ring and the mobile telephone in accordance with the process described herein.
- The mobile telephone of the user can comprise an application that is capable of authenticating the user via the
authentication system 100. The user of the mobile telephone can open the application which requires the user to login. The mobile telephone can comprise a user interface displaying a randomly generated authentication challenge received from theauthenticator computing device 103 that can be broadcasted to the smart ring via NFC. If the user is wearing the smart ring while the user is trying to log in to the application on the mobile telephone, the user can simply open up the authentication application on the smart ring, if necessary, and receive the broadcasted authentication challenge data on the smart ring via NFC. The authentication application on the smart ring can automatically transmit the authentication challenge data received in the smart ring to theauthenticator computing device 103. Alternatively, the smart ring can transmit a signed version of the authentication challenge data to the smart phone, which then forwards the signed authentication challenge data to theauthenticator computing device 103. Theauthenticator computing device 103 can compare the authentication challenge sent to the mobile telephone to the response received from the smart ring and/or smart phone. If the response is valid for the authentication challenge (e.g., the response is determined to be an appropriately signed version of the authentication challenge data), then the user will be logged into the application on the mobile telephone and granted access to the requested resource. If the response is not valid for the authentication challenge (e.g., the response is determined not to be an appropriately signed version of the authentication challenge data), then the user can be notified of an authentication failure on the user interface of the mobile telephone. - As another illustrative example, a user can have access to all registered devices 105 on his or her person (e.g., a phone, ring, watch, etc.). When the user gets into close proximity with a lock (e.g., hotel room, car door, office door, garage door, etc.), the data communication can happen automatically. In this example, the lock can be embodied as the requesting
client device 105A, and at least one of the registered devices 105 on his or her person can be embodied as the verifyingclient device 105B. For example, one of the registered devices 105 on the user can automatically initiate communication with the lock once the devices 105 come within a threshold proximity to the lock. Once the communication is initiated, the authentication protocol can automatically be executed with or without any user involvement. The user wearing the verifyingclient device 105B can simply hold the verifyingclient device 105B and/or stand within the threshold proximity of the lock as the authentication challenge data is transmitted from theauthenticator computing device 103, to the lock, to the verifyingclient device 105B, and back to theauthenticator computing device 103. - Alternatively, the lock can act as the
authenticator 103, in a system in which the user is in possession of a plurality of devices (e.g., a smart ring and a smart military necklace, a smart “dog tag”) on his or her person. When the user comes within a threshold proximity to the lock, the smart ring may initiate the authentication protocol with the lock by requesting access (i.e., requesting that the lock be opened). In response, the lock sends an authentication challenge to the smart ring. The smart ring then sends the authentication challenge to the smart necklace, which may then respond directly to the lock (or indirectly via the smart ring). In this embodiment, the protocol may execute automatically, without user involvement, based on proximity to the lock. Also, in this embodiment, the smart ring acts as the requestingclient device 105A, and the smart necklace acts as the verifyingclient device 105B. A theft-based attack in this embodiment would require stealing both the ring and necklace. - Similarly, the authentication system and methods described herein can be used between two or more drones that are in proximity to one another. For example, suppose one drone, embodied as the requesting
client device 105A, is requesting access to a resource that requires authentication using another verifyingclient device 105B. Therefore, if another registered device, for example another drone, is within a threshold proximity of the drone requesting access to the application, then the drones may automatically perform the authentication challenge to authenticate the requesting drone. - Additionally, a set of users/entities (e.g., drones, robots, soldiers, etc.) can access a resource as one group, wherein each entity is itself a device. The group can be authenticated through response from a subset of these entities and the authentication can proceed absent human intervention.
- Yet another embodiment can relate to theft security of devices 105 and/or accessing data from devices 105. For example, suppose a user owns a car that can be a smart car paired with a smart phone. The car can contain an in-car navigation or in-car entertainment system, for example, that requires the smart phone for access. The in-car navigation or in-car entertainment system can comprise sensitive information regarding the user. According to some embodiments, the in-car navigation or in-car entertainment system can be set up such that it has to be authenticated with another device 105 of the user, such as the smart phone, prior to operation. Therefore, a thief will not be able to authenticate the in-car navigation or in-car entertainment system unless the thief also stole the user's smart phone. In situations where the in-car navigation or in-car entertainment stores private data of the user, such as a home and work address, times of day when the victim is not home, etc., implementing multiple device 105 authentications can protect such sensitive information.
- In one embodiment, the user can be required to first register at least two different devices 105 in a defined time interval to prevent attacks during the registration process. In particular, the time between registering each of the devices 105 must be less than the defined time interval. In order to authenticate a particular user, the system can require the user to enter a minimum amount of information, such as a user credential and a device name. In one embodiment, the user credential can be an email address that identifies a particular user in the database. The number of devices 105 a user registers can be a choice based on the requirements of the authenticator, which may base its requirements on the particular resources that may be accessed. In one embodiment, registering a device 105 can only be performed one time, and a user cannot unregister a device 105. For example, when a user registers two devices 105, none of them can be deleted from the system.
- In another embodiment, the registered devices can be removed and new devices can be associated (registered) with a user. To remove or add a registered device, in-band or out-of-band communications could be used. With the in-band communication channel, a user can login to the system and then unregister or add devices. With the out-of-band communication channel, a user can unregister or add devices similarly to the registration phase, i.e., through other channels, such as calling or visiting a registration specialist in-person.
- Additionally, the authentication system can be utilized to implement parental controls into a device. For example, gaining access to a television can be subject to an authentication to allow only authorized users. As such, access to some television channels can also require an authentication, such as the presence of a parent's smart ring. Similar concepts apply to various other parental-control systems.
- According to various embodiments, when the authenticating
application 150 launches in the requestingclient device 105A, if the requestingdevice 105A has not been associated with any verifyingdevices 105B, then a device registration process may be initiated. The device registration process can occur by prompting the user via a user interface to enter an email address (the validity of this email is checked by a regular-expression pattern) and a device name (or identifier). In one embodiment, the email address can be stored in the user credentials 124 of thedata store 112, and the device name can be stored in the verifieddevice identifiers 130 of thedata store 112. Emails are unique and can represent the users in the system and the device names are used to identify user's devices. A possible attack could occur between the registration of the requestingclient device 105A and the verifyingclient device 105B. Therefore, theauthentication system 100 can require the use of the defined time interval, which forces the user to register a verifyingclient device 105B within a certain amount of time, according to one embodiment. If the user does not register the verifyingclient device 105B within the defined time interval, the email will be invalid and will be unusable. - In one embodiment, once the user registers the requesting
client device 105A, the verifyingclient device 105B needs to be registered with the same email and a different device name which can allow theauthenticator computing device 103 to identify the user's different devices 105. If the device name is the same as the previous one, the device 105 cannot be registered. The server then creates a randomly generated nonce or One-Time Password (OTP) and sends it to the email address provided by the user. The user can be prompted to enter this password via the user interface in order to register the verifyingclient device 105B. In one embodiment, by virtue of receiving the OTP confirmation, theauthentication system 100 assumes that the two devices 105 paired belong to the same user because the user got the OTP by accessing the email of the user corresponding to the email address. In this way, the user already has access to the email account given, and the two devices 105 paired. - In one embodiment, the
authenticator computing device 103 can check whether the email address is already registered. In particular, theauthenticator computing device 103 can search through the data store within theauthenticator computing device 103, for example, to determine whether the email address received from the device 105 requesting access to the application is stored. Second, theauthenticator computing device 103 can determine whether the devices 105 have been registered in association with that email address. Third, theauthenticator computing device 103 can determine whether the signatures and/or or names of the devices 105 stored in association with that email address corresponds to the name of the device 105 received from the device 105 requesting access to the application. - The
authenticator computing device 103 can retrieve the user credentials 124 and verifieddevice identifiers 130 associated with each device 105 that the user is registering. For each registered device 105, a pair of private/public keys can be generated by that device. Theauthentication system 100 can use the public key of each of the devices 105 in order to identify which device 105 is accessing the system and also to encrypt the data sent to, and decrypt the data received from, these devices 105. - In some embodiments, the user need not previously register any devices with the
authentication system 100. In one embodiment, theauthentication system 100 can be configured to automatically determine that a user associated with the requestingclient device 105A is the same user that is associated with the verifyingclient devices 105B. For example, theauthenticator computing device 103 can be configured to automatically retrieve user data from the requestingclient device 105A and the verifyingclient devices 105B. Thereafter, theauthenticator computing device 103 can compare the data to determine whether the user associated with the requestingclient device 105A is the same user that is associated with the verifyingclient device 105B. - Alternatively, the registration and the authentication phases of the
authentication system 100 can happen simultaneously. For example, when a user has not previously registered any devices with theauthentication system 100, a requestingclient device 105A may be prompted to enter user credentials and a device name upon requesting access to a resource. Thereafter, the verifyingclient device 105B, upon sending a response back to theauthenticator computing device 103, can also be prompted to enter user credentials and a device name. In this situation, theauthenticator computing device 103 can be configured to first determine whether the user credentials match before determining whether the authentication challenge sent and the response(s) received match. In yet another embodiment, theauthentication system 100 can be configured such that any device can be used as the verifyingclient device 105B, regardless of whether the verifyingclient device 105B belongs to the requesting user, as long as thatdevice 105B can be associated (i.e., registered) with the requesting user. - Once the devices 105 of the user are registered, a user can be authenticated via the
authentication system 100. To identify the user, the server can generate a random value (nonce) and compute a QR code of this value. This QR code can be sent to the user requiring access. Then, the user can take a picture of this QR code by using the verifyingclient device 105B which will send back the value, the name of the device 105, and the user's email address to theauthenticator computing device 103. If everything sent matches with the data on theauthenticator computing device 103, the user is granted access to the system. - In an additional embodiment for providing anonymous authentication, the requesting
client device 105A and the verifyingclient device 105B may be members of an associated set ofclient devices 160 and each of the client devices in the associated set of client devices is associated with more than one user. In this embodiment, the requestingclient device 105A sends a request to access to anauthenticator computing device 103. Theauthenticator computing device 103 does not know which user has requested access to the resource because more than one user is associated with the requestingclient device 105A. Theauthenticator 103 responds to the request by sending an authentication challenge to the requestingclient device 105A. The requestingclient device 105A then forwards the challenge to the verifyingclient device 105B and the verifyingclient device 105B sends the response to theauthenticator 103. If theauthenticator 103 determines that the response from the verifyingclient device 105B is a valid response, then the authenticator authenticates the associated set ofclient device 160. With this method, anonymity of the requestingclient device 105A is maintained. - With reference to
FIG. 3 , shown is a flow chart that provides one example of functionality that may be implemented in theauthenticator computing device 103, according to an embodiment of the present disclosure. Alternatively, the flow chart ofFIG. 3 can be viewed as depicting steps of an example of a method implemented in theauthenticator computing device 103 to authenticate the requestingclient device 105A using the verifyingclient device 105B. In particular, the flow chart depicted inFIG. 3 shows how theauthenticator computing device 103 determines whether to grant the requestingclient device 105A access to resources. - With reference to
FIG. 3 , the method of the present invention may include receiving a request to access a resource from a user device of a plurality of user devices at anauthenticator computing device 300. The method may then continue by determining whether the request from the user device is valid 305. If the request is not valid, the user device may be denied access to theresource 345. If the request is valid, the authenticator computing device may generate an authentication challenge in response to therequest 310. The authentication challenge may then be transmitted to a subset of user devices of the plurality of devices associated with the requesting device and/or itsuser 315, and a timer may be started 320. The subset of user devices comprises at least one user device that is not the user device requesting access to the resource. As the timer is running, the authenticator computing device may determine whether a response to the authentication challenge has been received 330 from any of the user devices in the subset of user devices. If a response has not been received, then the authenticator computing device determines whether the timer has elapsed 325 and if the time has elapsed, the user device requesting access, or another user device of the plurality of users devices, may be denied access to theresource 345. Alternatively, if a response to the authentication challenge has been received from one of the user devices in the subset of user devices, then the authenticator computing device will determine whether the response is a valid response to theauthentication challenge 335. If the response is not a valid response to the authentication challenge, then the user device requesting access, or another user device, may be denied access to theresource 345. Alternatively, if the response to the authentication challenge is determined to be valid, thereby constituting a valid response, then the authenticator computing device may determine whether all required responses have been received and validated 340. If all the responses have not been received and validated, then the authenticator computing system will continue to wait until all the required responses have been received and validated or until the maximum time for the responses has expired. Alternatively, if all the responses have been received and validated, then the user device requesting access, or another user device, may be granted access to theresource 350. - In a particular embodiment, a forwarding policy for the authenticator computing device and a forwarding policy for each of the plurality of user devices can be used to determine the subset of user devices that will receive the authentication challenge. As such, the forwarding policy of the authenticator computing device may cause the authenticator computing device to forward the authentication challenge to each of the user devices in the subset of user devices, or alternatively, the forwarding policy may cause the authenticator computing device to forward the authentication challenge to only some of the user devices in the subset. Additionally, the forwarding policy of each of the user devices may cause the user device to forward a received authentication challenge to other user devices.
- Additionally, each of the plurality of user devices may utilize a response policy to determine whether or not the user device is required to generate a response to a received authentication challenge. As such, a response policy of the user device may determine whether or not the user device is required to generate a response to the authentication challenge. In addition, the authenticator computing device may utilize a validation policy to determine which responses are required to be valid to grant access to the user devices. As such, the validation policy of the authenticator computing device may determine which responses from the subset of user devices are required to be valid to constitute a valid response to the authentication challenge. Accordingly, the validation policy may cause the authenticator computing device to ignore the responses from some of the user devices and to require valid responses from other user devices.
- It is within the scope of the present invention to make changes to the previously described policies in order to implement specific desired functionality into the authentication system.
- In a specific embodiment providing anonymous authentication, the requesting
client device 105A is associated with more than one user and the requesting device is a member of an associated set of user devices. In this embodiment, access to the resource is granted or denied to the associated set of user devices if the responses are determined to be valid responses. - With reference to
FIG. 4 , shown is a flow chart that provides one example of functionality implemented in the requestingclient device 105A. Alternatively, the flow chart ofFIG. 4 can be viewed as depicting steps of an example of a method implemented in the requestingclient device 105A to authenticate the requestingclient device 105A using at least one verifyingclient 105B. Specifically, the requestingapplication 155 of the first device (client device 105A) generates a request to access a resource and sends theauthenticator computing device 103 the request to access aresource 400. In response to the request from the requestingclient device 105A, theauthenticator computing device 103 generates an authentication challenge and transmits the authentication challenge to either the requestingclient device 105A or the verifyingclient device 105B. If it is determined that the authentication challenge is received at the requesting client device 405, then the requesting client device may proceed by transmitting the authentication challenge to at least one verifyingclient device 410. Alternatively, if the authentication challenge is not received at the requesting client device, then the requesting client device would not be required to forward the authentication challenge to other devices and the requestingclient device 105A may wait to receive notification of access granted or denied 445 based upon the authentication challenge responses from the other verifyingclient devices 105B. Additionally, the authentication challenge may instead be transmitted directly from theauthenticator computing device 103 to the verifyingclient device 105B. After at least one verifyingclient device 105B has received the authentication challenge from either theauthenticator computing device 103 or the requesting client device 105, the method proceeds atstep 410, where it is determined whether the requestingclient device 105A or the verifyingclient device 105B needs to forward the authentication challenge to another device before responding to the authentication challenge. In this regard, the requestingclient device 105A and/or the verifyingclient device 105B can be required to transmit the authentication challenge to multiple devices at varying times to receive access to the resources. If it is determined that the requestingclient device 105A or the verifyingclient device 105B needs to send the authentication challenge to another device, the requestingclient device 105A or the verifying client device 1059 forwards the authentication challenge to anotherdevice 415. If it is determined that the requestingdevice 105A or the verifyingclient device 105B does not need to send the authentication challenge to any other devices, then it is determined whether the devices receiving the authentication challenge need to respond to theauthentication challenge 420. If so, the devices receiving the authentication challenge generate a response to theauthentication challenge 425 and transmit the response to theauthenticator computing device 430. The method then determines whether it is necessary to forward the authentication challenge to anyother devices 435, and if it is necessary to forward the authentication challenge to another device, then the authentication challenge is forwarded to theother devices 440. The process continues until all of the appropriate devices have received the authentication challenge and all of the devices have had the opportunity to respond. Theauthenticator computing device 103 then determines whether or not to grant access to the requestingclient device 105A and notifies the requestingclient device 105A that access has been denied or granted 445. - In a specific embodiment providing anonymous authentication, the requesting
client device 105A is associated with more than one user and the requesting device is a member of an associated set of user devices. In this embodiment, access to the resource is granted or denied 445 to all of the users of the associated set of user devices if the responses are determined to be valid responses. - With reference to
FIG. 5 , shown is a flow chart that provides one example of functionality implemented in the verifyingclient device 105B. Alternatively, the flow chart ofFIG. 5 can be viewed as depicting steps of an example of a method implemented in the verifying client device 1059 to authenticate the requestingclient device 105A. In particular, the verifying client device can receive theauthentication challenge 500, wherein the authentication challenge may be received from theauthenticator computing device 103 or from the requestingclient device 105A. After receiving the authentication challenge at the verifying client device, the method continues by determining whether the authentication challenge should be forwarded to any other devices from the verifyingclient device 505. If it is determined that the authentication challenge should not be forwarded to any other devices, it is then determined whether the verifyingclient device 105B needs to respond to the authentication challenge 515. If not, then the method continues by determining whether any other devices should receive theauthentication challenge 530. Alternatively, if it is determined that that the verifying client device 1059 needs to respond to the authentication challenge, then a response is generated 520 and then transmitted to theauthenticator computing device 525. The method then continues by determining whether any additional devices should receive theauthentication challenge 530 and sending the authentication challenge to additional devices, if appropriate 535. The process continues until all of the appropriate devices have received the authentication challenge. The process then ends and the authenticator computing device notifies the requestingclient device 105A whether or not access has been granted based at least in part on the method performed within the verifying client device 1059. In some embodiments, multiple verifyingclient devices 105B can be required to receive and/or send the authentication challenge at various times to authenticate the requestingclient device 105A. - In a specific embodiment providing anonymous authentication, the requesting
client device 105A is associated with more than one user and the requesting device is a member of an associated set of user devices. In this embodiment, the process ends and the authenticator computing device notifies the associated set ofuser devices 160 whether or not access to the resource is granted or denied to all of the users of the associated set of user devices if the responses are determined to be valid responses. - With reference to
FIG. 6 , shown is a diagram illustrating an example of an authentication protocol implemented as a portion of the embodiment of the authentication system. In one embodiment, the requestingclient device 105A and verifyingclient device 105B shown inFIG. 6 are associated and/or registered to the same user. In an additional embodiment providing anonymous authentication, at least one of the requestingclient device 105A and the verifying client device 1059 are registered to more than one user and the requestingclient device 105A and the verifyingclient device 105B are members of an associated set of user devices. As shown inFIG. 6 , a requesting application in the requestingclient device 105A sends anaccess request 615 to theauthenticator computing device 103 to access a resource. Theauthenticator 103 sends anauthentication challenge 620 to the requestingclient device 105A after which the requestingclient device 105A sends theauthentication challenge 620 to a verifying client device 1059. The verifying client device 1059 sends aresponse 630 back to theauthenticator computing device 103. If theauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants the requestingclient 635 to the resource. In the case of anonymous authentication, if thedevice 105A accessauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants any one or more of the user devices of the associated set ofuser devices 160 access to the resource. - With reference to
FIG. 7 , shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system. In one embodiment, thedevices 105A and 1059 shown inFIG. 7 are associated and/or registered to the same user. In an additional embodiment providing anonymous authentication, at least one of the requestingclient device 105A and the verifyingclient device 105B are registered to more than one user and the requestingclient device 105A and the verifying client device 1059 are members of an associated set of user devices. In the embodiment shown inFIG. 7 , after the requestingclient device 105A requests access to aresource 715, theauthenticator computing device 103 sends theauthentication challenge 720 to the verifying client device 10511, The verifyingclient device 105B sends theauthentication challenge 720 to the requestingclient device 105A, after which the requestingclient device 105A sends aresponse 730 back to theauthenticator computing device 103. If theauthenticator computing device 103 determines that theresponse 730 is valid for the issuedauthentication challenge 720, theauthenticator computing device 103 grants the requestingclient 735 to the resource. In the case of anonymous authentication, if thedevice 105A accessauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants any one or more of the user devices of the associated set ofuser devices 160 access to the resource. - With reference to
FIG. 8 , shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system. In one embodiment, the requestingclient device 105A,first verifying device 105B and secondverifying client device 105B, shown inFIG. 8 , are associated and/or registered to the same user. In an additional embodiment providing anonymous authentication, at least one of the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are registered to more than one user and the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are members of an associated set of user devices. As shown inFIG. 8 , the requestingclient device 105A sends anaccess request 820 to theauthenticator computing device 103. The requestingclient device 105A that requests access to a resource receives theauthentication challenge 825 from theauthenticator computing device 103. A first verifying client device 10511 receives theauthentication challenge 825 from the requestingclient device 105A. Thereafter, the firstverifying client device 105B sends aresponse 840 back to theauthenticator computing device 103. Thereafter, the firstverifying client device 105B sends theauthentication challenge 825 to a secondverifying client device 105B. The secondverifying client device 105B then sends aresponse 845 back to theauthenticator computing device 103. If theauthenticator computing device 103 determines that theresponses verifying client devices 105B are valid for the issuedauthentication challenge 825, theauthenticator computing device 103 sends anaccess grant 850 to the requestingclient device 105A thereby granting the requestingclient device 105A access to the resource. In the case of anonymous authentication, if theauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants any one or more of the user devices of the associated set ofuser devices 160 access to the resource. - With reference to
FIG. 9 , shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of the authentication system. In one embodiment, the requestingclient device 105A,first verifying device 105B and secondverifying client device 105B, shown inFIG. 9 , are associated and/or registered to the same user. In an additional embodiment providing anonymous authentication, at least one of the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are registered to more than one user and the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are members of an associated set of user devices. As shown inFIG. 9 , the requestingclient device 105A sends anaccess request 920 to theauthenticator computing device 103. The requestingclient device 105A sends theauthentication challenge 925 to the firstverifying client device 105B, after which the firstverifying client device 105B sends aresponse 935 to theauthenticator computing device 103. The requestingclient device 105A then sends theauthentication challenge 925 to the secondverifying client device 105B. The secondverifying client device 105B then sends aresponse 945 back to theauthenticator computing device 103. If theauthenticator computing device 103 determines that theresponses verifying client devices 105B are valid for the issuedauthentication challenge 925, theauthenticator computing device 103 send anaccess grant 950 to the requestingclient device 105A, thereby granting access to the resource. In the case of anonymous authentication, if theauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants any one or more of the user devices of the associated set ofuser devices 160 access to the resource. - With reference to
FIG. 10 , shown is a diagram illustrating another example of an authentication protocol implemented as a portion of the embodiment of theauthentication system 100. In one embodiment, the requestingclient device 105A,first verifying device 105B and secondverifying client device 105B, shown inFIG. 10 , are associated and/or registered to the same user. In an additional embodiment providing anonymous authentication, at least one of the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are registered to more than one user and the requestingclient device 105A the firstverifying client device 105B and the secondverifying client device 105B are members of an associated set of user devices. As shown inFIG. 10 , the requestingclient device 105A first sends anaccess request 1020 to theauthenticator computing device 103. The requestingcomputing device 105A then receives anauthentication challenge 1025 and sends theauthentication challenge 1025 to the firstverifying client device 105B, then to the secondverifying client device 105B, after which both the first and the secondverifying client devices 105B send aresponse authenticator computing device 103. If theauthenticator computing device 103 determines that theresponses verifying client devices 105B are valid for the issuedauthentication challenge 1025, theauthenticator computing device 103 sends anaccess grant 1050 to the requestingclient device 105A thereby granting the requestingclient device 105A access to the resource. In the case of anonymous authentication, if theauthenticator computing device 103 determines that theresponse 630 is valid for the issuedauthentication challenge 620, theauthenticator computing device 103 grants any one or more of the user devices of the associated set ofuser devices 160 access to the resource. - In one embodiment, when the authentication process starts, a nonce and/or a OR-code version of this nonce can be generated by the server. Once the nonce is generated, the QR code can be generated. Finally, the server can send the created QR code to the device 105 requesting access to the application. In one embodiment, to forestall attacks during the authentication process, the authentication challenge can only be valid for about 15 seconds. It should be appreciated that the authentication challenge can be limited to being valid for any pre-determined amount of time.
- All the communications between the
authenticator computing device 103 and the devices 105 can be signed, encrypted, and/or contain a timestamp. There can be a time window (determined from the timestamp) within which the receiver of a message will accept a message. The timestamp and the digital signature can facilitate ensuring the authenticity, integrity, and non-repudiation of the message. The encryption can facilitate ensuring the confidentiality of the message. Also, an email address or other identifier can be used to identify the user and the signature to differentiate the two devices 105. - The interaction between the requesting
client device 105A and the verifyingclient device 105B can be modified to suit different purposes. For example, the authentication challenge data could be sent as a sound wave instead of a QR code. In this regard, different forms of authentication challenges can be transmitted to thedevice 105A requesting access to the application and received from thedevices 105B interacting with the requestingdevice 105A to authenticate the requesting device 1054. For example, the authentication challenge can be a nonce and may be communicated in the form of a sound wave, NFC, images, infrared rays, vibration, Bluetooth, the state of a memory device such as a USB drive or magnetic tape, or any form of communication between devices 105 that can be received via the devices 105. - The time limit set to perform the authentication challenge, and a timestamp that may optionally be included in all the communications, can improve the security of the present invention. If the communication of the authentication challenge is delayed by a third party (perhaps because the attacker is in possession of the requesting client device 1054, while a verifying
client device 105B is in possession of a legitimate user, and the attacker uses social engineering or spear phishing to send the authentication challenge data to said verifyingclient device 105B), timestamps can reveal that delay. - In an additional embodiment, continuous authentication can be provided, wherein, after a requesting client device 1054 gains access to the resource, the requesting client device 1054 is stolen, which would allow an attacker to gain access to the resource. To solve this problem, the
authenticator computing device 103 can send a challenge to the requesting device 1054 in a fixed or random time interval. The user of the requestingdevice 105A is then required to respond to the authentication challenges in order to continue being authenticated. The authentication system can require the challenge to be performed in a relatively small time interval, requiring the user to continuously respond to the authentication challenge in order to stay authenticated. Furthermore, the authentication system can generate different challenges, and/or it can request responses from a different subset of the devices associated with the user. - Additionally, while the detailed embodiments of the invention describe authenticating only the requesting
client device 105A, granting the verifyingclient devices 105B access to the resource is also within the scope of the present invention. - In some embodiments, if one of the client devices 105 is unable to communicate directly with the
authenticator computing device 103, it is possible to use one of the other client devices 105, that can communicate with theauthenticator computing device 103, to act as a relay for the communication between theauthenticator computing device 103 and the client device 105 unable to communicate directly with theauthenticator computing device 103. - With reference to
FIG. 11 , shown is a schematic block diagram of anauthenticator computing device 1103 according to an embodiment of the present disclosure. Theauthenticator computing device 1103 includes at least one processor circuit, for example, having aprocessor 1105 and amemory 1120, both of which are coupled to alocal interface 1110. To this end, theauthenticator computing device 1103 can comprise, for example, at least one server computer. Thelocal interface 1110 can comprise, for example, a data bus with an accompanying address/control bus or other bus structure as can be appreciated. - Stored in the
memory 1120 are both data and several components that are executable by theprocessor 1105. In particular, stored in thememory 1120 and executable by theprocessor 1105 are theauthentication challenge generator 1118,validator 1115, and potentially other applications. Also stored in thememory 1120 can be adata store 1112 and other data. In addition, an operating system can be stored in thememory 1120 and executable by theprocessor 1105. - It is understood that there can be other applications that are stored in the
memory 1120 and are executable by theprocessors 1105 as can be appreciated. Where any component discussed herein is implemented in the form of software, any one of a number of programming languages can be employed such as, for example, C, C++, C#, Objective C, ML, Erlang, F#, x86, ARM, Java, JavaScript, Perl, PHP, Visual Basic, Python, Ruby, Delphi, Matlab, or other programming languages. - A number of software components are stored in the
memory 1120 and are executable by theprocessor 1105. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by theprocessor 1105. Examples of executable programs can be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of thememory 1120 and run by theprocessor 1105, source code that can be expressed in proper format such as Object code that is capable of being loaded into a random access portion of thememory 1120 and executed by theprocessor 1105, or source code that can be interpreted by another executable program to generate instructions in a random access portion of thememory 1120 to be executed by theprocessor 1105, etc. An executable program can be stored in any portion or component of thememory 1120 including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components. - The
memory 1120 is defined herein as including both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power, Thus, thememory 1120 can comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, or a combination of any two or more of these memory components. In addition, the RAM can comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM can comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device. - Also, the
processor 1105 can representmultiple processors 1105 and thememory 1120 can representmultiple memories 1120 that operate in parallel processing circuits, respectively. In such a case, thelocal interface 1110 can be an appropriate network that facilitates communication between any two of themultiple processors 1105, between anyprocessor 1105 and any of thememories 1120, or between any two of thememories 1120, etc. Thelocal interface 1110 can comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. Theprocessor 1105 can be of electrical or of some other available construction. - Although
authentication challenge generator 1118,validator 1115, and other various systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits having appropriate logic gates, or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein. - The flow charts of
FIGS. 3-5 show the functionality and operation of an implementation of portions of an embodiment for the multiple device authentication system. If embodied in software, each block can represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as aprocessor 1105 in a computer system or other system. The machine code can be converted from the source code, etc. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s). - Although the flow charts of
FIGS. 3-5 show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession inFIGS. 1 and 2 can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown inFIGS. 1 and 2 can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure. - It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.
Claims (29)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/788,152 US9380058B1 (en) | 2014-12-22 | 2015-06-30 | Systems and methods for anonymous authentication using multiple devices |
PCT/US2016/036225 WO2017003651A1 (en) | 2015-06-30 | 2016-06-07 | Systems and methods for anonymous authentication using multiple devices |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201462095137P | 2014-12-22 | 2014-12-22 | |
US14/693,490 US9659160B2 (en) | 2014-12-22 | 2015-04-22 | System and methods for authentication using multiple devices |
US14/788,152 US9380058B1 (en) | 2014-12-22 | 2015-06-30 | Systems and methods for anonymous authentication using multiple devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/693,490 Continuation-In-Part US9659160B2 (en) | 2014-12-22 | 2015-04-22 | System and methods for authentication using multiple devices |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160182500A1 true US20160182500A1 (en) | 2016-06-23 |
US9380058B1 US9380058B1 (en) | 2016-06-28 |
Family
ID=56130847
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/788,152 Active 2035-04-24 US9380058B1 (en) | 2014-12-22 | 2015-06-30 | Systems and methods for anonymous authentication using multiple devices |
Country Status (1)
Country | Link |
---|---|
US (1) | US9380058B1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160381560A1 (en) * | 2015-06-27 | 2016-12-29 | Offla Selfsafe Ltd. | Systems and methods for derivative fraud detection challenges in mobile device transactions |
US20170201550A1 (en) * | 2016-01-10 | 2017-07-13 | Apple Inc. | Credential storage across multiple devices |
US20170264609A1 (en) * | 2016-03-10 | 2017-09-14 | Samsung Electronics Co., Ltd. | Server for authentication based on context information of particular location, control method thereof and electronic apparatus |
US20170264608A1 (en) * | 2016-03-09 | 2017-09-14 | Qualcomm Incorporated | Visual biometric authentication supplemented with a time-based secondary authentication factor |
US20170288884A1 (en) * | 2016-04-04 | 2017-10-05 | Mastercard International Incorporated | Systems and methods for device to device authentication |
US20170331817A1 (en) * | 2016-05-12 | 2017-11-16 | Bank Of America Corporation | Preventing Unauthorized Access to Secured Information Systems Using Multi-Device Authentication Techniques |
US20180212958A1 (en) * | 2017-01-26 | 2018-07-26 | Teltech Systems, Inc. | Two Factor Authentication Using SMS |
US10158629B2 (en) * | 2016-06-20 | 2018-12-18 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
US10305891B2 (en) * | 2016-05-12 | 2019-05-28 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
WO2021011160A1 (en) * | 2019-07-18 | 2021-01-21 | Hewlett-Packard Development Company, L.P. | User authentication |
US10922443B2 (en) * | 2015-06-19 | 2021-02-16 | Ingenico Group | System for protecting an input device |
US20210240804A1 (en) * | 2020-02-03 | 2021-08-05 | Toyota Jidosha Kabushiki Kaisha | Authentication system |
US11121857B2 (en) * | 2017-02-27 | 2021-09-14 | Walmart Apollo, Llc | Systems, devices, and methods for in-field authenticating of autonomous robots |
US20220103550A1 (en) * | 2020-09-30 | 2022-03-31 | International Business Machines Corporation | Providing isolated containers for user request processing |
US20220376933A1 (en) * | 2019-09-25 | 2022-11-24 | Commonwealth Scientific And Industrial Research Organisation | Cryptographic services for browser applications |
US20230015819A1 (en) * | 2020-07-08 | 2023-01-19 | Kevin Mike NICKELS | Automation of user identity using network protocol providing secure granting or revocation of secured access rights |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10367817B2 (en) | 2014-12-22 | 2019-07-30 | University Of South Florida | Systems and methods for challengeless coauthentication |
US10509898B2 (en) * | 2015-01-21 | 2019-12-17 | Jim Barney et al. | Enhanced security authentication methods, systems and media |
EP3379767B1 (en) | 2017-03-24 | 2021-01-13 | Hewlett-Packard Development Company, L.P. | Distributed authentication |
US11558365B1 (en) * | 2017-10-10 | 2023-01-17 | NortonLifeLock Inc. | Multi-second factor authentication |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030120920A1 (en) | 2001-12-20 | 2003-06-26 | Svensson Sven Anders Borje | Remote device authentication |
KR100412510B1 (en) * | 2002-03-30 | 2004-01-07 | 한민규 | An instant log-in method for authentificating a user and settling bills by using two different communication channels and a system thereof |
US8086853B2 (en) | 2005-03-18 | 2011-12-27 | Microsoft Corporation | Automatic centralized authentication challenge response generation |
EP1802155A1 (en) | 2005-12-21 | 2007-06-27 | Cronto Limited | System and method for dynamic multifactor authentication |
US8006300B2 (en) * | 2006-10-24 | 2011-08-23 | Authernative, Inc. | Two-channel challenge-response authentication method in random partial shared secret recognition system |
US8656472B2 (en) | 2007-04-20 | 2014-02-18 | Microsoft Corporation | Request-specific authentication for accessing web service resources |
US8156333B2 (en) * | 2008-05-29 | 2012-04-10 | Red Hat, Inc. | Username based authentication security |
US8522010B2 (en) * | 2008-10-20 | 2013-08-27 | Microsoft Corporation | Providing remote user authentication |
US9544143B2 (en) * | 2010-03-03 | 2017-01-10 | Duo Security, Inc. | System and method of notifying mobile devices to complete transactions |
EP2424185B1 (en) | 2010-08-23 | 2014-10-22 | 3M Innovative Properties Co. | Method and device for challenge-response authentication |
US8601602B1 (en) | 2010-08-31 | 2013-12-03 | Google Inc. | Enhanced multi-factor authentication |
US20130254858A1 (en) | 2012-03-26 | 2013-09-26 | Computer Associates Think, Inc. | Encoding an Authentication Session in a QR Code |
GB201213277D0 (en) | 2012-07-26 | 2012-09-05 | Highgate Labs Ltd | Two device authentication mechanism |
US9594896B2 (en) | 2012-12-21 | 2017-03-14 | Blackberry Limited | Two factor authentication using near field communications |
US8806205B2 (en) | 2012-12-27 | 2014-08-12 | Motorola Solutions, Inc. | Apparatus for and method of multi-factor authentication among collaborating communication devices |
US9313198B2 (en) | 2013-03-27 | 2016-04-12 | Oracle International Corporation | Multi-factor authentication using an authentication device |
US9332081B2 (en) * | 2013-08-30 | 2016-05-03 | Google Inc. | Anonymous cross-device linking using temporal identifiers |
-
2015
- 2015-06-30 US US14/788,152 patent/US9380058B1/en active Active
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10922443B2 (en) * | 2015-06-19 | 2021-02-16 | Ingenico Group | System for protecting an input device |
US20160381560A1 (en) * | 2015-06-27 | 2016-12-29 | Offla Selfsafe Ltd. | Systems and methods for derivative fraud detection challenges in mobile device transactions |
US20170201550A1 (en) * | 2016-01-10 | 2017-07-13 | Apple Inc. | Credential storage across multiple devices |
US20170264608A1 (en) * | 2016-03-09 | 2017-09-14 | Qualcomm Incorporated | Visual biometric authentication supplemented with a time-based secondary authentication factor |
US20170264609A1 (en) * | 2016-03-10 | 2017-09-14 | Samsung Electronics Co., Ltd. | Server for authentication based on context information of particular location, control method thereof and electronic apparatus |
US10904247B2 (en) * | 2016-03-10 | 2021-01-26 | Samsung Electronics Co., Ltd. | Server for authentication based on context information of particular location, control method thereof and electronic apparatus |
US20170288884A1 (en) * | 2016-04-04 | 2017-10-05 | Mastercard International Incorporated | Systems and methods for device to device authentication |
US10091007B2 (en) * | 2016-04-04 | 2018-10-02 | Mastercard International Incorporated | Systems and methods for device to device authentication |
US10305891B2 (en) * | 2016-05-12 | 2019-05-28 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
US10091194B2 (en) * | 2016-05-12 | 2018-10-02 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
US20170331817A1 (en) * | 2016-05-12 | 2017-11-16 | Bank Of America Corporation | Preventing Unauthorized Access to Secured Information Systems Using Multi-Device Authentication Techniques |
US10158629B2 (en) * | 2016-06-20 | 2018-12-18 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
US20180212958A1 (en) * | 2017-01-26 | 2018-07-26 | Teltech Systems, Inc. | Two Factor Authentication Using SMS |
US11121857B2 (en) * | 2017-02-27 | 2021-09-14 | Walmart Apollo, Llc | Systems, devices, and methods for in-field authenticating of autonomous robots |
WO2021011160A1 (en) * | 2019-07-18 | 2021-01-21 | Hewlett-Packard Development Company, L.P. | User authentication |
US20220376933A1 (en) * | 2019-09-25 | 2022-11-24 | Commonwealth Scientific And Industrial Research Organisation | Cryptographic services for browser applications |
US20210240804A1 (en) * | 2020-02-03 | 2021-08-05 | Toyota Jidosha Kabushiki Kaisha | Authentication system |
US20230015819A1 (en) * | 2020-07-08 | 2023-01-19 | Kevin Mike NICKELS | Automation of user identity using network protocol providing secure granting or revocation of secured access rights |
US11849053B2 (en) * | 2020-07-08 | 2023-12-19 | Atsign, Inc. | Automation of user identity using network protocol providing secure granting or revocation of secured access rights |
US20220103550A1 (en) * | 2020-09-30 | 2022-03-31 | International Business Machines Corporation | Providing isolated containers for user request processing |
US11368459B2 (en) * | 2020-09-30 | 2022-06-21 | International Business Machines Corporation | Providing isolated containers for user request processing |
Also Published As
Publication number | Publication date |
---|---|
US9380058B1 (en) | 2016-06-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10367817B2 (en) | Systems and methods for challengeless coauthentication | |
US9659160B2 (en) | System and methods for authentication using multiple devices | |
US9380058B1 (en) | Systems and methods for anonymous authentication using multiple devices | |
CN110915183B (en) | Block chain authentication via hard/soft token validation | |
US10542002B2 (en) | Systems and methods for device authentication | |
US10685526B2 (en) | Architecture for access management | |
US11770261B2 (en) | Digital credentials for user device authentication | |
US11093626B2 (en) | Security systems and methods for continuous authorized access to restricted access locations | |
US10027631B2 (en) | Securing passwords against dictionary attacks | |
US10176310B2 (en) | System and method for privacy-enhanced data synchronization | |
US20190096210A1 (en) | Methods and Apparatus for Management of Intrusion Detection Systems using Verified Identity | |
US11245526B2 (en) | Full-duplex password-less authentication | |
US20170257364A1 (en) | Systems and methods for authentication using authentication votes | |
US9280645B1 (en) | Local and remote verification | |
WO2017003651A1 (en) | Systems and methods for anonymous authentication using multiple devices | |
WO2019009971A1 (en) | Systems and methods for challengeless coauthentication | |
TWI625643B (en) | Anonymity based authentication method for wireless sensor networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: UNIVERSITY OF SOUTH FLORIDA, FLORIDA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIGATTI, JARRED ADAM;GOLDGOF, DMITRY;CETIN, CAGRI;AND OTHERS;REEL/FRAME:036542/0245 Effective date: 20150701 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |