Token-based UWB-IMU two-factor authentication system

Abstract

This is an exemplary authentication system and method that employs a short-range communication token to perform a first authentication of a login device or user when the authentication process is initiated and before a password or other biometric data for a second authentication operation is provided. The short-range non-network-connected token in this multi-factor authentication framework can, advantageously, be verified without user input while separating the username and password in the authentication process to mitigate attacks.

Description

[Technical Field]

[0001] Cross-reference of related applications This PCT application claims priority and benefits of U.S. Provisional Patent Application No. 63 / 584,477, “Wearable UWB-IMU-Based Two-Factor Authentication System,” filed on 21 September 2023, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] Two-factor authentication (2FA) is generally used to verify the user's knowledge of their password, followed by verification of legitimate token ownership or access to the network. However, 2FA is vulnerable to various attacks, such as phishing, in which victims are tricked into approving malicious login requests from adversaries.

[0003] There are advantages to improving existing systems and methods. [Overview of the Initiative]

[0004] An exemplary authentication system and method is disclosed that employs a short-range communication token to perform a first authentication of a login device or user when the authentication process is initiated and before a password or other biometric data for a second authentication operation is provided. The short-range non-network-connected token in this multi-factor authentication framework can advantageously be implemented without user input, separating the username and password in the authentication process to mitigate attacks such as remote phishing, colocation phishing, token theft attacks, malicious login devices, malicious token attacks, man-in-the-middle attacks, 2FA fatigue attacks, and phantom login attacks. Compared to conventional two-factor authentication systems that employ both username and password simultaneously, this separation of username and password by a token requiring short-range communication makes 2FA-related attacks less likely or even more difficult. The token may be implemented in any physical form, such as a keychain token, smartwatch, smartphone, or other wearable device.

[0005] The fundamental reason passwords can be easily obtained during phishing attacks is that the second factor—verifying ownership of a token or authenticator device—occurs after the user has provided their credentials. This verification sequence is necessary in traditional systems, otherwise adversaries could trigger a large number of second-factor notifications, inconveniencing users and depleting organizational resources. Nevertheless, this operation is vulnerable to other attacks, and therefore, exemplary authentication systems and methods can mitigate these attacks.

[0006] For example, by including short-range communications such as wireless, autonomous tokens can be further enhanced using proximity based on a location-based process (e.g., ultra-wideband (UWB) based location operation) negotiated between the login device and the token via short-range communications before a password is provided or adopted in the authentication process. For this purpose, username and password / biometric-based factor authentication are separated from each other, and a second-factor authentication based on the physical possession and proximity of the token is further employed. This series of operations makes it extremely difficult to implement the various attacks pointed out above and described herein.

[0007] In some embodiments, the techniques described herein include a method comprising: receiving an authentication or login request from a login computing device by an authentication server for a website, wherein the authentication or login request includes a username; sending a token authentication request from the authentication system to the computing device for an action by a token operably connected to and in close proximity to the login computing device; receiving token data stored in or evaluated by the token at the login computing device; sending the token data from the login computing device to a token authentication system; the token authentication system determining, at least in part, that the token data is associated with an authentication or login request and a username; providing a token authentication certificate to the website's authentication server by the token authentication system or the login computing device; prompting the login computing device by the authentication server to provide a password or biometric scan or action; and, in response to determining that the password or biometric scan or action matches a username, allowing the authentication or login request and providing access to the website.

[0008] In some embodiments, the techniques described herein further include methods for performing a location operation between a login computing device and a token.

[0009] In some embodiments, the techniques described herein relate to a method in which the location operation includes a bidirectional ranging operation between a login computing device and a token.

[0010] In some embodiments, the techniques described herein include a method for determining whether a token is in proximity to a login computing device, which includes determining at least one arrival angle measurement from at least one signal transmitted during a bidirectional ranging operation, at least in part on the arrival phase difference, before prompting the login computing device to provide a password or biometric authentication-related scan or action, and verifying the at least one arrival angle measurement by an authentication system.

[0011] In some embodiments, the techniques described herein further include: receiving location data generated from a location operation performed by an authentication system; and determining whether a token is in proximity to a computing device by determining, at least in part, 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, based at least in part on the location data.

[0012] In some embodiments, the techniques described herein relate to methods in which a location operation includes providing security key data stored or generated by a token to an authentication system.

[0013] In some embodiments, the techniques described herein relate to a method for determining whether a token is in proximity to a computing device, which includes determining whether a token is located within a predefined area relative to the computing device.

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

[0015] In some embodiments, the techniques described herein relate to methods in which each of the token and computing device includes at least one ultra-wideband (UWB) radio, and the location operation is a UWB-based operation.

[0016] In some embodiments, the techniques described herein further include, in response to receiving an authentication or login request, the authentication server transmitting a session key and / or encrypted key for use by the login computing device and / or token.

[0017] In some embodiments, the techniques described herein further include, in response to the token determining that the received session key and / or encrypted key is authentic, the method by which the token transmits token data directly to the authentication system.

[0018] In some embodiments, the techniques described herein relate to a method by which an authentication system or login computing device maintains a per-user shared secret used for each of a plurality of users to encrypt tokens and / or messages transmitted to the computing device.

[0019] In some embodiments, the techniques described herein further include registering a token with a login computing device by an authentication system or via a registration system.

[0020] In some aspects, the techniques described in this specification relate to a method in which a password or biometric authentication related scan or action is stored and / or obtained directly from a token.

[0021] In some aspects, the techniques described in this specification relate to a method, wherein the token is at least one of a wearable device, a ring, a smartphone, a smartwatch, a keychain, or a fob.

[0022] In some aspects, the techniques described in this specification 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 in this specification relate to a method, wherein determining whether a password or biometric authentication related scan or action matches comprises authenticating a captured signature, fingerprint, and / or facial print using a machine learning model.

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

[0025] In some aspects, the techniques described in this specification relate to a method, wherein determining whether a password or biometric authentication related scan or action matches comprises prompting a user to move a token according to a predefined motion signature.

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

[0027] In some embodiments, the techniques described herein relate to a method by which a given motion signature or trajectory is authenticated 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 a computing device.

[0028] In some embodiments, the techniques described herein relate to a non-temporary computer-readable medium on which instructions are stored, wherein the execution of instructions by a processor causes the processor to perform the following actions: receiving an authentication or login request from a computing device, wherein the authentication or login request includes a username; receiving token data stored in or evaluated in a token associated with the computing device; determining, at least in part, that the token data is associated with the authentication or login request and the username; prompting the computing device to provide a password or biometric scan or action; and, in response to determining that the password or biometric scan or action matches the username, authorizing the authentication or login request and providing access to a website.

[0029] In some embodiments, the techniques described herein relate to a non-temporary computer-readable medium in which the execution of an instruction by a processor causes the processor to further perform the following: receive location data generated from the execution of a location operation between a computing device and a token; and determine, at least in part, whether the computing device is in proximity to the token or within a predetermined range of the token, based on the received location data. [Brief explanation of the drawing]

[0030] [Figure 1A]An exemplary multi-factor authentication system is shown, employing a short-range communication token to perform authentication before a password or other biometric data is requested or provided for a second authentication operation, according to an exemplary embodiment. [Figure 1B] An exemplary multi-factor authentication system is shown, employing a short-range communication token to perform authentication before a password or other biometric data is requested or provided for a second authentication operation, according to an exemplary embodiment. [Figure 1C] An exemplary multi-factor authentication system is shown, employing a short-range communication token to perform authentication before a password or other biometric data is requested or provided for a second authentication operation, according to an exemplary embodiment. [Figure 1D] An exemplary multi-factor authentication system is shown, employing a short-range communication token to perform authentication before a password or other biometric data is requested or provided for a second authentication operation, according to an exemplary embodiment. [Figure 2A] This figure shows an exemplary authentication method between a login computing device, an authentication system, and a short-range communication token, according to an exemplary embodiment. [Figure 2B] This flowchart illustrates an exemplary authentication method between a login computing device, an authentication system, and a short-range communication token, according to an exemplary embodiment. [Figure 3A] This shows a conventional two-factor authentication method. [Figure 3B] An exemplary three-element embodiment of a system that further employs proximity or localization processes is shown. [Figure 4A] This document illustrates an exemplary authentication procedure for an exemplary system, including handshake protocols, location authentication protocols, and knowledge / biometric authentication protocols. [Figure 4B] This document illustrates an exemplary authentication procedure for an exemplary system, including handshake protocols, location authentication protocols, and knowledge / biometric authentication protocols. [Figure 5A]This document illustrates an exemplary registration protocol for exchanging messages between a server, a login device, and an ultra-wideband (UWB) token. [Figure 5B] This document illustrates an exemplary login (i.e., handshake) protocol configured to establish and verify communication between the server and the token. [Figure 5C] This shows an exemplary location authentication protocol configured to verify a user's location. [Figure 5D] This document illustrates exemplary bidirectional distance measurement methods and arrival phase difference measurement methods employed by the location authentication protocol. [Figure 5E] This document illustrates an exemplary knowledge / biometric protocol configured to verify the user's identity and intent. [Figure 6A] This document presents a prototype of an exemplary system embodiment that employs location-based UWB tokens. [Figure 6B] This section presents examples of tokens that could be used in an exemplary system employing location-based UWB tokens. [Figure 6C] This shows the visual and digital representations of the word "MyPassword" written by two volunteers. [Figure 6D] This demonstrates the visualization of signature features from 10 users and the similarity of signatures calculated using a Siam neural network. [Figure 7] This demonstrates an evaluation of angle and distance measurement using location-based UWB tokens. [Figure 8A] This shows distance and angle measurements of an exemplary system in different locations (e.g., atrium, common area, laboratory). [Figure 8B] This shows distance and angle measurements of an exemplary system in different locations (e.g., atrium, common area, laboratory). [Figure 8C] This shows distance and angle measurements of an exemplary system in different locations (e.g., atrium, common area, laboratory). [Figure 8D]This shows the variation in the received signal strength indicator (RSSI) of Bluetooth technology at different angles. [Figure 9A] This shows the trade-off between the true positive rate (TPR) and the true negative rate (TNR) at different values ​​of the penalty coefficient α. [Figure 9B] This shows the true negative rate (TNR) and true positive rate (TPR) for each individual signature collected by volunteers. [Figure 9C] The receiver operating characteristic curve (ROC) for low-quality signatures is shown. [Figure 9D] This shows the true negative rate (TNR) under known text (KT) attacks, shoulder surfing (SS) attacks, and known text shoulder surfing (KT-SS) attacks. [Figure 9E] Examples of failed and successful KT-SS attacks where the signature word was "keepcoding" are shown. [Figure 9F] This shows the time taken to enter passwords using a smart ring, a keyboard, and a virtual keyboard for four password types, such as Num8, Letter8, 3Class8 (i.e., 3cls8), and 4Class12 (i.e., 4cls12). [Figure 10] This shows a Likert scale chart of feedback from volunteers regarding the smart ring. [Modes for carrying out the invention]

[0031] Several references, which may include various patents, patent applications, and publications, are cited in the bibliography and discussed within the disclosures provided herein. Such citations and / or discussions of references are provided solely to clarify the description of the disclosed technology and do not constitute any "prior art" with respect to any aspect 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 herein are incorporated herein by reference and to the same extent as if each reference were incorporated separately by reference.

[0032] Embodiments of this disclosure provide a system and method capable of protecting authentication messages exchanged within a system / computing framework to mitigate various attacks, including phishing attacks and phantom login attacks. In one implementation, the proposed method includes validating a token (e.g., by analyzing token data provided by or evaluated by the token) before verifying a password or biometric authentication-related scan or action. The method described above is less susceptible to numerous types of vulnerabilities on computer and network systems, including malicious attacks. In particular, the integrity and performance of the framework can be enhanced by employing a location operation (e.g., a UWB-based location operation) to determine whether the token is in proximity to a computing device, either as part of or in addition to the above token validation step / operation.

[0033] Exemplary System #1 Figures 1A to 1D show exemplary multi-factor authentication systems 100 (indicated as 100a, 100b, 100c, and 100d) that employ a short-range communication token to perform an authentication operation before a password or other biometric data is requested or provided for a second authentication operation, according to exemplary embodiments. Figure 1A shows a short-range communication token operating with the authentication system on a network via a login computing device. Figure 1B shows a short-range communication token operating with an authentication module running on the login computing device. Figure 1C shows an authentication system or module running within a website infrastructure. In each of Figures 1A to 1C, authentication may optionally employ a location operation that can be determined using a machine learning model. In Figures 1A to 1C, the machine learning model runs on the authentication system or module. In Figure 1D, the machine learning model runs on the token.

[0034] In Figure 1A, the exemplary system 100a comprises a short-range communication token 101 (referred to as "token" 101), a login computing device 102 (referred to as "computing device" 102), and an authentication system 103. As shown in the figure, the token 101, computing device 102, and authentication system 103 communicate electronically with each other by exchanging information over a network 112 (for example, over the Internet).

[0035] The token 101 can be a wearable device, a ring, a smartphone, a mobile device, a smartwatch, a keychain, a fob, or a combination thereof, or may comprise them. As depicted in Figure 1A, the token 101 includes one or more UWB radios 104a (e.g., UWB chips or hardware), a communication interface 105a, a processor 106a, and memory 107a. Furthermore, as shown in the figure, the token 101 may also include an inertial measurement unit (IMU) 108 and / or one or more additional sensors, such as an accelerometer and / or a gyroscope, which can be employed to provide biometric authentication-related scans or actions as part of the proposed method.

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

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

[0038] To initiate an authentication operation for accessing a website (referred to as the "website" server 111) by the login computing device 102, for example to access the website, the login computing device 102 sends an authentication or login request, including a username, to the website server 111 via the network 112. The website server 111 receives the authentication or login request from the login computing device 102 via the network 112. The website 111 then sends a token authentication request to the login computing device 102 via the network 112 through its authentication server. The login computing device 102 receives the token authentication request via the network 112 and sends the token authentication request to the token 101 which is operationally connected to and in close proximity to the computing device 102.

[0039] A short-range communication token 101 associated with computing device 102 (connected by a short-range communication network) receives a token authentication request from login computing device 102. Token 101 then transmits first token data stored in or evaluated by token 101 to login computing device 102. In some embodiments, evaluation is based on additional multi-factor authentication (e.g., a location operation or other physical operation performed by or in conjunction with token 101). Login computing device 102 then receives the first token data from token 101 and transmits the first token data to authentication system 103 via network 112. This first-factor authentication ensures that the input of the login username is meaningful in the authentication process and prevents attacks such as remote phishing, colocation phishing, token theft attacks, malicious login devices, malicious token attacks, man-in-the-middle attacks, 2FA fatigue attacks, and phantom login attacks from being initiated. In conventional systems, the password is provided to the website server 111 (and its associated authentication server (not shown)) immediately or simultaneously with the username, but this is avoided by the claimed system.

[0040] The token authentication system 103 receives first token data from the computing device 102 via the network 112. Based on the first token data, the authentication system 103 determines that the first token data is associated with an authentication or login request and a username, and that the token is actually in close proximity to the computing device. The authentication system 103 then sends the token-authenticated certificate to the website's authentication server via the network 112 and the computing device 102. In some embodiments, the authentication system 103 sends the authenticated certificate to the website's authentication server.

[0041] Next, the authentication server of website 111 prompts the user for a password or biometric authentication scan via the login computing device 102. Authentication of the password or biometric authentication scan can be performed by the authentication server of website 111.

[0042] Example System #2 Figure 1B shows an exemplary system 100b comprising a token 101 and a login computing device 102 (indicated as 102') that employs an authentication module 103 (indicated as 103') running on the login computing device 102'.

[0043] Computing device 102' sends an authentication or login request, including a username, to website 111 via network 112. Website 111 receives the authentication or login request from computing device 102' via network 112. Website 111 then sends a token authentication request to computing device 102' via network 112. Computing device 102' receives the token authentication request via network 112 and sends the token authentication request to token 101 which is operationally connected to and in close proximity to computing device 102'.

[0044] Token 101 associated with computing device 102' receives a token authentication request from computing device 102'. Token 101 then sends the first token data stored in or evaluated by token 101 to authentication module 103' running on login computing device 102'.

[0045] The authentication module 103', running on the computing device 102', receives first token data from token 101. Based on the token data, the authentication module 103' determines that the first token data is associated with an authentication or login request and a username. The authentication module 103 then sends a request for a password or biometric authentication-related scan or action to token 101.

[0046] The token authentication module 103' receives first token data from token 101 via network 112. Based on the first token data, the authentication module 103' determines that the first token data is associated with an authentication or login request and a username. The authentication module 103' then sends a token-authenticated certificate to the authentication server of website 111 via network 112.

[0047] Next, the authentication server of website 111 prompts the user for a password or biometric scan via the login computing device 102'. Authentication of the password or biometric scan can be performed by the authentication server of website 111.

[0048] Exemplary System #3 Figure 1C illustrates an exemplary system 100c, which includes a token 101, a login computing device 102, and an authentication system 103 (indicated as 103") implemented in the website infrastructure 111 (indicated as 111'). As shown in the figure, the token 101, the login computing device 102, and the authentication system 103 embedded in the website 111' communicate electronically with each other by exchanging information over the network 112.

[0049] To initiate an authentication operation for accessing a website 111' by the login computing device 102, for example to access a website, the login computing device 102 sends an authentication or login request, including a username, to the website server 111' via the network 112. The website server 111' receives the authentication or login request from the login computing device 102 via the network 112. The website 111' then sends a token authentication request to the login computing device 102 via the network 112, through its authentication server which also functions as or operates with the authentication system 103''. The login computing device 102 receives the token authentication request via the network 112 and sends the token authentication request to a token 101 that is operationally connected to and in close proximity to the computing device 102.

[0050] The short-range communication token 101 receives a token authentication request from the login computing device 102. The token 101 then transmits the first token data stored in or evaluated by 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 the first token data to the authentication system 103" via the network 112.

[0051] The token authentication system 103” receives first token data from the computing device 102 via the network 112. Based on the first token data, the authentication system 103” determines that the first token data is associated with an authentication or login request and a username. The authentication system 103” then prompts the user to enter a password or perform a biometric scan via the login computing device 102. Authentication of the password or biometric scan can be performed by the authentication server of the website 111’.

[0052] Exemplary System #4 Figure 1D illustrates an exemplary system 100d comprising a token 101 (shown as 101'), a computing device 102, and an authentication system 103'. As shown in the figure, the token 101', the computing device 102, and the authentication system 103' communicate electronically with each other by exchanging information over a network 112.

[0053] To initiate an authentication operation for accessing a website 111 by the login computing device 102, for example to access a website, the login computing device 102 sends an authentication or login request, including a username, to the website server 111 via the network 112. The website server 111 receives the authentication or login request from the login computing device 102 via the network 112. The website 111 then sends a token authentication request to the login computing device 102 via the network 112 through its authentication server. The login computing device 102 receives the token authentication request via the network 112 and sends the token authentication request to a token 101' that is operationally connected to and in close proximity to the computing device 102.

[0054] The short-range communication token 101' receives a token authentication request from the login computing device 102. The token 101' then transmits first token data stored in or evaluated by the token 101' to the login computing device 102. The first token data may be generated by a machine learning model 110 running on the token. The login computing device 102 then receives the first token data from the token 101' and transmits the first token data to the authentication system 103 via the network 112.

[0055] The token authentication system 103 receives first token data from the computing device 102 via the network 112. Based on the first token data, the authentication system 103 determines that the first token data is associated with an authentication or login request and a username. The authentication system 103 then sends a token authentication certificate to the website's authentication server via the network 112 and the computing device 102. In some embodiments, the authentication system 103 sends an authenticated certificate to the website's authentication server.

[0056] Next, the authentication server of website 111 prompts the user for a password or biometric authentication scan via the login computing device 102. Authentication of the password or biometric authentication scan can be performed by the authentication server of website 111.

[0057] Exemplary Method Figure 2A is a signal diagram illustrating an exemplary method between a token 101, a computing device 102, and an authentication system 103, as described in relation to a particular implementation of the present disclosure, for example, in connection with Figure 1C. Similar but different operations may be performed for the systems described in relation to Figures 1A, 1B, and 1D.

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

[0059] In step / operation 204, the computing device 102 sends an authentication or login request to the authentication system 103. The authentication or login request may include a username.

[0060] In step / operation 206, in response to receiving an authentication or login request, the authentication system 103” sends a token authentication request to verify whether token 101 is associated with computing device 102. In various examples, the authentication system 103” can send the token authentication request directly to token 101 or via computing device 102. In some implementations, in addition to the token authentication request, the authentication system 103” provides a session key and / or encrypted key for use between token 101 and computing device 102 to secure communication between token 101 and computing device 102. In one embodiment, the authentication system 103” or computing device 102 maintains a per-user shared secret for each of multiple users, which is used to encrypt messages sent between token 101 and computing device 102.

[0061] In step / operation 208, in response to receiving a token authentication request regarding token 101 which is operationally connected to and in close proximity to computing device 102, computing device 102 initiates a handshake operation with token 101.

[0062] Optionally, in step / operation 210, in addition to or instead of the handshake operation, the token 101 and computing device 102 perform a location operation, such as bidirectional ranging or UWB-based operation, in response to a token authentication request received from the authentication system 103”.

[0063] In step / operation 212, token 101 generates token data stored in token 101 or evaluated by token 101.

[0064] In 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 in response to that determination, sends the token data directly to the authentication system 103”. Optionally, in some implementations, the token 101 or computing device 102 may additionally send location data generated from the execution of a location operation to the authentication system 103”.

[0065] In step / operation 216, the authentication system 103” analyzes the received token data and determines whether the token data is associated with an authentication or login request and, subsequently, with a username associated with the registered computing device 102. In some implementations, the authentication system 103” further analyzes the received location data, as described in more detail below in relation to Figure 2B.

[0066] In step / operation 218, the authentication system 103" prompts the computing device 102 or token 101 to perform a password or biometric authentication-related scan or action. In some implementations, the password or biometric authentication-related scan or action is stored and / or retrieved directly from token 101.

[0067] In step / operation 220, in response to the request, the computing device 102 transmits the requested password or biometric authentication-related scan or action to the authentication system 103.

[0068] In step / operation 222, token 101 (or authentication system 103") verifies the password or biometric scan or action and determines whether it matches one associated with the username. In some examples, token 101 (or authentication system 103") authenticates the captured signature, fingerprint, and / or facial print using, for example, one or more machine learning models (110). Illustrative machine learning models may include a Sham neural network or a support vector machine, as described in more detail below. In some implementations, step / operation 222 may be performed at least partially by computing device 102 or another computing device / system (e.g., a third-party system), which may also include one or more machine learning models (110). In some implementations, token 101 sends an instruction to authentication system 103" to confirm the verification of the password or biometric scan or action.

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

[0070] As described above, the systems described in relation to Figures 1A, 1B, and 1D may have similar but different operations. If the authentication system 103 operates independently and employs a machine learning model to verify biometric authentication-related scans or actions, the exemplary method shown in Figure 2A can be implemented in the exemplary system 100a.

[0071] The exemplary method shown in Figure 2A can be implemented in the exemplary system 100b in Figure 1B, in which the authentication module 103' runs on the login computing device 102'.

[0072] The exemplary method shown in Figure 2A can be implemented in the exemplary system 100c in Figure 1C, where the authentication system 103” is run within the website infrastructure.

[0073] Figure 2B is a flowchart of an exemplary method 200 for authenticating an authentication or login request by determining whether a token 101 is in proximity to a computing device 102, according to a particular embodiment described herein. In some implementations, method 200 is at least partially implemented using other system components described in relation to Figures 1A to 1D (e.g., tokens 101, 101', computing devices 102, 102'). Additionally or alternatively, method 200 can be at least partially implemented by a processing circuit (e.g., application-specific integrated circuits (ASICs), or central processing units (CPUs)). In some examples, the processing circuit may be electrically coupled to and / or electronically communicate with other circuits of the exemplary computing device. In some examples, embodiments may take the form of a computer program product on a non-temporary computer-readable storage medium that stores computer-readable program instructions (e.g., computer software).

[0074] In step / operation 230, the authentication system 103 (e.g., 103, 103', 103") receives location data associated with a location operation (e.g., performed between token 101 and computing device 102). As described above, location data can be generated by token 101 and / or computing device 102 and transmitted to the authentication system 103 via computing device 102 or directly from token 101. Advantageously, in some implementations, the authentication system 103 interacts with token 101 via computing device 102 rather than directly (e.g., via the internet) to further mitigate undesirable attacks.

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

[0076] In step / operation 250, the authentication system 103 verifies, for example, the determined distance measurement(s), relative angle, and / or signal direction based on the determined arrival phase difference corresponding to the positioning operation. In some implementations, the authentication system 103 determines at least one arrival angle measurement from at least one signal transmitted during the bidirectional ranging operation between the token 101 and the computing device 102 based on the arrival phase difference, and verifies the at least one arrival angle measurement.

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

[0078] In step / operation 270, if the authentication system 103 determines that the token 101 is in close proximity to the computing device 102, the authentication system 103 proceeds to prompt the computing device 102 or the token 101 to perform a password or biometric authentication-related scan or action.

[0079] Exemplary Embodiments Figure 3A illustrates a conventional two-factor authentication operation. As shown in Figure 3A, after the login credentials are verified 302 on the login device 304 (i.e., the computing device), the web server 306 (i.e., the authentication server) sends a challenge 308 to the user's registered smartphone 310 (i.e., the token) to request user approval and verify the legitimacy of the login attempt. However, this mechanism is vulnerable to phishing attacks such as the following: (1) An adversary creates a malicious website A' that looks similar to a legitimate website and tricks the victim into submitting their credentials (username and password). (2) The adversary then uses the credentials to log in to the legitimate website. And (3) the legitimate website triggers the second-factor approval process, and the victim may approve this fraudulent login request because they believe it is their own request that triggered this notification.

[0080] Besides phishing, phantom logins

[36] and 2FA fatigue[4], in which victims are tricked out of habit into accepting a login request from an adversary, are also viable attacks against existing 2FA solutions. Such attacks have successfully fooled IT professionals in the technology industry (Cisco

[15] , Uber

[23] ).

[0081] Figure 3B shows a two- or three-element embodiment of the exemplary system. The exemplary system includes message exchange between three main components: (1) a token, e.g., an ultra-wideband (UWB) token 312; (2) a login device 102 (shown here as 304); and (3) a web server 111 (shown here as 306) to which the user wishes to log in. However, as depicted in Figure 3B, communication between the web server and the token is facilitated via the login device, which acts as a conduit, allowing the UWB to easily provide precise location.

[0082] Exemplary Authentication Procedure When a user creates a new account on a website, the sign-up or registration process takes place in a secure location free from eavesdroppers or malicious actors. This requirement exists in almost all authentication systems. The user selects a username and password, which are stored in the server's database as usual. The user then registers a token with the website by prompting their login device to scan a nearby token. From this point onward, the token can be used as a possession factor for all logins.

[0083] Furthermore, to support different knowledge / biometric authentication methods, the exemplary system allows the token to securely store the user's passwords if the user plans to use the token as a password manager such as OnlyKey

[13] . The stored passwords may be retrieved from the token using only the user's predefined unlocking method, such as a valid fingerprint or motion signature. This unlocking method acts as a knowledge / biometric authentication element as an alternative to storing the password. If the user opts in, the user may also register a valid fingerprint or draw a motion pattern on the token.

[0084] Figures 4A and 4B illustrate exemplary authentication procedures for an exemplary system, including a handshake protocol, a location authentication protocol, and a knowledge / biometric authentication protocol.

[0085] In the exemplary system depicted in Figure 4A, normal account login is performed with significant differences from conventional methods. Specifically, after the user provides a username as shown in subpanel (a), the website (i.e., the server, authentication system) first verifies the proximity between the login device (i.e., the computing device) and the user's token (possession factor), as shown in subpanel (b). After successful verification of the possession factor, the website requests a password, which can be provided by either the user actively entering a password or by using a token with biometric or motion pattern-based authentication, as shown in subpanel (c).

[0086] As shown in Figure 4B, the authentication procedure employed by the exemplary system includes three protocols: a login (i.e., handshake) protocol, a location authentication protocol, and a knowledge / biometric authentication protocol. As shown in subpanel (a), the handshake protocol is configured to establish communication between the server and the token. As shown in subpanel (b), the location authentication protocol is configured to verify the user's location. As shown in subpanel (c), the knowledge / biometric authentication protocol is configured to verify the user's identity and intent.

[0087] Registration (Sign-up) Protocol The account signup process involves registering the token on the new website (creating a shared secret, i.e., an end-to-end (E2E) secret, and associating it with the token's ID). Figure 5A shows an exemplary registration protocol for exchanging messages between the server, login device, and UWB token.

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

[0089] Handshake protocol Figure 5B shows an exemplary handshake protocol configured to establish and verify communication between the server and the token. As shown in Figure 5B, the authentication procedure begins with the user entering username 502 on a website 111 (referred to here as 501) loaded over a secure HTTPS connection. When server 501 receives the login request, the handshake protocol is initiated. The main function of this protocol is to assure token 508 (referred to here as 508) that it is communicating with the registered website, and to assure website 501 that the website is communicating with the live token. The server sends bound data 514 to token 508 via login device 504 using its long-term shared secret E2E, and also generates a session key SK to secure communication between the login device and the token.

[0090] Since the domain name is included in the login device 504, the remote phishing attack will be intercepted by token 508 because the website name obtained by token 508 will not match the registered domain. The malicious token may not be able to decrypt and increment the E2E encrypted nonce provided by the server, and therefore will not be able to intercept UWB messages and generate its own response.

[0091] Location authentication protocol Once the handshake protocol is complete, the server requests the login device to initiate the location authentication protocol. Figure 5C shows an exemplary location authentication protocol configured to verify the user's location. Figure 5D shows exemplary bidirectional ranging methods (subpanel a) and reaching phase difference methods (subpanel b) employed by the location authentication protocol.

[0092] As shown in Figure 5C, location determination 516 is performed using a distance measurement method (e.g., bidirectional distance measurement) and an angle measurement method (e.g., arrival phase difference) 518. However, all UWB messages are encrypted using SK and this protocol is bound to the handshake protocol. The location authentication protocol employs an asymmetric bidirectional distance measurement (TWR) method as defined in the IEEE 802.15.4z standard

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

[0093] The angle and distance measurements generated from TWR and PDoA provide the token's location. As shown in Figure 5C, after the location authentication protocol, the token sends an E2E encrypted message 520 containing the distance measurement to the login device 504. The login device 504 packs the observed distance, observed angle, and token's E2E encrypted message 522 and sends it to the server 501. The server 501 checks whether the token 508 is legitimate by (1) decrypting the token ID and incremented nonce, and (2) whether the token 508 is physically located within a valid area near the login device based on the distance and angle reported by the token and the login device. These checks prevent colocation phishing and phantom login attacks.

[0094] Table 1 shows the procedures for providing angle and distance measurements using the TWR and PDoA methods. [Table 1]

[0095] Knowledge / Biometric Protocols While the proximity of a legitimate token to the login device is verified by handshake and location authentication protocols, two critical vulnerabilities remain: (a) the user's intent to log in is not verified, and (b) whether the token is with a legitimate user is not verified. As a result, if the token is lost or stolen, the user account becomes vulnerable. Therefore, a second element is essential to verify a knowledge or biometric element (to prove the user's legitimacy) in combination with some action taken voluntarily by the user (to demonstrate the user's intent).

[0096] The exemplary system employs a common communication protocol between the server, login device, and token, supporting authentication protocols for diverse knowledge and biometric elements. After location authentication is successful, the server expects a password to be presented. The user can either manually enter the password or unlock the password stored in the token, treating the token as a hardware password manager.

[0097] In the case of manual password entry performed on a laptop, the token is not involved in any further communication. If the user chooses fingerprint or motion signature matching, the login device instructs the token to initiate the knowledge / biometric protocol. Figure 5E shows an exemplary knowledge / biometric protocol configured to verify the user's identity and intent.

[0098] As shown in Figure 5E, the token 508 indicates to the user that it is ready to accept an "unlock" input. The user can use a legitimate fingerprint or move the token with a registered pattern. Once the fingerprint or motion signature 521 is verified, the token sends the SK encrypted password to the login device 504. The login device can then automatically fill in the password input field and send the password 524 to the server 501. In this protocol, the server 501 benefits from the simplicity of a common interface, namely, the use of the token is transparent to the web server whether the password is entered manually or automatically. By using the token 508 to store the password, it becomes possible to use longer and more randomized passwords, improving the overall system strength.

[0099] Experimental results and additional examples Research has been conducted to develop exemplary systems and methods that employ ultra-wideband (UWB) based location operations to determine whether a token is in proximity to a computing device before verifying a password or biometric authentication-related scan or action.

[0100] Figure 6A shows an exemplary system prototype. Each prototype shown in subpanels (a), (b), and (c) included a login / computing device (e.g., laptop), a token (e.g., keychain, watch, ring), and a PDoA device. The PDoA device was configured to provide local authentication within a valid sector, as shown in subpanel (d).

[0101] This study emulated a login system with an authentication process running on a server and a login page built on the client using the Flask framework. Since the laptop did not have a UWB embedded, a UWB module was connected to the login device via USB to emulate a UWB-embedded login device. This study used an HP ENVY, Intel Core i7-10510U laptop with 16GB of RAM as the login device. The study complements the login device with two standalone UWB setups connected to the laptop via USB (one emulating distance only, and another emulating distance and angle).

[0102] In the first setup shown in subpanel (a), this study used one Trek1000 transceiver as the UWB communication module for the login device. The Trek1000 is a single-antenna transceiver and can perform distance measurements using TWR in conjunction with nearby UWB devices, but cannot perform AoA measurements. This setup was similar to most existing state-of-the-art (SoA) mobile devices with UWB chips, such as the iPhone

[12] and Samsung Galaxy

[18] . In the second setup shown in subpanel (b), this study used two DWM1002 double-antenna devices as the UWB communication module, which can perform TWR and AoA measurements of nearby UWB devices simultaneously. To create a clear feasible area sector, the login device needs to be equipped with two vertically aligned antenna arrays.

[0103] Figure 6B shows tokens used in the exemplary system prototype. The token shown in subpanel (a) is a keychain coupled with a UWB chip and configured for location and password authentication. The token in subpanel (b) is a smartwatch employing a fingerprint sensor and a UWB chip and configured for location and fingerprint authentication. The token in subpanel (c) is a smart ring (i.e., a signing ring) coupled with a UWB chip and configured for location and motion signature authentication.

[0104] This study developed tokens in three different form factors: i) a token with an embedded UWB chip and no other sensors (a keychain form factor influenced by AirTags[2]), (ii) a smartwatch with a UWB chip and fingerprint sensor (a form factor influenced by PayPal-Samsung integration

[43] ), and (iii) a smart ring with a UWB chip and inertial sensor for motion signature authentication (a form factor influenced by

[14] and

[56] ). These form factors demonstrated the potential to develop exemplary systems on a variety of state-of-the-art devices while sharing the same authentication pipeline as defined in Sections 2 and 3. All three tokens used a DWM1000UWB module

[16] controlled by an ARM Cortex M0 ATSAMD21G18.

[0105] Keychain This research developed a UWB token (3.2cm x 4.6cm) equipped with a DWM1000 module and a Cortex M0 chip. In this prototype, the research envisioned the token being used for location authentication, with the user demonstrating a knowledge element by manually entering a password on a website. Since UWB chips are widely deployed in UWB location tags[2] and modern smartphones

[12] ,

[18] , no additional hardware is required to implement a UWB-specific token. While a simple keychain token provided only location authentication, it was still resistant to phishing attacks because the token's location was first verified and the token could detect domain name mismatches before the system proceeded to prompt the user for a password.

[0106] Smartwatch In this study, a UWB-Auth token was designed in the form factor of a smartwatch (two stacked 3.7cm x 3.1cm PCBs) that included a fingerprint sensor in addition to UWB[1]. The fingerprint sensor was also controlled via a Cortex M0 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 the vault containing the password. Upon successful fingerprint authentication, the token sent the encrypted password to the login device, which automatically filled in the password.

[0107] Smart ring (signing ring) A signature is typically a stylized way of writing a name, which an individual perfects through considerable practice. Signatures are rich in complex strokes and pauses, and sometimes curves, lines, and dots. Often, a well-designed signature is visible in a document but difficult for an attacker to replicate [10']. Essentially, in addition to knowing the word the signature represents, knowledge of how the signature is drawn is important.

[0108] This study developed a ring form factor hardware with two PCB layers: one for computing and inertial sensing, and another for communication. The overall dimensions were 3cm × 1.8cm × 1.5cm. The top layer consisted of a DWM1000 chip and a UWB antenna, and was solely responsible for communication between the login device and the ring. The bottom layer housed an 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 acquired data at a rate of 70Hz.

[0109] The smart ring can capture the user's finger movements using an inertial measurement unit (IMU) and match them with IMU readings previously registered by the user. This movement captures both what the user draws and how it is drawn, thus increasing the feature space for signature matching. Figure 6C shows how the same word "MyPassword," written by two volunteers, visually differs as observed from the IMU sensor data.

[0110] In contrast to traditional authentication approaches like passwords, signature matching is an imprecise process, meaning that there may be cases where a legitimate user's signature fails to match a registered signature. Similarly, from the perspective of IMU readings, an attacker may be able to draw something that looks similar to a user's registered signature.

[0111] Smart Ring signature similarity-based matching This study developed an IMU data-based signature matching algorithm that clusters signatures drawn by individuals together but effectively separates them when compared to signatures of other people. The matching algorithm used finger movements (captured by a ring) that mimicked signatures on a flat surface, rather than visible written signatures. In this study, features from registered sensor data (when the user first signed up) were extracted and stored, and these features were matched with sensor data obtained by the user drawing a new signature each time they logged in.

[0112] This study also uses and modifies hand-design features very similar to those qualitatively described in [11'] for fit to a ring worn on the finger, namely (1) the time span of the handwriting sequence, (2) the mean and standard deviation of acceleration for every 0.5 second time window over 8 seconds (representing the position derivative as described in [11']), (3) the zero crossing rate of acceleration for every 0.5 second time window over 8 seconds, and (4) the Fast Fourier Transform (FFT) of the three-axis acceleration.

[0113] Collectively, these features function as a fingerprint of an individual's signature. Since individual personalized signatures were also different from one another (and the same words weren't written differently), greater differentiation can occur between signatures from different people.

[0114] Figure 6D shows the feature visualization of signatures from 10 users and the similarity of signatures computed by a Sham neural network. Specifically, subpanel (a) visualizes the separation between personalized signatures from 10 different users, transformed into a 2D space using t-distributed stochastic neighbor embedding (t-SNE)[16'], a method for visualizing high-dimensional data in a low-dimensional space. While signatures from different users were separable, different instances of user signatures were closely clustered, which is an essential property for effective signature matching.

[0115] The extracted features were then fed into a matching model to determine whether the query signature sequence (during the login attempt) matched the registered signature during signup. To perform this comparison of signature sequences, this study employs a Sham neural network (SNN) [4'], an architecture that uses the same parameters for two input vectors to produce comparable output vectors. Subpanel (b) demonstrates the forward process of the SNN, where the query signature s q and registered signatures r When these are input to the same neural network, f(s) are respectively input to the output space. q ) and f(s r ) generates s q If they are from the same user, the SNN output f(s q ) and f(s r The two output vectors should be close in the feature space. If not, the outputs should be far apart. The Euclidean distance, defined by equation 2, was used to measure the proximity of the two output vectors.

number

[0116] This study used a simple two-layer perceptron (128×16) network that avoided overfitting. The network was trained by backpropagating the contrast loss [9'] defined by equation 3.

number

[0117] In equation 3, y ∈ {0, 1} represents the true label, and m is the margin of the contrast loss. In the design of the smart ring, we used m = 0.5 in this study.

[0118] Signatures drawn by the same individual have minor variations. Having access to only a single registered signature may be too strict for usability, making it difficult for legitimate users to authenticate their own accounts, or if the matching criteria are kept loose, unauthorized access can be facilitated. To enhance the robustness of the smart ring, the user can repeat the same signature multiple times (n) during the registration phase s r ) to form a database of legitimate signatures as shown in Equation 4. [Equation]

[0119] To pass signature verification, the query signature s q was compared with each registered signature in the database S. If s q is "close" to the majority of the registered signatures (i.e., d E (f(s q ), f(s r )) is small), the smart ring assumes that s q is from a legitimate user. Mathematically, the smart ring checks the legitimacy of the query signature using Equation 5. [Equation]

[0120] In Equation 5, d0 is the Euclidean distance threshold of SNN, and ρ is the proportion of the "majority" for which a query signature is treated as legitimate.

[0121] Evaluation of angle and distance measurements The exemplary system measured the angle and distance of the token using TWR and PDoA. In this study, a valid area around the login device where the server can approve a login request was defined. The capabilities and limitations of the UWB hardware determine the size and shape of this area.

[0122] Figure 7 shows an evaluation of the token angle and distance measurement employed by an exemplary system. Specifically, subpanel (a) shows the stability of the token distance measurement (average subtraction) when the token is placed approximately 1 m and 2 m away from the login device. As shown in subpanel (a), the accuracy at the 95th percentile in the center is ±5 cm in both cases, indicating an approximate error range for distance measurement. In this study, based on ergonomic recommendations for laptop use, a maximum of 1 m was used in the evaluation, assuming that the token could be within 2 feet (60 cm) of the login device [7]. The actual authentication distance desired by the user and website may be an adjustable parameter.

[0123] The accuracy of angle measurement depends on the measured phase difference and the physical angle (shown in Equation 1).

number

[0124] Distance measurements of 1m and angles [30°, 150°] define the valid area for authentication. To eliminate ambiguity in the front-back angle, this study used two orthogonal PDoA devices that define a small sector of the valid authentication area, as shown in subpanel (d).

[0125] As shown in Figure 8A, this study further evaluated angle and distance measurements of an exemplary system at different locations. The evaluation was carried out at three locations with different levels of multipath, namely (i) an atrium, (ii) a small common area, and (iii) a cluttered laboratory.

[0126] In this evaluation, the study set the effective sector radius to 1m, and logins were approved within that range. In this study, the token was moved in 10cm increments from 0.6m to 1.4m. Authentication was successful if the measured distance was less than 1m, and failed otherwise.

[0127] Figure 8B shows the authentication success rates at different distances. When the distance was greater than 1.2m, the authentication success rate dropped to 0 at all locations, meaning that attacks from locations beyond 1.2m could be blocked. When the distance was less than 0.8m, the success rate remained above 99%. Considering that the user was very close to the login device (approximately 0.5m), the 2FA of the exemplary system was remarkably accurate in distance authentication due to the high precision of the UWB-based TWR scheme. This study also observed a ranging bias of approximately 10cm in cluttered spaces due to multipath (e.g., laboratory areas), expanding the 50% success rate range to 1.1m.

[0128] Angle authentication restricted the feasible area to a smaller circular sector area (rather than a simple distance-based circle) and provided additional security to prevent attacks from nearby adversaries. In this study, two double-antenna PDoA devices were placed orthogonally to uniquely determine the AoA of a token in 2D. Authentication should only succeed if the token is within a valid angular range, which was set to [-75°, -15°] in this study. Figure 8C shows the authentication success rates at different angles in three locations. The success rate was nearly 0 when the angle was outside [-80°, -10°] and over 98% within [-70°, -20°]. This demonstrates the effectiveness of using the UWB PDoA algorithm to implement angle authentication.

[0129] Exemplary system vs. Bluetooth Bluetooth has been used in 2FA in

[27] and

[50] to verify the proximity of a token to a login device. This study compares an exemplary system with two types of Bluetooth-based 2FA solutions: proximity authentication via Bluetooth connection and proximity authentication via received signal strength indicator (RSSI). This study evaluated Bluetooth using an insecure RFCOMM socket that does not require a pairing process, as used in

[27] .

[0130] The login device established a Bluetooth connection with the token as proof of possession. This approach was vulnerable to colocation attacks. Because Bluetooth communication range can exceed 10m, an attacker could hide nearby and launch a phishing or phantom login attack.

[0131] The login device initiated a Bluetooth connection with the token and estimated the token's proximity using thresholding of the Bluetooth Received Signal Strength Indicator (RSSI). To compare the performance of an exemplary system with a Bluetooth RSSI-based solution, this study set up two Bluetooth devices and collected Bluetooth RSSI data when they were positioned at different distances. In this study, a Google Pixel 6a was used as the login device and a Google Pixel 4a as the token. The collected RSSI ranged from -100 to 0, with higher RSSIs indicating greater received power. Figure 8D shows the variation in RSSI at different angles of the Bluetooth technology.

[0132] As shown in Figure 8D, Bluetooth RSSI exhibited significant variability even when stationary at the same distance, making it difficult to establish a single threshold based on RSSI. For example, if the proximity threshold was set to approximately 1.5m, an attacker could easily carry out a colocation attack from a distance of 3m. Even worse, an attacker could use a Bluetooth repeater / extender to significantly increase the observed RSSI. In contrast, the exemplary system employed bidirectional ranging and angle of reach to calculate the precise relative position between the login device and the token, severely limiting colocation attacks.

[0133] Evaluation of signature authentication using smart rings In this study, 18 volunteers were recruited and asked to design their own motion signatures and repeat them multiple times. A total of 1,559 samples were collected, covering a variety of signature styles and practice levels. All volunteers were right-handed and wore the ring on their index finger.

[0134] When using finger movements as signatures, this study acknowledged an acceptable range due to the inherent variability in signatures drawn by humans. However, this range could also allow an attacker's signature to be accepted by the exemplary system. Therefore, this study tightened the boundaries and evaluated signature authentication under the following metrics based on true positives (TP), false negatives (FN), true negatives (TN), and false positives (FP), and understood the trade-offs between them. Table 2 shows the authentication metrics and their explanations when evaluating the UWB-Auth platform. [Table 2]

[0135] The exemplary system in this study extracted features from raw IMU data and employed a SNN for signature authentication. To improve the robustness of authentication, this study collected multiple instances of the user's signature during registration. A query signature was assumed to be valid if it matched 80% of the registered signatures. Evaluation was performed via k-fold cross-validation (where k is the number of volunteers). This study iteratively trained the model with data from k-1 users and evaluated the remaining users.

[0136] To understand the accuracy of the model compared to other models that can also perform pattern matching on motion data, this study compared the authentication accuracy of the ring using SNN-based models, canonical time stretching (CTW)

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

[48] .

[0137] Table 3 shows state-of-the-art signature matching models compared to SSN models. [Table 3]

[0138] Table 4 presents the results in terms of overall BAC, TPR, and TNR for the same k-fold cross-validation set. [Table 4]

[0139] As shown in Table 4, the SNN achieved the best performance among the evaluated models, with 95.2% accuracy in approving legitimate queries and 99.9% accuracy in rejecting false queries. This demonstrates that SNN-based similarity comparison effectively encodes raw IMU data into feature space, making signatures comparable using Euclidean distance.

[0140] This study prioritized rejecting false queries, resulting in a slightly higher TNR than TPR. The weights of TNR and TPR were adjustable by adding a penalty coefficient α for false negatives, based on the application's use case and user preferences. Figure 9A shows the trade-off between TPR and TNR when different values ​​of α were used. As α increased from 0.7 to 1.1, TNR / TPR fluctuated from 99.9% / 91.9% to 95.2% / 99.9%. TPR and TNR balanced at α=0.91 rather than 1, due to differences between the training and test datasets.

[0141] Figure 9B shows the true negative rate (TNR) and true positive rate (TPR) for each individual. As shown in Figure 9B, some users performed worse than most other users. For example, user 4's TPR dropped to 80% in order to maintain a TNR of over 99%. This study summarized two underlying factors that contributed to the low TPR of these individuals: (i) the individual failed to draw a consistent signature, resulting in a larger margin of error to account for greater within-class variance, and (ii) the individual used a signature that was easy to imitate. This highlighted the need for metrics to quantify signature quality.

[0142] To evaluate the improvement in TPR when low-quality signatures were not accepted, this study plotted receiver operating characteristic curves (ROCs) in Figure 9C with and without users 4 and 7. As shown in Figure 9C, after removing data from users 4 and 7, the false positive rate (FPR), defined as the probability that a fake signature is identified as legitimate, decreased for the same TPR. The process for determining signature quality was similar to a website password strength meter: if a signature is too weak, the system can request a redraw of a better, stronger signature to improve security. This study only evaluated the impact of signature duration on its strength in microbenchmarks based on the collected dataset.

[0143] While smart rings were resistant to 99.8% of random signatures (as shown in Table 4), this study also evaluated how smart rings resist knowledge-based attacks. Personalized signatures involve knowledge not only of what is drawn, but also of how it is drawn. Therefore, this study evaluated both of these aspects of smart rings individually and collectively against several knowledge-based attacks, as shown in Table 5. [Table 5]

[0144] To evaluate the performance of each type of attack, this study asked one volunteer to design and register their own signature. Other volunteers, acting as adversaries, attempted to trick the model into accepting the signature they had created. In the KT-SS attack, adversaries were allowed to watch videos capturing the entire signing process and practice an unlimited number of times. Knowledge was additive in this evaluation, and therefore, each of the KT, SS, and KT-SS attack evaluations involved a different set of volunteers and signatures.

[0145] Figure 9D shows the TNR under each attack (each instance had its own TNR because different sets of volunteers were involved). As shown in Figure 9D, the smart ring achieved nearly 100% performance in rejecting the attacker's signature, demonstrating its robustness against KT and SS attacks. Such high TNR was due to the biometric nature of the signature. Even if an adversary knew the contents of the signature or observed the hand movements, it would be difficult to mimic the subtle aspects of the signature, such as pause, speed, and strength. In contrast, password-based authentication can be broken under any of these attacks.

[0146] As shown in Figure 9D, the smart ring did not provide absolute security, as the TNR dropped to 87% in the KT-SS attack. Figure 9E shows examples of failed and successful KT-SS attacks where the signature word was "keepcoding". As shown in Figure 9E, the malicious query signature 1(S q,1 ) is a registered signature (S r Attempts were made to mimic (e.g., character connections and pauses), but these were still distinguishable from IMU features. In comparison, malicious signature 2(S q,2 ) resembles the subtle parts of a legitimate user, resulting in similar features that deceived the model. However, s q,2 It was written by volunteers who practiced mimicking the victims' signatures for tens of minutes using pre-recorded slow-motion videos.

[0147] In addition to authentication accuracy, the time required to enter a signature was also a crucial consideration in real-world 2FA solutions. Long and complex authentication processes detract from the user experience. This study compared the signature entry time for a smart ring with password entry on (1) a physical PC keyboard and (2) a virtual keyboard on a mobile device (e.g., iPhone 13).

[0148] In this study, random passwords of four different complexity levels (i.e., four password types) were generated for testing: (1) pure numeric passwords of length 8 or greater (Num8), (2) pure letter passwords of length 8 or greater (Letter8), (3) combinations of three of {numeric, lowercase, uppercase, and symbol} of length 8 or greater, and (4) all combinations of {numeric, lowercase, uppercase, and symbol} of length 8 or greater. For smart rings, volunteers wrote signatures of the same complexity. For all input methods, volunteers first practiced several times before being prepared for timed repetitions.

[0149] Figure 9F shows the input time using the smart ring, the time using a keyboard, and the time using a virtual keyboard for four password types, e.g., Num8, Letter8, 3Class8 (i.e., 3cls8), and 4Class12 (i.e., 4cls12). The smart ring took 2.89 seconds, 3.69 seconds, 4 seconds, and 6.57 seconds for the four password types, respectively. For simple passwords, the smart ring's input time was comparable to traditional password entry on PCs and mobile devices. However, the smart ring outperformed other methods for complex passwords, particularly when compared to input on mobile devices. Specifically, compared to input on PCs and mobile devices, the smart ring was 1.08 times and 2.63 times faster for 3Class8 passwords (4.33 seconds on PC, 10.52 seconds on mobile devices) and 1.22 times and 2.53 times faster for 4Class12 passwords (8.02 seconds on PC, 16.62 seconds on mobile devices). Given the strict enforcement of password strength requirements, smart rings can significantly improve usability.

[0150] System usability To understand the volunteer experience, this study asked volunteers to complete a short questionnaire at the end. Specifically, this study asked the following questions: (Q1) I can repeat drawing my pattern naturally and fairly accurately. (Q2) I can quickly draw my pattern for authentication. (Q3) Overall, do you think wearing the ring could interfere with my daily activities (especially if the ring's form factor were converted to something like the Oura ring[2'])? (Q4) Overall, do you think I can repeatedly draw the same pattern with a low cognitive load? This study used a 7-point Likert scale to describe agreement levels from “strongly disagree” (1) to “strongly agree” (7) in the questionnaire. Figure 10 shows the Likert scale chart of the volunteer responses. As shown in Figure 10, volunteers overall agreed that smart ring 2FA has high reproducibility (Q1), short authentication time (Q2), low overhead of wearing the ring (Q3), and low cognitive load (Q4).

[0151] System Authentication Time Average authentication time was a quantitative metric used to evaluate the usability of the authentication approach. This study measured authentication time by including the time spent in three phases (i.e., the protocol): the handshake phase, the location authentication phase, and the knowledge / biometric authentication phase. Volunteers were recruited to perform authentication using different prototypes, and the average time spent in each phase was recorded.

[0152] For the UWB token prototype, this study set the required password strength as "3class12"

[41] , meaning the password should contain at least 12 characters from three different character classes. For the ring prototype, this study asked volunteers to wear the ring and write (draw) a string of at least 8 characters. Table 6 shows the login delays for each prototype observed in the end-to-end implementation. [Table 6]

[0153] As shown in Table 6, the time spent on handshakes and location authentication was in the sub-second range and was barely perceptible to the user. The majority of the time was spent on user interaction during the knowledge / biometric authentication phase. Providing a fingerprint by touching the watch or drawing a pattern on the ring was more time-efficient than password entry, but users experienced the overhead of wearing the watch or ring. Overall, login latency across all prototypes ranged from 4 to 5 seconds, comparable to performing one-factor password-only authentication on a laptop / PC. Furthermore, the watch / ring prototypes in this study were significantly faster compared to password entry on a smartphone, which frequently took more than 10 seconds

[41] .

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

[0155] Because UWB-based message transmission was short compared to the entire authentication process, the UWB radio and fingerprint sensor could be significantly duty cycle-limited. As shown in Table 7, power consumption at a 95% duty cycle was 95mW, 108mW, and 163mW for the UWB token, watch, and ring, respectively. Even with the token powered on, this power consumption indicated that it could be used all day on a 3.7V / 400mAh battery alone.

[0156] Security Analysis The exemplary system achieved secure login through (i) location authentication, (ii) knowledge / biometric authentication, and (iii) swapping the two sequences, in contrast to traditional 2FA. Table 8 shows the resilience of exemplary and state-of-the-art 2FA methods to common attacks (e.g., phishing, credential harvesting, and colocation attacks). [Table 8]

[0157] Consideration 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 uses one or more machine learning models to authenticate captured signatures, fingerprints, and / or facial prints. The term “artificial intelligence” can include any technique that enables one or more computing devices or computing systems (i.e., machines) to mimic human intelligence. Artificial intelligence (AI) includes, but is not limited to, knowledge bases, machine learning, representation learning, and deep learning. The term “machine learning” is defined herein as a subset of AI that enables machines to acquire knowledge by extracting patterns from raw data. Machine learning techniques include, but are not limited to, logistic regression, support vector machines (SVMs), Siam neural networks (SNNs), decision trees, naive Bayes classifiers, and artificial neural networks. The term “representation learning” is defined herein as a subset of machine learning that enables machines to automatically discover representations necessary 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 as a subset of machine learning that uses layers of processing to enable machines to automatically discover the representations necessary for features detection, prediction, classification, and other tasks. Deep learning techniques include, but are not limited to, artificial neural networks or multilayer perceptrons (MLPs).

[0158] Machine learning models include supervised, semi-supervised, and unsupervised learning models. In supervised learning models, the model learns a function that maps inputs (also known as features) to outputs (also known as targets) during training with labeled data sets. In unsupervised learning models, the algorithm discovers patterns between data. In semi-supervised models, the model learns a function that maps inputs (also known as features) to outputs (also known as targets) during training with both labeled and unlabeled data.

[0159] Neural Network An artificial neural network (ANN) is a computing system comprising multiple interconnected neurons (also referred to as “nodes”). This disclosure intends that nodes can be implemented using computing devices (e.g., the processing units and memory described herein). Nodes may be arranged in multiple layers, such as an input layer, an output layer, and one or more hidden layers having optionally different activation functions. An ANN with hidden layers may 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 may consist of multiple nodes, and each node is connected to all nodes in the previous layer. Nodes in a given layer are not interconnected with each other; that is, nodes in a given layer function independently of each other. As used herein, nodes in the input layer receive data from outside 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., a binary step function, a linear function, a sigmoid function, a hyperbolic tangent function, or a rectified linear unit (ReLU) function), and provide an output according to this activation function. Additionally, each node is associated with its respective weights. The ANN is trained to maximize or minimize an objective function using a dataset. In some implementations, this objective function is a cost function, which is a measure of the ANN's performance during training (e.g., an error such as an L1 or L2 loss), and its training algorithm minimizes this cost function by adjusting the node weights and / or biases. This disclosure is intended to show that any algorithm that finds the maximum or minimum value of the objective function can be used to train the ANN. Training algorithms for the ANN include, but are not limited to, backpropagation. It should be understood that the artificial neural network is provided only as an illustrative machine learning model.This disclosure assumes that the machine learning model may be any supervised, semi-supervised, or unsupervised learning model. The machine learning model is optionally a deep learning model. Machine learning models are known in the art and are therefore not described in further detail herein.

[0160] A SNN is a type of network that can be used to compare or identify similarities between dual inputs (e.g., an input password and a stored password). SNNs have subnetworks with identical structures and weights to facilitate the comparison of different inputs. An exemplary SNN can be configured to determine distance measures such as Euclidean distance, Manhattan distance, or cosine similarity measurement between feature representations for each respective input. For example, an SNN can be used to determine distance measures between one or more features (e.g., feature vectors) in an input signature and a stored signature.

[0161] A convolutional neural network (CNN) is a type of deep neural network applied, for example, to image analysis applications. Unlike conventional neural networks, each layer of a CNN has multiple nodes arranged in three dimensions (width, height, and depth). A CNN can include several types of layers, such as convolutional layers, pooling layers, and fully connected (also referred to herein as "tightly connected") layers. Convolutional layers contain a set of filters and perform most of the computation. Pooling layers are optionally inserted between convolutional layers to reduce the computational load and / or to control overfitting (e.g., by downsampling). Fully connected layers contain neurons, each neuron connected to all neurons in the previous layer. These layers are stacked, similar to conventional neural networks. A GCNN is a CNN adapted to operate on structured datasets such as graphs.

[0162] Exemplary computing device The computing devices described herein (for example, token 101, computing device 102, and authentication system 103 as described in relation to Figures 1A to 1C) may be 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 that include a plurality of any of the above systems or devices. A distributed computing environment enables remote computing devices connected to a communication network or other data transmission medium to perform various tasks. In a distributed computing environment, program modules, applications, and other data may be stored on local and / or remote computer storage media.

[0163] 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 the computing device, the system memory may be volatile (e.g., random access memory (RAM)), non-volatile (e.g., read-only memory (ROM), flash memory, etc.), or a combination of both. The processing unit may be a processor that performs the arithmetic and logical operations necessary for the operation of the computing device. The computing device may also include a bus or other communication mechanism for communicating information between the various components of the computing device.

[0164] Computing devices may have additional features / functions. For example, a computing device may include additional storage, such as removable and non-removable storage, including but not limited to magnetic disks or optical disks or magnetic tapes or optical tapes. A computing device may also include network connectivity(s) that enable it to communicate with other devices. A computing device may also have input devices(s) such as keyboards, mice, and touchscreens. It may also include output devices(s) such as displays, speakers, and printers. These additional devices may be connected to a bus to facilitate data communication between components of the computing device. All of these devices are well known in the art and do not need to be discussed further herein.

[0165] A processing unit may be configured to execute program code encoded in a tangible computer-readable medium. A tangible computer-readable medium is any medium capable of providing data that causes a computing device (i.e., a machine) to operate in a particular way. Various computer-readable media can be used to provide instructions for execution to a processing unit. Examples of tangible computer-readable media include, but are not limited to, volatile, non-volatile, removable, and inremovable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. System memory, removable storage, and inremovable storage are all examples of tangible computer storage media. Examples of tangible computer-readable recording media include, but are not limited to, integrated circuits (e.g., field-programmable gate arrays or application-specific ICs), hard disks, optical disks, magneto-optical disks, floppy disks, magnetic tapes, holographic recording media, solid-state devices, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technologies, CD-ROMs, digital multipurpose disks (DVDs) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices.

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

[0167] It should be understood that the various techniques described herein may be implemented in relation to hardware, software, or, where appropriate, a combination thereof. Therefore, the methods and apparatus of the currently disclosed subject matter, or certain aspects or parts thereof, may take the form of program code (i.e., instructions) embodied on a tangible medium such as a floppy disk, CD-ROM, hard drive, or any other machine-readable storage medium, and when such program code is loaded and executed by a machine such as a computing device, that machine becomes an apparatus for practicing the currently disclosed subject matter. When program code is executed on a programmable computer, 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 relation to the currently disclosed subject matter, for example, through the use of an application programming interface (API), reusable controls, etc. Such programs may be implemented in a high-level procedural or object-oriented programming language for communication with a computer system. However, these programs may be implemented in assembly language or machine code, where preferred. In either case, this language may be a compiled language or an interpreted language, and may be combined with a hardware implementation.

[0168] conclusion Furthermore, it should be noted that, as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include multiple references unless the context explicitly indicates otherwise. In this specification, ranges may be expressed as from a specific value such as “about” or “approximately 5” to another specific value such as “about” or “approximately.” Where such ranges are expressed, other exemplary embodiments include one specific value and / or the other specific value.

[0169] "Comprising," "containing," or "including" means that at least the specified compound, element, particle, or method step is present in the composition, article, or method, but does not exclude the presence of other such compounds, materials, particles, or method steps, even if those compounds, materials, particles, or method steps have the same function as the specified ones.

[0170] In describing exemplary embodiments, terminology will be used for clarity. Each term is intended to be understood in its broadest sense, as understood by those skilled in the art, and is intended to include all technical equivalents that operate in a similar manner to achieve similar purposes. It should also be understood that reference to one or more steps of a method does not preclude the presence of additional or intervening method steps between those explicitly identified steps. The steps of a method may be performed in an order different from that described herein without departing from the scope of this disclosure. Similarly, reference to one or more components in a device or system should also be understood that does not preclude the presence of additional or intervening components between those explicitly identified components.

[0171] The following patents, applications, and publications, listed below and referred to throughout this Spec, are incorporated herein by reference in their entirety. List of References #1 [1]Adafruit fingerprint sensor.https: / / www.adafruit.com / product / 4750. [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 / Info_Ergonomics_Computer_Monitor_ Positioning.pdf. [8]Fido2.https: / / fidoalliance.org / fido2 / . [9]Google 2-step verification.https: / / safety.google / authentication / .

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

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

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

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

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

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

[16] Qorvo dw1000 chip.https: / / store.qorvo.com / products / detail / dw1000itr13-qorvo / 681945 / .

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

[18] Samsung uwb.

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

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

[21] Ieee standard for low-rate wireless networks.IEEE Std 802.15.4-2015(Revision of IEEE Std 802.15.4-2011),pages 1-709,2016.

[22] Usman Alhaji Abdurrahman,Mustafa Kaiiali,and Jawad Muhammad.A new mobile-based 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.

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

[24] Jane Bromley,Isabelle Guyon,Yann LeCun,Eduard Saeckinger,and Roopak Shah.Signature verification using a“siamese”time delay neural network.Advances in neural information processing systems,6,1993.

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

[26] 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.

[27] 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.

[28] Sanchari Das,Gianpaolo Russo,Andrew C Dingman,Jayati Dev,Olivia Kenny,and L Jean 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.

[29] 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.

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

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

[32] Bernhard Grobwindhager,Michael Stocker,Michael Rath,Carlo Alberto Boano,and Kay Roemer.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.

[33] 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.

[34] 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.

[35] 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.

[36] 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.

[37] Andre Kalamandeen,Adin Scannell,Eyal de Lara,Anmol Sheth,and Anthony LaMarca.Ensemble:cooperative proximity-based authentication.In Proceedings of the 8th international conference on Mobile systems,applications,and services,pages 331-344,2010.

[38] 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.

[39] 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.

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

[41] 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.

[43] Leena Rao.Paypal debuts its biometrics and smartwatch integrations with samsung.https: / / techcrunch.com / 2014 / 04 / 11 / paypal-debuts-its-biometrics-and-smartwatch-integrations-with-samsung / .

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

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

[46] 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.

[47] Anthony Rosati.Two factor authentication using near field communications,March 14 2017.US Patent 9,594,896.

[48] Bernhard Schoelkopf,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.

[49] Richard Shay,Iulia 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.

[50] 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.

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

[52] 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.

[53] 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.

[54] 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.

[55] Feng Zhou and Fernando Torre. Canonical time warping for alignment of human behavior. Advances in Neural Information Processing Systems, 22, 2009.

[56] Hao Zhou, Taiting 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 sequential model.In 2018 24th International Conference on Pattern Recognition(ICPR),pages 3525-3530.IEEE,2018. [4’]Jane Bromley,Isabelle Guyon,Yann LeCun,Eduard Saeckinger,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 Schoelkopf,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 on smartphones.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,Taiting 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

1. The authentication server for the website receives authentication or login requests from login computing devices, and the authentication or login request includes a username. The authentication server sends a token authentication request to the computing device for an action using a token that is operablely connected to and in close proximity to the login computing device. The login computing device receives token data stored in the token or evaluated by the token, The login computing device transmits the token data to the token authentication system, The token authentication system determines, and at least partially based on the token data, that the token data is associated with the authentication or login request and the username. The token authentication system or the login computing device provides the authentication server of the website with a token-authenticated certificate, The authentication server prompts the login computing device to provide a password or biometric authentication-related scan or action, A method comprising: allowing the authentication server to permit the authentication or login request and provide access to the website in response to the determination that the password or biometric authentication-related scan or action matches the username.

2. The method according to claim 1, further comprising performing a location operation between the login computing device and the token.

3. The method according to claim 2, wherein the location determination operation includes a bidirectional distance measurement operation between the login computing device and the token.

4. Determining whether the token is in proximity to the login computing device is: Before prompting the login computing device to provide the password or biometric authentication-related scan or action, determine at least one arrival angle measurement from at least one signal transmitted during the bidirectional ranging operation, at least partially based on the arrival phase difference. The method according to claim 3, comprising verifying the at least one angle of reach measurement using the authentication system.

5. The authentication system receives location data generated from the location operation performed, The method according to any one of claims 2 to 4, further comprising determining by the authentication system whether the token is in proximity to the computing device by determining 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, based at least in part on the location data.

6. The method according to claim 2, wherein the location identification operation includes providing the authentication system with security key data stored or generated by the token.

7. Determining whether the token is in proximity to the computing device is: The method according to any one of claims 4 to 6, comprising determining whether the token is located within a predefined area for the computing device.

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

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

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

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

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

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

14. The method according to claim 13, wherein the password or biometric authentication-related scan or action is stored and / or retrieved directly from the token.

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

16. The method according to any one of claims 1 to 15, wherein the token includes at least one of an inertial measuring unit, an accelerometer, and a gyroscope.

17. The method according to any one of claims 1 to 16, wherein determining whether the password or biometric authentication-related scan or action matches includes authenticating a captured signature, fingerprint, and / or facial print using a machine learning model.

18. The method according to claim 17, wherein the machine learning model includes at least one of a support vector machine and a Siam neural network (SNN).

19. The method according to any one of claims 1 to 18, wherein determining whether the password or biometric authentication-related scan or action matches includes prompting the user to move the token according to a predetermined motion signature.

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

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

22. A non-temporary computer-readable medium on which instructions are stored, wherein the execution of the instructions by the processor is performed by the processor, Receiving an authentication or login request from a computing device, wherein the authentication or login request includes a username, Receiving token data stored in or evaluated by a token associated with the computing device, Based at least partially on the aforementioned token data, it is determined that the token data is associated with the authentication or login request and the username. Prompting the computing device to provide a password or biometric authentication-related scan or action, A non-temporary computer-readable medium that, in response to determining that the password or biometric authentication-related scan or action matches the username, permits the authentication or login request and provides access to the website.

23. The execution of the instruction by the aforementioned processor means that the processor Receiving location data generated from the execution of a location operation between the computing device and the token, The non-temporary computer-readable medium according to claim 22, further comprising determining, at least in part, whether the computing device is in proximity to the token or within a predetermined range of the token, based on the received location data.

Images