System and method for encrypted authentication of contactless cards

Abstract

An exemplary embodiment of a system and method for data transmission between a contactless card, a client device, and one or more servers is provided. The memory of the contactless card may include one or more applets and a counter. The client device may be in data communication with the contactless card and one or more servers, which may contain appropriate counter values. The client device may be configured to read the counter from the contactless card and transmit it to the one or more servers. The one or more servers may compare the counter with appropriate counter values ​​for synchronization. The contactless card and one or more servers may resynchronize the counter via one or more processes based on one or more readings of the one or more applets. The one or more servers may authenticate the contactless card based on the resynchronization.

Description

Technical Field

[0001] Cross - References to Related Applications This application is a partial continuation of U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, and claims priority from U.S. Provisional Patent Application No. 62 / 740,352, filed on October 2, 2018, and U.S. Patent Application No. 16 / 589,192, filed on October 1, 2019, the disclosures of which are hereby incorporated by reference in their entireties.

[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 enterprises and consumers. As electronic transactions constitute an increasingly large share of business activities, this need continues to grow.

[0004] E - mail can be used as a tool for verifying transactions, but e - mail 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. Furthermore, data encryption algorithms such as the Triple DES algorithm also 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 project]

[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 the present disclosure provide a counter resynchronization system comprising: a contactless card including one or more processors and memory, the contactless card comprising one or more applets and counters; a client application comprising instructions for execution on a client device comprising one or more processors and memory; one or more servers communicating data with the client application, the one or more servers comprising memory having appropriate counter values; the client application being configured to read counters from the contactless card and send the counters to the one or more servers; the one or more servers being configured to compare the counters with appropriate counter values ​​for synchronization; the contactless card and the one or more servers being configured to resynchronize the counters via one or more processes based on one or more reads of the one or more applets; and the one or more servers being configured to authenticate the contactless card based on the resynchronization.

[0009] Embodiments of the present disclosure provide a method for resynchronizing counters of a contactless card, comprising the steps of: the contactless card communicating with a client application which has instructions to be executed on a client device, the client application which also communicates with one or more servers, the contactless card which includes one or more processors and memory which includes one or more applets and a first counter; one or more servers which compare the counters received from the client application for synchronization with appropriate counter values; one or more servers which resynchronize the counters via one or more resynchronization processes based on one or more reads of one or more applets; and one or more servers which authenticate the contactless card based on the resynchronization of the counters.

[0010] Embodiments of the present disclosure provide a contactless card comprising one or more processors and memory, the memory comprising one or more applets and counters, the counters being resynchronized via a resynchronization process based on one or more reads of one or more applets, the resynchronization process comprising a client application having instructions to be executed on a client device, performing one or more reads of one or more applets during a single gesture (operation) by the contactless card, one or more servers receiving one or more reads from the client application based on the single gesture, and the contactless card resynchronizing the counters, the single gesture comprising a wave, tap, swipe, or any combination thereof to the client application by the contactless card, and the resynchronization process comprising a first window, configured to determine whether an increment of the counters belongs to a first non-monotonical sequence within the first window.

[0011] 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. [Brief explanation of the drawing]

[0012] [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 is a counter resynchronization system according to an exemplary embodiment. [Figure 14] This flowchart shows a method for resynchronizing counters in a contactless card according to an exemplary embodiment. [Modes for carrying out the invention]

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

[0014] An object of some embodiments of the present disclosure is to incorporate one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform many other functions that may require the user to carry a separate physical token in addition to the contactless card for authentication and other methods. By adopting a contactless interface, the contactless card can be provided with a method for interacting and communicating between the user's device (such as a mobile phone) and the card itself. For example, the EMV protocol underlying many credit card transactions includes a sufficient authentication process for the Android (registered trademark) operating system, but there are issues with iOS (registered trademark), which is more restricted regarding the use of Near Field Communication (NFC) because it can only be used in a read-only manner. Exemplary embodiments of the contactless card described herein utilize NFC technology.

[0015] FIG. 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 FIG. 1A shows a single instance of the components, system 100 may include any number of components.

[0016] 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 wirelessly communicate with the client device 110, for example, by utilizing NFC.

[0017] System 100 may include a client device 110 that can be a network-enabled computer. As referred to herein, a network-enabled computer can include, but is not limited to, a computer device, or a communication device such as, for example, a server, a network appliance, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. 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.

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

[0019] In some examples, a client device 110 of system 100 may run one or more applications, such as software applications, that enable network communication with one or more components of system 100 and transmit and / or receive data.

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

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

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

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

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

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

[0026] 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).

[0027] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0083] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0117] 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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0132] 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).

[0133] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

[0147] 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).

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

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

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

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

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

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

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

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

[0156] The following use examples illustrate specific implementations of this disclosure. They are for illustrative purposes only and not limitable. 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 on 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 outputs to display the transaction status indicator.

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

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

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

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

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

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

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

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

[0165] As explained above, the counter may be incremented by an applet, for example, each time the applet ID of the applet is requested via NFC. In some examples, the counter may only be incremented when the device, such as a mobile phone, is within the magnetic field and the applet ID is requested. However, if the transaction with the server is interrupted, or if the applet is only partially read, the counter on the contactless card and the backend counter may become out of sync. Therefore, maintaining the synchronization of these counters is important for the security and integrity of the system for various reasons, such as preventing messages from being replayed on multiple attempts. As will be further explained below, the system and methods describe how to resynchronize the counters when they become out of sync.

[0166] Counter fluctuations are acceptable, and complete synchronization is not required. For resynchronization to occur, the backend may receive multiple reads of the applet from the mobile device, verify that it is incrementing, and obtain a new value to synchronize. Thus, the backend may be configured to determine whether the counter values ​​are arriving in the expected order, and if not, to invalidate the contactless card. As described below, the backend may be configured not to accept numbers previously used for the counter.

[0167] Figure 13 shows a system 1300, such as a counter resynchronization system, comprising a contactless card 1305, a client device 1310, and one or more servers 1320. Although Figure 13 shows a single instance of the components, system 1300 may include any number of components. The contactless card 1305, client device 1310, and one or more servers 1320 may refer to the same or similar components mentioned above with reference to Figures 1A, 1B, 5A, and 5B, such as the contactless card 105, client device 110, and server 120.

[0168] The contactless card 1305 may include one or more processors 1307 and memory 1309. The memory 1309 may include one or more applets 1311 and counters 1313.

[0169] The client device 1310 may include one or more processors 1315 and memory 1317. The client device 1310 can communicate data with the contactless card 1305 via a communication interface (not shown).

[0170] One or more servers 1320 can communicate data with the client device 1310. A counter 1313 is transmitted and may be compared by one or more servers 1320 to an appropriate counter value for synchronization. For example, one or more servers 1320 may attempt to obtain an appropriate value. In one example, a counter on a contactless card may start from zero. In one or more servers 1320, the counter may start from zero and increment by, for example, 1, so that the next expected counter is 1. If 1 is the appropriate counter and one or more servers 1320 decide on a different value, such as 10 instead, a decision is made regarding whether the different value is within a given window or range. As long as the different value is within the window or range, the counter is set to 10 and is therefore accepted. If the different value is not within the window or range, for example, 100, this value is obviously not equal to the appropriate counter value of 1, and one or more messages may be sent to the client device 1310. In some examples, one or more messages may include instructions that the contactless card must be gestured (operated) once or more times. In response to one or more of these gestures, the counter value may be set to 101, which may be an acceptable number determined by one or more servers 1320. However, in some examples, determining any other number may deactivate the contactless card 1305. In some examples, the contactless card 1305 may be shut down by one or more servers 1320. For example, as described below, one or more servers 1320 may stop data communication with the contactless card 1305 because it may be under attack.

[0171] The counter 1313 of the contactless card 1305 may be resynchronized via one or more synchronization processes based on one or more reads of one or more applets 1311 of the contactless card 1305. One or more servers 1320 may be configured to authenticate the contactless card 1305 based on the resynchronization.

[0172] The counter 1313 may be configured to notify of one or more attacks, including but not limited to malicious activities such as misuse, overuse, card tampering, card communication interference, or any combination thereof. In some examples, one or more attacks may relate to physical access to the contactless card 1305. For example, these attacks may include attempts to extract master keys for secure elements of the contactless card 1305, side-channel attacks via other communication paths such as the EMV chip contact interface, and / or fuzzing of the contactless card 1305 or contact interface with random or structured information attempting to overload or force an unintended response from one or more applets 1311 of the contactless card 1305. In some examples, the counter 1313 may be configured to include, but not limited to, increments or decrements in non-monotonical sequences. In other examples, the counter 1313 may be configured to include, but not limited to, increments or decrements in monotonical sequences. In some examples, the counter 1313 may be modified to include, but not be limited to, increments or decrements in randomly generated or non-sequential sequences.

[0173] In other examples, when an attacker attempts to impersonate a message, the attack may be detected by, for example, attempting to intercept and modify the message, or creating their own artificial message. These can be detected by message replay using previously used counters, such as the last counter stored on one or more servers 1320, replaying a message with a modified counter, replaying a message with a changed account number and / or user identification, and / or a message with modified or created ciphertext.

[0174] In some examples, when the contactless card 1305 detects one or more attacks, one or more applets 1311 may be configured to perform one or more actions. For example, one or more applets 1311 of the contactless card 1305 may be configured to transition to a state where it does not function at all. In other examples, one or more applets 1311 of the contactless card 1305 may be configured to notify one or more servers 1320 of what attack has occurred. For example, if a fuzzing attack is detected, an encrypted value indicating a fuzzing attack may be sent to one or more servers 1320 to notify them that the contactless card 1305 may be compromised.

[0175] In some examples, a single or multiple gestures of the contactless card 1305 may be used as part of one or more synchronization processes. For example, a first process may include a client device 1305 configured to perform one or more reads of one or more applets 1311 during a single gesture by the contactless card 1305 within the data communication range of the client device 1310. Furthermore, one or more servers 1320 may be configured to receive one or more reads from the client device 1310 based on the single gesture in order to resynchronize the counter 1313. In some examples, a single gesture may comprise a wave, tap, swipe, or any combination thereof, of the contactless card 1305 to the client device 1310. In some examples, a first process may include a first window configured to determine whether the increment of the counter 1313 of the contactless card 1305 belongs to a first monotonic or non-monotonical sequence. For example, if the increment of the counter 1313 of the contactless card 1305 does not belong to a first monotonic sequence within a first window, the contactless card 1305 may be prompted for one or more additional gestures. One or more additional gestures may include a wave, tap, swipe, or any combination thereof by the contactless card 1305 to the client device 1310. If the counter 1313 is within a second window containing a second monotonic or non-monotonical sequence, the counter 1313 may be resynchronized in response to one or more additional gestures. If the counter 1313 is outside the second window, the contactless card 1305 may be deactivated in response to one or more additional gestures.

[0176] In other examples, the second process may include a client device 1305 configured to perform one or more reads of one or more applets 1311 during two or more gestures by a contactless card 1305 within the data communication range of the client device 1310. Furthermore, one or more servers 1320 may be configured to receive one or more reads from the client device 1310 based on two or more gestures to resynchronize a counter 1313. In some examples, the two or more gestures may include a wave, tap, swipe, or any combination thereof to the client device 1310 by the contactless card 1305. In some examples, the second process may include a first window configured to determine whether the increment of the counter 1313 of the contactless card 1305 belongs to a first monotonic or non-monotonical sequence. For example, if the increment of the counter 1305 of the contactless card 1310 does not belong to a first monotonic sequence within the first window, the contactless card 1305 may be prompted for one or more additional gestures. One or more additional gestures may include a wave, tap, swipe, or any combination thereof to the client device 1310 via the contactless card 1305. If the counter 1313 is within a second window containing a second monotonic or non-monotonical sequence, the counter 1313 may be resynchronized in response to one or more additional gestures. If the counter 1313 is outside the second window, the contactless card 1305 may be deactivated in response to one or more additional gestures.

[0177] Continuing with the above example, assuming a monotonic increment is used, the next value would be 102. As a result, within the range where ambiguity exists in the counter sequence (e.g., 1, 1, 2, 1), the contactless card 1305 may make one or more additional gestures to determine exactly where counter 1313 is in the sequence for resynchronization. In some examples, there may be multiple windows for trial. Thus, multiple windows may be adjusted, such as expanding one or more windows, shrinking one or more windows, or a combination thereof. If the next number for counter 1313 is presented in the next read and also within one of the windows, one or more servers 1320 may be configured to authenticate rather than deactivate contactless card 1305.

[0178] Figure 14 shows a method 1400 for resynchronizing the counters of a contactless card. Method 1400 may refer to the same or similar components described above with respect to Figure 13.

[0179] In block 1410, this method may include communication with a client device via a contactless card. The client device may communicate with one or more servers. The contactless card may include one or more processors and memory. The memory may comprise one or more applets and counters. The counters may be configured to notify of one or more attacks, including but not limited to malicious activity such as misuse, overuse, tampering with the card, interference with card communications, or any combination thereof. In some examples, one or more attacks may be associated with physical access to the contactless card. Examples of these attacks may include attempts to extract the master key of the secure elements of the contactless card, side-channel attacks via other communication paths such as the EMV chip contact interface, and / or fuzzing the contactless card or contact interface with random or structured information attempting to overload or force an unintended response from one or more applets of the contactless card.

[0180] In other examples, when an attacker attempts to impersonate a message, the attack may be detected by, for example, attempting to intercept and modify the message, or creating their own artificial message. These can be detected by, for example, replaying a message using previously used counters, such as the last counter stored on one or more servers, a modified counter, a modified message with an altered account number and / or user identification, and / or a message with altered or created ciphertext.

[0181] In some examples, one or more applets may be configured to perform one or more actions in response when a contactless card detects one or more attacks. For example, one or more applets on a contactless card may be configured to transition to a state where it does not function at all. In other examples, one or more applets on a contactless card may be configured to notify one or more servers of what attack has occurred. For example, if a fuzzing attack is detected, an encrypted value indicating a fuzzing attack may be sent to one or more servers to notify them that the contactless card may be compromised.

[0182] In some examples, counters may be tuned to include, but not limited to, increments or decrements in non-monotonical sequences. In other examples, counters may be tuned to include, but not limited to, increments or decrements in monotonical sequences. In some examples, counters may be tuned to include, but not limited to, increments or decrements in randomly generated or non-contiguous sequences. A client device may include one or more processors and memory.

[0183] In block 1420, this method may involve one or more servers comparing the received counter with a suitable counter value for synchronization. For example, one or more servers may attempt to obtain a suitable value. In one example, the counter on a contactless card may start at zero. On one or more servers, the counter may start at zero and increment, for example, by 1, so that the next expected counter is 1. If 1 is the suitable counter and one or more servers decide on a different value instead, such as 10, then it is determined whether the different value is within a particular window or range. As long as the different value is within the window or range, the counter is set to 10 and is therefore acceptable. If the different value is not within the window or range, for example, 100, then this value is obviously not equal to the suitable counter value of 1, and one or more messages may be sent to the client device. In some examples, one or more messages may include instructions that the contactless card must be gestured (operated) once or more times. In response to these one or more gestures, the counter value may be 101, which may be an acceptable number determined by one or more servers. However, in some cases, determining other numbers may cause the contactless card to be deactivated. In some cases, the contactless card may be shut down by one or more servers. For example, as mentioned above, one or more servers may stop data communication with the contactless card because it may be under attack.

[0184] In block 1430, this method may include resynchronizing counters through one or more processes based on one or more reads of one or more applets. In some examples, a single or multiple gestures of a contactless card may be used as part of one or more synchronization processes. For example, a first process may include a client device configured to perform one or more reads of one or more applets during a single gesture by a contactless card within the data communication range of the client device. Furthermore, one or more servers may be configured to receive one or more reads from the client device based on a single gesture in order to resynchronize the counters. In some examples, a single gesture may comprise a wave, tap, swipe, or any combination thereof, of the contactless card to the client device. In some examples, the first process may include a first window configured to determine whether the increment of the contactless card's counter belongs to a first monotonic or non-monotonical sequence. For example, if the increment of the contactless card's counter does not belong to a first monotonic sequence within the first window, the contactless card may be prompted for one or more additional gestures. One or more additional gestures may include a wave, tap, swipe, or any combination thereof on the client device via the contactless card. If the counter is within a second window containing a second monotonic or non-monotonical sequence, the counter may be resynchronized in response to one or more additional gestures. If the counter is outside the second window, the contactless card may be deactivated in response to one or more additional gestures.

[0185] In other examples, the second process may include a client device configured to perform one or more reads of one or more applets during two or more gestures by a contactless card within the data communication range of the client device. Furthermore, one or more servers may be configured to receive one or more reads from the client device based on two or more gestures in order to resynchronize counters. In some examples, the two or more gestures may include a wave, tap, swipe, or any combination thereof to the client device by the contactless card. In some examples, the second process may include a first window configured to determine whether the increment of the contactless card's counter belongs to a first monotonic or non-monotonical sequence. For example, if the increment of the contactless card's counter does not belong to a first monotonic sequence within the first window, the contactless card may be prompted for one or more additional gestures. One or more additional gestures may include a wave, tap, swipe, or any combination thereof to the client device by the contactless card. If the counter is within a second window containing a second monotonic or non-monotonical sequence, the counter may be resynchronized in response to one or more additional gestures. If the counter is outside the second window, the contactless card may be deactivated in response to one or more additional gestures.

[0186] Continuing with the above example, if a monotonic increment is used, the next value would be 102. As a result, if there is ambiguity in the counter sequence (e.g., 1, 1, 2, 1), the contactless card may perform one or more additional gestures to determine exactly where the counter is in the sequence for resynchronization. In some examples, there may be multiple windows for trial and error. Some client devices may perform multiple reads of the tag each time the tag is read. Thus, multiple windows may be adjusted, such as an expansion of two or three windows. If the next number in the counter is displayed and is also within one of the windows, one or more servers may be configured to authenticate the contactless card rather than deactivate it.

[0187] In block 1440, this method may include authenticating a contactless card based on counter resynchronization by one or more servers.

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

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

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

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

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

[0193] 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 server, wherein the server is Processor and A memory comprising a memory for storing a server counter, the server counter being updated in response to each read of a contactless card received from a client device, The aforementioned processor, The system receives a card counter from the contactless card, and the card counter is stored on the contactless card and corresponds to the number of times the client device has read the contactless card. For the purpose of determining synchronization, the card counter is compared with the server counter, the contactless card is authenticated when the card counter is synchronized with the server counter, and comparing the card counter with the server counter includes determining whether the increment or decrement of the card counter belongs to a first sequence within a first threshold range. If it is determined that the card counter is not synchronized with the server counter, the client device is prompted to read one or more additional contactless cards. The server decides to synchronize the updated card counters in response to receiving the updated card counters from the client device due to one or more additional reads. Based on the updated card counter resulting from the one or more additional reads, a new server counter is obtained, and the updated card counter is resynchronized to the new server counter. The system is configured to authenticate the contactless card based on the resynchronization of the card counter. server.

2. The server according to claim 1, wherein the card counter is configured to notify of an attack associated with the fraudulent use of the contactless card.

3. The server according to claim 2, wherein the attack is associated with physical access to the contactless card.

4. The server according to claim 1, wherein the card counter is read from the contactless card via short-range wireless communication with the client device.

5. A server having a processor and memory for storing server counters receives a card counter from a client device, wherein the card counter corresponds to the number of times the client device has read a contactless card. The server compares the card counter with the server counter for the purpose of determining synchronization, wherein the contactless card is authenticated when the card counter is synchronized with the server counter, and the comparison of the card counter with the server counter includes determining whether the increment or decrement of the card counter belongs to a first sequence within a first threshold range. When the server determines that the card counter is not synchronized with the server counter, it resynchronizes the card counter, and the resynchronization is The server prompts the client device to perform an additional reading of one or more of the contactless cards, The server determines the synchronization of the updated card counter in response to receiving the updated card counter from the client device due to one or more additional reads, The server obtains a new server counter based on the updated card counter resulting from the one or more additional reads, and resynchronizes the updated card counter to the new server counter. This includes resynchronizing, The server authenticates the contactless card based on the resynchronization of the card counter, A method of resynchronization that includes [specific details].

6. The method according to claim 5, wherein the reading of the card counter is based on the reading of an applet contained in the memory of the contactless card.

7. The aforementioned method, An application containing instructions to be executed on the client device performs the reading of the applet in response to a gesture including the movement of placing the contactless card within the communication range of the client device. The server receives the updated card counter from the application in order to resynchronize the card counter, The method according to claim 6, further comprising:

8. To determine synchronization, comparing the card counter with the server counter is: The server determines whether the increment or decrement of the card counter that results in a match with the server counter belongs to a first sequence within a first threshold range. The method according to claim 5, including the method described in claim 5.

9. The server resynchronizes the card counter, The server determines that the updated card counter is within a second threshold range, following the receipt of an updated card counter from the client device due to one or more additional readings of the contactless card, if the increment or decrement of the card counter does not belong to a first sequence within a first threshold range. The method according to claim 8, including the method described in claim 8.

10. The method according to claim 9, wherein the second threshold range includes a second sequence.

11. The aforementioned method, When the server determines that the updated card counter is outside the second threshold range, the server deactivates the contactless card. The method according to claim 9, further comprising:

12. The method according to claim 5, wherein the card counter is configured to notify of an attack associated with the fraudulent use of the contactless card.

13. The method according to claim 12, wherein the attack comprises at least one selected from the group of attempting to extract a master key from a secure element of the contactless card, a side-channel attack on the contactless card, and fuzzing the contactless card.

14. A resynchronization system, wherein the resynchronization system is A contactless card including a processor and memory, wherein the memory of the contactless card stores a card counter, A server that communicates data with the contactless card via a client device, wherein the server includes a processor and memory, and the memory of the server stores a server counter, The contactless card is configured to transmit the card counter to the server via the client device, and the client device is configured to establish short-range wireless communication with the contactless card. The server is configured to compare the card counter received from the client device with the server counter for synchronization determination, the contactless card is authenticated by the server when the card counter is synchronized with the server counter, and comparing the card counter with the server counter includes determining whether the increment or decrement of the card counter belongs to a first sequence within a first threshold range. The contactless card and the server are configured to resynchronize the card counter. The aforementioned server, The client device is prompted to perform an additional reading of one or more of the contactless cards. In response to receiving the updated card counter from the client device due to one or more additional reads, the system determines to synchronize the updated card counter. Based on the updated card counter resulting from the one or more additional reads, a new server counter is obtained, and the updated card counter is resynchronized to the new server counter. The system is configured to authenticate the contactless card based on the resynchronization of the card counter. Resynchronization system.

15. The resynchronization system according to claim 14, wherein the card counter is configured to notify of an attack associated with the fraudulent use of the contactless card.

16. The resynchronization system according to claim 15, wherein the attack includes an impersonation attack.

17. The contactless card is configured to decrement the card counter in a pre-generated sequence. The resynchronization system according to claim 14, wherein the server is configured to decrement the server counter in the pre-generated sequence.

18. The resynchronization system according to claim 14, wherein the contactless card is configured to decrement the card counter in a non-monotonical sequence.

19. The resynchronization system according to claim 14, wherein the contactless card is configured to increment the card counter in a non-monotonical sequence.

20. The memory of the contactless card further includes an applet, The resynchronization system according to claim 14, wherein the applet is configured to transition to a non-functional state when an attack is detected.

Images