Systems and methods for contactless card communications and multi-device key pair cryptographic authentication - Patents.com

Abstract

Systems and methods for authentication can include an authentication device. The authentication device can include a processor and a memory. The processor generates first instructions, the first instructions including a request to obtain a first FIDO (Fast Identity Online) key, transmits the first instructions, receives the first FIDO key, signs one or more challenges with the first FIDO key, and transmits the one or more signed challenges for verification with a second FIDO key.

Description

[Technical field]

[0001] The present disclosure relates to systems and methods for contactless card communications, and more particularly, to systems and methods for key-pair cryptographic authentication of contactless cards using multiple devices.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 352,181, filed June 18, 2021, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0003] Card-based businesses often use cards to communicate with server machines and other devices. It is necessary to protect these communications from eavesdropping and unauthorized access. However, there are many sophisticated methods of intercepting data that can be employed by hackers and other fraudsters. Summary of the Invention [Problem to be solved by the invention]

[0004] For example, data transmission without encryption or other safeguards may be susceptible to man-in-the-middle, phishing, replay, and other attacks and other vulnerabilities, resulting in increased security risks and increased risk of accounts or cards being misused. These risks may be further increased by the use of contactless cards that communicate wirelessly with other devices, thereby exposing data to the possibility of being intercepted during transmission.

[0005] Measures taken to address security risks, such as encryption, may consume system resources and impede operational efficiency. In the case of a large number of operations, the consumption of system resources and the impediment to operational efficiency may increase, leading to operation failures and unsatisfactory performance. In addition, access to secure authentication devices may be restricted or unavailable, which may adversely affect access to secure encryption, data transmission, and secure registration and authentication, leading to compromised accounts that may be used for fraudulent transactions or account takeover.

[0006] These and other deficiencies exist, and therefore what is needed is a system and method for authentication that overcomes these deficiencies by effectively utilizing multi-device key-pair cryptographic authentication to securely and quickly identify and determine the authenticity of a sender by protecting communications from eavesdropping and unauthorized access in a secure and reliable manner. [Means for solving the problem]

[0007] An embodiment of the present disclosure provides an authentication device. The authentication device may include a processor and a memory. The processor may be configured to receive one or more challenges. The processor may be configured to generate a first instruction, the first instruction including a request to obtain a first FIDO (Fast Identity Online) key. The processor may be configured to transmit the first instruction. The processor may be configured to receive the first FIDO key. The processor is configured to sign the one or more challenges with the first FIDO key. The processor is configured to transmit the one or more signed challenges for verification with a second FIDO key.

[0008] An embodiment of the present disclosure provides a method of authentication. The method includes receiving, at a processor, one or more challenges. The method includes generating, by the processor, first instructions including a request to obtain a first FIDO (Fast Identity Online) key. The method includes transmitting, by the processor, the first instructions. The method includes receiving the first FIDO key. The method includes signing, by the processor, the one or more challenges with the first FIDO key. The method includes transmitting, by the processor, the one or more signed challenges for verification with a second FIDO key.

[0009] An embodiment of the present disclosure provides a computer-readable, non-transitory medium including computer-executable instructions that, when executed on a processor, perform a procedure including the steps of: receiving one or more challenges and generating first instructions including a request to obtain a first FIDO (Fast Identity Online) key, transmitting the first instructions, receiving the first FIDO key, signing the one or more challenges with the first FIDO key, and transmitting the one or more signed challenges for verification with a second FIDO key.

[0010] The various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in which: [Brief description of the drawings]

[0011] [Figure 1] 1 illustrates an authentication system according to an exemplary embodiment. [Figure 2A] FIG. 1 is an illustration of a first device according to an exemplary embodiment. [Figure 2B] FIG. 2 is an illustration of a contact pad of a first device according to an exemplary embodiment. [Diagram 3] 1 illustrates an authentication method according to an exemplary embodiment. [Figure 4]FIG. 2 is a sequence diagram of an authentication process according to an exemplary embodiment. [Diagram 5] 1 illustrates an authentication method according to an exemplary embodiment. [Figure 6] 1 illustrates an authentication method according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Detailed explanation The following description of the embodiments provides a non-limiting representative example that refers to numbers to specifically describe the features and teachings of different aspects of the present invention. It should be recognized from the description of the embodiments that the described embodiments can be implemented separately or in combination with other embodiments. Those skilled in the art who review the description of the embodiments should be able to learn and understand the different described aspects of the present invention. The description of the embodiments is not specifically exhaustive, but should facilitate the understanding of the present invention to the extent that other embodiments within the knowledge of those skilled in the art who read the description of the embodiments are understood to be consistent with the application of the present invention.

[0013] The systems and methods disclosed herein can be used to complement authentication frameworks, including but not limited to FIDO authentication, FIDO2 authentication, WebAuthn, CTAP (Client to Authenticator Protocol) FIDO, and other authentication implementations. The systems and methods employed herein can be implemented with distributed storage, cloud-based storage, and other forms of storage to support this functionality. The systems and methods disclosed herein enable a device to act as a roaming authenticator in Fast Identity Online 2 (FIDO2) authentication in a browser. As described further below, a user can use the implemented systems and methods to authenticate with a website in a password-less environment. To log in to a website, a private key may be stored on the device during the website's registration process. When the user wishes to re-login to the website, the device can enter a communication field, such as a mobile device, using one or more gestures, including but not limited to a tap, swipe, wave, etc. The private key may then be transmitted from the first device to an application that includes instructions for execution on the mobile device, including but not limited to an authentication device function. The authentication device is configured to sign a challenge issued by the website using the private key. The signed challenge is sent to the relying party server device and verified using the stored public key. This authentication thus serves as a primary authentication to log in a user. Furthermore, this authentication can also be used in combination with a second factor authentication, e.g. biometrics or credentials entered into a mobile device.

[0014] Advantages of the systems and methods disclosed herein include protecting communications from interception and unauthorized access, and improving authentication by safely and quickly identifying the sender and determining their authenticity. The systems and methods disclosed herein can be used as an authentication device for FIDO2 authentication on browsers, including laptop browsers, tablet browsers, desktop browsers, and not just when iOS or Android is running on the device, to implement conditional multi-factor authentication to avoid man-in-the-middle and phishing attacks, prevent replay attacks, improve authentication device accessibility and security, secure encryption and data transmission, and reduce other security vulnerabilities.

[0015] Additionally, a concern with the FIDO2 framework and other authentication frameworks is establishing the identity of a user attempting to perform an authentication process. The systems and methods described herein can reduce this vulnerability by registering credentials and verifying that a user attempting to authenticate with the framework is the user they claim to be and is authorized to perform the authentication process. Doing so can increase the security of the framework and its ability to exclude unauthorized users. Thus, security risks can be further reduced and compatibility and transaction efficiency between various devices can be further improved. In some examples, computational processing of the authentication device is reduced when instructing a first device to obtain or generate one or more FIDO keys instead of generating one or more FIDO keys within the authentication device.

[0016] These features can be implemented without degrading the user experience by burdening the user with unnecessary security tasks, and furthermore, these features can be performed in a manner that allows for time-efficient execution of transactions to conform to user expectations and transaction requirements.

[0017] Thus, the systems and methods disclosed herein reduce the risk of, for example, fraudulent use of a card or an account associated with the card, while improving secure access to authentication devices and encrypted data transmission. The systems and methods disclosed herein improve upon implementations that lack secure authentication. These benefits may be advantageously achieved while promoting system efficiency, avoiding degradation of the user experience, and promoting compatibility among multiple devices.

[0018] Figure 1 illustrates an authentication system 100. System 100 is comprised of a browser extension 101, a first device 105, an authentication device 110 or second device, a network 115, a relying party device or server device 120, and a database 125. Although Figure 1 illustrates a single instance of the components of system 100, system 100 may include any number of components.

[0019] The system 100 may include a browser extension 101. The browser extension 101 may be comprised of Chrome®, Internet Explorer®, Firefox®, or Safari®. It is understood that software applications other than browser extensions (including standalone software applications) may be utilized. Without being limited thereto, an authentication request, such as a website registration, may occur on any device, including but not limited to a laptop or desktop associated with the browser extension 101. The mobile-based browser extension 101, or the tablet-based browser extension 101, or the laptop-based browser extension 101, or the desktop-based browser extension 101 may be configured to send and receive one or more requests, as further described below.

[0020] The system 100 may include a first device 105. The first device 105 may be, without limitation, a contactless card, a contact card, a network-enabled computer, or other device described herein. As referred to herein, a network-enabled computer may include, but is not limited to, a computing device or a communication device. These devices may include, for example, a server device, a network appliance, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a contactless card, a thin client, a fat client, an Internet browser, a kiosk, a tablet, a terminal, or other devices. As further described below in FIG. 2A-2B, the first device 105 may include one or more processors 102 and a memory 104. The memory 104 may include one or more applets 106 and one or more counters 108. Each counter 108 may include a counter value. The memory 104 may include a counter value, transmission data, and at least one key.

[0021] The first device 105 may include a communication interface 107. The communication interface 107 may include communication capabilities with a physical interface and a contactless interface. For example, the communication interface 107 is configured to communicate with the physical interface, for example, by swiping through a card swipe interface and inserting into a card chip reader found in an automated teller machine (ATM) or other device configured to communicate through a physical interface. In other examples, the communication interface 107 may be configured to establish contactless communication with a card reading device using a near-field wireless communication method such as NFC, Bluetooth, Wi-Fi, RFID, etc. As shown in FIG. 1, the communication interface 107 may be configured to directly communicate with the authentication device 110 or the second device, the relying party device or server device 120, and / or the database 125 via the network 115.

[0022] The first device 105 may be in data communication with any number of components of the system 100. For example, the first device 105 may transmit data to the authentication device 110 or the second device, and / or the relying party device or the server device 120 over the network 115. The first device 105 may transmit data to the database 125 over the network 115. In some examples, the first device 105 may be configured to transmit data over the network 115 after entry into one or more communication fields of any device. Without limitation, each input may be associated with a tap, a swipe, a wave, and / or any combination thereof.

[0023] The system 100 may include an authenticator 110. The authenticator 110 may constitute a roaming authenticator for other client devices. In some examples, the authenticator 110 may include a mobile device that serves as a roaming authenticator for a laptop, desktop, or tablet. It should be understood that the client device is not limited to such devices and other client devices are within the scope of the present invention.

[0024] As an example, the authentication device 110 may constitute a second device. The authentication device 110 may include one or more processors 112 and memory 114. The memory 114 may include one or more applications, including but not limited to an application 116. The authentication device 110 may be in data communication with any number of components of the system 100. For example, the authentication device 110 may transmit data to the server device 120 via the network 115. The authentication device 110 may transmit data to the database 125 via the network 115. Without limitation, the authentication device 110 may be a network-enabled computer. As referred to herein, a network-enabled computer includes, but is not limited to, a computing device or a communication device. These devices include, for example, a server device, a network appliance, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a contactless card, a thin client, a fat client, an Internet browser, a kiosk, a tablet, a terminal, and other devices. The authentication device 110 may be a mobile device, including, for example, an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® Mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices.

[0025] The authentication device 110 may include processing circuitry and may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, necessary to perform the functions described herein. The authentication device 110 may further include a display and input devices. The display may be any device that displays visual information, such as a computer monitor, flat panel display, mobile device screen, liquid crystal display, light emitting diode display, plasma panel, cathode ray tube display, etc. The input devices may include any device available and supported by the user's device for inputting information into the user's device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder, video camera, etc., which may be used to input information and interact with the software and other devices described herein.

[0026] System 100 may include a network 115. In some examples, network 115 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect to any one of the components of system 100. For example, first device 105 may be configured to connect to a relying party device or server device 120 via network 115. In some examples, the network 115 may be an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing based system, a code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and the like.

[0027] Further, network 115 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. Further, network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 115 may further operate as an independent network or in cooperation with one another and may include one network or any number of the exemplary types of networks described above. Network 115 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 115 may translate from other protocols to one or more protocols of a network device or from other protocols to one or more protocols of a network device. Although network 115 is illustrated as a single network, it should be understood that according to one or more embodiments, network 115 may be comprised of multiple interconnected networks, such as, for example, the Internet, a service provider network, a cable television network, or the like, an enterprise network, such as, for example, a credit card association network, a home network, or the like.

[0028] The system 100 may include a server device 120, which may constitute a relying party device, for example, but not by way of limitation. In some examples, the server device 120 may include one or more processors 122 coupled to a memory 124. Without limitation, the server device 120 may constitute a cloud-based authentication device. The server device 120 may be configured as a central system, server device, or platform for controlling and invoking various data at different times to perform multiple workflow operations. The server device 120 may be configured to connect to the first device 105. The server device 120 may be in data communication with the applet 106 and / or the application 116. For example, the server device 120 may be in data communication with the applet 106 via one or more networks 115. The first device 105 may communicate with one or more server devices 120 via one or more networks 115 and may operate as a front-end to back-end pair with the server device 120, respectively. The first device 105 may send one or more requests to the server device 120, for example from an applet 106 executing thereon. The one or more requests may relate to obtaining data from the server device 120. The server device 120 may receive the one or more requests from the first device 105. Based on the one or more requests from the applet 106, the server device 120 may be configured to obtain the requested data. The server device 120 may be configured to send the received data to the applet 106, where the received data is responsive to the one or more requests.

[0029] In some examples, server device 120 may be a dedicated server device computer, such as a blade server device, or server device 120 may be a personal computer, laptop computer, notebook computer, palmtop computer, network computer, mobile device, wearable device, or any processor-controlled device capable of supporting system 100. Figure 1 illustrates a single relying party device or server device 120. It should be understood that in other embodiments, multiple server devices or multiple computer systems may be used as needed or desired to support users, and backup or redundant server devices may also be used to prevent network downtime in the event that a particular server device fails.

[0030] Server device 120 may include applications including instructions for execution thereon. For example, an application may include instructions for execution on server device 120. The applications of server device 120 may communicate with any component of system 100. For example, server device 120 may execute one or more applications that enable network and / or data communication with, for example, one or more components of system 100 to transmit and / or receive data. Without limitation, server device 120 may be a network-enabled computer. As referred to herein, a network-enabled computer includes, but is not limited to, a computing device or a communication device. These devices include, for example, a server device, a network appliance, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a contactless card, a thin client, a fat client, an Internet browser, or other device. Server device 120 may also be a mobile device, which may include, for example, an Apple® iPhone®, iPod®, iPad®, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0031] Server device 120 may include processing circuitry and may include additional components necessary to perform the functions described herein, such as processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, anti-tamper hardware, etc. Server device 120 may further include displays and input devices. Displays may be any type of device for presenting visual information, including computer monitors, flat panel displays, mobile device screens, etc., liquid crystal displays, light emitting diode displays, plasma panels, cathode ray tube displays, etc. Input devices may include any device available and supported by the user's device for inputting information into the user's device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder, video camera, etc. These devices may be used to input information and interact with the software described herein and other devices.

[0032] The system 100 may include one or more databases 125. The databases 125 may be comprised of a relational database, a non-relational database, or other database implementations, and any combination thereof, including a plurality of relational and non-relational databases. In some examples, the databases 125 are comprised of a desktop database, a mobile database, or an in-memory database. Furthermore, the databases 125 may be hosted internally by any component of the system 100, such as the first device 105 or the server device 120, or the databases 125 may be hosted externally to the components of the system 100, such as a cloud-based platform or any storage device in data communication with the first device 105 or the server device 120. In some examples, the databases 125 may be in data communication with any number of components of the system 100. For example, the server device 120 may be configured to retrieve requested data from the database 125 sent by the applet 106. Server device 120 may be configured to transmit data received from database 125 to applet 106 over network 115, the received data being responsive to one or more transmitted requests. In another example, applet 106 may be configured to transmit one or more requests for the requested data from database 125 over network 115.

[0033] In some examples, the exemplary procedures according to the disclosure described herein may be performed by a processing and / or computational arrangement (e.g., a computer hardware arrangement). Such a processing / computational arrangement may, for example, be in whole or in part, or may include, for example, one or more microprocessors, and may include, but is not limited to, a computer / processor using instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device). For example, the computer-accessible medium may be part of the memory of the first device 105, the authentication device 110, the server device 120, and / or the database 125, or other computer hardware arrangement.

[0034] In some examples, a computer accessible medium (which may be, for example, a storage device as described herein above, such as a hard disk, a floppy disk, a memory stick, a CD-ROM, RAM, ROM, etc., or a combination thereof) may be provided (e.g., in communication with the processing arrangement). The computer accessible medium may include executable instructions. Additionally or alternatively, a storage device may be provided separate from the computer accessible medium, which may provide instructions to the processing device to configure the processing device to perform certain example procedures, processes, and methods as described herein.

[0035] The processor 122 of the server device 120 may be configured to receive an authentication request. For example, the authentication request may be received from the browser extension 101. In some examples, the authentication request may consist of a request for a FIDO2 (Fast Identity Online 2) website registration. The processor 122 may be configured to generate one or more challenges. For example, the processor 122 may be configured to generate a first challenge. In some examples, the processor 122 is configured to request the authentication device 110 to log in. The first challenge may include an identifier, such as a user identifier or a site identifier, that is used to select an appropriate FIDO key pair. The first challenge may further include an unpredictable number, possibly provided by the server device 120, that is used to prevent replay. For example, a new unpredictable number is needed for each instance of authentication, so that the unpredictable number is different each time. In this way, it is avoided to utilize a signature of an old unpredictable number and instead utilize the number for an instant session of authentication.

[0036] The authentication device 110, such as the processor 112 of the mobile device, may be configured to prompt the first device 105 for one or more inputs. For example, the one or more entries may include at least one selected from the group of taps, swipes, waves, and / or any combination thereof. Thus, the communication interface 107 of the first device 105 may input into a communication field of the authentication device 110, such as a communication field of the mobile device. The first device 105 may be configured to generate or obtain a FIDO key pair associated with a particular user or site in response to a first instruction received from the authentication device 110. The generated or obtained FIDO key pair is read by the authentication device 110. The FIDO key pair includes a FIDO private key that the authentication device 110 can read from the first device 105 and can be used by the authentication device 110 to sign a first challenge. The FIDO private key may be obtained through input into the communication field of the communication interface 107 of the first device 105. In some examples, the FIDO private key may be encrypted by the first device 105 before being transferred to the authenticator 110, in which case the mobile device processor 112 may be configured to decrypt the received encrypted FIDO private key. The server device 120 may receive the signed challenge data from the authenticator 110, such as the mobile device processor 112. The server device 120 may perform validation of the signed challenge data. For example, the server device 120 may validate the signed challenge data with a FIDO public key that was stored when the user registered with the site. The validation may constitute a result of the authentication process, including signature validation.

[0037] In some examples, transmission of the FIDO private key from the first device 105 to the authentication device 110 is prevented. For example, over-the-air (OTA) transmission of the FIDO private key is avoided when the first device 105 performs the signing of the first challenge. Thus, the first challenge and site or user identifier information are transmitted from the authentication device to the first device 105. This distributes the computation to the first device 105 using Near Field Communication (NFC) using a proxy protocol.

[0038] In some examples, the FIDO private key is generated based on a master key and an identifier associated with the authentication request using one or more encryption algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate another key pair. The first device 105 is configured to store a finite number of keys in memory 104 so that keys do not have to be regenerated. In other examples, the first instruction from the authentication device 110 may include a request to regenerate a FIDO private key, such as a private key that is part of a public / private key pair.

[0039] In some examples, the master key is stored in memory 104 on the first device 105 and the master key is combined with the site identifier on the first device 105 to generate a FIDO private key. In other examples, the master key is transferred from the first device 105 to the authentication device 110, and the combination of the master key and the site identifier is performed by the authentication device 110 to generate a FIDO private key.

[0040] In some examples, the FIDO private key is not generated or stored in the first device 105, but rather in a secure element belonging to the authentication device 110. For example, the FIDO private key may be stored in a secure element held by the authentication device 110. In some examples, the secure element may constitute a tamper-resistant secure storage area where one or more keys are securely stored and retrieved by the server device 120.

[0041] After generating the instruction, the authenticator 110 is configured to transmit the first instruction to the first device 105. The authenticator 110 may be configured to receive a FIDO private key from the first device 105 based on the first instruction. The first instruction may be transmitted by the authenticator 110 to the processor 102 of the first device 105. For example, the processor 102 of the first device 105 is configured to generate a FIDO private key. The processor 102 of the first device 105 may be configured to transmit the FIDO private key. For example, the processor 102 of the first device 105 is configured to transmit the FIDO private key to the authenticator 110, such as an application 116 including instructions for execution on the authenticator 110. As mentioned above, the authenticator 110 may be a mobile device, such as, but not limited to, a laptop, tablet, phone, etc. In some examples, the FIDO private key may be transmitted or received via one or more channels. For example, the FIDO private key is transmitted or received via an out-of-band channel. The processor 102 of the first device 105 is configured to transmit the FIDO private key to the authentication device 110 by an entry into a communication field of the communication interface 107 of the authentication device 110. In some examples, the entry may be associated with one or more gestures, including but not limited to one or more taps, swipes, waves, and / or any combination thereof. The authentication device 110 may be configured to transmit the first FIDO key to the processor 122 of the server device 120 for verification, and thus the authentication device 110 may be configured to act as an intermediary device between the first device 105 and the processor 122 of the server device 120.

[0042] The processor 122 may be configured to verify the signed challenge data sent from the authentication device 110 using a second FIDO key, which may be a FIDO public key, which may be part of a public-private key pair, as described above. For example, the application 116, which includes instructions for execution on the authentication device 110, may be configured to sign a first challenge issued by the website using the FIDO private key. Once the challenge is signed by the authentication device 110, it is sent to the processor 122 for verification using the FIDO public key stored in the memory 124 of the server device 120.

[0043] The processor 122 may be configured to generate the second instructions. For example, the second instructions may include a second request to transmit input data. After generating the instructions, the processor 122 may be configured to transmit the second instructions. For example, the processor 122 may be configured to transmit the second instructions to the authentication device 110. In some examples, the second instructions may be forwarded by the processor 122 to the application 116 using one or more push notifications. In some examples, the second instructions may be transmitted by the processor 122 after evaluation of one or more conditions by the processor 122 and / or the database 125. For example, at least one of the one or more conditions may include determining a threshold number of authentication requests over a predetermined period of time. For example, the processor 122 and / or the database 125 may be configured to determine whether an abnormal number of transactions or requests have been performed within any number of seconds, minutes, hours, days, weeks, months, years, etc. In another example, at least one of the one or more conditions may include determining whether abuse or fraud has occurred associated with the account and / or user. For example, the processor 122 and / or database 125 may be configured to determine whether the user's transaction history indicates excessive purchases or unusual locations. In this manner, conditional multi-factor authentication may be implemented to improve security and trigger transmission of a second instruction to receive input data.

[0044] The processor 122 may be configured to receive input data based on the second instructions. The processor 122 may be configured to receive input data from the authentication device 110, such as from an application 116 including instructions for execution on the second device. The input data may include at least one selected from the group of biometric data and credential data. For example, the input data may include biometric data, credential data, and / or any combination thereof. Without limitation, the biometric data may include at least one selected from the group of a fingerprint, a face scan, a retina scan, voice recognition, and / or any combination thereof. In some examples, the input data may additionally and / or alternatively include credential data. Without limitation, the login data may include at least one selected from the group of an input username, a password, an account number, a security code, a one-time passcode, an answer to a security question, and / or any combination thereof.

[0045] The processor 122 may be configured to complete the authentication request by authenticating the input data. For example, the processor 122 may be configured to generate one or more results by comparing the received input data with the reference input data. In some examples, the reference input data may be stored in the memory 124 of the server device 120. In other examples, the reference input data may be requested by the processor 122. For example, the processor 122 may be configured to receive the reference input data through one or more requests, or alternatively, to transmit the input data to the database 125 for comparison with the reference input data. For example, the processor 122 of the server device 120 may be configured to generate a result indicating successful authentication if matching is successful based on the comparison of the received input data with the reference input data. In another example, the processor 122 of the server device 120 may be configured to generate a result of failed authentication if matching is unsuccessful based on the comparison of the received input data with the reference input data. If authentication is determined to be unsuccessful, the processor 122 of the server device 120 may be configured to re-authenticate the input data up to and including a predetermined number of attempts before successfully authenticating the input data. To complete the authentication request or to abort completion of the authentication request. As such, system 100 may be implemented using distributed storage, cloud-based storage, and other forms of storage to support the functionality described above.

[0046] Figure 2A shows one or more first devices 200. The first devices 200 may refer to the same or similar components of the first devices 105, as described above with respect to Figure 1. Although Figures 2A and 2B depict a single instance of the components of the first devices 200, any number of components may be utilized.

[0047] The first device 200 may be configured to communicate with one or more components of the system 100. The first device 200 may be configured with a contact card (e.g., a card that is read by swiping a magnetic stripe or by inserting into a chip reader) or a contactless card. The first device 200 may be configured with a payment card, such as a credit card, a debit card, a gift card, etc., issued by the service provider 205 displayed on the front or back of the first device 200. In some examples, the first device 200 may be configured with an ID card, a membership card, and a transportation card, independent of a payment card. In some examples, the payment card may be configured with a dual interface contactless payment card.

[0048] The first device 200 can be comprised of a substrate 210, which can include a single layer or one or more "laminated layers" comprised of plastics, metals, and other materials. Exemplary substrates include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, biodegradable materials, and the like. In some examples, the first device 200 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, and the first device 200 may otherwise conform to the ISO / IEC 14443 standard. However, it is understood that the first device 200 according to the present disclosure may have different characteristics and the present disclosure does not require implementation in a payment card.

[0049] The first device 200 may also include identification information 215 displayed on the front and / or back of the card, and a contact pad 220. The contact pad 220 may be configured to establish contact with other communication devices, including but not limited to user equipment, smartphones, laptops, desktops, or tablet computers. The first device 200 may also include processing circuitry, an antenna, and other components not shown in FIG. 2A. These components may be located behind the contact pad 220 or elsewhere on the substrate 210. The first device 200 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 2A).

[0050] As shown in Figure 2B, the contact pad 220 of Figure 2A can include processing circuitry 225 for storing and processing information, which includes a processor 230, such as a microprocessor, and memory 235. It should be understood that the processing circuitry 225 can include additional components, such as processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, anti-tamper hardware, and other additional components necessary to perform the functions described herein.

[0051] The memory 235 may be, for example, a read-only memory such as a RAM, a ROM, an EEPROM, a write-once-read-multiple memory, or a read / write memory, and the first device 200 may include one or more of these memories. A read-only memory may be factory programmable as read-only, or may be one-time programmable. One-time programmable offers the opportunity to write once and read many times. A write-once / read-multiple memory may be programmed at a time after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but can be read many times. A read / write memory may be programmed and reprogrammed many times after leaving the factory, and can be read many times.

[0052] The memory 235 may be configured to store one or more applets 240, one or more counters 245, and a customer identifier 250. The one or more applets 240 may be comprised of one or more software applications configured to run on one or more contact or contactless cards, such as a Java Card applet. However, it is understood that the applet 240 is not limited to a Java Card applet, but may instead be any software application operable on a contact or contactless card, or other device with limited memory. The one or more counters 245 may be comprised of a numeric counter sufficient to store an integer number. The customer identifier 250 may be comprised of a unique alphanumeric identifier assigned to a user of the first device 200, and the identifier may distinguish a user of a contactless card from users of other contactless cards. In some examples, the customer identifier 250 may identify both a customer and an account assigned to the customer, and may further identify a contactless card associated with the customer's account.

[0053] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto, and it will be appreciated that these elements may be implemented external to the contact pads 220, may be completely separate from the contact pads 220, or may be implemented as additional elements in addition to the processor 230 and memory 235 elements disposed within the contact pads 220.

[0054] In some examples, the first device 200 may include one or more antennas 255. The one or more antennas 255 may be disposed within the first device 200 around the processing circuit 225 of the contact pad 220. For example, the one or more antennas 255 may be integral with the processing circuit 225, or the one or more antennas 255 may be used with an external booster coil. As another example, the one or more antennas 255 may be external to the contact pad 220 and the processing circuit 225.

[0055] In one embodiment, the coil of the first device 200 may function as the secondary side of an air-core transformer. The terminal may communicate with the first device 200 by disconnecting the power or amplitude modulation. The first device 200 may use a gap in the power connection of the first device to infer data transmitted from the terminal, which may be functionally maintained using one or more capacitors. The first device 200 may return communication by switching the load or performing load modulation on the coil of the first device. Load modulation may be detected on the coil of the terminal by interference.

[0056] Figure 3 illustrates an authentication method 300. Figure 3 may reference the same or similar components of the system 100 of Figure 1 and the first device 200 of Figures 2A and 2B.

[0057] At block 305, the method 300 may include receiving one or more challenges at a processor. For example, a relying party device or a server device may be configured to generate a first challenge. In some examples, the relying party device may be configured to challenge an authentication device, such as a processor of a mobile device, to log in. The first challenge may include an identifier, such as a user identifier or a site identifier, that is used to select an appropriate FIDO key pair. The first challenge may further include an unpredictable number provided by the relying party device that is used to prevent replay. For example, a new unpredictable number is needed for each instance of authentication, so that the unpredictable number is different each time. In this way, utilizing a signature of an old unpredictable number is avoided, and instead utilizes an instant session number of authentication.

[0058] In some examples, the first request comprises an authentication request. The authentication request includes a FIDO2 (Fast Identity Online 2) website registration request. The processor may be configured to generate one or more instructions. For example, the processor is configured to generate first instructions. Each instruction may include one or more requests. The first instructions may include a first request to obtain a first key from a processor of the first device. The key includes a FIDO key. The first key may be obtained by input to a communication field of a communication interface of the first device. In some examples, the first instructions include a request to generate the first key by the processor of the first device. In other examples, the first instructions may include a request to regenerate the first FIDO key, the processor of the first device using a private key that is part of a public / private key pair, or the like.

[0059] At block 310, the method 300 may include generating, by a processor, a first instruction including a request to obtain a first Fast Identity Online (FIDO) key from the first device. For example, based on a first challenge received from the relying party device, an authentication device, such as a processor of a mobile device, is configured to prompt one or more inputs of the first device by generating one or more instructions. For example, the one or more inputs may include at least one selected from the group of a tap, a swipe, a wave, etc., and / or any combination thereof. The first instruction may include a request to generate a first FIDO key by the first device. In some examples, the first FIDO key is generated based on a master key and an identifier associated with the first request using one or more cryptographic algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate a key pair. In some examples, the master key is stored on the first device, and the master key is combined with the site identifier on the first device to generate a private key. In other examples, the master key may be transferred from the first device to an application containing instructions for execution on the second device, and the binding of the master key and the site identifier is performed by the application on the second device to generate a private key. In some examples, rather than generating or storing the FIDO private key on the first device, the first FIDO key may be generated or stored on a secure element belonging to the second device. For example, the FIDO private key is stored in a secure element held by the second device. In some examples, the secure element may constitute a tamper-resistant secure storage area where one or more keys are securely stored and retrieved by the server device.

[0060] At block 315, the method 300 may include transmitting, by the processor, the first instruction. For example, the processor may be configured to transmit the first instruction to the first device. In some examples, the first instruction may be transmitted to a processor of the first device by the authentication device. After generating the instruction, the authentication device is configured to transmit the first instruction to the first device.

[0061] At block 320, the method 300 may include receiving a first FIDO key. For example, a communication interface of the first device may be input into a communication field of the authentication device, such as a communication field of the mobile device, to transfer the first FIDO key. The first device is configured to generate or obtain a FIDO key pair associated with a particular user or site in response to a first instruction received from the authentication device. The generated or obtained FIDO key pair is read by the authentication device. The FIDO key pair includes a FIDO private key that the authentication device can read from the first device and can be used by the authentication device to sign a first challenge resulting in signed challenge data. The FIDO private key is obtained by the communication interface of the first device being input into the communication field. In some examples, the FIDO private key may be encrypted by the first device before being transferred to the authentication device, in which case the processor of the mobile device may be configured to decrypt the received encrypted FIDO private key.

[0062] In some examples, the FIDO private key is generated based on a master key and an identifier associated with the authentication request using one or more encryption algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate another key pair. The first device is configured to store a finite number of keys in memory so that keys do not have to be regenerated. In other examples, the first instruction from the authentication device includes a request to regenerate a FIDO private key, e.g., a private key that is part of a public / private key pair.

[0063] In some examples, the master key is stored in a memory on the first device and the master key is combined with the site identifier on the first device to generate a FIDO private key, in other examples, the master key is transferred from the first device to an authentication device and the combination of the master key and the site identifier is performed by the authentication device to generate a FIDO private key.

[0064] In some examples, transmission of the FIDO private key from the first device to the authentication device is prevented. For example, over-the-air transmission of the FIDO private key is avoided when the first device performs the signing of the first challenge. Thus, the first challenge and site or user identifier information are transmitted from the authentication device to the first device, whereby the authentication device distributes the computation to the first device using Near Field Communication (NFC) using a proxy protocol.

[0065] In some examples, the FIDO private key is not generated or stored in the first device, but rather in a secure element belonging to the authentication device. For example, the FIDO private key is stored in a secure element held by the second device. In some examples, the secure element may include a tamper-resistant secure storage area where one or more keys are securely stored and may be retrieved by the relying party device.

[0066] In some examples, the processor of the first device may be configured to generate a FIDO private key. The processor of the first device is configured to transmit the FIDO private key. For example, the processor of the first device is configured to transmit the FIDO private key to the authentication device, such as, for example, an application including instructions for execution on the second device. As mentioned above, the authentication device may be a mobile device, such as, but not limited to, a laptop, tablet, phone, etc. In some examples, the FIDO private key is transmitted and received over one or more channels. For example, the FIDO private key is transmitted and received over an out-of-band channel. The processor of the first device is configured to transmit the FIDO private key to the authentication device by an entry from a communication interface of the first device to a communication field of the authentication device. In some examples, the entry is associated with one or more gestures, including, but not limited to, one or more taps, swipes, waves, and / or any combination thereof.

[0067] For example, the processor of the first device may be configured to generate a first FIDO key. The processor of the first device may be configured to transmit the first FIDO key. For example, the processor of the first device may be configured to transmit the first FIDO key to an application including instructions for execution on the second device. As mentioned above, the second device may be a mobile device such as, but not limited to, a laptop, tablet, phone, etc. In some examples, the first FIDO key may be transmitted and received over one or more channels. For example, the first FIDO key is transmitted and received over an out-of-band channel. The processor of the first device may be configured to transmit the first FIDO key to an application of the second device by entry of a communication interface into a communication field of the second device. In some examples, the entry is associated with one or more gestures, including, but not limited to, one or more taps, swipes, waves, and / or any combination thereof. The application on the second device may be configured to send the first FIDO key to a processor of the server device for verification, and thus the second device may be configured to act as an intermediary device between the first device and the processor.

[0068] At block 325, the method 300 may include signing, by the processor, the one or more challenges with the first FIDO key.

[0069] At block 330, the method 300 may include transmitting, by the processor, one or more signed challenges for verification with the second FIDO key. For example, the processor may be configured to transmit the one or more signed challenges to a relying party device. The relying party device may receive the signed challenge data from an authentication device, such as a processor of a mobile device. The relying party device may perform verification of the signed challenge data. For example, the relying party device may verify the signed challenge data with a FIDO public key stored when the user registered with the site. The verification comprises a result of an authentication process that includes signature verification. The authentication device may be configured to transmit the first FIDO key to a processor of the relying party device for verification, and thus the authentication device may be configured to act as an intermediary device between the first device and the processor of the relying party device.

[0070] The relying party device is configured to verify the FIDO private key with a FIDO service of the website. The relying party device may be configured to verify the signed challenge data sent from the authenticator device with a second FIDO key, such as a FIDO public key that is part of the public / private key pair described above. For example, an application including instructions for execution on the second device is configured to sign a first challenge issued by the website with the FIDO private key. Once the challenge is signed by the authenticator, it is sent to a processor for verification with the FIDO public key stored in the memory of the server device.

[0071] The relying party device may be configured to generate a second instruction. For example, the second instruction may include a second request to transmit input data. After generating the instruction, the relying party device may be configured to transmit the second instruction. For example, the relying party device is configured to transmit the second instruction to the authentication device. In some examples, the second instruction may be forwarded by the relying party device to the application using one or more push notifications. In some examples, the second instruction may be transmitted by the relying party device after evaluation of one or more conditions by the relying party device and / or database. For example, at least one of the one or more conditions may include determining a threshold number of authentication requests over a predetermined period of time. For example, the relying party device and / or database may be configured to determine whether an abnormal number of transactions or requests have been performed within any number of seconds, minutes, hours, days, weeks, months, years, etc. In another example, at least one of the one or more conditions may include determining whether abuse or fraud has occurred associated with the account and / or user. For example, the relying party device and / or database may be configured to determine whether a user's transaction history indicates excessive purchases or anomalous locations. In this manner, conditional multi-factor authentication may be implemented to improve security and trigger the transmission of a second instruction to receive input data.

[0072] The relying party device may be configured to receive input data based on the second instructions. The relying party device may be configured to receive input data from an authentication device, such as from an application including instructions for execution on the second device. The input data may include at least one selected from the group of biometric data and credential data. For example, the input data may include biometric data, credential data, and / or any combination thereof. Without limitation, the biometric data may include at least one selected from the group of fingerprint, face scan, retina scan, voice recognition, and / or any combination thereof. In some examples, the input data may additionally and / or alternatively include credential data. Without limitation, the login data may include at least one selected from the group of input of a username, a password, an account number, a security code, a one-time passcode, an answer to a security question, and / or any combination thereof.

[0073] The relying party device is configured to complete the authentication request by authenticating the input data. For example, the relying party device may be configured to generate one or more results by comparing the received input data with the reference input data. In some examples, the reference input data may be stored in a memory of the relying party device. In other examples, the reference input data may be requested by the relying party device. For example, the relying party device may be configured to receive the reference input data through one or more requests, or alternatively, to transmit the input data to a database for comparison with the reference input data. For example, the processor of the relying party device is configured to generate a result indicating successful authentication if the matching is successful based on the comparison of the received input data with the reference input data. In another example, the processor of the relying party device is configured to generate a result indicating failed authentication if the matching is unsuccessful based on the comparison of the received input data with the reference input data. If authentication is determined to be unsuccessful, the processor of the relying party device may be configured to reauthenticate the input data up to a predetermined number of attempts before successfully authenticating the input data, completing the authentication request, or aborting the completion of the authentication request. As such, the authentication system may implement distributed storage, cloud-based storage, and other forms of storage to support the functionality described above.

[0074] 4 illustrates a sequence diagram 400 of an authentication process according to an example embodiment. FIG 4 may refer to the same or similar components of the system 100, the first device 200 of FIG 2A and FIG 2B, and the method 300 of FIG 3.

[0075] At step 405, a processor may be configured to receive an authentication request. As an example, the processor may be part of a relying party device or a server device. In some examples, the authentication request comprises a request for a FIDO2 (Fast Identity Online 2) website registration. For example, the request is received from a browser extension.

[0076] In step 410, the processor may be configured to generate one or more challenges in response to the authentication request. For example, the processor is configured to generate a first challenge. In some examples, the relying party device is configured to challenge the authenticator, such as a processor of a mobile device logging in, and the first challenge may include, for example, an identifier. The first challenge may further include an unpredictable number provided by the relying party device, used to prevent replay. For example, a new unpredictable number is needed for each instance of authentication, so that the unpredictable number is different each time. In this way, one avoids using a signature of an old unpredictable number and instead uses the number of the instant session of authentication.

[0077] In step 415, the processor may be configured to transmit a first challenge, for example, the processor may be configured to transmit a first instruction to an authentication device, for example, an application including instructions for execution on a device, including but not limited to a mobile device.

[0078] In step 420, a first instruction may be sent to the first device. For example, the first instruction may be generated by the authentication device and / or sent to a processor of the card. The processor may be configured to generate one or more instructions. For example, the processor may be configured to generate the first instructions. Each instruction may include one or more requests. The first instruction includes a first request to obtain a first key from a processor of the first device. The key includes a FIDO key. The first key may be obtained by inputting from a communication interface of the first device into a communication field, such as a communication field of the authentication device. In some examples, the first instruction may include a request to generate the first key by the processor of the first device. In other examples, the first instruction may include a request to regenerate the first FIDO key, such as using a private key that is part of a public / private key pair, the processor of the first device.

[0079] For example, based on the first challenge received from the relying party device, the authentication device, such as a processor of a mobile device, may be configured to prompt one or more inputs of the first device by generating one or more instructions. For example, the one or more inputs may include at least one selected from the group of a tap, a swipe, a wave, etc., and / or any combination thereof. The first instruction may include a request to generate a first FIDO key by the first device. In some examples, the first FIDO key is generated based on a master key and an identifier associated with the first request using one or more cryptographic algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate a key pair. In some examples, the master key is stored on the first device, and the master key is combined with the site identifier on the first device to generate a private key.

[0080] In step 425, the processor of the first device is configured to generate and transmit a first FIDO key. For example, a communication interface of the first device can be input to a communication field of the authentication device, such as a communication field of the mobile device, to transfer the first FIDO key. The first device is configured to generate or obtain a FIDO key pair associated with a particular user or site in response to a first instruction received from the authentication device. The generated or obtained FIDO key pair is read by the authentication device. The FIDO key pair includes a FIDO private key that the authentication device can read from the first device and that the authentication device can use to sign the first challenge. The FIDO private key is obtained by inputting the communication interface of the first device to the communication field. In some examples, the FIDO private key is encrypted by the first device before being transferred to the authentication device, in which case the processor of the mobile device is configured to decrypt the received encrypted FIDO private key.

[0081] In some examples, the FIDO private key is generated based on a master key and an identifier associated with the authentication request using one or more encryption algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate another key pair. The first device is configured to store a finite number of keys in memory so that keys do not have to be regenerated. In other examples, the first instruction from the authentication device includes a request to regenerate a FIDO private key, such as a private key that is part of a public / private key pair.

[0082] In some examples, the master key is stored in a memory on the first device and the master key is combined with the site identifier on the first device to generate the FIDO private key, in other examples, the master key is transferred from the first device to the authentication device and the combination of the master key and the site identifier is performed by the authentication device to generate the FIDO private key.

[0083] In some examples, transmission of the FIDO private key from the first device to the authentication device is prevented. For example, over-the-air transmission of the FIDO private key is avoided when the first device performs the signing of the first challenge. In this manner, the first challenge and site or user identifier information are transmitted from the authentication device to the first device, thereby distributing the computation to the first device over Near Field Communication (NFC) using a proxy protocol.

[0084] In some examples, the FIDO private key is not generated or stored in the first device, but rather in a secure element belonging to the authentication device. For example, the FIDO private key is stored in a secure element held by the second device. In some examples, the secure element consists of a tamper-resistant secure storage area where one or more keys are securely stored and retrieved by the relying party device.

[0085] In some examples, the processor of the first device may be configured to generate a FIDO private key. The processor of the first device may be configured to transmit the FIDO private key to an authentication device, such as, for example, an application including instructions for execution on the second device. As discussed above, the authentication device may be a mobile device, such as, but not limited to, a laptop, tablet, phone, etc. In some examples, the FIDO private key may be transmitted or received over one or more channels. For example, the FIDO private key may be transmitted or received over an out-of-band channel. The processor of the first device may be configured to transmit the FIDO private key to the authentication device by an entry into a communication field of the authentication device of a communication interface of the first device. In some examples, the entry may be associated with one or more gestures, including, but not limited to, one or more taps, swipes, waves, and / or any combination thereof.

[0086] In step 430, the authentication device is configured to receive a first FIDO key. For example, an application on the second device is configured to receive a first FIDO private key from a processor on the first device. The authentication device is configured to sign a first challenge with the received first FIDO key. The authentication device is configured to send the signed first challenge to the relying party device for verification.

[0087] In step 435, a processor of the relying party device or server device may be configured to verify the signed first challenge. For example, a processor of the relying party device or server device may be configured to receive the signed first challenge from an authentication device. For example, the relying party device may verify the signed challenge data with a FIDO public key stored when the user registered with the site. The verification may constitute a result of an authentication process that includes signature verification. The authentication device may be configured to transmit the first FIDO key to the processor of the relying party device for verification, and thus the authentication device may be configured to act as an intermediary device between the first device and the processor of the relying party device.

[0088] In step 440, the processor of the relying party device or the server device may be configured to generate a second instruction. For example, the second instruction may include a second request to transmit input data. In some examples, the processor may be configured to evaluate one or more conditions. For example, the second instruction is transmitted by the processor after evaluation of the one or more conditions. For example, at least one of the one or more conditions may include determining a threshold number of authentication requests over a predetermined period of time. For example, the processor may be configured to determine whether an abnormal number of transactions or requests have been performed within any number of seconds, minutes, hours, days, weeks, months, years, etc. In another example, at least one of the one or more conditions may include determining whether abuse or fraud has occurred associated with the account and / or user. For example, the processor may be configured to determine whether the user's transaction history indicates excessive purchases or abnormal locations. In this manner, conditional multi-factor authentication may be implemented to improve security, which may trigger the transmission of the second instruction to receive input data.

[0089] In step 445, the authenticator may be configured to receive second instructions. For example, the processor of the mobile device may be configured to receive second instructions from the processor of the relying party device or server device after evaluation of one or more conditions by the relying party device or server device. In some examples, the second instructions, such as an application including instructions for execution on the mobile device using one or more push notifications, are forwarded to the authenticator by the processor of the relying party device or server device.

[0090] In step 450, the authentication device is configured to transmit the input data based on the second instruction. For example, a processor or application of the mobile device can be configured to transmit the input data to a relying party device, such as a processor of a server device. The input data can include at least one selected from the group of biometric data and credential data. For example, the input data can include biometric data, credential data, and / or any combination thereof. Without limitation, the biometric data can include at least one selected from the group of fingerprint, face scan, retina scan, voice recognition, and / or any combination thereof. In some examples, the input data can additionally and / or alternatively include credential data. Without limitation, the login data can include at least one selected from the group of input of a username, a password, an account number, a security code, a one-time passcode, an answer to a security question, and / or any combination thereof.

[0091] In step 455, the relying party device or server device is configured to complete the authentication request by authenticating the input data. For example, a processor of the relying party device or server device is configured to receive input data from an authentication device, such as a processor or application configuring execution instructions of a mobile device. In some examples, the processor of the relying party device or server device may be configured to generate one or more results by comparing the received input data with reference input data. In some examples, the reference input data may be stored by the relying party device or server device. In other examples, the reference input data may be requested by the relying party device or server device. For example, the processor of the relying party device or server device may be configured to receive the reference input data through one or more requests, or alternatively, to send the input data to a database for comparison with the reference input data. For example, the relying party device or server device is configured to generate a result indicating successful authentication if matching is successful based on a comparison of the received input data with the reference input data. In another example, the relying party device or server device is configured to generate a result of failed authentication if matching is unsuccessful based on a comparison of the received input data with the reference input data. If authentication is determined to be unsuccessful, the relying party device or server device may be configured to re-authenticate the input data up to a predetermined number of attempts to complete the authentication request or to abort completion of the authentication request before successfully authenticating the input data. Thus, authentication process sequence diagram 400 may be implemented using distributed storage, cloud-based storage, and other forms of storage to support the functionality described above.

[0092] Figure 5 illustrates a method 500 of authentication according to an example embodiment. Figure 5 may reference the same or similar components of the system 100, the first device 200 of Figures 2A and 2B, the method 300 of Figure 3, and the sequence diagram 400 of Figure 4.

[0093] At block 505, the method 500 may include receiving a first instruction at a processor. The processor may be coupled to a memory including an application including instructions for executing on a first device, such as a card. In some examples, the first instruction may be associated with completing an authentication request. For example, the authentication request comprises a request for a Fast Identity Online 2 (FIDO2) website registration. The first instruction is part of one or more instructions generated and / or transmitted by a processor of the authentication device, such as, for example, an application including instructions for executing on a second device, such as a client device or a mobile device. For example, the processor of the authentication device is configured to generate the first instruction. Each instruction may include one or more requests. The first instruction includes a first request to generate or obtain a first key from the processor of the first device. The key comprises a FIDO key, such as a FIDO private key.

[0094] The first instruction may include a request to obtain a first FIDO (Fast Identity Online) key from a first device, including but not limited to a card. The first instruction may include a request to generate a first FIDO key by the first device. In some examples, the first FIDO key is generated based on a master key and an identifier associated with the first request using one or more cryptographic algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate a key pair. In some examples, the master key is stored on the first device, and the master key is combined with the site identifier on the first device to generate a private key. In some examples, rather than generating or storing the FIDO private key on the first device, the first FIDO key can be generated or stored on an authentication device, such as a client device, including a mobile device, or a secure element belonging to a second device. For example, the FIDO private key can be stored in a secure element held by the second device. In some examples, the secure element comprises a tamper-resistant secure storage area in which one or more keys are securely stored and retrieved by the authentication device or relying party device server device. For example, the authentication device is configured to send a first instruction to the first device, and the authentication device is configured to act as an intermediary device between the first device and the relying party device or the server device.

[0095] At block 510, the method 500 may include generating a first key. For example, the first key may be obtained by inputting a communication interface of the second device into a communication field of a client device, such as an authentication device or a mobile device. In some examples, the first instruction may include a request for the first device to generate the first key. In other examples, the first instruction may include a request to regenerate a first FIDO key, such as a private key that is part of a public / private key pair. The authentication device, such as a processor of the mobile device, may be configured to prompt one or more inputs of the first device. For example, the one or more inputs may include at least one selected from the group of a tap, a swipe, a wave, and / or any combination thereof. Thus, the communication interface of the first device may enter a communication field of the authentication device, such as a communication field of the mobile device. The first device is configured to generate or obtain a FIDO key pair associated with a particular user or site based on the first instruction received from the authentication device. The processor of the first device may be configured to receive a first instruction from the authentication device via a first entry and transmit the FIDO private key to a communication field of the authentication device via a second entry in a communication interface of the first device. In some examples, the one or more entries may be associated with one or more gestures, including, but not limited to, one or more taps, swipes, waves, and / or any combination thereof.

[0096] In some examples, the FIDO private key is generated based on a master key and an identifier associated with the authentication request using one or more encryption algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate another key pair. The first device is configured to store a finite number of keys in memory so that keys do not have to be regenerated. In other examples, the first instruction from the authentication device includes a request to regenerate a FIDO private key, such as a private key that is part of a public / private key pair.

[0097] In some examples, the master key is stored in a memory on the first device and the master key is combined with the site identifier on the first device to generate the FIDO private key, in other examples, the master key is transferred from the first device to the authentication device and the combination of the master key and the site identifier is performed by the authentication device to generate the FIDO private key.

[0098] In some examples, the FIDO private key is not generated or stored in the first device, but rather in a secure element belonging to the authentication device, e.g., the FIDO private key is stored in a secure element held by the second device.

[0099] At block 515, the method 500 includes encrypting the first key. For example, the FIDO private key is encrypted by the first device before being transferred to the authentication device. Thus, the processor of the mobile device is configured to decrypt the received encrypted FIDO private key before signing the one or more challenges.

[0100] At block 520, the method 500 may include transmitting the encrypted first key for verification. For example, the processor of the first device may be configured to transmit the encrypted FIDO private key to the authentication device for verification. The generated or obtained FIDO key pair may be read by the authentication device, including but not limited to via Near Field Communication (NFC). The FIDO key pair includes a FIDO private key that the authentication device can read from the first device. The FIDO private key is obtained by one or more entries from a communication interface of the first device to a communication field of the authentication device.

[0101] In some examples, transmission of the encrypted FIDO private key from the first device to the authentication device is prevented. For example, if the first device is configured to perform signing of the first challenge, over-the-air (OTA) transmission of the FIDO private key is avoided. Thus, the first challenge and site or user identifier information are transmitted from the authentication device to the first device, whereby the authentication device distributes the computation to the first device using Near Field Communication (NFC) using a proxy protocol.

[0102] In some examples, the FIDO private key may be transmitted and received over one or more channels. For example, the FIDO private key is transmitted and received over an out-of-band channel. In some examples, the authenticator is configured to receive the FIDO private key from the first device over the out-of-band channel. The authenticator may be configured to transmit the first FIDO key to a processor of the relying party device for validation, and thus the authenticator may be configured to act as an intermediary device between the first device and the processor of the relying party device.

[0103] In some examples, the relying party device may be configured to generate and / or transmit one or more second instructions. For example, the second instructions may include a request to transmit input data. An authentication device, such as a processor of the second device, is configured to receive the second instructions. For example, the processor of the second device may be configured to receive a request to transmit input data from a processor of the relying party device or the server device. In some examples, the second instructions are forwarded from the processor of the relying party device or the server device to the authentication device and communicated to the processor of the second device, such as with one or more push notifications. In some examples, the second instructions may be received by the authentication device after evaluation of one or more conditions by the relying party device or the server device. For example, at least one of the one or more conditions includes determining a threshold number of authentication requests over a predetermined period of time. For example, the relying party device may be configured to determine whether an abnormal number of transactions or requests have been performed within any period of time, such as a second, minute, hour, day, week, month, year, etc. In another example, at least one of the one or more conditions may include determining whether abuse or fraud has occurred associated with the account and / or user. For example, the relying party device may be configured to determine whether a user's transaction history indicates excessive purchase amounts or anomalous locations, thus implementing conditional multi-factor authentication to improve security and trigger transmission of a second instruction to receive input data.

[0104] Fig. 6 illustrates an authentication method 600 according to an example embodiment. Fig. 6 may reference the same or similar components of the system 100, the first device 200 of Fig. 2A and Fig. 2B, the method 300 of Fig. 3, the sequence diagram 400 of Fig. 4, and the method 500 of Fig. 5.

[0105] At block 610, the method 600 may include receiving an authentication request at a processor. For example, the processor may reside in a relying party device or a server device. In some examples, the authentication request includes a Fast Identity Online 2 (FIDO2) website registration request.

[0106] At block 620, the method 600 may include transmitting, by the processor, a first challenge. For example, the processor is configured to transmit the first challenge to an authentication device, such as an application including instructions for execution on an intermediary second device or a client device. In some examples, the processor may be configured to generate one or more challenges in response to an authentication request. For example, the processor is configured to generate the first challenge. In some examples, the relying party device is configured to request a login to an authentication device, such as a processor of a mobile device. The first challenge may include an identifier, such as a user identifier or a site identifier, that may be used to select an appropriate FIDO key pair. The first challenge may further include an unpredictable number provided by the relying party device that is used to prevent replay. For example, a new unpredictable number is needed for each instance of authentication, so that the unpredictable number is different each time. In this way, utilizing a signature of an old unpredictable number is avoided, and instead utilizes an instant session number of authentication.

[0107] At block 630, the method 600 may include verifying the first challenge. For example, a first instruction may be sent by the authentication device to the first device. In some examples, the first instruction may be generated and / or sent by the authentication device to a processor of the card. The authentication device, such as a processor of a mobile device, may be configured to generate one or more instructions. For example, the processor of the mobile device may be configured to generate the first instructions. Each instruction may include one or more requests. The first instruction may include a first request to obtain a first key from a processor of the first device, such as a card. The key may comprise a FIDO key. The FIDO private key is obtained by a communication interface of the first device being entered into a communication field, such as a communication field of the authentication device. In some examples, the first instruction may include a request to generate a FIDO private key by the processor of the first device. In other examples, the first instruction may include a request to regenerate a first FIDO key, e.g., a FIDO private key, where the FIDO private key is part of a public / private key pair.

[0108] For example, the authentication device may be configured to prompt one or more entries of the first device by generating one or more instructions based on a first challenge received from a processor of the relying party device or the server device. For example, the one or more inputs may include at least one selected from the group of a tap, a swipe, a wave, etc., and / or any combination thereof. The first instruction may include a request to generate a first FIDO key by the first device. In some examples, the first FIDO key is generated based on a master key and an identifier associated with the first request using one or more cryptographic algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate a key pair. In some examples, the master key is stored on the first device, and the master key is combined with the site identifier on the first device to generate a private key.

[0109] For example, the processor of the first device is configured to generate and transmit a first FIDO key. For example, the communication interface of the first device can enter a communication field of the authentication device, such as a communication field of a mobile device. The first device is configured to generate or obtain a FIDO key pair associated with a particular user or site in response to a first instruction received from the authentication device. The generated or obtained FIDO key pair is read by the authentication device. The FIDO key pair includes a FIDO private key that the authentication device can read from the first device and can be used by the authentication device to sign a first challenge resulting in signed challenge data. The FIDO private key is obtained by entering it from the communication interface of the first device into the communication field. In some examples, the FIDO private key may be encrypted by the first device before being transferred to the authentication device, in which case the processor of the mobile device may be configured to decrypt the received encrypted FIDO private key.

[0110] In some examples, the FIDO private key is generated based on a master key and an identifier associated with the authentication request using one or more encryption algorithms. For example, the identifier includes a site identifier and is combined with the master key to generate another key pair. The first device is configured to store a finite number of keys in memory so that keys do not have to be regenerated. In other examples, the first instruction from the authentication device includes a request to regenerate a FIDO private key, such as a private key that is part of a public / private key pair.

[0111] In some examples, the master key is stored in a memory on the first device and the master key can be combined with the site identifier on the first device to generate the FIDO private key, in other examples, the master key is transferred from the first device to the authentication device and the combination of the master key and the site identifier is performed by the authentication device to generate the FIDO private key.

[0112] In some examples, transmission of the FIDO private key from the first device to the authentication device is prevented. For example, over-the-air transmission of the FIDO private key is avoided when the first device performs the signing of the first challenge. In this manner, the first challenge and site or user identifier information are transmitted from the authentication device to the first device, thereby distributing the computation to the first device over Near Field Communication (NFC) using a proxy protocol.

[0113] In some examples, the FIDO private key is not generated or stored in the first device, but rather in a secure element belonging to the authentication device. For example, the FIDO private key is stored in a secure element held by the second device. In some examples, the secure element consists of a tamper-resistant secure storage area where one or more keys are securely stored and retrieved by the relying party device.

[0114] In some examples, the processor of the first device may be configured to generate a FIDO private key. The processor of the first device may be configured to transmit the FIDO private key. For example, the processor of the first device may be configured to transmit the FIDO private key to the authentication device, such as an application including instructions for execution on the second device. As mentioned above, the authentication device may be a mobile device, such as, but not limited to, a laptop, tablet, phone, etc. In some examples, the FIDO private key may be transmitted and received over one or more channels. For example, the FIDO private key is transmitted and received over an out-of-band channel. The processor of the first device may be configured to transmit the FIDO private key to the authentication device by a communication interface of the first device being entered into a communication field of the authentication device. In some examples, the entry may be associated with one or more gestures, including, but not limited to, one or more taps, swipes, waves, and / or any combination thereof.

[0115] In some examples, the authentication device is configured to receive a first FIDO key. For example, an application of the second device is configured to receive a first FIDO private key from a processor of the first device. The authentication device is configured to sign a first challenge with the received first FIDO key. The authentication device is configured to send the signed first challenge to the relying party device for verification. A processor of the relying party device or server device is configured to verify the signed first challenge. For example, a processor of the relying party device or server device is configured to receive the signed first challenge from the authentication device. For example, the relying party device can verify the signed challenge data with a FIDO public key stored when the user registered with the site. The verification can constitute a result of the authentication process including signature verification. The authentication device may be configured to send the first FIDO key to a processor of the relying party device for verification, and thus the authentication device may be configured to act as an intermediary device between the processor of the first device and the processor of the relying party device.

[0116] At block 640, the method 600 may include evaluating, by the processor, one or more conditions. For example, at least one of the one or more conditions may include determining a threshold number of authentication requests over a predetermined period of time. For example, the processor may be configured to determine whether an abnormal number of transactions or requests have been performed within any number of seconds, minutes, hours, days, weeks, months, years, etc. In another example, at least one of the one or more conditions may include determining whether abuse or fraud has occurred associated with the account and / or user. For example, the processor may be configured to determine whether the user's transaction history indicates excessive purchases or abnormal locations. In this manner, implementing conditional multi-factor authentication may improve security, which may trigger the transmission of a second challenge to receive input data.

[0117] At block 650, the method 600 may include transmitting, by the processor, a second challenge. For example, a processor of the relying party device or the server device may be configured to generate the second challenge. For example, the second challenge may include a second request to transmit the input data. In some examples, the processor of the relying party device or the server device may be configured to evaluate one or more conditions, as described above. In some examples, the second challenge may be transmitted by the processor after evaluation of the one or more conditions.

[0118] In some examples, the authentication device may be configured to receive a second challenge. For example, a processor of the mobile device may be configured to receive a second challenge from a processor of the relying party device or server device after evaluation of one or more conditions by the relying party device or server device. In some examples, the second challenge, such as an application including instructions for execution on the mobile device using one or more push notifications, is forwarded to the authentication device by a processor of the relying party device or server device.

[0119] The authentication device is configured to transmit input data based on the second challenge. For example, a processor or application of the mobile device can be configured to transmit the input data to a relying party device, such as a processor of the server device. The input data can include at least one selected from the group of biometric data and credential data. For example, the input data can include biometric data, credential data, and / or any combination thereof. Without limitation, the biometric data can include at least one selected from the group of fingerprint, face scan, retina scan, voice recognition, and / or any combination thereof. In some examples, the input data can additionally and / or alternatively include credential data. Without limitation, the login data can include at least one selected from the group of input of a username, a password, an account number, a security code, a one-time passcode, an answer to a security question, and / or any combination thereof.

[0120] At block 660, the method 600 may include authenticating, by a processor, the received input data. For example, the processor of the relying party device or server device may be configured to complete the authentication request by authenticating the input data. For example, the processor of the relying party device or server device may be configured to receive the input data from an authentication device, such as a processor or application configuring execution instructions of a mobile device. In some examples, the processor of the relying party device or server device may be configured to generate one or more results by comparing the received input data to reference input data. In some examples, the reference input data may be stored by the relying party device or server device. In other examples, the reference input data may be requested by the relying party device or server device. For example, the processor of the relying party device or server device may be configured to receive the reference input data through one or more requests, or alternatively, to send the input data to a database for comparison with the reference input data. For example, the relying party device or server device may be configured to generate a result indicating successful authentication if the match is successful based on the comparison of the received input data to the reference input data. In another example, the relying party device or server device is configured to generate an authentication failure result if a match fails based on a comparison of the received input data to the reference input data. If authentication is determined to be unsuccessful, the relying party device or server device may be configured to re-authenticate the input data up to a predetermined number of attempts before successfully authenticating the input data, completing the authentication request, or aborting completion of the authentication request. Thus, the authentication process sequence diagram 400 may be implemented using distributed storage, cloud-based storage, and other forms of storage to support the aforementioned functionality.

[0121] Additionally, it should be noted that the systems and methods described herein may be embodied in one or more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, a read-only memory (ROM), a random access memory (RAM), and other physical media capable of storing data. For example, a data storage device may include a random access memory (RAM) or a read-only memory (ROM) configured to access and store data, information, and computer program instructions. A data storage device may also include a storage medium or other suitable type of memory (e.g., RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, flash drive, any type of tangible and non-transitory storage medium, etc.) in which an operating system, application programs, including, for example, a web browser application, an email application, and / or other applications, and files constituting data files are stored. Data storage in a network-enabled computer system includes electronic information, files, and documents stored in a variety of ways, where the data storage devices include, for example, flat files, index files, hierarchical databases, relational databases, such as databases created and managed by software such as Oracle Corporation, Microsoft Excel files, Microsoft Access files, and the like, and the data storage devices are enterprise storage devices including solid state storage devices such as flash arrays, hybrid arrays, server appliance side products, online storage devices, cloud storage devices, and other storage mechanisms. Additionally, the figures show various components (e.g., server appliances, computers, processors, etc.) separately.The functions described as being performed by various components may be performed by other components, the various components may be combined or separated, and other variations are possible.

[0122] In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will be apparent, however, that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broad scope of the invention as defined in the claims which follow. The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. An authentication device comprising a memory and a processor, The processor is configured to: receive one or more challenges; generate a first instruction, the first instruction including a request to obtain a first FIDO (Fast Identity Online) key; The processor is further configured to: send the first instruction; receive the first FIDO key; sign one or more challenges using the first FIDO key; and send one or more signed challenges for verification using a second FIDO key.

2. The first instruction includes a request to generate a first FIDO key. The authentication device according to claim 1.

3. The first key is generated based on an identifier associated with a master key and an authentication request using one or more cryptographic algorithms. The authentication device according to claim 2.

4. The first FIDO key is transmitted via an out-of-band channel. The authentication device according to claim 1.

5. The first instruction includes a request to regenerate the first FIDO key. The authentication device according to claim 1.

6. The one or more challenges are received based on an authentication request for FIDO website registration. The authentication device according to claim 1.

7. The processor is further configured to receive input data including at least one selected from a group of biometric data and credential data. The authentication device according to claim 1.

8. The first FIDO key is obtained by input of a communication interface to a communication field, The authentication device according to claim 1.

9. The input data is transmitted after determination of one or more conditions, The authentication device according to claim 7.

10. An authentication method, The authentication method includes, a processor receiving one or more challenges, the processor generating a first instruction including a request to obtain a first FIDO (Fast Identity Online) key, the processor transmitting the first instruction, the processor receiving the first FIDO key, the processor signing one or more challenges using the first FIDO key, the processor transmitting one or more signed challenges for verification using a second FIDO key, An authentication method including the above.

11. The first instruction includes a request to generate the first FIDO key, The method according to claim 10.

12. The first FIDO key is generated based on a third key and an identifier associated with an authentication request using one or more encryption algorithms, The method according to claim 11.

13. Further including transmitting the first FIDO key via an out-of-band channel, The method according to claim 10.

14. The first instruction includes a request to regenerate the first FIDO key, The method according to claim 10.

15. The one or more challenges are received based on an authentication request for FIDO website registration, The method according to claim 10.

16. The method further comprising the processor receiving input data including at least one selected from the group of biometric data and credential data, The method according to claim 10.

17. The first FIDO key is obtained by input of a communication interface to a communication field, The method according to claim 10.

18. The input data is transmitted after determination of one or more conditions, The method according to claim 16.

19. At least one condition includes determining a threshold number of authentication requests over a predetermined period, The method according to claim 18.

20. A computer-readable non-transitory medium including computer-executable instructions, When the instructions are executed on a processor, they execute a procedure including predetermined steps, The steps are, Receiving one or more challenges; Generating a first instruction including a request to obtain a first FIDO (Fast Identity Online) key; Sending the first instruction; Receiving the first FIDO key; Signing one or more challenges using the first FIDO key; Sending one or more signed challenges for verification using a second FIDO key; A computer-readable non-transitory medium including

Images