System and method for password authentication of contactless cards

Abstract

Example embodiments of systems and methods for data transfer between a contactless card and a client application are provided. A card key can be generated using a master key and an identification number. A first session key and a second session key can be generated using a portion of the card key and a counter. A cryptographic result including the counter can be generated using one or more cryptographic algorithms and the card key. A password can be generated using the first session key, and encryption can be performed using the second session key. The application can send one or more messages to a first applet of the contactless card. The first applet can be configured to establish one or more communication paths to a second applet based on receiving one or more messages from the client device. The second applet can be deactivated by the first applet via the one or more communication paths.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is a partial continuation of U.S. patent application Ser. No. 16 / 205,119, filed on Nov. 29, 2018, and claims priority from U.S. Provisional Application No. 62 / 740,352, filed on Oct. 2, 2018, and U.S. patent application Ser. No. 16 / 590,153, filed on Oct. 1, 2019, the entire disclosures of which are incorporated herein by reference. Technical Field

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

[0004] Data security and transaction integrity are crucial for businesses and consumers. As electronic transactions account for an increasing share of commercial activities, this need continues to grow.

[0005] Email can be used as a tool for verifying transactions, but email is vulnerable to attacks and is susceptible to hacking or other unauthorized access. Short Message Service (SMS) messages can also be used, but they are also vulnerable to compromise. Moreover, even data encryption algorithms (such as the Triple - DES algorithm) have similar vulnerabilities.

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

[0007] There are these and other deficiencies. Accordingly, there is a need to provide users with appropriate solutions to overcome these deficiencies to provide data security, authentication, and verification for contactless cards. Additionally, there is a need for an improved method for activating cards, as well as an improved authentication for account access. Summary of the Invention

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

[0009] Embodiments of the present disclosure provide a card activation system. The card locking system includes: a contactless card, which includes one or more processors and a memory, where the memory includes a diversified master key, transmitted data, first and second applets, and a counter; a client application, which includes instructions for execution on a client device including one or more processors and a memory; the memory contains a master key, wherein the contactless card is configured to: generate a diversified key using the diversified master key, one or more cryptographic algorithms, and the counter, generate a cryptographic result including the counter using one or more cryptographic algorithms and the diversified key, encrypt the transmitted data using one or more cryptographic algorithms and the diversified key to produce encrypted transmitted data, and send the cryptographic result and the encrypted transmitted data to the client application; and wherein the application is configured to: generate an authentication diversified key based on the master key and a unique identifier, generate a session key based on the authentication diversified key and the cryptographic result, and decrypt the encrypted transmitted data and verify the cryptographic result using the one or more cryptographic algorithms and the session key, wherein for each transmission between the contactless card and the application, the counter is independently updated by the contactless card and the client application, wherein the first applet is configured to establish a communication path to the second applet based on a message received from the client application, and wherein the second applet is deactivated by the first applet via the communication path.

[0010] Embodiments of the present disclosure provide a method for locking a contactless card. The contactless card includes a processor and a memory. The memory contains a master key, an identification number, a first applet, a second applet, and a counter. The method includes: generating a card key using the master key and the identification number; generating a first session key using the card key and a first part of the counter, and generating a second session key using the card key and a second part of the counter, wherein the first part of the counter is different from the second part of the counter; generating a cryptographic result including the counter using one or more cryptographic algorithms and the card key; generating a password using the first session key, the password including the cryptographic result and the identification number; encrypting the password using the second session key; sending the encrypted password and the cryptographic result; receiving a deactivation instruction to deactivate the contactless card; creating a communication path to the second applet; and deactivating the second applet via the communication path.

[0011] Embodiments of the present disclosure provide a contactless card, which includes: a processor and a memory, where the memory includes a first applet, a second applet, and a counter; where the first applet is configured to receive one or more messages, where the first applet is configured to create a communication path to the second applet based on the reception of the one or more messages, where the one or more messages are configured to deactivate the second applet of the contactless card, where the second applet is reactivated based on one or more gestures of the contactless card within a communication domain, the one or more gestures including at least one selected from the group consisting of tapping, swiping, waving, or any combination thereof, and where the counter is adjusted for each transaction, and the counter is configured to increment for a predetermined number of transactions.

[0012] Other features of the disclosed design and the advantages provided thereby are explained in more detail hereinafter with reference to specific example embodiments shown in the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

[0022] Figure 8 is a flowchart showing a key operation according to an example embodiment.

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

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

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

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

[0027] Figure 13 It is a card locking system according to an exemplary embodiment.

[0028] Figure 14 It is a flowchart showing a method for locking a contactless card according to an exemplary embodiment. Detailed Description

[0029] The following description of the embodiments provides non - restrictive representative examples of reference numbers to particularly describe the features and teachings of different aspects of the present invention. From the description of the embodiments, it should be recognized that the described embodiments can be implemented separately or in combination with other embodiments. A person of ordinary skill in the art reviewing the description of the embodiments should be able to learn and understand the different described aspects of the present invention. The description of the embodiments should, to some extent, facilitate the understanding of the present invention such that other implementations that are not specifically covered but are within the knowledge of those skilled in the art after reading the description of the embodiments will be understood to be consistent with the application of the present invention.

[0030] Some embodiments of the present disclosure aim to build one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform authentication and many other functions that, otherwise, the user might need to carry a separate physical token in addition to the contactless card. By adopting a contactless interface, a method for the contactless card to interact and communicate between the user's device (such as a mobile phone) and the card itself can be provided. For example, the EMV protocol, which is the basis for many credit card transactions, includes the following authentication process that meets the requirements of the operating system but poses challenges - its use of near - field communication (NFC) is more restrictive because it can only be used in read - only mode. The exemplary embodiments of the contactless cards described herein utilize NFC technology.

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

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

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

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

[0035] In some examples, the client device 110 of the system 100 can execute one or more applications, such as software applications, which enable, for example, network communication with one or more components of the system 100 and sending and / or receiving of data.

[0036] The client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a corresponding front-end to back-end pairing with the servers 120. The client device 110 can send, for example, one or more requests to the servers 120 from a mobile device application executed on the client device 110. One or more requests can be associated with retrieving data from the servers 120. The servers 120 can receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the servers 120 can be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the servers 120 can be configured to send the received data to the client device 110, where the received data is in response to the one or more requests.

[0037] The system 100 can include one or more networks 115. In some examples, the network 115 can be a wireless network, a wired network, or one or more of any combination of wireless and wired networks, and can be configured to connect the client device 110 to the servers 120. For example, the network 115 can include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (LAN), global system for mobile communications, personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

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

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

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

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

[0042] In step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a Message Authentication Code (MAC) password. In some examples, this can occur when the application 122 reads the contactless card 105. In particular, this can occur when reading (e.g., NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC Data Exchange Format. For example, a reader such as the application 122 can send a message such as a Select Applet message, which has an applet ID of the applet that generates the NDEF. After confirming the selection, a sequence of a Select File message followed by a Read File message can be sent. For example, the sequence can include "Select Function File", "Read Function File", and "Select NDEF File". At this time, the counter value maintained by the contactless card 105 can be updated or incremented, followed by "Read NDEF File". At this time, a message that can include a header and a shared secret can be generated. Then a session key can be generated. The MAC password can be created from the message, which can include the header and the shared secret. Then the MAC password can be concatenated with one or more random data blocks, and then the MAC password and the random number (RND) can be encrypted with the session key. Thereafter, the password and the header can be concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "Read NDEF File" message).

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

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

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

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

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

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

[0049] In some examples, for verification purposes, the MAC password can be used as a digital signature. Other digital signature algorithms such as public-key asymmetric algorithms, such as the Digital Signature Algorithm and the RSA algorithm, or zero-knowledge protocols, can be used to perform the verification.

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

[0051] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and ciphertext-based message authentication code (CMAC) algorithms, it is important that the key remains 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 cryptographic algorithm and the same key.

[0052] It is also important that the same key is not used too many times. If the key is used or reused too frequently, the key may be compromised. Each time the key is used, an additional data sample that has been processed by the cryptographic algorithm using the same key is provided to the attacker. The more data processed using the same key the attacker has, the more likely the attacker is to discover the key value. Keys that are used frequently may be included in various different attacks.

[0053] In addition, each time a symmetric cryptographic algorithm is executed, it may reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data may include minute power fluctuations that occur when the encryption algorithm is executed using the key. Sufficient measurements can be made of the side-channel data to reveal sufficient information about the key to enable it to be recovered by an attacker. Exchanging data using the same key will repeatedly reveal the data processed by the same key.

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

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

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

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

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

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

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

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

[0062] At block 235, before sending the result to the receiving device 210, the sensitive data can be processed using the diversified symmetric key. For example, the sending device 205 can encrypt the sensitive data using a symmetric encryption algorithm that uses the diversified symmetric key, where the output includes protected encrypted data. Then, the sending device 205 can send the protected encrypted data and the counter value to the receiving device 210 for processing.

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

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

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

[0066] The next time sensitive data needs to be sent from a sender to a recipient via the respective sending device 205 and receiving device 210, a different counter value may be selected to generate a different diversified symmetric key. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 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.

[0067] As described above, both the sending device 205 and the receiving device 210 initially have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is independently created by both the sending device 205 and the receiving device 210, it is never transmitted between the two parties. Thus, an attacker cannot intercept the diversified symmetric key, and the attacker never sees any data processed using the master symmetric key. The master symmetric key is used to process only the counter value, not the sensitive data. As a result, reduced side-channel data about the master symmetric key is revealed. Moreover, the operations of the sending device 205 and the receiving device 210 can be controlled by symmetry requirements regarding how often new diversified values and thus new diversified symmetric keys are created. In one embodiment, a new diversified value and thus a new diversified symmetric key can be created for each exchange between the sending device 205 and the receiving device 210.

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

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

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

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

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

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

[0074] System 300 may include one or more hardware security modules (HSMs) 330. By way of 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 dedicated security devices that are configured to perform one or more cryptographic operations. HSM 330 may be configured such that keys are never leaked outside of HSM 330, but rather are kept within HSM 330. For example, one or more HSMs 330 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 330 may be included within servers 320 and 325 or may communicate data with servers 320 and 325.

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

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

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

[0078] The application 311 of any one of the client devices 310 may communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). The application 311 may be configured to interface with the 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 twenty centimeters is consistent with the NFC range.

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

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

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

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

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

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

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

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

[0087] At block 420, the sending device can then encrypt the counter value using the master symmetric key via the selected symmetric encryption algorithm, thereby creating a diversified symmetric key. Before sending the result to the receiving device, the diversified symmetric key can be used to process the sensitive data. For example, the sending device can encrypt the sensitive data using a symmetric encryption algorithm that uses the diversified symmetric key, where the output includes the protected encrypted data. Then, the sending device can send the protected encrypted data and the counter value to the receiving device for processing. In some examples, cryptographic operations other than encryption can be performed, and the diversified symmetric key can be used to perform multiple cryptographic operations before transmitting the protected data.

[0088] In certain examples, the counter value may not be encrypted. In these examples, the counter value can be sent between the sending device and the receiving device without encryption at block 420.

[0089] At block 430, one or more cryptographic algorithms and the diversified key can be used to protect the sensitive data. The diversified session key created through key diversification using the counter can be used with one or more cryptographic algorithms to protect the sensitive data. For example, a first diversified session key can be used by the MAC to process the data, and a second diversified session key that produces the protected data can be used to encrypt the resulting output.

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

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

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

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

[0094] As described above, both the sending device and the receiving device initially have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is independently created by the sending device and the receiving device, it is never transmitted between the two parties. Thus, an attacker cannot intercept the diversified symmetric key, and the attacker never sees any data processed using the master symmetric key. Only a small counter value is processed using the master symmetric key, rather than the sensitive data. As a result, reduced side-channel data about the master symmetric key is revealed. Also, the sender and the receiver can, for example, agree via a previous arrangement or otherwise on how often to create new diversified values and thus new diversified symmetric keys. In one embodiment, a new diversified value and thus a new diversified symmetric key can be created for each exchange between the sending device and the receiving device.

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

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

[0097] In other examples, for example, to limit the number of uses of the master symmetric key, the sender of the sending device and the receiver of the receiving device can agree that new diversified values, and thus new diversified symmetric keys, will only occur periodically. In one example, this can be after a predetermined number of uses, such as after every ten transmissions between the sending device and the receiving device. In another example, this can be after a certain period of time, after a specific period of time after a transmission, or be periodic (e.g., daily at a specified time; weekly at a specified time on a specified date). In another example, this can be 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 strategically and can change due to, for example, the current risk level perceived by the receiver of the receiving device.

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

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

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

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

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

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

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

[0105] In one embodiment, the coil of the contactless card 500 can be used as the secondary of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting off power or amplitude modulation. The contactless card 500 can infer the data sent from the terminal using the gap in the power connection of the contactless card, and the gap can be functionally maintained by one or more capacitors. The contactless card 500 can perform backhaul by switching the load on the coil of the contactless card or load modulation. The load modulation can be detected in the coil of the terminal by interference.

[0106] As described above, the contactless card 500 can be built on a software platform that can operate on a smart card or other devices with limited memory (such as JavaCard), and can securely execute one or more applications or applets. In various mobile application-based use cases, applets can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA). 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 that includes an encrypted and secure OTP encoded as an NDEF text tag.

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

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

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

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

[0111]

[0112]

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

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

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

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

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

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

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

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

[0121] At block 820, the counter can be used as diversification data since it changes with each use and provides a different session key each time, as opposed to master key derivation - in which a single unique set of keys is generated per card. In some examples, it is preferable to use a 4-byte method for both operations. Thus, at block 820, two session keys can be created for each transaction from the ETDK, i.e., one session key from the AEGTKEU and one session key from the ENCKEY. In the card, for the MAC key (i.e., the session key created from the AGTEKEU), 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 full length of the OTP counter can be used for the ENC key.

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

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

[0124] For contactless cards, different unique identifiers are derived, which can be related to the Application Primary Account Number (PAN) and PAN serial number encoded in the card. Key diversification can be configured to receive the identifier as an input to the master key, so that one or more keys can be created for each contactless card. In some examples, these diversified keys can include a first key and a second key. The first key can include the Authentication Master Key (Card Crypotogram Generation / Authentication Key—Card-Key-Auth), and can be further diversified to create the MAC session key used in generating and verifying the MAC password. The second key can include the Encryption Master Key (Card Data Encryption Key—Card-Key-DEK), and can be further diversified to create the ENC session key used in encrypting and decrypting the encrypted data. In some examples, the issuer master key can be diversified by combining it with the unique ID number (pUTD) of the card of the payment applet and the PAN serial number (PSN) to create the first key and the second key. The pUID can include a 16-digit numerical value. As described above, the pUID can include 16-digit BCD-encoded digits. In some examples, the pUTD can include a 14-digit numerical value.

[0125] In certain examples, since the EMV session key derivation method can be wrapped when used at 2^16, a counter (e.g., a full 32-bit counter) can be added to the initialization array of the diversification method.

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

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

[0128] Regarding master key management, for each part of the layout for issuing one or more applets, two issuer master keys 905, 910 may be required. For example, the first master key 905 may include an issuer cryptographic generation / authentication key (Iss-Key-Auth), while the second master key 910 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, diversifying the two issuer master keys 905, 910 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, which are background data, can be used to identify which issuer master key 905, 910 is used for authentication during the encryption process. The system that performs the authentication can be configured to retrieve the values of the pNPR 915 and pDKI 920 of the contactless card during authentication.

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

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

[0131] In addition, the update of each card can be unique and can be assigned either through personalization or algorithmically through a pETID or other identification information. For example, cards with odd numbers can be incremented or decremented by 2, while cards with even numbers can be incremented or decremented by 5. In some examples, the update can also vary in sequential reads such that a card can be incremented in sequence with a repetition of 1, 3, 5, 2, 2... A specific sequence or algorithmic sequence can be defined at the time of personalization or based on one or more processes derived from a unique identifier. This makes it more difficult for replay attackers to generalize from a small number of card instances.

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

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

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

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

[0136]

[0137]

[0138]

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

[0140]

[0141]

[0142]

[0143]

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

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

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

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

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

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

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

[0151] At block 1020, the issuer master key can be diversified by combining the issuer master key with the unique ID number (pUID) of the card and the PAN serial number (PSN) of one or more applets (e.g., a payment applet).

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

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

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

[0155] At block 1120, the counter value can be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value can 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 can be used during both encryptions.

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

[0157] At block 1130, the sender processes the data to be protected through a cryptographic MAC operation using the data integrity session key and a cryptographic MAC algorithm. One of the session keys (AUT - Session - Key) can be used to generate the MAC for the protected data (including plain text and shared secrets).

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

[0159] At block 1150, the encrypted MAC is sent from the sender to the receiver, with sufficient information to identify additional secret information (such as shared secrets, master keys, etc.) to authenticate the cipher.

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

[0161] At block 1170, the data encryption derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Then additional processing of the exchanged data occurs. In some examples, after extracting the MAC, it is expected to reproduce and match the MAC. For example, when authenticating the cipher, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. An MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

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

[0163] In some examples of the methods described herein, when the following conditions are met, it can be advantageously confirmed when a successful authentication has been determined. First, the ability to verify the MAC indicates that the derived session key is correct. The MAC is correct only if the decryption is successful and produces the correct MAC value. Successful decryption can indicate that the correctly derived encryption key has been 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 the receiver (e.g., the receiving device), it can be believed that the contactless card that originally created the MAC and encrypted the MAC is indeed trustworthy. Also, the counter values used to derive the first session key and the second session key can be shown to be valid and can be used to perform authentication operations.

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

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

[0166] In some examples, the contactless card can be tapped against a device such as one or more kiosks or terminals to verify identity for receiving a transaction item in response to a purchase (such as coffee). By using the contactless card, a secure method of proving identity in a loyalty program can be established. A secure way of proving identity is established in a different way than just scanning a barcode to, for example, obtain rewards, coupons, offers, etc., or receive benefits. For example, an encrypted transaction may occur between the contactless card and the device, and the transaction 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, for example, cause the user to act or respond to it via one or more tap gestures. In some examples, data such as consumer points, loyalty points, reward points, healthcare information, etc. can be written back to the contactless card.

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

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

[0169] In some embodiments, a dedicated application may be configured to execute on a client device to perform activation of a contactless card. In other embodiments, a web portal, a web-based application, an applet, etc. may perform the activation. The activation may be performed on the client device, or the client device may merely act as a channel between the contactless card and an external device (e.g., an account server). According to some embodiments, when providing the activation, the application may indicate to the account server the type of device on which the activation is being performed (e.g., a personal computer, a smart phone, a tablet, or a point-of-sale (POS) device). Additionally, depending on the type of device involved, the application may output different and / or additional data to the account server for transmission. For example, such data may include information associated with a merchant, such as merchant type, merchant ID, and information associated with the device type itself such as POS data and POS ID.

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

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

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

[0173] As another example, the tap of a contactless card can be directed to a POS device, which includes but is not limited to a kiosk, checkout counter, payment station, or other terminal. Upon performing the tap, the contactless card can identify the POS device and send only the information required for the action or transaction. For example, after identifying a POS device for completing a commercial transaction, the contactless card can transmit the payment information required to complete the transaction under the EMV standard.

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

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

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

[0177] In some examples, one or more apps can be configured to determine that they are launched by one or more tap gestures of a contactless card such that the launch occurs at 3:51 PM and the transaction is processed or occurs at 3:56 PM to verify the user's identity.

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

[0179] In some examples, data about tap behavior can be collected for biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and not easily intercepted can be sent to one or more backend services. The unique identifier can be configured to look up secondary information about an individual. The secondary information can include personally identifiable information about the user. In some examples, the secondary information can be stored within a contactless card.

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

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

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

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

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

[0185] In block 1220, one or more portions of the dynamically generated data can be transmitted to an application on the device via NFC or other wireless communication. For example, tapping the card near the device can allow the application on the device to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to assist with the activation of the card, tapping the card can direct the device or prompt the user to a software application store to download the associated application to activate the card. In some examples, the user can be prompted to sufficiently present, place, or orient the card towards the surface of the device, such as at an angle or flat on the surface of the device, placed near it, or placed close to it. In response to the sufficient presentation, placement, and / or orientation of the card, the device can continue to send one or more encrypted portions of the data received from the card to one or more servers.

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

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

[0188] In block 1250, one or more servers can send a return message based on the successful activation of the card. For example, the device can be configured to receive an output from the one or more servers indicating that the one or more servers have successfully activated the card. The device can be configured to display a message indicating the successful activation of the card. Once the card is activated, the card can be configured to disconnect dynamic generation of data, thereby avoiding fraudulent use. In this way, the card can thereafter not be activated, and the one or more servers can be notified that the card has been activated.

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

[0190] A user can attempt to lock a payment, transaction, or other type of card to prevent unauthorized activities such as misuse or fraud. However, it is the back-end server that performs locking the user's card to prevent misuse or fraud upon the user's request or when the card-issuing institution detects suspicious activities. In such cases, there is usually a possibility that the card may still perform transactions offline or otherwise perform unauthorized transactions. By leveraging the systems and methods described herein, a message can be sent to one of the applets of the card to deactivate the payment applet. One of the applets can establish a secure channel to the payment applet and deactivate the payment applet on the chip, thus bypassing any firewalls within the contactless card. Additionally, reactivating the function of the deactivated payment applet can restore the use of the card. In some examples, the applets can be controlled or otherwise owned by a financial institution. As further described below, the systems and methods described herein provide applet-to-applet communication to lock contactless cards.

[0191] Figure 13 System 1300 is shown, such as a card locking system, which includes a contactless card 1305, a client device 1310, and one or more servers 1320. Although Figure 13 a single instance of the components is shown, system 1300 can include any number of components. The contactless card 1305, the client device 1310, and the one or more servers 1320 can refer to the same or similar components as previously referenced Figure 1A 、 Figure 1B 、 Figure 5A and Figure 5B described, such as the contactless card 105, the client device 110, and the server 120. It should be understood that in some examples, the contactless card 1305 can be another device, such as a device the same as or similar to the client device 1310.

[0192] The contactless card 1305 may include one or more processors 1307 and a memory 1309. The memory 1309 may include a plurality of applets. In some examples, the memory may include a first applet 1311 and a second applet 1313. As described above, the first applet 1313 of the contactless card 1305 may allow communication between the contactless card 1305 and the client device 1310. In some examples, the contactless card 1305 may communicate with the client device 1310 via a communication interface (not shown). The second applet 1313 of the contactless card 1305 may include, but is not limited to, a payment applet. The memory 1309 may include a counter. The second applet 1313 may be reactivated, for example, based on one or more gestures of the contactless card 1305 to the client device 1310. In some examples, one or more gestures may include tapping, swiping, waving, or any combination thereof. For example, reactivation of the second applet 1313 may occur when the contactless card 1305 is placed within the communication domain of the client device 1310. The first applet 1311 may be configured to monitor transaction information and the amount associated with each transaction. In some examples, the counter may be adjusted for each transaction such that the counter may be configured to increment within a predetermined number of transactions. For example, the contactless card 1305 may be configured to be utilized within a limited range, a limited duration, or any combination thereof before deactivating the second applet 1313, which may be predetermined at the time of card issuance or card activation, or may be dynamically adjusted after card issuance or activation of the card. In some examples, deactivation of the second applet 1313 may be based on exceeding one or more predetermined thresholds, thresholds that are dynamically set or adjusted, or any combination thereof. The threshold may be based on one or more of the following: user status (e.g., paid or indebted account status), user history (e.g., spending history, payment history), account activity, account history, transaction limits, spending limits, time limits, location geographical limits, commodity or service category or type limits, merchant or seller category limits, point-of-sale devices (e.g., online commerce, retail kiosk), or any combination thereof.

[0193] The client device 1310 may include one or more processors 1312 and a memory 1314. The client device 1310 may communicate data with the contactless card 1305. The client device 1305 may be configured to send one or more messages to a first applet 1311 of the contactless card 1305. In some examples, the one or more messages may be configured to deactivate a second applet 1313 of the contactless card 1305. Based on the one or more messages from the client device 1310, the first applet 1311 may be configured to establish one or more communication paths 1315 to the second applet 1313. In some examples, the one or more communication paths 1315 may include a secure channel. The first applet 1311 may be configured to deactivate the second applet 1313 via the one or more communication paths 1315.

[0194] One or more servers 1320 may communicate data with the client device 1310. One or more servers 1320 may be configured to provide one or more actions in response to the deactivation of the second applet 1313. One or more notifications may include the sending of one or more messages to the client device 1310. In some examples, the one or more messages may indicate location information of the contactless card 1305. In some examples, the one or more messages may indicate account information of the contactless card. In some examples, the one or more messages may indicate loyalty or reward points. In other examples, the one or more messages may include any combination thereof.

[0195] In one example, an entity may have multiple contactless cards operating in accordance with the systems and methods disclosed herein. For example, one of the contactless cards 1305 may be associated with the entity, including (but not limited to) a corporate account card, in which it may be used for transactions such as purchases and then remain dormant or otherwise inactive when not in use upon returning to the entity. The contactless card 1305 may then be tapped or otherwise posed to reactivate the card. The first applet 1311 of the contactless card 1305 may be configured to enable and disable the second applet 1313 of the contactless card 1305. As described above, this is different from using the server 1320 to do so, which is for certain values regarding micropayments. Then, the contactless card 1305 itself is blocked from being active and cannot be used on a device such as a point-of-sale device. Therefore, the first applet 1311 may be configured to set the contactless card 1305 to an inactive state.

[0196] As described above, the gesture may include one or more of tapping, swiping, waving, etc. or any combination thereof. In some examples, the contactless card 1305 must be within the communication domain of the client device 1310 in order for it to be powered up and reactivated. As a result, machine learning can be used to learn how often the contactless card 1305 needs to be reactivated, including but not limited to batch reactivation of a portion of the contactless cards. Additionally, notifications or reminders can be provided via an application (not shown) executed on the client device 1310, including but not limited to: the contactless card has been deactivated for a period of time, where the contactless card 1305 was recently or currently located, how to use the contactless card 1305 to obtain more rewards or points, and account balance information.

[0197] In another example, an individual, including but not limited to a child, may wish to use the contactless card 1305 operating in accordance with the systems and methods disclosed herein to perform one or more transactions, such as a purchase. Although the contactless card 1305 may be owned by the individual, the contactless card 1305 may operate within limited or restricted usage. The temporary usage may be controlled by one or more factors, including but not limited to: a limited range, a limited duration, the type of individual, and the purpose of the transaction, or any combination thereof.

[0198] In another example, the server 1320 may be configured to monitor the deactivation of the contactless card over a period of time (e.g., minutes, hours, days, weeks, or months, etc.). For example, a user of the contactless card 1305 may be on a business trip and subject to restrictions regarding one or more transactions (including but not limited to purchases) associated with the contactless card 1305. Thus, the contactless card 1305 may include transaction information, such as the history and usage of the contactless card 1305, where the contactless card 1305 tracks the amount spent and is then disabled after exceeding a certain spending limit threshold. In some examples, a counter may be used to determine when an adjustment is made, such as setting a number of incremented instances, before the contactless card 1305 is deactivated regarding the threshold. In effect, the contactless card 1305 may be shut down for any charge that exceeds the threshold. The contactless card 1305 may store transaction information as well as the credited amount.

[0199] Figure 14 A method 1400 for locking a contactless card is shown. The method 1400 may refer to the same or similar components as described above with respect to Figure 13 described.

[0200] At block 1410, the method may include: communicating from a contactless card to a client device, the contactless card including one or more processors and a memory. The memory may include a plurality of applets. In some examples, the memory may include a first applet and a second applet. As described above, the first applet of the contactless card may allow communication between the contactless card and a mobile device. The second applet of the contactless card may include, but is not limited to, a payment applet. The memory may include a counter. The counter is adjusted for each transaction and is configured to increment for a predetermined number of transactions. The client device may include one or more processors and a memory.

[0201] At block 1420, the method may include sending, by the client device, one or more messages to the first applet of the contactless card. At block 1430, the method may include creating, by the first applet, a communication path to the second applet based on the one or more messages from the client device. For example, the communication path may include a secure channel.

[0202] At block 1440, the method may include: deactivating, based on the one or more messages, the second applet of the contactless card via the communication path. The second applet may be deactivated for a predetermined period of time. The second applet may be reactivated based on one or more gestures from the contactless card to the client device. The one or more gestures may include one or more of tapping, swiping, waving, or any combination thereof. In some examples, for instance, when the contactless card is placed within the communication domain of the client device, reactivation of the second applet may occur.

[0203] At block 1450, the method may include: providing, by one or more servers in response to the deactivation of the second applet, one or more actions. For example, the one or more actions may include sending one or more messages to the client device. In some examples, the one or more messages may indicate location information of the contactless card. In some examples, the one or more messages may indicate account information of the contactless card. In some examples, the one or more messages may indicate loyalty or reward points. In other examples, the one or more messages may include any combination thereof.

[0204] For example, the contactless card may be configured to communicate with a device to disable one or more capabilities or functions of the contactless card, including but not limited to: deactivation of an applet (such as a payment applet). As a result, one or more servers may be notified that the contactless card has been shut down due to one or more deactivated capabilities or functions. In some examples, one or more servers may be configured to remind the user that the contactless card has been unusable for a period of time, such as a few hours, days, weeks, or months, etc., due to the disablement.

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

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

[0207] In this description, many specific details have been set forth. However, it should be understood that embodiments of the disclosed technology may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification. References to "some examples", "other examples", "one example", "examples", "various examples", "one embodiment", "embodiment", "some embodiments", "example embodiments", "various embodiments", "one implementation", "implementations", "exemplary implementations", "various implementations", "some implementations", etc. indicate that the described embodiments of the disclosed technology may include particular features, structures, or characteristics, but not every implementation must include the particular features, structures, or characteristics. Further, although the phrases "in one example", "in one embodiment", or "in one implementation" may be reused, they do not necessarily refer to the same example, embodiment, or implementation.

[0208] As used herein, unless otherwise stated, the use of ordinal adjectives "first", "second", "third", etc. to describe a common object only refers to different instances of similar objects being referenced, and is not intended to imply that the objects so described must be in a given order in terms of time, space, rank, or any other manner.

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

[0210] This written description uses examples to disclose certain embodiments of the disclosed technology, including the best mode, and also enables those skilled in the art to practice certain embodiments of the disclosed technology, including making and using any device or system and performing any included method. The patentable scope of certain implementations of the disclosed technology is defined in the claims, and may include other examples that occur to those skilled in the art. If such other examples have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that do not have a substantial difference from the literal language of the claims, then they are intended to be within the scope of the claims.

Claims

1. A non-contact card, comprising: A processor; and a memory, wherein the memory includes a first applet, a second applet, and a counter, wherein the first applet is configured to: create a communication path to the second applet in response to one or more messages configured to deactivate the second applet, and deactivate the second applet via the communication path, wherein the second applet is reactivated based on one or more gestures of the contactless card within a communication domain, the one or more gestures including at least one selected from the group consisting of tapping, swiping, waving, or any combination thereof, and wherein the counter is adjusted for each transaction involving the contactless card, the counter being configured to increment for a predetermined number of transactions.

2. The non-contact card according to claim 1, wherein, The communication path includes a secure channel.

3. The non-contact card according to claim 1, wherein, The first applet is further configured to receive the one or more messages from an application executing on a receiving device.

4. The non-contact card according to claim 3, wherein, The receiving device includes a server, and the one or more messages are received by the first applet via a client device.

5. The non-contact card according to claim 1, wherein, The first applet is configured to deactivate the second applet within a predetermined time period.

6. The non-contact card according to claim 1, wherein, The first applet is further configured to deactivate the second applet based on exceeding a threshold.

7. The non-contact card according to claim 6, wherein, The threshold includes at least one selected from the group consisting of user status, user history, account activity, account history, transaction limit, spending limit, time limit, location limit, merchandise type limit, service type limit, merchant limit, and point-of-sale device type.

8. The non-contact card according to claim 1, wherein, The first applet is further configured to set the contactless card to an inactive state.

9. The non-contact card according to claim 1, wherein, The first applet is further configured to deactivate the second applet based on exceeding a spending limit threshold.

10. The non-contact card according to claim 1, wherein, The contactless card is active for limited use.

11. The non-contact card according to claim 10, wherein, The limited use is based on at least one selected from the group consisting of a limited range, a limited duration, a personal type, and a transaction purpose.

12. The non-contact card according to claim 11, wherein, The personal type includes children.

13. A method, comprising: Creating, by a first applet stored on the contactless card, a communication path to the second applet in response to one or more messages configured to deactivate the second applet stored on the contactless card; and Deactivating, by the first applet, the second applet via the communication path; and Reactivating, by the first applet, the second applet based on one or more gestures of the contactless card within a communication domain, the one or more gestures including at least one selected from the group consisting of tapping, swiping, waving, or any combination thereof, wherein a counter stored on the contactless card is adjusted for each transaction involving the contactless card, the counter being configured to increment for a predetermined number of transactions.

14. The method according to claim 13, further comprising: Sending, by the server in response to the deactivation of the second applet, one or more response messages to the client device, wherein the one or more response messages indicate at least one selected from the group consisting of location information, account information, and reward points.

15. The method according to claim 14, further comprising the server monitoring a time period associated with the deactivation of the second applet.

16. The method according to claim 13, wherein the first applet is configured to deactivate the second applet based on exceeding a threshold, and the threshold includes at least one selected from the group consisting of user status, user history, account activity, account history, transaction limits, spending limits, time limits, location limits, merchandise type limits, service type limits, merchant limits, and point of sale device types.

17. The method according to claim 13, further comprising the contactless card receiving power from the communication domain before adjusting the counter.

18. A non-transitory computer-readable medium comprising instructions for execution by a processor of a contactless card, wherein, When executed, the processor is configured to execute a program including the following: A communication path to the second small application is created by the first small application in response to one or more messages configured to deactivate the second small application; The second small application is deactivated by the first small application via the communication path; And The second small application is reactivated by the first small application based on one or more gestures of the contactless card within the communication domain, the one or more gestures including at least one selected from the group consisting of tapping, swiping, waving, or any combination thereof, wherein a counter stored by the contactless card is adjusted for each transaction involving the contactless card, the counter being configured to increment for a predetermined number of transactions.

19. The non-transitory computer-readable medium according to claim 18, wherein the communication path includes a secure channel.

20. The non-transitory computer-readable medium according to claim 18, the first applet is configured to deactivate the second applet based on exceeding a threshold, and the threshold includes at least one selected from the group consisting of user status, user history, account activity, account history, transaction limits, spending limits, time limits, location limits, merchandise type limits, service type limits, merchant limits, and point of sale device types.

Images