First-element contactless card authentication system and method

Abstract

This system and method provides a passwordless authentication system that enhances application security by storing the username on a card without requiring user input, thereby restricting access to and knowledge of login credentials, and reduces the possibility of malicious access by using dynamic passwords. [Solution] The method includes registering a client's contactless card with an application service and binding the contactless card to one or more client devices. The contactless card conveniently stores a username and a dynamic password. Client access to the application service is performed using any client device, and authentication of access is performed by any client device that includes a contactless card interface and can retrieve a username and dynamic password pair from the contactless card.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 519,079, entitled "First Element Non-Contact Card Authentication System and Method," filed on July 23, 2019. The entire contents of the foregoing application are incorporated herein by reference in their entirety.

Background Art

[0002] Many service providers use the Internet to offer offerings to potential or current customers. Offerings are typically provided in the form of software applications that operate using the service provider's dedicated resources.

[0003] Many application services store highly confidential client content such as account numbers, personal information, purchase history, passwords, social security numbers, etc. To limit unauthorized access to highly confidential customer content, service providers need to implement authentication controls.

[0004] Many authentication controls verify the client based on some combination of elements including a knowledge element (what the client knows), a possession element (what the client has), and an inherent element (who the client is). The knowledge element may include a password, partial password, passphrase, or personal identification number (PIN), challenge response (where the user needs to answer a question or pattern). The possession element may include what the client owns (e.g., a wristband, ID card, security token, embedded device, mobile phone with a hardware token incorporated, software token, or mobile phone holding a software token). The inherent element may be related to the user himself or what the user is doing (e.g., fingerprint, retina pattern, DNA sequence, signature, face, voice, unique bioelectrical signal, or other biometric identifier).

[0005] Access to service provider information and services is typically controlled through layered security protocols designed to protect sensitive and critical information using multi-factor authentication technologies. Despite such efforts, service provider systems remain vulnerable to phishing, man-in-the-middle attacks, and other malicious attacks, particularly during username / password exchange. These are specific targets for hackers who understand the tendency of users to use the same password across multiple platforms. Encrypting passwords, while it may impair, does not eliminate the ability of malicious actors to interfere with client accounts. [Overview of the project]

[0006] According to one aspect of the present invention, a method for authorizing a client's access to an application includes the steps of: receiving a request from a first client device to access the application; identifying the client associated with the first client device; verifying the authenticity of the request by forwarding a notification of the request to a second client device associated with the client; and receiving a response from the second client device, the response including authentication information including a username and dynamic password obtained by the second client device from a contactless card associated with the client. The method also includes comparing the username and dynamic password obtained by the second client device with the client's expected username and expected dynamic password. The method also includes authenticating the request and launching the application on the first client device in response to a match between the username and the expected username and dynamic password and the expected dynamic password. The method also includes updating and storing the dynamic password associated with the client. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method.

[0007] In another embodiment, a system for controlling client access to an application includes a processor and an interface configured to receive authentication requests from a second client device associated with a client and authenticate access requests made by a first client device associated with the client to access the application, wherein the authentication request includes a ciphertext provided to the second client device by a contactless card, the ciphertext including a username and a dynamic password; a non-temporary storage medium including a client table including at least one entry for at least one client, the at least one entry including an expected username and an expected dynamic password for the client; and program code stored in the non-temporary storage medium and operable when executed by the processor. The system also includes selectively approving authentication requests in response to a first match between a username and an expected username, and a second match between a dynamic password and an expected dynamic password. The system also includes updating the expected dynamic password for the client in response to the approval of the authentication request. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operation of the method.

[0008] In a further embodiment, a method for authorizing a client's access to an application includes: verifying the authenticity of a request by forwarding a notification of the request to a second device associated with the client, which includes receiving a request for access to the application from a first device associated with the client; identifying the client associated with the first device; and generating a prompt to be displayed on the second device requesting an authentication input from the client; and receiving an authentication input from the second device, wherein the authentication input includes one or more of a biometric input, a query input, and a contactless card ciphertext token input including a username and dynamic password obtained by the second device from a contactless card associated with the client. The method also includes comparing the authentication input to an expected authentication input from the client. The method also includes enabling the first device to access the application in response to a match between the authentication input and the expected authentication input. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operation of the method.

[0009] In another embodiment, a method for launching an application hosted by a service provider includes the steps of registering a client with the application and binding a contactless card to the client. In one embodiment, binding a contactless card to a client may include obtaining a ciphertext from the contactless card containing a username and a dynamic password, authenticating the username and dynamic password pair, associating the username and dynamic password pair with the client, and storing the client's username and dynamic password pair in memory. The method further includes updating the client's application interface to provide a contactless card login option as part of a modified application interface.

[0010] In a further embodiment, a system for launching an application includes one or more coupled client devices, a storage device, and a client interface adapted to exchange information with a table stored in the storage device, which has entries for at least one client. The entries include the client's card identifier and dynamic card password. The system includes an authentication unit coupled to the client interface and the table, which selectively authenticates the client in response to a comparison between the card identifier and dynamic card password stored in the table and the authentication card identifier and authentication password obtained from the client's contactless card. The system may also include application launch control coupled to the authentication unit and configured to selectively launch an application for the client in response to the client's selective authentication.

[0011] In another embodiment, a method for launching an application includes the step of displaying a number of login options to a user operating a client device, the number of login options including a contactless card login option. The method includes, in response to the selection of a contactless card login option, prompting the user to engage a contactless card with the client device and retrieve an encoded ciphertext from the contactless card's storage device, the encoded ciphertext comprising a username and a dynamic password, and transferring the encoded ciphertext to an authorization server so that the username and dynamic password can be compared with a username and password expected for selective authentication. The method includes the step of receiving an authentication result from the authorization server and selectively launching an application in response to the authentication result.

[0012] Such arrangements allow contactless card ciphertext exchange, which provides dual-factor verification on its own (such as username knowledge, dynamic passwords, contactless card ownership, and mobile device), to be used as the first-factor authentication mechanism in a hierarchical security protocol, thus reducing the likelihood of sensitive client information being misused during client / server communication. [Brief explanation of the drawing]

[0013] [Figure 1] This is a block diagram of a data transmission system configured to pre-authenticate customer requests according to an exemplary embodiment. [Figure 2] This figure shows a sequence for providing authenticated access according to an exemplary embodiment. [Figure 3] Figure 1 shows an example of a contactless card for storing authentication information that may be used in the system. [Figure 4] Figure 3 is a detailed block diagram showing exemplary components of a contactless card. [Figure 5] Figure 1 shows an example of the fields in a message exchanged between a contactless card and a client device. [Figure 6] This is a detailed block diagram of the components of the system shown in Figure 1A, which may be used to support embodiments of the present invention. [Figure 7] This data flow diagram is provided to illustrate exemplary steps that may be performed to register a client, one or more client devices, and / or a contactless card in order to enable first-factor authentication of a contactless card, as described herein. [Figure 8] This data flow diagram is provided to illustrate exemplary embodiments of a system and method for secure passwordless login using a username / dynamic password pair provided as part of ciphertext exchange between a contactless card and a client device. [Figure 9]This specification shows exemplary user interface elements that may be provided on various client devices to support the embodiments disclosed herein. [Figure 10] This specification illustrates exemplary user interface elements that may be provided on various client devices during the passwordless login process disclosed herein. [Figure 11A] This shows exemplary user interface elements that can enable two-factor authentication for launching applications that use a device. [Figure 11B] This shows exemplary user interface elements that can enable two-factor authentication for launching applications that use a device. [Modes for carrying out the invention]

[0014] Passwordless login protocols allow service providers to authenticate clients without requiring them to enter a password. For example, passwordless email-based or text-based systems use an email / text address and a complex encrypted key code to verify the user's identity. Public key authentication is another method for implementing passwordless login. Passwordless login methods using public key authentication are supported by the Fast ID Online (FIDO) Alliance. FIDO defines various authentication standards, including the Universal Second Factor (U2F) protocol. The U2F protocol uses strong second-factor authentication, such as Near Field Communication (NFC) taps or USB security tokens. Users are asked to insert and touch their personal U2F device during login. The user's FIDO-enabled device creates a new key pair, and the public key is shared with the online service and associated with the user's account. The service can then authenticate the user by requiring the registered device to sign a challenge using the private key. While the U2F protocol offers improved security compared to password-based methods, the use of static secret keys for authentication, even when encrypted, is a weakness of the entire U2F security protocol.

[0015] In one embodiment, the improved passwordless authentication protocol actually applies a contactless card ciphertext exchange protocol as a first-factor authentication mechanism to facilitate access to application services without sacrificing the security of the application services.

[0016] In one embodiment, the contactless card comprises a credit card-sized card including an embedded integrated circuit, a storage device, and an interface that enables the card to communicate with a transmitting device using a Near Field Communication (NFC) protocol. An exemplary contactless card that may be used herein includes the one described herein by reference to Osborn et al., U.S. Patent Application No. 16 / 205,119, entitled “System and Method for Cryptographic Authentication of Contactless Cards,” filed November 29, 2018 (hereinafter, the '119 application). The contactless card may be configured to exchange ciphertext as part of an NFC exchange.

[0017] The improved passwordless protocol includes registering a client's contactless card with an application service, binding the contactless card to the client, and performing first, second, and / or other authentication of the client access request by the application service using the cryptographic exchange protocol described in '119'. In one embodiment, the contactless card may include memory comprising one or more applets, a counter value, a plurality of keys, and one or more processors configured to increment the counter value for each ciphertext exchanged with the service provider. The contactless card may be configured to create a ciphertext using the plurality of keys and the counter value and to transmit the ciphertext to a receiving device via a communication interface such as a Near Field Communication (NFC) interface. In one embodiment, the ciphertext may comprise the client's username or other identifier. In various embodiments, the username may be automatically generated for the client or may be defined by the client. In various embodiments, the username may be embedded in the contactless card before it is delivered to the client, or may be loaded or embedded in the contactless card as part of the registration process by the service provider. In some embodiments, the username may be hashed or encrypted using one or more hash functions, symmetric encryption algorithms, and / or keys provided by the contactless card.

[0018] According to another aspect, the ciphertext may include a dynamic password that can be used in combination with a username to perform the first element authentication of the client when accessing the application service. In one embodiment, the dynamic password includes a ciphertext counter, and thus the dynamic password is related to the number of ciphertexts exchanged between the client and the application service, that is, the number of times the username is obtained from the contactless card. In such a configuration, the unpredictability of the dynamic password enhances the certainty of the client's reliability, thereby strengthening the security of client / server communication.

[0019] According to one aspect, binding a contactless card to a client includes associating the card with digital qualification information and / or the client device. The association between the card and the client's digital qualification information may occur as part of the client's initial registration with the service provider (i.e., the client's first access to the application service), or instead, before delivering the contactless card to the client. In one embodiment, at least one client device includes an interface for communicating with the contactless card. When the contactless card is bound to a client device having a contactless card interface, the client access to the application service registered on any web-connected device can be authenticated using the contactless card ciphertext exchange executed on a known client device. For example, the contactless card / mobile device ciphertext exchange can be used to authenticate the access request of the client to the service provider on the mobile device or other web-based devices.

[0020] In one embodiment, the application service client interface may be configured to propose or mandate the use of a ciphertext exchange authentication method for application service access. The ciphertext exchange protocol provides two-factor authentication (i.e., knowledge of a username and a dynamic password, and possession of a contactless card and / or a client device), and due to the unpredictability of the dynamic password, the function of using the disclosed protocol as a first-factor authentication method may satisfy clients seeking highly secure passwordless authentication.

[0021] These and other features of the present invention are described with reference to the figures, and like reference numbers are used throughout to refer to like elements. Referring generally to the notation and nomenclature used herein, the following detailed description may be presented with respect to program processes executed on a computer or a network of computers. The description and representation of these processes are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0022] A process is herein, generally considered to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily always, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. For primarily reasons of common usage, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, and so forth. However, it should be noted that all of these and similar terms are merely convenient labels associated with appropriate physical quantities and are nothing more than labels applied to these quantities.

[0023] Furthermore, the operations performed are often referred to in terms such as addition or comparison, and these are generally associated with intelligent calculations performed by human operators. In any of the calculations described herein, forming part of one or more embodiments, such ability of a human operator is neither necessary nor, in most cases, desirable. Rather, the calculations are machine calculations. Useful machines for performing the calculations of various embodiments include general-purpose digital computers or similar devices.

[0024] Various embodiments also relate to apparatus or systems for performing these operations. Such apparatus may be specifically constructed for a required purpose, or may comprise a general-purpose computer that is selectively invoked or reconfigured by a computer program stored within the computer. The processes presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus for performing the required method steps. The necessary structures for these various machines will become apparent from the given description.

[0025] Here, we refer to the drawings. Similar reference numbers are used throughout to refer to similar elements. In the following description, many specific details are shown for explanatory purposes and to provide a complete understanding. However, it may be obvious that novel embodiments can be implemented without these specific details. In other examples, well-known structures and devices are shown in block diagram form to facilitate their description. The intent is to cover all modifications, equivalents, and alternatives that are consistent with the claimed subject.

[0026] Figure 1 shows a system 100 including one or more client devices 110 connected to a service provider 120 via a network 115. In one embodiment, the client device 110 comprises a network-enabled computer and communicates with the service provider 120 via networks 115 and 125 to access the service provider's content and services.

[0027] As referred to herein, a network-enabled computer may include, but is not limited to, computer devices, or communication devices, such as servers, network appliances, personal computers (PCs), workstations, mobile devices, telephones, handheld PCs, personal digital assistants (PDAs), thin client devices, fat client devices, internet browsers, or other devices.

[0028] Therefore, the client device 110 may include a processor and memory, and it is understood that the processing circuit may include additional components, including a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and tamper-proof hardware, in order to perform the functions described herein. The client device 110 may further include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input device may include any device for inputting information available and supported on the user's device into the user's device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0029] One or more client devices 110 may be mobile devices such as, for example, Apple's iPhone®, iPod®, iPad®, or other mobile devices running Apple's iOS® operating system, devices running Microsoft's Windows® mobile operating system, and / or other smartphones or similar wearable mobile devices.

[0030] The various client devices 110 in Figure 1 include a mobile phone 142, a laptop 144, a tablet 148, and a terminal 146. The client device 110 may include a thin client application specifically adapted for communication with a service provider 120. The thin client application is stored in the client device's memory and is operational when run by the client device. It may control the interface between the client device and the service provider application, allowing the user of the client device to access the service provider's content and services.

[0031] In some examples, network 115 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect client devices 110 to a service provider 120. For example, network 115 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless local area networks (WLANs), global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, 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, etc.

[0032] Furthermore, network 115 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks ("WAN"), wireless personal area networks ("WPAN"), local area networks ("LAN"), or global networks such as the Internet. Additionally, network 115 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 115 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 115 may utilize one or more protocols of one or more network elements that are communicatively coupled together. Network 115 may convert from one or more protocols to one or more protocols of network devices, or from one or more protocols to another.

[0033] It should be understood that, as one or more examples show, network 115 may be part of multiple interconnected networks, such as the Internet, a service provider's private network 125, a cable television network, a corporate network such as a credit card association network or a home network. Furthermore, private network 125 may be implemented as a layered virtual private network on top of network 115.

[0034] In one embodiment, the service provider 120 is a business that provides computer-based services to clients via the network 115. The combination of software and hardware that provides the service provider's specific services to clients is referred to here as a “server.” The servers may communicate via the service provider’s private network 125, which is often referred to as a corporate network or enterprise network. The private network 125 may comprise a wireless network, a wired network, or any combination of wireless and wired networks, as described above with respect to the network 115.

[0035] Software services can be embodied in applications that run on electronic devices, such as desktop applications that run on the operating system of a computing device, mobile applications that run on the mobile operating system of a mobile device, or web applications that run on the browser component of either a mobile or desktop operating system. Those skilled in the art will understand how to design, build, and deploy software applications on any type of electronic device. In some embodiments, the application may be a browser application running on the device's operating system.

[0036] In the system shown in Figure 1, the service provider 120 is shown to include an application server 150 and an authentication server 160. Although each server is shown as a separate device, it is understood that applications and servers may be distributed across the enterprise, or, in the case of distributed resources such as “cloud” resources, they may be distributed across the network 115. The application server 150 may support one or more application services provided by the service provider 120, for example, an account management service. In one embodiment, the authentication server 160 may be configured to provide one or both of first-factor authentication and second-factor authentication using contactless cards, as disclosed in more detail below.

[0037] The database 130 comprises data storage resources that can be used to store customer accounts, credentials, and other authentication information, including dynamic password data, for use by, for example, the application server 150 and the authentication server 160. The database 130 may consist of combined data resources comprising any combination of local storage, distributed data center storage, or cloud-based storage, the data resources comprising non-transient, tangible storage media that do not contain carrier waves or propagating data signals.

[0038] In one embodiment, the contactless card 105 may communicate wirelessly with one or more client devices 110, for example, via Near Field Communication (NFC). For example, the contactless card 105 may include one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 105 may communicate with the client devices 110 via other means, including but not limited to Bluetooth®, satellite, and / or Wi-Fi. As described in the 119th application, the contactless card 105 may be configured to communicate via NFC with one of a card reader terminal 146, a mobile phone 142, a laptop 144, and / or a tablet 148 when the contactless card 105 is within range of the respective client device. As will be described in more detail below, the contactless card 105 may include username, key, and counter information that can be translated using an encryption algorithm to generate a ciphertext containing a dynamic password that can be used by a service provider to authenticate client devices.

[0039] As described above, according to one embodiment, the first factor authentication may be performed by exchanging a username and a dynamic password as part of a ciphertext communication as described in the '119 application. Next, an exemplary ciphertext exchange system and method will be described with reference to Figures 2 to 5.

[0040] Figure 2 is a data flow diagram illustrating an exemplary workflow for authenticating client access to a service provider application according to various embodiments disclosed herein. In Figure 2, the client device 110 is shown to include an application 122 and a processor 124. In one embodiment, the application may include, for example, a client-side applet comprising program code that is operable when executed by the processor 124 to control the interface between the client device 110 and the service provider application hosted by a server on the service provider network.

[0041] In step 102, application 122 communicates with contactless card 105 (for example, after being brought close to contactless card 105). Communication between application 122 and contactless card 105 may include contactless card 105 being close enough to the card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0042] In step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a Message Authentication Code (MAC) ciphertext according to the NFC Data Exchange format. In some examples, this may occur when the contactless card 105 is read by application 122 in response to application 122 issuing a read request for a Near Field Radio Data Exchange (NDEF) tag stored on the contactless card. At this point, a counter value maintained by the contactless card 105 may be updated or incremented, and the contactless card may generate a message containing a header, payload, and shared secret. According to one embodiment, the payload may contain the client's username, and the shared secret may contain a dynamic password used to authenticate the client. The MAC ciphertext may be constructed from the message, which may contain the header, payload, and shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random numbers (RND) may be encrypted with a session key. Subsequently, the ciphertext and header may be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to the "Read NDEF file" message).

[0043] In some cases, the MAC ciphertext may be transmitted as an NDEF tag, while in other cases, the MAC ciphertext may be included with a uniform resource indicator (e.g., as a formatted string).

[0044] In some examples, application 122 may be configured to send a request to contactless card 105, the request comprising instructions for generating a MAC ciphertext.

[0045] In step 106, the contactless card 105 transmits the MAC ciphertext to the application 122. In some examples, the transmission of the MAC ciphertext is performed via NFC. However, this disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth®, Wi-Fi, or other wireless data communication means.

[0046] In step 108, application 122 communicates the MAC ciphertext to processor 124.

[0047] In step 112, the processor 124 verifies the MAC ciphertext according to instructions from application 122. For example, the MAC ciphertext may be verified as described below.

[0048] In some examples, MAC ciphertext verification may be performed by a device other than the client device 110, such as a service provider 120 in data communication with the client device 110 (as shown in Figure 1). For example, processor 124 may output MAC ciphertext for transmission to the authentication server 160 of service provider 120, which can then verify the MAC ciphertext.

[0049] In one embodiment, first-factor security authentication may prompt a user to perform one or more actions associated with one or more contactless cards. In effect, security factor authentication prompts a user to engage in one or more types of actions, including but not limited to one or more tap gestures associated with contactless cards. In some examples, one or more tap gestures may involve the user tapping a contactless card on a device. One or more tap gestures may be used to exchange ciphertext containing a username and a dynamic password for the purpose of authenticating a client access request at a service provider.

[0050] In one embodiment, as will be described in more detail below, the contactless card includes cryptographic processing capabilities that can be used to generate ciphertext containing a username, key, counter, and a dynamic password which can be used to verify the user of the client device along with the username. In one embodiment, the dynamic password is related to a counter. Thus, in such an embodiment, the dynamic password favorably reflects the cardholder's previous behavior. For example, a counter-based dynamic password may reflect the number of times the user has previously accessed a particular service of a service provider, and is a knowledge element that is virtually impossible for a malicious third party to grasp.

[0051] Figure 3 shows one or more contactless cards 300, which may include payment cards such as credit cards, debit cards, or gift cards issued by a service provider 305, with identification information displayed on the front or back of the card 300. In some examples, the contactless card 300 may be an identification card or passport unrelated to a payment card, but is not limited to these. In some examples, the payment card may be a dual-interface contactless payment card. The contactless card 300 may include a substrate 310 which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical properties conforming to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, please understand that the contactless card 300 described herein may have different characteristics, and that this disclosure does not require contactless card functionality for payment cards.

[0052] The contactless card 300 may also include identification information 315 displayed on the front and / or back of the card, and a contact pad 320. The contact pad 320 may be configured to establish contact with a user device, a smartphone, a laptop, a desktop, or a tablet computer or other communication device. The contactless card 300 may also include processing circuits, an antenna, and other components not shown in Figure 3. These components may be located behind the contact pad 320 or elsewhere on the substrate 310. The contactless card 300 may also include a magnetic strip or tape (not shown in Figure 3) that may be located on the back of the card.

[0053] As shown in Figure 4, the contact pad 420 may include processing circuitry for storing and processing information, including a microprocessor 430 and memory 435. It is understood that the processing circuitry may include additional components necessary to perform the functions described herein, such as the processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and tamper-proof hardware.

[0054] Memory 435 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and contactless card 400 may include one or more of these memories. Read-only memory may be programmable at the factory as read-only or one-time programmable. One-time programming allows it to be written once and read multiple times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritable but can be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

[0055] The memory 435 may be configured to store one or more applets 440, one or more counters 445, and customer information 450. Each of the one or more applets 440 may be associated with one or more service provider applications and comprise one or more software applications configured to run on one or more contactless cards, such as Java card applets. In one embodiment, each applet may store a username 402 for a client to access the service provider application associated with the applet.

[0056] One or more counters 445 may comprise numeric counters sufficient to store integers. Customer information 450 may comprise a unique alphanumeric identifier assigned to a user of a contactless card 400, and / or one or more keys that can be used together to distinguish a contactless card user from other contactless card users. In some examples, customer information 450 may include information that identifies both the customer and the account assigned to that customer, and further may identify the contactless card associated with the customer's account. According to some embodiments, a username 442 may be derived from a combination of one or more customer information 450 and / or one or more keys.

[0057] The processor and memory elements of the exemplary embodiments described above are described with reference to the contact pads, but the disclosure is not limited thereto. It is understood that these elements may be implemented as additional elements in addition to the microprocessor 430 and memory 335 elements, either outside the pads 420, completely separate from the pads 420, or located within the contact pads 420.

[0058] In some examples, the contactless card 400 may include one or more antennas 425 positioned around the processing circuit 455 of the contact pads 420 within the contactless card 400. For example, one or more antennas may be integrated with the processing circuit, or one or more antennas may be used in conjunction with an external booster coil. In other examples, one or more antennas may be located outside the contact pads 420 and the processing circuit.

[0059] As described above, the contactless card 400 can be built on a software platform capable of running on smart cards or other devices that have program code, processing power, and memory, such as a Java card. An applet can be added to the contactless card to generate one-time passwords (OTPs) for multi-factor authentication (MFA) in a variety of mobile application-based use cases. The applet can be configured to respond to one or more requests, such as a Near Field Communication (NDEF) request from a reader, such as a mobile Near Field Communication (NFC) reader, and generate an NDEF message with a cryptographically secure OTP encoded as an NDEF text tag. Thus, the functionality of the contactless card is adapted to provide a unique one-time password as part of a Near Field Communication, as described below.

[0060] Figure 5 shows an exemplary NDEF short record layout (SR=1) 500 according to an exemplary embodiment. NDEF messages provide a standardized way for a client device 110 to communicate with a contactless card 105. In some examples, an NDEF message may comprise one or more records. An NDEF record 500 includes a header 502 containing several flags that define how to interpret the rest of the record, including a message start (MB) flag 503a, a message end (ME) flag 503b, a chunk flag (CF) 503c, a short record (SR) flag 503d, an ID length (IL) flag 503e, and a type name format (TNF) field 503f. The MB 503a and ME flags 503b may be set to indicate the first and last records, respectively, of the message. The CF 503c and IL flags 503e provide information about the record, including whether the data is a "chunk" (data distributed across multiple records in the message) or whether the ID type length field 508 is relevant, respectively. If a message contains only one record, the SR flag 503d may be set.

[0061] The TNF field 503f identifies the type of content the field contains, as defined by the NFC protocol. These types include empty well-known (data as defined in the NFC Forum Record Type Definitions (RTDs)), Multipurpose Internet Mail Extension (MIME) [as defined in RFC2046], Absolute Uniform Resource Identifier [as defined in RFC3986], External (user-defined), Unknown, Unmodified [for chunks], and Reserved.

[0062] Other fields in an NFC record include Type Length 504, Payload Length 506, ID Length 508, Type 510, ID 512, and Payload 514. The Type Length field 504 specifies the exact type of data found in the payload. Payload Length 506 contains the length of the payload in bytes. A record can contain up to 4,294,967,295 bytes (or 2^32-1 bytes) of data. ID Length 508 contains the length of the ID field in bytes. Type 510 identifies the type of data contained in the payload. For example, for authentication purposes, Type 510 may indicate that the payload contains a username / password pair. The ID field 512 provides a means for an external application to identify the entire payload transmitted within the NDEF record. Payload 514 contains the message.

[0063] In some embodiments, data may be initially stored on the contactless card by performing STORE DATA(E2) under a secure channel protocol. This data may include a unique personal user ID (pUID) or other username on the card, and encryption processing data including one or more initial keys, session keys, data encryption keys, random numbers, and other values ​​described in more detail below. In other embodiments, the pUID or other username may be pre-loaded onto the contactless card before it is delivered to the client. In some embodiments, the username may be automatically generated by the service provider.

[0064] In some embodiments, a unique username may be provided to each service provider applet / service. In some embodiments, the username is automatically generated by the service provider and is unknown to the client. In other embodiments, the username may be selected by the client as part of a registration process using the service provider application and downloaded to the contactless card as part of the registration process. Thus, the username may consist of any combination of automatically generated or predefined data stored in the applet or other part of the contactless card's memory, including a pUID, being a distinct value, and / or being encrypted or encoded using the contactless card's hash value or key.

[0065] For example, each of the client and the authentication server may use one or more hash algorithms, including but not limited to the SHA-2 algorithm, for encoding usernames. Alternatively, the encryption algorithm that may be used to encrypt / decrypt usernames and / or ciphertext payloads may be selected from a group including at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. Non-exclusive examples of symmetric algorithms that may be used to encrypt usernames and / or encryptions may include symmetric encryption algorithms such as 3DES (Triple Data Encryption Algorithm) or Advanced Cryptographic Standard (AES) 128, symmetric hash-based message authentication (HMAC) algorithms such as HMAC-SHA-256, and symmetric cryptography-based message authentication code (CMAC) algorithms such as AES-CMAC. Many forms of encryption are known to those skilled in the art, and it will be understood that this disclosure is not limited to those specifically identified herein.

[0066] Following initialization, both the contactless card, the client device applet, and / or the authentication server store information for uniquely identifying the cardholder through the username / dynamic password authentication process described herein.

[0067] Figure 6 shows a communication system 600 in which a contactless card 610 may store information that can be used during first-factor authentication. As described with respect to Figure 4, each contactless card may include a microprocessor 612 and memory 616 for customer information 618, which includes one or more uniquely identifying attributes such as an identifier, key, random number, etc. In one embodiment, the memory further includes an authentication applet 617 that is operable when executed by the microprocessor 612 to control the authentication process described herein. As described above, the username 618 may be stored as part of the applet and / or as part of the customer information 618. Furthermore, each card 610 may include one or more counters 614 and an interface 615. In one embodiment, the interface operates NFC or other communication protocol.

[0068] The client device 620 includes a contactless card interface 625 for communicating with a contactless card and one or more other network interfaces (not shown) that enable the device 620 to communicate with a service provider using various communication protocols as described above. The client device may further include a user interface 626 which may include one or more of a keyboard or touchscreen display that enables communication between a service provider application and a user of the client device 620. The client device 620 further includes a processor 624 and a memory 622 that stores information and program code that controls the operation of the client device 620 when executed by the processor, and includes, for example, a client-side application 623 that may be provided to the client by the service provider to facilitate access to and use of the service provider application. In one embodiment, the client-side application 623 includes program code configured to communicate authentication information, including a username and dynamic password from a contactless card 610, to one or more services provided by the service provider. The client-side application 623 may be controlled via input received by a service provider (SP) application interface 627 displayed on the user interface 626. For example, a user may launch a client-side application and access an SP application service by selecting an icon, link, or other mechanism provided as part of the SP application interface 627, and part of the launch may include verifying the client using ciphertext exchange.

[0069] In an exemplary embodiment, the ciphertext exchange includes a transmitting device having a processor and memory, the transmitting device's memory containing a master key, transmission data, and a counter value. The transmitting device communicates with a receiving device having a processor and memory, the receiving device's memory containing the master key. The transmitting device may be configured to generate a diversified key using the master key and one or more encryption algorithms, store the diversified key in the transmitting device's memory, generate an encrypted counter value by encrypting the counter value using one or more encryption algorithms and the diversified key, generate encrypted transmission data by encrypting the transmission data using one or more encryption algorithms and the diversified key, and send the encrypted counter value and encrypted transmission data to the receiving device as ciphertext. The receiving device may be configured to generate a diversified key based on the stored master key and the stored counter value, store the diversified key in the receiving device's memory, and decrypt the encrypted ciphertext (containing an encrypted counter and encrypted transmission data) using one or more decryption algorithms and the diversified key. The receiving device may authenticate the transmitting device in response to a match between the decrypted counter and the stored counter. Next, counters may be incremented on both the sending and receiving devices for subsequent authentication, thereby providing a ciphertext-based dynamic authentication mechanism for the sending / receiving device transactions.

[0070] As described with respect to Figure 1, the client device 620 may be connected to various services of the service provider 605 and managed by the application server 606. In the illustrated embodiment, the authentication server 605 and the application server 606 are shown as separate components, but it should be understood that the application server may include all the functions described as being included in the authentication server.

[0071] The application server 606 is shown to include an interface 607 and application program code 608. The interface may include a network interface programmed to communicate with other network members via network 630 using network protocols, and application program code 608 stored in the non-temporary storage of the application server 606 and operable when executed by the central processing unit (CPU 609) to perform the functions described herein.

[0072] The authentication server 650 is shown to include a network interface 653 for communicating with network members via the network 630 and a central processing unit (CPU) 659. The authentication server may include a non-temporary storage medium for storing a client information table 652 containing information relating to the service provider's clients. Such information may include, but is not limited to, the client's username, the client's personal identifier, and the client's ciphertext keys and counters. In one embodiment, the authentication server further includes a client counter value table 656 which may be used to perform authentication in conjunction with a contactless card 610, as described below. The authentication unit 654 includes hardware and software for performing various authentication processes for clients using information from tables 652 and 656, as described with reference to Figures 7 and 8.

[0073] Figure 7 illustrates various steps of a setup process 700 that may be performed to enable passwordless login to an application service using ciphertext exchange. In step 710, the client's contactless card is registered with the application service. Registration may be performed online, offline, or a combination thereof. As part of registration, the client's username may be stored in the client information database of either the application server or the authentication server. In some embodiments, the client's username may be automatically generated by the service provider and not disclosed to the client, and may be loaded into both the service provider's client information table and the applet downloaded to the contactless card before or after the contactless card is delivered to the client. In an alternative embodiment, the client may be informed of the username and / or self-select a username to be stored on the contactless card. The self-selected username may be written to the contactless card using the NFC interface described above. Such self-selection may instead occur when registering the card with the application service or as part of the process of issuing the contactless card to the client, with the self-selected password embedded in the contactless card when it is delivered to the client.

[0074] While there may be advantages to allowing clients to self-select or recognize their usernames, knowledge of usernames is not a requirement for the passwordless authentication protocols described herein, as username and dynamic password information are communicated electronically between the card, NFC-enabled device, and application server without client intervention. Such arrangements mitigate the risks associated with malicious eavesdropping on username / password authentication schemes.

[0075] In step 720, the contactless card is bound to the client. Specifically, the contactless card's username, pUID, etc., are stored as part of the service provider's client digital identity. The digital identity may include, for example, single sign-on (SSO) information, profile reference identifiers, or other client identifiers.

[0076] In step 730, once the card is registered with the client, the client-card combination may be bound to one or more client devices. For example, the digital identity may also include client device information such as a unique identifier associated with the user device (e.g., telephone number, Internet Protocol (IP) address, network identifier, mobile device identifier (MEID), international subscriber identification number (IMSI), serial number, media access control (MAC) address, etc.), and application information related to the application used to capture the image (e.g., identifier of the application instance, application version of the application, session identifier, etc.).

[0077] Once triangulation between the client, card, and client device is established, step 740 may support multi-factor secure passwordless login for client applications running on any client device using a contactless card. More generally, multi-factor secure passwordless login for client application access may be provided using ciphertext exchange, which includes encrypted usernames and dynamic passwords.

[0078] As an example, Figure 8 is a data flow diagram provided to illustrate an exemplary embodiment of a system and method for secure passwordless login using a username / dynamic password pair provided as part of ciphertext exchange between a contactless card and a client device. In this example, the application server receives an application launch request from the client by allowing the client to access the application via a web browser application by selecting an access option on a website associated with the application supported by the application server.

[0079] In the embodiment shown in Figure 8, the client, contactless card, and client device are pre-registered with the application using the same method as described with respect to Figure 7, and a user of web device 810 requesting access to the application utilizes this association by selecting the contactless card authentication option on the application login page displayed on web device 810. As a result, the contactless card authentication request is forwarded to the application server 820 in step 801.

[0080] The application server may use the information contained in the request to identify a client sourcing an access request that includes, but is not limited to, cookie data stored by a browser on the web device 810 during a previous access to the application, such as when the client registers with the application, based on, for example, the IP or MAC address of the web device or other device identification attributes of the application access request.

[0081] Upon receiving a startup request, the application server 820 may obtain client device information associated with the client, including, for example, the identification of one or more client devices (such as client NFC-enabled device 830) that include authentication hardware supporting contactless card ciphertext exchange (including, but not limited to, components shown within client device 620).

[0082] In some embodiments, the web device 810 and the client NFC-enabled device 830 may be the same device. In other embodiments, the web device 810 and the client NFC-enabled device 830 may be different devices. For example, in one embodiment, the web device 810 may be a laptop device, and the client NFC-enabled device 830 may be a laptop device and a mobile phone that has previously been bound to the client. In any embodiment, the NFC-enabled device 830 may work in conjunction with the contactless card 840 to authenticate web-based access by the web device 810.

[0083] In step 802, in response to the access request, the application server 820 establishes a communication link with the client NFC-enabled device 830 and forwards a notification to the client NFC-enabled device via the communication link. The notification may visually or audibly indicate that an access request for an application registered with the client has been received. The notification may additionally include a prompt for action by the client. The prompt may take various forms and may include one or more mechanisms that allow the client to authorize access.

[0084] As an example, Figure 9 shows exemplary webpage data and control mechanisms for a web device 910 and a mobile device 920 configured according to embodiments disclosed herein. The web device 910 is shown to display the publicly available main webpage 915 of an application service website. According to one embodiment, a user may sign in to the application service using several mechanisms which may be presented as menu pull-down options 940 when selecting a sign-in link 925. Clients may generally customize the availability and selection of sign-in option types using the security settings of their web browser according to their personal preferences, and it may be understood that the present invention is not limited to any particular combination of sign-in options. Rather, passwordless authentication systems that provide a username and dynamic password pair using a contactless card or other mechanism are included herein.

[0085] Therefore, in the embodiment of Figure 9, the client selects the contactless card sign-in option 905 to initiate the application launch. As described with respect to step 802, in response to the selection of the contactless card sign-in option 905, the service provider application identifies the client that sent the request using one or more of the following: web cookies (i.e., information stored by the service provider application in the web browser of the client device during the client's previous access to the application), IP address, MAC address, or other forms of web device identification. The application service identifies the client's authorization device, i.e., the client's device configured to accept authentication information from the client. This authorization device may be, for example, a mobile phone, tablet, or other device having NFC capabilities that enable authentication using ciphertext exchange with encrypted username and dynamic password.

[0086] It is important to understand that the group of client devices configured to approve application access requests may vary depending on the type of approval requested and the capabilities of the specific client device. For example, authentication using facial scanning would utilize an approval device with image processing capabilities. Authentication using fingerprint scanning would utilize an approval device with fingerprint scanning capabilities. Authentication using contactless card authentication would utilize an approval device with NFC communication capabilities.

[0087] In the example in Figure 9, the mobile phone 920 is identified as an authorized client device, and the service provider application forwards a notification 930 to the authorized device indicating that an attempt has been made to access a service provider application registered with the client. The notification 930 appears as a pop-up alert on the client's phone. The notification may also include a prompt 950 requesting further action from the client. For example, the prompt 950 might instruct the client to "tap your contactless card to authorize." An alternative prompt requesting only the selection of a link 955 may be used depending on a determined authentication level threshold for accessing the service provider application.

[0088] Referring to Figure 8, if the service provider requests contactless card authentication in step 802, the client engages the contactless card 840 with the NFC-enabled device 830, for example, by bringing the contactless card 840 into NFC proximity with the device 830. Then, as described with respect to Figure 2, the contactless card 840 and the device 830 can exchange ciphertexts, and the stored and encrypted username and dynamic password are transferred to the NFC-enabled device.

[0089] In one embodiment, as described above, the authentication server 850 may be configured to store at least the username, master key information, and counter information of each client. The authentication server 850 may decrypt the encrypted username and compare the decrypted username with a stored username known to correspond to the client in order to verify the client's identity. The authentication server 850 may further decrypt the ciphertext using a diversified key generated using the stored counter value and the client's master key, and extract the password from the ciphertext. In one embodiment, the password may have or be associated with a counter and may be dynamically updated with each ciphertext exchange between the client and the application server. The authentication server 850 compares the password extracted from the ciphertext with a stored expected password for the client to approve or reject the application request. In step 805, the approval / rejection is forwarded to the client device 830 for communication with the web device 810.

[0090] In one embodiment, the approval / denial of an access request may be provided to the web device 810 via a dedicated, secure channel established by the service provider application between the application session established by the web device 810 and the client NFC-enabled device 830. Thus, approval received by the NFC-enabled device 830 can be broadcast over the channel to automatically update the application session on the web device and launch the application. In an alternative embodiment, the application session established by the web device may monitor the communication link established between the application and the NFC-enabled device for approval notifications. The web device may periodically poll the service provider application to determine whether it has received an authentication notification from the NFC-enabled device. Upon receiving approval in step 806, the service provider application grants access to the web device by launching the application in step 807.

[0091] Figure 10 is a timeline illustrating the evolution of various displays and controls provided by the display interfaces of the web device 1010 and the mobile phone 1020 over time during the passwordless login technology disclosed herein. Web page 1010A shows the public login page of an application service running on the web device 1010. Display 1020A shows the mobile phone 1020 in its initial, stationary state. As described with respect to Figure 8, when a client attempts to access the service provider application, the access request is translated into an authentication request that is forwarded to the mobile phone device 1020 identified in step 1004, and a notification 1025 is displayed as the mobile phone display 1020B. As described above, the notification may include prompts such as asking the client to approve the request using an input mechanism such as link selection 1026. In some embodiments, while the application service is communicating with the client device 1020 / contactless card / authentication server, in step 1002, the display 1010B of the web device 1010 includes a notification that the application is waiting for client authentication.

[0092] In some embodiments, following initial authentication to establish ownership (i.e., the client owns a known mobile device), the application service may further prompt alternative forms of authentication, including those that establish identity and / or knowledge. Such configurations enable at least two-factor authentication for passwordless login. Such forms of authentication include, but are not limited to, facial scanning, fingerprint scanning, query / response challenges, and ciphertext username / dynamic password exchange. In such embodiments, in step 1006, the mobile phone display 1020C may include an additional prompt 1027 requesting a second-factor authentication, such as facial scanning, biometric authentication, or contactless card ciphertext exchange. Following the receipt and verification of the second factor of authentication, in step 1008, authorization is conditionally forwarded to the application service, and in step 1009, the application service website display 1010C is updated to allow access by the client.

[0093] Figures 11A and 11B are time diagrams illustrating the evolution of various displays and controls provided by / on the display interface of a mobile phone 1120 over time, configured to implement the passwordless login technology disclosed herein. Web page 1110 shows the public login page of an application service running on the web device 1120. When a client attempts to access the service provider application from the mobile phone device, a first-factor authentication menu 1125 may be presented to the user, including the option to select a “contactless card login” option 1105. The user may satisfy first-factor authentication by tapping a contactless card 1115 on the NFC reader of the mobile device. Authentication using the above process proceeds as the mobile phone 1120 exchanges ciphertext authentication information with an authentication server.

[0094] After successful contactless card authentication, a second factor authentication may be required before granting access to the application service, as shown in Figure 11B. In Figure 11B, other techniques such as facial scanning, voice recognition, or eye scanning may be used, but the second factor authentication is shown to include biometric thumbprint authentication. In some embodiments, the user may choose the form of second factor authentication to use. In other embodiments, the application may choose the form of second factor authentication. In any case, successful biometric authentication enables client access to the application service.

[0095] Therefore, a system and method for secure, passwordless authentication that uses ciphertext exchange including username and dynamic password for the purpose of multi-factor authentication has been shown and described. Such a configuration advantageously enhances the security of an application by using an unpredictable and dynamically encoded username-password pair and a protocol that provides multi-factor authentication before application access.

[0096] As used in this application, the terms “system,” “component,” and “unit” are intended to refer to computer-related entities that are either hardware, a combination of hardware and software, software, or running software, examples of which are given herein. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives, a non-temporary computer-readable medium (either optical and / or magnetic storage medium), an object, an executable, an execution thread, a program, and / or a computer. As an example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized to one computer and / or distributed across two or more computers.

[0097] Furthermore, components can be coupled together in a communicative manner by various types of communication media to coordinate their operation. Coordination may include one-way or two-way information exchange. For example, components may communicate information in the form of signals transmitted over a communication medium. This information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0098] Some embodiments may be described using the expression “one embodiment” or “embodiment” together with their derivatives. These terms mean that certain features, structures, or characteristics described in relation to an embodiment are included in at least one embodiment. The appearance of the phrase “in one embodiment” in various places in this specification does not necessarily all refer to the same embodiment. Furthermore, unless otherwise noted, the features described above are understood to be usable together in any combination. Thus, any features discussed separately may be used together in combination with each other unless it is noted that the features are incompatible with each other.

[0099] With general reference to the notation and nomenclature used herein, the detailed descriptions herein may be presented with respect to functional blocks or units that can be implemented as program procedures executed on a computer or a network of computers. The descriptions and representations of these procedures are intended to convey to those skilled in the art in the most effective way possible the substance of their work.

[0100] The procedures described herein are generally considered to be a self-consistent set of operations leading to a desired result. These operations require the physical manipulation of physical quantities. These quantities, though not always, take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. For reasons of common usage, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

[0101] Furthermore, the operations performed are often referred to in terms such as addition or comparison, and these are generally associated with intelligent calculations performed by human operators. In any of the calculations described herein, which form part of one or more embodiments, such ability of a human operator is not required, or in most cases, undesirable. Rather, the calculations are machine calculations. Useful machines for performing the calculations of various embodiments include general-purpose digital computers or similar devices.

[0102] Some embodiments, along with their derivatives, may be described using the expressions “joined” and “connected.” These terms are not necessarily intended to be synonyms of each other. For example, some embodiments may be described using the terms “connected” and / or “joined” to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “joined” can also mean that two or more elements are not in direct contact with each other but are still cooperating or interacting with each other.

[0103] It is emphasized that a summary of the disclosure is provided so that readers can quickly confirm the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the aforementioned detailed description, various features are grouped into a single embodiment in order to streamline the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiment requires more features than expressly described in each claim. Rather, as reflected in the following claims, the subject matter of the invention lies in fewer features than all the features of a single disclosed embodiment combined. Accordingly, the following claims are incorporated into the detailed description, and each claim stands independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as plain English equivalents of the terms “equip” and “here,” respectively. Furthermore, terms such as “first,” “second,” and “third” are used merely as labels and are not intended to impose numerical requirements on their subjects.

[0104] The above description includes examples of disclosed architectures. Of course, it is impossible to describe all possible combinations of components and / or methodologies, but those skilled in the art will recognize that many more combinations and permutations are possible. Therefore, novel architectures are intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the attached claims.

Claims

1. A method for authorizing a client's access to an application, Receiving a request from the first client device to access the application, Identifying the client associated with the first client device described above, The authenticity of the request is verified by forwarding the notification of the request to a second client device associated with the aforementioned client, Receiving a response from the second client device, wherein the response comprises authentication information including a username and dynamic password obtained by the second client device from a contactless card associated with the client, The process involves comparing the username and dynamic password obtained by the second client device with the expected username and dynamic password of the client, In response to the matching of the username, the expected username, and the dynamic password, the request is authenticated and the application is launched on the first client device. Updating and storing the dynamic password associated with the client, A method that includes this.

2. The method according to claim 1, wherein the first client device and the second client device comprise different devices, the second client device being used to authenticate the request made by the first client device.

3. The method according to claim 2, wherein the step of launching the application includes the step of establishing a communication link between the web session associated with the request and the second client device, enabling the second client device to transfer authentication to the web session and launch the application.

4. The method according to claim 2, wherein the step of launching the application includes monitoring a second client device communication to detect approval of the request, and selectively launching the application in response to the detection of approval.

5. The method according to claim 1, wherein the first client device and the second client device are the same device.

6. The aforementioned method, The method according to claim 1, further comprising the step of registering the first client device and the second client device with the client.

7. The aforementioned method, The method according to claim 1, further comprising the step of binding the contactless card to the second client device.

8. The method according to claim 5, wherein at least the username is encoded using one or more of the following: the SHA-2 hash algorithm, the triple data encryption algorithm, the symmetric hash-based message authentication (HMAC) algorithm, and the symmetric cryptography-based message authentication code (CMAC) algorithm.

9. The aforementioned method, The method according to claim 1, further comprising the step of prompting the client to retrieve the username and dynamic password from the contactless card associated with the client.

10. The method according to claim 1, wherein the dynamic password is related to a counter maintained by the client and related to the number of times the username is obtained from the contactless card.

11. A system for controlling access to application clients, Processor and An interface configured to receive an authentication request from a second client device associated with a client and to authenticate an access request made by a first client device associated with the client to access an application, wherein the authentication request includes a ciphertext provided to the second client device by a contactless card, the ciphertext comprising a username and a dynamic password, and the interface, A non-temporary storage medium comprising a client table having at least one entry for at least one client, wherein the at least one entry includes an expected username and an expected dynamic password for the client, Program code stored in the non-temporary storage medium and operable when executed by the processor, In response to a first match between the username and the expected username, and a second match between the dynamic password and the expected dynamic password, the authentication request is selectively approved. In response to the approval of the authentication request, the expected dynamic password of the client is updated, The program code to execute, A system that includes this.

12. The system according to claim 11, wherein the first client device and the second client device comprise different devices, the second client device being used to authenticate a request made by the first client device.

13. The system according to claim 11, wherein the first client device and the second client device are the same device.

14. The system according to claim 11, wherein the program code is further configured to register the first client device and the second client device with the client.

15. The system according to claim 11, wherein the program code is further configured to bind the contactless card to the second client device.

16. The system according to claim 11, wherein at least a portion of the username is encoded, and the program code is further configured to decrypt the username using one or more of the SHA-2 hash algorithm, triple data encryption algorithm, symmetric hash-based message authentication (HMAC) algorithm, and symmetric cryptography-based message authentication code (CMAC) algorithm.

17. The system according to claim 11, wherein the program code is further configured to prompt the client to retrieve the username and dynamic password from the contactless card associated with the client.

18. The at least one entry in the client table includes a master key and counter associated with the client, and the program code is: In response to the client's counter and master key, a diversified key for the client is generated. The ciphertext is decrypted using the diversified keys. The system according to claim 11, further configured as follows.

19. The system according to claim 18, wherein the dynamic password is associated with the counter.

20. A method for authorizing a client's access to an application, Receiving a request to access the application from a first device associated with the client, Identifying the client associated with the first device, Verifying the authenticity of the request by forwarding a notification of the request to a second device associated with the client, which includes generating a prompt to be displayed on a second device requesting authentication input from the client, Receiving the authentication input from the second device, wherein the authentication input includes one or more of a biometric input, a query input, and a contactless card ciphertext token input comprising a username and dynamic password obtained by the second device from a contactless card associated with the client, Comparing the authentication input with the authentication input expected by the client, In response to the matching of the authentication input and the expected authentication input, the first device is enabled to access the application. A method that includes the following steps.

Images