System and method for encrypted authentication of contactless cards

Abstract

To provide a system and a method for secure communication between a sending device and a receiving device.SOLUTION: A method includes the steps of initiating an operation, pausing the operation until a user's identity is authenticated, authenticating the user's identity after a transmitting device comes into communication range of a receiving device and transmits identification data encrypted using the diversified key from the transmitting device to the receiving device application, and completing the operation.SELECTED DRAWING: None

Description

Technical Field

[0001] Cross - References to Related Applications This application claims priority to U.S. Patent Application No. 16 / 351,441, filed Mar. 12, 2019, which is a continuation - in - part of U.S. Patent Application No. 16 / 205,119, filed Nov. 29, 2018, which claims priority to U.S. Provisional Patent Application No. 62 / 740,352, filed Oct. 2, 2018, the disclosure of which is incorporated herein by reference in its entirety.

[0002] The present disclosure relates to encryption, more specifically, systems and methods for encrypted authentication of contactless cards.

Background Art

[0003] The security of data and the integrity of transactions are very important for both businesses and consumers. As electronic transactions make up an increasingly large share of commercial activities, this need continues to grow.

[0004] Email can be used as a tool to verify transactions, but email is vulnerable to attacks and is susceptible to hacking and other unauthorized access. Short Message Service (SMS) messages can also be used, but they can also be compromised. Additionally, data encryption algorithms such as the Triple DES algorithm have similar vulnerabilities.

[0005] Activating many cards, including financial cards (e.g., credit cards and other payment cards), requires a time-consuming process where the cardholder makes a phone call, visits a website, or enters and provides card information. Furthermore, while the increasing use of chip-based financial cards offers more security features than previous technologies for in-person purchases (e.g., magnetic stripe cards), access to accounts may still rely on login credentials (e.g., username and password) to verify the cardholder's identity. However, if login credentials are compromised, another person may be able to access the user's account.

[0006] These and other shortcomings exist. Therefore, in order to provide data security, authentication, and verification for contactless cards, users need to be provided with appropriate solutions to overcome these shortcomings. Furthermore, both improved methods for activating cards and improved authentication for account access are needed. [Overview of the Initiative]

[0007] The disclosed embodiments of the technology include systems and methods for cryptographic authentication of contactless cards. Various embodiments describe systems and methods for performing and managing cryptographic authentication of contactless cards.

[0008] Embodiments of this disclosure are systems for secure communication, comprising: a transmitting device having a processor and memory, the transmitting device's memory containing a diversified master key, transmission data, and a counter value; an application comprising instructions for execution on a receiving device having a processor and memory, the receiving device's memory containing a master key; the transmitting device generates a diversified key using the diversified master key, one or more encryption algorithms, and a counter value; generates an encrypted result containing the counter value using one or more encryption algorithms and the diversified key; and transmits the transmission data using one or more encryption algorithms and the diversified key. The system is configured to encrypt, generate encrypted transmission data, and send the encrypted results and encrypted transmission data to an application, the application being configured to generate an authentication diversification key based on a master key and a unique identifier, generate a session key based on the authentication diversification key and the encryption results, decrypt the encrypted transmission data, and verify the received encryption results using one or more encryption algorithms and the session key, the system is further configured to, at the start of operation, request user identification, pause operation until user identification is authenticated, and complete operation upon authentication of user identification, providing a system for secure communication after the transmitting device enters the communication range of the receiving device.

[0009] Embodiments of the present disclosure are methods for ensuring operation, the methods comprising: providing a transmitting device comprising a processor and memory, wherein the memory of the transmitting device comprises a diversified master key, identity data, and a counter value; and providing an application comprising instructions for execution on a receiving device comprising a processor and memory comprising a master key, wherein the transmitting device generates a diversified key using the diversified master key, one or more encryption algorithms, and a counter; generates an encryption result comprising a counter value using one or more encryption algorithms and the diversified key; encrypts identity data using one or more encryption algorithms and the diversified key; generates encrypted identity data; and the encryption result and encryption A method is provided which includes the steps of: sending encrypted identification data to an application, the application generating an authentication diversification key based on a master key and a unique identifier, generating a session key based on the authentication diversification key and the encryption result, decrypting the encrypted identification data, and verifying the received encryption result using one or more encryption algorithms and the session key; and the method provides an operation which includes the steps of: initiating an operation; pausing the operation until the user's identity is authenticated; authenticating the user's identity after the transmitting device has entered the communication range of the receiving device, thereby sending encrypted identification data from the transmitting device to the application, wherein the user's identity is provided after the transmitting device has entered the communication range; and completing an operation.

[0010] Further features of the disclosed design and the advantages provided thereby are described in more detail below with reference to specific exemplary embodiments shown in the accompanying drawings. Similar elements are indicated by similar reference designations. [Brief explanation of the drawing]

[0011] [Figure 1A] This is a diagram of a data transmission system according to an exemplary embodiment. [Figure 1B]This figure shows a sequence for providing authenticated access according to an exemplary embodiment. [Figure 2] This is a diagram of a data transmission system according to an exemplary embodiment. [Figure 3] This is a diagram of a system using a contactless card according to an exemplary embodiment. [Figure 4] This is a flowchart illustrating a key diversification method according to an exemplary embodiment. [Figure 5A] This is a diagram of a contactless card according to an exemplary embodiment. [Figure 5B] This is a diagram of a contact pad for a contactless card according to an exemplary embodiment. [Figure 6] This figure shows a message for communicating with a device according to an exemplary embodiment. [Figure 7] This figure shows a message and message format according to an exemplary embodiment. [Figure 8] This is a flowchart showing the key operation according to an exemplary embodiment. [Figure 9] This is a diagram of a key system according to an exemplary embodiment. [Figure 10] This is a flowchart of a method for generating a cryptographic code according to an exemplary embodiment. [Figure 11] This is a flowchart illustrating the key diversification process according to an exemplary embodiment. [Figure 12] This is a flowchart illustrating a method for card activation according to an exemplary embodiment. [Figure 13] This flowchart shows a method for accessing restricted functions and information using a contactless card according to an exemplary embodiment. [Figure 14] This flowchart shows how to contact customer support using a contactless card according to an exemplary embodiment. [Modes for carrying out the invention]

[0012] The following description of embodiments provides non-limiting representative examples that refer to figures specifically to illustrate features and teachings of different aspects of the invention. It should be recognized from the description of embodiments that the described embodiments can be practiced separately or in combination with other embodiments. Those skilled in the art should be able to learn and understand the different described aspects of the invention. The description of embodiments should facilitate understanding of the invention to the extent that other embodiments, which are not specifically covered but are within the knowledge of those skilled in the art who have read the description of embodiments, will be understood to be consistent with the application of the invention.

[0013] An objective of some embodiments of this disclosure is to incorporate one or more keys into one or more contactless cards. In these embodiments, the contactless cards can perform authentication and many other functions that may otherwise require the user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, the contactless cards may provide a method for interaction and communication between the user's device (such as a mobile phone) and the card itself. For example, the EMV protocol, which underlies many credit card transactions, includes a sufficient authentication process for the Android® operating system, but presents challenges for iOS®, which is more limited in its use of Near Field Communication (NFC) because it can only be used in read-only mode. Exemplary embodiments of contactless cards described herein utilize NFC technology.

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

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

[0016] System 100 may include a client device 110, which can be a network-enabled computer. As mentioned herein, a network-enabled computer can include, but is not limited to, a computer device, or a communication device such as a server, network appliance, personal computer, workstation, telephone, handheld PC, personal digital assistant, thin client, fat client, Internet browser, or other devices. The client device 110 can also be a mobile device. For example, mobile devices can include Apple's iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark), or other mobile devices running Apple's iOS (registered trademark) operating system, devices running Microsoft's Windows (registered trademark) Mobile operating system, devices running Google's Android (registered trademark) operating system, and / or other smartphones, tablets, or similar wearable mobile devices.

[0017] The client device 110 can include a processor and a memory. The processing circuitry can include additional components such as a processor, a memory, an error and parity / CRC checker, a data encoder, a collision avoidance algorithm, a controller, a command decoder, security primitives, and tamper protection hardware as necessary to perform the functions described herein. The client device 110 can further include a display and an input device. The display can 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 can include any device for inputting information available and supported by the user's device into the user's 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 camcorder. These devices can be used to input information and interact with the software and other devices described herein.

[0018] In some examples, the client device 110 of the system 100 can execute one or more applications, such as a software application, that enables network communication with one or more components of the system 100 and transmits and / or receives data.

[0019] A client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a front-end to back-end pair with each of the servers 120. The client device 110 can send one or more requests to the server 120, for example, from a mobile device application running on the client device 110. One or more requests may be associated with retrieving data from the server 120. The server 120 can receive one or more requests from the client device 110. Based on 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 the receipt of the requested data from one or more databases, the server 120 may be configured to send the received data to the client device 110, and the received data responds to one or more requests.

[0020] System 100 may include one or more networks 115. In some examples, network 115 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 110 to a server 120. For example, network 115 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless local area networks (LANs), global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth®, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0021] Furthermore, network 115 includes, but is not limited to, global networks such as telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or the Internet. Additionally, network 115 can support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 115 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 115 can utilize one or more protocols of one or more network elements that are communicatively coupled together. Network 115 can translate to one or more protocols of network devices between other protocols. Although network 115 is presented as a single network, it should be understood that, according to one or more examples, network 115 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

[0022] System 100 may include one or more servers 120. In some examples, server 120 may include one or more processors coupled to memory. Server 120 may be configured as a central system, server, or platform for controlling and retrieving 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 connect to at least one client device 110.

[0023] Figure 1B is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may comprise a contactless card 105 and a client device 110, which may include an application 122 and a processor 124. Figure 1B can refer to components similar to those shown in Figure 1A.

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

[0025] In step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when the contactless card 105 is read by application 122. In particular, this may occur during reading, such as NFC reading of a Near Field Radio Data Exchange (NDEF) tag, which may be created according to the NFC Data Exchange format. For example, a reader such as application 122 may send a message, such as an applet selection message, using the applet ID of the NDEF generation applet. Once the selection is confirmed, a series of selection file messages followed by read file messages may be sent. For example, the sequence may include "Select Function File", "Read Function File", and "Select NDEF File". At this point, a counter value maintained by the contactless card 105 may be updated or incremented, followed by "Read NDEF File". At this point, a message containing a header and a shared secret may be generated. Next, a session key can be generated. The MAC ciphertext can be constructed from the message. The message may include a header and a shared secret. Next, the MAC ciphertext can be concatenated with one or more blocks of random data, and the MAC ciphertext and random numbers (RND) can be encrypted with the session key. Then, the ciphertext and header can be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to the "Read NDEF File" message).

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

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

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

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

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

[0031] In some cases, MAC ciphertext verification may be performed by a device other than the client device 110, such as a server 120 communicating data with the client device 110 (as shown in Figure 1A). For example, the processor 124 can output the MAC ciphertext for transmission to the server 120, which can verify the MAC ciphertext.

[0032] In some cases, MAC ciphertext can function as a digital signature for verification purposes. To perform this verification, public-key asymmetric algorithms, such as the RSA algorithm or other digital signature algorithms like zero-knowledge protocols, can be used.

[0033] Figure 2 shows a data transmission system according to an exemplary embodiment. System 200 may include one or more servers 220 and a transmitting or transmitting device 205, a receiving or receiving device 210, communicating, for example, over a network 215. The transmitting or transmitting device 205 may be the same as or similar to the client device 110 discussed above with reference to Figure 1A. The receiving or receiving device 210 may be the same as or similar to the client device 110 discussed above with reference to Figure 1A. The network 215 may be similar to the network 115 discussed above with reference to Figure 1A. The server 220 may be similar to the server 120 discussed above with reference to Figure 1A. Although Figure 2 shows a single instance of the components of system 200, system 200 may include any number of the illustrated components.

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

[0035] It is also important not to use the same key multiple times. Frequent use or reuse of a key can compromise it. Each time a key is used, the attacker is provided with additional samples of data processed by the same encryption algorithm using that key. The more data processed with the same key an attacker possesses, the higher the chance they will discover the key's value. Frequently used keys can be targeted in a variety of attacks.

[0036] Furthermore, each time a symmetric encryption algorithm is executed, information such as side-channel data about the key used during the symmetric encryption operation may be revealed. Side-channel data may include slight power fluctuations that occur when the encryption algorithm is executed while the key is in use. By thoroughly measuring the side-channel data, enough information about the key can be revealed to allow an attacker to recover it. If data is exchanged using the same key, data processed with the same key will be repeatedly revealed.

[0037] However, limiting the number of times a particular key is used restricts the amount of side-channel data an attacker can collect, thereby reducing exposure to this attack and other types of attacks. As further described herein, the parties involved in the exchange of cryptographic information (e.g., sender and receiver) must generate keys independently of the initial shared master symmetric key in combination with a counter value, thereby requiring them to periodically replace the shared symmetric key being used and rely on any form of key exchange to maintain synchronization between the parties. Periodically changing the shared secret symmetric key used by the sender and receiver makes the above attack impossible.

[0038] Returning to Figure 2, System 200 can be configured to implement key diversification. For example, a sender and receiver may wish to exchange data (e.g., original confidential data) through their respective devices 205 and 210. As described above, this may include a single instance of the sending device 205 and receiving device 210, but it is understood that one or more sending devices 205 and one or more receiving devices 210 may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending device 205 and receiving device 210 may be provisioned with the same master symmetric key. Furthermore, it is 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 be a shared secret symmetric key that is kept secret from all parties other than the sending device 205 and receiving device 210 involved in the secure exchange of data. Furthermore, it is understood that the same master symmetric key can be provided to both the transmitting device 205 and the receiving device 210, and that some of the data exchanged between the transmitting device 205 and the receiving device 210 may consist of at least a portion of the data which may be called a counter value. The counter value may consist of a number which changes each time data is exchanged between the transmitting device 205 and the receiving device 210.

[0039] System 200 may include one or more networks 215. In some examples, network 215 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect one or more transmitting devices 205 and one or more receiving devices 210 to a server 220. For example, network 215 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless LANs, global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth®, NFC, RFID, Wi-Fi, etc.

[0040] Furthermore, network 215 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 215 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 215 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 215 may utilize one or more protocols of one or more network elements that are communicatively coupled together. Network 215 can translate to one or more protocols of network devices between other protocols. Although network 215 is presented as a single network, it should be understood that, according to one or more examples, network 215 may comprise multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

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

[0042] In block 225, when the transmitting device 205 is preparing to process sensitive data in symmetric encryption operation, the sender can update the counter. Furthermore, the transmitting device 205 can select an appropriate symmetric encryption algorithm, which may include at least one of the symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process the diversified value may be any symmetric encryption algorithm used as needed to generate a diversified symmetric key of the desired length. Non-restrictive 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 produce 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 generate a sufficiently long key.

[0043] In block 230, the transmitting device 205 can employ a selected encryption algorithm and process the counter value using a master symmetric key. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated in every conversation between the transmitting device 205 and the receiving device 210. The transmitting device 205 can then use the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm and create a diversified symmetric key.

[0044] In some examples, the counter value may not be encrypted. In these examples, the counter value may be transmitted unencrypted between the transmitting device 205 and the receiving device 210 in block 230.

[0045] In block 235, sensitive data can be processed using a diversified symmetric key before sending the result to the receiving device 210. For example, the transmitting device 205 can encrypt sensitive data using a symmetric encryption algorithm with a diversified symmetric key, and the output will have protected encrypted data. The transmitting device 205 can then send the protected encrypted data, along with a counter value, to the receiving device 210 for processing.

[0046] In block 240, the receiving device 210 can first obtain a counter value, then use that counter value as input to the encryption, and use the master symmetric key as the key for the encryption to perform the same symmetric encryption. The output of the encryption can be the same variety of symmetric key values ​​as those created by the sender.

[0047] Next, in block 245, the receiving device 210 can acquire the protected encrypted data and decrypt it using a symmetric decryption algorithm with the diversified symmetric key.

[0048] In block 250, the original confidential data may be revealed as a result of decrypting the protected encrypted data.

[0049] Next, when confidential data needs to be transmitted from the sender to the receiver via the respective sending device 205 and receiving device 210, different counter values ​​can be selected to generate different diverse symmetric keys. By processing the counter values ​​using the same symmetric cryptographic algorithm as the master symmetric key, both the sending device 205 and the receiving device 210 can independently generate the same diverse symmetric keys. These diverse symmetric keys, rather than the master symmetric key, are used to protect the confidential data.

[0050] As explained above, both the transmitting device 205 and the receiving device 210 initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is created independently by both the transmitting device 205 and the receiving device 210, it is never transmitted between them. Therefore, an attacker cannot intercept the diversified symmetric key, and an attacker will never see the data processed with the master symmetric key. Only counter values, not sensitive data, are processed with the master symmetric key. As a result, a reduction in side-channel data related to the master symmetric key becomes apparent. Furthermore, the operation of the transmitting device 205 and the receiving device 210 may be governed by a symmetric requirement regarding the frequency of creating new diversified values, and therefore new diversified symmetric keys. In one embodiment, new diversified values, and therefore new diversified symmetric keys, may be created for every exchange between the transmitting device 205 and the receiving device 210.

[0051] In some examples, a key diversification value can constitute a counter value. Other non-restrictive examples of key diversification values ​​include a random nonce generated each time a new diversification key is needed, a random nonce sent from the transmitting device 205 to the receiving device 210, the full value of a counter value sent from the transmitting device 205 and the receiving device 210, a portion of a counter value sent from the transmitting device 205 and the receiving device 210, a counter maintained independently by the transmitting device 205 and the receiving device 210 but not transmitted between the two devices, a one-time passcode exchanged between the transmitting device 205 and the receiving device 210, and a cryptographic hash of sensitive data. In some examples, one or more portions of a key diversification value may be used by the parties to create multiple diversified keys. For example, a counter can be used as a key diversification value. Furthermore, one or more combinations of the exemplary key diversification values ​​described above can be used.

[0052] In other examples, a portion of the counter can be used as a key diversification value. When multiple master key values ​​are shared between parties, multiple diversified key values ​​can be obtained by the systems and processes described herein. New diversification values, and therefore new diversified symmetric keys, can be created as many times as needed. In the most secure case, a new diversification value may be created for each exchange of sensitive data between the transmitting device 205 and the receiving device 210. In effect, this can create one-time use keys, such as single-use session keys.

[0053] Figure 3 shows a system 300 that uses a contactless card. 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 shows a single instance of the components, the system 300 may include any number of components.

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

[0055] 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, such as servers, network appliances, personal computers, workstations, mobile devices, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices. One or more client devices 310 may also be mobile devices. For example, mobile devices may include Apple's iPhone®, iPod®, iPad®, or other mobile devices running Apple's iOS® operating system, devices running Microsoft's Windows® Mobile operating system, devices running Google's Android® operating system, and / or other smartphones or similar wearable mobile devices. In some examples, client device 310 may be the same as or similar to client device 110, as described with reference to Figure 1A or Figure 1B.

[0056] 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 one or more servers 320 and 325, for example, from an application 311 running on the client device 310. One or more requests can be associated with retrieving data from one or more servers 320 and 325. Servers 320 and 325 can receive one or more requests from the client device 310. Based on one or more requests from the client device 310, one or more servers 320 and 325 may be configured to retrieve the requested data from one or more databases 335. Based on the receipt of the requested data from one or more databases 335, one or more servers 320 and 325 may be configured to send the received data to the client device 310, and the received data responds to one or more requests.

[0057] System 300 may include one or more hardware security modules (HSMs) 330. For example, one or more HSMs 330 may be configured to perform one or more cryptographic operations as disclosed herein. In some examples, one or more HSMs 330 may be configured as special-purpose security devices configured to perform one or more cryptographic operations. The HSMs 330 may be configured such that keys are never revealed outside the HSMs 330 and are instead maintained within the HSMs 330. For example, one or more HSMs 330 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 330 may be contained within or communicate with servers 320 and 325.

[0058] System 300 may include one or more networks 315. In some examples, network 315 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 315 to servers 320 and 325. For example, network 315 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, cellular networks, Internet networks, satellite networks, wireless LANs, global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth®, NFC, RFID, Wi-Fi, and / or any combination of those networks. As a non-limiting example, communication from the contactless card 305 and the client device 310 may include NFC communication, a cellular network between the client device 310 and the carrier, and the internet between the carrier and the backend.

[0059] Furthermore, network 315 includes, 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. Additionally, network 315 can support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 315 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 315 can utilize one or more protocols of one or more network elements that are communicatively coupled. Network 315 can translate to one or more protocols of network devices between other protocols. Although network 315 is presented as a single network, it should be understood that, as one or more examples show, network 315 may comprise multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

[0060] In various examples provided herein, a client device 310 of system 300 may run one or more applications 311 and include one or more processors 312 and one or more card readers 313. For example, one or more applications 311, such as a software application, may be configured to enable network communication with one or more components of system 300, for example, and to transmit and / or receive data. Although only a single instance of the components of client device 310 is shown in Figure 3, it is understood that any number of devices 310 can be used. The card reader 313 may be configured to read from and / or communicate with a contactless card 305. In conjunction with one or more applications 311, the card reader 313 can communicate with the contactless card 305.

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

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

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

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

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

[0066] Figure 4 illustrates a key diversification method 400 according to an example of the present disclosure. Method 400 may include transmitting and receiving devices similar to the transmitting device 205 and receiving device 210 referenced in Figure 2.

[0067] For example, a sender and a receiver may wish to exchange data (e.g., original confidential data) via a sending device and a receiving device. As described above, these two parties may be involved, but it is understood that one or more sending devices and one or more receiving devices may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending and receiving devices may be provisioned with the same master symmetric key. Furthermore, it is understood that any party or device holding the same secret symmetric key can perform the functions of a sending device, and similarly, any party holding the same secret symmetric key can perform the functions of a receiving device. In some examples, the symmetric key may be a shared secret symmetric key kept secret from all parties other than the sending and receiving devices involved in the secure exchange of data. Furthermore, it is understood that the same master symmetric key may be provided to both the sending and receiving devices, and that some of the data exchanged between the sending and receiving devices may consist of at least one portion of the data, which may be called a counter value. The counter value may be a number that changes each time data is exchanged between the sending and receiving devices.

[0068] In block 410, the sending and receiving devices may be provisioned with the same master key, such as the same master symmetric key. When the sending device is ready to process sensitive data in symmetric cryptographic operation, the sender can update the counter. Furthermore, the sending device may select an appropriate symmetric cryptographic algorithm, which may include at least one of the symmetric cryptographic algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process the divergence values ​​may be any symmetric cryptographic algorithm used as needed to generate a divergenced symmetric key of the desired length. Non-restrictive examples of symmetric algorithms may include symmetric cryptographic algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. If the output of the selected symmetric algorithm does not produce a sufficiently long key, it is understood that 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.

[0069] The sending device may use a selected cryptographic algorithm and process counter values ​​using a master symmetric key. For example, the sender may choose a symmetric encryption algorithm and use a counter that is updated with each conversation between the sending and receiving devices.

[0070] Next, in block 420, the transmitting device can use the master symmetric key to encrypt the counter value with a selected symmetric encryption algorithm to create a diversified symmetric key. The diversified symmetric key can be used to process the sensitive data before sending the result to the receiving device. For example, the transmitting device can encrypt the sensitive data using a symmetric encryption algorithm with the diversified symmetric key, and the output may consist of protected encrypted data. The transmitting device can then send the protected encrypted data, along with the counter value, to the receiving device for processing. In some examples, non-encryption operations can be performed, and multiple encryption operations can be performed using the diversified symmetric key before sending the protected data.

[0071] In some cases, the counter value may not be encrypted. In these cases, the counter value may be transmitted between the sending and receiving devices in block 420 without encryption.

[0072] In block 430, sensitive data may be protected using one or more encryption algorithms and diversified keys. Diversified session keys, which may be created by key diversification using counters, may be used with one or more encryption algorithms to protect sensitive data. For example, data may be processed by MAC using a first diversified session key, and the resulting output may be encrypted using a second diversified session key that generates protected data.

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

[0074] In block 450, the receiving device can use a diversified key with one or more encryption algorithms to verify the protected data.

[0075] In block 460, the original data can be verified. If the output of the MAC operation (via a receiving device using the first diversified session key) matches the MAC output revealed by decryption, the data may be considered valid.

[0076] Next, when sensitive data needs to be sent from a sending device to a receiving device, different counter values ​​can be selected, which generates different diversified symmetric keys. By processing the counter values ​​using the same symmetric encryption algorithm as the master symmetric key, both the sending and receiving devices can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the sensitive data.

[0077] As explained above, both the transmitting and receiving devices initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is created independently by both the transmitting and receiving devices, it is not transmitted between the two parties. Therefore, an attacker cannot intercept the diversified symmetric key, and an attacker will not see the data processed with the master symmetric key. Only small counter values, not sensitive data, are processed with the master symmetric key. As a result, a reduction in side-channel data related to the master symmetric key becomes apparent. Furthermore, the sender and receiver can agree, for example, by prior arrangement or by other means, on how often new diversified values, and therefore new diversified symmetric keys, are created. In one embodiment, new diversified values, and therefore new diversified symmetric keys, may be created for all exchanges between the transmitting and receiving devices.

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

[0079] In other examples, a portion of the counter can be used as a key diversification value. When multiple master key values ​​are shared between parties, multiple diversified key values ​​can be obtained by the systems and processes described herein. New diversification values, and therefore new diversified symmetric keys, can be created as many times as needed. In the most secure case, a new diversification value may be created each time sensitive data is exchanged between a sending device and a receiving device. In effect, this can create one-time use keys, such as a single session key.

[0080] In other examples, such as limiting the number of times a master symmetric key is used, the sender on the sending device and the receiver on the receiving device may agree that new diversified values, and therefore new diversified symmetric keys, should only occur periodically. In one example, this might occur after a predetermined number of uses, such as every 10 transmissions between the sending and receiving devices. In other examples, this might occur after a specific period, a specific period after transmission, or periodically (e.g., daily at a specified time; weekly at a specified time on a specified day). In yet another example, this might occur each time the receiving device signals to the sending device that it wishes to change the key in the next communication. This can be controlled based on policy and may vary, for example, depending on the current risk level perceived by the receiver on the receiving device.

[0081] Figure 5A shows one or more contactless cards 500, which may include payment cards such as credit cards, debit cards, or gift cards issued by a service provider 505, as indicated on the front or back of the card 500. In some examples, the contactless card 500 may include an identification card unrelated to a payment card, but is not limited to this. In some examples, the payment card may be a dual-interface contactless payment card. The contactless card 500 may include a substrate 510 which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical properties conforming to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that the contactless card 500 relating to this disclosure may have different characteristics, and this disclosure does not require that the contactless card be implemented as a payment card.

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

[0083] As shown in Figure 5B, the contact pad 520 in Figure 5A may include a processing circuit 525 for storing and processing information, including a microprocessor 530 and memory 535. It is understood that the processing circuit 525 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, collision avoidance algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as necessary to perform the functions described herein.

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

[0085] The memory 535 may be configured to store one or more applets 540, one or more counters 545, and a customer identifier 550. The one or more applets 540 may comprise one or more software applications configured to run on one or more contactless cards, such as Java Card applets. However, it is understood that the applet 540 is not limited to Java Card applets, but could instead be any software application capable of running on a contactless card or other device with limited memory. The one or more counters 545 may comprise numeric counters sufficient to store integers. The customer identifier 550 may comprise a unique alphanumeric identifier assigned to a user of a contactless card 500, the identifier being able to distinguish a user of a contactless card from other contactless card users. In some examples, the customer identifier 550 may identify both a customer and the account assigned to that customer, and further, the contactless card associated with the customer's account.

[0086] While the processor and memory elements of the exemplary embodiments described above have been described with reference to the contact pads, the disclosure is not limited thereto. It is understood that these elements may be implemented outside of the pads 520, completely separate from the pads 520, or as additional elements in addition to the processor 530 and memory 535 elements located within the contact pads 520.

[0087] In some examples, the contactless card 500 may have one or more antennas 555. One or more antennas 555 may be arranged within the contactless card 500, around the processing circuit 525 of the contact pads 520. For example, 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. In other examples, one or more antennas 555 may be located outside the contact pads 520 and the processing circuit 525.

[0088] In one embodiment, the coil of the contactless card 500 can function as the secondary side of an air-core transformer. The terminal can communicate with the contactless card 500 by blocking power or amplitude modulation. The contactless card 500 can infer data transmitted from the terminal using the gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 500 can resume communication by switching the load on the contactless card's coil or by load modulation. Load modulation can be detected in the terminal's coil by interference.

[0089] As described above, the contactless card 500 may be built on a software platform that can run on other devices with limited memory, such as smart cards or Java Cards, and one or more applications or applets may be securely executed on it. Applets can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in a variety of mobile application-based use cases. The applet can be configured to respond to one or more requests, such as a Near Field Data Exchange request from a reader, such as a mobile NFC reader, and generate an NDEF message with a cryptographically secure OTP encoded as an NDEF text tag.

[0090] Figure 6 shows an NDEF short record layout (SR=1) 600 according to an exemplary embodiment. One or more applets can be configured to encode OTPs as well-known types of text tags of NDEF type 4. In some examples, an NDEF message may comprise 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, English encoding (en); applet ID: D2760000850101; function: read-only access; encoding: authentication messages can be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template may comprise a first record with a known index for providing the actual dynamic authentication data.

[0091] Figure 7 shows a message 710 and message format 720 according to an exemplary embodiment. In one example, if additional tags are added, the first byte is modified to indicate the start of the message but not the end, and subsequent records may be added. Since the ID length is zero, the ID length field and ID are omitted from the record. An example message includes UDK AUT key; derived AUT session key (using 0x00000050); version 1.0; pATC=0x00000050; RND=4838FB7DC171B89E; MAC=<calculated 8 bytes>.

[0092] In some cases, data may be stored on a contactless card during personalization by implementing STORE DATA(E2) under Secure Channel Protocol 2. The personalization bureau can read one or more values ​​from the EMBOSS file (the section specified by the applet ID) and, after authentication and the establishment of a secure channel, send one or more store data commands to the contactless card.

[0093] A pUID consists of a 16-digit BCD encoded number. In some examples, a pUID may consist of 14 digits. [Table 1]

[0094] In some cases, one or more applets are configured to maintain their personalization state, allowing personalization only after unlocking and authentication. Other states may have pre-personalization of the standard state. Upon entering the exit state, one or more applets may be configured to delete the personalized data. In the exit state, one or more applets may be configured to stop responding to all Application Protocol Data Unit (APDU) requests.

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

[0096] In some examples, one or more applets may be configured to emulate RFID tags. RFID tags may include one or more polymorphic tags. In some examples, each time a tag is read, various encrypted data may be presented that could indicate the authenticity of a contactless card. Based on one or more applications, the NFC reading of the tag may be processed, a token may be sent to a server such as a backend server, and the token may be validated by the server.

[0097] In some examples, contactless cards and servers may contain specific data to ensure the card is properly identified. A contactless card may have one or more unique identifiers. It can be configured to update a counter each time a read operation is performed. In some examples, each time a card is read, it is sent to the server for verification, and (as part of the verification) it is determined whether the counters are equal.

[0098] One or more counters can be configured to prevent replay attacks. For example, if a ciphertext is retrieved and replayed, the ciphertext will be immediately rejected if the counters are read, used, or otherwise passed. If no counters are used, replay is possible. In some examples, counters updated on the card are different from counters updated for transactions. In some examples, a contactless card may have a first applet, which may be a transaction applet, and a second applet. Each applet may have counters.

[0099] In some cases, counters may become out of sync between a contactless card and one or more servers. For example, even if a contactless card is activated, its counters are updated, and the contactless card generates new communication, the communication may not be sent for processing by one or more servers. This can cause the counters on the contactless card to become out of sync with the counters maintained by one or more servers. This can happen unintentionally, for example, if the card is stored adjacent to the device (e.g., carried in a pocket with the device), if the contactless card is read at an angle, or if the card is misaligned or not positioned correctly, so that the NFC range is powered on but the card is not readable. If the contactless card is positioned adjacent to the device, the device's NFC range can be turned on to power the contactless card and update its counters, but the application on the device does not receive the communication.

[0100] To maintain counter synchronization, applications such as background applications can run that are configured to detect when a mobile device wakes up, synchronize with one or more servers to indicate that a read has occurred, and move the counter forward. Because the counters of the contactless card and one or more servers may become out of sync, one or more servers may be configured to allow the contactless card's counter to be updated a threshold or a predetermined number of times before it is read by one or more servers and still considered valid. For example, if the counter is configured to increment (or decrement) by 1 for each occurrence indicating contactless card activation, one or more servers may allow any counter value read from the contactless card to be considered valid, or any counter value within a threshold range (e.g., 1 to 10). Furthermore, if one or more servers read a counter value that is above 10 but below another threshold range value (e.g., 1000), they may request a gesture associated with the contactless card, such as a user tap. If the counter value is within the desired or acceptable range from the user tap, authentication is successful.

[0101] Figure 8 is a flowchart of key operation 800 according to an exemplary embodiment. As shown in Figure 8, in block 810, two Bank Identifier Number (BIN) level master keys can be used in combination with an account identifier and a card sequence number to generate two unique derived keys (UDKs) per card. In some examples, the Bank Identifier Number may consist of one number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, and may be used to generate and / or diversify session keys. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.

[0102] In block 820, the counter can be used as diversification data because it changes with each use and provides a different session key each time, in contrast to the master key derivation, which generates one unique set of keys per card. In some examples, it is desirable to use a 4-byte scheme for both operations. Thus, in block 820, two session keys may be created for each transaction from the UDK: one session key from the AUTKEY and one session key from the ENCKEY. On the card, for the MAC key (i.e., the session key created from the AUTKEY), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from the ENCKEY), the entire length of the OTP counter can be used for the ENC key.

[0103] In block 830, the MAC key may be used to prepare the MAC ciphertext, and the ENC key may be used to encrypt the ciphertext. For example, the ciphertext may be prepared using the MAC session key and then encrypted with the ENC key before being sent to one or more servers.

[0104] In block 840, 2-byte divergence is directly supported by the MAC authentication function of the payment HSM, simplifying MAC verification and processing. Decryption of the ciphertext is performed before MAC verification. Since the session key is derived independently on one or more servers, a first session key (ENC session key) and a second session key (MAC session key) are generated. 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.

[0105] For contactless cards, another unique identifier may be derived that is associated with the application's primary account number (PAN) and the PAN sequence number encoded on the card. Key diversification can be configured to receive the identifier as input to the master key, so that one or more keys can be created for each contactless card. In some examples, these diversified keys may consist of a first key and a second key. The first key may contain an authentication master key (card ciphertext generation / authentication key - Card-Key-Auth), which can be further diversified to create a MAC session key used when generating and verifying MAC ciphertext. The second key may contain an encryption master key (card data encryption key - Card-Key-DEK), which can be further diversified to create an ENC session key used when encrypting and decrypting encrypted data. In some examples, the first and second keys may be created by diversifying the issuer master key by combining them with the card's unique ID number (pUID) and the payment applet's PAN sequence number (PSN). The pUID may consist of a 16-digit number. As explained above, a pUID can consist of a 16-digit BCD coded number. In some examples, a pUID can consist of a 14-digit number.

[0106] In some cases, the EMV session key derivation method is 2 ∧ Because it can be wrapped with 16, counters such as full 32-bit counters can be added to the initialization array of the diversification method.

[0107] In other examples, such as credit cards, numbers such as account numbers, or unpredictable numbers provided by one or more servers, can be used to generate and / or diversify session keys.

[0108] Figure 9 shows a diagram of a system 900 configured to implement one or more embodiments of the present disclosure. As described below, during the contactless card creation process, two encryption keys may be uniquely assigned to each card. The encryption keys may be symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm can be used with EMV and is implemented by the hardware of the contactless card. By using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information of each entity that requires a key.

[0109] With regard to master key management, two issuer master keys 905, 910 may be required for each part of a portfolio in which one or more applets are issued. For example, the first master key 905 may contain the issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 910 may contain the issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 905, 910 are diversified into card master keys 925, 930, which are unique for each card. In some examples, a network profile record ID (pNPR) 915 and a derived key index (pDKI) 920 can be used as back-office data to identify the issuer master keys 905, 910 used in the encryption process for authentication. The system performing authentication can be configured to look up the values ​​of the pNPR 915 and pDKI 920 for the contactless card at the time of authentication.

[0110] In some examples, to enhance the security of the solution, a session key (such as a unique key per session) can be obtained, but as described above, instead of using a master key, a unique key and counter derived from the card can be used as diversification data. For example, a different key may be used each time the card is used in operation to generate the Message Authentication Code (MAC) and perform encryption. Regarding the generation of session keys, the key used to generate ciphertext and encrypt data within one or more applets may be a session key based on the card's unique key (Card-Key-Auth925 and Card-Key-Dek930). The session key (Auth-Session-Key935 and DEK-Session-Key940) is generated by one or more applets and derived using the Application Transaction Counter (pATC)945 in one or more algorithms. Only the lower two bytes of the four-byte pATC945 are used to fit the data to one or more algorithms. In some examples, a 4-byte session key derivation method may consist of: F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(4 bytes)F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(4 bytes)SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG contains a 3DES ECB and MK may contain a card-unique derived master key.

[0111] As described herein, one or more MAC session keys can be derived using the lower two bytes of the pATC945 counter. Each time the contactless card is tapped, the pATC945 is configured to be updated, and the card master keys Card-Key-AUTH925 and Card-Key-DEK930 are further diversified into session keys Aut-Session-Key935 and DEK-Session-Key940. The pATC945 can be initialized to zero during personalization or applet initialization. In some examples, the pATC counter 945 may be initialized during or before personalization and may be configured to increment by 1 with each NDEF read.

[0112] Furthermore, each card update is unique, assigned either by personalization or by an algorithm using a pUID or other identifying information. For example, odd-numbered cards can be incremented or decremented by 2, and even-numbered cards can be incremented or decremented by 5. In some examples, updates can also differ with sequential reads, with a single card being incremented sequentially in a repeating pattern of 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from a unique identifier. This can make it difficult for a replay attacker to generalize from a small number of card instances.

[0113] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may contain only the authentication data and an 8-byte random number followed by the MAC of the authentication data. In some examples, the random number precedes ciphertext A and may be the length of one block. In other examples, there may be no limit to the length of the random number. In further examples, the total data (i.e., random number and ciphertext) may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block generated by the MAC algorithm. In other examples, if the algorithm employed uses 16-byte blocks, a multiple of that block size may be used, or the output may be automatically or manually padded to a multiple of that block size.

[0114] MAC can be performed using a function key (AUT-Session-Key) 935. The data specified in the ciphertext can be processed using the javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 and associated with the EMV ARQC verification method. The key used for this calculation may be the session key AUT-Session-Key 935, as described above. As described above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, AUT-Session-Key 935 may be used for MAC data 950, and the resulting data or ciphertext A955 and random number RND can be encrypted using DEK-Session-Key 940 to create ciphertext B or output 960 sent in the message.

[0115] In some examples, one or more HSM commands may be processed for decryption so that the last 16 (binary, 32hex) bytes consist of 3DES symmetric encryption using CBC mode with a random zero IV followed by MAC authentication data. The key used for this encryption may consist of a session key DEK-Session-Key940 derived from Card-Key-DEK930. In this case, the ATC value of the session key derivation is the least significant byte of counter pATC945.

[0116] The following format represents an exemplary embodiment of the binary version. Furthermore, in some examples, the first byte may be set to the ASCII character "A". [Table 2]

[0117] Other exemplary formats are shown below. In this example, the tags can be encoded in hexadecimal format. [Table 3]

[0118] The UID field of the received message can be extracted, and from the master keys Iss-Key-AUTH905 and Iss-Key-DEK910, the card master keys (Card-Key-Auth925 and Card-Key-DEK930) for that particular card can be derived. Using the card master keys (Card-Key-Auth925 and Card-Key-DEK930), and the counter (pATC) field of the received message, the session keys (Aut-Session-Key935 and DEK-Session-Key940) for that particular card can be derived. The ciphertext B960 can be decrypted using the DEK-Session-KEY. This generates the ciphertext A955 and RND, which can be discarded. The UID field can be used to retrieve the shared secret of a contactless card. This, along with the Ver, UID, and pATC fields of the message, can be processed via an encrypted MAC using the recreated Aut-Session-Key to produce MAC outputs such as 'MAC'. If the MAC is the same as the ciphertext A955, this indicates that the message decryption and MAC check have all passed. Next, we read the pATC to determine if it is valid.

[0119] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, one or more ciphertexts may be generated as a 3DES MAC using Method 2 padding via ISO9797-1 algorithm 3 and one or more session keys such as Auto-Session-Key 935. The input data 950 may take the following format: version(2), pUID(8), pATC(4), shared secret(4). In some examples, the numbers in parentheses may have a length in bytes. In some examples, the shared secret may be generated by one or more random number generators which may be configured to ensure that the random numbers are unpredictable through one or more secure processes. In some examples, the shared secret may consist of a random 4-byte binary number known by the authentication service and injected into the card at personalization. During an authentication session, the shared secret may not be provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte to the end of the input data and adding a 0x'00' byte which may be added to the end of the resulting data up to an 8-byte boundary. The resulting ciphertext may consist of 8 bytes in length.

[0120] In some examples, one advantage of using MAC ciphertext to encrypt non-shared random numbers as the first block is that it acts as an initialization vector while using the CBC (blockchain) mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without having to establish fixed or dynamic IVs beforehand.

[0121] By including an Application Transaction Counter (pATC) as part of the data contained in the MAC ciphertext, the authentication service can be configured to determine whether the value transmitted in clear data has been tampered with. Furthermore, by including a version in one or more ciphertexts, it becomes difficult for an attacker to deliberately falsify the application version in an attempt to weaken the strength of the encryption solution. In some examples, the pATC may start at zero and be updated by one each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authentication may be rejected. In some examples, if the pATC is greater than a previously received value, it may be evaluated to determine whether it is within an acceptable range or threshold, and if it is above or below the range or threshold, the verification may be considered to have failed or to be untrustworthy. In MAC operation 936, data 950 is processed via MAC using the Auto-Session-Key 935 to generate encrypted MAC output (ciphertext A) 955.

[0122] To provide additional protection against brute-force attacks that would expose the key on the card, it is desirable that the MAC ciphertext A955 be encrypted. In some examples, the data or ciphertext A955 contained in the ciphertext may consist of random(8), ciphertext(8). In some examples, the numbers in parentheses may have a length in bytes. In some examples, the random numbers may be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more secure processes. The key used to encrypt this data may consist of a session key. For example, the session key may consist of DEK-Session-Key940. In encryption operation 941, the data or ciphertext A955 and RND are processed using DEK-Session-Key940 to produce encrypted data, ciphertext B960. The data 955 is encrypted using 3DES in cryptographic blockchain mode to ensure that an attacker would have to perform an attack on all ciphertexts. As a non-restrictive example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' can be used. Successfully decrypted data will appear randomly and will be indistinguishable from incorrectly decrypted data, so an attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used.

[0123] For the authentication service to verify one or more ciphertexts provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile device during the authentication session: a version number and message format for verifying the encryption to determine the encryption approach used, so that the approach can be changed in the future; a pUID for looking up the crypto asset and deriving the card key; and a pATC for deriving the session key used for the ciphertext.

[0124] Figure 10 shows a method 1000 for generating ciphertext. For example, in block 1010, the network profile record ID (pNPR) and derived key index (pDKI) can be used to identify the issuer master key to be used in the cryptographic process for authentication. In some examples, this method may involve performing authentication and looking up the pNPR and pDKI values ​​of a contactless card at the time of authentication.

[0125] In block 1020, issuer master keys can be diversified by combining them with the card's unique ID number (pUID) and one or more applets, such as the PAN sequence number (PSN) of a payment applet.

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

[0127] In block 1040, the key used to generate the ciphertext and encrypt data within one or more applets may comprise the session key in block 1030, based on the card-unique key (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys are generated by one or more applets, derived using pATC, and become the session keys Aut-Session-Key and DEK-Session-Key.

[0128] Figure 11 shows an exemplary process 1100 illustrating key diversification in one example. Initially, two different master keys may be provisioned to the sender and receiver. For example, the first master key may comprise a data encryption master key, and the second master key may comprise a data integrity master key. The sender has other data, such as a counter value that can be updated in block 1110, and data to be protected, which can ensure its sharing with the receiver.

[0129] In block 1120, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value may also be encrypted by the sender using the data integrity master key to generate a data integrity derived session key. In some examples, the entire counter value or a portion of the counter value may be used during both encryptions.

[0130] In some cases, the counter value may not be encrypted. In these cases, the counter can be sent in plain text, i.e., without encryption, between the sender and receiver.

[0131] In block 1130, the data to be protected is processed by the sender's encrypted MAC operation using a data integrity session key and an encrypted MAC algorithm. Using the protected data, including plaintext and shared secrets, a MAC can be generated using one of the session keys (AUT-Session-Key).

[0132] In block 1140, the data to be protected may be encrypted by the sender using a data encryption derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with equal amounts of random data, each 8 bytes long, and encrypted using a second session key (DEK-Session-Key).

[0133] In block 1150, the encrypted MAC is sent from the sender to the receiver along with enough information to identify additional secrets (such as a shared secret or master key) for verification of the ciphertext.

[0134] In block 1160, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as described above.

[0135] In block 1170, the data encryption derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Additional processing is then performed on the exchanged data. In some examples, it is desirable to reconstruct and match the MAC after it has been extracted. For example, when verifying a ciphertext, it can be decrypted using a properly generated session key. The protected data may 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 it is to attempt to recreate it from the source data.

[0136] In block 1180, the data integrity derived session key is used in conjunction with the cryptographic MAC operation to verify that the protected data has not been altered.

[0137] Several examples of the methods described herein can favorably verify when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is valid. The MAC can only be correct if decryption is successful and a valid MAC value is obtained. If decryption is successful, it can indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the sending device) and receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed genuine. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

[0138] Subsequently, the two derived session keys may be discarded, and the next iteration of data exchange may update the counter value (returning to block 1110) and create a new set of session keys (in block 1120). In some examples, combined random data may be discarded.

[0139] Exemplary embodiments of the systems and methods described herein may be configured to provide security factor authentication. Security factor authentication may comprise several processes. As part of security factor authentication, a first process may comprise logging in and verifying the user through one or more applications running on the device. As a second process, the user may engage in one or more actions associated with one or more contactless cards in response to the successful login and verification of the first process through one or more applications. In effect, security factor authentication may comprise both securely proving the user's identity and engaging in one or more types of actions, including but not limited to one or more tap gestures associated with a contactless card. In some examples, one or more tap gestures may comprise tapping a contactless card on the device by the user. In some examples, the device may comprise a mobile device, kiosk, terminal, tablet, or any other device configured to process received tap gestures.

[0140] In some cases, a contactless card can be tapped on one or more devices, such as computer kiosks or terminals, to verify identity and receive transaction items in response to a purchase, such as coffee. Using contactless cards can establish a secure way to verify identity in loyalty programs. For example, securely verifying identity to receive rewards, coupons, offers, or benefits is established in a way different from simply scanning a barcode. For example, encrypted transactions can occur between the contactless card and the device. This can be configured to handle one or more tap gestures. As described above, one or more applications can be configured to verify the user's identity and then prompt the user to act or respond to it, for example, via one or more tap gestures. In some cases, data such as bonus points, loyalty points, reward points, and healthcare information can be written back to the contactless card.

[0141] In some cases, contactless cards can be tapped onto devices such as mobile devices. As described above, a user's identity may be verified by one or more applications, which will then grant the user the desired benefit based on the verification of their identity.

[0142] In some cases, contactless cards can be activated by tapping a device, such as a mobile device. For example, a contactless card can communicate with a device's application via NFC communication through the device's card reader. In communication where the card tap is close to the device's card reader, the device's application may read the data associated with the contactless card and activate the card. In some cases, activation may allow the card to be used to perform other functions, such as making purchases, accessing accounts or restricted information, or other functions. In some cases, a tap can activate or launch a device's application, and then activate the contactless card by initiating one or more actions or communication with one or more servers. If the application is not installed on the device, tapping a contactless card near a card reader may initiate the download of the application, such as navigating to the application's download page. Following installation, tapping the contactless card activates or launches the application, and then initiates the activation of the contactless card, for example, through the application or other backend communication. After activation, the contactless card can be used in a variety of activities, including but not limited to commercial transactions.

[0143] In some embodiments, a dedicated application may be configured to run on a client device to perform contactless card activation. In other embodiments, a web portal, web-based app, applet, etc., can perform activation. Activation may be performed on the client device, or the client device may act as an intermediary 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 on which the activation will be performed (e.g., a personal computer, smartphone, tablet, or point-of-sale (POS) device). Furthermore, the application may output different data and / or additional data to the account server for transmission, depending on the type of device involved. For example, such data may include merchant-related information such as merchant type and merchant ID, and information related to the device type itself, such as POS data and POS ID.

[0144] In some embodiments, the exemplary authentication communication protocol can, with some modifications, mimic an EMV standard offline dynamic data authentication protocol commonly performed between transaction cards and point-of-sale (POS) devices. For example, since the example authentication protocol is not used to complete payment transactions with the card issuer / payment processor itself, some data values ​​are unnecessary, and authentication can be performed without requiring a real-time online connection to the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction, including the transaction amount, to the card issuer. Whether the issuer approves or rejects the transaction may be based on whether the card issuer is aware of the transaction amount. On the other hand, in certain embodiments of this disclosure, transactions originating from a mobile device lack the transaction amount relevant to the POS system. Therefore, in some embodiments, a dummy transaction amount (i.e., a value that is recognizable to the card issuer and sufficient for activation to occur) may be passed as part of the exemplary authentication communication protocol. POS-based transactions may also reject transactions based on the number of transaction attempts (e.g., a transaction counter). If the number of attempts exceeds the buffer value, it may gradually decrease. A gradual decrease requires further verification before accepting the transaction. In some implementations, the transaction counter buffer value may be modified to avoid a decrease in legitimate transactions.

[0145] In some cases, contactless cards can selectively communicate information depending on the recipient's device. When a contactless card is tapped, it can recognize the device being tapped, and based on this recognition, it can provide the appropriate data to that device. This is advantageous because contactless cards only transmit the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting data transmission and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. Information recognition and selective communication can be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and reducing step-up fraud.

[0146] When a contactless card tap is directed towards a device running Apple's iOS® operating system, such as an iPhone®, iPod®, or iPad®, the contactless card can recognize the iOS® operating system and transmit appropriate data for communication with the device. For example, the contactless card can provide encrypted ID information necessary to authenticate the card using an NDEF tag, for example, via NFC. Similarly, when a contactless card tap is directed towards a device running the Android® operating system, such as an Android® smartphone or tablet, the contactless card can recognize the Android® operating system and transmit appropriate data for communication with the device (such as encrypted ID information necessary for authentication as described herein).

[0147] As another example, contactless card taps can be directed to POS devices, including but not limited to kiosks, checkout registers, payment stations, or other terminals. When a tap is performed, the contactless card can recognize the POS device and transmit only the information necessary for the action or transaction. For example, upon recognizing a POS device used to complete a commercial transaction, the contactless card can transmit the payment information necessary to complete the transaction under the EMV standard.

[0148] In some examples, a POS device participating in a transaction may request or specify additional information provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, when a POS device receives data communication from a contactless card, it may recognize the contactless card and request additional information necessary to complete an action or transaction.

[0149] In some cases, a POS device may partner with authorized merchants or other entities that are familiar with or accustomed to performing certain contactless card transactions. However, it is understood that such partnerships are not required for the performance of the described methods.

[0150] In some examples, such as shopping stores, grocery stores, and convenience stores, contactless cards can be tapped on a mobile device without opening an application, indicating a desire or intention to use one or more reward points, loyalty points, coupons, offers, etc., to cover one or more purchases. Thus, the intention behind the purchase is provided.

[0151] In some examples, one or more applications may be configured to determine that they were launched via one or more tap gestures on a contactless card, and as a result, to verify the user's identity, they were launched at 3:51 p.m. and the transaction was processed or executed at 3:56 p.m.

[0152] In some examples, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, one or more actions may include collecting rewards, collecting points, deciding on the most important purchase, deciding on the least expensive purchase, and / or reconfiguring into other actions in real time.

[0153] In some examples, data may be collected about tap behavior as biometric / gesture authentication. For example, a cryptographically secure and intercept-resistant unique identifier may be sent to one or more backend services. The unique identifier can be configured to retrieve secondary information about the individual. The secondary information may consist of personally identifiable information about the user. In some examples, the secondary information may be stored within a contactless card.

[0154] In some examples, the device may include an application that splits bills or checks payments between multiple individuals. For example, each individual may, but not be required, own a contactless card and be a customer of the same issuing financial institution. Each of these individuals may receive a push notification on the device via the application to split a purchase. Instead of accepting only one card tap to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may own contactless cards that provide information to initiate one or more payment requests from the individual tapping the card.

[0155] The following use examples illustrate specific implementations of this disclosure. They are for illustrative purposes only and not intended to limit the scope. In one case, a first friend (payer) is obligated to pay an amount to a second friend (recipient). The payer makes the payment via the recipient's smartphone (or other device) using a contactless card, rather than accessing an ATM or requesting an exchange via a peer-to-peer application. The recipient logs into the appropriate application on their smartphone and selects the payment request option. Accordingly, the application requests authentication via the recipient's contactless card. For example, the application displays a prompt requesting the recipient to tap their contactless card. With the application enabled, the recipient taps their contactless card against the smartphone screen, and the contactless card is read and verified. The application then displays a prompt requesting the payer to tap their contactless card to submit the payment. Once the payer taps their contactless card, the application reads the card information and, via the relevant processor, sends the payment request to the payer's card issuer. The card issuer processes the transaction and sends a transaction status indicator to the smartphone. The application then displays a prompt to show the transaction status indicator.

[0156] In another example, a credit card customer might receive a new credit card (or debit card, other payment card, or other card requiring activation) via email. Instead of activating the card by calling a provided phone number associated with the card issuer or visiting a website, the customer might decide to activate the card through an application on their device (e.g., a mobile device such as a smartphone). The customer can select the card activation function from a menu in the application displayed on the device's screen. The application might prompt the customer to tap the credit card on the screen. Once the credit card is tapped on the device's screen, the application can be configured to communicate with a server, such as a card issuer's server, which will activate the customer's card. The application might then display a message indicating that the card activation was successful. The card activation is now complete.

[0157] Figure 12 shows a method 1200 for card activation according to an exemplary embodiment. For example, card activation can be completed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers may refer to the same or similar components described above with reference to Figures 1A, 1B, 5A, and 5B, such as the contactless card 105, client device 110, and server 120.

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

[0159] In block 1220, one or more portions of dynamically generated data may be communicated to the device's application via NFC or other wireless communication. For example, tapping a card in close proximity to the device may allow the device's application to read one or more portions of data associated with the contactless card. In some examples, if the device does not have an application to assist in activating the card, tapping the card may prompt the customer to instruct the device or to download the relevant application for activating the card from a software application store. In some examples, the user may be prompted to gesture, position, or orient the card sufficiently, such as placing it facing the surface of the device, at an angle, or flat, close to, or in close proximity to the surface of the device. In response to sufficient gesture, position, and / or orientation of the card, the device may begin sending one or more encrypted portions of the data received from the card to one or more servers.

[0160] In block 1230, one or more portions of the data may be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data may be sent from the device to the card issuer server for card activation.

[0161] In block 1240, one or more servers may decrypt one or more encrypted portions of the data via systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and decrypt it by comparing the received data to record data accessible to one or more servers. If the comparison of the decrypted portions of the data by one or more servers results in a successful match, the card may be activated. If the comparison of the decrypted portions of the data by one or more servers results in a failed match, one or more processes may be performed. For example, in response to a failed match determination, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold with a number of attempts allowed for the user to activate the card. Alternatively, the user may receive a notification on their device, such as a message indicating that a card verification attempt has failed, and send a phone call, email, or text message to the relevant service for assistance in activating the card; or the user may receive another notification on their device, such as a phone call indicating that a card verification attempt has failed, and send a phone call, email, or text message to the relevant service for assistance in activating the card; or the user may receive another notification, such as an email indicating that a card verification attempt has failed, and send a phone call, email, or text message to the relevant service for assistance in activating the card.

[0162] In block 1250, one or more servers may send a return message based on the success of the card activation. For example, a device may be configured to receive output from one or more servers indicating that the card has been successfully activated by one or more servers. The device may be configured to display a message indicating that the card has been successfully activated. Once the card is activated, it may be configured to stop dynamic data generation to prevent misuse. In this way, the card may not be activated again, and one or more servers are notified that the card has already been activated.

[0163] In another example, a customer wants to access their financial account on their mobile phone. The customer launches an application (e.g., a banking application) on their mobile device and enters their username and password. At this stage, the customer can view first-level account information (e.g., recent purchases) and perform first-level account options (e.g., credit card payments). However, second-factor authentication is required if the user wants to access second-level account information (e.g., spending limits) or perform second-level account options (e.g., transfers to external systems). Therefore, the application requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps their credit card on their mobile device, and the application verifies that the credit card corresponds to the user's account. The user can then view second-level account data and / or perform second-level account functions.

[0164] In some cases, a user may need to verify their identity before using an application, before utilizing extended or restricted features of an application or device, before viewing sensitive information, or before performing certain actions. Transmitting devices, such as contactless cards as described herein, may be used as a means of verifying the user's identity and accessing these features. Examples of sensitive information include, but are not limited to, academic, financial, historical, medical, and technical information. Examples of restricted features include, but are not limited to, accessing or modifying sensitive information, generating additional sensitive information, purchasing, selling, or transferring assets or sensitive information, or destroying or otherwise disposing of assets or sensitive information.

[0165] A user may verify their identity, for example, by providing their identity via a transmitting device. User identification may comprise specific information relating to the user that is not widely known. Examples of user identification information include, but are not limited to, the user's date of birth, home address, work address, telephone number, credit card number, bank account number, billing zip code, security number, password, biometric information (e.g., facial, retinal, or fingerprint scan, voice recognition), personal identification number, identification information related to the transmitting device (e.g., unique identification number, algorithm-determined value, counter value), or a combination thereof. User identification may be transmitted by a transmitting device by the methods described herein and may be encrypted before transmission.

[0166] For example, a user may want to protect their personal, financial, medical, or other sensitive information using enhanced security features associated with a contactless card or other transmitting device equipped with the communication and encryption capabilities described herein. A user may establish security features that require identity verification before performing high-risk operations or other sensitive operations, including but not limited to transferring money from an account or credit (e.g., withdrawing cash from an ATM), modifying contact information, editing a password, or changing portfolio positions. Other sensitive operations include, but are not limited to, authorizing access to or transmission of personal data, medical data, and / or financial data. A user may log into the application to establish the desired security features that require identity verification before performing certain sensitive operations. If a user wishes to perform such an operation, they may authenticate their identity by tapping or gesturing to a contactless card, smartphone, or other transmitting device near the receiving device. The receiving device may detect the use of the transmitting device and authenticate the user's identity using the communication and encryption capabilities described herein. Once the user's identity is authenticated and the authentication is communicated from the receiving device to the application, it may be possible to access sensitive information or perform necessary sensitive operations.

[0167] In some cases, contactless cards can be used with terminals, kiosks, receiving devices, and / or mobile devices to transmit insurance data to doctors, medical staff, support staff, and / or claims agents. In some cases, transmitting insurance information facilitates claims processing and billing users for the correct amount. In some cases, transmitting insurance information facilitates the creation of invoices and / or invoices that may differ depending on the specific type and / or amount of insurance applicable to the user.

[0168] In some examples, a user may run an application on a mobile device, and the application may communicate with a billing and / or accounting application associated with the healthcare provider via a server. The user may authenticate their identity to the application running on the mobile device using a contactless card. The mobile device may then transfer the user's insurance information to the healthcare provider for billing purposes.

[0169] Figure 13 illustrates method 1300 for a user to access one or more restricted functions of an application or to access sensitive information within the application. Method 1300 may be performed before or after the user authenticates his or her transmitting device by the method described herein. Method 1300 begins in block 1310 with the user accessing the application or hotline. The application may be installed and / or run on a receiving device such as a network-enabled computer or mobile device, as described herein.

[0170] In block 1320, the application or hotline requires the user to authenticate their identity before proceeding to utilize the application's extensions or access sensitive information. In block 1330, the user moves a transmitting device equipped with the communication and encryption capabilities described herein near a receiving device. In block 1340, the receiving device authenticates the user's identity. In block 1350, the receiving device communicates the user's authenticated identity to the application. In block 1360, the application allows the user to utilize the application's extensions or access sensitive information. In some examples, the extensions and sensitive information available to the user differ based on user information associated with the user's authenticated identity.

[0171] In other examples, a user might want to authenticate their identity in order to initiate a secure chat or call with a customer service agent. In such cases, securely authenticating the user's identity may allow the agent to access their personal information, account information, transaction history, call history, previous notes, and / or other information without the agent having to independently verify the user's identity. In some examples, a user might call or otherwise contact an agent, and the agent might request the user to authenticate their identity using a transmitting and receiving device with the communication and encryption capabilities described herein. The user might perform a tap, swipe, wave, or any gesture or combination thereof on the transmitting device near the receiving device. The receiving device may communicate with the agent and / or the application the agent is using that the user has authenticated their identity, allowing the agent to access the user's information. In some examples, this saves the user time providing their date of birth, address, password, social security number, and / or other identifying information to one or more agents. In some cases, this saves time and enhances the protection of such information because it eliminates the need to provide sensitive user information to human agents.

[0172] In some examples, an application may require the user to authenticate their identity as a first step before connecting with an agent. In some examples, an application may first direct the user to a specific agent or category of agent based on the user's authenticated identity. In some examples, the user's authenticated identity may be associated with a rank, category, or points system, which may grant the user certain benefits, such as faster access to agents, access to agents with a certain experience level, access to agents with a certain quality rating, or access to agents with certain extended approvals. Such approvals may include, for example, approvals to refund or credit a certain amount to the user, approvals to provide the user with certain premium features or benefits, approvals to waive certain fees or charges, approvals to renew, negotiate, and / or modify contracts or other agreements, approvals to offer free or discounted delivery, and / or approvals to provide the user with additional or premium services.

[0173] Figure 14 illustrates a method 1400 for a user to contact customer support and receive different services based on the user's identity being authenticated using a transmitting device such as a contactless card, according to an exemplary embodiment. Method 1400 begins in block 1410, where the user accesses a customer support application and / or calls a customer support hotline. The application may be installed and / or run on a receiving device such as a network-enabled computer or mobile device as described herein, and the hotline may be accessed via a mobile or landline phone, a Voice over Internet Protocol-enabled device, or other telephone communication means. In some examples, the hotline may communicate with the user via a human operator, a recorded operator, a voice chat agent, or other audible communication means, and the user's interaction with the hotline may include interaction with an application installed on the receiving device.

[0174] In block 1420, the application or hotline requests the user to authenticate their identity. In block 1430, the user moves a transmitting device, such as a contactless card, near a receiving device. In block 1440, the receiving device authenticates the user's identity. In block 1450, the receiving device communicates the user's authenticated identity to the application or hotline.

[0175] After receiving the authenticated identity of the user, the application or hotline may proceed to block 1460, 1470, or 1480. In block 1460, the application or hotline provides the user's account information to a human operator, thereby saving the user time relaying that information to the operator. In block 1470, the application or hotline routes the user's call to a specific category of human operator based on user information, such as rank associated with the user's identity. In block 1480, the application or hotline routes the user's call to the first available human operator based on user information, such as transaction history associated with the user's identity, thereby preventing priority customers from waiting in a queue.

[0176] In some cases, a user may wish to provide information to an application using a transmitting device equipped with the communication and encryption capabilities described herein and a receiving device communicating with the application. In such cases, the user's information may be recorded on the transmitting and / or receiving device. Such information may include, but is not limited to, the user's name, date of birth, home address, work address, telephone number, credit card number, bank account number, billing zip code, security number, password, and / or preferences. If prompted to provide such information, the user may perform taps, swipes, waves, or any of these gestures or combinations using a contactless card, smartphone, or other transmitting device equipped with the communication and encryption capabilities described herein to authenticate his or her identity to the receiving device. This may transfer information from the transmitting device to the receiving device and / or allow the receiving device to communicate the user's information to the application, thereby reducing or eliminating the need for the user to manually enter his or her information and creating a more secure transmission of data.

[0177] In some cases, an application may record information related to a user's identity authentication actions. Such information may include, for example, the time of authentication, the location of authentication, the type of transmitting device used, the individual transmitting devices used, the type of receiving device used, the individual receiving devices used, and / or information related to the movement or timing of taps, swipes, waves, or any gestures or combinations thereof used for identity authentication. In some cases, the recorded information may be analyzed to develop a user behavior profile. Such a profile may be used to detect potential indicators of fraud. Such indicators may include actions that fall outside the scope of the user's established behavior profile. In some cases, a certain amount of variance may be determined before an activity is judged to be fraudulent or potentially fraudulent. In some cases, the amount of acceptable behavioral variance may be based on the amount of variance detected in the user's behavior profile. Such examples may be used to set a lower variance threshold for detecting potential fraud in a user with a long established record of authenticating only from home using a specific contactless card, compared to a user who frequently authenticates from multiple locations using multiple transmitting devices. In some cases, artificial intelligence or machine learning techniques can be used to analyze user behavior information in order to establish profile patterns and the degree of variability of those patterns.

[0178] In some examples, a user's behavioral profile may include information related to the type of application or application that requires identity verification. This information may be used to provide the user with targeted advertising, features, content, or other benefits. In some examples, if a user uses a contactless card with the communication and encryption capabilities described herein for a gaming application, that user may be offered additional content related to the game, a specific game the user plays, or a business that provides products or services related to the game. In some examples, if a user uses a contactless card with the communication and encryption capabilities described herein for a travel application, that user may be offered additional content related to travel, a destination that the user may be interested in, a hotel, a spa, an attraction, or a product or service related to travel, or other businesses located in a specific destination that the user may be interested in based on the user's behavioral profile.

[0179] In some cases, an application may require the user to authenticate their identity as the first step in a multi-step security process before accessing sensitive information or performing sensitive operations. In such cases, the application may require the user to authenticate their identity using a transmitting device with the communication and encryption capabilities described herein before the application sends a passcode or PIN to the user. In some cases, a step of authenticating the user's identity may be required before the application sends a one-time passcode to the user's smartphone. In some cases, the user may need to authenticate their identity using a contactless card or another transmitting device other than their smartphone. In such cases, the user may need to physically possess both their contactless card and their smartphone in order to generate and receive a one-time passcode from the application. This configuration may help reduce or prevent fraudulent activity by requiring multiple layers of security. In some cases, such enhanced security features may only be implemented if the application detects activity outside of the user's established behavioral profile. For example, if an application detects that a user is attempting to access sensitive data from another country, the application may require the user to perform multi-factor authentication.

[0180] In some examples, a user may want to facilitate a registration or check-in process. In some examples, a user may use transmitting and receiving devices with communication and encryption capabilities as described herein to authenticate his or her identity at a hotel, convention center, restaurant, airline, mechanic, clinic, hospital, dental office, or other place that accepts reservations. In some examples, a user may enter a hotel and use a transmitting device with communication and encryption capabilities as described herein near a receiving device that may be located at the hotel's front desk to perform a tap, swipe, wave, or any gesture or combination thereof. The receiving device may communicate to the reservation system that the user's identity has been authenticated in order to facilitate the check-in process. In some embodiments, the receiving device may communicate with an automated kiosk that can issue a room key upon receiving the user's authenticated identification, without the involvement of a human clerk.

[0181] In some embodiments, a hotel may not issue a separate room key but may allow the user to access the room using their transmitting device. In such examples, the user may use their smartphone to authenticate their identity at a kiosk equipped with a receiving device. Once the hotel authenticates the user's identity, it may update an internal application. This allows the user to access a specific room for a certain period of time using their smartphone without needing a room key from another hotel.

[0182] In some embodiments, a user may authenticate their identity using a contactless card at a room access terminal, such as an electronic lock installed on a door. In some embodiments, a user may authenticate their identity using a contactless card that communicates with an application running on a mobile device. The application may interact directly with the access terminal or communicate with a backend hotel application or database using a server, and once the user's identity is established as described herein, it may grant the user access to the room.

[0183] In some embodiments, once a reservation is made, the hotel may update an internal application that allows the user to access the room using a contactless card configured to authenticate the user's identity. In some embodiments, the user may use the contactless card to directly interface with terminals and / or other hotel devices to access the room.

[0184] In some embodiments, a user may run an application on a mobile device that communicates with the hotel's internal access and control system via a server. In some embodiments, a user may tap, swipe, wave, or any combination thereof on a contactless card in response to prompts from the application on the mobile device to open the door to a hotel room. Once the user's mobile device verifies the user's identity using the contactless card, it may notify the hotel's internal access and control system that the user has been authenticated, thereby allowing the hotel's access and control system to unlock or open the particular door.

[0185] In some cases, a user may be able to cancel, change, or modify a hotel reservation. In such cases, the hotel reservation application may require the user to authenticate their identity before granting access to the reservation information or allowing the user to modify the reservation.

[0186] In some examples, a user might want to pay or tip staff at a hotel, restaurant, or other location. In such examples, the user might pre-arrange a series of gestures to initiate a specific payment transaction. To initiate the transaction, the user might tap a receiving device carried by the staff, or otherwise associated with the staff. In some examples, following the initiation of the transaction, the user might perform one or a series of gestures to pay the staff the desired amount. In one example, the user might tap a sending device onto a staff member's receiving device and then perform a series of lateral sweep actions using the sending device, each lateral sweep transferring $1 or other currency unit to the staff member associated with the receiving device. In such examples, the user might tip or pay the staff as much or less as desired, based on the number of lateral sweep actions performed. In other examples, the user might pre-arrange gestures to initiate the transfer of a specific amount, for example, $1, $5, or $10, respectively. In such examples, the user might tip or pay the staff member the desired amount based on a combination of pre-prepared gestures.

[0187] In some examples, a user may access a secure physical location, including but not limited to unlocking a locker, opening a locked door, or unlocking a safe. In such examples, the secure physical location is equipped with a receiving device, and the user may access the secure location by authenticating his or her identity using a transmitting device with the communication and encryption capabilities described herein. In such examples, the user may perform taps, swipes, waves, or any gesture or combination thereof using a contactless card, a smartphone, or other transmitting device located near the receiving device. Once the user's identity is authenticated, the receiving device may unlock the secure location.

[0188] In one example, a user may unlock a locker equipped with a receiving device. To authenticate their identity, the user may perform a tap, swipe, wave, or any combination thereof on a contactless card or transmitting device with the communication and encryption capabilities described herein, located near the receiving device. Once the user's identity is authenticated, the locker may open. In another example, once the user's identity is authenticated, the receiving device may send a temporary passcode to the user's smartphone or mobile device, and the user may unlock the locker by entering the code. In such a configuration, the user may need to physically possess both the smartphone or mobile device associated with their account and the contactless card or transmitting device used to authenticate their identity. In some examples, the receiving device may require the user to perform a predetermined gesture on a contactless card, creating yet another layer of security necessary to access the locker.

[0189] In some examples, a user may provide an operator of a controlled physical location with a list of other individuals authorized to access the controlled space on their behalf. In such examples, the user's agent may perform a tap, swipe, wave, or any of these gestures or combinations on the agent's contactless card to authenticate their identity as the user's authorized agent. In some examples, once the agent's identity is authenticated, the agent may be granted access to the controlled space on the user's behalf. In some examples, once the agent's identity is authenticated, the receiving device may send the user a text message or other notification asking whether the user wishes to grant the agent access to the controlled space before granting the agent access.

[0190] In certain secure locations, multiple users may need to authenticate their identity by swiping, tapping, or gesturing with a contactless card near the receiving device, either within a specific time frame or substantially simultaneously. Such examples would prevent a single individual from accessing a controlled space without the presence of other necessary individuals.

[0191] In other examples, a user may have access to a vehicle equipped with a receiving device. In such examples, the user may perform a tap, swipe, wave, or any gesture or combination thereof on a contactless card or other transmitting device with the communication and encryption capabilities described herein, near the receiving device, in order to authenticate the user's identity and thereby obtain access to the vehicle. In some examples, performing a similar tap, swipe, wave, or any gesture or combination thereof near the receiving device may initiate the vehicle's ignition or otherwise access the vehicle's driving functions. In some examples, the vehicle or a receiving device associated with the vehicle may maintain a list of authorized agents who can access and / or operate the vehicle on behalf of the user. In some examples, a particular individual may be granted permission to access the vehicle but not to drive or operate it. For example, a user may grant each member of their family the ability to access the vehicle by swiping, tapping, or gesture on their family member's contactless card, thereby authenticating the identity of each individual family member. However, the user may grant only their spouse the ability to operate the vehicle. This could prevent a user's child from operating the car, even if their identity is authenticated. In some embodiments, an authorized agent may be granted the ability to operate the vehicle only on specific days and / or during specific hours. If a user has a teenage son learning to drive and does not want him to drive at night, the user can change the permissions associated with the son's identity so that the son can access the car at any time, but only before 7 p.m. In some examples, the transmitting device eliminates the need for a separate key to access and / or operate the vehicle.

[0192] In some cases, a user may have access to their healthcare or medical information. Because such information is highly sensitive, the user may need to authenticate their identity using a contactless card with the communication and encryption capabilities described herein. In such cases, the user may perform a tap, swipe, wave, or any gesture or combination thereof on a contactless card or other transmitting device near the receiving device to authenticate their identity. Once the user authenticates their identity to the receiving device, the receiving device communicates this information to a server, which may then grant access to the user's medical information. By requiring secure identity verification before granting access to medical data, hospitals, clinics, universities, and other organizations can reduce the likelihood of unauthorized access to medical information. Furthermore, in some cases, patients may be able to access their medical information from an unmanned kiosk, thereby enabling greater access to their information without requiring additional staff or record-keeping personnel.

[0193] Throughout the statement, various accounts are referenced, for example, bank accounts, credit card accounts, and debit accounts. However, it should be understood that this disclosure is not limited to specific bank accounts and may include any financial accounts, as well as accounts related to entertainment, loyalty programs, utilities, and other services.

[0194] In some instances, this disclosure refers to tapping a contactless card. However, this disclosure is not limited to tapping and is understood to include other gestures, such as waving or other movements of the card.

[0195] Throughout the specification and claims, the following terms have the meanings expressly associated herein, unless the context clearly indicates otherwise. The term "or" is intended to mean an inclusive "or." Furthermore, the terms "a," "an," and "the" are intended to mean one or the plural, unless otherwise specified or the context makes it clear that they are singular.

[0196] This description provides many specific details. However, it should be understood that the disclosed technology may be implemented without these specific details. In other examples, well-known methods, structures, and techniques are not described in detail so as not to obscure the understanding of this description. References to “several examples,” “other examples,” “one example,” “example,” “various examples,” “one embodiment,” “embodiment,” “several embodiments,” “exemplary embodiment,” “various embodiments,” “one implementation,” “implementation,” “exemplary implementation,” “various implementations,” and “several implementations” indicate that the implementation of the disclosed technology described in this way may include certain features, structures, or characteristics, but not all implementations necessarily include those specific features, structures, or characteristics. Furthermore, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” does not necessarily refer to the same example, embodiment, or implementation, but may.

[0197] Where used herein, unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe a common subject merely indicates that different instances of a similar subject are being referred to, and does not imply that the subjects described in this way must be in a particular order, temporally, spatially, in rank, or otherwise.

[0198] While specific implementations of the disclosed technology have been described in relation to those currently considered to be the most practical and diverse implementations, it should be understood that the disclosed technology should not be limited to the disclosed implementations, but rather is intended to cover a variety of modifications and equivalent arrangements included within the scope of the attached claims. Certain terms are used herein, but they are used in a general and descriptive sense only, and not for limiting purposes.

[0199] This written description, using examples, discloses specific practices of the disclosed technology, including the best mode, and enables a person skilled in the art to practice specific practices of the disclosed technology, including the creation and use of any device or system, and the execution of any incorporated methods. The patentable scope of specific practices of the disclosed technology is defined in the claims and may include other examples that arise for a person skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are substantially different from the literal language of the claims.

Claims

1. A method performed by a receiving device having a processor that executes an application including executable instructions stored in memory, The aforementioned method, Receiving encrypted transmission data from a contactless card, Decrypting transmitted data encrypted using cryptographic algorithms and application keys, Record information including at least one selected from the group of authentication time, authentication location, contactless card type, and receiving device type, Performing confidential operations, A method that includes this.

2. The aforementioned confidential operation includes accessing confidential information. The method according to claim 1.

3. The aforementioned confidential information includes at least one selected from the group consisting of personal information, financial information, and medical information. The method according to claim 2.

4. The aforementioned confidential operation includes transmitting confidential information. The method according to claim 1.

5. The aforementioned confidential operation includes at least one selected from the group consisting of modifying the account's contact information and editing the account's password. The method according to claim 3.

6. The type of receiving device includes at least one selected from the group of terminals, kiosks, and mobile devices. The method according to claim 1.

7. Further comprising recording the movement of one or more entries of the contactless card to a communication field, The method according to claim 1.

8. The above method further, Analyzing the recorded information, To generate user behavior profiles, The method according to claim 1, including the method described in claim 1.

9. The above method further, Determining the threshold for variation in the user behavior profile, Detecting fraud indicators based on the aforementioned user behavior profile, Includes, The aforementioned fraud indicators are outside the user behavior profile and include behaviors that exceed the threshold of variation. The method according to claim 8.

10. The above method further, Determining the threshold for the aforementioned variation, The method according to claim 9, including the method described in claim 9.

11. The threshold for variation in a user behavior profile that includes authentication at one location is lower than the threshold for variation in a user behavior profile that includes authentication at multiple locations. The method according to claim 10.

12. The threshold for variation in a user behavior profile that includes authentication with one contactless card is lower than the threshold for variation in a user behavior profile that includes authentication with multiple contactless cards. The method according to claim 10.

13. A contactless card having a processor and memory, A receiving device having a processor and memory, A system equipped with, The memory of the receiving device includes an application key and an application containing executable instructions. When the aforementioned application is executed, the receiving device, Receive encrypted transmission data from a contactless card. The encrypted transmission data is decrypted using the encryption algorithm and the application key. The system records information including at least one selected from the group of authentication time, authentication location, contactless card type, and receiving device type. Perform confidential operations A system configured in such a way.

14. The confidential operation includes at least one selected from the group of transfers from the account and changes to the account's portfolio position. The system according to claim 13.

15. The receiving device includes a server, The contactless card is configured to transmit the encrypted transmission data to the receiving device via one or more intermediate devices. The system according to claim 13.

16. The recorded information includes at least one pre-authentication of user identification and at least one location associated with the at least one pre-authentication. The system according to claim 13.

17. The aforementioned confidential operation includes accessing confidential information, The aforementioned confidential information includes technical information, The system according to claim 13.

18. The aforementioned confidential operation includes destroying confidential information. The system according to claim 13.

19. A non-temporary computer-readable medium for storing instructions to be executed by the processor of a receiving device having memory including an application key, During execution by the processor, the instruction causes the receiving device to perform a predetermined procedure. The above procedure is, Receiving encrypted transmission data from a contactless card, Decrypting encrypted transmission data using the encryption algorithm and the application key, Record information including at least one selected from the group of authentication time, authentication location, contactless card type, and receiving device type, To perform confidential operations, Non-temporary computer-readable media, including [the specified format].

20. The confidential operation includes at least one selected from the group of purchasing an asset, selling an asset, and transferring an asset. The non-temporary computer-readable medium according to claim 19.

Images