Token UWB-IMU-based two-factor authentication system

Abstract

An exemplary authentication system and method that employ a short-range communicating token to perform a first authentication of a login device or user upon the authentication process initiated and prior to passwords or other biometric data being provided for a second authentication operation. The short-range non-networked token in this multi-factor authentication framework can beneficially be verified without user input while separating the username and password in the authentication process to mitigate attacks.

Description

TOKEN UWB-IMU-BASED TWO-FACTOR AUTHENTICATION SYSTEMCross-Reference to Related Applications

[0001] This PCT application claims priority to, and the benefit of, U.S. Provisional Patent Application No. 63 / 584,477, filed September 21, 2023, entitled “Wearable UWB- IMU-Based Two-Factor Authentication System,” the content of which is incorporated by reference herein in its entirety.Background

[0002] Two-factor authentication (2FA) is generally used to verify the possession of a legitimate token or network access after verifying the knowledge of a password. However, 2FA is vulnerable to various attacks, such as phishing, in which victims are lured to approve a malicious login request from an adversary.

[0003] There is a benefit to improving existing systems and methods.Summary

[0004] An exemplary authentication system and method are disclosed that employ a short-range communicating token to perform a first authentication of a login device or user upon the authentication process initiated and prior to passwords or other biometric data being provided for a second authentication operation. The short-range non-networked token in this multi-factor authentication framework can beneficially be performed without user input and that separates the username and password in the authentication process to mitigate attacks such as remote phishing, co-located phishing, stolen-token attack, malicious login device, malicious token attack, man-in-the-middle attack, 2FA-fatigue attack, and phantom-login attacks. As compared to a conventional two-factor authentication system that employs username and password contemporaneously together, this separation in the username and password by a token requiring short-way communication makes attacks associated with 2FA unlikely or even more difficult. The token may be implemented in any one of any physical forms, for example, key-chain token, smartwatch, smart phone, or other wearable devices.

[0005] The fundamental reason why passwords can easily be garnered during a phishing attack is that the second factor that verifies the possession of a token or authenticator device occurs after the credentials have been provided by the user. This order of verification is necessary on traditional systems since otherwise, an adversary could trigger a large number of second-factor notifications, creating a nuisance for users and drainingorganizational resources. The operation is nevertheless open to other attacks that the exemplary authentication system and method can thus mitigate.

[0006] With the inclusion of short-range communication, for example, radios, the autonomous token can be further hardened using proximity based on localization processes (e.g., ultra- wideband (UWB) based localization operation) that are negotiated between a login device and the token via the short-range communication prior to the password being provided or employed in the authentication process. To this end, usernames and password / biometric- based factor authentication are separated from one another and further employ a second- factor authentication based on token physical possession and proximity. The sequence of operations makes various attacks noted above and described herein very difficult to implement.

[0007] In some aspects, the techniques described herein relate to a method including: receiving, by an authentication server for a website, an authentication or login request from a login computing device, wherein the authentication or login request includes a username; transmitting, from the authentication system, to the computing device, a token authentication request for an action by a token operatively connected and in proximity to the login computing device; receiving, at the login computing device, token data stored or assessed at the token; transmitting, from the login computing device to a token authentication system, the token data; determining, by the token authentication system and based, at least in part, on the token data, that the token data is associated with the authentication or login request and the username; providing, by the token authentication system or the login computing device, a token authenticated certificate to the authentication server of the website; prompting, by the authentication server, the login computing device to provide a password or biometric associated scan or action; and responsive to determining that the password or biometric associated scan or action matches the username, granting by the authentication server the authentication or login request and providing access to the website.

[0008] In some aspects, the techniques described herein relate to a method, further including: executing a localization operation between the login computing device and the token.

[0009] In some aspects, the techniques described herein relate to a method, wherein the localization operation includes a two-way ranging operation between the login computing device and the token.

[0010] In some aspects, the techniques described herein relate to a method, wherein determining whether the token is in proximity to the login computing device includes: priorto prompting the login computing device to provide the password or biometric associated scan or action, determining at least one angle of arrival measurement from at least one signal transmitted during the two-way ranging operation based, at least in part, on a phasedifference of arrival; and validating, by the authentication system, the at least one angle of arrival measurement.

[0011] In some aspects, the techniques described herein relate to a method, further including: receiving, by the authentication system, localization data generated from the executed localization operation; and determining, by the authentication system, whether the token is in proximity to the computing device by determining, based at least in part, on the localization data, at least one of a distance measurement between the token and the computing device, a relative angle between the token and the computing device, and a signal direction between the token and the computing device.

[0012] In some aspects, the techniques described herein relate to a method, wherein the localization operation includes providing a security key data stored or generated by the token to the authentication system.

[0013] In some aspects, the techniques described herein relate to a method, wherein determining whether the token is in proximity to the computing device includes: determining whether the token is positioned within a predefined region relative to the computing device.

[0014] In some aspects, the techniques described herein relate to a method, wherein the predefined region is a user-configurable parameter.

[0015] In some aspects, the techniques described herein relate to a method, wherein each of the token and the computing device includes at least one ultra- wideband (UWB) radio, and wherein the localization operation is a UWB-based operation.

[0016] In some aspects, the techniques described herein relate to a method, further including: responsive to receiving the authentication or login request, transmitting, by the authentication server, a session key and / or encrypted key for use by the login computing device and / or the token.

[0017] In some aspects, the techniques described herein relate to a method, further including: responsive to determining, by the token, that the received session key and / or encrypted key is authentic, transmitting, by the token, token data directly to the authentication system.

[0018] In some aspects, the techniques described herein relate to a method, wherein the authentication system or login computing device maintains a per-user shared secret foreach of a plurality of users that is used to encrypt messages transmitted to the token and / or the computing device.

[0019] In some aspects, the techniques described herein relate to a method, further including: registering, by the authentication system or via a registration system, the token with the login computing device.

[0020] In some aspects, the techniques described herein relate to a method, wherein the password or biometric associated scan or action is stored and / or directly retrieved from the token.

[0021] In some aspects, the techniques described herein relate to a method, wherein the token is at least one of a wearable device, ring, a smartphone, a smartwatch, a key-chain, or a fob.

[0022] In some aspects, the techniques described herein relate to a method, wherein the token includes at least one of an inertial measurement unit, an accelerometer, and a gyroscope.

[0023] In some aspects, the techniques described herein relate to a method, wherein determining whether the password or biometric associated scan or action matches includes authenticating a captured signature, fingerprint, and / or faceprint using a machine learning model.

[0024] In some aspects, the techniques described herein relate to a method, wherein the machine learning model includes at least one of a support vector machine and a Siamese Neural Network (SNN).

[0025] In some aspects, the techniques described herein relate to a method, wherein determining whether the password or biometric associated scan or action matches includes prompting a user to move the token in accordance with a predetermined motion signature.

[0026] In some aspects, the techniques described herein relate to a method, wherein the predetermined motion signature is authenticated based, at least in part, on detected changes in acceleration and angular velocity.

[0027] In some aspects, the techniques described herein relate to a method, wherein the predetermined motion signature or trajectory is authenticated based, at least in part, on a distance measure between one or more features of an input signature and a stored signature associated with a user of the computing device.

[0028] In some aspects, the techniques described herein relate to a non-transitory computer-readable medium having instructions stored thereon, wherein execution of the instructions by a processor causes the processor to: receive an authentication or login requestfrom a computing device, wherein the authentication or login request includes a username; receive token data stored or assessed at a token associated with the computing device; determine, based, at least in part, on the token data, that the token data is associated with the authentication or login request and the username; prompt the computing device to provide a password or biometric associated scan or action; and responsive to determining that the password or biometric associated scan or action matches the username, grant the authentication or login request and provide access to a website.

[0029] In some aspects, the techniques described herein relate to a non-transitory computer-readable medium, wherein execution of the instructions by the processor further causes the processor to: receive localization data generated from execution of a localization operation between the computing device and the token; and determine whether the computing device is in proximity to or within a predetermined range of the token based, at least in part, on the received localization data.Brief Description of the Drawings

[0030] FIGS. 1A - ID each show an exemplary multi-factor authentication system that employ a short-range communicating token to perform an authentication prior to passwords or other biometric data being required or provided for a second authentication operation in accordance with an illustrative embodiment.

[0031] FIG. 2A is a diagram illustrating an example authentication method between a login computing device, an authentication system, and the short-range communicating token in accordance with an illustrative embodiment.

[0032] FIG. 2B is a flowchart diagram illustrating the example authentication method between the login computing device, the authentication system, and the short-range communicating token in accordance with an illustrative embodiment.

[0033] FIG. 3A illustrates a conventional two-factor authentication embodiment.

[0034] FIG. 3B illustrates a three-factor embodiment of the exemplary system, further employing proximity or localization process.

[0035] FIGS. 4A - 4B illustrate example authentication procedures for the exemplary system comprising a handshake protocol, a location authentication protocol, and a knowledge / biometric authentication protocol.

[0036] FIG. 5A illustrates an example registration protocol exchanging messages between the server, login device, and ultra- wideband (UWB) token.

[0037] FIG. 5B illustrates an example login (i.e., handshaking) protocol configured to establish and verify a server-token communication.

[0038] FIG. 5C illustrates an example location authentication protocol configured to verify the location of the user.

[0039] FIG. 5D illustrates an example two-way ranging measurement method and a phase-difference-of-arrival measurement method employed by the location authentication protocol.

[0040] FIG. 5E illustrates an example knowledge / biometric authentication protocol configured to verify the user identity and intent.

[0041] FIG. 6A illustrates prototypes of an embodiment of the exemplary system employing localization-based UWB tokens.

[0042] FIG. 6B illustrates examples of tokens that can be employed in the exemplary system employing localization-based UWB tokens.

[0043] FIG. 6C illustrates the visual and data representations of the word “MyPassword” written by two volunteers.

[0044] FIG. 6D illustrates the feature visualization of signatures from 10 users and the similarity of the signatures computed by a Siamese neural network.

[0045] FIG. 7 illustrates the evaluation of the angle and distance measurement of a localization-based UWB token.

[0046] FIGS. 8 A - 8C illustrate the distance and angle measurement of the exemplary system at different locations (e.g., atrium, common area, lab).

[0047] FIG. 8D illustrates the Received Signal Strength Indicator (RS SI) variation at different angles of the Bluetooth technology.

[0048] FIG. 9A illustrates the trade-off between true positive rate (TPR) and true negative rate (TNR) at different values of punishing factor a.

[0049] FIG. 9B illustrates the true negative rate (TNR) and true positive rate (TPR) of each individual signature by the volunteers.

[0050] FIG. 9C illustrates the receiver operating characteristic curve (ROC) for low- quality signatures.

[0051] FIG. 9D illustrates the true negative rate (TNR) under a known-text (KT) attack, shoulder-surfing (SS) attack, and a known-text should-surfing (KT-SS) attack.

[0052] FIG. 9E illustrates an example of a failed and a successful KT-SS attack, in which the signature word was “keepcoding.”

[0053] FIG. 9F illustrates the input time for a smart ring, typing a password on a keyboard, and typing a password on a virtual keyboard for the four password types, e.g., Num8, Letter8, 3Class8 (i.e., 3cls8), and 4Classl2 (i.e., 4clsl2).

[0054] FIG. 10 illustrates the Likert scale chart of the feedback on the smart ring from the volunteers.Detailed Description

[0055] Some references, which may include various patents, patent applications, and publications, are cited in a reference list and discussed in the disclosure provided herein. The citation and / or discussion of such references is provided merely to clarify the description of the disclosed technology and is not an admission that any such reference is “prior art” to any aspects of the disclosed technology described herein. In terms of notation, “[n]” corresponds to the nth reference in the list. For example, [1] refers to the first reference in the list. All references cited and discussed in this specification are incorporated herein by reference in their entirety and to the same extent as if each reference was individually incorporated by reference.

[0056] Embodiments of the present disclosure provide a system and method that can secure authenticating messages exchanged within a system / computing framework in order to mitigate various attacks, including phishing and phantom-login attacks. In one implementation, the proposed method includes verifying a token (e.g., by analyzing token data provided by or assessed at a token) prior to verifying a password or biometric-associated scan or action. The noted method is not vulnerable to numerous types of computer and network system vulnerabilities, including malicious attacks. Notably, the integrity and performance of the framework can be enhanced by employing a localization operation (e.g., UWB-based localization operation) to determine whether the token is in proximity to a computing device as part of or in addition to the above-noted token verification steps / operations.

[0057] Example System #1

[0058] FIGS. 1A - ID each shows an exemplary multi-factor authentication system 100 (shown as 100a, 100b, 100c, lOOd) that employ a short-range communicating token to perform an authentication operation prior to passwords or other biometric data being required or provided for a second authentication operation in accordance with an illustrative embodiment. Fig. 1A shows the short-range communicating token operating with an authentication system over a network through the login computing device. Fig. IB shows theshort-range communicating token operating with an authentication module executing on the login computing device. Fig. 1C shows the authentication system or module executing in the website infrastructure. In each of Figs. 1 A -1C, the authentication may optionally employ localization operation that may be determined using machine learning models. In Figs. 1 A -IC, the machine learning model is executed on the authentication system or module. In Fig.ID, the machine learning model is executed on the token.

[0059] In Fig. 1A, the example system 100a comprises a short-range communication token 101 (shown as “token” 101), a login computing device 102 (shown as “Computing device” 102), and an authentication system 103. As shown, the token 101, the computing device 102, and the authentication system 103 are in electronic communication with one another by exchanging information over a network 112 (e.g., over the Internet).

[0060] The token 101 can be or comprise a wearable device, ring, smartphone, mobile device, smartwatch, keychain, fob, or a combination thereof. As depicted in Fig. 1A, the token 101 includes one or more UWB radios 104a (e.g., UWB chips or hardware), a communications interface 105a, a processor 106a, and a memory 107a. Additionally, as shown, the token 101 may include an inertial measurement unit (1MU) 108 and / or one or more additional sensors, such as an accelerometer and / or a gyroscope, that can be employed for providing biometric-associated scans or actions as part of the proposed method.

[0061] The login computing device 102 may be a laptop computer, a desktop computer, a cloud computing device, one or more servers, a network, a hand-held computer, a mobile computing device, a mobile phone, a personal digital assistant, a tablet computer, or combinations thereof. As shown, the computing device 102 includes one or more UWB radios 104b, a communications interface 105b, a processor 106b, a memory 107b, and a user interface 109b. The computing device 102 can be a mobile device that is accessible to a user via one or more input devices (e.g., keyboard, graphical user interface) through the communications interface 105b / user interface 109b.

[0062] The authentication system 103 may be a web server configured to provide access to a system, platform, and / or one or more databases. As illustrated in Fig. 1 A, the authentication system 103 includes a communications interface 105c, a processor 106c, a memory 107c, and one or more machine learning models 110. The authentication system 103 can be implemented or embodied (via the processor 106c and memory 107c) as a program stored on a computer-readable medium.

[0063] To initiate an authentication operation to access a website (shown by “website” server 111 ) by a login computing device 102, e.g., to access a website, the logincomputing device 102 transmits, via the network 112, an authentication or login request, including a username to the website server 111. The website server 111 receives, via the network 112, the authentication or login request from the login computing device 102. The website 111, via its authentication server, then transmits, via the network 112, a token authentication request to the login computing device 102. The login computing device 102 receives, via the network 112, the token authentication request and transmits the token authentication request to the token 101, operatively connected and in proximity to the computing device 102.

[0064] The short-range communicating token 101, associated with the computing device 102 (in being connected by the short-range communication network), receives the token authentication request from the login computing device 102. The token 101 then transmits a first token data stored or assessed at the token 101 to the login computing device 102. In some embodiments, the assessment is based on an additional multi-factor authentication (e.g., localization operation or other physical operation conducted by the token 101 or in conjunction with the token 101). The login computing device 102 then receives the first token data from the token 101 and transmits, via the network 112, the first token data to the authentication system 103. This first- factor authentication ensures the login username input is meaningful in the authentication process and ensures that attacks such as remote phishing, co-located phishing, stolen-token attack, malicious login device, malicious token attacks, man-in-the-middle attacks, 2FA-fatigue attack, and phantom-login attacks cannot be initiated. In traditional systems the password is being immediately or contemporaneously provided with the username to the website server 111 (and its associated authentication server (not shown)), which is avoided by the claimed system.

[0065] The token authentication system 103 receives, via the network 112, the first token data from the computing device 102. The authentication system 103 determines, based on the first token data, that the first token data is associated with the authentication or login request and the username, and that the token is indeed in proximity to the computing device. The authentication system 103 then transmits, via the network 112 and through the computing device 102, a token authenticated certificate to the authentication server of the website. In some embodiments, the authentication system 103 transmits the authenticated certificate to the authentication server of the website

[0066] The authentication server of the website 111 then prompts the user via the login computing device 102 for the password or biometric scan. Authentication of the password or biometric scan can be performed by the authentication server of the website 111.

[0067] Example System #2

[0068] Fig. IB illustrates the example system 100b comprising the token 101 and the login computing device 102 (shown as 102’) employing an authentication module 103 (shown as 103’) executing on the login computing device 102’.

[0069] The computing device 102’ transmits, via the network 112, an authentication or login request including a username to the website 111. The website 111 receives, via the network 112, the authentication or login request from the computing device 102’. The website 11 1 then transmits, via the network 112, a token authentication request to the computing device 102’. The computing device 102’, via the network 112, receives the token authentication request and transmits the token authentication request to the token 101, operatively connected and in proximity to the computing device 102’.

[0070] The token 101, associated with the computing device 102’, receives the token authentication request from the computing device 102’. The token 101 then transmits a first token data stored or assessed at the token 101 to the authentication module 103’ executing on the login computing device 102’.

[0071] The authentication module 103’ executing on the computing device 102’, receives the first token data from the token 101. The authentication module 103’ determines, based on the token data, that the first token data is associated with the authentication or login request and the username. The authentication module 103 then transmits a request to the token 101 for a password or biometric-associated scan or action.

[0072] The token authentication module 103’ receives, via the network 112, the first token data from the token 101. The authentication module 103’ determines, based on the first token data, that the first token data is associated with the authentication or login request and the username. The authentication module 103’ then transmits, via the network 112, a token authenticated certificate to the authentication server of the website 11 1.

[0073] The authentication server of the website 111 then prompts the user via the login computing device 102’ for the password or biometric scan. Authentication of the password or biometric scan can be performed by the authentication server of the website 111.

[0074] Example System #3

[0075] Fig. 1C illustrates the example system 100c that includes the token 101, login computing device 102, and the authentication system 103 (shown as 103”) implemented in the website infrastructure 111 (shown as 111’). As shown, the token 101 , login computing device 102, and the authentication system 103 embedded in the website 111 ’ are in electronic communication with one another by exchanging information over a network 112.

[0076] To initiate an authentication operation to access a website 111’ by the login computing device 102, e.g., to access a website, the login computing device 102 transmits, via the network 112, an authentication or login request including a username to the website server 111 ’. The website server 111 ’ receives, via the network 112, the authentication or login request from the login computing device 102. The website 111’, via its authentication server that also serves as or operates with the authentication system 103”, then transmits, via the network 112, a token authentication request to the login computing device 102. The login computing device 102 receives, via the network 1 12, the token authentication request and transmits the token authentication request to the token 101 operatively connected and in proximity to the computing device 102.

[0077] The short-range communicating token 101 receives the token authentication request from the login computing device 102. The token 101 then transmits a first token data stored or assessed at the token 101 to the login computing device 102. The login computing device 102 then receives the first token data from the token 101 and transmits, via the network 112, the first token data to the authentication system 103”.

[0078] The token authentication system 103” receives, via the network 112, the first token data from the computing device 102. The authentication system 103” determines, based on the first token data, that the first token data is associated with the authentication or login request and the username. The authentication system 103” then prompts the user via the login computing device 102 for the password or biometric scan. Authentication of the password or biometric scan can be performed by the authentication server of the website 11 1’.

[0079] Example System #4

[0080] Fig. ID illustrates an example system lOOd comprising a token 101 (shown as 101’), the computing device 102, and the authentication system 103’. As shown, the token 10T, the computing device 102, and the authentication system 103’ are in electronic communication with one another by exchanging information over a network 112.

[0081] To initiate an authentication operation to access a website 111 by the login computing device 102, e.g., to access a website, the login computing device 102 transmits, via the network 112, an authentication or login request including a username to the website server 11 1. The website server 1 11 receives, via the network 112, the authentication or login request from the login computing device 102. The website 111, via its authentication server, then transmits, via the network 112, a token authentication request to the login computing device 102. The login computing device 102 receives, via the network 112, the tokenauthentication request and transmits the token authentication request to the token 101 ’ operatively connected and in proximity to the computing device 102.

[0082] The short-range communicating token 10 T receives the token authentication request from the login computing device 102. The token 101’ then transmits a first token data stored or assessed at the token 10T to the login computing device 102. The first token data may be generated by the machine learning model 110 executing at the token. The login computing device 102 then receives the first token data from the token 101’ and transmits, via the network 1 12, the first token data to the authentication system 103.

[0083] The token authentication system 103 receives, via the network 112, the first token data from the computing device 102. The authentication system 103 determines, based on the first token data, that the first token data is associated with the authentication or login request and the username. The authentication system 103 then transmits, via the network 112 and through the computing device 102, a token authentication certificate to the authentication server of the website. In some embodiments, the authentication system 103 transmits the authenticated certificate to the authentication server of the website

[0084] The authentication server of the website 111 then prompts the user via the login computing device 102 for the password or biometric scan. Authentication of the password or biometric scan can be performed by the authentication server of the website 111.

[0085] Example Method

[0086] Fig. 2A is a signal diagram illustrating an example method between the token 101, computing device 102, and authentication system 103, according to certain implementations of the present disclosure, e.g., as described in relation to Fig. 1C. Similar but different operations may be performed for the system described in relation to Figs. 1A, IB, and ID.

[0087] For the example shown in Fig. 1C, at step / operation 202, the authentication system 103” registers / associates the token 101 with the computing device 102, for example, in response to a registration request transmitted from the computing device 102 to the authentication system 103. The authentication system 103” can associate a username with the token 101 and the computing device 102. In some embodiments, another computing device / system (e.g., a third-party system) may register / associate the token 101 with the computing device 102 and provide information to the authentication system 103” upon request.

[0088] At step / operation 204, the computing device 102 sends an authentication or login request to the authentication system 103”. The authentication or login request can include the username.

[0089] At step / operation 206, responsive to receiving the authentication or login request, the authentication system 103” sends a token authentication request to verify whether the token 101 is associated with the computing device 102. In various examples, the authentication system 103” can send the token authentication request directly to the token 101 or through the computing device 102. In some implementations, in addition to the token authentication request, the authentication system 103” provides a session key and / or encryption key for use between the token 101 and the computing device 102 in order to secure communications between the token 101 and the computing device 102. In an aspect, the authentication system 103” or computing device 102 maintains a per-user shared secret for each of a plurality of users that is used to encrypt messages transmitted between the token 101 and the computing device 102.

[0090] At step / operation 208, in response to receiving the token authentication request with respect to the token 101 that is operatively connected and in proximity to the computing device 102, the computing device 102 initiates a handshaking operation with the token 101.

[0091] Optionally, at step / operation 210, in addition to or instead of the handshaking operation, the token 101 and the computing device 102 execute a localization operation, such as a two-way ranging or UWB-based operation, in response to the token authentication request received from the authentication system 103”.

[0092] At step / operation 212, the token 101 generates token data that is stored or assessed at the token 101.

[0093] At step / operation 214, the token 101 or computing device 102 sends the generated token data to the authentication system 103”. In some implementations, the token 101 determines whether the session key and / or encrypted key provided by the authentication system 103” via the computing device 102 is authentic, and responsive to the determination, transmits token data directly to the authentication system 103”. Optionally, in some implementations, the token 101 or computing device 102 may additionally send localization data generated from the execution of the localization operation to the authentication system 103”.

[0094] At step / operation 216, the authentication system 103” analyzes the received token data to determine whether the token data is associated with the authentication or loginrequest and the username that is, in turn, associated with the registered computing device 102. In some implementations, the authentication system 103” further analyzes the received localization data, as described in more detail below in connection with Fig. 2B.

[0095] At step / operation 218, the authentication system 103” prompts the computing device 102 or the token 101 for a password or biometric-associated scan or action. In some implementations, the password or biometric-associated scan or action is stored and / or directly retrieved from the token 101.

[0096] At step / operation 220, responsive to the request, the computing device 102 transmits the requested password or biometric-associated scan or action to the authentication system 103”.

[0097] At step / operation 222, the token 101 (or authentication system 103”) validates the password or biometric-associated scan or action to determine whether it matches that associated with the username. In some examples, the token 101 (or authentication system 103”) authenticates a captured signature, fingerprint, and / or faceprint, for example, using one or more machine learning models (110). The example machine learning model can comprise a Siamese Neural Network or a support vector machine, as described in more detail below. In some implementations, step / operation 222 can be at least partially performed by the computing device 102 or another computing device / system (e.g., a third-party system), which can also include one or more machine learning models (110). In some implementations, the token 101 sends an indication to the authentication system 103” confirming validation of the password or biometric-associated scan or action.

[0098] At step / operation 224, responsive to determining that the password or biometric associated scan or action matches the username, the authentication system 103” grants the authentication or login request and provides the computing device 102 access to the website. In some examples, the authentication system 103” determines whether the password or biometric-associated scan or action matches by prompting a user to move the token in accordance with a predetermined motion signature that can be authenticated based on detected changes in acceleration and angular velocity (e.g., via the IMU / sensors 108 of the token 101). In some implementations, using the machine learning model(s), the authentication system 103” can authenticate a predetermined motion signature or trajectory based on a distance measure between one or more features (e.g., feature vector) of an input signature and a stored signature associated with a user of the computing device 102.

[0099] As noted above, similar but different operations may be performed for the system described in relation to Figs. 1A, IB, and ID. The example method shown in Fig. 2Acan be implemented in the example system 100a when the authentication system 103 operates independently, and the machine learning models for verifying biometric-associated scans or actions are employed by the authentication system 103.

[0100] The example method shown in Fig. 2A can be implemented in the example system 100b of Fig. IB, where the authentication module 103’ is executed on the login computing device 102’.

[0101] The example method shown in Fig. 2A can be implemented in the example system 100c of Fig.lC, where the authentication system 103” is executed in the website infrastructure.

[0102] Fig. 2B is a flowchart of an example method 200 for authenticating an authentication or login request by determining whether the token 101 is in proximity to the computing device 102, in accordance with certain embodiments described herein. In some implementations, the method 200 is at least partially performed using other system components (e.g., token 101, 101’ computing device 102, 102’) described in connection with Figs. 1 A - ID. Additionally, or alternatively, the method 200 can be at least partially performed by a processing circuitry (for example, but not limited to, an application-specific integrated circuit (ASIC), or a central processing unit (CPU)). In some examples, the processing circuitry may be electrically coupled to and / or in electronic communication with other circuitries of an example computing device. In some examples, embodiments may take the form of a computer program product on a non-transitory computer-readable storage medium storing computer-readable program instruction (e.g., computer software).

[0103] At step / operation 230, the authentication system 103 (e.g., 103, 103’, 103”) receives localization data associated with a localization operation (e.g., executed between the token 101 and computing device 102). As noted above, localization data can be generated by the token 101 and / or the computing device 102 and transmitted to the authentication system 103 via the computing device 102 or directly from the token 101. Advantageously, in some implementations, the authentication system 103 interacts with the token 101 through the computing device 102 and not directly (e.g., over the Internet) to further mitigate unwanted attacks.

[0104] At step / operation 240, the authentication system 103 analyzes the received localization data and determines at least one distance measurement between the token 101 and the computing device 102, a relative angle between the token 101 and the computing device 102, and / or a signal direction between the token 101 and the computing device 102.

[0105] At step / operation 250, the authentication system 103 validates the determined distance measurement(s), relative angle, and / or signal direction, for example, based on a determined phase difference of arrival corresponding with the localization operation. In some implementations, the authentication system 103 determines at least one angle of arrival measurement from at least one signal transmitted during the two-way ranging operation between the token 101 and the computing device 102 based on a phase difference of arrival and validates the at least one angle of arrival measurement.

[0106] At step / operation 260, the authentication system 103 determines whether the token 101 is in proximity to the computing device 102 based, at least in part, on the above analysis. For example, the authentication system can determine whether the token 101 is within a predefined region relative to the computing device 102 or within a predetermined range of the computing device 102. The predefined region can be a user-configurable parameter allowing the user to increase or decrease the security requirements based on preferences (e.g., based on a current geographic location).

[0107] At step / operation 270, if the authentication system 103 determines that the token 101 is in proximity to the computing device 102, then the authentication system 103 proceeds to prompt the computing device 102 or token 101 for a password or biometric- associated scan or action.

[0108] Example Embodiments

[0109] Fig. 3A shows a conventional two-factor authentication operation. As shown in Fig. 3 A, after login credential verification 302 on the login device 304 (i.e., a computing device), the web server 306 (i.e., authentication server) sends a challenge 308 to the user’s registered smartphone 310 (i.e., token) to request the user’s approval, affirming the legitimacy of the login attempt. However, this mechanism is vulnerable to phishing attacks as follows: (1) an adversary creates a malicious website A' which resembles in appearance to the authentic website, tricking the victim into submitting their credentials (username and password); (2) the adversary then uses the credentials to log into the authentic website; and (3) the authentic website trigger a second-factor approval process, and the victim may approve this illegitimate login request since the victim believes that it is their own request that is triggering this notification.

[0110] Apart from phishing, phantom-login

[0036] and 2FA-fatigue attacks [4], where victims are tricked into approving the login request from the adversary out of habit, are also feasible attacks on existing 2FA solutions. Such attacks have successfully fooled even IT professionals in the tech industry (Cisco

[0015] , Uber

[0023] ).

[0111] Fig. 3B shows a two-factor embodiment or three-factor embodiment of the exemplary system. The exemplary system involves message exchange among the three main components: (1) the token, e.g., ultra-wideband (UWB) token 312, (2) the login device 102 (now shown as 304), and (3) the web server 111 (now shown as 306) to which the user wishes to login. However, as depicted in Fig. 3B, the communication between the web server and the token is facilitated via the login device acting as a conduit, with UWB facilitating precise localization.

[0112] Example Authentication Procedures

[0113] Account signup or registration, where a user opens a new account at a website, occurs from a secure location with no eavesdroppers or malicious actors. This requirement exists for almost all authentication systems. The user selects a username and a password, which will be stored in the server’s database, as usual. Then the user registers the token with the website by requesting the login device to scan for nearby tokens. Henceforth, the token can be used as a have-factor for all logins.

[0114] Additionally, to support different knowledge / biometric authentication methods, the exemplary system, allows the token to securely store the user’s password when the user plans to use the token as a password manager, like OnlyKey

[0013] . The stored password may be retrieved from the token only using the user’ s predefined unlocking method, such as a valid fingerprint or a motion signature. This unlocking method functions as the knowledge / biometric authentication factor as an alternative to remembering passwords. When the user opts in, the user also registers a valid fingerprint or draws a motion pattern at the token.

[0115] Figs. 4A - 4B shows example authentication procedures for the exemplary system comprising a handshake protocol, a location authentication protocol, and a knowledge / biometric authentication protocol.

[0116] Regular account logins in the exemplary system, depicted in Fig. 4A, are performed with a marked difference from traditional methods: after the user supplies the username as shown in subpanel (a), the website (i.e., server, authentication system) first verifies proximity of the login device (i.e., a computing device) and the user’s token (the have-factor) as shown in subpanel (b). After successful verification of the have-factor, the website requests the password, which may be either supplied by typing the password or by the token using biometric or motion pattern-based authentication, actively performed by the user as shown in subpanel (c).

[0117] As shown in Fig. 4B, authentication procedures employed by the exemplary system include three protocols: a login (i.e., handshaking) protocol, a location authentication protocol, and a knowledge / biometric authentication protocol. As shown in subpanel (a), the handshaking protocol is configured to set up communication between the server and the token. As shown in subpanel (b), the location authentication protocol is configured to verify the location of the user. As shown in subpanel (c), the knowledge / biometric authentication protocol is configured to verify the identity and intent of the user.

[0118] Registration (Signup) Protocol. The process of account signup includes registering the token with a new website (creating a shared secret, end to end (E2E) , and associating it with the token’s ID). Fig. 5A shows an example registration protocol exchanging messages between the server, login device, and UWB token.

[0119] As shown in Fig. 5A, when the user creates a username with a password 502 on a new website 111 (now shown as 501) (e.g., authentication server), the website requests the login device 504 (e.g., computing device 102) to scan for a token nearby (over UWB). The correct token 508, in the valid region, responds to this scan request 506 with its ID 510. The server 501 creates a shared secret, called E2E. for this token. Then, the server sends the E2E key to the token together with its website’s domain name, as a combined data 512, through the login device acting as an intermediary. A secure end-to-end channel during account signup protocol provides (1) a secure Hypertext Transfer Protocol Secure (HTTPS) connection between the login device and the web server, and (2) confidence that there are no malicious UWB eavesdroppers in the vicinity of the login device at this stage.

[0120] Handshake protocol. Fig. 5B shows an example handshake protocol configured to establish and verify a server-token communication. As shown in Fig. 5B, the authentication procedure starts with the user entering the username 502 on a website 111 (now shown as 501) loaded over a secure HTTPS connection. Once the server 501 receives the login request, the handshake protocol commences. The main function of this protocol is to convince the token 508 that the token 101 (now shown as 508) is communicating with a registered website, and convince the website 501 that the website is communicating with a live token. The server uses its long-term shared secret E2E to send a combined data 514 to the token 508 via the login device 504, and also generates a session key SK for securing communication between the login device and the token.

[0121] Since the domain name is included by the login device 504, remote phishing attacks are caught by the token 508 since the website name the token 508 obtains does notmatch the registered domain. Malicious tokens cannot intercept the UWB messages and generate their own replies since they may not be able to decrypt and increment the E2E encrypted nonce supplied by the server.

[0122] Location Authentication Protocol. Once the handshake protocol is complete, the server requests the login device to start the location authentication protocol. Fig. 5C shows an example location authentication protocol configured to verify the location of the user. Fig. 5D shows example two-way ranging measurement method (subpanel a) and phase- difference-of-arrival measurement method (subpanel b) employed by the location authentication protocol.

[0123] As shown in Fig. 5C, localization 516 is performed using a ranging measurement method (e.g., two-way ranging) and an angle measurement method (e.g., phase- difference-of-arrival) 18. However, all UWB messages are encrypted using SK, connecting this protocol with the handshake protocol. The location authentication protocol employs an asymmetric two-way ranging (TWR) method as specified in the IEEE 802.15.4z standard

[0021] to measure distances and a phase-difference-of-arrival (PDoA) method to measure the relative angles of the token to the login device 504. The location authentication protocol performs both measurement methods using the same TWR messages (since PDoA is a passive operation), and the message exchange is encrypted using the session key SK to prevent eavesdropping.

[0124] The angle and distance measurements generated from TWR and PDoA provide the location of the token. As shown in Fig. 5C, post location authentication protocol, the token sends an E^E-encrypted message 520, including the distance measurement, to the login device 504. The login device 504 packs the observed distance, the observed angle, and the token’s E2E-encrypled message 522, and sends to the server 501. The server 501 will check: (1) if the token 508 is legitimate by decrypting the token ID and incremented nonce and (2) if the token 508 is physically located within the valid area in the vicinity of the login device based on the distance and angles reported by the token and the login device. These checks prevent co-located phishing and phantom-login attacks.

[0125] Table 1 shows the operations of providing angle and distance measurements of the TWR and PDoA methods.Table 1

[0126] Knowledge / Biometric Authentication Protocol. While a legitimate token’s close proximity to the login device has been verified by the handshaking and locationauthentication protocol, two important vulnerabilities still remain: (a) the user’ s intent to login is not verified, and (b) whether or not the token is with the legitimate user is not verified. As a consequence, the user account is vulnerable when the token is lost or stolen. Therefore, a second factor verifying the know-factor or biometric factor is essential (to prove the legitimacy of the user), coupled with some action voluntarily taken by the user (to indicate user intent).

[0127] The exemplary system employs a general communication protocol between the server, the login device, and the token, which supports diverse know-factor and biometric-factor authentication protocols. After the location authentication passes, the server expects to be presented with the password. The user can either manually type in the password or unlock the password stored in the token, treating the token as a hardware password manager.

[0128] For manual password entry done on the laptop, the token is not involved in any further communication. When the user chooses fingerprint matching or motion signature matching, the login device directs the token to start the knowledge / biometric authentication protocol. Fig. 5E shows an example knowledge / biometric authentication protocol configured to verify the user identity and intent.

[0129] As shown in Fig. 5E, the token 508 indicates to the user that it is ready to accept an “unlocking” input. The user can use either a legal fingerprint or move the token in the registered pattern. Once the fingerprint or the motion signature 521 is verified, the token sends the SK -encrypted password to the login device 504. The login device can fill in the password input field automatically and then submit the password 524 to the server 501. In this protocol, the server 501 benefits from the simplicity of a general interface: whether the password is typed in manually or auto-filled, using the token is transparent to the webserver. Using the token 508 to store the password, it is feasible to use longer and randomized passwords, strengthening the overall system.

[0130] Experimental Results and Additional Examples

[0131] A study was conducted to develop the exemplary system and method employing an ultra-wideband (UWB) based localization operation to determine whether the token is in proximity to a computing device prior to verifying the password or biometric- associated scan or action.

[0132] Fig. 6A shows prototypes of the exemplary system. Each prototype shown in each subpanel (a), (b), and (c) included a login / computing device (e.g., laptop), a token (e.g.,keychain, watch, ring), and PDoA devices. The PDoA devices were configured to provide local authentication within a valid sector as shown in subpanel (d).

[0133] The study emulated a login system with an authentication process running at the server and a login page built with Flask framework at the client. Since laptops did not have embedded UWB, a UWB module was connected to the login device via USB to emulate a UWB-embedded login device. The study used an HP ENVY, Intel Core i7-10510U laptop with 16GB RAM as the login device. The study supplements the login device with two standalone UWB setups (mimicking a range-only and another range-and-angle setup) connected to the laptop over USB.

[0134] In the first setup shown in subpanel (a), the study used one TreklOOO transceiver as the UWB communication module at the login device. TreklOOO was a one- antenna transceiver that could perform distance measurements using TWR with nearby UWB devices but cannot perform Ao A measurements. This setup was similar to most existing state- of-the-art (SoA) mobile devices with UWB chips, such as iPhone

[0012] and Samsung Galaxy

[0018] . In the second setup shown in subpanel (b), the study used two DWM1002 doubleantenna devices as the UWB communication module, which can simultaneously perform TWR and measure the AoA of a nearby UWB device. To create an unambiguous feasible area sector, the login device should be equipped with two vertically aligned antenna arrays.

[0135] Fig. 6B shows tokens employed in the prototypes of the exemplary system. The token shown in subpanel (a) was a key chain coupled with a UWB chip, which was configured for location and password authentication. The token in subpanel (b) was a smartwatch employing a fingerprint sensor and a UWB chip, which was configured for location and fingerprint authentication. The token in subpanel (c) was a smart ring (i.e., a signing ring) coupled with a UWB chip, which was configured for location and motion signature authentication.

[0136] The study developed tokens of three different form factors: (i) A UWB -chip embedded token with no other sensors (a key-chain form-factor inspired by AirTags [2]); (ii) A smartwatch with a UWB chip and a fingerprint sensor (form-factor inspired by PayPal- Samsung integration

[0043] ); and (iii) A smart ring (form factor inspired by

[0014] and

[0056] ) with a UWB chip and an inertial sensor for authentication via motion signatures. These form factors demonstrated the possibility of developing the exemplary system on various state-of- the-art devices while sharing the same authentication pipeline as specified in Sections 2 and 3. All three tokens used the DWM1000 UWB module

[0016] controlled by an ARM Cortex MO ATSAMD21G18.

[0137] Key chain. The study developed a UWB token (3.2cm x 4.6cm) with a DWM1000 module and Cortex MO chip. In this prototype, the study expected the token to be used for location authentication, and the user demonstrate the know-factor by manually typing the password on the website. Since UWB chips have been widely deployed in UWB location tags [2] and modem smartphones

[0012] ,

[0018] , no extra hardware would be required to implement a UWB -only token. While the simple key-chain token only provided location authentication, it was still resistant to phishing attacks since the location of the token was verified first, and the token can detect a domain name mismatch before the system proceeded to prompt for the user’s password.

[0138] Smartwatch. The study designed a UWB-Auth token in a smartwatch form factor (A stack of two 3.7cmx3. 1cm PCBs) with a fingerprint sensor [1] in addition to the UWB. The fingerprint sensor was also controlled via the Cortex MO microcontroller. The user authorized access to the password by touching their finger to the fingerprint sensor. The fingerprint was stored and matched locally on the smartwatch, which unlocked a vault that contained the password. Once they pass the fingerprint authentication, the token sent the encrypted password to the login device, which automatically filled in the password.

[0139] Smart ring (Signing ring). Signatures are usually a stylized way of writing a name, perfected by individuals through a significant amount of practice. A signature is replete with intricate strokes and pauses, and potentially curves, lines, and dots. In many cases, well designed signatures, while visible on documents, are difficult to replicate by an attacker [10’]. Inherently, the knowledge of how a signature is drawn is important in addition to knowing the word the signature represents.

[0140] The study developed a ring form-factor hardware with two PCB layers, one for computing and inertial sensors and another for communication. The overall dimension was 3 cm x 1 ,8cm x 1.5 cm. The top layer consisted of a DWM1000 chip and a UWB antenna which only performed communication between the login device and the ring. The bottom layer housed a LSM6DSO 6-DoF inertial sensor, along with a Cortex M0. The UWB chip and IMU were connected to a Cortex M0 microcontroller for data processing. The IMU collected data at 70Hz rate.

[0141] The smart ring can capture the user’s finger movements using an inertial measurement unit (IMU) and match those to the user’s previously registered IMU readings. The movements capture both what is drawn by the user as well as how it is drawn, thereby increasing the feature space for matching signatures. Fig. 6C shows how the same word,“MyPassword”, written by two volunteers, differed visually and as observed from the IMU sensor data.

[0142] In contrast to traditional authentication approaches like passwords, matching signatures is an inexact process, meaning there can be instances when a legitimate user’s signature may fail to match with their registered signature. Similarly, there might be instances when an attacker may be able to draw something that looks similar to the user’s registered signature from the lens of the IMU readings.

[0143] Signature similarity-based matching by a smart ring. The study developed a signature matching algorithm based on IMU data clustering together the signatures drawn by an individual but separating them well when compared to the signatures of others. The matching algorithm did not use visible written signatures but rather finger movements (captured by the ring) that mimicked signatures on a flat surface. The study extracted and stored features of registered sensor data (when the user first signed up) and, at every login, matched these features with the sensor data obtained from the user freshly drawing their signature.

[0144] The study also used and modified hand-crafted features that closely resemble those qualitatively described in [11’] for suitability on a ring worn on the finger: (1) The time span of the handwriting sequence; (2) The mean and the standard deviation of acceleration of every 0.5s time window in 8 seconds (represents the positional derivatives described in [11’]); (3) The zero-crossing rate of acceleration of every 0.5s time window in 8 seconds; and (4) The Fast Fourier Transform (FFT) of 3 -axis acceleration.

[0145] These features collectively function as the fingerprint of one’s signature. Since individual personalized signatures were also different from one another (and not the same word written differently), there can be a larger separation between signatures from different people.

[0146] Fig. 6D shows the feature visualization of signatures from 10 users and the similarity of the signatures computed by a Siamese neural network. Specifically, subpanel (a) visualizes the separation between personalized signatures of 10 different users converted to 2D space using t-distributed Stochastic Neighbor Embedding (t-SNE) [16’], a method to visualize high-dimension data in a low-dimensional space. Signatures from different users were separable, while different instances of the user’ s signatures were closely clustered, an essential property for effective signature matching.

[0147] The extracted features were then fed into a matching model to determine if a query signature sequence (during a login attempt) matched the signatures registered duringsignup. To perform this comparison of signature sequences, the study adopted a Siamese neural network (SNN) [4’], an architecture using the same parameters on two input vectors and producing a comparable output vector. Subpanel (b) demonstrates the forward process of the SNN, wherein the query signature sqand a registered signature srwere fed into the same neural network, producing f(sq) and f(sr) respectively, in the output space. When sqwas from the same user, outputs of the SNN, f(sq) and f (sr), should be close in the feature space. Otherwise, the outputs should be far from each other. Euclidean distance, defined per Equation 2, was used to measure the proximity of two output vectors. d = dE(f(Sq), f(sr))(Eq. 2)

[0148] The study used a simple two-layer perceptron (128x16) network that avoided overfitting. The network was trained by back-propagating the contrastive loss [9’] defined per Equation 3.(Eq. 3)

[0149] In Equation 3, y 6 {0, 1 } represents the true label, and m is the margin for contrastive loss. In the smart ring’s design; the study used m = 0.5.

[0150] Signatures drawn by the same individual had small variations. Having access to only a single registered signature can be too restrictive for usability, making it difficult for the legitimate user to authenticate their own accounts, or when the matching criteria were kept loose, unauthorized access may be made easier. To enhance the smart ring’s robustness, the user could repeat the same signatures multiple times (n) in the registration phase (sr), which forms a database of legitimate signatures as shown in Equation 4.(Eq. 4)

[0151] To pass signature verification, the query signature sqwas compared with each registered signature in the database 5. When sqwas “close” (i.e., dE(f(sq), f(sr)) was small) to a majority of the registered signatures, and smart ring assumed sqcomes from a legitimate user. Mathematically, the smart ring checked a query signature for its legitimacy using Equation 5.(Eq. 5)

[0152] In Equation 5, do is the Euclidean distance threshold of SNN, and p is the “majority” percentage over which a query signature is treated as being legitimate.

[0153] Evaluation of angle and distance measurement. Using TWR and PDoA, the exemplary system measured the angle and distance of the token. The study defined a valid region around the login device in which the server can approve the login request. The capabilities and limitations of the UWB hardware guide the size and shape of this region.

[0154] Fig. 7 shows the evaluation of the angle and distance measurement of a token employed by the exemplary system. Specifically, subpanel (a) shows the stability of the token’s distance measurement (mean subtracted values) when the token was placed about Im and around 2m from the login device. As shown in subpanel (a), the central 95thpercentile precision was ±5 cm in both cases, showing an approximate margin of error in the distance measurements. The study used an upper bound of Im in our evaluations, with an expectation that the token can be within 2 feet (60 cm) of the login device, based on ergonomic recommendations for laptop usage [7], The actual authentication distance desired by the user and the website may be a tunable parameter.

[0155] Angle measurement precision was more complex due to the non-linear mapping between the measured phase difference and the physical angle (cos 9 = shownin Equation 1). To study the real-world effects of this non-linear mapping, the study placed the token at 37 different locations along a circle Im in radius spanning [0°, 180°] angles. Subpanel (b) shows a marked testbed with the test locations 10° apart and small markings every 5°. As shown in subpanel (c), the results of the angle measurement obtained by averaging 500 readings at each location show varying precision as the physical angle changes. The angle of arrival (AoA) precision improved as 9 approached 90°, leading to the recommended setting: 9 within [30°, 150°].

[0156] The Im distance measurement and the [30°, 150°] angle define the valid region for authentication. To remove front-back angle ambiguity, the study used two orthogonal PDoA devices defining a small sector of valid authentication region as shown in subpanel (d).

[0157] The study further evaluated the angle and distance measurement of the exemplary system at different locations, as shown in Fig. 8A. The evaluation occurred at three locations with different levels of multipath: (i) An atrium, (ii) a small-size common area, and (iii) a cluttered lab.

[0158] In this evaluation, the study set the radius of the valid sector to be Im, within which login was approved. The study moved the token 10cm at a time from 0.6m to 1.4m. When the measured distance was less than Im, the authentication was successful; otherwise, authentication failed.

[0159] Fig. 8B shows the authentication success rate at different distances. The authentication success rate dropped to 0 in all locations when the distance was larger than 1.2m, meaning attacks from beyond 1.2m can be blocked. The success rate remained over 99% when the distance was smaller than 0.8m. Considering the user was very close to the login device (around 0.5m), the 2FA of the exemplary system was highly accurate in distance authentication due to the high precision of the UWB -based TWR scheme. The study also observed a ranging bias of about 10cm in a cluttered space (e.g., lab area) due to multipath, enlarging the 50% success rate region to 1.1m.

[0160] Angle authentication restricted the feasible region to a smaller circular sector area (instead of a circle with just distance measurements) and provided additional security to prevent attacks from a nearby adversary. The study placed two double- antenna PDoA devices orthogonal, to uniquely determine the AoA of the token in 2D. The authentication should succeed only when the token was in the valid angle range, set to [-75°, -15 ] in the study. Fig. 8C shows the authentication success rate at different angles in three locations. The success rate was approximately 0 when the angle was outside |-80 , -10 ] and was over 98% within [-70°, -20°], demonstrating the effectiveness of using the UWB PDoA algorithm to perform angle authentication.

[0161] Exemplary system vs. Bluetooth. Bluetooth was used for 2FA in

[0027] ,

[0050] , which verified the proximity of a token to the login device. The study compared the exemplary system with two types of Bluetooth-based 2FA solutions: proximity authentication via Bluetooth connection and proximity authentication via Received Signal Strength Indicator (RSSI). The study evaluated Bluetooth using insecure RFCOMM sockets, as used in

[0027] , which did not need a pairing process.

[0162] The login device established a Bluetooth connection with the token as proof of have-factor. This approach was vulnerable to co-located attacks. Because the communication range of Bluetooth can be larger than 10m, the attacker can hide nearby and load a phishing or phantom-login attack.

[0163] The login device initiated a Bluetooth connection with the token and used thresholding on Bluetooth received signal strength indicator (RSSI) to infer the proximity ofthe token. To compare exemplary system’s performance versus Bluetooth RSSI based solutions, the study set up two Bluetooth devices and collected Bluetooth RSSI data when they were placed at different distances. The study used a Google Pixel 6a as the login device and a Google Pixel 4a as the token. The collected RSSI ranged from -100 to 0, where higher RSSI indicated larger received power. Fig. 8D shows the RSSI variation at different angles of the Bluetooth technology.

[0164] As shown in Fig. 8D, Bluetooth RSSI exhibited large fluctuations even when kept static at the same distance, making it difficult to establish a single threshold based on RSSI. For example, when the proximity threshold was set to about 1.5m, an attacker can easily load a co-located attack from a place that was 3m away. Worse still, the attacker can use a Bluetooth repeater / extender to significantly increase the observed RSSI. In contrast, the exemplary system employed two-way ranging and angle of arrival to compute the exact relative position between the login device and the token, severely limiting co-located attacks.

[0165] Evaluation of signature authentication by a smart ring. The study recruited 18 volunteers and asked them to design their own motion signatures and repeat them multiple times. The study collected 1,559 samples in total, covering various signature styles and levels of practice. All the volunteers were right-handed, with the ring worn on their index finger.

[0166] When using movements of the finger as a signature, due to inherent variations in signatures drawn by a person, the study allowed a margin of error. However, this margin of error may also allow an attacker’s signature to be accepted by the exemplary system.Therefore, the study tightened bounds and evaluated signature authentication under the following metrics, based on true positives (TP), false negatives (FN), true negatives (TN), and false positives (FP), and understand the trade-offs between them. Table 2 shows the authentication metrics and their descriptions in evaluating the UWB-Auth platform.Table 2

[0167] The exemplary system of the study extracted features from raw IMU data and employed SNN for signature authentication. To improve authentication robustness, the study collected multiple instances of a user’s signature during registration. A query signature was assumed legitimate if it matched with 80% of the registered signatures. The evaluation was performed via / c-fold cross-validation (k was the number of volunteers): the study iteratively trained the model with k - 1 users’ data and evaluated the remaining users.

[0168] To understand the model’s accuracy in comparison with other models which may also perform pattern matching on motion data, the study compared the ring’s authentication accuracy using the SNN-based model, canonical time warping (CTW)

[0055] , support vector machines (SVM), and one-class SVM (OC-SVM)

[0048] .

[0169] Table 3 shows the state-of-the-art signature matching models compared with the SSN model.Table 3

[0170] Table 4 presents the results in terms of overall BAC, TPR, and TNR of the same Ufold cross-validation set.Table 4

[0171] As shown in Table 4, SNN achieves the best performance among the evaluated models, with 95.2% accuracy in approving a legitimate query and 99.9% accuracy in rejecting a fake query. This demonstrated that the SNN-based similarity comparison effectively encoded raw IMU data into a feature space, making signatures comparable with Euclidean distances.

[0172] As the study set a higher preference for rejecting fake queries, TNR was slightly higher than TPR. Based on the application use case and user preferences, the weight of TNR and TPR was adjustable by adding a punishing factor a to false negatives. Fig. 9A shows the trade-off between TPR and TNR when different values of a were used. As a increased from 0.7 to 1.1, TNR / TPR varied from 99.9% / 91.9% to 95.2% / 99.9%. TPR and TNR were balanced when a = 0.91 rather than 1 , which resulted from differences between the training and test datasets.

[0173] Fig. 9B shows the true negative rate (TNR) and true positive rate (TPR) of each individual. As shown in Fig. 9B, some users performed poorly compared to most others. For example, the TPR of User 4 dropped to 80% to maintain higher than 99% TNR. The study summarized two underlying factors accounting for the low TPR of these individuals: (i) The individual failed to draw consistent signatures, resulting in a large margin of error to account for the larger intra-class variance; and (ii) The individual used a signature which was trivial to mimic. This indicated the need for a metric quantifying the quality of a signature.

[0174] To evaluate the improvement in TPR when low-quality signatures were not accepted, the study plotted the receiver operating characteristic curve (ROC) in Fig. 9C when users 4 and 7 were included or excluded. As shown in Fig. 9C, after removing users 4 and 7’s data, the false positive rate (FPR), defined as the probability that a fake signature got identified as a legitimate one, decreased for the same TPR. The process of determining the quality of a signature was analogous to password strength meters on websites: when a signature was too weak, the system can require redrawing a better, stronger signature for improved security. The study just evaluated the effect of signature duration on its strength in microbenchmarks based on the collected dataset.

[0175] Although the smart ring was resilient against 99.8% random signatures (shown in Table 4), the study also evaluated how the smart ring stood up against knowledge-based attacks. A personalized signature entailed knowledge of what was drawn as well as how it was drawn. Therefore, the study evaluated both these aspects of the smart ring separately as well as jointly against some knowledge-based attacks as shown in Table 5.Table 5

[0176] To evaluate the performance of each kind of attack, the study asked one volunteer to design their signature and register it. Other volunteers, acting as adversaries, tried to trick the model into accepting the signatures drawn by them. In KT-SS attacks, the adversaries were allowed to watch the video, which captured the entire signing process and practice an unlimited number of times. Knowledge was additive in this evaluation; therefore,different sets of volunteers and signatures were involved in each of the KT, SS, and KT-SS attack evaluations.

[0177] Fig. 9D shows the TNR under each attack (each instance had its own TPR since a different volunteer set was involved). As shown in Fig. 9D, the smart ring achieved nearly 100% performance in rejecting attackers’ signatures, demonstrating the smart ring’s resilience to KT and SS attacks. Such high TNR resulted from the biometric nature of signatures: even when an adversary knew the signature content or saw the hand movements, it was difficult to mimic the signature’s subtleties, such as pause, speed, strength, etc. Tn contrast, password-based authentication may break under either of these attacks.

[0178] As shown in Fig. 9D, the smart ring did not bring absolute security as the TNR decreased to 87% in the KT-SS attacks. Fig. 9E gives an example of a failed and a successful KT-SS attack in which the signature word was “keepcoding.” As shown in Fig. 9E, while malicious query signature 1 (Sq^i) attempted to mimic the registered signature (Sr) (e.g., letter connection and pause), it was still distinguishable with IMU features. In comparison, malicious signature 2 (Sq. ) resembled the subtleties of the legitimate user, resulting in similar features that tricked the model. However, Sq.i was written by a volunteer who practiced mimicking the victim’s signature for tens of minutes with a pre-recorded slow-motion video.

[0179] In addition to authentication accuracy, the time taken to input the signature was also a crucial consideration in real-world 2FA solutions. Long and complicated authentication process degraded user experience. The study compared the smart ring’s signature input time with password typing (1) on a physical keyboard on a PC; and (2) on a virtual keyboard of mobile devices (e.g., iPhone 13).

[0180] The study generated random passwords of four different levels of complexity (i.e., four password types) for the test: (1) Pure number with a length > 8 (Num8); (2) Pure letters with a length > 8 (Letter8); (3) Combination of three of {number, lower-case letters, upper-case letters, symbols] with a length > 8; and (4) Combination of all of {number, lowercase letters, upper-case letters, symbols] with a length > 8. For the smart ring, volunteers wrote the signature of the same complexity. For all input methods, volunteers first practiced several times before being ready for timed repetitions.

[0181] Fig. 9F shows the input time for the smart ring, typing a password on a keyboard, and typing a password on the virtual keyboard for the four password types, e.g., Num8, Letter8, 3Class8 (i.e., 3cls8), and 4Classl2 (i.e., 4clsl2). Smart ring took 2.89s, 3.69s, 4s, 6.57s for the four password types. For simple passwords, the input time of the smart ringwas comparable to traditional password typing on PC and mobile devices. However, smart rings outperformed others in complicated passwords, especially when compared to typing on mobile devices. Specifically, compared to typing on PC and mobile devices, the smart ring was 1.08x and 2.63x faster (4.33s on PC and 10.52s on mobile devices) in 3Class8 password, and 1.22x and 2.53x faster (8.02s on PC and 16.62s on mobile devices) in 4Classl2 password. Given how password-strength requirements are strictly enforced, smart rings can significantly improve usability.

[0182] System usability. To understand the experience of the volunteers, the study asked the volunteers to fill out a short questionnaire at the end. Specifically, the study asked the following questions: (QI) I can repeat drawing my pattern naturally and quite precisely; (Q2) I can quickly draw my pattern for authentication; (Q3) Overall, I think wearing the ring can interfere with my daily life activities (particularly when the ring form-factor was converted into something like the Oura ring [2’]); and (Q4) Overall, I think I can draw the same pattern over and over again with low cognitive load. The study used a 7-point Likert scale describing the agreement levels from strongly disagree (1) to strongly agree (7) in the questionnaire. Fig. 10 shows the Likert scale chart of the answers from the volunteers. As shown in Fig. 10, the volunteers overall agreed that the 2FA of smart ring had high repeatability (QI), short authentication time (Q2), low over-head of wearing the ring (Q3), and low cognitive load (Q4).

[0183] System authentication time. The average authentication time was a quantitative metric evaluating the usability of an authentication approach. The study measured authentication time by including the time spent in three phases (i.e., protocols): handshake phase, location authentication phase, and knowledge / biometric authentication phase. The study recruited volunteers to perform authentication with different prototypes and recorded the average time spent in each phase.

[0184] For UWB token prototype, the study set the required password strength of “3classl2”

[0041] , where the password should include 3 different classes of characters with at least 12 characters. For the ring prototype, the study asked the volunteers to wear the ring to write (draw) a string with at least 8 characters. Table 6 shows the login delay of each prototype, as seen in the end-to-end implementation.Table 6

[0185] As shown in Table 6, time spent in the handshake and location authentication was at a sub-second level, which was almost unperceivable to the user. The major portion of time consumption was the user interaction in the knowledge / biometric authentication phase. Compared to password typing, providing a fingerprint by touching the watch or drawing a pattern with the ring was more time efficient, but experienced the overhead of wearing the watch or ring. Overall, the login delay with all the prototypes ranged from 4-5 seconds, comparable to performing one-factor password-only authentication on a laptop / PC. Also, when compared with typing a password on a smartphone, which frequently took more than 10 seconds

[0041] , the watch / ring prototype in the study was significantly faster.

[0186] System power consumption. Authentication is a user-initiated process. Therefore, it is possible to incorporate a miniature physical button to turn the token on and off, which would allow several days of battery life. However, for simplicity, the study tested the energy consumption of the prototype tokens in an always-on mode: when idle, when actively running location authentication, and when running knowledge / biometric authentication. Table 7 shows the results of the power consumption of the prototype tokens.Table 7

[0187] Since UWB-based message transmission was short compared to the whole authentication process, the UWB radio and the fingerprint sensor can be heavily duty-cycled. As shown in Table 7, the power consumption with 95% duty cycle was 95mWZ , 108mI Z, and 163mW for the UWB token, watch, and the ring, respectively. Even with the token keptpowered on, this power consumption indicated a day-long charge with just a 3.7V / 400mAh battery.

[0188] Security analysis. The exemplary system achieved secure login through (i) location authentication, (ii) knowledge / biometric authentication, and (iii) switching the sequence of the two, in contrast with traditional 2FA. Table 8 shows the resilience of the exemplary and state-of-the-art 2FA methods against common attacks (e.g., phishing, credential gamering, co-located attack).Table 8

[0189] Discussion

[0190] Machine Learning. The system can be implemented using one or more artificial intelligence and machine learning operations. For example, as described above, in some implementations, the authentication system authenticates a captured signature, fingerprint, and / or faceprint using one or more machine learning models. The term “artificial intelligence” can include any technique that enables one or more computing devices or computing systems (i.e., a machine) to mimic human intelligence. Artificial intelligence (Al) includes but is not limited to knowledge bases, machine learning, representation learning, and deep learning. The term “machine learning” is defined herein to be a subset of Al that enables a machine to acquire knowledge by extracting patterns from raw data. Machine learning techniques include, but are not limited to, logistic regression, support vector machines (SVMs), Siamese Neural Networks (SNN), decision trees, Naive Bayes classifiers, and artificial neural networks. The term “representation learning” is defined herein to be a subsetof machine learning that enables a machine to automatically discover representations needed for feature detection, prediction, or classification from raw data. Representation learning techniques include, but are not limited to, autoencoders and embeddings. The term “deep learning” is defined herein to be a subset of machine learning that enables a machine to automatically discover representations needed for feature detection, prediction, classification, etc., using layers of processing. Deep learning techniques include but are not limited to artificial neural networks or multilayer perceptron (MLP).

[0191] Machine learning models include supervised, semi-supervised, and unsupervised learning models. In a supervised learning model, the model learns a function that maps an input (also known as feature or features) to an output (also known as target) during training with a labeled data set (or dataset). In an unsupervised learning model, the algorithm discovers patterns among data. In a semi-supervised model, the model learns a function that maps an input (also known as a feature or features) to an output (also known as a target) during training with both labeled and unlabeled data.

[0192] Neural Networks. An artificial neural network (ANN) is a computing system including a plurality of interconnected neurons (e.g., also referred to as “nodes”). This disclosure contemplates that the nodes can be implemented using a computing device (e.g., a processing unit and memory as described herein). The nodes can be arranged in a plurality of layers such as input layer, an output layer, and optionally one or more hidden layers with different activation functions. An ANN having hidden layers can be referred to as a deep neural network or multilayer perceptron (MLP). Each node is connected to one or more other nodes in the ANN. For example, each layer is made of a plurality of nodes, where each node is connected to all nodes in the previous layer. The nodes in a given layer are not interconnected with one another, i.e., the nodes in a given layer function independently of one another. As used herein, nodes in the input layer receive data from outside of the ANN, nodes in the hidden layer(s) modify the data between the input and output layers, and nodes in the output layer provide the results. Each node is configured to receive an input, implement an activation function (e.g., binary step, linear, sigmoid, tanh, or rectified linear unit (ReLU) function), and provide an output in accordance with the activation function. Additionally, each node is associated with a respective weight. ANNs are trained with a dataset to maximize or minimize an objective function. In some implementations, the objective function is a cost function, which is a measure of the ANN’s performance (e.g., an error such as LI or L2 loss) during training, and the training algorithm tunes the node weights and / or bias to minimize the cost function. This disclosure contemplates that any algorithm that finds themaximum or minimum of the objective function can be used for training the ANN. Training algorithms for ANNs include but are not limited to backpropagation. It should be understood that an artificial neural network is provided only as an example machine learning model. This disclosure contemplates that the machine learning model can be any supervised learning model, semi-supervised learning model, or unsupervised learning model. Optionally, the machine learning model is a deep learning model. Machine learning models are known in the art and are therefore not described in further detail herein.

[0193] A Siamese Neural Network is type of network that can be used to compare or identify similarities between dual inputs (e.g., an input password and a stored password). An SNN comprises sub-networks with identical structures and weights to facilitate comparison of different inputs. An example SNN can be configured to determine a distance measurement between feature representations for each respective input such as a Euclidean distance, Manhattan distance, or Cosine similarity measurement. By way of example, an SNN can be used to determine a distance measurement between one or more respective features (e.g., feature vectors) of an input signature and a stored signature.

[0194] A convolutional neural network (CNN) is a type of deep neural network that has been applied, for example, to image analysis applications. Unlike traditional neural networks, each layer in a CNN has a plurality of nodes arranged in three dimensions (width, height, and depth). CNNs can include several types of layers, e.g., convolutional, pooling, and fully-connected (also referred to herein as “dense”) layers. A convolutional layer includes a set of filters and performs the bulk of the computations. A pooling layer is optionally inserted between convolutional layers to reduce the computational power and / or control overfitting (e.g., by downsampling). A fully connected layer includes neurons, where each neuron is connected to all of the neurons in the previous layer. The layers are stacked similarly to traditional neural networks. GCNNs are CNNs that have been adapted to work on structured datasets such as graphs.

[0195] Example Computing Device

[0196] The computing devices described herein (e.g., token 101, computing device 102, authentication system 103 described in connection with FIGS. 1A-1C) can be a computing system including, but not limited to, personal computers, servers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, and / or distributed computing environments including a plurality of any of the above systems or devices. Distributed computing environments enable remote computing devices, which areconnected to a communication network or other data transmission medium, to perform various tasks. In the distributed computing environment, the program modules, applications, and other data may be stored on local and / or remote computer storage media.

[0197] In its most basic configuration, a computing device typically includes at least one processing unit and system memory. Depending on the exact configuration and type of computing device, system memory may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. The processing unit may be a processor that performs arithmetic and logic operations necessary for the operation of the computing device. The computing device may also include a bus or other communication mechanism for communicating information among various components of the computing device.

[0198] Computing device may have additional features / functionality. For example, computing device may include additional storage such as removable storage and nonremovable storage, including, but not limited to, magnetic or optical disks or tapes. Computing device may also contain network connection(s) that allow the device to communicate with other devices. Computing device may also have input device(s) such as a keyboard, mouse, touch screen, etc. Output device(s), such as a display, speakers, printer, etc., may also be included. The additional devices may be connected to the bus in order to facilitate the communication of data among the components of the computing device. All these devices are well-known in the art and need not be discussed at length here.

[0199] The processing unit may be configured to execute program code encoded in tangible, computer-readable media. Tangible, computer-readable media refers to any media that is capable of providing data that causes the computing device (i.e., a machine) to operate in a particular fashion. Various computer-readable media may be utilized to provide instructions to the processing unit for execution. Example of tangible, computer-readable media may include, but is not limited to, volatile media, non-volatile media, removable media, and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. System memory, removable storage, and non-removable storage are all examples of tangible, computer storage media. Examples of tangible, computer-readable recording media include, but are not limited to, an integrated circuit (e.g., field-programmable gate array or application- specific IC), a hard disk, an optical disk, a magneto-optical disk, a floppy disk, a magnetic tape, a holographic storage medium, a solid-state device, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices.

[0200] In an example implementation, the processing unit may execute program code stored in the system memory. For example, the bus may carry data to the system memory, from which the processing unit receives and executes instructions. The data received by the system memory may optionally be stored on the removable storage or the non-removable storage before or after execution by the processing unit.

[0201] It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination thereof. Thus, the methods and apparatuses of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium where, when the program code is loaded into and executed by a machine, such as a computing device, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an application programming interface (API), reusable controls, or the like. Such programs may be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and it may be combined with hardware implementations.

[0202] Conclusion

[0203] It must also be noted that, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” or “ 5 approximately” one particular value and / or to “about” or “approximately” another particular value. When such a range is expressed, other exemplary embodiments include one particular value and / or the other particular value.

[0204] By “comprising” or “containing” or “including,” is meant that at least the name compound, element, particle, or method step is present in the composition or article ormethod but does not exclude the presence of other compounds, materials, particles, method steps, even if the other such compounds, material, particles, method steps have the same function as what is named.

[0205] In describing example embodiments, terminology will be resorted to for the sake of clarity. It is intended that each term contemplates its broadest meaning as understood by those skilled in the art and includes all technical equivalents that operate in a similar manner to accomplish a similar purpose. It is also to be understood that the mention of one or more steps of a method does not preclude the presence of additional method steps or intervening method steps between those steps expressly identified. Steps of a method may be performed in a different order than those described herein without departing from the scope of the present disclosure. Similarly, it is also to be understood that the mention of one or more components in a device or system does not preclude the presence of additional components or intervening components between those components expressly identified.

[0206] The following patents, applications, and publications, as listed below and throughout this document, are hereby incorporated by reference in their entirety herein. Reference List #1[1] Adafruit fingerprint sensor.[2] Airtag. https: / / www.apple.com / airtag / .[3] Apple watch, https: / / www.apple.com / watch / .[4] Current mfa fatigue attack campaign targeting microsoft office 365 users. https: / / www.gosecure.net / blog / 2022 / 02 / 14 / current-mfa-fatigue-attack-campaign- targeting-microsoft-office-365-users / .[5] Dealing with phantom mfa challenges in microsoft 365. https: / / duo.com / blog / mfa- fatigue-what-is-it-how-to-respond.[6] Duo mobile app. https: / / duo.com / product / multi-factor-authentication-mfa / duo-mobile- app.[7] Ergonomic monitor positioning. https: / / workerscomp.nm.gov / sites / default / files / documents / publications / Ergonomics / In fo_Ergonomics_Computer_Monitor_ Positioning.pdf.[8] Fido2. https: / / fidoalliance.org / fido2 / .[9] Google 2-step verification, https : / / safety.google / authentication / .

[0010] How does phishing work? https: / / www.yubico.com / resources / phishing / .

[0011] Mfa fatigue: What it is and how to respond, https: / / duo.com / blog / mfa-fatigue-what-is- it-how-to-respond.

[0012] Nearby interaction with uwb. https: / / developer.apple.com / nearby-interaction / .

[0013] Onlykey. https: / / www.samsung.com / us / smartphones / galaxy-z-flip5 / .

[0014] Oura. https: / / www.ouraring.com.

[0015] Phishing attack on cisco, https: / / www.cybersecuritydive.com / news / cisco-phishing- attack / 629442 / .

[0016] Qorvo dwlOOO chip, https: / / store.qorvo.com / products / detail / dwl000itrl3-qorvo / 681945 / .

[0017] Rsa securid. https: / / www.rsa.com / products / .

[0018] Samsung uwb.

[0019] Signicat. https: / / www.signicat.com / .

[0020] Yubikey. https: / / www.yubico.com / .

[0021] leee standard for low-rate wireless networks. IEEE Std 802.15.4-2015 (Revision ofIEEE Std 802.15.4-2011), pages 1-709, 2016.

[0022] Usman Alhaji Abdurrahman, Mustafa Kaiiali, and Jawad Muhammad. A new mobilebased multi-factor authentication scheme using pre-shared number, gps location and time stamp. In 2013 International Conference on Electronics, Computer and Computation (ICECCO), pages 293-296. IEEE, 2013.

[0023] Lawrence Abrams. Phishing attack on uber, https: / / tinyurl.com / 34r7muz7.

[0024] Jane Bromley, Isabelle Guyon, Yann LeCun, Eduard Sackinger, and Roopak Shah.Signature verification using a" Siamese" time delay neural network. Advances in neural information processing systems, 6, 1993.

[0025] Yifeng Cao, Ashutosh Dhekne, and Mostafa Ammar. Itracku: Tracking a pen-like instrument via uwb-imu fusion. In Proceedings of the 19th Annual Intema-tional Conference on Mobile Systems, Applications, and Services, MobiSys ’21, page 453- 466, New York, NY, USA, 2021. Association for Computing Machinery.

[0026] Haige Chen and Ashutosh Dhekne. Pnploc: Uwb based plug & play indoor localization.In 2022 IEEE 12th International Conference on Indoor Positioning and Indoor Navigation (IPIN), pages 1-8. IEEE, 2022.

[0027] Alexei Czeskis, Michael Dietz, Tadayoshi Kohno, Dan Wallach, and Dirk Bal-fanz.Strengthening user authentication through opportunistic cryptographic identity assertions. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 404-414, 2012.

[0028] Sanchari Das, Gianpaolo Russo, Andrew C Dingman, Jayati Dev, Olivia Kenny, and LJean Camp. A qualitative study on usability and acceptability of yubico security key.In Proceedings of the 7th Workshop on Socio-Technical Aspects in Security and Trust, pages 28-39, 2018.

[0029] Rachna Dhamija, J Doug Tygar, and Marti Hearst. Why phishing works. In Proceedings of the SIGCHI conference on Human Factors in computing systems, pages 581-590, 2006.

[0030] Ashutosh Dhekne, Ayon Chakraborty, Karthikeyan Sundaresan, and SampathRangarajan. {TrackIO}: Tracking first responders {Inside-Out}. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), pages 751-764, 2019.

[0031] Ashutosh Dhekne, Mahanth Gowda, Yixuan Zhao, Haitham Hassanieh, and Remit RoyChoudhury. Liquid: A wireless liquid identifier. In Proceedings of the 16th annual international conference on mobile systems, applications, and services, pages 442- 454, 2018.

[0032] Bernhard GroBwindhager, Michael Stocker, Michael Rath, Carlo Alberto Boano, andKay Romer. Snaploc: An ultra-fast uwb-based indoor localization system for an unlimited number of tags. In Proceedings of the 18th International Conference on Information Processing in Sensor Networks, pages 61-72, 2019.

[0033] Tzipora Halevi, Di Ma, Nitesh Saxena, and Tuo Xiang. Secure proximity detection for nfc devices based on ambient sensor data. In Computer Security-ESORICS 2012: 17th European Symposium on Research in Computer Security, Pisa, Italy, September 10-12, 2012. Proceedings 17, pages 379-396. Springer, 2012.

[0034] Dianqi Han, Yimin Chen, Tao Li, Rui Zhang, Yaochao Zhang, and Terri Hedg-peth.Proximity-proof: Secure and usable mobile two-factor authentication. In Proceedings of the 24th Annual International Conference on Mobile Computing and Networking, pages 401-415, 2018.

[0035] Gerhard P Hancke and Markus G Kuhn. An rfid distance bounding protocol. In First international conference on security and privacy for emerging areas in communications networks (SECURECOMM’05), pages 67-73. IEEE, 2005.

[0036] Mohammed Jubur, Prakash Shrestha, Nitesh Saxena, and Jay Prakash. Bypass-ing push-based second factor and passwordless authentication with human- indistinguishable notifications. In Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security, pages 447-461, 2021.

[0037] Andre Kalamandeen, Adin Scanned, Eyal de Lara, Anmol Sheth, and AnthonyLaMarca. Ensemble: cooperative proximity-based authentication. In Proceedings ofthe 8th international conference on Mobile systems, applications, and services, pages 331-344, 2010.

[0038] Nikolaos Karapanos, Claudio Marforio, Claudio Soriente, and Srdjan Capkun. {Sound-Proof} : Usable {Two-Factor} authentication based on ambient sound. In 24th USENIX security symposium (USENIX security 15), pages 483-498, 2015.

[0039] Arash Habibi Lashkari, Samaneh Farmand, Dr Zakaria, Omar Bin, Dr Saleh, et al.Shoulder surfing attack in graphical password authentication. arXiv preprint arXiv: 0912.0951 , 2009.

[0040] Michael McLaughlin and Billy Verso. Asymmetric double-sided two-way ranging in an ultrawideband communication system, November 26 2019. US Patent 10,488,509.

[0041] William Melicher, Darya Kurilova, Sean M Segreti, Pranshu Kalvani, Richard Shay,Blase Ur, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Michelle L Mazurek. Usability and security of text passwords on mobile devices. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pages 527-539,2016.|42| Philip Polleit and Michael Spreitzenbarth. Defeating the secrets of otp apps. In 2018 11th International Conference on IT Security Incident Management & IT Forensics (IMF), IEEE, pages 76-88, 2018.

[0043] Leena Rao. Paypal debuts its biometrics and smartwatch integrations with Samsung. https: / / techcrunch.com / 2014 / 04 / ! 1 / paypal-debuts-its-biometrics-and-smartwatch- integrations-with-samsung / .

[0044] Kasper Bonne Rasmussen and Srdjan Capkun. Realization of {RF} distance bounding.In 19th USENIX Security Symposium (USENIX Security 10), 2010.

[0045] Ken Reese, Trevor Smith, Jonathan Dutson, Jonathan Armknecht, Jacob Cameron, andKent Seamons. A usability study of five two-factor authentication methods. In Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019), pages 357-370, 2019.

[0046] Yanzhi Ren, Chen Chen, Hongbo Liu, Jiadi Yu, Zhourong Zheng, Yingying Chen,Pengcheng Huang, and Hongwei Li. Secure mobile two-factor authentication leveraging active sound sensing. IEEE Transactions on Mobile Computing, 2022.

[0047] Anthony Rosati. Two factor authentication using near field communications, March 142017. US Patent 9,594,896.

[0048] Bernhard Scholkopf, John C Platt, John Shawe-Taylor, Alex J Smola, and Robert CWilliamson. Estimating the support of a high-dimensional distribution. Neural computation, 13(7):1443— 1471, 2001.

[0049] Richard Shay, lulia Ion, Robert W Reeder, and Sunny Consolvo. " my religious aunt asked why i was trying to sell her viagra" experiences with account hijacking. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 2657-2666, 2014.

[0050] Enis Ulqinaku, Daniele Lain, and Srdjan Capkun. 2fa-pp: 2nd factor phishing prevention. In Proceedings of the 12th Conference on Security and Privacy in Wireless and Mobile Networks, pages 60-70, 2019.

[0051] Laurens Van der Maaten and Geoffrey Hinton. Visualizing data using t-sne. Journal of machine learning research, 9(1 1), 2008.

[0052] Dimitra Zarafeta, Christina Katsini, George E Raptis, and Nikolaos M Avouris.Ultrasonic watch: Seamless two-factor authentication through ultrasound. In Extended Abstracts of the 2019 CHI Conference on Human Factors in Computing Systems, pages 1-6, 2019.

[0053] Jiansong Zhang, Zeyu Wang, Zhice Yang, and Qian Zhang. Proximity based iot device authentication. In IEEE INFOCOM 2017-IEEE conference on computer communications, pages 1-9. IEEE, 2017.

[0054] Tianyue Zheng, Zhe Chen, Jun Luo, Lin Ke, Chaoyang Zhao, and Yaowen Yang. Siwa:See into walls via deep uwb radar. In Proceedings of the 27th Annual International Conference on Mobile Computing and Networking, pages 323-336, 2021.

[0055] Feng Zhou and Fernando Torre. Canonical time warping for alignment of human behavior. Advances in neural information processing systems, 22, 2009.

[0056] Hao Zhou, Tailing Lu, Yilin Liu, Shijia Zhang, Runze Liu, and Mahanth Gowda. One ring to rule them all: An open source smartring platform for finger motion analytics and healthcare applications. In Proceedings of the 8th ACM / IEEE Conference on Internet of Things Design and Implementation, pages 27-38, 2023.Reference List #2[1'] Leap motion controller 2. https: / / www.ultraleap.com / .[2'] Oura. https: / / www.ouraring.com.[3’] Santosh Kumar Behera, Ajaya Kumar Dash, Debi Prosad Dogra, and Partha Pratim Roy. Air signature recognition using deep convolutional neural network-based sequentialmodel. In 2018 24th International Conference on Pattern Recognition (ICPR), pages 3525-3530. IEEE, 2018.[4'] Jane Bromley, Isabelle Guyon, Yann LeCun, Eduard Sackinger, and Roopak Shah.Signature verification using a" Siamese" time delay neural network. Advances in neural information processing systems, 6, 1993.[5’] Yifeng Cao, Ashutosh Dhekne, and Mostafa Ammar. Uwb-auth: A uwb-based two factor authentication platform. https: / / faculty.cc.gatech. edu / ~dhekne / UWB_Auth_WiSec2024.pdf.[6'] Yongliang Chen, Tao Ni, Weitao Xu, and Tao Gu. Swipepass: Acoustic -based second- factor user authentication for smartphones. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 6(3): 1-25, 2022.[7'] Andrea Ferlini, Dong Ma, Robert Harle, and Cecilia Mascolo. Eargate: gait-based user identification with in-ear microphones. In Proceedings of the 27th Annual International Conference on Mobile Computing and Networking, pages 337-349, 2021.[8’] Elyoenai Guerra-Segura, Aysse Ortega-Perez, and Carlos M Travieso. In-air signature verification system using leap motion. Expert Systems with Applications, 165: 113797, 2021.[9'] Raia Hadsell, Sumit Chopra, and Yann LeCun. Dimensionality reduc-tion by learning an invariant mapping. In 2006 IEEE Computer Society Conference on Computer Vision and Pattern Recognition (CVPR’06), vol-ume 2, pages 1735-1742. IEEE, 2006.[10'] Anil Jain, Lin Hong, and Sharath Pankanti. Biometric identification. Communications of the ACM, 43(2):90-98, 2000.[11'] Jacques Linden, Raymond Marquis, Silvia Bozza, and Franco Taroni. Dynamic signatures: A review of dynamic feature variation and forensic methodology. Forensic science international, 291:216-229, 2018.[12'] Muhammad Imran Malik, Sheraz Ahmed, Marcus Lewicki, and Andreas Dengel. Freak for real time forensic signature verification. In 2013 12th International Conference on Document Analysis and Recognition, pages 971-975. IEEE, 2013.[13'] Bernhard Schblkopf, John C Platt, John Shawe-Taylor, Alex J Smola, and Robert C Williamson. Estimating the support of a high-dimensional distribution. Neural computation, 13(7):1443— 1471, 2001.[14'] Dai Shi, Dan Tao, Jiangtao Wang, Muyan Yao, Zhibo Wang, Houjin Chen, and Sumi Helal. Fine-grained and context-aware behavioral biometrics for pattern lock onsmartphones. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 5( 1): 1— 30, 2021.[15'] Ruben Tolosana, Ruben Vera-Rodriguez, Julian Fierrez, and Javier Ortega-Garcia. Deepsign: Deep on-line signature verification. IEEE Transactions on Biometrics, Behavior, and Identity Science, 3(2):229-239, 2021.[16'] Laurens Van der Maaten and Geoffrey Hinton. Visualizing data using t-sne. Journal of machine learning research, 9(11), 2008.[17'] Cong Wu, Jing Chen, Kun He, Ziming Zhao, Ruiying Du, and Chen Zhang. Echohand: High accuracy and presentation attack resistant hand authentication on commodity mobile devices. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2931-2945, 2022.[18'] Weiye Xu, Wenfan Song, Jianwei Liu, Yajie Liu, Xin Cui, Yuanqing Zheng, Jinsong Han, Xinhua Wang, and Kui Ren. Mask does not matter: anti-spoofing face authentication using mmwave without on-site registration. In Proceedings of the 28th Annual International Conference on Mobile Computing And Networking, pages 310— 323, 2022.[19'] Xiangyu Xu, Jiadi Yu, Yingying Chen, Qin Hua, Yanmin Zhu, Yi-Chao Chen, and Minglu Li. Touchpass: towards behavior-irrelevant on-touch user authentication on smartphones leveraging vibrations. In Proceedings of the 26th Annual International Conference on Mobile Computing and Networking, pages 1-13, 2020.[20'] Feng Zhou and Fernando Torre. Canonical time warping for alignment of human behavior. Advances in neural information processing systems, 22, 2009.[21'] Hao Zhou, Tailing Lu, Yilin Liu, Shijia Zhang, Runze Liu, and Mahanth Gowda. One ring to rule them all: An open source smartring platform for finger motion analytics and healthcare applications. In Proceedings of the 8th ACM / IEEE Conference on Internet of Things Design and Implementation, pages 27-38, 2023.

Claims

What is claimed:

1. A method comprising : receiving, by an authentication server for a website, an authentication or login request from a login computing device, wherein the authentication or login request includes a username; transmitting, from the authentication server, to the computing device, a token authentication request for an action by a token operatively connected and in proximity to the login computing device; receiving, at the login computing device, token data stored or assessed at the token; transmitting, from the login computing device to a token authentication system, the token data; determining, by the token authentication system and based, at least in part, on the token data, that the token data is associated with the authentication or login request and the username; providing, by the token authentication system or the login computing device, a token authenticated certificate to the authentication server of the website; prompting, by the authentication server, the login computing device to provide a password or biometric associated scan or action; and responsive to determining that the password or biometric associated scan or action matches the username, granting by the authentication server the authentication or login request and providing access to the website.

2. The method of claim 1, further comprising: executing a localization operation between the login computing device and the token.

3. The method of claim 2, wherein the localization operation comprises a two-way ranging operation between the login computing device and the token.

4. The method of claim 3, wherein determining whether the token is in proximity to the login computing device comprises: prior to prompting the login computing device to provide the password or biometric associated scan or action, determining at least one angle of arrival measurement from at least one signal transmitted during the two-way ranging operation based, at least in part, on a phase-difference of arrival; andvalidating, by the authentication system, the at least one angle of arrival measurement.

5. The method of any one of claims 2-4, further comprising: receiving, by the authentication system, localization data generated from the executed localization operation; and determining, by the authentication system, whether the token is in proximity to the computing device by determining, based at least in part, on the localization data, at least one of a distance measurement between the token and the computing device, a relative angle between the token and the computing device, and a signal direction between the token and the computing device.

6. The method of claim 2, wherein the localization operation includes providing a security key data stored or generated by the token to the authentication system.

7. The method of any one of claims 4-6, wherein determining whether the token is in proximity to the computing device comprises: determining whether the token is positioned within a predefined region relative to the computing device.

8. The method of claim 7, wherein the predefined region is a user-configurable parameter.

9. The method of any one of claims 2-8, wherein each of the token and the computing device comprises at least one ultra- wideband (UWB) radio, and wherein the localization operation is a UWB -based operation.

10. The method of any one of claims 1-9, further comprising: responsive to receiving the authentication or login request, transmitting, by the authentication server, a session key and / or encrypted key for use by the login computing device and / or the token.

11. The method of claim 10, further comprising:responsive to determining, by the token, that the received session key and / or encrypted key is authentic, transmitting, by the token, token data directly to the authentication system.

12. The method of any one of claims 1-11, wherein the authentication system or login computing device maintains a per-user shared secret for each of a plurality of users that is used to encrypt messages transmitted to the token and / or the computing device.

13. The method of any one of claims 1-12, further comprising: registering, by the authentication system or via a registration system, the token with the login computing device.

14. The method of claim 13, wherein the password or biometric associated scan or action is stored and / or directly retrieved from the token.

15. The method of any one of claims 1-14, wherein the token is at least one of a wearable device, ring, a smartphone, a smartwatch, a key-chain, or a fob.

16. The method of any one of claims 1-15, wherein the token comprises at least one of an inertial measurement unit, an accelerometer, and a gyroscope.

17. The method of any one of claims 1-16, wherein determining whether the password or biometric associated scan or action matches comprises authenticating a captured signature, fingerprint, and / or faceprint using a machine learning model.

18. The method of claim 17, wherein the machine learning model comprises at least one of a support vector machine and a Siamese Neural Network (SNN).

19. The method of any one of claims 1-18, wherein determining whether the password or biometric associated scan or action matches comprises prompting a user to move the token in accordance with a predetermined motion signature.

20. The method of claim 19, wherein the predetermined motion signature is authenticated based, at least in part, on detected changes in acceleration and angular velocity.

21. The method of claim 19 or 20, wherein the predetermined motion signature or trajectory is authenticated based, at least in part, on a distance measure between one or more features of an input signature and a stored signature associated with a user of the computing device.

22. A non-transitory computer-readable medium having instructions stored thereon, wherein execution of the instructions by a processor causes the processor to: receive an authentication or login request from a computing device, wherein the authentication or login request includes a username; receive token data stored or assessed at a token associated with the computing device; determine, based, at least in part, on the token data, that the token data is associated with the authentication or login request and the username; prompt the computing device to provide a password or biometric associated scan or action; and responsive to determining that the password or biometric associated scan or action matches the username, grant the authentication or login request and provide access to a website.

23. The non-transitory computer-readable medium of claim 22, wherein execution of the instructions by the processor further causes the processor to: receive localization data generated from execution of a localization operation between the computing device and the token; and determine whether the computing device is in proximity to or within a predetermined range of the token based, at least in part, on the received localization data.

Images