System and method for password authentication of contactless cards

Abstract

An example embodiment of a system and method for data transmission between a sending and receiving device is provided. In one embodiment, the sending device may include a contactless card and may be configured to create a password and send the password and transmission information to a receiving device application. The receiving device application may be configured to update the transmission information stored on the sending device based on the number of times the communication interface enters the communication field, and update the score value stored on the sending device.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. patent application No. 16 / 351,424 filed on March 12, 2019, which is a continuation-in-part of and claims priority to U.S. patent application No. 16 / 205,119 filed on November 29, 2018. This application also claims priority to U.S. Provisional Patent Application No. 62 / 740,352 filed on October 2, 2018. The entire disclosure of the above patent application is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to cryptography, and more particularly, to systems and methods for cryptographic authentication of contactless cards. Background Art

[0004] Data security and transaction integrity are critical to businesses and consumers, and as electronic transactions become a larger share of business activity, this need continues to grow.

[0005] Email can be used as a tool to verify transactions, but email is vulnerable to attack and can be easily hacked or otherwise accessed without authorization. Short Message Service (SMS) messages can also be used, but SMS messages are also vulnerable to threats. Furthermore, even data encryption algorithms, such as the Triple DES algorithm, have similar vulnerabilities.

[0006] Activating many cards, including financial cards (e.g., credit cards and other payment cards), requires the cardholder to spend time dialing a phone number or visiting a website and entering or otherwise providing card information. In addition, while the increasing use of chip-based financial cards provides greater security than previous technologies (e.g., magnetic stripe cards), for personal purchases, account access may still rely on login credentials (e.g., username and password) to confirm the cardholder's identity. However, if the login credentials are compromised, others may be able to access the user's account.

[0007] The above 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. In addition, there is a need for both an improved method of activating cards and improved authentication for account access. Summary of the invention

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

[0009] An embodiment of the present disclosure provides a data transmission system, which includes: a contactless card, which includes a processor and a memory; an application, which includes instructions for execution on a receiving device having a processor and a memory, wherein the application communicates data with the contactless card; wherein the contactless card is configured to: send one or more user credentials for authentication after entering a communication field one or more times; wherein the application is configured to execute one or more processes after determining the authentication of the one or more user credentials, wherein at least one of the one or more processes is selected from audible messages and visual messages within a predetermined time period, wherein the selection depends on the one or more entries into the communication field, wherein the at least one process selected from the audible messages and the visual messages is selected based on the one or more entries, the one or more entries include one or more gestures, so that each of the one or more gestures indicates a different message, the one or more gestures include at least one selected from tapping, waving, gestures and swiping, and wherein the contactless card is configured to update the records stored therein when executing the one or more processes.

[0010] An embodiment of the present disclosure provides a method for transmitting data using a contactless card and an application, wherein the application includes instructions for execution on a receiving device having a processor and a memory, and the contactless card includes a processor and a memory, wherein the application communicates data with the contactless card, and the method includes the following steps: after entering a communication field one or more times, sending one or more user credentials for authentication; the application executes one or more processes after determining the authentication of the one or more user credentials, wherein at least one process is selected from audible messages and visual messages within a randomly selected time period, wherein the selection depends on the one or more times entering the communication field, wherein the at least one process selected from the audible messages and the visual messages is selected based on the one or more entries, the one or more entries include one or more gestures, so that each of the one or more gestures indicates a different message, and the one or more gestures include at least one selected from tapping, waving, gestures, and swiping; and the contactless card updates the records stored therein when executing the one or more processes.

[0011] Other features of the disclosed design, and the advantages provided thereby, are explained in more detail hereinafter with reference to specific example embodiments shown in the accompanying drawings, in which like elements are indicated by like reference numerals. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0016] Figure 4 is a flow chart illustrating a key diversification method according to an example embodiment.

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

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

[0019] Figure 6 is a diagram illustrating messages communicated with a device according to an example embodiment.

[0020] Figure 7 is a diagram illustrating messages and message formats according to an example embodiment.

[0021] Figure 8 is a flow chart illustrating key operations according to an example embodiment.

[0022] Fig. 9 is a diagram of a key system according to an example embodiment.

[0023] Fig.10 is a flow chart of a method of generating a password according to an example embodiment.

[0024] Fig.11 is a flow chart illustrating a key diversification process according to an example embodiment.

[0025] Fig.12 is a flow chart of a method of activating a card according to an example embodiment.

[0026] Fig.13 is a flow chart illustrating a method of performing one or more gaming operations using a contactless card according to an example embodiment.

[0027] Fig.14 is a flow chart illustrating a method of displaying one or more messages using a contactless card according to an example embodiment. DETAILED DESCRIPTION

[0028] The following description of the embodiments provides non-limiting representative example reference numbers to specifically describe the features and teachings of different aspects of the present invention. It should be appreciated that the described embodiments can be implemented separately or in combination with other embodiments in the description of the embodiments. By carefully reading the description of the embodiments, those of ordinary skill in the art should be able to learn and understand the different aspects of the present invention described. The description of the embodiments should promote understanding of the present invention to some extent, so that other implementations that are not specifically covered but can be understood by those skilled in the art who have read the description of the embodiments are understood to be consistent with the application of the present invention.

[0029] An object of some embodiments of the present disclosure is 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 would otherwise require the user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, a method can be provided for the contactless card to interact and communicate between the user's device (e.g., a mobile phone) and the card itself. For example, the EMV protocol that underlies many credit card transactions includes an authentication process that is sufficient to satisfy operating system requirements, but given This poses a challenge because it is more restrictive to use near field communication (NFC), which can only be used in a read-only manner. Exemplary embodiments of contactless cards described herein utilize NFC technology.

[0030] Figure 1A 1 shows a data transmission system according to an example embodiment. As discussed further below, system 100 may include contactless card 105, client device 110, network 115, and server 120. Figure 1A A single component example is shown, but system 100 may include any number of components.

[0031] The system 100 may include one or more contactless cards 105, hereinafter referred to as Figures 5A to 5B The contactless card is further described. In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110 using NFC.

[0032] System 100 may include 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, such as a server, a network device, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. Client device 110 may also be a mobile device; for example, a mobile device may include iPhone, iPod, iPad or any other device running Apple operating system; any mobile device running Microsoft Mobile operating system devices; any device running Google operating system, and / or any other smartphone, tablet computer or similar wearable mobile device.

[0033] The client device 110 may include a processor and memory, and it should be understood that the processing circuit may include other components, including processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware necessary to perform the functions described herein. The client device 110 may further 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 device, and 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 camera. These devices can be used to input information and interact with the software and other devices described herein.

[0034] In some examples, client device 110 of system 100 may execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of system 100 and send and / or receive data.

[0035] The client device 110 may communicate with one or more servers 120 via one or more networks 115 and may operate as a corresponding front-end to back-end pair with the server 120. The client device 110 may send one or more requests to the server 120, for example, via a mobile device application executing on the client device 110. The one or more requests may be associated with data retrieved 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 send the received data to the client device 110, the received data being responsive to the one or more requests.

[0036] 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 with the server 120. For example, the network 115 may include one or more of: a fiber optic network, a passive fiber optic network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and the like.

[0037] In addition, the network 115 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. In addition, the network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The network 115 may further include a network, or any number of the above exemplary network types, which operate as independent networks or collaborate with each other. The network 115 may utilize one or more protocols of one or more network elements coupled to it in communication. The network 115 may convert to one or more protocols of a network device, or convert from other protocols to one or more protocols of a network device. Although the network 115 is described as a single network, it should be understood that according to one or more examples, the network 115 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network (e.g., a credit card association network), and a home network.

[0038] 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 to control and call 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.

[0039] Figure 1B is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may include contactless card 105 and client device 110 , which may include application 122 and processor 124 . Figure 1B Can be cited Figure 1ASimilar components as shown in .

[0040] At step 102, application 122 communicates with contactless card 105 (e.g., after being brought into proximity with contactless card 105). Communication between application 122 and contactless card 105 includes contactless card 105 being close enough to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0041] At step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a message authentication code (MAC) password. In some examples, this may occur when the application 122 reads the contactless card 105. In particular, this may occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader such as the application 122 may send a message, such as an applet selection message, which has an applet ID of the NDEF that generates the applet. After confirming the selection, a series of select file messages followed by a read file message may be sent. For example, the sequence may include "select function file", "read function file", and "select NDEF file". At this time, a counter value maintained by the contactless card 105 may be updated or incremented, which may be followed by "read NDEF file". At this time, a message may be generated, which may include a header and a shared secret. A session key may then be generated. A MAC password may be created by this message, which may 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 then be encrypted with the session key. Thereafter, the password and header can be concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "Read NDEF File" message).

[0042] In some examples, the MAC password may be sent as an NDEF tag, and in other examples, the MAC password may be included in a uniform resource indicator (eg, as a formatted string).

[0043] In some examples, application 122 may be configured to send a request to contactless card 105 that includes instructions to generate a MAC password.

[0044] In step 106, the contactless card 105 sends the MAC password to the application 122. In some examples, the sending of the MAC password occurs via NFC, but the present disclosure is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi or other wireless data communication means.

[0045] At step 108 , application 122 transmits the MAC password to processor 124 .

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

[0047] In some examples, the operation of verifying the MAC password may be performed by a device other than the client device 110 (such as a server 120 in data communication with the client device 110). Figure 1A For example, the processor 124 may output the MAC password to send to the server 120, and the server 120 may verify the MAC password.

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

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

[0050] When using symmetric cryptographic algorithms such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms, it is important that the keys remain confidential between the party that initially processes the data protected by the symmetric algorithm and key and the party that receives and processes the data using the same algorithm and the same key.

[0051] It is also important not to use the same key more than once. If a key is used or reused too frequently, it can be compromised. Each time a key is used, it provides an attacker with an additional sample of data that is processed by the cryptographic algorithm using the same key. The more data an attacker has that was processed using the same key, the more likely they are to discover the key value. A key that is used frequently can be included in a variety of different attacks.

[0052] Additionally, each time a symmetric cryptographic algorithm is executed, information about the key used during the symmetric cryptographic operation may be revealed, such as side-channel data. Side-channel data may include subtle power fluctuations that occur when a cryptographic algorithm is executed while using the key. An attacker could manipulate the side-channel data sufficiently to reveal enough information about the key to recover the key. Exchanging data using the same key continually exposes data processed with the same key.

[0053] However, by limiting the number of times a particular key is used, the amount of side channel data that an attacker can collect can be limited, thereby reducing the risk of this and other types of attacks. As further described herein, the parties involved in the cryptographic information exchange (e.g., a sender and a receiver) can individually generate keys from an initial shared master symmetric key combined with a counter value, thereby periodically replacing the shared symmetric keys in use, without resorting to any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and the receiver, the above attacks can be made impossible.

[0054] Return to reference Figure 2 , the system 200 may be configured to implement key decentralization. For example, a sender and a receiver may wish to exchange data (e.g., original sensitive data) via respective devices 205 and 210. As described above, although a single instance of a sending device 205 and a 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 same master symmetric key may be provided to the sending device 205 and the receiving device 210. In addition, it should be understood that any party or device holding the same secret symmetric key can perform the functions of the sending device 205, and similarly, any party holding the same secret symmetric key can perform the functions of the receiving device 210. In some examples, the symmetric key may include a shared secret symmetric key that remains confidential to all other parties other than the sending device 205 and the receiving device 210 involved in exchanging secure data. It should also be understood that the same master symmetric key can be provided to the sending device 205 and the receiving device 210, and further 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.

[0055] The system 200 may include one or more networks 215. In some examples, the network 215 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 one or more sending devices 205 and one or more receiving devices 210 to a server 220. For example, the network 215 may include one or more of the following: a fiber optic network, a passive fiber optic network, a cable network, an Internet network, a satellite network, a wireless LAN, a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short messaging service, a system based on time division multiplexing, a system based on code division multiple access, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and the like.

[0056] In addition, the network 215 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. In addition, the network 215 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The network 215 may further include a network, or any number of the above exemplary network types, which operate as independent networks or collaborate with each other. The network 215 may utilize one or more protocols of one or more network elements coupled to it in communication. The network 215 may convert to one or more protocols of a network device, or convert from other protocols to one or more protocols of a network device. Although the network 215 is described as a single network, it should be understood that according to one or more examples, the network 215 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network (e.g., a credit card association network), and a home network.

[0057] In some examples, the one or more transmitting devices 205 and the one or more receiving devices 210 may be configured to communicate with each other and send and receive data without using the network 215. For example, the communication between the one or more transmitting devices 205 and the one or more receiving devices 210 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, etc.

[0058] At box 225, when the sending device 205 is ready to use a symmetric cryptographic operation to process sensitive data, the sender can update the counter. In addition, 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 decentralized values ​​can include any symmetric cryptographic algorithm that generates a desired length decentralized symmetric key as needed. Non-limiting examples of symmetric algorithms can 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 sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may produce multiple outputs, which can be combined as needed to produce a sufficiently long key.

[0059] At block 230, the sending device 205 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 205 and the receiving device 210. The sending device 205 may then use the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm to create a decentralized symmetric key.

[0060] In some examples, the counter value may not be encrypted. In these examples, the unencrypted counter value may be sent between the sending device 205 and the receiving device 210 at block 230 .

[0061] At block 235, the decentralized symmetric key may be used to process the sensitive data before the result is sent to the receiving device 210. For example, the sending device 205 may encrypt the sensitive data using a decentralized symmetric key with a symmetric encryption algorithm, where the output includes the protected encrypted data. The sending device 205 may then send the protected encrypted data along with the counter value to the receiving device 210 for processing.

[0062] At block 240, the receiving device 210 may first obtain the counter value, then use the counter value as an encryption input, and perform the same symmetric encryption using the master symmetric key as the encryption key. The output of the encryption may be the same as the decentralized symmetric key value created by the sender.

[0063] At block 245 , the receiving device 210 may then obtain the protected encrypted data and decrypt the protected encrypted data using the symmetric decryption algorithm and the decentralized symmetric key.

[0064] At block 250, the original sensitive data may be displayed as a result of decrypting the protected encrypted data.

[0065] The next time sensitive data needs to be sent from the sender to the receiver via the corresponding sending device 205 and receiving device 210, different counter values ​​can be selected to generate different decentralized symmetric keys. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 can individually generate the same decentralized symmetric key. This decentralized symmetric key is used instead of the master symmetric key to protect sensitive data.

[0066] As described above, the sending device 205 and the receiving device 210 initially each hold a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the decentralized symmetric key is independently created by the sending device 205 and the receiving device 210, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the decentralized symmetric key, and the attacker will never see any data processed using the master symmetric key. Only the counter value is processed using the master symmetric key, and the sensitive data is not processed in this way. Therefore, the exposure of the side channel data related to the master symmetric key is reduced. Moreover, the operation of the sending device 205 and the receiving device 210 can be controlled by the symmetry requirements, thereby determining how often a new decentralized value is created, and thus a new decentralized symmetric key is created. In one embodiment, a new decentralized value can be created for each exchange between the sending device 205 and the receiving device 210, and thus a new decentralized symmetric key is created.

[0067] In some examples, the key diversification value may include a counter value. Other non-limiting examples of key diversification values ​​include: a random nonce generated each time a new diversification key is needed, which is sent from the sending device 205 to the receiving device 210; the full value of the counter value sent from the sending device 205 and the receiving device 210; a portion of the counter value sent from the sending device 205 and the receiving device 210; a counter maintained separately 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 sensitive data. In some examples, the parties may use one or more portions of the key diversification value to create multiple diversification keys. For example, a counter may be used as a key diversification value. In addition, a combination of one or more of the above exemplary key diversification values ​​may be used.

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

[0069] Figure 3 A system 300 using a contactless card is shown. The system 300 may 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 component example is shown, but system 300 may include any number of components.

[0070] System 300 may include the following references FIG. 5A to FIG. 5B One or more contactless cards 305 further described. 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 may include one or more chips, such as a radio frequency identification chip, which are configured to communicate via NFC or other short-range protocols. 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, when the contactless card 305 is within the range of the card reader 313, the contactless card 305 may be configured to communicate with the card reader 313 of the client device 310 via NFC. In other examples, communication with the contactless card 305 can be achieved through a physical interface, such as a universal serial bus interface or a card swipe interface.

[0071] System 300 may include client devices 310, which may be network-enabled computers. As referred to herein, network-enabled computers may include, but are not limited to, computer devices or communication devices, including, for example, servers, network devices, personal computers, workstations, mobile devices, phones, handheld PCs, personal digital assistants, thin clients, fat clients, Internet browsers, or other devices. One or more client devices 310 may also be mobile devices; for example, a mobile device may include iPhone, iPod, iPad or any other device running Apple operating system; any mobile device running Microsoft Mobile operating system devices; any device running Google operating system, and / or any other smartphone or similar wearable mobile device. In some examples, client device 310 may communicate with reference Figure 1A or Figure 1B The client devices 110 described are the same or similar.

[0072] The client device 310 can communicate with one or more servers 320 and 325 via one or more networks 315. The client device 310 can send one or more requests to the servers 320 and 325, for example, through an application 311 executed on the client device 310. The one or more requests can be associated with data retrieved from the servers 320 and 325. The servers 320 and 325 can receive the one or more requests from the client device 310. Based on the one or more requests from the client device 310, the servers 320 and 325 can be configured to retrieve the requested data from the one or more databases 335. Based on receiving the requested data from the one or more databases 335, the servers 320 and 325 can be configured to send the received data to the client device 310, the received data being responsive to the one or more requests.

[0073] The system 300 may include one or more hardware security modules (HSM) 330. For example, one or more HSM 330 may be configured to perform one or more cryptographic operations disclosed herein. In some examples, one or more HSM 330 may be configured as a dedicated security device that is configured to perform one or more cryptographic operations. The HSM 330 may be configured so that the key is never leaked outside the HSM 330, but is stored within the HSM 330. For example, one or more HSM 330 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSM 330 may be included in the servers 320 and 325 or may be in data communication with the servers 320 and 325.

[0074] System 300 may include one or more networks 315. In some examples, network 315 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 315 with servers 320 and 325. For example, network 315 may include one or more of: a fiber optic network, a passive fiber optic network, a cable network, a cellular network, an Internet network, a satellite network, a wireless LAN, a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short messaging service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and / or any combination of networks thereof. As a non-limiting example, communications from the contactless card 305 and the client device 310 may include NFC communications, a cellular network between the client device 310 and the operator, and the Internet between the operator and the backend.

[0075] In addition, the network 315 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. In addition, the network 315 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The network 315 may further include a network, or any number of the above exemplary network types, which operate as independent networks or collaborate with each other. The network 315 may utilize one or more protocols of one or more network elements coupled to it in communication. The network 315 may be converted to one or more protocols of a network device, or converted from other protocols to one or more protocols of a network device. Although the network 315 is described as a single network, it should be understood that according to one or more examples, the network 315 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network (e.g., a credit card association network), and a home network.

[0076] In various examples according to the present disclosure, the client device 310 of the system 300 may execute one or more applications 311 and include one or more processors 312 and one or more card readers 313. For example, the one or more applications 311 (such as software applications) may be configured to enable network communication with one or more components of the system 300 and to send and / or receive data. It should be understood that although Figure 3Only a single component example of a 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 conjunction with one or more applications 311, the card reader 313 may communicate with the contactless card 305.

[0077] The application 311 of any client device 310 can communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). The application 311 can be configured to interface with a card reader 313 of the client device 310 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 distance.

[0078] In some embodiments, application 311 communicates with contactless card 305 through an associated reader (eg, card reader 313 ).

[0079] In some embodiments, the card can be activated without user authentication. For example, the contactless card 305 can communicate with the application 311 via NFC, with the aid of the card reader 313 of the client device 310. This communication (e.g., tapping the card close to the card reader 313 of the client device 310) allows the application 311 to read the data associated with the card and perform the activation. In some cases, this tap can activate or launch the application 311, and then initiate one or more actions or communications with the account server 325 to activate the card, thereby facilitating later use. In some cases, if the application 311 is not installed on the client device 310, tapping the card against the card reader 313 can initiate the download of the application 311 (e.g., navigating to the application download page). After installation, tapping the card can 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 can be used for various transactions, including commercial transactions.

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

[0081] Server 320 may include a network server in communication 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 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 payment and transaction requests.

[0082] Figure 4 A method 400 of key decentralization according to an example of the present disclosure is shown. The method 400 may include Figure 2 The sending device 205 and the receiving device 210 referenced in the specification are similar to the sending device and the receiving device.

[0083] For example, the sender and the receiver may wish to exchange data (e.g., original sensitive data) via a sending device and a receiving device. As described above, although these two parties may be included, it is to be understood that as long as each party shares the same shared secret symmetric key, one or more sending devices and one or more receiving devices may be involved. In some examples, the same master symmetric key may be provided to the sending device and the receiving device. In addition, 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 is kept confidential for all other parties other than the sending device and the receiving device involved in exchanging secure data. It should also be understood that the same master symmetric key may be provided to the sending device and the receiving device, and further, a portion of the data exchanged between the sending device and the receiving device includes at least a portion of the 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.

[0084] At block 410, the same master key, such as the same master symmetric key, may be provided to the sending device and the receiving device. When the sending device is ready to use a symmetric cryptographic operation to process sensitive data, the sender may update the counter. In addition, 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 decentralized values ​​may include any symmetric cryptographic algorithm that generates a desired length decentralized symmetric key as needed. 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 sufficiently long key, techniques such as processing multiple iterations of 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 sufficiently long key.

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

[0086] At block 420, the sending device may then use the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm to create a decentralized symmetric key. The decentralized symmetric key may be used to process sensitive data before the result is sent to the receiving device. For example, the sending device may use the decentralized symmetric key to encrypt the sensitive data with the symmetric encryption algorithm, where the output includes the protected encrypted data. The sending device may then send 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 decentralized symmetric key before the protected data is sent.

[0087] In some examples, the counter value may not be encrypted. In these examples, the unencrypted counter value may be sent between the sending device and the receiving device at block 420 .

[0088] At block 430, one or more cryptographic algorithms and decentralized keys may be used to protect sensitive data. The decentralized session key that may be created by decentralizing the key using the counter can be used in conjunction with one or more cryptographic algorithms to protect sensitive data. For example, data may be processed using a MAC using a first decentralized session key, and the resulting output may be encrypted using a second decentralized session key to produce protected data.

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

[0090] At block 450, the receiving device may use the decentralized key in conjunction with one or more cryptographic algorithms to authenticate the protected data.

[0091] The original data may be verified at block 460. If the output of the MAC operation (via the receiving device using the first decentralized session key) matches the MAC output revealed by decryption, then the data may be deemed valid.

[0092] The next time sensitive data needs to be sent from the sending device to the receiving device, a different counter value can be selected to generate a different decentralized 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 can independently generate the same decentralized symmetric key. This decentralized symmetric key is used instead of the master symmetric key to protect sensitive data.

[0093] As described above, the sending device and the receiving device initially each hold a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the decentralized symmetric key is independently created by the sending device and the receiving device, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the decentralized symmetric key, and the attacker will never see any data processed using the master symmetric key. Only small counter values ​​are processed using the master symmetric key, and sensitive data is not processed in this way. Therefore, the exposure of side channel data related to the master symmetric key is reduced. Moreover, the sender and the receiver can, for example, by previous arrangement or other means, agree on how often a new decentralized value is created, and thus a new decentralized symmetric key is created. In one embodiment, a new decentralized value, and thus a new decentralized symmetric key, can be created for each exchange between the sending device and the receiving device.

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

[0095] In another example, a portion of the counter can be used as a key diversification value. If the parties share multiple master key values, multiple diversification key values ​​can be obtained through the systems and processes described herein. New diversification values, and therefore new decentralized symmetric keys, can be created as often as needed. In the most secure case, a new diversification value can be created for each sensitive data exchange between the sending device and the receiving device. In practice, this can create a one-time use key, such as a one-time session key.

[0096] In other examples, for example, to limit the number of uses of the master symmetric key, the sender of the sending device and the recipient of the receiving device may agree to only periodically create new decentralized values, and therefore new decentralized symmetric keys. In one example, this operation may occur after a predetermined number of uses, such as after every ten transmissions between the sending device and the receiving device. In another example, this operation may occur after a certain period of time; after a certain period of time after a transmission, or this operation may occur periodically (e.g., at a specified time every day; at a specified time on a specified day of the week). In another example, this operation may occur each time the receiving device signals the sending device that it wishes to change the key in the next communication. This operation may be controlled according to a policy and may change due to, for example, the current risk level perceived by the recipient of the receiving device.

[0097] Figure 5AOne or more contactless cards 500 are shown, and the contactless card 500 may include a payment card, such as a credit card, a debit card, or a gift card, issued by a service provider 505 displayed on the front or back of the card 500. The contactless card 500 is unrelated to the 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 laminates composed 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 that conform to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may additionally conform to 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 in the form of a payment card.

[0098] The contactless card 500 may also include identification information 515 displayed on the front and / or back of the card and a contact sheet 520. The contact sheet 520 may be configured to establish communication with another communication device (e.g., a user device, a smartphone, a notebook computer, a desktop computer, or a tablet computer). The contactless card 500 may also include a processing circuit, an antenna, and a Figure 5A Other components not shown in the figure. These components can be located behind the contact sheet 520 or elsewhere on the substrate 510. The contactless card 500 can also include a magnetic stripe or a magnetic tape, which can be located on the back of the card ( Figure 5A not shown).

[0099] like Figure 5B As shown, Figure 5A The contact sheet 520 may include a processing circuit 525 for storing and processing information, the processing circuit including a microprocessor 530 and a memory 535. It is understood that the processing circuit 525 may include other components, including a processor, memory, error and parity / CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives, and anti-tampering hardware necessary to perform the functions described herein.

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

[0101] Memory 535 can be configured to store one or more applets 540, one or more counters 545, and customer identifier 550. One or more applets 540 can include one or more software applications configured to be executed on one or more contactless cards, such as Java Card applets. However, it should be understood that applets 540 are not limited to Java Card applets, but can include any software application that can be run on contactless cards or other devices with limited memory. One or more counters 545 can include digital counters sufficient to store integers. Customer identifier 550 can include a unique alphanumeric identifier assigned to the user of contactless card 500, which can distinguish the user of this contactless card from the user of other contactless cards. In some examples, customer identifier 550 can identify the customer and the account assigned to the customer, and can further identify the contactless card associated with the customer's account.

[0102] The processor and memory elements of the above exemplary embodiments are described with reference to the contact sheet, but the present disclosure is not limited thereto. It should be understood that these elements can be implemented outside the contact sheet 520 or completely separated from the contact sheet 520, or implemented as other elements other than the processor 530 and the memory 535 located in the contact sheet 520.

[0103] In some examples, the contactless card 500 may include one or more antennas 555. One or more antennas 555 may be placed inside the contactless card 500 and around the processing circuit 525 of the contact sheet 520. One or more antennas 555 may be integrated with the processing circuit 525, and one or more antennas 555 may be used with an external booster coil. As another example, one or more antennas 555 may be located outside the contact sheet 520 and the processing circuit 525.

[0104] In one embodiment, the coil of the contactless card 500 can be used as the secondary 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 connection of the contactless card (which can be kept functional by one or more capacitors) to infer the data sent from the terminal. The contactless card 500 can communicate by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal by interference.

[0105] As described above, the contactless card 500 can be built on a software platform (e.g., JavaCard) that can run on a smart card or other device with limited memory, and can securely execute one or more applications or applets. In various mobile application-based use cases, applets can be added to contactless cards to provide a one-time password (OTP) to implement multi-factor authentication (MFA). The applet can be configured to respond to one or more requests (e.g., near field data exchange requests) from a reader (e.g., a mobile NFC reader) and generate an NDEF message that includes a cryptographically secure OTP encoded as an NDEF text tag.

[0106] Figure 6 An NDEF short record layout (SR=1) 600 is shown according to an example embodiment. One or more applets can be configured to encode the OTP as a NDEF Type 4 well-known 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: authentication message can be encoded as ASCII hexadecimal; type-length-value (TLV) data can be provided as personal card issuance parameters that can be used to generate NDEF messages. In one embodiment, the authentication template can include a first record with a well-known index for providing actual dynamic authentication data.

[0107] Figure 7 A message 710 and a message format 720 are shown according to an example embodiment. In one example, if additional tags are to be added, the first byte may be changed to indicate the beginning of the message rather than the end, and subsequent records may be added. Because the ID length is zero, the ID length field and the ID are omitted from the record. An example message may include: UDK AUT Key; Derived AUT Session Key (using 0x00000050); Version 1.0; pATC = 0x00000050; RND = 4838FB7DC171B89E; MAC = <eight calculated bytes>.

[0108] In some examples, data can be stored in a contactless card at the time of personal card issuance by implementing STORE DATA (E2) under Secure Channel Protocol 2. One or more values ​​can be read from the EMBOSS file (in the section specified by the applet ID) by the personal card issuing department, and after authentication and establishment of a secure channel, one or more store data commands can be sent to the contactless card.

[0109] The pUID may include a 16-bit BCD encoded number. In some examples, the pUID may include 14 digits.

[0110]

[0111] In some examples, one or more applets may be configured to maintain their personal card issuance state to allow personal card issuance only after unlocking and authentication. Other states may include a standard state pre-personal card issuance. Upon entering a terminated state, one or more applets may be configured to delete personal card issuance data. In a terminated state, one or more applets may be configured to stop responding to all application protocol data unit (APDU) requests.

[0112] One or more applets may be configured to maintain an applet version (2 bytes) that may be used in authentication messages. In some examples, this version may be interpreted as most significant byte major, least significant byte minor. Rules are configured for each version to interpret the authentication message: for example, for major versions, this may include each major version containing a specific authentication message layout and a specific algorithm. For minor versions, changes to the authentication message or cryptographic algorithm are not included, except for bug fixes, security enhancements, etc., and changes to static label content.

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

[0114] In some examples, the contactless card and the server may include specific data so that the card can be correctly identified. The contactless card may include one or more unique identifiers. The counter may be configured to be updated each time a read operation occurs. In some examples, each time a card is read, it is sent to the server for verification and to determine whether the counter is equal (as part of the verification).

[0115] One or more counters may be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if the counter has been read or used or otherwise skipped. 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.

[0116] In some examples, the counter may be out of sync between the contactless card and one or more servers. For example, the contactless card may be activated to update the counter and cause the contactless card to generate new communications, but the communications cannot be sent to the one or more servers for processing. This may cause the counter of the contactless card to be out of sync with the counter maintained on the one or more servers. For example, this may occur unintentionally, such as when the card is placed near the device (e.g., in a pocket with the device), and when the contactless card is read at a certain angle, the card is not aligned or positioned correctly, so that the contactless card is connected to the NFC field, but cannot be read. If the contactless card is placed near the device, the NFC field of the device may turn on and power the contactless card, causing the counter therein to be updated, but the application on the device fails to receive the communication.

[0117] To keep the counters synchronized, an application such as a background application may be executed that is configured to detect when the mobile device wakes up and synchronizes with one or more servers, thereby indicating that the read performed due to the detection then advances the counter. Since the counter of the contactless card may not be synchronized with the counter of the one or more servers, the one or more servers may 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 being 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 each time the contactless card is activated, the one or more servers may allow any counter value it reads from the contactless card to be valid, or any counter value is within a threshold range (e.g., from 1 to 10). Moreover, the one or more servers may be configured to request a gesture associated with the contactless card, such as a user tap, provided that the counter value it reads has exceeded 10 but is below another threshold range value (e.g., 1000). After the user taps, if the counter value is within the expected or accepted range, the authentication is successful.

[0118] Figure 8 8 is a flow chart illustrating key operation 800 according to an example embodiment. Figure 8As shown, at block 810, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and the card serial number to generate two unique derived keys (UDKs) per card. In some examples, the bank identifier number may 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 that may be used for session key generation and / or decentralization. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personal card issuance process.

[0119] At block 820, the counter may be used as decentralization data so that it changes at each use and provides a different session key each time, as opposed to master key derivation where a unique set of keys is generated for each card. In some examples, it is preferred to use a 4-byte approach for both operations. Thus, at block 820, two session keys may be created by the UDK for each transaction, i.e., one from the AUTKEY and one from the ENCKEY. In the card, for the MAC key (i.e., the session key created by the AUTKEY), the two lower bytes of the OTP counter may be used for decentralization. For the ENC key (i.e., the session key created by the ENCKEY), the full length of the OTP counter may be used for the ENC key.

[0120] At block 830, a MAC password may be prepared using the MAC key and the password may be encrypted using the ENC key. For example, a password may be prepared using the MAC session key and the result may be encrypted using the ENC key before being sent to one or more servers.

[0121] At block 840, verification and processing of the MAC is simplified because 2-byte decentralization is directly supported in the MAC authentication function of the payment HSM. Decryption of the password is performed before MAC verification. The session key is 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, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

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

[0123] In some examples, since the EMV session key derivation method may wrap up after 2^16 uses, a counter such as a full 32-bit counter may be added to the initialization array of the decentralization method.

[0124] In other examples (eg, credit cards), one or more server-provided numbers (eg, account numbers or unpredictable numbers) may be used for session key generation and / or decentralization.

[0125] Fig. 9 A diagram of a system 900 configured to implement one or more embodiments of the present disclosure is shown. As described below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys can include a symmetric key that can be used for both encryption and decryption of data. EMV can use a triple DES (3DES) algorithm that is implemented by hardware in the contactless card. By using a key decentralization process, one or more keys can be derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0126] With regard to master key management, two issuer master keys 905, 910 are required for each portion of the folder where one or more applets are issued. For example, the first master key 905 may include an issuer password generation / authentication key (Iss-Key-Auth), and the second master key 910 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 905, 910 are decentralized into master keys 925, 930 of the card, which are unique to each card. In some examples, a network profile record ID (pNPR) 915 and a derived key index (pDKI) 920 as background data may be used to identify which issuer master keys 905, 910 are used for authentication in the cryptographic process. The system performing the authentication may be configured to retrieve the values ​​of the pNPR 915 and pDKI 920 of the contactless card at the time of authentication.

[0127] In some examples, to improve the security of the solution, session keys (e.g., unique keys for each session) may be derived instead of using a master key, and as described above, unique card derived keys and counters may be used as decentralized data. For example, each time a card is used in an operation, a different key may be used to create a message authentication code (MAC) and perform encryption. With respect to session key generation, keys used to generate passwords and encrypt data in one or more applets may include session keys based on card unique keys (Card-Key-Auth 925 and Card-Key-Dek 930). Session keys (Aut-Session-Key 935 and DEK-Session-Key 940) may be generated by one or more applets and may be derived using an application transaction counter (pATC) 945 using one or more algorithms. In order to make the data suitable for one or more algorithms, only the 2 low-order bytes of the 4-byte pATC 945 are used. In some examples, a four-byte session key derivation method may include: F1: =PATC(2 low-order bytes)||'F0'||'00'||PATC(four bytes) F1: =PATC(2 low-order bytes)||'0F'||'00'||PATC(four bytes) SK: ={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG contains 3DES ECB and MK contains the card-unique derived master key.

[0128] As described herein, one or more MAC session keys may be derived using the two lower bytes of the pATC 945 counter. The pATC 945 is configured to be updated each time a contactless card is tapped, and the card master keys Card-Key-AUTH 925 and Card-Key-DEK 930 are further decentralized into session keys Aut-Session-Key 935 and DEK-Session-KEY 940. The pATC 945 may be initialized to zero upon personal card issuance or applet initialization. In some examples, the pATC counter 945 may be initialized upon or prior to personal card issuance and may be configured to increment by one upon each NDEF read.

[0129] Additionally, updates to each card may be unique and assigned by individual card issuance, or may be algorithmically assigned by pUID or other identifying information. For example, odd-numbered cards increment or decrement by 2, while even-numbered cards increment or decrement by 5. In some examples, updates may also vary when read sequentially, such that a card may increment by 1, 3, 5, 2, 2, ..., and so on. The specific sequence or algorithmic sequence may be defined at individual card issuance, or by one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to infer based on a small number of card instances.

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

[0131] The MAC may be performed by a function key (AUT-Session Key) 935. The data specified in the cipher may be processed with the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 to be associated with the EMV ARQC authentication method. As described above, the key used for this calculation may include the session key AUT-Session-Key 935. As described above, the two lower bytes of the counter may be used to disperse one or more MAC session keys. The AUT-Session-Key 935 may be used to MAC data 950, and the resulting data or cipher A 955 and random number RND may be encrypted using the DEK-Session-KEY 940 to create the cipher B or output 960 sent in the message.

[0132] In some examples, one or more HSM commands may be processed for decryption so that the last 16 (binary, 32 hex) bytes may include a 3DES symmetric encryption using CBC mode containing a random number-zero IV followed by MAC authentication data. The key used for this encryption may include a session key DEK-Session-Key 940 derived from 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.

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

[0134]

[0135]

[0136]

[0137] Another exemplary format is shown below. In this example, the tag may be encoded in hexadecimal format.

[0138]

[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) of a particular card through the master keys Iss-Key-AUTH 905 and Iss-Key-DEK 910. Using the card master keys (Card-Key-Auth 925 and Card-Key-DEK930), 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) of that particular card. Cryptogram B 960 can be decrypted using the DEK-Session-KEY to produce Cryptogram A 955 and RND, which can be discarded. The UID field can be used to look up the contactless card's shared secret, which is processed along with the Ver, UID, and pATC fields of the message using the cryptographic MAC using the recreated Aut-Session-Key to create a MAC output (e.g., MAC'). If the MAC' is the same as the cipher A 955, then both the message decryption and the MAC check have passed. The pATC can then be read to determine if it is valid.

[0142] During the authentication session, one or more applications may generate one or more passwords. For example, the one or more passwords may be generated as a 3DES MAC using ISO 9797-1 Algorithm 3 with Method 2 padding via one or more session keys (e.g., Aut-Session-Key 935). Input data 950 may take the form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the number in parentheses may include a 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 that the random number is unpredictable through one or more security processes. In some examples, the shared secret may include a 4-byte binary random number injected into the card at the time of issuance of the personal card known to the authentication service. During the authentication session, the shared secret is not provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte at the end of the input data and adding 0x'00' bytes at the end of the result data until an 8x boundary is reached. The result password may include a length of 8 bytes.

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

[0144] By including an application transaction counter (pATC) as part of the data contained in the MAC password, the authentication service can be configured to determine whether the value passed in the plaintext data has been tampered with. In addition, by including the version in one or more passwords, it is difficult for an attacker to purposefully misrepresent the application version in an attempt to reduce the strength of the password solution. In some examples, the pATC starts at zero and is updated 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 less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message and the authentication can be rejected. In some examples, if the pATC is greater than the previous value received, it can be determined by evaluation whether it is within an acceptable range or threshold, and if it exceeds or is not within the range or threshold, the authentication can be considered to have failed or is unreliable. In MAC operation 936, the data 950 is processed by MAC using the Aut-Session-Key 935 to produce an encrypted MAC output (password A) 955.

[0145] In order to provide additional protection to prevent brute force attacks that expose the key on the card, the MAC password 955 needs to be encrypted. In some examples, the data or password A 955 to be included in the ciphertext may include: random number (8), password (8). In some examples, the number in brackets may include a length in bytes. In some examples, the random number may be generated by one or more random number generators, which may be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include a DEK-Session-Key 940. In an encryption operation 941, the data or password A 955 and RND are processed using the DEK-Session-Key 940 to generate encrypted data, password B 960. The data 955 can be encrypted using 3DES in a cipher block chaining mode to ensure that an attacker must perform any attack on all ciphertexts. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, a 0x'0000000000000000' initialization vector may be used. Any attacker attempting to brute force the key used to encrypt the data will not be able to determine when the correct key was used because correctly decrypted data cannot be distinguished from incorrectly decrypted data due to its random appearance.

[0146] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plain text from one or more applets to the mobile device during the authentication session: version number; which is used to determine the encryption method used and the message format used to verify the password, allowing the method to change in the future; pUID, which is used to retrieve the cryptographic asset and derive the card key; and pATC; which is used to derive the session key for the password.

[0147] Fig.10 A method 1000 for generating a cryptogram is shown. For example, at block 1010, a network profile record ID (pNPR) and a derived key index (pDKI) may be used to identify which issuer master keys are used for authentication in a cryptographic process. In some examples, this method may include performing authentication to retrieve the values ​​of the pNPR and pDKI of the contactless card at the time of authentication.

[0148] At block 1020, the issuer master key may be decentralized by combining it with the card's unique ID number (pUID) and the PAN serial number (PSN) of one or more applets (eg, a payment applet).

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

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

[0151] Fig.11 An exemplary process 1100 showing key decentralization according to an example is shown. Initially, two different master keys may be provided to a sender and a receiver. For example, a first master key may include a data encryption master key and a second master key may include a data integrity master key. The sender has a counter value (which may be updated at block 1110), as well as other data, such as data to be protected that is ensured to be shared with the receiver.

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

[0153] In some examples, the counter value may not be encrypted. In these examples, the counter may be sent between the sender and the receiver in plain text (ie, without encryption).

[0154] The sender processes the data to be protected using a cryptographic MAC operation using the data integrity session key and the cryptographic MAC algorithm at block 1130. A MAC can be generated using the protected data (including plain text and shared secret) using one of the session keys (AUT-Session-Key).

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

[0156] At block 1150, the encrypted MAC is sent from the sender to the receiver with sufficient information to identify additional confidential information (eg, a shared secret, a master key, etc.) used to verify the password.

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

[0158] At box 1170, the protected data is decrypted using a combination of a session key derived from the encryption of the data and a symmetric decryption operation. Additional processing is then performed on the exchanged data. In some examples, after the MAC is extracted, it is necessary to reproduce and match the MAC. For example, when verifying a password, the password can be decrypted using a properly generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if 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, a data integrity derived session key is used in conjunction with a cryptographic MAC operation to verify that the protected data has not been modified.

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

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

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

[0163] In some examples, a contactless card can be tapped against a device such as one or more computer kiosks or terminals to verify identity, thereby receiving a transaction item, such as coffee, in response to a purchase. By using a contactless card, a secure method of proving identity in a loyalty program can be established. Identity is securely proven in a manner different from simply scanning a bar card, thereby, for example, obtaining rewards, coupons, offers, etc. or receiving benefits. For example, an encrypted transaction can occur between a contactless card and a device that can be configured to process one or more tap gestures. As described above, one or more applications can be configured to, for example, verify the identity of a user via one or more tap gestures, and then allow the user to react or respond to it. In some examples, data such as reward points, loyalty points, bonus points, health care information, etc. can be written back to the contactless card.

[0164] In some examples, the contactless card may be tapped against a device such as a mobile device.As described above, the user's identity may be verified by one or more applications, which then grant the user desired benefits based on the identity verification.

[0165] In some examples, the contactless card can be activated by tapping against a device such as a mobile device. For example, the contactless card can communicate with the device's application via a card reader of the device through NFC communication. Wherein the communication of tapping the card when close to the card reader of the device allows the device's application to read the data associated with the contactless card and activate the card. In some examples, activation can authorize the card to perform other functions, such as purchasing, accessing accounts or restricted information or other functions. In some examples, tapping can activate or start the device's application, and then initiate one or more actions or communications with one or more servers to activate the contactless card. If the application is not installed on the device, tapping the contactless card when close to the card reader will initiate the download of the application, such as navigating to the application download page. After installation, tapping the contactless card can activate or start the application, and then initiate the activation of the contactless card, such as via the application or other back-end 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 may be configured to run on a client device to perform activation of the contactless card. In other embodiments, a web portal, a web-based application, an applet, etc. may perform activation. Activation may be performed on the client device, or the client device may simply act as a channel between the contactless card and an external device (e.g., an account server). According to some embodiments, when providing activation, the application may indicate to the account server the type of device performing the activation (e.g., a personal computer, a smart phone, a tablet computer, or a point of sale (POS) device). In addition, depending on the type of device involved, the application may output (for transmission) different and / or additional data to the account server. For example, such data may include information associated with a merchant, such as a merchant type, a merchant ID, and information associated with the device type itself, such as POS data and a POS ID.

[0167] In some embodiments, the example authentication communication protocol can mimic the offline dynamic data authentication protocol of the EMV standard that is usually performed between a transaction card and a point-of-sale device, with some modifications. For example, since the example 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 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 depends on whether the card issuer recognizes the transaction value. At the same time, in certain embodiments of the present disclosure, transactions originating from mobile devices lack transaction values ​​associated with the POS system. Therefore, in some embodiments, a virtual transaction value (i.e., a value that is recognizable by the card issuer that is sufficient to allow activation to occur) can be passed as part of the example authentication communication protocol. POS-based transactions can also reject transactions based on the number of transaction attempts (e.g., a transaction counter). The number of attempts exceeding the buffer value may result in a gentle rejection, which requires further verification to accept the transaction. In some implementations, the buffer value of the transaction counter can be modified to avoid rejecting legitimate transactions.

[0168] In some examples, the contactless card can selectively transmit information based on the recipient device. Once tapped, the contactless card can identify the device to which the tap is directed, and based on that identification, the contactless card can provide the appropriate data for that device. This advantageously allows the contactless card to send only the information required to complete the immediate operation or transaction (e.g., payment or card authentication). By limiting the transmission of data and avoiding the transmission of non-essential data, both efficiency and data security can be improved. The identification and selective transmission of information can be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and fraud reduction.

[0169] If the contactless card is tapped towards a device running Apple If you have a device running the same operating system (such as an iPhone, iPod or iPad), the contactless card can be recognized The system operates the system and transmits the appropriate data to communicate with the device. For example, a contactless card can use an NDEF tag, such as via NFC, to provide the encrypted identity information necessary to authenticate the card. Similarly, if a contactless card is tapped against the operating system, Operating system devices (such as smartphone or tablet), the contactless card can be recognized The system operates and transmits appropriate data to communicate with the device (such as encrypted identity information required for authentication via the methods described herein).

[0170] As another example, the contactless card tap can be directed to a POS device, including but not limited to a sales kiosk, a checkout counter, a payment station, or other terminal. When performing the tap, the contactless card can identify the POS device and send only the information required for the operation or transaction. For example, after identifying the POS device used to complete 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, a POS device participating in a transaction may require 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 data communications from a contactless card, the POS device may identify the contactless card and request additional information required to complete the operation or transaction.

[0172] In some examples, the POS device may be affiliated with an authorized merchant or other entity that is familiar with certain contactless cards or accustomed to performing specific contactless card transactions. However, it should be understood that such an affiliation is not required to perform the described methods.

[0173] In some examples, such as shopping malls, grocery stores, convenience stores, etc., a contactless card may be tapped against a device without opening an application to indicate a desire or intent to use one or more of reward points, loyalty points, coupons, offers, etc. to fulfill one or more purchases, thereby providing the intent behind the purchase.

[0174] In some examples, one or more applications may be configured to determine that it was initiated via one or more tap gestures of a contactless card, was initiated at 3:51 PM, and a transaction was processed or occurred at 3:56 PM, thereby authenticating 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, the one or more actions can include collecting rewards, collecting points, determining the most important purchases, determining the lowest cost purchases, and / or reconfiguring to another action in real time.

[0176] In some examples, data can be collected when the tapping behavior occurs to perform biometric / gesture authentication. For example, a unique identifier that is password protected and not easily intercepted can be sent 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 a contactless card.

[0177] In some examples, a device may include an application to split a bill payment or check between multiple individuals. For example, each person holds a contactless card and is a customer of the same issuing financial institution, but this is not required. Each of these people receives a push notification on their device via the application to split the purchase. Rather than accepting only a tap of one card indicating payment, other contactless cards are also used. In some examples, individuals with different financial institutions may hold contactless cards to provide information to initiate one or more payment requests from the individuals tapping the cards.

[0178] The following exemplary use cases describe examples of specific implementations of the present disclosure. These are for illustrative purposes only and not for limitation. In one case, a first friend (payer) owes a second friend (payee) a sum of money. The payer wants to pay using a contactless card through the payee's smartphone (or other device) instead of going to an ATM or transacting through a peer-to-peer application. The payee logs into the appropriate application on his 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 to ask the payee to tap his contactless card. Once the payee taps the contactless card against the screen of the smartphone with the application enabled, the contactless card is read and verified. Next, the application displays a prompt asking the payee to tap his contactless card for payment. After the payee taps his contactless card, the application reads the card information and sends the payment request to the payee's card issuer via an associated processor. The card issuer processes the transaction and sends a status indication of the transaction to the smartphone. Then, the application outputs a status indication to display the transaction.

[0179] In another example scenario, a credit card customer may receive a new credit card (or debit card, other payment card, or any other card that requires activation) via the mail. Rather than activating the card by calling a provided phone number or visiting a website associated with the card issuer, the customer may decide to activate the card via an application on their device (e.g., a mobile device such as a smartphone). The customer may select a card activation function from an application menu displayed on the device display. The application prompts the customer to tap their credit card against the screen. After tapping the credit card against the device screen, the application may be configured to communicate with a server (e.g., a card issuer server that activates the customer's card). The application may then display a message indicating that the card was successfully activated. Activation of the card is then complete.

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

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

[0182] At box 1220, one or more portions of the dynamically generated data may be transmitted to an application of the device via NFC or other wireless communication. For example, tapping a card close to the device allows an 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 help activate the card, tapping the card may direct the device or prompt the customer to a software application store to download an associated application to activate the card. In some examples, the user may be prompted to perform a satisfactory gesture, placement, or orientation of the card toward the surface of the device, such as placing the card on, near, or near the surface of the device at an angle or flatly. In response to performing a satisfactory gesture, placement, and / or orientation of the card, the device may proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0183] At block 1230, one or more portions of the data may be transmitted to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data may 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 the 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 to compare the received data with recorded data accessible to one or more servers. If the comparison of the one or more decrypted portions of the data by the one or more servers indicates a successful match, the card may be activated. If the comparison of the one or more decrypted portions of the data by the one or more servers indicates an unsuccessful match, one or more processes may occur. For example, in response to determining that the match is unsuccessful, the user may be prompted to perform an action of tapping, swiping, or waving the card again. In this case, there is a predetermined threshold that includes the number of attempts to allow the user to activate the card. Alternatively, the user may receive a notification such as a message on their device indicating that the card verification attempt was unsuccessful and call, email, or text an associated service to request assistance in activating the card; or receive a notification such as a phone call indicating that the card verification attempt was unsuccessful on their device and call, email, or text an associated service to request assistance in activating the card; or receive a notification such as an email indicating that the card verification attempt was unsuccessful and call, email, or text an associated service to request assistance in activating the card.

[0185] At block 1250, the one or more servers may send a return message based on the successful activation of the card. For example, the device may be configured to receive an output from the one or more servers indicating that the one or more servers successfully activated the card. The device may be configured to display a message indicating that the card was successfully activated. Once the card is activated, the card may be configured to cease dynamically generating data to avoid fraudulent use. In this way, the card may be deactivated 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 his financial account on his 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 can see first-level account information (e.g., recently purchased items) and is 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 limits) or perform second-level account options (e.g., transfers to an external system), he must have a second-level factor authentication. Therefore, the application requests the user to 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 whether the credit card corresponds to the user's account. Thereafter, the user can view second-level account data and / or perform second-level account functions.

[0187] Fig.13 A method of performing one or more gaming operations using a contactless card according to an example embodiment is shown. For example, the method 1300 may include triggering at least one of a gaming, a credit, a message, or a lottery process, as further described herein.

[0188] Method 1300 may start at block 1310, where communication is initiated between a sending device or user device (such as a contactless card) and a client device or a receiving device. The contactless card and the client device or the receiving device may be devices as described above. For example, the client device may include a system such as a POS device, a self-service terminal, a terminal, a tablet computer, a mobile device, a computer with network capabilities, a server, and combinations thereof, and the contactless card may be configured to send data to and receive data from the client device via short-range communication, including but not limited to NFC, WiFi, or Bluetooth communication.

[0189] At block 1320 , method 1300 may include authenticating the contactless card based on one or more user credentials in accordance with the systems and methods described herein.

[0190] At block 1330, method 1300 may include performing one or more processes in response to authentication of one or more user credentials of the contactless card of block 1320. In some examples, performing one or more processes in response to authentication of one or more user credentials of the contactless card may include triggering at least one of a game, a points, a message, or a lottery process.

[0191] At block 1340, method 1300 may include updating data or records on the contactless card.

[0192] In some examples, a user may wish to use his or her contactless card to play a scavenger hunt in order to receive points and offers. For example, a scavenger hunt application may be executed on a client device or system. The system may be configured to authenticate the contactless card based on one or more user credentials received from the contactless card. In some examples, the system may be configured to retrieve data from the contactless card to authenticate the contactless card in addition to retrieving one or more user credentials. The user may gesture to the contactless card to indicate a tap, a wave, or other gestures, which may be communicated to the system via short-range communications (including but not limited to NFC, WiFi, or Bluetooth communications).

[0193] For example, as part of a scavenger hunt, a user may visit multiple places, monuments, or famous places. In some examples, the scavenger hunt application may be associated with a user account, which may be associated with one or more bank accounts. After visiting one or more places, monuments, or famous places during the scavenger hunt, the user may receive one or more reward points and offers. The points or offers may be redeemed in association with one or more bank accounts.

[0194] In some examples, a user can receive credits into one or more user accounts to visit one or more places, monuments, or famous places during a scavenger hunt. For example, credits can be redeemed for one or more products or services. A user can decide to allocate credits to one or more user accounts based on one or more user preferences. For example, a first portion of credits can be used to redeem or purchase a first product, and a second portion of credits can be used to increase a credit balance of a user account associated with a loyalty or points or airplane account.

[0195] In some examples, a user may receive credits to one or more user accounts for access to one or more places, monuments, or famous locations during a scavenger hunt. For example, an offer may be associated with a discounted or free purchase of one or more products or services. In addition, based on a comparison of transaction history (e.g., recent purchase history) by one or more servers, one or more offers for products or services that suggest or predict similar purchases may be provided to the user.

[0196] In the foregoing example, users no longer need to wait in line or queue to process tickets for the scavenger hunt, and access and user authentication via contactless cards are improved, thereby providing greater security. In addition, users earn points and benefits through contactless card authentication and interaction with one or more applications related to the scavenger hunt.

[0197] Fig.14 A method of displaying one or more messages using a contactless card according to an example embodiment is shown.For example, the method 1400 may include initiating an action associated with playing or displaying at least one of an audible and visual message based on the authentication.

[0198] Method 1400 may start at block 1410, where communication is initiated between a sending device or user device (such as a contactless card) and a client device or a receiving device. The contactless card and the client device or the receiving device may be devices as described above. For example, the client device may include a system such as a POS device, a self-service terminal, a terminal, a tablet computer, a mobile device, a computer with network capabilities, a server, and combinations thereof, and the contactless card may be configured to send data to and receive data from the client device via short-range communication, including but not limited to NFC, WiFi, or Bluetooth communication.

[0199] At block 1420 , method 1400 may include authenticating the contactless card based on one or more user credentials in accordance with the systems and methods disclosed herein.

[0200] At block 1430, method 1400 may include performing one or more processes in response to authentication of one or more user credentials of the contactless card of block 1420. In some examples, performing one or more processes in response to authentication of one or more user credentials of the contactless card may include playing or displaying at least one of an audible and visual message.

[0201] In some examples, a user may wish to use his or her contactless card to receive audible and / or visual messages. The messages may be delivered in conjunction with an application, for example, a mobile application may be executed on a client device or system. For example, the system may be configured to authenticate the contactless card based on one or more user credentials received from the contactless card. In some examples, the system may be configured to retrieve data from the contactless card to authenticate the contactless card in addition to retrieving one or more user credentials. The user may gesture to the contactless card to indicate a tap, a wave, or other gesture, which may be communicated to the system via short-range communications (including but not limited to NFC, WiFi, or Bluetooth communications).

[0202] The user can use the contactless card to indicate one or more gestures to the user's mobile device. Before sending an audible and / or visual message from the mobile device via one or more mobile applications, the mobile device can be configured to authenticate one or more user credentials received from the contactless card. In some examples, after authenticating the one or more user credentials, the mobile device can send an audible message. The audible message can include a funny message.

[0203] In some examples, via one or more gestures, the audible message can be repeated at one or more predetermined intervals, can be played only once, or include different funny messages when each gesture is made to the contactless card. Each type of gesture (e.g., a tap gesture or a waving gesture) can indicate different types of funny messages played by the mobile device, respectively. The audible message played can be associated with a database accessible to the mobile phone, or can be retrieved from one or more servers. The audible message can include a fixed duration, which lasts from two or three seconds to ten seconds or more. In some examples, the funny message can include female and / or male voices. The funny message can include a first portion duration of a female voice, a second portion duration of a male voice, or any combination thereof. The funny message can be selectively selected or randomly selected to be played. In some examples, the funny message can include English and / or non-English voices.

[0204] In other examples, the message may alternatively or additionally include a visual message displayed via a mobile device. The visual message may include a funny message. In some examples, via one or more gestures, the visual message may be repeated at one or more predetermined intervals, may be played only once, or may include different funny messages when each gesture is made to the contactless card. Each type of gesture (e.g., a tap gesture, a wave, or a swipe) may indicate a different type of funny message displayed by the mobile device, respectively. The displayed visual message may be associated with a database accessible to a mobile phone, or may be retrieved from one or more servers. The visual message may include a fixed duration, which may be from two or three seconds up to ten or more seconds. Funny messages may be selectively selected or randomly selected to be displayed. In some examples, funny messages may include English and / or non-English text.

[0205] In this way, users no longer need to browse through numerous windows or prompts of an application or search and find funny messages through their mobile devices, and access and user authentication via contactless cards is improved, providing greater security.

[0206] At block 1440, method 1400 may include updating data or records on the contactless card.

[0207] In some examples, a user may wish to use his or her contactless card to play games and win tickets. Playing games and winning tickets can be performed in conjunction with applications such as mobile applications executed on client devices or systems. For example, the system can be configured to authenticate the contactless card based on one or more user credentials received from the contactless card. In some examples, the system can be configured to retrieve data from the contactless card to authenticate the contactless card in addition to retrieving one or more user credentials. The user can gesture to the contactless card to indicate a tap, a wave, or other gestures, which can be communicated to the system via short-range communications (including but not limited to NFC, WiFi, or Bluetooth communications).

[0208] For example, a user may gesture a contactless card toward a client device. After authenticating the contactless card via one or more gestures, the application may allow the user to win tickets, such as lottery tickets, concert tickets, sports tickets, conference tickets, event tickets, restaurant coupons, cash rewards, loyalty rewards, and combinations thereof. In some examples, the user may interact with the application to win tickets. In other examples, the user may provide information to the application to conduct a raffle or draw, so that the user is eligible and has the opportunity to win a ticket.

[0209] In the aforementioned example, users may no longer need to wait in line to provide authentication information to win tickets, and users may no longer need to manually enter identity and redemption information when using games to win tickets. In addition, access and user authentication via contactless cards are improved, thereby providing higher security.

[0210] Throughout the specification, reference is made to various accounts, such as bank accounts, credit card accounts, and debit accounts. However, it should be understood that the present disclosure is not limited to specific bank accounts, and may include any financial account, as well as accounts related to entertainment, loyalty programs, utilities, and other services.

[0211] In some examples, the present disclosure relates to the 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 a card or performing other actions on a card).

[0212] Throughout the specification and claims, the following terms have at least the meanings explicitly associated herein unless the context clearly dictates otherwise. The term "or" is intended to mean an inclusive "or". In addition, the terms "a", "an", and "the" are intended to mean one or more, unless otherwise specified or clear from context to indicate a singular form.

[0213] In this specification, many specific details have been set forth. However, it should be understood that the implementation 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 specification. References to "some examples", "other examples", "an example", "an example", "various examples", "an embodiment", "an embodiment", "some embodiments", "example embodiments", "various embodiments", "an implementation", "an implementation", "example implementation", "various implementations", "some implementations", etc. indicate that the implementation of the disclosed technology described in this way may include specific features, structures or characteristics, but not every implementation must include the specific characteristics, structures or characteristics. In addition, repeated use of the phrases "in one example", "in one embodiment" or "in an implementation" does not necessarily refer to the same example, embodiment or implementation, although it may be so indicated.

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

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

[0216] This written description uses examples to disclose certain implementations of the disclosed technology, including the best mode, and also to enable any person skilled in the art to practice certain implementations of the disclosed technology, including making and using any devices or systems and performing any incorporated methods. The patentable scope of certain implementations 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 structural elements that do not differ from 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. A system comprising: A device having a processor and a memory; The device comprises an application comprising instructions for execution on the device, wherein the application is configured to: Receive credentials from a contactless card where: the credential being sent by the contactless card after one or more entries of the contactless card into the communication field of the device, the one or more entries comprising one or more gestures, and After authentication of the credentials is determined by the application, executing one or more processes by the application, wherein the one or more processes include playing or displaying, via the device, at least one item selected from the group consisting of an audible message and a visual message, and wherein at least one of the processes selected from the audible message and the visual message is selected based on one or more gestures representing different messages, and The one or more gestures include at least one selected from tapping, swiping, and swiping.

2. The system according to claim 1, wherein: The visual message is repeated at one or more predetermined intervals.

3. The system according to claim 1, wherein: The audible message is repeated at one or more predetermined intervals.

4. The system according to claim 1, wherein: The application is also configured to provide redeemable credits to a user account associated with the game.

5. The system according to claim 1, wherein: The application is also configured to provide offers to user accounts associated with the game.

6. The system according to claim 1, wherein: At least one item selected from the group of audible messages and visual messages is associated with a database accessible to the application.

7. The system of claim 1, wherein: The application is further configured to provide a ticket to a user account, and The ticket includes at least one item selected from the group of lottery tickets, concert tickets, sporting event tickets, conference tickets, and restaurant coupons.

8. A method comprising: Credentials are received from a contactless card by an application comprising instructions for execution on a device, wherein: the credential being sent by the contactless card after one or more entries of the contactless card into the communication field of the device, the one or more entries comprising one or more gestures, and After authentication of the credentials is determined by the application, executing one or more processes by the application, wherein the one or more processes include playing or displaying, by the application, at least one item selected from the group consisting of an audible message and a visual message, and wherein at least one of the processes selected from the audible message and the visual message is selected based on one or more gestures representing different messages, and The one or more gestures include at least one selected from tapping, swiping, and swiping.

9. The method of claim 8, wherein the at least one process comprises repeating at least one selected from the audible message and the visual message at a predetermined interval.

10. The method according to claim 8, further comprising: Prior to playing or displaying the at least one item selected from the group of audible messages and visual messages, the at least one item selected from the group of audible messages and visual messages is retrieved by the application from one or more servers.

11. The method according to claim 8, wherein: The audible message comprises a first part and a second part, The first part includes female voices, and The second portion includes male speech.

12. A system comprising: A contactless card comprising a processor and a memory, the memory of the contactless card comprising a credential, wherein the contactless card is configured to send the credential to an application executed on a user device upon entering a communication field of the user device; and The application comprising instructions for execution on the user device having a processor and a memory, wherein the application is configured to: receiving said credential from said contactless card, After confirming the authentication of said credentials, executing one or more processes by the application, wherein the one or more processes include playing or displaying, via the user device, at least one item selected from the group of an audible message and a visual message, wherein at least one process is selected from the audible message and the visual message within a randomly selected time period, wherein at least one of the selected from the audible message and the visual message is selected based on one or more gestures, whereby each of the one or more gestures represents a different message, and The one or more gestures include at least one selected from tapping, swiping, and swiping.

13. The system according to claim 12, wherein: The visual message is repeated at one or more predetermined intervals.

14. The system according to claim 12, wherein: The audible message is repeated at one or more predetermined intervals.

15. The system of claim 12, wherein: A second process of the one or more processes includes a scavenger hunt to receive at least one selected from bonus points and offers, The hidden object game includes visiting at least one selected from a place, a monument, a destination, and a famous place during the hidden object game, and At least one selected from the reward points and offers is associated with one or more user accounts.

16. The system of claim 12, wherein: The audible message includes at least one item selected from the group of English speech and non-English speech.

17. The system of claim 12, wherein: The visual message includes at least one item selected from the group of English text and non-English text.

18. The system of claim 12, wherein: One or more predetermined intervals of repeating the audible message are associated with the one or more gestures.

19. The system of claim 13, wherein: One or more predetermined intervals of repeating the visual message are associated with the one or more gestures.

20. The system of claim 12, wherein: The memory of the contactless card also contains records; The contactless card is configured to update the record when performing the one or more processes.

Images