System and method for password authentication of contactless cards

Abstract

The invention relates to a system and a method for password authentication of a contactless card. Example embodiments of systems and methods for data transfer between a contactless card, a client device, and one or more servers are provided. The one or more applets of the contactless card are configured to dynamically generate an encrypted payload attached to the link, where the contactless card is configured to communicate the link with the additional payload to the client device via the one or more gestures. The one or more servers are configured to receive a payload from the client device via the one or more applications, parse and decrypt the payload after startup of the one or more applications, and transmit one or more notifications to the client device based on a status associated with decryption of the payload. Based on the one or more notifications received from the one or more servers, the client device is authorized to access a plurality of services associated with the one or more servers.

Description

[0001] This application is a divisional application of a patent application with the application number "201980078675.9", the application date "October 1, 2019", and the invention title "Systems and Methods for Cryptographic Authentication of Contactless Cards".

[0002] Cross - reference to related applications

[0003] This application is a continuation - in - part of U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, and claims the priority of U.S. Provisional Application No. 62 / 740,352, filed on October 2, 2018, and U.S. Patent Application No. 16 / 589,352, filed on October 1, 2019. The disclosures of the above - mentioned patent applications are incorporated herein by reference in their entirety. Technical field

[0004] This disclosure relates to cryptography and, more particularly, to systems and methods for cryptographic authentication of contactless cards. Background art

[0005] Data security and transaction integrity are crucial for businesses and consumers. As electronic transactions constitute an increasingly large share of commercial activities, this need continues to grow.

[0006] Email may be used as a tool to verify transactions, but email is vulnerable to attacks and can be damaged by hackers or other unauthorized access. Short message service (SMS) messages can also be used, but they are also subject to compromise. Moreover, even data encryption algorithms (such as the triple - DES algorithm) have similar vulnerabilities.

[0007] Activating many cards, including, for example, financial cards (such as credit cards and other payment cards), involves a time - consuming process where the cardholder dials a phone number or accesses a website and enters or otherwise provides card information. Further, although the increasing use of chip - based financial cards provides more secure features for personal purchases compared to previous technologies (such as magnetic stripe cards), account access may still rely on login credentials (such as a username and password) to confirm the cardholder's identity. However, if the login credentials are compromised, others may gain access to the user's account.

[0008] These and other deficiencies exist. Therefore, there is a need to provide users with appropriate solutions to overcome these deficiencies to provide data security, authentication, and verification for contactless cards. Further, there is a need for improved methods for activating cards and improved authentication for account access. Summary of the invention

[0009] Aspects of the disclosed technology include systems and methods for cryptographic authentication of contactless cards. Various embodiments describe systems and methods for implementing and managing cryptographic authentication of contactless cards.

[0010] Embodiments of the present disclosure provide an encrypted payload system, comprising: a contactless card including a processor and a memory, wherein the memory includes a plurality of applets, and one or more of the applets are configured to dynamically generate an encrypted payload appended to a link; a client application including instructions for execution on a client device including a processor and a memory; and one or more servers in communication with the client application; wherein the contactless card is configured to send the link with the appended payload to the client application via one or more gestures, the one or more gestures including one or more taps, swipes, waves, or any combination thereof, wherein the link is configured to launch the client application; wherein one or more servers are configured to receive the payload from the client application; wherein one or more servers are configured to parse and decrypt the payload after launching the client application; wherein one or more servers are configured to transmit one or more notifications to the client application based on a status associated with the decryption of the payload; and wherein, based on one or more notifications received from one or more servers, the client application is authorized to access a plurality of services associated with the one or more servers.

[0011] Embodiments of the present disclosure provide a method for authorizing access, comprising: dynamically generating, by a contactless card, a payload appended to a string, the payload being encrypted by the contactless card; establishing communication between a client application and the contactless card, the client application including instructions for execution on a client device via one or more gestures, the one or more gestures including one or more taps, swipes, waves, or any combination thereof, wherein the string is configured to launch the client application; transmitting, by the contactless card via one or more gestures, the string and the appended payload to the client application; receiving, at one or more servers, the payload from the client application; decrypting, by one or more servers after launching the client application, the payload; transmitting, by one or more servers based on a status associated with the decryption of the payload, one or more messages to the client application; and at the client application, authorizing access to a plurality of resources associated with one or more servers based on one or more messages received from one or more servers.

[0012] Embodiments of the present disclosure provide a contactless card, comprising: one or more processors and a memory, wherein the memory includes one or more applets, wherein the one or more applets are configured to dynamically generate an encrypted payload attached to a link, wherein the encrypted payload is configured to verify identity for personalizing the link; wherein the contactless card is configured to transmit the link with the attached payload to a client application, the client application including instructions for execution on a client device via one or more gestures, the one or more gestures including one or more taps, swipes, waves, or any combination thereof, wherein the link is configured to start the client application based on one or more notifications to decrypt the encrypted payload for authorizing access to multiple services, and wherein at least one of the one or more gestures triggers an activation process of the contactless card.

[0013] In the following, with reference to specific example embodiments shown in the accompanying drawings, other features of the disclosed design and the advantages provided thereby are described in more detail. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1A is a diagram of a data transmission system according to an example embodiment.

[0015] Figure 1B is a diagram showing a sequence for providing authenticated access according to an example embodiment.

[0016] Figure 2 is a diagram of a data transmission system according to an example embodiment.

[0017] Figure 3 is a diagram of a system using a contactless card according to an example embodiment.

[0018] Figure 4 is a flowchart showing a method of key diversification according to an example embodiment.

[0019] Figure 5A is an illustration of a contactless card according to an example embodiment.

[0020] Figure 5B is an illustration of a contact pad of a contactless card according to an example embodiment.

[0021] Figure 6 is an illustration depicting a message for communicating with a device according to an example embodiment.

[0022] Figure 7 is an illustration depicting a message and a message format according to an example embodiment.

[0023] Figure 8 is a flowchart showing key operations according to an example embodiment.

[0024] Figure 9 It is a diagram of a key system according to an exemplary embodiment.

[0025] Figure 10 It is a flowchart of a method for generating a password according to an exemplary embodiment.

[0026] Figure 11 It is a flowchart showing the process of key diversification according to an exemplary embodiment.

[0027] Figure 12 It is a flowchart showing a method for card activation according to an exemplary embodiment.

[0028] Figure 13 It is an encrypted payload system according to an exemplary embodiment.

[0029] Figure 14 It is a flowchart showing a method for authorizing access according to an exemplary embodiment. Detailed Description

[0030] The following description of the embodiments provides non - limiting representative examples of reference numbers to particularly describe the features and teachings of different aspects of the present invention. From the description of the embodiments, it should be recognized that the described embodiments can be implemented separately or in combination with other embodiments. A person of ordinary skill in the art who has reviewed 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 should to some extent facilitate the understanding of the present invention such that other implementations that are not specifically covered but are within the knowledge of a person skilled in the art after reading the description of the embodiments will be understood to be consistent with the application of the present invention.

[0031] Some embodiments of the present disclosure aim to build one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform authentication and many other functions that otherwise may require the user to carry a separate physical token in addition to the contactless card. By adopting a contactless interface, a method for interaction and communication can be provided between the user's device (such as a mobile phone) and the card itself. For example, the EMV protocol (which is the basis for many credit card transactions) includes an authentication process that is sufficient to meet the operating system, but poses a challenge to which is more restrictive in terms of near field communication (NFC) usage as it can only be used in a read - only manner. The exemplary embodiments of the contactless cards described herein utilize NFC technology.

[0032] Figure 1Aillustrates a data transmission system according to an exemplary embodiment. As further discussed below, system 100 may include a contactless card 105, a client device 110, a network 115, and a server 120. Although Figure 1A a single instance of the components is shown, system 100 may include any number of components.

[0033] System 100 may include one or more contactless cards 105, which will be further described below with reference to Figure 5A - Figure 5B . In some embodiments, the contactless card 105 may wirelessly communicate with the client device 110 using NFC in the example.

[0034] System 100 may include a client device 110, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to, a computer device or a communication device, including, for example, a server, a network application, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other devices. The client device 110 may also be a mobile device; for example, the mobile device may include an iPhone, an iPod, an iPad from or any other mobile device running Apple's operating system, any device running Microsoft Mobile operating system, any device running Google's operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

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

[0036] In some examples, the client device 110 of the system 100 may execute one or more applications, such as software applications, that implement network communication with one or more components of the system 100 and transmit and / or receive data.

[0037] The client device 110 may communicate with one or more servers 120 via one or more networks 115 and may operate with the servers 120 as corresponding front-end to back-end pairs. The client device 110 may transmit, for example, one or more requests from a mobile device application executing on the client device 110 to the server 120. One or more requests may be associated with retrieving data from the server 120. The server 120 may receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 may be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 120 may be configured to transmit the received data to the client device 110, the received data being in response to the one or more requests.

[0038] The system 100 may include one or more networks 115. In some examples, the 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 the client device 110 to the server 120. For example, the 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 (LANs), global system for mobile communications, personal communication services, personal area networks, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-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, and / or the like.

[0039] Additionally, network 115 may include, but is not limited to, a telephone line, fiber optic, IEEE Ethernet 902.3, wide area network, wireless personal area network, LAN, or a global network such as the Internet. Additionally, network 115 may support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. Network 115 may further include one network, or any number of the above-exemplified types of networks, operating as independent networks or cooperating with each other. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate to one or more protocols of a network device, or translate from other protocols to one or more protocols of a network device. Although network 115 is depicted as a single network, it should be understood that, according to one or more examples, network 115 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0040] System 100 may include one or more servers 120. In some examples, server 120 may include one or more processors coupled to a memory. Server 120 may be configured as a central system, server, or platform for controlling and invoking various data at different times to perform multiple workflow actions. Server 120 may be configured to connect to one or more databases. Server 120 may be connected to at least one client device 110.

[0041] Figure 1B is a timing diagram showing an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may include a non-contact card 105 and a client device 110, which may include an application 122 and a processor 124. Figure 1B may refer to similar components as Figure 1A shown.

[0042] In step 102, application 122 (e.g., after being brought near non-contact card 105) communicates with non-contact card 105. The communication between application 122 and non-contact card 105 may involve non-contact card 105 being close enough to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and non-contact card 105.

[0043] In step 104, after communication has been established between the client device 110 and the contactless card 105, the contactless card 105 generates a message authentication code (MAC) password. In some examples, this may occur when the application 122 reads the contactless card 105. In particular, this can occur when reading (e.g., NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a reader such as the application 122 can transmit a message having a small application ID such as an NDEF generation applet, such as a small application selection message. After confirming the selection, a sequence of select file messages can be transmitted, followed by a read file message. For example, the sequence can include "select capability file", "read capability file", and "select NDEF file". At this time, the counter value maintained by the contactless card 105 can be updated or incremented, and then it can be "read NDEF file". At this time, a message that can include a header and a shared secret can be generated. Then a session key can be generated. The MAC password can be created based on the message, which can include a header and a shared secret. The MAC password can then be concatenated with one or more random data blocks, and the MAC password and random number (RND) can be encrypted with the session key. Thereafter, the password and the header can be concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "read NDEF file" message).

[0044] In some examples, the MAC password can be transmitted as an NDEF tag, and in other examples, the MAC password can be included with a Uniform Resource Indicator (e.g., as a formatted string).

[0045] In some examples, the application 122 can be configured to transmit a request to the contactless card 105 that includes instructions for generating the MAC password.

[0046] In step 106, the contactless card 105 sends the MAC password to the application 122. In some examples, the transmission of the MAC password occurs via NFC, however, the present disclosure is not limited to this. In other examples, such communication can occur via Bluetooth, Wi-Fi, or other wireless data communication means.

[0047] In step 108, the application 122 transmits the MAC password to the processor 124.

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

[0049] In some examples, verification of the MAC password can be performed by a device other than the client device 110, such as a server 120 that communicates data with the client device 110 (as Figure 1A shown). For example, the processor 124 can output the MAC password for transmission to the server 120, which can verify the MAC password.

[0050] In some examples, the MAC password can be used as a digital signature for verification purposes. Other digital signature algorithms (such as public key asymmetric algorithms, e.g., digital signature algorithms and RSA algorithms, or zero-knowledge protocols) can be used to perform such verification.

[0051] Figure 2 A data transmission system according to an example embodiment is shown. The system 200 can include, for example, a sending device 205 and a receiving device 210 that communicate via a network 215 with one or more servers 220. The sending device 205 can be the same as or similar to the client device 110 discussed above with reference to Figure 1A discussion. The receiving device 210 can be the same as or similar to the client device 110 discussed above with reference to Figure 1A discussion. The network 215 can be similar to the network 115 discussed above with reference to Figure 1A discussion. The server 220 can be similar to the server 120 discussed above with reference to Figure 1A discussion. Although Figure 2 a single instance of the components of the system 200 is shown, the system 200 can include any number of the shown components.

[0052] When using symmetric cryptographic algorithms (such as cryptographic algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms), it is important that the key remains secret between the party that initially uses the symmetric algorithm and the key to process the protected data and the party that receives and processes the data using the same cryptographic algorithm and the same key.

[0053] It is also important that the same key is not used too many times. If the key is used or reused too frequently, the key may be compromised. Each time the key is used, it provides the attacker with an additional data sample that is processed by the encryption algorithm using the same key. The more data processed by the attacker with the same key, the greater the likelihood that the attacker will discover the key value. Frequently used keys can be involved in various different attacks.

[0054] Moreover, each time a symmetric cryptographic algorithm is executed, it may reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data can include minute power fluctuations that occur while the encryption algorithm is executing while using the key. The side-channel data can be measured sufficiently to reveal enough information about the key to allow it to be recovered by an attacker. Exchanging data using the same key repeatedly reveals the data processed through the same key.

[0055] However, by limiting the number of times a particular key will be used, the amount of side-channel data that an attacker can collect is limited, and thus the exposure to this and other types of attacks is reduced. As further described herein, the parties participating in the cryptographic information exchange (e.g., the sender and the receiver) can independently generate keys based on an initial shared master symmetric key in combination with counter values, and thus periodically replace the shared symmetric key being used, without relying on any form of key exchange to keep the parties in sync. By periodically changing the shared secret symmetric key used by the sender and the receiver, the attacks described above become impossible.

[0056] Returning to the reference Figure 2 , system 200 can be configured to implement key diversification. For example, a sender and a receiver may wish to exchange data (e.g., raw sensitive data) via their respective devices 205 and 210. As explained above, although a single instance of the sending device 205 and the receiving device 210 may be included, it should be understood that one or more sending devices 205 and one or more receiving devices 210 may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending device 205 and the receiving device 210 may be provided with the same master symmetric key. Further, it should be understood that any party or device holding the same secret symmetric key can perform the function of the sending device 205, and similarly, any party holding the same secret symmetric key can perform the function of the receiving device 210. In some examples, the symmetric key may include a shared secret symmetric key that remains secret to all parties other than the sending device 205 and the receiving device 210 participating in the exchange of secure data. It should also be understood that both the sending device 205 and the receiving device 210 may be provided with the same master symmetric key, and it should also be understood that a portion of the data exchanged between the sending device 205 and the receiving device 210 includes at least a portion of data that can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the sending device 205 and the receiving device 210.

[0057] System 200 may include one or more networks 215. In some examples, network 215 may be a wireless network, a wired network, or one or more of any combination of wireless and wired networks, and may be configured to connect one or more sending devices 205 and one or more receiving devices 210 to server 220. For example, network 215 may include a fiber optic network, a passive optical network, a cable network, the Internet, a satellite network, a wireless LAN, global mobile communications, personal communications services, personal area networks, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-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, RFID, Wi-Fi, and / or the like.

[0058] In addition, network 215 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 215 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. Network 215 may also include one network operating as a stand-alone network, or any number of the above-mentioned exemplary types of networks operating in cooperation with each other. Network 215 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 215 may translate to one or more protocols of network devices, or translate from other protocols to one or more protocols of network devices. Although network 215 is depicted as a single network, it should be understood that, according to one or more examples, network 215 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0059] In some examples, one or more sending devices 205 and one or more receiving devices 210 may be configured to communicate with each other and transmit and receive data without going through network 215. For example, communication between one or more sending devices 205 and one or more receiving devices 210 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and / or the like.

[0060] At block 225, when the sending device 205 is ready to process sensitive data with symmetric cryptographic operations, the sender can update the counter. Additionally, the sending device 205 can select an appropriate symmetric cryptographic algorithm, which can include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm for processing the diversification value can include any symmetric cryptographic algorithm as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms such as 3DES or AES128; symmetric HMAC algorithms such as the HMAC-SHA-256 algorithm; and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not generate a key of sufficient length, techniques such as multiple iterations of processing the symmetric algorithm with different input data and the same master key can produce multiple outputs, which can be combined as needed to produce a key of sufficient length.

[0061] At block 230, the sending device 205 can employ the selected cryptographic algorithm and use the master symmetric key to process the counter value. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated with each conversation between the sending device 205 and the receiving device 210. Then, the sending device 205 can use the selected symmetric encryption algorithm to create a diversified symmetric key using the master symmetric key and encrypt the counter value.

[0062] In some examples, the counter value may not be encrypted. In these examples, the counter value can be transmitted between the sending device 205 and the receiving device 210 at block 230 without encryption.

[0063] At block 235, the diversified symmetric key can be used to process the sensitive data before transmitting the result to the receiving device 210. For example, the sending device 205 can use the diversified symmetric key to encrypt the sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. The sending device 205 can then transmit the protected encrypted data along with the counter value to the receiving device 210 for processing.

[0064] At block 240, the receiving device 210 can first obtain the counter value and then perform the same symmetric encryption using the counter value as the input to the encryption and the master symmetric key as the key for encryption. The output of the encryption can be the same as the diversified symmetric key value created by the sender.

[0065] At block 245, the receiving device 210 can then obtain the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm and the diversified symmetric key.

[0066] At block 250, as a result of decrypting the protected encrypted data, the original sensitive data can be revealed.

[0067] The next time sensitive data needs to be sent from the sender via the corresponding sending device 205 and receiving device 210 to the receiver, a different counter value can be selected, thereby generating a different diversified symmetric key. By processing the counter value with the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 can independently generate the same diversified symmetric key. This diversified symmetric key (instead of the master symmetric key) is used to protect the sensitive data.

[0068] As explained above, both the sending device 205 and the receiving device 210 initially each have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is independently created by both the sending device 205 and the receiving device 210, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker will never see any data processed with the master symmetric key. Only the counter value is processed with the master symmetric key, and the sensitive data is not processed with the master symmetric key. Therefore, the side-channel data revealed about the master symmetric key is reduced. Moreover, the operations of the sending device 205 and the receiving device 210 can be controlled by the symmetric requirement of how often a new diversified value is created and thus a new diversified symmetric key is created. In an embodiment, a new diversified value can be created for each exchange between the sending device 205 and the receiving device 210, and thus a new diversified symmetric key is created.

[0069] In some examples, the key diversification value can include a counter value. Other non-limiting examples of the key diversification value include: generating a random nonce each time a new diversified key is needed, the random nonce being sent from the sending device 205 to the receiving device 210; sending the full value of the counter value from the sending device 205 and the receiving device 210; sending a part of the counter value from the sending device 205 and the receiving device 210; the counter being independently maintained by the sending device 205 and the receiving device 210 but not sent between the two devices; a one-time password exchanged between the sending device 205 and the receiving device 210; and a cryptographic hash of the sensitive data. In some examples, one or more parts of the key diversification value can be used by the parties to create multiple diversified keys. For example, the counter can be used as the key diversification value. Further, a combination of one or more of the above exemplary key diversification values can be used.

[0070] In another example, a portion of a counter can be used as a key diversification value. If multiple master key values are shared among parties, multiple diversified key values can be obtained through the systems and processes described herein. New diversification values can be created whenever needed, and thus new diversified symmetric keys can be created. In the most secure scenario, a new diversification value can be created for each exchange of sensitive data between the sending device 205 and the receiving device 210. In practice, this may create one-time use keys, such as single-use session keys.

[0071] Figure 3 A system 300 using a contactless card is shown. The system 300 can include a contactless card 305, one or more client devices 310, a network 315, servers 320, 325, one or more hardware security modules 330, and a database 335. Although Figure 3 a single instance of the components is shown, the system 300 can include any number of components.

[0072] The system 300 can include one or more contactless cards 305, which are further described below with respect to Figure 5A to Figure 5B In some examples, the contactless card 305 can communicate wirelessly with the client device 310, such as NFC communication. For example, the contactless card 305 can include one or more chips configured to communicate via NFC or other short-range protocols, such as radio frequency identification chips. In other embodiments, the contactless card 305 can communicate with the client device 310 in other ways, including but not limited to Bluetooth, satellite, Wi-Fi, wired communication, and / or any combination of wireless and wired connections. According to some embodiments, the contactless card 305 can be configured to communicate with the reader 313 of the client device 310 via NFC when the contactless card 305 is within the range of the reader 313. In other examples, communication with the contactless card 305 can be achieved through a physical interface (e.g., a universal serial bus interface or a swipe card interface).

[0073] The system 300 can include client devices 310, which can be network-enabled computers. As described herein, network-enabled computers can include, but are not limited to: for example, computer devices, or communication devices, including, for example, servers, network appliances, personal computers, workstations, mobile devices, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, Internet browsers, or other devices. One or more client devices 310 can also be mobile devices; for example, mobile devices can include iPhones, iPods, iPads from or any other mobile device running Apple's operating system, or any other mobile device running Microsoft Any device running the Mobile operating system, any device running Google's operating system, and / or any other smartphone or similar wearable mobile device. In some examples, client device 310 may be the same as or similar to the client device 110 described with reference to Figure 1A or Figure 1B described.

[0074] Client device 310 may communicate with one or more servers 320 and 325 via one or more networks 315. Client device 310 may transmit, for example, one or more requests from an application 311 executing on client device 310 to one or more servers 320 and 325. One or more requests may be associated with retrieving data from one or more servers 320 and 325. Servers 320 and 325 may receive one or more requests from client device 310. Based on the one or more requests from client device 310, one or more servers 320 and 325 may be configured to retrieve the requested data from one or more databases 335. Based on receiving the requested data from one or more databases 335, one or more servers 320 and 325 may be configured to transmit the received data to client device 310, the received data being in response to the one or more requests.

[0075] System 300 may include one or more hardware security modules (HSMs) 330. For example, one or more HSMs 330 may be configured to perform one or more cryptographic operations disclosed herein. In some examples, one or more HSMs 330 may be configured as dedicated security devices that are configured to perform one or more cryptographic operations. HSM 330 may be configured such that keys are never leaked outside of HSM 330, but rather remain within HSM 330. For example, one or more HSMs 330 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 330 may be included within servers 320 and 325, or may communicate data with servers 320 and 325.

[0076] System 300 may include one or more networks 315. In some examples, network 315 may be a wireless network, a wired network, or one or more of any combination of wireless and wired networks, and may be configured to connect client devices 315 to servers 320 and 325. For example, network 315 may include a fiber optic network, a passive optical network, a cable network, a cellular network, the Internet, a satellite network, a wireless LAN, global mobile communications, personal communications services, personal area networks, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time-division multiplexing-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, RFID, Wi-Fi, and / or any combination of its networks. As a non-limiting example, communications from contactless card 305 and client device 310 may include NFC communications, a cellular network between client device 310 and the carrier, and the Internet between the carrier and the backend.

[0077] In addition, network 315 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. Additionally, network 315 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. Network 315 may further include one network, or any number of the above-exemplified types of networks, operating as independent networks or cooperating with each other. Network 315 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 315 may translate to one or more protocols of network devices, or translate from other protocols to one or more protocols of network devices. Although network 315 is depicted as a single network, it should be understood that, according to one or more examples, network 315 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0078] In various examples in accordance with the present disclosure, client device 310 of system 300 may execute one or more application programs 311 and include one or more processors 312 and one or more readers 313. For example, one or more application programs 311 (such as software applications) may be configured to implement, for example, network communication with one or more components of system 300 and transmit and / or receive data. It should be understood that although in Figure 3Only a single instance of the components of the client device 310 is shown, but any number of devices 310 may be used. The card reader 313 may be configured to read from and / or communicate with the contactless card 305. In combination with one or more applications 311, the card reader 313 may communicate with the contactless card 305.

[0079] An application 311 of any of the client devices 310 may communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). The application 311 may be configured to interface with a card reader 313 of the client device 310 that is configured to communicate with the contactless card 305. It should be noted that those skilled in the art will understand that a distance of less than twenty centimeters is consistent with the NFC range.

[0080] In some embodiments, the application 311 communicates with the contactless card 305 via an associated reader (e.g., the card reader 313).

[0081] In some embodiments, card activation may occur without user authentication. For example, the contactless card 305 may communicate with the application 311 via NFC, via the card reader 313 of the client device 310. The communication (e.g., tapping the card near the card reader 313 of the client device 310) allows the application 311 to read data associated with the card and perform activation. In some cases, the tap may activate or launch the application 311 and then initiate one or more actions or communication with the account server 325 to activate the card for subsequent use. In some cases, if the application 311 is not installed on the client device 310, tapping the card against the card reader 313 may initiate the download of the application 311 (e.g., navigate to the application download page). After installation, tapping the card may activate or launch the application 311 and then initiate the activation of the card (e.g., via the application or other backend communication). After activation, the card may be used for various transactions, including commercial transactions.

[0082] According to some embodiments, the contactless card 305 may include a virtual payment card. In those embodiments, the application 311 may retrieve information associated with the contactless card 305 by accessing a digital wallet implemented on the client device 310, where the digital wallet includes the virtual payment card. In some examples, the virtual payment card data may include one or more static or dynamically generated virtual card numbers.

[0083] Server 320 may include a web server that communicates with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more credentials from contactless card 305 and / or client device 310 by comparing them with one or more credentials in database 335. Server 325 may be configured to authorize one or more requests from contactless card 305 and / or client device 310, such as payments and transactions.

[0084] Figure 4 A method 400 for key diversification according to an example of the present disclosure is shown. Method 400 may include a sending device and a receiving device similar to Figure 2 the sending device 205 and receiving device 210 referenced in

[0085] For example, a sender and a receiver may desire to exchange data (e.g., raw sensitive data) via the sending device and the receiving device. As described above, although these two parties may be included, it should be understood that one or more sending devices and one or more receiving devices may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending device and the receiving device may be provided with the same master symmetric key. Further, it should be understood that any party or device holding the same secret symmetric key may perform the function of the sending device, and similarly, any party holding the same secret symmetric key may perform the function of the receiving device. In some examples, the symmetric key may include a shared secret symmetric key that remains secret to all parties other than the sending device and the receiving device participating in the exchange of secure data. It should also be understood that both the sending device and the receiving device may be provided with the same master symmetric key, and it should also be understood that a portion of the data exchanged between the sending device and the receiving device includes at least a portion of data that may be referred to as a counter value. The counter value may include a number that changes each time data is exchanged between the sending device and the receiving device.

[0086] At block 410, the sending device and the receiving device may be provided with the same master key, such as the same master symmetric key. When the sending device is ready to process sensitive data using symmetric cryptographic operations, the sender may update a counter. Additionally, the sending device may select an appropriate symmetric cryptographic algorithm, which may include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm for processing the diversification value may include any symmetric cryptographic algorithm that is used as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms, such as 3DES or AES128; symmetric HMAC algorithms, such as HMAC-SHA-256; and symmetric CMAC algorithms, such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not generate a key that is long enough, techniques such as multiple iterations of processing the symmetric algorithm with different input data and the same master key may produce multiple outputs that can be combined as needed to produce a key that is long enough.

[0087] The sending device may employ the selected cryptographic algorithm and use the master symmetric key to process the counter value. For example, the sender may select a symmetric encryption algorithm and use a counter that is updated with each conversation between the sending device and the receiving device.

[0088] At block 420, the sending device may then use the master symmetric key to encrypt the counter value using the selected symmetric encryption algorithm, thereby creating a diversified symmetric key. The diversified symmetric key may be used to process sensitive data before transmitting the result to the receiving device. For example, the sending device may use the diversified symmetric key and use a symmetric encryption algorithm to encrypt the sensitive data, where the output includes protected encrypted data. The sending device may then transmit the protected encrypted data along with the counter value to the receiving device for processing. In some examples, cryptographic operations other than encryption may be performed, and multiple cryptographic operations may be performed using the diversified symmetric key before transmitting the protected data.

[0089] In some examples, the counter value may not be encrypted. In these examples, the counter value may be transmitted between the sending device and the receiving device at block 420 without encryption.

[0090] At block 430, one or more cryptographic algorithms and the diversified key may be used to protect sensitive data. The diversified session key (which may be created by key diversification using the counter) may be used with one or more cryptographic algorithms to protect sensitive data. For example, a first diversified session key may be used to process data via MAC, and a second diversified session key may be used to encrypt the resulting output, thereby producing protected data.

[0091] At block 440, the receiving device may perform the same symmetric encryption using the counter value as the input for encryption and the master symmetric key as the key for encryption. The output of the encryption may be the same diversified symmetric key value as the diversified symmetric key value created by the sender. For example, the receiving device may independently create copies of its own first diversified session key and second diversified session key using the counter. The receiving device may then use the second diversified session key to decrypt the protected data to reveal the output of the MAC created by the sending device. The receiving device may then process the final data through a MAC operation using the first diversified session key.

[0092] At block 450, the receiving device may utilize one or more cryptographic algorithms to use the diversified key to authenticate the protected data.

[0093] At block 460, the original data may be authenticated. If the output of the MAC operation (by the receiving device using the first diversified session key) matches the MAC output revealed by the decryption, the data may be considered valid.

[0094] The next time sensitive data needs to be sent from the sending device to the receiving device, a different counter value may be selected, which results in a different diversified symmetric key. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device and the receiving device may independently generate the same diversified symmetric key. This diversified symmetric key (instead of the master symmetric key) is used to protect the sensitive data.

[0095] As explained above, both the sending device and the receiving device initially each have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is independently created by both the sending device and the receiving device, it is never transmitted between the two parties. Thus, an attacker cannot intercept the diversified symmetric key, and an attacker never sees any data processed using the master symmetric key. Only the smaller counter value is processed using the master symmetric key, and the sensitive data is not processed using the master symmetric key. Thus, the side-channel data revealed about the master symmetric key is reduced. Also, the sender and the receiver may, for example, agree through prior arrangement or other means how often to create a new diversified value and thus create a new diversified symmetric key. In an embodiment, a new diversified value may be created for each exchange between the sending device and the receiving device, and thus a new diversified symmetric key may be created.

[0096] In some examples, the key diversification value can include a counter value. Other non-limiting examples of key diversification values include: a random nonce generated each time a new diversified key is needed, which is transmitted from the sending device to the receiving device; the full value of the counter value transmitted from the sending device and the receiving device; a portion of the counter value transmitted from the sending device and the receiving device; a counter maintained independently by the sending device and the receiving device but not transmitted between the two; a one-time password exchanged between the sending device and the receiving device; a cryptographic hash of sensitive data. In some examples, one or more portions of the key diversification value can be used by the parties to create multiple diversified keys. For example, the counter can be used as the key diversification value.

[0097] In another example, a portion of the counter can be used as the key diversification value. If multiple master key values are shared between the parties, multiple diversified key values can be obtained through the systems and processes described herein. New diversified values, and thus new diversified symmetric keys, can be created whenever needed. In the most secure scenario, a new diversified value can be created for each exchange of sensitive data between the sending device and the receiving device. In practice, this can create one-time-use keys, such as a single session key.

[0098] In other examples, such as to limit the number of uses of the master symmetric key, it can be agreed upon by the sender of the sending device and the receiver of the receiving device that: new diversified values and thus new diversified symmetric keys will occur only periodically. In one example, this can be after a predetermined number of uses (such as every 10 transmissions between the sending device and the receiving device). In another example, this can be after a certain period of time, after a certain period of time after a transmission, or periodically (e.g., daily at a specified time; weekly at a specified time on a specified date). In another example, this can be whenever the receiving device signals to the sending device that it expects to change the key in the next communication. This can be controlled according to a policy and can vary due to, for example, the current risk level perceived by the receiver of the receiving device.

[0099] Figure 5AOne or more contactless cards 500 are shown, and the one or more contactless cards may include payment cards issued by a service provider 505 displayed on the front or back of the card 500, such as a credit card, a debit card, or a gift card. In some examples, the contactless card 500 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 500 may include a substrate 510, which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical characteristics in an ID-1 format that complies with the ISO / IEC 7810 standard, and the contactless card may additionally comply with the ISO / IEC 14443 standard. However, it should be understood that the contactless card 500 according to the present disclosure may have different characteristics, and the present disclosure does not require the contactless card to be implemented as a payment card.

[0100] The contactless card 500 may further include identification information 515 displayed on the front and / or back of the card, and contact pads 520. The contact pads 520 may be configured to establish contact with another communication device (such as a user device, a smart phone, a laptop computer, a desktop computer, or a tablet computer). The contactless card 500 may further include a processing circuit, an antenna, and Figure 5A other components not shown. These components may be located behind the contact pads 520 or elsewhere on the substrate 510. The contactless card 500 may further include a magnetic stripe or magnetic tape ( Figure 5A not shown) that may be located on the back of the card.

[0101] As Figure 5B shown, Figure 5A the contact pads 520 may include a processing circuit 525 for storing and processing information, and the processing circuit includes a microprocessor 530 and a memory 535. It should be understood that the processing circuit 525 may include additional components necessary for performing the functions described herein, including a processor, a memory, an error and parity / CRC checker, a data encoder, an anti-collision algorithm, a controller, a command decoder, security primitives, and tamper-resistant hardware.

[0102] The memory 535 can be a read-only memory, a write-once read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 500 can include one or more of these memories. The read-only memory can be a factory-programmable read-only memory or a one-time programmable memory. One-time programmability provides an opportunity to write once and then read many times. The write-once / read-many memory can be programmed at some point after the storage chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. The read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read many times.

[0103] The memory 535 can be configured to store one or more applets 540, one or more counters 545, and a customer identifier 550. The one or more applets 540 can include one or more software applications configured to execute on one or more contactless cards, such as Java card applets. However, it should be understood that the applets 540 are not limited to Java card applets and can be any software application operable on a contactless card or other device with limited memory. The one or more counters 545 can include digital counters sufficient to store integers. The customer identifier 550 can include a unique alphanumeric identifier assigned to the user of the contactless card 500, and this identifier can distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 550 can identify both the customer and the account assigned to the customer and can further identify the contactless card associated with the customer's account.

[0104] The processor and storage elements of the foregoing exemplary embodiments have been described with reference to the contact pad, but the present disclosure is not limited thereto. It should be understood that these elements can be implemented outside the pad 520, or be completely separated from the pad, or be other elements outside the processor 530 and memory 535 elements located within the contact pad 520.

[0105] In some examples, the contactless card 500 can include one or more antennas 555. The one or more antennas 555 can be placed within the contactless card 500 and around the processing circuit 525 of the contact pad 520. For example, the one or more antennas 555 can be integral with the processing circuit 525, and the one or more antennas 555 can be used with an external boost coil. As another example, the one or more antennas 555 can be outside the contact pad 520 and the processing circuit 525.

[0106] In an embodiment, the coil of the contactless card 500 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting off power or amplitude modulation. The contactless card 500 can use the gap in the power connector of the contactless card to infer the data transmitted from the terminal, and this power connection can be maintained functionally through one or more capacitors. The contactless card 500 can communicate by switching the load on the coil of the contactless card or load modulation. The load modulation can be detected by interfering with the terminal coil.

[0107] As explained above, the contactless card 500 can be built on a software platform that can operate on a smart card or other devices with limited memory (such as JavaCard), and can securely execute one or more applications or applets. Applets can be added to the contactless card to provide one-time passwords (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The applet can be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader), and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag.

[0108] Figure 6 An NDEF short record layout (SR = 1) 600 according to an example embodiment is shown. One or more applets can be configured to encode the OTP as an NDEF type 4 well-known type text tag. In some examples, the NDEF message can include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include but are not limited to tag type: well-known type, text, encoded English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message can be encoded as ASCII hexadecimal; type-length-value (TLV) data can be provided as personalized parameters that can be used to generate the NDEF message. In an embodiment, the authentication template can include a first record having a well-known index for providing actual dynamic authentication data.

[0109] Figure 7Message 710 and message format 720 according to an example embodiment are shown. In one example, if additional tags are to be added, the first byte can be changed to indicate the start rather than the end of the message, and subsequent records can be added. Since the ID length is zero, the ID length field and the ID are omitted from the record. Message examples can include: UDK AUT key; derived AUT session key (using 0x00000050); version 1.0; pATC = 0x00000050; RND = 4838FB7DC171B89E; MAC = <eight calculated bytes>.

[0110] In some examples, data can be stored in a contactless card during personalization by implementing STORE DATA (E2) under the secure channel protocol 2. One or more values can be read by the personalization bureau from the EMBOSS file (in the section specified by the applet ID), and one or more store data commands can be sent to the contactless card after authentication and secure channel establishment.

[0111] The pUID can include 16-bit BCD-encoded digits. In some examples, the pUID can include 14 digits.

[0112]

[0113] In some examples, one or more applets can be configured to maintain their personalized state to allow personalization only when unlocked and authenticated. Other states can include standard state pre-personalization. When entering the termination state, one or more applets can be configured to remove personalized data. In the termination state, one or more applets can be configured to stop responding to all application protocol data unit (APDU) requests.

[0114] One or more applets can be configured to maintain the applet version (2 bytes) that can be used in the authentication message. In some examples, this can be interpreted as the most significant byte for the major version and the least significant byte for the minor version. The rules for each version are configured to interpret the authentication message: for example, regarding the major version, this can include that each major version includes a specific authentication message layout and a specific algorithm. For the minor version, this can include no changes to the authentication message or the cryptographic algorithm, and no changes to the static tag content, in addition to bug fixes, security enhancements, etc.

[0115] In some examples, one or more applets can be configured to emulate RFID tags. The RFID tags can include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data that can indicate the authenticity of the contactless card can be presented. Based on one or more applications, the NFC reading of the tag can be processed, a token can be transmitted to a server such as a backend server, and the token can be verified at the server.

[0116] In some examples, the contactless card and the server can include certain data that enables the card to be correctly identified. The contactless card can include one or more unique identifiers. Each time a read operation occurs, a counter can be configured to be updated. In some examples, each time the card is read, the card is transmitted to the server for verification, and it is determined whether the counters are equal (as part of the verification).

[0117] One or more counters can be configured to prevent replay attacks. For example, if a cryptographic password has been obtained and replayed, if the counter has been read and used, the password is immediately rejected or otherwise ignored. If the counter has not been used, it can be replayed. In some examples, the counter updated on the card is different from the counter updated for the transaction. In some examples, the contactless card can include a first applet and a second applet, and the first applet can be a transaction applet. Each applet can include a counter.

[0118] In some examples, the counters may be out of sync between the contactless card and one or more servers. For example, the contactless card may be activated such that the counter is updated and new communication is generated by the contactless card, but the communication may not be transmitted to one or more servers for processing. This can cause the counter on the contactless card and the counter maintained at one or more servers to become out of sync. This can occur inadvertently, including, for example, when the card is kept close to a device (e.g., carried in a bag with the device), and when the contactless card is read at an angle, which may include the card being misaligned or not positioned such that the contactless card is powered on but not readable in the NFC field. If the contactless card is positioned close to the device, the NFC field of the device can be turned on to power the contactless card, causing the counter therein to be updated, but no application on the device receives the communication.

[0119] To keep the counter synchronized, an application (such as a background application) can be executed, which will be configured to detect when the mobile device wakes up, synchronize with one or more servers indicating a read due to the detection, and then increment the counter forward. Since the counter of the contactless card and the counter of the one or more servers may become desynchronized, the one or more servers can be configured to allow the counter of the contactless card to be updated a threshold number of times or a predetermined number of times before it is read by the one or more servers and still be considered valid. For example, if the counter is configured to increment (or decrement) by 1 for each occurrence indicating activation of the contactless card, the one or more servers can allow any counter value read from the contactless card to be valid, or allow any counter value within a threshold range (e.g., from 1 to 10) to be valid. Additionally, the one or more servers are configured to: if the counter value it reads has exceeded 10 but is below another threshold range value (such as 1000), request a gesture associated with the contactless card, such as a user tap. By the user tap, if the counter value is within the desired or acceptable range, authentication is successful.

[0120] Figure 8 is a flowchart showing a key operation 800 according to an example embodiment. As Figure 8 shown, at block 810, two bank identifier number (BIN)-level master keys can be used in combination with an account identifier and a card serial number to generate two unique derived keys (UDKs) for each card. In some examples, the bank identifier number can include a number or a combination of one or more numbers (such as an account number or an unpredictable number provided by one or more servers), which can be used for session key generation and / or diversification. During the personalization process, the UDKs (AUTKEY and ENCKEY) can be stored on the card.

[0121] At block 820, the counter can be used as diversification data since it changes with each use and provides a different session key each time, which is contrary to master key derivation that generates a unique set of keys for each card. In some examples, it is preferred to use a 4-byte method for both operations. Thus, at block 820, two session keys can be created for each transaction from the UDKs, i.e., one session key from AUTKEY and one session key from ENCKEY. In the card, for the MAC key (i.e., the session key created from AUTKEY), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from ENCKEY), the full length of the OTP counter can be used for the ENC key.

[0122] At block 830, the MAC key can be used to prepare the MAC password, and the ENC key can be used to encrypt the password. For example, the MAC session key can be used to prepare the password, and the result can be encrypted using the ENC key before it is transmitted to one or more servers.

[0123] At block 840, the verification and processing of the MAC are simplified because 2-byte diversification is directly supported in the MAC authentication function of the payment HSM. Decryption of the password is performed before MAC verification. The session keys are independently derived on one or more servers, resulting in a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, while the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0124] For contactless cards, different unique identifiers will be derived, which can be related to the application primary account number (PAN) and PAN serial number encoded in the card. Key diversification can be configured to receive the identifier and use it as an input together with the master key, so that one or more keys can be created for each contactless card. In some examples, these diversified keys can include a first key and a second key. The first key can include an authentication master key (Card Password Generation / Auth Key - Card-Key-Auth), and can be further diversified to create a MAC session key used in generating and verifying the MAC password. The second key can include an encryption master key (Card Data Encryption Key – Card-Key-DEK), and can be further diversified to create an ENC session key used in encrypting and decrypting encrypted data. In some examples, the issuer master key can be diversified by combining it with the unique ID number (pUID) of the card and the PAN serial number (PSN) of the payment applet to create the first key and the second key. The pUID can include a 16-bit numerical value. As explained above, the pUID can include a 16-bit BCD-encoded number. In some examples, the pUID can include a 14-bit numerical value.

[0125] In some examples, since the EMV session key derivation method ends after 2^16 uses, a counter such as a full 32-bit counter can be added to the initialization array of the diversification method.

[0126] In other examples such as credit cards, numbers (such as account numbers or unpredictable numbers provided by one or more servers) can be used for session key generation and / or diversification.

[0127] Figure 9FIG. 900 shows a schematic diagram of a system 900 configured to implement one or more embodiments of the present disclosure. As explained below, during the non-contact card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys can include symmetric keys that can be used in the encryption and decryption of data. EMV can use the triple DES (3DES) algorithm, which is implemented by hardware in the non-contact card. By using a key diversification process, one or more keys can be derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0128] Regarding master key management, for each part of a portfolio that issues a selection of one or more applets, two issuer master keys 905, 910 are required. For example, the first master key 905 can include an issuer cryptographic generation / authentication key (Iss-Key-Auth), and the second master key 910 can include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 905, 910 are diversified into card master keys 925, 930, which are unique for each card. In some examples, the network profile record ID (pNPR) 915 and the derived key index (pDKI) 920 can be used as background data, which can be used to identify which issuer master key 905, 910 to use in the encryption process for authentication. The system that performs authentication can be configured to retrieve the values of the pNPR 915 and pDKI 920 of the non-contact card at the time of authentication.

[0129] In some examples, to increase the security of the solution, a session key (such as a unique key per session) can be derived, but instead of using the master key, a unique card-derived key and a counter can be used as the diversification data, as explained above. For example, each time the card is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. Regarding session key generation, the key used to generate the cipher and encrypt data in one or more applets can include a session key based on the card unique keys (Card-Key-Auth 925 and Card-Key-Dek 930). The session keys (Aut-Session-Key 935 and DEK-Session-Key 940) can be generated by one or more applets, and the session keys are derived using one or more algorithms and the application transaction counter (pATC) 945. To make the data suitable for one or more algorithms, only the 2 lower-order bytes of the 4-byte pATC 945 are used. In some examples, the four-byte session key derivation method can include: F1 := PATC (lower 2 bytes) || 'F0' || '00' || PATC (four bytes) F1 := PATC (lower 2 bytes) || '0F' || '00' || PATC (four bytes) SK := {(ALG(MK)[F1]) || ALG(MK)[F2]}, where ALG can include 3DES ECB and MK can include the card-unique derived master key.

[0130] As described herein, the lower two bytes of the pATC 945 counter can be used to derive one or more MAC session keys. On each tap of the contactless card, the pATC 945 is configured to be updated, and the card master keys Card-Key-AUTH 925 and Card-Key-DEK 930 are further diversified into the session keys Aut-Session-Key 935 and DEK-Session940. The pATC 945 can be initialized to zero at the time of personalization or applet initialization. In some examples, the pATC counter 945 can be initialized at or before personalization and can be configured to increment by 1 on each NDEF read.

[0131] Furthermore, the update of each card can be unique and can be assigned through personalization or algorithmically through a pUID or other identifying information. For example, cards with odd numbers can be incremented or decremented by 2, while cards with even numbers can be incremented or decremented by 5. In some examples, the update can also vary during sequential reads such that one card can increment sequentially 1, 3, 5, 2, 2, …… repeatedly. A specific sequence or algorithmic sequence can be defined during personalization or derived from a unique identifier according to one or more processes. This makes it more difficult for replay attackers to generalize from a smaller number of card instances.

[0132] The authentication message can be passed as the content of a text NDEF record in hexadecimal ASCII format. In some examples, only the authentication data and an 8-byte random number (followed by the MAC of the authentication data) can be included. In some examples, the random number can be before the password A and can be a block length. In other examples, there may be no limit on the length of the random number. In additional examples, the total data (i.e., the random number plus the password) can be a multiple of the block size. In these examples, additional 8-byte blocks can be added to match the blocks produced by the MAC algorithm. As another example, if the algorithm employed uses 16-byte blocks, even multiples of that block size can be used, or the output can be automatically or manually padded to a multiple of that block size.

[0133] The MAC can be performed through the functional key (AUT-Session-Key) 935. The data specified in the password can be processed using the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3, thus being related to the EMV ARQC verification method. As explained above, the key used for this calculation can include the session key AUT-Session-Key 935. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As explained below, AUT-Session-Key 935 can be used for MAC data 950, and the resulting data or password A 955 and random number RND can be encrypted using DEK-Session-Key 940 to create password B or output 960 sent in the message.

[0134] In some examples, one or more HSM commands can be processed for decryption such that the final 16 (binary, 32 hexadecimal) bytes can include 3DES symmetric encryption using CBC mode where the fourth zero of the random number is followed by MAC authentication data. The key used for such encryption can include the session key DEK-Session-Key 940 derived from the Card-Key-DEK 930. In this case, the ATC value used for session key derivation is the least significant byte of the counter pATC 945.

[0135] The following format represents a binary version example embodiment. Further, in some examples, the first byte can be set to the ASCII 'A'.

[0136]

[0137]

[0138] Another example format is shown below. In this example, the tags can be encoded in hexadecimal format.

[0139]

[0140]

[0141] The UID field of the received message can be extracted to derive the card master keys (Card-Key-Auth 925 and Card-Key-DEK 930) for that particular card from the master keys Iss-Key-AUTH 905 and Iss-Key-DEK 910. Using the card master keys (Card-Key-Auth 925 and Card-Key-DEK 930), the counter (pATC) field of the received message can be used to derive the session keys (Aut-Session-Key 935 and DEK-Session-Key 940) for that particular card. The cipher B 960 can be decrypted using the DEK-Session-KEY, which produces the cipher A 955 and RND, and the RND can be discarded. The UID field can be used to look up the shared secret of the contactless card, which together with the Ver, UID, and pATC fields of the message can be processed by the cipher MAC, using the recreated Aut-Session-Key, to create a MAC output, such as MAC'. If MAC' is the same as the cipher A 955, then this indicates that both message decryption and MAC checking have passed. Then, the pATC can be read to determine if it is valid.

[0142] During an authentication session, one or more applications may generate one or more passwords. For example, one or more passwords may be generated as 3DES MACs using the ISO 9797-1 algorithm 3 with method 2 padding via one or more session keys such as Aut-Session-Key 935. The input data 950 may take the following form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the shared secret may be generated by one or more random number generators that may be configured to ensure the random number is unpredictable through one or more security processes. In some examples, the shared secret may include a random 4-byte binary number injected into the card during personalization, which is known to the authentication service. During the authentication session, the shared secret may not be provided from one or more applets to the mobile application. Method 2 padding may include adding the mandatory 0x'80' byte to the end of the input data, and adding 0x'00' bytes to the end of the resulting data until an 8-byte boundary. The resulting password may include a length of 8 bytes.

[0143] In some examples, one benefit of encrypting a non-shared random number as the first block using the MAC password is that it acts as an initialization vector when using the CBC (block chaining) mode of a symmetric encryption algorithm. This allows for "scrambling" block by block without having to pre-establish a fixed or dynamic IV.

[0144] By including the application transaction counter (pATC) as part of the data included in the MAC password, the authentication service can be configured to determine whether the value conveyed in the plaintext data has been tampered with. Additionally, by including the version in one or more passwords, it is difficult for an attacker to purposefully tamper with the application version when attempting to reduce the strength of the encryption solution. In some examples, the pATC may start at zero and be incremented by 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC that is equal to or lower than the previous value received by the authentication service, this may be interpreted as an attempt to replay an old message and the authenticated message may be rejected. In some examples, when the pATC is greater than the previously received value, it can be evaluated to determine if it is within an acceptable range or threshold, and if it exceeds the range or threshold or is outside the range or threshold, the authentication may be considered to have failed or be unreliable. In the MAC operation 936, the data 950 is processed through the MAC using the Aut-Session-Key 935 to produce an encrypted MAC output (password A) 955.

[0145] To provide additional protection against brute force attacks that expose keys on the card, it is desirable to encrypt the MAC password 955. In some examples, the data or password A955 included in the ciphertext can include: a random number (8), a password (8). In some examples, the numbers in parentheses can include the length in bytes. In some examples, the random number can be generated by one or more random number generators, which can be configured to ensure that the random number is unpredictable through one or more secure processes. The key used to encrypt this data can include a session key. For example, the session key can include DEK-Session-Key 940. In the encryption operation 941, the data or password A955 and RND are processed using DEK-Session-Key 940 to produce the encrypted data, i.e., password B 960. 3DES can be used to encrypt the data 955 in cipher block chaining mode to ensure that any attack by an attacker must be directed against the entire ciphertext. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) can be used. In some examples, an initialization vector of 0x’0000000000000000’ can be used. Any attacker attempting to brute force the key used to encrypt this data will not be able to determine when the correct key has been used because the correctly decrypted data cannot be distinguished from the incorrectly decrypted data due to its random occurrence.

[0146] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be passed from the one or more applets to the mobile device in plaintext during the authentication session: the version number, which is used to determine the password method used and the message format for password verification, which allows the method to be changed in the future; the pUID, which is used to retrieve password assets and derive the card key; and the pATC, which is used to derive the session key for the password.

[0147] Figure 10 A method 1000 for generating a password is shown. For example, in block 1010, the network configuration file record ID (pNPR) and the derived key index (pDKI) can be used to identify which issuer master key to use during the encryption process for authentication. In some examples, the method can include performing the following authentication: retrieving the values of the pNPR and pDKI of the contactless card during authentication.

[0148] In block 1020, the issuer master key can be diversified by combining it with the unique ID number of the card (pUID) and the PAN serial number (PSN) of one or more applets (such as a payment applet).

[0149] At block 1030, Card-Key-Auth and Card-Key-DEK (unique card key) can be created by diversifying the issuer master key to generate a session key that can be used to generate the MAC password.

[0150] At block 1040, the keys used to generate passwords and encrypt data in one or more applets can include the session keys of block 1030 based on the card unique keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys can be generated by one or more applets and derived using pATC, resulting in the session keys Aut-Session-Key and DEK-Session-Key.

[0151] Figure 11 An exemplary process 1100 showing key diversification according to one example is depicted. Initially, the sender and receiver can be provided with two different master keys. For example, the first master key can include a data encryption master key, and the second master key can include a data integrity master key. The sender has a counter value that can be updated at block 1110 and other data (such as the data to be protected) that the sender can securely share with the receiver.

[0152] At block 1120, the counter value can be encrypted by the sender using the data encryption master key to produce a data encryption-derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to produce a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value can be used during the two encryptions.

[0153] In some examples, the counter value may not be encrypted. In these examples, the counter can be transmitted between the sender and receiver in plaintext, i.e., without encryption.

[0154] At block 1130, the sender uses the data integrity session key and a cryptographic MAC algorithm to process the data to be protected using a cryptographic MAC operation. The protected data (including the plaintext and the shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0155] At block 1140, the data to be protected can be encrypted by the sender using the data encryption-derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data (e.g., 8 bytes long each), and then it is encrypted using the second session key (DEK-Session-Key).

[0156] At block 1150, the encrypted MAC and sufficient information for identifying additional secret information (such as a shared secret, a master key, etc.) are transmitted from the sender to the receiver for password verification.

[0157] At block 1160, the receiving party uses the received counter value to independently derive two derived session keys from the two master keys as described above.

[0158] At block 1170, the data encryption-derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Then, other processing is performed on the exchanged data. In some examples, after the MAC is extracted, it is desirable to reproduce and match the MAC. For example, when verifying a password, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. An appropriately generated session key can be used to perform a MAC operation to determine whether it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

[0159] At block 1180, the data integrity-derived session key is used in combination with a password MAC operation to verify that the protected data has not been modified.

[0160] When the following conditions are met, some examples of the methods described herein can advantageously confirm when a successful authentication is determined. First, the ability to verify the MAC indicates that the derived session key is correct. The MAC can only be correct if the decryption is successful and produces the correct MAC value. Successful decryption can indicate that the correctly derived encryption key has been used to decrypt the encrypted MAC. Since the derived session key is created using master keys known only to the sender (e.g., the sending device) and the receiver (e.g., the receiving device), it can be believed that the contactless card that initially created and encrypted the MAC is indeed genuine. In addition, the counter values used to derive the first session key and the second session key can be shown to be valid and can be used to perform authentication operations.

[0161] Thereafter, the two derived session keys can be discarded, and the next iteration of the data exchange will update the counter value (returning to block 1110), and a new set of session keys can be created (at block 1120). In some examples, the combined random data can be discarded.

[0162] Example embodiments of the systems and methods described herein can be configured to provide multi-factor authentication. Multi-factor authentication can include multiple processes. As part of the multi-factor authentication, a first process can include logging in and authenticating a user via one or more applications executed on a device. As a second process, in response to a successful login and authentication of the first process via one or more applications, the user can engage in one or more actions associated with one or more contactless cards. In effect, multi-factor authentication can include both securely proving the identity of a user and engaging in one or more types of actions associated with contactless cards, including but not limited to one or more tap gestures. In some examples, one or more tap gestures can include the user tapping a contactless card against the device. In some examples, the device can include a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process received tap gestures.

[0163] In some examples, a contactless card can be tapped against a device such as one or more computer kiosks or terminals to authenticate an identity in order to receive a transaction item in response to a purchase, such as coffee. By using a contactless card, a secure method of proving identity in a loyalty program can be established. A secure way of proving identity is established in a manner different from simply scanning a barcode card, for example to obtain rewards, coupons, discounts, etc. or the receipt of benefits. For example, an encrypted transaction can occur between the contactless card and the device, which can be configured to process one or more tap gestures. As explained above, one or more applications can be configured to authenticate the identity of the user and then enable the user to act or respond, for example via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, healthcare information, etc. can be written back to the contactless card.

[0164] In some examples, a contactless card can be tapped against a device such as a mobile device. As explained above, the identity of the user can be authenticated by one or more applications, and then the application can grant the desired benefits to the user based on the identity-based authentication.

[0165] In some examples, a contactless card can be activated by tapping on a device such as a mobile device. For example, the contactless card can communicate with an application on the device via a card reader of the device through NFC communication. During the communication, tapping the card close to the card reader of the device can allow the application on the device to read data associated with the contactless card and activate the card. In some examples, activation can authorize the card to perform other functions, such as making a purchase, accessing an account or restricted information, or other functions. In some examples, tapping can activate or launch an application on the device, and then initiate one or more actions or communication with one or more servers to activate the contactless card. If the application is not installed on the device, tapping the contactless card near the card reader can initiate the download of the application, such as navigating to the download page of the application. After installation, tapping the contactless card can activate or launch the application, and then initiate the activation of the contactless card, for example, via the application or other backend communication. After activation, the contactless card can be used for various activities, including but not limited to commercial transactions.

[0166] In some embodiments, a dedicated application can be configured to run on a client device to perform the activation of the contactless card. In other embodiments, a web portal, a web-based application, an applet, and / or the like can perform the activation. The activation can be performed on the client device, or the client device can only act as a medium between the contactless card and an external device (e.g., an account server). According to some embodiments, when providing the activation, the application can indicate to the account server the type of device (e.g., a personal computer, a smartphone, a tablet, or a point-of-sale (POS) device) that performs the activation. Further, depending on the type of device involved, the application can output different and / or additional data for transmission to the account server. For example, such data can include information associated with the merchant, such as merchant type, merchant ID, and information associated with the device type itself, such as POS data and POS ID.

[0167] In some embodiments, an exemplary authentication communication protocol may mimic an offline dynamic data authentication protocol of the EMV standard, with some modifications, that is typically performed between a transaction card and a point-of-sale device. For example, since the exemplary authentication protocol itself is not used to complete a payment transaction with a card issuer / payment processor, certain data values are not required and authentication can be performed without involving a real-time online connection with the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction including a transaction value to a card issuer. Whether the issuer approves or rejects the transaction may be based on whether the card issuer recognizes the transaction value. However, in certain embodiments of the present disclosure, a transaction originating from a mobile device lacks a transaction value associated with the POS system. Thus, in some embodiments, a pseudo-transaction value (i.e., a value recognizable by the card issuer and sufficient to allow activation to occur) may pass as part of the exemplary authentication communication protocol. A POS-based transaction may also reject a transaction based on the number of transaction attempts (e.g., a transaction counter). A number of attempts exceeding a buffer value may result in a soft decline; a soft decline requires further verification before accepting the transaction. In some implementations, the buffer value of the transaction counter may be modified to avoid rejecting legitimate transactions.

[0168] In some examples, a contactless card may selectively transmit information based on the receiving device. Once tapped, the contactless card may identify the device to which the tap is directed, and based on that identification, the contactless card may provide appropriate data for that device. This advantageously allows the contactless card to transmit only the information required to complete an immediate action or transaction, such as a payment or card authentication. By restricting data transmission and avoiding unnecessary data transmission, both efficiency and data security can be improved. The identification and selective transmission of information may be applied to various scenarios, including card activation, balance transfer, account access attempts, commercial transactions, and step-up fraud reduction.

[0169] If the contactless card tap is directed at a device running the Apple operating system (such as an iPhone, iPod, or iPad), the contactless card may identify the operating system and transmit appropriate data to communicate with this device. For example, the contactless card may provide encrypted identity information required to authenticate the card using an NDEF tag via, for example, NFC. Similarly, if the contactless card tap is directed at a device running the operating system (such as, a smartphone or tablet), the contactless card may identify the operating system and transmit appropriate data (such as encrypted identity information required to authenticate via the methods described herein) to communicate with this device.

[0170] As another example, the contactless card tap can be performed on a POS device (including but not limited to a self-service machine, a checkout register, a payment station, or other terminals). When performing the tap, the contactless card can identify the POS device and transmit only the information required for the action or transaction. For example, after identifying the POS device for completing a commercial transaction, the contactless card can transmit the payment information required to complete the transaction according to the EMV standard.

[0171] In some examples, the POS device participating in the transaction can request or specify additional information to be provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, once the POS device receives a data communication from the contactless card, the POS device can identify the contactless card and request the additional information required to complete the action or transaction.

[0172] In some examples, the POS device can be affiliated with an authorized merchant or other entity familiar with certain contactless cards or accustomed to performing certain contactless card transactions. However, it should be understood that the execution of the described method does not require such an affiliation.

[0173] In some examples, in places such as a shopping store, a grocery store, a convenience store, etc., the contactless card can be tapped on a mobile device without having to open an application to indicate the desire or intention to cover one or more purchases using one or more of reward points, loyalty points, coupons, offers, etc. Thus, the intention behind the purchase is provided.

[0174] In some examples, one or more applications can be configured to determine that it is launched via one or more tap gestures of the contactless card, such that the launch occurs at 3:51 PM and the transaction is processed or occurs at 3:56 PM in order to verify the user's identity.

[0175] In some examples, one or more applications can be configured to control one or more actions in response to one or more tap gestures. For example, one or more actions can include collecting rewards, collecting points, determining the most important purchase, determining the cheapest purchase, and / or reconfiguring to another action in real time.

[0176] In some examples, data can be collected on the tap behavior for biometric / gesture authentication. For example, a unique identifier that is password-secure and not easily intercepted can be transmitted to one or more backend services. The unique identifier can be configured to look up auxiliary information about the individual. The auxiliary information can include personally identifiable information about the user. In some examples, the auxiliary information can be stored in the contactless card.

[0177] In some examples, the device can include an application for dividing bills or checks for payments among multiple individuals. For example, each individual can have a contactless card and can be a customer of the same issuing financial institution, but this is not required. Each of these individuals can receive a push notification on their device via the application to divide a purchase. Instead of accepting only one card tap to indicate payment, other contactless cards can be used. In some examples, individuals with different financial institutions may have contactless cards to provide information to initiate one or more payment requests from the card-tapping individual.

[0178] The following example use cases describe examples of particular implementations of the present disclosure. These are only for illustrative purposes and not for limiting purposes. In one case, a first friend (payer) owes a second friend (payee) some money. The payer wishes to use a contactless card to make a payment through the payee's smartphone (or other device) rather than going to an ATM or needing to exchange via an end-to-end application. The payee logs into the appropriate application on their smartphone and then selects the payment request option. In response, the application requests authentication via the payee's contactless card. For example, the application outputs a display asking the payee to tap their contactless card. Once the payee taps his contactless card on the screen of the smartphone with the supported application, the contactless card is read and verified. Next, the application displays a prompt for the payer to tap his contactless card to send the payment. After the payer taps his contactless card, the application reads the card information and sends the payment request to the payer's card issuer via an associated processor. The card issuer processes the transaction and sends a status indicator of the transaction to the smartphone. Then, the application outputs to display the status indicator of the transaction.

[0179] In another example case, a credit card customer can receive a new credit card (or debit card, other payment card, or any other card that needs to be activated) by mail. The customer can decide to activate the card via an application on his or her device (such as a mobile device like a smartphone) rather than by calling the provided phone number associated with the card issuer or accessing a website to activate the card. The customer can select the card activation function from the application menu displayed on the device's display. The application can prompt the customer to tap his or her credit card on the screen. When the credit card is tapped against the device's screen, the application can be configured to communicate with a server (such as the card issuer server that activates the customer's card). Then, the application can display a message indicating successful activation of the card. Then the card activation will be completed.

[0180] Figure 12The method 1200 for card activation according to an exemplary embodiment is shown. For example, card activation can be accomplished by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components explained previously with reference to Figure 1A , Figure 1B , Figure 5A and Figure 5B such as the contactless card 105, the client device 110, and the server 120.

[0181] In block 1210, the card can be configured to dynamically generate data. In some examples, the data can include information such as an account number, a card identifier, a card verification value, or a phone number, which can be transmitted from the card to the device. In some examples, one or more portions of the data can be encrypted via the systems and methods disclosed herein.

[0182] In block 1220, one or more portions of the dynamically generated data can be transmitted to an application of the device via NFC or other wireless communication. For example, tapping the card near the device can allow the application of the device to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to assist in activating the card, tapping the card can direct the device or prompt the customer to download the associated application from a software application store to activate the card. In some examples, the user can be prompted to adequately position, place, or orient the card towards the surface of the device, such as at an angle or flat on, near, or adjacent to the surface of the device. In response to the adequate positioning, placement, and / or orientation of the card, the device can continue to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0183] In block 1230, one or more portions of the data can be transmitted to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data can be transmitted from the device to the card issuer server to activate the card.

[0184] At block 1240, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and may decrypt it in order to compare the received data with record data accessible to the one or more servers. If a resulting comparison of the one or more decrypted portions of data by the one or more servers yields a successful match, the card may be activated. If a resulting comparison of the one or more decrypted portions of data by the one or more servers yields an unsuccessful match, one or more processes may occur. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In such a case, there may be a predetermined threshold including the number of attempts allowed for the user to activate the card. Alternatively, the user may receive a notification, such as a message on his or her device, that indicates an unsuccessful attempt at card verification and provides a way to contact the associated service by call, email, or text message to assist with activating the card; or another notification, such as a phone call on his or her device, that indicates an unsuccessful attempt at card verification and provides a way to contact the associated service by call, email, or text message to assist with activating the card; or another notification, such as an email, that indicates an unsuccessful attempt at card verification and provides a way to contact the associated service by call, email, or text message to assist with activating the card.

[0185] At block 1250, one or more servers may transmit a backhaul message based on successful activation of the card. For example, the device may be configured to receive output from the one or more servers indicating successful activation of the card by the one or more servers. The device may be configured to display a message indicating successful activation of the card. Once the card is activated, the card may be configured to stop dynamically generating data to avoid fraudulent use. In this way, the card may not be activated thereafter, and the one or more servers may be notified that the card has been activated.

[0186] In another example scenario, a customer wants to access a financial account on his or her mobile phone. The customer launches an application (e.g., a banking application) on the mobile device and enters a username and password. At this stage, the customer may see first-level account information (e.g., recently purchased items) and be able to perform first-level account options (e.g., pay a credit card). However, if the user attempts to access second-level account information (e.g., spending limit) or perform second-level account options (e.g., transfer to an external system), then he must have second-level factor authentication. Thus, the application requests that the user provide a transaction card (e.g., a credit card) for account verification. The user then taps his credit card against the mobile device, and the application verifies that the credit card corresponds to the user's account. Thereafter, the user may view second-level account data and / or perform second-level account functions.

[0187] It is understood that a large number of commercial and entertainment activities are carried out through software applications, and the number of applications installed on the client devices of ordinary users continues to increase. Instead of requiring the installation and / or launching of applications on the client device, example embodiments of the present disclosure provide systems and methods in which gestures of a contactless card can be configured to transmit a Uniform Resource Locator (URL) with an encrypted one-time password and initiate one or more calls to a server for authorization to authorize access to one or more services associated with the server.

[0188] The systems and methods described herein are configured to use a link such as a URL to deliver a one-time password. In particular, an encrypted payload can be passed in the URL string, which is dynamically generated by one or more applets. In some examples, the encrypted payload can include a password. The encrypted payload can be configured to verify an identity, which can be used for URL personalization for a particular individual. As further explained below, the encrypted payload can be attached to the end of the URL and processed separately from the main URL string. In some examples, the server can receive the payload, and the server can be configured to decrypt the payload using symmetric key decryption to authorize access to one or more services associated with the backend. In other examples, the server can receive the payload, and the server can be configured to decrypt the payload using public key decryption to authorize access to one or more services associated with the backend. Instead of requiring the installation and / or launching of applications on the client device, the systems and methods disclosed herein do not require the installation of an application on the client device for the URL to work, such that gestures generated by a contactless card can be configured to transmit a URL with an encrypted one-time password and initiate one or more calls to a server for authorization to authorize access to one or more services associated with the server, including but not limited to the activation and launching of a pre-logged-in website. The systems and methods described herein can be configured to operate on one or more of a variety of user devices, including but not limited to devices such as payment terminals or systems, self-service machines, devices running an operating system, including but not limited to for example running an operating system and running an operating system.

[0189] Figure 13System 1300 is shown, which is configured to use a link to deliver a one-time password. System 1300 may include an encrypted payload system, which includes a contactless card 1305, a client device 1310, and one or more servers 1320. Although Figure 13 a single instance of the components is shown, System 1300 may include any number of components. The contactless card 1305, the client device 1310, and the one or more servers 1320 may refer to the same or similar components as previously referenced Figure 1A , Figure 1B , Figure 5A and Figure 5B explained, such as the contactless card 105, the client device 110, and the server 120.

[0190] The contactless card 1305 may include, but is not limited to, a processor 1307 and a memory 1309. The memory 1309 may include one or more applets 1311. The one or more applets 1311 may be configured to dynamically generate a payload that is attached to the link. In some examples, the encrypted payload may include a password. The encrypted payload may be configured to authenticate an identity, which may be used for link personalization for a particular individual. By attaching a one-time password to the link, limitations regarding operating systems that do not allow reading the full NDEF message can be avoided. In some examples, the payload may include a delimiter. For example, the delimiter may be configured to delimit the start and end portions and may be depicted by a symbol to identify the payload. As described below, one or more symmetric key decryption algorithms may be used to decrypt the payload. In other examples, one or more public key decryption algorithms may be used to decrypt the payload. The payload may be generated by one or more random number generator algorithms.

[0191] The contactless card 1305 can be configured to transmit a link with an additional payload to the client device 1310. In some examples, this transmission can occur via one or more gestures. For example, one or more gestures can include one or more taps, waves, or other gestures or any combination thereof. The link can be configured to launch one or more applications 1316 executable on the client device 1310. In some examples, at least one gesture can be configured to trigger one or more pre-programmed URLs for a single or multiple services, including but not limited to the activation process of the contactless card 1305 by one or more servers 1320. In some examples, one or more services can include web-based services that do not require installation on the client device 1310. Additionally, the user or one or more servers 1320 can determine which service should occur, for example, after the activation process of the contactless card 1305, in response to the first gesture. This can include but is not limited to a customer service-initiated phone call, email, or text message; directing to a website and logging in.

[0192] In some examples, different gestures, such as different taps, waves, gestures, or any combination thereof, can indicate corresponding services. For example, a tap can indicate a service, such as the activation process of the contactless card 1305. A second tap can indicate another service, such as a customer service-initiated phone call, email, or text message. In some examples, at least one of the gestures can be configured to trigger a redirect by one or more servers 1320 to one or more websites. In some examples, at least one of the gestures can be configured to trigger one or more servers 1320 to generate at least one notification. As described below, the notification can be transmitted to the client device 1310 to access one or more applications 1316. In some examples, the activation process of the contactless card 1305 can occur before launching the application 1316 or website.

[0193] The client device 1310 can include but is not limited to a processor 1312, a memory 1314, and one or more applications 1316. The client device 1310 can communicate with the contactless card 1305. In some examples, the client device 1310 can be one or more of various user devices, including but not limited to devices such as payment terminals or systems, self-service machines, devices running an operating system, including but not limited to iPhone For example running an operating system, and devices running an operating system.

[0194] The client device 1310 can be configured to receive a link from the contactless card 1305. In some examples, the client device 1310 can be configured to transfer a payload to one or more servers 1320. The client device 1310 can be configured to request access to a plurality of services associated with one or more servers 1320.

[0195] One or more servers 1320 can communicate with the client device 1310. One or more servers 1320 can be configured to receive a payload from the client device 1310 via one or more applications 1316. In some examples, one or more servers 1320 can be configured to parse and decrypt the payload after starting one or more applications 1316. In some examples, one or more servers 1320 can be configured to decrypt the encrypted payload via one or more symmetric key decryption algorithms. In other examples, one or more servers 1320 can be configured to decrypt the encrypted payload via one or more public key decryption algorithms. One or more servers 1320 can be configured to send one or more notifications to the client device 1310 based on the status associated with the decryption of the payload. Based on one or more notifications received from one or more servers 1320, the client device 1310 can be authorized to access a plurality of services associated with one or more servers 1320. In some examples, one or more services can include web-based services that do not need to be installed on the client device 1310.

[0196] In some examples, at least one notification can include an authentication message transmitted from one or more servers 1320 to the client device 1310. In some examples, at least one notification can be transmitted to the client device 1310 to access a previously authorized website. In some examples, at least one notification can include a failure message transmitted from one or more servers 1320 to the client device 1310. For example, one or more servers 1320 can trigger a predetermined delay, and the one or more servers can be configured to be adjusted by a predetermined amount for each occurrence of a decryption failure of the payload, so as to allow successful decryption of the payload within the allocated predetermined amount. In some examples, each occurrence of a decryption failure denies the user of the client device 1310 from logging in, thus prohibiting them from logging in again within 60 seconds. Based on each occurrence of a decryption failure, one or more servers can gradually increase this time.

[0197] Figure 14 A method 1400 for using a link to deliver a one-time password is shown. In some examples, the method can include steps for authorization access. Method 1400 can refer to components that are the same as or similar to those described above with respect to Figure 13 the components described.

[0198] At block 1410, method 1400 may include dynamically generating, by the contactless card, a payload appended to a string. The payload may be encrypted by the contactless card. In some examples, the encrypted payload may include a password. The encrypted payload may be configured to authenticate an identity that may be used for string personalization of a particular individual. The payload may include a delimiter. For example, the delimiter may be configured to delimit a start and an end portion and may be depicted by a symbol to identify the payload. The payload may be generated by one or more random number generator algorithms.

[0199] At block 1420, method 1400 may include establishing a data communication between the client device and the contactless card to transfer the payload via one or more gestures. In some examples, the transfer may occur via one or more gestures. By way of example, one or more gestures may include one or more taps, swipes, waves, or any combination thereof. The string may be configured to initiate one or more applications executable on the client device.

[0200] At block 1430, method 1400 may include transferring, by the contactless card via one or more gestures, the string and the appended payload to the client device. At block 1440, method 1400 may include receiving, at one or more servers via one or more applications, the payload from the client device. At block 1450, method 1400 may include decrypting, by one or more servers after starting one or more applications, the payload. In some examples, one or more symmetric key decryption algorithms may be used to decrypt the encrypted payload. In other examples, one or more public key decryption algorithms may be used to decrypt the encrypted payload.

[0201] At block 1460, method 1400 may include transferring, by one or more servers based on a status associated with the decryption of the payload, one or more messages to the client device. In some examples, at least one message may include an authorization message transferred from one or more servers to the client device. In some examples, at least one message may include a failure message that may be transferred from one or more servers to the client device. For example, one or more servers may trigger a predetermined delay that may be configured to be adjusted by a predetermined amount for each occurrence of a decryption failure of the payload, thereby allowing successful decryption of the payload within the allotted amount. In some examples, each occurrence of a decryption failure may deny the user of the client device from logging in, thereby prohibiting them from logging in again within 60 seconds. Based on each occurrence of a decryption failure, one or more servers may gradually increase this time.

[0202] In some examples, at least one gesture made by the contactless card to the client device can be configured to trigger one or more servers to generate at least one message. For example, the message can be transmitted to the client device to access a previously authorized website. In some examples, at least one gesture can be configured to trigger one or more servers to generate at least one message. For example, the message can be transmitted to the client device to access one or more applications. In some examples, at least one gesture can be configured to trigger one or more pre-programmed URLs directed to a single or multiple services, where the services include but are not limited to the activation process of the contactless card by one or more servers. In some examples, one or more services can include web-based services that do not require installation on the client device. Additionally, the user or one or more servers can determine, in response to a first gesture, which service should occur, for example, after the activation process of the contactless card. This can include but is not limited to a customer service-initiated phone call, email, or text message; directing to a website and logging in. In some examples, different gestures, such as different taps, waves, gestures, or any combination thereof, can indicate corresponding services. For example, a tap can indicate a service, such as the activation process of the contactless card. A second tap can indicate another service, such as a customer service-initiated phone call, email, or text message. In some examples, at least one gesture can be configured to trigger redirection by one or more servers to one or more websites. In some examples, the activation process of the contactless card can occur before starting an application or website.

[0203] At block 1470, method 1400 can include: authorizing access to multiple resources associated with one or more servers at the client device based on one or more messages received from the one or more servers.

[0204] In some examples, the present disclosure relates to tapping of a contactless card. However, it should be understood that the present disclosure is not limited to tapping, and the present disclosure includes other gestures (e.g., waving the card or other movement of the card).

[0205] Throughout the specification and claims, unless the context clearly indicates otherwise, the following terms have at least the meanings explicitly associated herein. The term "or" is intended to mean an inclusive "or". Additionally, the terms "a", "an", and "the" are intended to mean one or more, unless otherwise stated or clearly indicated as singular from the context.

[0206] In this description, many specific details have been set forth. However, it should be understood that the embodiments of the disclosed technology can be practiced without these specific details. In other cases, well-known methods, structures, and techniques are not shown in detail to avoid confusing the understanding of this description. Reference to "some examples", "other examples", "one example", "example", "various examples", "one embodiment", "embodiment", "some embodiments", "example embodiments", "various embodiments", "one implementation", "implementation", "exemplary implementation", "various implementations", "some implementations", etc. indicates that one or more embodiments of the disclosed technology described in this way may include specific features, structures or characteristics, but not every implementation must include the specific features, structures or characteristics. In addition, although the phrases "in one example", "in one embodiment" or "in one implementation" can be used repeatedly, it does not necessarily refer to the same example, embodiment or implementation.

[0207] As used herein, unless otherwise specified, the use of ordinal adjectives "first," "second," "third," etc. to describe common objects indicates merely that different instances of the same object are referenced and is not intended to imply that the objects so described must be presented in a given order in time, space, rank, or in any other manner.

[0208] Although certain embodiments of the disclosed technology have been described in conjunction with what are currently considered to be the most practical and various embodiments, it should be understood that the disclosed technology is not limited to the disclosed embodiments, but rather, the present disclosure is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are used herein, they are used only in a general and descriptive sense and not for purposes of limitation.

[0209] This written description uses examples to disclose certain embodiments of the disclosed technology, including the best mode, and also enables those skilled in the art to practice certain embodiments of the disclosed technology, including making and using any device or system and performing any content included. The patentable scope of certain embodiments of the disclosed technology is defined in the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have the same structural elements as the literal language of the claims, or if they include equivalent structural elements that do not differ substantially from the literal language of the claims.

Claims

1. An encrypted payload system, comprising: A contactless card including a processor and a memory, wherein the memory includes a plurality of applets, and one or more applets are configured to dynamically generate an encrypted payload attached to a link; A client application including instructions for execution on a client device including a processor and a memory; and One or more servers communicating with the client application; wherein the contactless card is configured to transmit a link with an attached payload to the client application via one or more gestures, the one or more gestures including one or more taps, swipes, waves, or any combination thereof, wherein the link is configured to launch the client application; wherein the one or more servers are configured to receive the payload from the client application; wherein the one or more servers are configured to parse and decrypt the payload after the launch of the client application; wherein the one or more servers are configured to transmit one or more notifications to the client application based on a state associated with the decryption of the payload; wherein, based on one or more notifications received from the one or more servers, the client application is authorized to access a plurality of services associated with the one or more servers.

2. The encrypted payload system according to claim 1, wherein, The payload includes delimiters.

3. The encrypted payload system according to claim 1, wherein, At least one notification includes an authentication message returned to the client application.

4. The encrypted payload system according to claim 1, wherein, At least one notification includes a failure message, the failure message being returned to the client application such that a predetermined time delay is triggered by the one or more servers, and for each decryption failure of the payload, the predetermined time delay increases by a predetermined amount to allow successful decryption of the payload within the predetermined amount.

5. The encrypted payload system according to claim 1, wherein, The payload is decrypted using one or more symmetric key decryption algorithms.

6. The encrypted payload system according to claim 1, wherein, The payload is generated by one or more random number generator algorithms.

7. The encrypted payload system according to claim 1, wherein, The client application is configured to request access to a plurality of services associated with the one or more servers.

8. The encrypted payload system according to claim 1, wherein, At least one gesture triggers an activation process of the one or more servers for the contactless card.

9. The encrypted payload system according to claim 1, wherein, At least one gesture triggers the one or more servers to redirect to a website.

10. The encrypted payload system according to claim 1, wherein, At least one gesture triggers the one or more servers to generate at least one notification, and the at least one notification is transmitted to the client application for access.

Images