System and method for password authentication of contactless card

Abstract

An example embodiment of a system and method for data transmission between a contactless card, a client device, and one or more servers is provided. The contactless card may include one or more processors and memory, which may include one or more applets. The client device may include one or more processors and memory. The client device may communicate data with the contactless card. One or more servers may communicate data with the client device. A first set of information may be sent from the contactless card to the client device. The first set of information may include one or more links to activate the contactless card via a specified email program. After the one or more servers verify the first set of information, the contactless card may be activated.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 16 / 546,792, filed on August 21, 2019, which is a continuation-in-part of and claims priority to U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, and this application claims priority from U.S. Provisional Patent Application No. 62 / 740,352, filed on October 2, 2018, the entire disclosure of which is incorporated herein by reference. Technical Field

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

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

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

[0006] Activating many cards, including, for example, financial cards (e.g., credit cards and other payment cards) involves a time-consuming process in which the cardholder dials a phone number or visits a website and enters or otherwise provides card information. In addition, while the increasing use of chip-based financial cards provides more secure functionality for personal purchases than previous technologies (e.g., magnetic stripe cards), account access may still rely on login credentials (e.g., username and password) to confirm the cardholder's identity. However, if the login credentials are compromised, others may be able to access the user's account.

[0007] These and other deficiencies exist. Therefore, there is a need to provide users with appropriate solutions that overcome these deficiencies to provide data security, authentication and verification for contactless cards. In addition, there is a need for an improved method of activating cards, and 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] An embodiment of the present disclosure provides a card activation system, which includes: a contactless card, which includes one or more processors and a memory, wherein the memory contains one or more applets; a client application, which includes instructions for execution on a client device including the one or more processors and the memory; and one or more servers, wherein the one or more applets of the contactless card are configured to send a first set of information to the client application after the contactless card enters a communication field, the first set of information including one or more links configured to activate the contactless card through an email program, wherein the client application is configured to receive the first set of information from the one or more applets of the contactless card and send it to the one or more servers for verification, wherein if the one or more servers verify the first set of information, the contactless card will be activated.

[0010] An embodiment of the present disclosure provides a method for activating a contactless card, the method comprising the following steps: entering a communication field through a contactless card; sending a first set of information to a client application via the communication field by one or more small application programs contained in a memory of the contactless card, the first set of information including one or more links, the links being configured to activate the contactless card via a designated email program; sending the first set of information to one or more servers by the client application; performing one or more cryptographic operations by the one or more servers to verify the first set of information; and activating the contactless card by the one or more servers after verifying the first set of information.

[0011] An embodiment of the present disclosure provides a contactless card, comprising: a processor; a memory, wherein the memory contains one or more small applications and a first set of information, wherein, after the contactless card enters a communication field, the one or more small applications are configured to send the first set of information, wherein the first set of information includes: one or more links configured to activate the contactless card via an email program, the one or more links including a first information element and a second information element, wherein the first information element includes an email address, and the second information element includes an encrypted payload.

[0012] Further 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 illustrating 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 flow chart illustrating a method of 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 messages communicated with a device according to an example embodiment.

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

[0022] Figure 8 is a flowchart illustrating key operations according to an exemplary embodiment.

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

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

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

[0026] Fig.12 is a flow chart illustrating a method for card activation according to an example embodiment.

[0027] Fig.13 is a card activation system according to an example embodiment.

[0028] Fig.14 is a method for card activation according to an example embodiment. DETAILED DESCRIPTION

[0029] The following description of the embodiments provides non-limiting representative examples of reference numbers to particularly describe the features and teachings of different aspects of the present invention. From the description of the embodiments, it should be appreciated that the described embodiments can be implemented separately or in combination with other embodiments. Those of ordinary skill in the art who review 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 facilitate understanding of the present invention to some extent, so that other implementations that are not specifically covered but within the knowledge of those skilled in the art who have read the description of the embodiments will be understood to be consistent with the application of the present invention.

[0030] An object of some embodiments of the present disclosure is to build one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform authentication and many other functions that might otherwise require the user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, a method can be provided for the contactless card to interact and communicate between the user's device (e.g., a mobile phone) and the card itself. For example, the EMV protocol that underlies many credit card transactions includes the following authentication process that satisfies operating system requirements, but given This brings challenges - it is more restrictive to the use of near field communication (NFC) because it can only be used in a read-only manner. The exemplary embodiment of the contactless card described herein utilizes NFC technology.

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

[0032] The system 100 may include one or more contactless cards 105, which will be referred to below. Figure 5A-5B Further explanation: In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110 using NFC, for example.

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

[0034] The client device 110 device may include a processor and memory, and it should be understood that the processing circuit may contain additional components, including a processor, memory, error and parity check / CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives and anti-tampering 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: a liquid crystal display, a light emitting diode display, a plasma panel, and a cathode ray tube display. The input device may include any device for inputting information into a user device to be available and supported by the user device, such as a touch screen, a keyboard, a mouse, a cursor control device, a touch screen, a microphone, a digital camera, a video recorder, or a portable camera. These devices can be used to input information and interact with the software and other devices described herein.

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

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

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

[0038] In addition, the network 115 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. In addition, the network 115 may support an Internet network, a wireless communication network, a cellular network, the like, or any combination thereof. The network 115 may further include a network, or any number of the exemplary types of networks described above, operating as independent networks or in collaboration with one another. The network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 115 may convert to one or more protocols of a network device or convert from other protocols to one or more protocols of a network device. Although the network 115 is depicted as a single network, it should be understood that, according to one or more examples, the network 115 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network (e.g., a credit card associated 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 call various data at different times to perform multiple workflow actions. Server 120 may be configured to connect to one or more databases. Server 120 may be connected to at least one client device 110.

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

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

[0042] At step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a message authentication code (MAC) password. In some examples, this may occur when the application 122 reads the contactless card 105. In particular, this may occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader such as the application 122 may send a message such as an applet selection message, which has the 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 may be sent. For example, the sequence may include "select function file", "read function file", and "select NDEF file". At this point, a counter value maintained by the contactless card 105 may be updated or incremented, which may be followed by "read NDEF file". At this point, a message that may include a header and a shared secret may be generated. A session key may then be generated. A MAC password may be created from the message, which may include a header and a shared secret. The MAC password can then be concatenated with one or more random data blocks, and the MAC password and random number (RND) can then be encrypted with the session key. Thereafter, the password and header can be concatenated and 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 may be sent as an NDEF tag, and in other examples, the MAC password may be included in a uniform resource indicator (eg, as a formatted string).

[0044] In some examples, application 122 may be configured to send a request to contactless card 105 that includes instructions for generating a 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, but the present disclosure is not limited thereto. In other examples, the communication can occur via Bluetooth, Wi-Fi or other wireless data communication methods.

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

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

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

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

[0050] Figure 2 2 shows a data transmission system according to an example embodiment. The system 200 may include a transmission or sending device 205, a receiving or receiver device 210, and one or more servers 220 in communication via a network 215. The transmission or sending device 205 may be similar to the above-referenced Figure 1A The receiving or recipient device 210 may be the same as or similar to the client device 110 discussed above. Figure 1A The client device 110 discussed above may be the same or similar. The network 215 may be similar to the client device 110 discussed above. Figure 1A The network 115 discussed above. The server 220 may be similar to Figure 1A Server 120 of discussion. Although Figure 2 A single instance of a component of system 200 is shown, but system 200 may include any number of the shown components.

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

[0052] It is also important that the same key is not used too many times. If a key is used or reused too frequently, it can be compromised. Each time a key is used, it provides an attacker with an additional sample of data that has been processed by the cryptographic algorithm using the same key. The more data an attacker has that has been processed using the same key, the greater the chance that the attacker can discover the value of the key. A key that is used frequently can be included in a variety of different attacks.

[0053] Additionally, 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 tiny power fluctuations that occur when the cryptographic algorithm is executed while using the key. Sufficient measurements may be made on the side-channel data to reveal enough information about the key to enable it to be recovered by an attacker. Exchanging data using the same key will repeatedly reveal 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, the 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 keys in use, along with the need to rely on any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and receiver, the above-described attacks are made impossible.

[0055] Back to Figure 2, the system 200 can be configured to implement key diversification. For example, the sender and the receiver may wish to exchange data (e.g., original 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. In addition, it should be understood that any party or device having the same secret symmetric key can perform the functions of the sending device 205, and similarly, any party having the same secret symmetric key can perform the functions of the receiving device 210. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all other parties except the sending device 205 and the receiving device 210 involved in exchanging secure data. It should also be understood that both the sending device 205 and the receiving device 210 can 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 can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the sending device 205 and the receiving device 210.

[0056] The system 200 may include one or more networks 215. In some examples, the 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 a server 220. For example, the 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 system based on time division multiplexing, a system based on code division multiple access, D-AMPS, Wi-Fi, fixed wireless data, IEEE802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, etc.

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

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

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

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

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

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

[0063] At block 240, receiving device 210 may first obtain the counter value and then 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 may be the same diversified symmetric key value created by the sender.

[0064] At block 245 , the receiving device 210 may then obtain the protected encrypted data and decrypt the protected encrypted data using the symmetric decryption algorithm and the 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 the sender to the receiver via the corresponding sending device 205 and receiving device 210, different counter values ​​can be selected to generate different diversified symmetric keys. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 can independently generate the same diversified symmetric key. This diversified symmetric key is used to protect sensitive data instead of the master symmetric key.

[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 the sending device 205 and the receiving device 210, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker will never see any data processed using the master symmetric key. Only counter values, not sensitive data, are processed using the master symmetric key. As a result, reduced side channel data about the master symmetric key is revealed. Moreover, the operation of the sending device 205 and the receiving device 210 can be controlled by the symmetry requirements of how often a new diversified value and thus a new diversified symmetric key are created. In one embodiment, a new diversified value can be created for each exchange between the sending device 205 and the receiving device 210, and thus a new diversified symmetric key is created.

[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 and sent from the sending device 205 to the receiving device 210; the full value of the counter value sent from the sending device 205 and the receiving device 210; a portion of the counter value sent from the sending device 205 and the receiving device 210; a counter maintained independently by the sending device 205 and the receiving device 210 but not sent between the two devices; a one-time password exchanged between the sending device 205 and the receiving device 210; and a cryptographic hash of sensitive data. In some examples, the parties may use one or more portions of the key diversification value to create multiple diversified keys. For example, a counter may be used as a key diversification value. In addition, a combination of one or more of the above exemplary key diversification values ​​may be used.

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

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

[0071] System 300 may include one or more contactless cards 305, as described below with respect to Figure 5A-5B Further explanation. In some examples, the contactless card 305 can communicate wirelessly with the client device 310, such as NFC communication. For example, the contactless card 305 may include one or more chips such as a radio frequency identification chip, which is configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 305 can communicate with the client device 310 in other ways, including but not limited to: Bluetooth, satellite, Wi-Fi, wired communication and / or any combination of wireless and wired connections. According to some embodiments, 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 may include client devices 310, which may be network-enabled computers. As referred to herein, network-enabled computers may include, but are not limited to, for example, computer devices, or communication devices, including, for example, servers, network appliances, personal computers, workstations, mobile devices, phones, handheld PCs, personal digital assistants, thin clients, fat clients, Internet browsers, or other devices. One or more client devices 310 may also be mobile devices. For example, a mobile device may include iPhone, iPod, iPad or other device running Apple Any other mobile device running Microsoft's Any device running Google's Mobile operating system Any device running a 320 operating system, and / or any other smartphone or similar wearable mobile device. In some examples, client device 310 may communicate with reference Figure 1A or Figure 1B The client devices 110 described are the same or similar.

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

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

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

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

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

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

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

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

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

[0082] Server 320 may include a network server in communication with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more 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 of key diversification according to an example of the present disclosure is shown. The method 400 may include Figure 2 A sending device and a receiving device similar to the sending device 205 and the receiving device 210 referred to in .

[0084] For example, a sender and a receiver may wish to exchange data (e.g., original sensitive data) via a sending device and a receiving device. As described above, although these two parties may be included, it 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 a sending device and a receiving device. In addition, it should be understood that any party or device holding the same secret symmetric key may perform the function of a sending device, and similarly, any party holding the same secret symmetric key may perform the function of a receiving device. In some examples, a symmetric key may include a shared secret symmetric key that is kept secret from all other parties except the sending device and the receiving device involved in exchanging 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, may be provided to the sending device and the receiving device. When the sending device is ready to process sensitive data using a symmetric cryptographic operation, the sender may update the counter. In addition, the sending device may select an appropriate symmetric cryptographic algorithm, which may include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm for processing the diversified value may include any symmetric cryptographic algorithm for generating a diversified symmetric key of a desired length as needed. Non-limiting examples of symmetric algorithms may include: a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm such as HMAC-SHA-256; and a symmetric CMAC algorithm such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may produce multiple outputs, which may be combined as needed to produce a sufficiently long key.

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

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

[0088] In some examples, the counter value may not be encrypted. In these examples, the counter value may 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 diversified keys may be used to protect sensitive data. A diversified session key that may be created by key diversification using a counter may be used with one or more cryptographic algorithms to protect sensitive data. For example, data may be processed by a MAC using a first diversified session key, and the resulting output may be encrypted using a second diversified session key that produces protected data.

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

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

[0092] The original data may be verified at block 460. If the output of a MAC operation (via the receiving device using the first diversified session key) matches the MAC output revealed by the decryption, then the data may be deemed 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 will produce a different diversified symmetric key. By processing the counter value with the master symmetric key and the same symmetric cryptographic algorithm, both the sending device and the receiving device can independently produce the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect 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. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker will never see any data processed using the master symmetric key. Only small counter values, not sensitive data, are processed using the master symmetric key. As a result, reduced side channel data about the master symmetric key is revealed. Moreover, the sender and the receiver can agree, for example, by previous arrangements or other means, how often to create new diversified values, and therefore new diversified symmetric keys. In one embodiment, a new diversified value, and therefore 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 may include a counter value. Other non-limiting examples of the key diversification value include: a random number generated each time a new diversified key is needed, the random number being sent from the sending device to the receiving device; the full value of the counter value sent from the sending device and the receiving device; a portion of the counter value sent from the sending device and the receiving device; a counter maintained independently 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 may use one or more portions of the key diversification value to create multiple diversified keys. For example, a counter may be used as a key diversification value.

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

[0097] In other examples, for example, to limit the number of uses of the master symmetric key, it may be agreed by the sender of the sending device and the receiver of the receiving device that new diversified values, and therefore new diversified symmetric keys, will only occur periodically. In one example, this may 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 may be after a certain period of time, after a specific period of time after a transmission, or periodically (e.g., every day at a specified time; every week at a specified time on a specified date). In another example, this may be every time the receiving device signals to the sending device that it wishes to change the key in the next communication. This may be controlled in policy and may 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 such as credit cards, debit cards, or gift cards issued by a service provider 505 displayed on the front or back of the card 500. 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 of plastic, metal, and other materials. Exemplary substrate materials include: polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 500 according to the present disclosure may have different characteristics, and the present disclosure does not require the implementation of the contactless card in the payment card.

[0099] The contactless card 500 may also include identification information 515 displayed on the front and / or back of the card, and a contact sheet 520. The contact sheet 520 may be configured to establish 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 processing circuits, an antenna, and other components. Figure 5A Components not shown in the figure. These components may be located behind the contact sheet 520 or at other locations on the substrate 510. The contactless card 500 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card ( Figure 5A not shown).

[0100] like Figure 5B As shown, Figure 5A The contact sheet 520 may include: processing circuitry 525 for storing and processing information, including a microprocessor 530 and a memory 535. It should be understood that the processing circuitry 525 may contain additional components, including processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware to perform the functions described herein as needed.

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

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

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

[0104] In some examples, the contactless card 500 may include one or more antennas 555. The one or more antennas 555 may be placed within the contactless card 500 and around the processing circuit 525 of the contact sheet 520. For example, the one or more antennas 555 may be integrally formed with the processing circuit 525, and the one or more antennas 555 may be used with an external booster coil. As another example, the one or more antennas 555 may be external to the contact sheet 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 use the gap in the power connection of the contactless card to infer the data sent from the terminal, which can be functionally maintained by one or more capacitors. The contactless card 500 can be backhauled by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal by interference.

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

[0107] Figure 6 An NDEF short record layout (SR=1) 600 is shown according to an example embodiment. One or more applets can be configured to encode the OTP as an 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 personalized parameters that can be used to generate NDEF messages. In one embodiment, the authentication template can include a first record with a well-known index for providing the actual dynamic authentication data.

[0108] Figure 7A message 710 and a message format 720 are shown according to an example embodiment. In one example, if additional tags are to be added, the first byte may be changed to indicate the start of a message instead of the end, and subsequent records may be added. Because the ID length is zero, the ID length field and the ID are omitted from the record. The message example may 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 the contactless card at personalization time by implementing STORE DATA (E2) under the secure channel protocol 2. One or more values ​​can be read from the EMBOSS file (in the section specified by the AppletID) by the personalization office, and one or more store data commands can be sent to the contactless card after authentication and secure channel establishment.

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

[0111]

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

[0113] One or more applets may be configured to maintain an applet version (2 bytes) which may be used in authentication messages. In some examples, this may be interpreted as most significant byte major version, least significant byte minor version. The rules for each version are configured to interpret the authentication message: For example, with respect to major versions, this may include: Each major version includes a specific authentication message layout and a specific algorithm. For minor versions, this may include: No changes to the authentication message or cryptographic algorithm, and changes to static tag content other than bug fixes, security enhancements, etc.

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

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

[0116] One or more counters may be configured to prevent replay attacks. For example, if a password has been obtained 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 some examples, the counter updated on the card is different from the counter updated for the transaction. In some examples, the contactless card may include a first applet and a second applet, and the first applet may be a transaction applet. Each applet may include a counter.

[0117] In some examples, the counter may be out of sync between the contactless card and one or more servers. For example, the contactless card may be activated to cause the counter to be updated and the contactless card to generate a new communication, but the communication may not be sent for processing at one or more servers. This may cause the counter of the contactless card to be out of sync with the counter maintained on one or more servers. For example, this may happen unintentionally, including: for example, when the card is stored adjacent to the device (for example, in a pocket with the device), and when the contactless card is read at a certain angle, it may include that the card is not aligned or positioned, so 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, resulting in the counter therein being updated, but no application on the device receives the communication.

[0118] In order to keep the counter synchronized, an application such as a background application can be executed, which will be configured to detect when the mobile device wakes up and synchronize with one or more servers to indicate that a read occurs due to detection and then move the counter forward. Since the counter of the contactless card and the one or more servers may not be synchronized, the one or more servers can be configured to allow the counter of the contactless card to be updated a threshold or predetermined number of times before it is read by the one or more servers and still be considered valid. For example, if the counter is configured to increment (or decrement) by one for each occurrence indicating the activation of the contactless card, the 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. Moreover, the 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 that the counter value has exceeded 10 but is below another threshold range value (e.g., 1000). Through the user's tap, if the counter value is within the expected or accepted range, the verification is successful.

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

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

[0121] At block 830, the MAC key may be used to prepare the MAC cipher, and the ENC key may be used to encrypt the cipher. For example, the MAC session key may be used to prepare the cipher, and the result may be encrypted with the ENC key before being sent to one or more servers.

[0122] At block 840, verification and processing of the MAC is 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 key is independently derived on one or more servers, resulting in a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

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

[0124] In some examples, since the EMV session key derivation method may wrap when used at 2^16, a counter (eg, a full 32-bit counter) may be added to the initialization array of the diversification method.

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

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

[0127] With respect to master key management, two issuer master keys 905, 910 may be required for each portion of a layout that issues one or more applets. For example, the first master key 905 may include an issuer password 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, the two issuer master keys 905, 910 are diversified into card master keys 925, 930, which are unique to each card. In some examples, a network profile record ID (pNPR) 915 and a derived key index (pDKI) 920 as background data may be used to identify which issuer master key 905, 910 is used for authentication during the encryption process. The system performing the authentication may be configured to retrieve the values ​​of the pNPR 915 and pDKI 920 of the contactless card at the time of authentication.

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

[0129] As described herein, the lower two bytes of the pATC 945 counter may be used to derive one or more MAC session keys. At each tap of a 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 session keys Aut-Session-Key 935 and DEK-Session-Key 940. The pATC 945 may be initialized to zero at personalization or at applet initialization time. In some examples, the pATC counter 945 may be initialized at or prior to personalization and may be configured to increase by 1 at each NDEF read.

[0130] Additionally, updates for each card may be unique and may be assigned either by personalization or algorithmically via a PETID or other identifying information. For example, odd-numbered cards may be incremented or decremented by 2, while even-numbered cards may be incremented or decremented by 5. In some examples, updates may also vary in sequential reads, such that a card may be incremented in a repeating sequence of 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence may be defined at personalization, or based on one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

[0131] The authentication message can be delivered as the content of a text NDEF recorded in hexadecimal ASCII format. In some examples, only an 8-byte random number may be included after the authentication data and the MAC of the authentication data. In some examples, the random number may precede the password A and may be one block long. 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) may be a multiple of the block size. In these examples, additional 8-byte blocks may be added to match the blocks generated by the MAC algorithm. As another example, if the algorithm used uses 16-byte blocks, even multiples of that block size may be used, or the output may be automatically or manually padded to a multiple of that block size.

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

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

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

[0135]

[0136]

[0137]

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

[0139]

[0140]

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

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

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

[0144] By including an application transaction counter (pATC) as part of the data contained in the MAC password, the authentication service can be configured to determine whether the value conveyed in the clear data has been tampered with. In addition, by including the version in one or more passwords, it is difficult for an attacker to intentionally tamper with the application version in a way that attempts to reduce the strength of the password solution. In some examples, pATC can start from zero and be updated by 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC that is equal to or less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated can be rejected. In some examples, if 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 exceeds the range or threshold or is outside it, the verification can be considered to have failed or is unreliable. In MAC operation 936, the data 950 is processed by MAC using Aut-Session-Key 935 to produce an encrypted MAC output (password A) 955.

[0145] 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 password A 955 to be included in the ciphertext may include: random number (8), password (8). In some examples, the number in brackets may include a length in bytes. In some examples, the random number may be generated by one or more random number generators, which may be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include a DEK-Session-Key 940. In an encryption operation 941, the data or password A 955 and RND are processed using the DEK-Session-Key 940 to generate encrypted data, password B 960. The data 955 may be encrypted using 3DES in a cipher block chaining mode to ensure that an attacker must perform any attack on all ciphertexts. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' may 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 was used because correctly decrypted data will be indistinguishable from incorrectly decrypted data regions due to its random appearance.

[0146] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be delivered in the clear from the one or more applets to the mobile device during the authentication session: a 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; a pUID, which is used to retrieve the password asset and derive the card key; and a pATC, which is used to derive the session key for the password.

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

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

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

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

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

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

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

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

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

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

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

[0158] At block 1170, the session key derived from the data encryption is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing of the exchanged data will then occur. In some examples, after the MAC is extracted, it is desirable to reproduce and match the MAC. For example, when verifying a password, it can be decrypted using a properly generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

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

[0160] Some examples of the methods described herein can advantageously confirm when a successful authentication is determined when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is correct. The MAC is correct only when 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., a sending device) and the receiver (e.g., a receiving device), it can be believed that the contactless card that originally created the MAC and encrypted the MAC is indeed credible. Moreover, the counter value used to derive the first session key and the second session key can be shown as valid and can be used to perform the authentication operation.

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

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

[0163] In some examples, the contactless card can be tapped against a device such as one or more computer kiosks or terminals to verify identity in order to receive a transaction item in response to a purchase (such as coffee). By using a contactless card, a secure method of proving identity in a loyalty program can be established. Establishing a secure way to prove identity in order to, for example, obtain rewards, coupons, offers, etc., or the receipt of benefits in a different way than just scanning a bar card. For example, an encrypted transaction may occur between a contactless card and a device, which can be configured to process one or more tap gestures. As described above, one or more applications can be configured to verify the identity of the user, and then, for example, via one or more tap gestures, the user can act or respond to it. In some examples, data such as consumer points, loyalty points, reward points, health care information, etc. can be written back to the contactless card.

[0164] 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, which will then grant the user desired benefits based on the verification of the identity.

[0165] 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. Wherein the communication of tapping the card 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 purchasing, accessing accounts or restricted information or other functions. In some examples, tapping can activate or start the application of the device, and then initiate one or more actions or communications with one or more servers to activate the contactless card. If the application is not installed on the device, tapping the contactless card 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 start the application, and then initiate the activation of the contactless card, such as via the application or other back-end communications. After activation, the contactless card can be used for various activities, including but not limited to commercial transactions.

[0166] In some embodiments, a dedicated application may be configured to execute on a client device to perform activation of a contactless card. In other embodiments, a web portal, a web-based application, a small application, etc. may perform activation. Activation may be performed on the client device, or the client device may simply act as a channel between a contactless card and an external device (e.g., an account server). According to some embodiments, when providing activation, the application may indicate to the account server the type of device performing the activation (e.g., a personal computer, a smart phone, a tablet, or a point of sale (POS) device). In addition, 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 a merchant type, a merchant ID, and information associated with the device type itself such as POS data and POS ID.

[0167] In some embodiments, the example authentication communication protocol can 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 can be based on whether the card issuer recognizes the transaction value. At the same time, in certain embodiments of the present disclosure, transactions originating from mobile devices lack a transaction value associated with the POS system. Therefore, in some embodiments, a virtual transaction value (i.e., a value that is recognizable by the card issuer and sufficient to allow activation to occur) can be passed as part of the example authentication communication protocol. POS-based transactions can also reject transactions based on the number of transaction attempts (e.g., a transaction counter). The number of attempts exceeding a buffer value may result in a soft decline; the soft decline requires further verification before accepting the transaction. In some implementations, the buffer value of the transaction counter can be modified to avoid rejecting legitimate transactions.

[0168] In some examples, contactless cards can selectively transmit information based on the recipient device. Once tapped, the contactless card can identify the device that the tap is directed to, and based on that identification, the contactless card can provide the appropriate data for that device. Advantageously, this allows the contactless card to send only the information necessary to complete an immediate action or transaction, such as a payment or card authentication. By limiting 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 can be applied in a variety of situations, including card activation, balance transfers, account access attempts, commercial transactions, and fraud reduction.

[0169] If the tap of the contactless card is directed to a computer running Apple If you have a device running the operating system (such as an iPhone, iPod or iPad), the contactless card can be recognized The operating system sends the appropriate data to communicate with this device. For example, a 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 the operating system Operating system devices (such as smartphone or tablet), the contactless card can be recognized The system operates and sends appropriate data to communicate with the device (such as encrypted identity information required for authentication via the methods described herein).

[0170] As another example, the tap of a contactless card may be directed to a POS device, including but not limited to a kiosk, checkout counter, payment station, or other terminal. When performing the tap, the contactless card may identify the POS device and transmit only the information necessary for the action or transaction. For example, upon identifying the POS device used to complete a commercial transaction, the contactless card may transmit the payment information necessary to complete the transaction under the EMV standard.

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

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

[0173] In some examples, such as shopping malls, grocery stores, convenience stores, etc., a contactless card can be tapped against a mobile device without having to open an app to indicate a desire or intent to utilize one or more of reward points, loyalty points, coupons, offers, etc. to cover one or more purchases, thereby providing the intent behind the purchase.

[0174] In some examples, one or more applications may be configured to determine that it was initiated via one or more tap gestures of a contactless card such that the initiation occurred at 3:51 PM and the transaction was processed or occurred at 3:56 PM to verify the user's identity.

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

[0176] In some examples, data about the tapping behavior can be collected as a 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 the 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.

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

[0178] 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 case, a first friend (payer) owes a second friend (payee) a sum of money. The payer wants to pay using a contactless card through the payee's smartphone (or other device) instead of going to an ATM or requesting an exchange through a peer-to-peer application. The payee logs into the appropriate application on his smartphone and 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 the payee to tap his contactless card. Once the payee taps his contactless card on the screen of his smartphone where the application is enabled, the contactless card is read and verified. Next, the application displays a prompt for the payee to tap his contactless card for payment. After the payee taps his contactless card, the application reads the card information and sends the payment request to the payee's card issuer through an associated processor. The card issuer processes the transaction and sends a status indicator of the transaction to the smartphone. Then, the application outputs a status indicator to display the transaction.

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

[0180] Fig.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, the device, and the one or more servers may refer to the above Figure 1A , Figure 1B , Figure 5A and Figure 5B The same or similar components explained previously, such as contactless card 105 , client device 110 , and server 120 .

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

[0182] In box 1220, one or more portions of the dynamically generated data may be transmitted to an application of the device via NFC or other wireless communication. For example, a tap of the card close to the device may allow an application of the device to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application for assisting in the activation of the card, the tap of the card may 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 may be prompted to fully gesture, place, or orient the card toward the surface of the device, such as placing it at an angle or flat on the surface of the device, near it, or close to it. In response to the full gesture, placement, and / or orientation of the card, the device may continue to send one or more encrypted portions of the data received from the card to one or more servers.

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

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

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

[0186] In another example scenario, a customer wants to access 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), he must have a second-level authentication. Therefore, the application requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps his or her credit card against the mobile device, and the application verifies whether the credit card corresponds to the user's account. Thereafter, the user can view second-level account data and / or perform second-level account functions.

[0187] The systems and methods described herein provide a contactless card that can be moved toward a mobile device to initiate an email and activate the contactless card without utilizing an application. As a result, these techniques provide a variety of benefits, including a more efficient way to activate the card, greater security for consumers and issuers, and eliminating the need for users to use an application.

[0188] Fig.13 A card activation system 1300 is shown, which includes a contactless card 1305, a client device 1310, and one or more servers 1320. Fig.13 A single instance of a component is shown, but the system 1300 may include any number of components. The contactless card 1305, the client device 1310 and one or more client applications 1316 and one or more servers 1320 may refer to the previously referenced Figure 1A , Figure 1B , Figure 5A and Figure 5B The same or similar components as described above, such as contactless card 105, client device 110, and server 120.

[0189] The contactless card 1305 may include one or more processors 1307 and a memory 1309. The memory 1309 may include one or more applets 1311. In some examples, when the contactless card 1305 is gestured, including but not limited to one or more gestures, so that the contactless card 1305 can enter a communication field, such as an NFC field, of the client device 1310 to establish communication therewith, such as NFC communication, the one or more applets 1311 of the contactless card may generate an NDEF file that can be read by the client device 1310 and / or the client device application 1316. The client device 1310 may include one or more processors 1312 and a memory 1314, and may contain one or more client applications 1316, which include instructions for execution on the client device. The one or more client applications 1316 may be software applications configured to perform the client device functions described herein. The client device 1310 and / or the one or more client applications 1316 may communicate data with the contactless card 1305 via a communication interface (not shown). In some examples, the one or more gestures may include at least a tap, swipe, or other gesture of the contactless card 1305 so that the contactless card 1305 enters the communication field of the client device 1310. For example, the contactless card 1305 may be tapped to a client device 1310, such as a mobile device, to initiate an email.

[0190] The NDEF file may initiate one or more communications with one or more client applications 1316 on the client device 1310. As described below, one or more applets 1311 of the contactless card 1305 may dynamically generate information, such as a link configured to generate an email using a default email program of the client device 1310. In some examples, one or more processes may be utilized to activate the contactless card 1305. Exemplary processes include, but are not limited to, generating and sending emails, short message service (SMS) messages, and multimedia message service (MMS) messages.

[0191] For example, a link may be generated that is configured to initiate an email on the client device 1310. This may be accomplished using the default email program of the client device 1310, or in other examples, a different or designated email program may be used. For example, a uniform resource locator (URL) may be dynamically generated so that a corresponding "subject" line of the email may include a card verification value or token, including, but not limited to, a one-time password token. For example, this may be illustrated by the following exemplary link:

[0192] mailto:card_activation@capitalone.com? subject=l234567

[0193] For example, a default email program may be launched, or an application download store may be presented to prompt the user to download and install an email program on the client device 1310. In other examples, rather than routing the user to an application download store, an activation link or URL may be presented to the user to activate the contactless card 1305, such that the payload includes the URL. Thus, the notification or indication that the contactless card 1305 has been activated may include sending a text message or email from the one or more servers 1320 to the client device 1310.

[0194] In some examples, the link may include one or more information elements. In some examples, the link may include a first information element, a second information element, and a third information element. For example, the first information element may precede the second information element, and the second information element may precede the third information element.

[0195] In one embodiment, the first information element may include an email address, such as card_activation@capitalone.com. In other examples, the email address may include any other email address, including but not limited to an email address associated with contactless card activation. In some examples, one or more emails may be dynamically generated, or one or more emails may be retrieved from a preconfigured list. In some examples, a list of email addresses is received from the contactless card 1305. The email address may be selected from the list based on the purpose of the authentication, including but not limited to user status, account status, card expiration date, card activation date, transaction information, account information, and card replacement issuance.

[0196] In one embodiment, the second information element may include the "subject" line of the email as part of the mailto link. Additionally and / or alternatively, other fields or lines of the email may be included as part of the link, including but not limited to the "CC" or "BCC" fields or any combination thereof.

[0197] In one embodiment, the third information element may include one or more payloads. For example, the transmitted payload (e.g., 1234567) may be configured to authenticate the contactless card. In some examples, the string of digits may be delivered to the client device and / or one or more client applications in an encrypted format and may be decrypted with a key. If the decryption process fails, for example, due to an unintentional or typographical error or input error or other reasons, this process may trigger one or more fallback options. For example, one option may include: routing the call to an operator or customer service representative who can handle the call. In another example, another option may include: the process may be routed to another system to enter the card verification value of the contactless card 1305, as discussed above.

[0198] In some examples, if an incorrect email address or link is used during the activation of the contactless card 1305, this event can be marked and stored in the database for analysis of potential suspicious objects. As a result, an unregistered or unverifiable email may indicate a higher probability of fraudulent activity. In other examples, this event can be marked and stored in the database for analysis of errors or inputs related to incorrect email addresses or links. In some examples, one or more servers 1320 can be configured to verify the "sender" field or line of the email as part of determining and activating the contactless card 1305.

[0199] In some examples, a value such as a card verification value (CVV) of the contactless card 1305 can be configured to activate the contactless card 1305. In other examples, higher security than the CVV method can be provided, including: utilizing a one-time password (OTP) generated by one or more card applets 1311, which can be encrypted and decrypted by one or more servers 1320 to authenticate the contactless card 1305.

[0200] In some examples, one or more client applications 1316 of the client device 1310 can parse the payload from the email link and transmit it through one or more network applications for decryption. In some examples, the token can be encrypted via a private key / public key. For example, a private key can be used to decrypt data and can also be stored securely so that encryption (via a public key) can be performed without a private key, which means that the private key does not need to be transmitted and is therefore not easily intercepted by a third party. One or more servers 1320 can check and verify the link used to initiate the email in order to determine the reliability of the email. Therefore, the encrypted data can be decrypted, and the notification or indication that the contactless card 1305 has been activated can include sending a text message or email from one or more servers 1320 to one or more client applications 1316 of the client device 1310.

[0201] In some examples, after the contactless card 1305 has been successfully activated and one or more client applications 1316 of the client device 1310 have received a notification indicating activation, the contactless card 1305 can be instructed to disable the dynamic generation of data. In some examples, as described above, after the contactless card 1305 has been activated, the user of the contactless card 1305 can be optionally directed to customer support, or the contactless card 1305 can be used at a POS device or any other system. For example, if the user interacts with the POS device using an activated card, the contactless card 1305 can be instructed to stop dynamically generating emails. In some examples, this may require communication between small applications such as payment small applications or transaction small applications to indicate to one or more other small applications 1311 of the contactless card 1305 that the generation of emails should be stopped at the next occurrence of one or more gestures of the contactless card 1305. In this way, the dynamic generation feature of the contactless card 1305 can be turned off or disabled in response to the successful activation of the contactless card 1305.

[0202] Fig.14 A method 1400 for card activation according to an example embodiment is shown. The method 1400 may refer to the method described above with respect to Fig.13 The same or similar components as described herein.

[0203] At block 1410, when a contactless card is gestured (including, but not limited to, one or more gestures) to a client device to establish communication with the contactless card by bringing the contactless card into the communication field of the client device, one or more applets of the contactless card may generate an NDEF file that may be read by the client device and / or client application. In some examples, the one or more gestures may include at least a tap, a wave, or other gesture as a contactless card. For example, a contactless card may be tapped to a client device such as a mobile device to initiate an email.

[0204] The NDEF file may initiate one or more communications with different applications on the client device. As described below, one or more applets of the contactless card may dynamically generate information, such as being configured to generate a link to an email using the default email program of the client device.

[0205] At block 1420, one or more processes may be utilized to activate the contactless card. Exemplary processes include, but are not limited to, generating and sending an email, a short message service (SMS) message, and a multimedia message service (MMS) message.

[0206] For example, a link may be generated that is configured to initiate an email on a client device. In other examples, a different or designated email program than the default email program of the client device may be used. For example, a uniform resource locator (URL) may be dynamically generated so that a corresponding "subject" line of the email may include a card verification value or token, including but not limited to a one-time password token. For example, this may include the following exemplary link:

[0207] mailto:card_activation@capitalone.com? subject=l234567

[0208] For example, a default email program may be launched, or an application download store may be provided to prompt the user to download and install the email program on the client device. In other examples, rather than routing the user to an application download store, an activation link or URL may be presented to the user to activate the contactless card such that the payload includes the URL. Thus, notification or indication that the contactless card has been activated may include sending a text message or email from one or more servers to the client device.

[0209] In some examples, the link may include one or more information elements. In some examples, the link may include a first information element, a second information element, and a third information element. For example, the first information element may precede the second information element, and the second information element may precede the third information element. In these examples, the link may include a first information element. The first information element may include an email address, such as card_activation@capitalone.com. In other examples, the email address may include any other email address, including, but not limited to, an email address associated with contactless card activation. In some examples, one or more emails may be dynamically generated, or one or more emails may be retrieved from a preconfigured list. The email address may be selected from the list based on the purpose of the authentication, including, but not limited to, user status, account status, card expiration date, card activation date, transaction information, account information, and card replacement issuance.

[0210] The link may include a second information element. The second information element may include the "subject" line of the email as part of the mailto link. Additionally and / or alternatively, other fields or lines of the email may be included as part of the link, including but not limited to a "CC" or "BCC" field or any combination thereof.

[0211] The link may include a third information element, which may include one or more payloads. For example, the transmitted payload (e.g., 1234567) may be configured to authenticate the contactless card. In some examples, the digital string may be delivered to the client device in an encrypted format and may be decrypted with a key. If the decryption process fails, for example due to an unintentional or typographical error or input error or other reasons, this process may trigger one or more fallback options. For example, one option may include routing the call to an operator or customer service representative who can handle the call. In another example, another option may include that the process may be routed to another system to enter a card verification value for a contactless card, as discussed below.

[0212] In some examples, a value such as the CVV of a contactless card can be configured to activate the contactless card. In other examples, higher security than the CVV method can be provided, including a one-time password (OTP) generated by one or more card applets that can be encrypted and decrypted by one or more servers to authenticate the contactless card.

[0213] At box 1430, the client device and / or one or more client applications can parse the payload from the email link and pass it via one or more network applications for decryption. In some examples, the token can be encrypted via a private key / public key. For example, a private key can be used to decrypt data and can also be stored securely so that encryption (via a public key) can be performed without a private key, which means that the private key does not need to be transmitted and is therefore not easily intercepted by a third party. One or more servers can check and verify the link used to initiate the email in order to determine the authenticity of the email. Thus, the encrypted data can be decrypted, and a notification or indication that the contactless card has been activated can include sending a text message or email from one or more servers to the client device.

[0214] At box 1440, after the contactless card has been successfully activated and the client device has received a notification indicating activation, the contactless card can be instructed to disable the dynamic generation of data. In some examples, as described above, after the contactless card has been activated, the user of the contactless card can be optionally directed to customer support, or the contactless card can be used at a POS device or any other system. For example, if the user interacts with the POS device using an activated card, the contactless card can be instructed to stop dynamically generating emails. In some examples, this may require communication between small applications such as payment small applications or transaction small applications to indicate to one or more other small applications of the contactless card that the generation of emails will stop when the next occurrence of one or more gestures of the contactless card occurs. In this way, the dynamic generation feature of the contactless card can be closed or disabled in response to successfully activating the contactless card.

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

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

[0217] 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 cases, well-known methods, structures, and techniques are not shown in detail to avoid confusing the understanding of this specification. References to "some examples", "other examples", "one example", "example", "various examples", "one embodiment", "embodiment", "some embodiments", "example embodiments", "various embodiments", "one implementation", "implementation", "exemplary implementation", "various implementations", "some implementations", etc. indicate that the embodiments of the disclosed technology described may include specific features, structures, or characteristics, but not every implementation must include specific features, structures, or characteristics. In addition, although the phrases "in one example", "in one embodiment", or "in one implementation" may be used repeatedly, they do not necessarily refer to the same examples, embodiments, or implementations.

[0218] As used herein, unless otherwise indicated, the use of ordinal adjectives "first," "second," "third," etc., to describe common objects simply indicates that different instances of similar objects are referenced and is not intended to imply that the objects so described are necessarily in a given order in time, space, rank, or in any other manner.

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

[0220] 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 method included. The patentable scope of certain implementations of the disclosed technology is defined in the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements that do not differ substantially from the literal language of the claims.

Claims

1. A contactless card, comprising: processor, and a memory containing the applet and activation information, wherein the activation information comprises a link configured to activate the contactless card via an email program executed on a client device, the link comprising an email address and an encrypted payload, and wherein the applet is configured to, upon entering the communication field of the client device: send the activation information to the client device for transmission to a server for verification of the encrypted payload, Wherein the contactless card is configured to disable dynamic generation of data after activation of the contactless card.

2. The contactless card according to claim 1, wherein: Once verification of the encrypted payload and email address is performed, the contactless card is activated by the server.

3. The contactless card according to claim 1, wherein: The server associated with activation of the contactless card is identified by the email address.

4. The contactless card according to claim 1, wherein: The link includes a uniform resource locator for launching an email on the client device.

5. The contactless card according to claim 1, wherein: The encrypted payload included in the activation information includes a card verification value associated with the contactless card.

6. The contactless card according to claim 1, wherein: The encrypted payload includes a one-time password.

7. The contactless card according to claim 1, wherein: The contactless card is configured to disable the dynamic generation of data after an additional entry into the communication field.

8. A method for activating a contactless card, the method comprising the following steps: storing activation information in a memory of the contactless card, wherein the activation information comprises a link configured to activate the contactless card via an email program executed on a client device, the link comprising an email address and an encrypted payload; Once the contactless card enters the communication field of the client device, sending the activation information to the client device for transmission to a server for verification; and Upon activation of the contactless card, dynamic generation of data is disabled.

9. The method according to claim 8, wherein: The encrypted payload includes a limited-use token.

10. The method according to claim 8, wherein: Once verification of the encrypted payload and email address is performed, the contactless card is activated by the server.

11. The method according to claim 8, wherein: The link includes a uniform resource locator.

12. The method according to claim 8, wherein: The encrypted payload includes a card verification value configured to be associated with the contactless card.

13. The method according to claim 8, wherein: The encrypted payload includes a one-time password.

14. The method according to claim 8, wherein: The sending and disabling of the dynamic generation of said data is performed by an applet stored in the memory of said contactless card.

15. A server, comprising: processor; and Memory, The memory is configured as follows: receiving an email message from a client device, the email message comprising an encrypted payload and an email data field, wherein the email message is sent to the server in response to an activation link from a contactless card, verifying the encrypted payload, Activate the contactless card, and A notification is sent to the client device regarding activation of the contactless card.

16. The server according to claim 15, wherein: The processor is further configured to activate the contactless card upon verification of the encrypted payload.

17. The server according to claim 15, wherein: The encrypted payload includes an encrypted one-time password token, and The processor is also configured to activate the contactless card by decrypting and verifying the encrypted one-time password token.

18. The server according to claim 15, wherein: The server is configured to verify the "from" field of the email message as part of determining and activating the contactless card.

19. The server according to claim 15, wherein: The dynamic generation of data is disabled after activation of the contactless card, wherein the disabling of the dynamic generation of data comprises disabling the dynamic generation of data by the applet after the contactless card additionally enters the communication field of the client device.

20. The server of claim 15, wherein the processor is further configured to decrypt the encrypted payload using one or more keys prior to authenticating the encrypted payload.

Images