System and method for password authentication of contactless cards

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. One or more applets of the contactless card are configured to dynamically generate an encrypted payload attached to a link, wherein the contactless card is configured to transmit the link with the attached payload to the client device via one or more gestures. The one or more servers are configured to receive the payload from the client device via the one or more applications, parse and decrypt the payload after launching the one or more applications, and transmit one or more notifications to the client device based on a status associated with the decryption of the payload. Based on the one or more notifications received from the one or more servers, the client device is authorized to access multiple services associated with the one or more servers.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a continuation-in-part of U.S. patent application No. 16 / 205,119 filed on November 29, 2018, and claims priority to U.S. Provisional Application No. 62 / 740,352 filed on October 2, 2018 and U.S. Patent Application No. 16 / 589,352 filed on October 1, 2019, the disclosures of which are incorporated herein by reference in their entirety. 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. As electronic transactions constitute an increasing share of commercial activity, this need continues to grow.

[0005] Emails could potentially be used as a tool to verify transactions, but emails are vulnerable and can be easily compromised by hackers or other unauthorized access. Short message service (SMS) messages could also be used, but this can also be 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. Further, while the increasing use of chip-based financial cards provides a more secure feature 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 drawbacks exist. Therefore, there is a need to provide users with appropriate solutions that overcome these drawbacks to provide data security, authentication and verification for contactless cards. Further, there is a need for improved methods of activating cards and 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 an encrypted payload system, comprising: a contactless card including a processor and a memory, wherein the memory includes a plurality of applets, wherein one or more applets are configured to dynamically generate an encrypted payload attached to a link; a client application including instructions for execution on a client device including the processor and the memory; and one or more servers communicating with the client application; wherein the contactless card is configured to send a link with an attached payload to the client application via one or more gestures, wherein the one or more gestures include one or more taps, swipes, swipes, or any combination thereof, wherein the link is configured to launch the client application; wherein the one or more servers are configured to receive the payload from the client application; wherein the one or more servers are configured to parse and decrypt the payload after launching the client application; wherein the one or more servers are configured to transmit one or more notifications to the client application based on a state associated with the decryption of the payload; wherein the client application is authorized to access a plurality of services associated with the one or more servers based on the one or more notifications received from the one or more servers.

[0010] An embodiment of the present disclosure provides a method for authorizing access, comprising: dynamically generating a payload attached to a string through a contactless card, the payload being encrypted by the contactless card; establishing communication between a client application and the contactless card, the client application comprising instructions for executing on a client device via one or more gestures, the one or more gestures comprising one or more taps, slides, swipes or any combination thereof, wherein the string is configured to launch the client application; the contactless card transmits the string and the attached payload to the client application via the one or more gestures; receiving the payload from the client application at one or more servers; after launching the client application, decrypting the payload by the one or more servers; transmitting one or more messages to the client application by the one or more servers based on a state associated with the decryption of the payload; and authorizing access to multiple resources associated with the one or more servers at the client application based on the one or more messages received from the one or more servers.

[0011] An embodiment of the present disclosure provides a contactless card, comprising: one or more processors and a memory, wherein the memory comprises one or more applets, wherein the one or more applets are configured to dynamically generate an encrypted payload attached to a link, wherein the encrypted payload is configured to verify identity in order to personalize the link; wherein the contactless card is configured to transmit the link with the attached payload to a client application, the client application comprising instructions for execution on a client device via one or more gestures, the one or more gestures comprising one or more taps, swipes, swipes or any combination thereof, wherein the link is configured to launch the client application based on one or more notifications to decrypt the encrypted payload in order to authorize access to multiple services, and wherein at least one of the one or more gestures triggers an activation process for the contactless card.

[0012] Other features of the disclosed design and 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 contact pads of a contactless card according to an example embodiment.

[0020] Figure 6 is a diagram depicting messages for communicating 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 flow chart illustrating key operations according to an example 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 an encrypted payload system in accordance with an example embodiment.

[0028] Fig.14 is a flow chart illustrating a method for authorizing access 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 have reviewed 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 promote 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 (such as a mobile phone) and the card itself. For example, the EMV protocol (which is the basis for many credit card transactions) includes an authentication process that is sufficient to meet the requirements of the present disclosure. operating system, but for The challenge Near field communication (NFC) is more restricted in use because it can only be used in a read-only manner. Example embodiments of contactless cards described herein utilize NFC technology.

[0031] Figure 1A1 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-Figure 5B Further explanation: In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110 using NFC in the 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 web application, 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 running Apple Any other mobile device running Microsoft 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 necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives, and anti-tampering hardware. 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 the user's device that is available and supported by the user device, such as a touch screen, a keyboard, a mouse, a cursor control device, a touch screen, a microphone, a digital camera, a video recorder, or a portable camera. These devices can be used to input information and interact with software and other devices described herein.

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

[0036] The client device 110 can communicate with one or more servers 120 via one or more networks 115, and can operate with the server 120 as a respective front-end to back-end pair. The client device 110 can transmit 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 can be associated with retrieving data from the server 120. The server 120 can receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 can be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 120 can be configured to transmit the received data to the client device 110, the received data being 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 time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and / or 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, or 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, which operate as independent networks or collaborate with each other. The network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 115 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 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 such as a credit card association network, and a home network.

[0039] System 100 may include one or more servers 120. In some examples, server 120 may include one or more processors coupled to a memory. Server 120 may be configured as a central system, server, or platform for controlling and calling 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 Can be cited as Figure 1A Similar components as shown.

[0041] At step 102, application 122 (e.g., after being brought into proximity with contactless card 105) communicates with contactless card 105. Communication between application 122 and contactless card 105 may involve 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 has been 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 transmit a message such as an applet ID of an NDEF generating applet, such as an applet selection message. After confirming the selection, a sequence of select file messages may be transmitted, followed by a read file message. For example, the sequence may include "select capability file", "read capability file", and "select NDEF file". At this time, a counter value maintained by the contactless card 105 may be updated or incremented, followed by "read NDEF file". At this time, 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 based on 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 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 transmitted as an NDEF tag, and in other examples, the MAC password may be included with a uniform resource indicator (eg, as a formatted string).

[0044] In some examples, application 122 may be configured to transmit a request to contactless card 105 that includes instructions for generating a MAC password.

[0045] At step 106, the contactless card 105 sends the MAC password to the application 122. In some examples, the transmission of the MAC password occurs via NFC, however, the present disclosure is not limited thereto. In other examples, such communication can be performed 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 verification MAC password may be performed by a device other than the client device 110 (such as a server 120 (eg, 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, which 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 such verification.

[0050] Figure 2 2 shows a data transmission system according to an example embodiment. The system 200 may include a sending device 205, a receiving device 210, and a receiving device 210 that communicate with one or more servers 220 via a network 215. The sending device 205 may be similar to the one described above. Figure 1A The receiving device 210 may be the same as or similar to the client device 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 cipher algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms), it is important that the keys remain secret between the party that initially processes the protected data using the symmetric algorithm and key and the party that receives and processes the data using the same cryptographic algorithm and the same key.

[0052] It is also important that the same key is not used too many times. If 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 was processed by the encryption algorithm using the same key. The more data an attacker has that was processed with the same key, the greater the chance that the attacker can discover the key's value. Frequently used keys can be included in a variety of different attacks.

[0053] Furthermore, 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 a cryptographic algorithm is executed while using the key. Side-channel data may be adequately measured to reveal enough information about the key to allow it to be recovered by an attacker. Exchanging data using the same key repeatedly reveals data processed with 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, and exposure to this and other types of attacks is thereby reduced. As further described herein, the parties participating in the cryptographic information exchange (e.g., a sender and a receiver) can independently generate keys based on an initial shared master symmetric key in conjunction with a counter value, and thereby periodically replace the shared symmetric keys in use, without relying on any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and the receiver, the attacks described above become impossible.

[0055] Return reference 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 explained above, although a single instance of a sending device 205 and a receiving device 210 may be included, it should be understood that one or more sending devices 205 and one or more receiving devices 210 may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending device 205 and the receiving device 210 may be provided with the same master symmetric key. Further, it should be understood that any party or device holding the same secret symmetric key can perform the function of the sending device 205, and similarly, any party holding the same secret symmetric key can perform the function of the receiving device 210. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret to all parties except the sending device 205 and the receiving device 210 that participate 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 it should also be understood that a portion of the data exchanged between the sending device 205 and the receiving device 210 includes at least a portion of data that can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the sending device 205 and the receiving device 210.

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

[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 the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. The network 215 may also include a network operating as an independent network, or any number of networks of the exemplary types mentioned above operating in cooperation 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 such as a credit card association 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 with each other and transmit and receive data without going through the network 215. For example, 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, and / or the like.

[0059] At block 225, when the sending device 205 is ready to process sensitive data with a symmetric cryptographic operation, the sender may update the counter. In addition, the sending device 205 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 desired length diversified symmetric key as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms, such as 3DES or AES128; symmetric HMAC algorithms, such as the HMAC-SHA-256 algorithm; 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 can 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 use the master symmetric key to process the counter value. For example, the sender may select a symmetric encryption algorithm and use a counter that is updated with each conversation between the sending device 205 and the receiving device 210. The sending device 205 may then encrypt the counter value using the selected symmetric encryption algorithm and the master symmetric key to create a diversified symmetric key.

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

[0062] At block 235, the diversified symmetric key may be used to process the sensitive data before transmitting the result 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 transmit the protected encrypted data along with the counter value to the receiving device 210 for processing.

[0063] At block 240, the receiving device 210 may first obtain the counter value and then perform the same symmetric encryption using the counter value as an input to the encryption and the master symmetric key as the key for encryption. The output of the encryption may be the same as the 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, a different counter value can be selected to generate a different diversified symmetric key. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 can independently generate the same diversified symmetric key. This diversified symmetric key (rather than the master symmetric key) is used to protect sensitive data.

[0067] As explained above, both the sending device 205 and the receiving device 210 initially each possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Because the diversified symmetric key is independently created by both the sending device 205 and the receiving device 210, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker will never see any data processed using the master symmetric key. Only the counter value is processed using the master symmetric key, and the sensitive data is not processed using the master symmetric key. Therefore, the side channel data disclosed about the master symmetric key is reduced. Moreover, the operation of the sending device 205 and the receiving device 210 can be governed by the symmetric requirements of how often a new diversified value is created and thus a new diversified symmetric key is created. In an 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: generating a random nonce that is sent from the sending device 205 to the receiving device 210 each time a new diversified key is needed; sending the full value of the counter value from the sending device 205 and the receiving device 210; sending a portion of the counter value from the sending device 205 and the receiving device 210; the counter is maintained independently by the sending device 205 and the receiving device 210, but is 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, one or more portions of the key diversification value may be used by each party to create multiple diversified keys. For example, a counter may be used as a key diversification value. Further, 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. A new diversification value, and therefore a new diversified symmetric key, can be created whenever needed. In the most secure case, a new diversification value can be created for each exchange of sensitive data between the sending device 205 and the receiving device 210. In practice, this may create a one-time use key, such as a single-use 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 3 A 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 FIG. 5A to FIG. 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 configured to communicate via NFC or other short-range protocols, such as a radio frequency identification chip. 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 described 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 a computer from iPhone, iPod, iPad or running Apple Any other mobile device running Microsoft Any device running Google's Mobile operating system Any device running a Windows 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 the one or more servers 320 and 325 via one or more networks 315. The client device 310 can transmit 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 transmit 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 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] System 300 may include one or more networks 315. In some examples, network 315 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect client device 315 to servers 320 and 325. For example, network 315 may include one or more of a fiber optic network, a passive optical network, a cable network, a cellular network, the Internet, a satellite network, a wireless LAN, global mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and / or any combination of networks thereof. As a non-limiting example, 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, 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, network 315 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. Network 315 may further include a network, or any number of networks of the above exemplary types, which operate as independent networks or collaborate with each other. Network 315 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 315 may 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 network 315 is depicted as a single network, it should be understood that, according to one or more examples, network 315 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

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

[0078] An application 311 of any of the client devices 310 may communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). The application 311 may be configured to interface with a card reader 313 of the client device 310 configured to communicate with the 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, the contactless card 305 can communicate with the application 311 through NFC, through the card reader 313 of the client device 310. Communication (e.g., the card is tapped close to the card reader 313 of the client device 310) allows the application 311 to read the data associated with the card and perform activation. In some cases, the tap can activate or start the application 311, and then initiate one or more actions or communications with the account server 325 to activate the card for subsequent use. In some cases, if the application 311 is not installed on the client device 310, the tapping of the card against the card reader 313 can initiate the download of the application 311 (e.g., navigating to the application download page). After installation, tapping the card can activate or start the application 311, and then initiate the activation of the card (e.g., via the application or other backend communication). After activation, the card can be used for various transactions, including commercial transactions.

[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 web server in communication with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more credentials from contactless card 305 and / or client device 310 by comparing with one or more credentials in database 335. Server 325 may be configured to authorize one or more requests from contactless card 305 and / or client device 310, such as 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 a method similar to Figure 2 The sending device and receiving device of the sending device 205 and the receiving device 210 referenced in the embodiment.

[0084] For example, the sender and the receiver may expect 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 sending device and the receiving device may be provided with the same master symmetric key. Further, it should be understood that any party or device holding the same secret symmetric key can perform the function of the sending device, and similarly, any party holding the same secret symmetric key can perform the function of the receiving device. In some examples, the symmetric key may include a shared secret symmetric key, which is kept secret to all parties except the sending device and the receiving device that participate in the exchange of secure data. It should also be understood that both the sending device and the receiving device may be provided with the same master symmetric key, and it should also be understood that 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 sending device and the receiving device may be provided with the same master key, such as the same master symmetric key. 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 desired length diversified symmetric key as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms, such as 3DES or AES128; symmetric HMAC algorithms, such as HMAC-SHA-256; and symmetric CMAC algorithms, such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key can produce multiple outputs, which can 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 to create a diversified symmetric key. The diversified symmetric key may be used to process sensitive data before transmitting the result to the receiving device. For example, the sending device may use the diversified symmetric key to encrypt sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. The sending device may then transmit the protected encrypted data along with the counter value to the receiving device for processing. In some examples, cryptographic operations other than encryption may be performed, and multiple cryptographic operations may be performed using the diversified symmetric key before transmitting the protected data.

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

[0089] At block 430, one or more cryptographic algorithms and diversified keys may be used to protect sensitive data. A diversified session key (which 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 through a MAC using a first diversified session key, and the resulting output may be encrypted using a second diversified session key, thereby producing 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 the encryption. The output of the encryption may be a diversified symmetric key value that is the same as the diversified symmetric key value created by the sender. For example, the receiving device may independently create its own copy of the first diversified session key and the second diversified session key 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 using one or more cryptographic algorithms to authenticate the protected data.

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

[0093] The next time sensitive data needs to be sent from the sending device to the receiving device, a different counter value can be selected, which generates 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 generate the same diversified symmetric key. This diversified symmetric key (rather than the master symmetric key) is used to protect sensitive data.

[0094] As explained above, both the sending device and the receiving device initially each possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is independently created by both the sending device and the receiving device, it will never be 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 a small counter value is processed using the master symmetric key, while sensitive data is not processed using the master symmetric key. Therefore, the side channel data disclosed about the master symmetric key is reduced. Moreover, the sender and the receiver can agree, for example, by prior arrangement or other means, how often a new diversified value is created and thus a new diversified symmetric key is created. In an embodiment, a new diversified value can be created for each exchange between the sending device and the receiving device, and thus a new diversified symmetric key is created.

[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 nonce generated each time a new diversified key is needed and transmitted 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, one or more portions of the key diversification value may be used by each party 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. A new diversification value, and therefore a new diversified symmetric key, can be created whenever needed. In the most secure case, a new diversification value can be created for each exchange of sensitive data between a sending device and a receiving device. In practice, this may create a one-time use key, such as a single session key.

[0097] In other examples, such as 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 every 10 transmissions between the sending device and the receiving device). In another example, this may be after a certain period of time, after a certain period of time after the 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 whenever the receiving device signals to the sending device that it expects to change the key in the next communication. This may be controlled according to policy and may vary 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 unrelated to the payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 500 may include a substrate 510, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical properties that conform to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that a contactless card 500 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a 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 pad 520. The contact pad 520 may be configured to establish contact with another communication device (such as a user device, a smart phone, a laptop, a desktop computer, or a tablet computer). The contactless card 500 may also include processing circuitry, an antenna, and a Figure 5A Other components not shown in the figure. These components can be located behind the contact pad 520 or elsewhere on the substrate 510. The contactless card 500 can also include a back side of the card ( Figure 5A A magnetic strip or tape (not shown).

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

[0101] The memory 535 may 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 may include one or more of these memories. The read-only memory may be a factory-programmable read-only memory or a one-time programmable memory. One-time programmable provides the opportunity to write once and then read multiple times. The write-once / read-many memory can be programmed at a certain point in time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

[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 both 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 pads, but the present disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the pad 520, or completely separated from the pad, or as other elements outside of the processor 530 and memory 535 elements located within the contact pad 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 pad 520. For example, the one or more antennas 555 may be integral 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 pad 520 and the processing circuit 525.

[0105] In an embodiment, the coil of the contactless card 500 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting off power or modulating amplitude. The contactless card 500 can use the gap in the power connector of the contactless card to infer the data transmitted from the terminal, and the power connection can be maintained in terms of function by one or more capacitors. The contactless card 500 can communicate by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference.

[0106] As explained 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. A small application can be added to a contactless card to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The small application can be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader) and generate an NDEF message including 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 may be configured to encode the OTP as an NDEF Type 4 well-known type text tag. In some examples, the NDEF message may include one or more records. The applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, Tag Type: Well-known Type, Text, Encoded English (en); Applet ID: D2760000850101; Function: Read-only access; Encoding: The authentication message may be encoded as ASCII hexadecimal; Type-Length-Value (TLV) data may be provided as personalized parameters that may be used to generate an NDEF message. In an embodiment, the authentication template may 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 message starts, rather than ends, 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 may be stored in the contactless card at personalization by implementing STORE DATA (E2) under secure channel protocol 2. One or more values ​​may be read by the personalization office from the EMBOSS file (in the section specified by the applet ID), and one or more store data commands may be transmitted to the contactless card after authentication and secure channel establishment.

[0110] The pUID may include 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 when unlocked and authenticated. Other states may include a standard state pre-personalization. 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) that 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 including a specific authentication message layout and a specific algorithm. For minor versions, this may include not making changes to the authentication message or cryptographic algorithm, and not making changes to static tag content, except for 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 reading of the tag can be processed, the token can be transmitted to a server such as a backend server, and the token can be verified at the server.

[0115] In some examples, the contactless card and the server may include certain data that enables the card to 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 the card is read, the card is transmitted to the server for verification and a determination is made as to whether the counters are 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 is immediately rejected or otherwise ignored if the counter has been read, used, or otherwise ignored. If the counter has not been used, it may 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, the first applet being 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 so that the counter is updated and a new communication is generated by the contactless card, but the communication may not be transmitted to one or more servers for processing. This may cause the counter of the contactless card and the counter maintained at one or more servers to be out of sync. This may happen unintentionally, including, for example, when the card is kept close to the device (e.g., carried in a bag with the device), and when the contactless card is read at an angle, it may include that the card is not aligned or not positioned so that the contactless card is powered on but unreadable in the NFC field. If the contactless card is positioned close to the device, the NFC field of the device can 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 counters synchronized, an application (such as a background application) may be executed that is configured to detect when the mobile device wakes up and synchronize with one or more servers indicating that a read has occurred due to the detection, and then forward the counter. Since the counter of the contactless card and the counter of the one or more servers may be out of synchronization, the one or more servers may be configured to allow the counter of the contactless card to be updated a threshold number of times or a predetermined number of times before 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 1 for each occurrence indicating that the contactless card is activated, the one or more servers may allow any counter value read from the contactless card to be valid, or allow any counter value within a threshold range (e.g., from 1 to 10) to be valid. In addition, the one or more servers are configured to request a gesture associated with the contactless card, such as a user tap, if the counter value it reads has exceeded 10 but is below another threshold range value (such as 1000). Through the user tap, if the counter value is within the expected or accepted range, the authentication is successful.

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

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

[0121] The MAC key may be used to prepare a MAC password and the ENC key may be used to encrypt the password at block 830. For example, a MAC session key may be used to prepare a password and the result may be encrypted using the ENC key before it is transmitted 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 MAC verification. The session key is independently derived on one or more servers, resulting in a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0123] For contactless cards, different unique identifiers will be derived, which may be related to the application master account number (PAN) and PAN serial number encoded in the card. Key diversification may be configured to receive an identifier and take it as input along with a master key, so that one or more keys may 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 Password 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 first key and the second key may be created by diversifying the issuer master key by combining the issuer master key with the card's unique ID number (pUID) and the PAN sequence number (PAN sequencenumber, PSN) of the payment applet. The pUID may include a 16-bit digital value. As explained above, the pUID may include a 16-bit BCD-encoded number. In some examples, the pUID may include a 14-bit digital value.

[0124] In some examples, since the EMV session key derivation method may terminate at 2^16 uses, a counter, such as a full 32-bit counter, may be added to the initialization array of the diversification method.

[0125] In other examples such as a credit card, a number (such as an account number or an unpredictable number provided by one or more servers) may be used for session key generation and / or diversification.

[0126] Fig. 9A schematic diagram of a system 900 configured to implement one or more embodiments of the present disclosure is shown. As explained 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 that 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 portfolio of one or more applets being issued. For example, the first master key 905 may include an issuer password generation / authentication key (Iss-Key-Auth), and the second master key 910 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 905, 910 are 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 may be used as background data that may be used to identify which issuer master key 905, 910 to use during the encryption process for authentication. 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 increase the security of the solution, session keys (such as unique keys for each session) can be derived, but instead of using a master key, a unique card derived key and counter can be used as diversified data, as explained above. For example, each time a card is used in an operation, a different key can be used to create a message authentication code (MAC) and perform encryption. Regarding session key generation, the keys used to generate passwords and encrypt data in one or more applets can 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) can be generated by one or more applets and derived using an application transaction counter (pATC) 945 using one or more algorithms. In order to make the data suitable for one or more algorithms, only the 2 low-order bytes of the 4-byte pATC 945 are used. In some examples, a four-byte session key derivation method may include: F1: =PATC(lower 2 bytes)||'F0'||'00'||PATC(four bytes) F1: =PATC(lower 2 bytes)||'0F'||'00'||PATC(four bytes) SK: ={(ALG(MK)[F1])||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-AUTH 925 and Card-Key-DEK 930 are further diversified into session keys Aut-Session-Key 935 and DEK-Session 940. The pATC 945 may be initialized to zero at personalization or applet initialization time. In some examples, the pATC counter 945 may be initialized at or before personalization and may be configured to increment by 1 at each NDEF read.

[0130] Further, updates may be unique to each card and may be assigned by personalization or algorithmically assigned by pUID 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 when read sequentially, such that a card may be sequentially incremented by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined at personalization, or derived from the unique identifier according to one or more processes. This makes it more difficult for a replay attacker to generalize from a smaller number of card instances.

[0131] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, only the authentication data and an 8-byte random number (followed by a MAC of the authentication data) may be included. 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 other 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 the block size may be used, or the output may be automatically or manually padded to a multiple of the block size.

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

[0133] In some examples, one or more HSM commands may be processed for decryption so that the final 16 (binary, 32 hex) bytes may include 3DES symmetric encryption using CBC mode, where the fourth zero of the random number is 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. Further, in some examples, the first byte may be set to ASCII 'A'.

[0135]

[0136]

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

[0138]

[0139]

[0140] 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. Using the card master keys (Card-Key-Auth 925 and Card-Key-DEK 930), the counter (pATC) field of the received message can be used to derive the session keys (Aut-Session-Key 935 and DEK-Session-Key 940) for that particular card. Cryptogram B 960 can be decrypted using the DEK-Session-KEY, which produces Cryptogram 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, UID, and pATC fields of the message, can be processed through the Cryptogram MAC, using the recreated Aut-Session-Key, to create a MAC output, such as MAC'. If the MAC' is the same as the cipher A 955, this indicates that the message decryption and MAC check have all passed. The pATC can then be read to determine if it is valid.

[0141] During the authentication session, one or more applications may generate one or more passwords. For example, one or more passwords may be generated as a 3DES MAC using ISO 9797-1 algorithm 3 with method 2 padding via one or more session keys (such as Aut-Session-Key 935). Input data 950 may take the following form: version (2), pUID (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 personalization, which is 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 to the end of the input data and adding a 0x'00' byte to the end of the result data until an 8-byte boundary. The resulting password may include a length of 8 bytes.

[0142] In some examples, one benefit of encrypting the unshared random number as the first block with 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" on a block-by-block basis without having to pre-establish a fixed or dynamic IV.

[0143] By including an application transaction counter (pATC) as part of the data included in the MAC password, the authentication service can be configured to determine whether the value conveyed in the plaintext data has been tampered with. In addition, by including the version in one or more passwords, it is difficult for an attacker to purposefully tamper with the application version in an attempt to reduce the strength of the encryption solution. In some examples, the 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 lower than a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authenticated message may be rejected. In some examples, when the pATC is greater than the previously received value, it can be evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds the range or threshold or is outside the range or threshold, the verification can be considered to have failed or 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.

[0144] In order to provide additional protection against brute force attacks that expose the on-card key, it is desirable to encrypt the MAC password 955. In some examples, the data or password A 955 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 this 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, i.e., password B 960. The data 955 may be encrypted using 3DES in a ciphertext block chaining mode to ensure that any attack by an attacker must be performed against the entire ciphertext. 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 has been used, as correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.

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

[0146] 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 in an encryption process for authentication. In some examples, the method may include performing authentication as follows: retrieving the values ​​of the pNPR and pDKI of the contactless card at the time of authentication.

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

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

[0149] 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 to obtain the session keys Aut-Session-Key and DEK-Session-Key.

[0150] Fig.11 An exemplary process 1100 showing key diversification according to one example is depicted. Initially, a sender and a receiver may be provided with two different master keys. 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 that may be updated at block 1110, as well as other data (such as data to be protected) that the sender may securely share with the receiver.

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

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

[0153] 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 plaintext and shared secret) may be used to generate a MAC using one of the session keys (AUT-Session-Key).

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

[0155] At block 1150, the encrypted MAC is transmitted from the sender to the receiver along with sufficient information (eg, a shared secret, a master key, etc.) to identify the additional secret information for cryptographic verification.

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

[0157] 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. Other processing is then performed on the exchanged data. 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.

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

[0159] 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 only likely to be correct if the decryption is successful and produces the correct MAC value. Successful decryption can indicate that the correctly derived encryption key has been used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., a sending device) and the receiver (e.g., a receiving device), it can be believed that the contactless card that originally created the MAC and encrypted the MAC is indeed authentic. In addition, the counter value used to derive the first session key and the second session key can be shown to be valid and can be used to perform the authentication operation.

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

[0161] 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 the 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 both 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 against a device. In some examples, the device may include a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process a received tap gesture.

[0162] In some examples, the contactless card can be tapped against a device (such as one or more computer kiosks or terminals) to verify identity, thereby receiving a transaction item in response to a purchase, such as coffee. By using a contactless card, a secure method for proving identity in a loyalty program can be established. Establishing a secure way to prove identity in a manner different from simply scanning a barcode card, such as to obtain a reward, coupon, discount, etc. or the receipt of a benefit. For example, an encrypted transaction can occur between a contactless card and a device, which can be configured to process one or more tap gestures. As explained above, one or more applications can be configured to verify the identity of the user, and then enable the user to act or respond to it, for example, via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, health care information, etc. can be written back to the contactless card.

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

[0164] In some examples, a contactless card can be activated by tapping against a device such as a mobile device. For example, a contactless card can communicate with an application of the device via a card reader of the device through NFC communication. In the communication, the card is tapped near the card reader of the device, which can allow the application of the device to read the data associated with the contactless card and activate the card. In some examples, activation can authorize the card to perform other functions, such as purchase, access to account 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, for example, 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.

[0165] In some embodiments, a dedicated application may be configured to run on a client device to perform activation of a contactless card. In other embodiments, a web portal, a web-based application, a small application, and / or the like may perform activation. Activation may be performed on a client device, or the client device may only act as an intermediary 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 activation (e.g., a personal computer, a smart phone, a tablet computer, or a point-of-sale (POS) device). Further, 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.

[0166] In some embodiments, the example authentication communication protocol can mimic the offline dynamic data authentication protocol of the EMV standard with some modifications that is typically performed between a transaction card and a point-of-sale device. For example, because the example authentication protocol itself is not used to complete a payment transaction with a card issuer / payment processor, certain data values ​​are not required, and authentication can be performed without involving a real-time online connection with the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction including a transaction value to a card issuer. Whether the issuer approves or rejects the transaction can be based on whether the card issuer recognizes the transaction value. However, 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 pseudo 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 the buffer value may result in a soft decline; a 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.

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

[0168] If the contactless card tap is for running Apple The contactless card can be recognized by the device operating system (such as iPhone, iPod or iPad) The operating system transmits the appropriate data to communicate with this device. For example, a contactless card can provide the encrypted identity information required to authenticate the card using an NDEF tag via, for example, NFC. Similarly, if a contactless card tap is directed to a running Operating system devices (e.g. smartphone or tablet), the contactless card can be recognized operating system and transmits appropriate data (such as encrypted identity information required for authentication via the methods described herein) to communicate with this device.

[0169] As another example, a contactless card tap can be performed against a POS device, including but not limited to a self-service machine, a checkout register, a payment station, or other terminal. When performing the tap, the contactless card can identify the POS device and transmit only the information required for the action or transaction. For example, after identifying the POS device used to complete a commercial transaction, the contactless card can transmit the payment information required to complete the transaction in accordance with the EMV standard.

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

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

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

[0173] 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 in order to verify the user's identity.

[0174] 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 cheapest purchases, and / or reconfiguring to another action in real time.

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

[0176] In some examples, the device may include an application to split a bill or check for payment among multiple individuals. For example, each individual may have a contactless card and may be a customer of the same issuing financial institution, but this is not required. Each of these individuals may receive a push notification on their device via 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 card tapping individual.

[0177] The following example use cases describe examples of specific embodiments of the present disclosure. These are intended for explanation purposes only, not for limiting purposes. 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 needing to exchange via an end-to-end application. The payee logs into the appropriate application on his smartphone and then selects the payment request option. In response, the application requests authentication through the payee's contactless card. For example, the application outputs a display asking the payee to tap his contactless card. Once the payee taps his contactless card on the screen of a smartphone with a supported application, the contactless card is read and verified. Next, the application displays a prompt for the payee to tap his contactless card to send the 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.

[0178] 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 needs to be activated) 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 via an application on his or her device (e.g., a mobile device such as a smartphone). The customer may select a card activation function from an application menu displayed on the device's display. The application may prompt the customer to tap his or her credit card on the screen. Upon tapping the credit card against the device's screen, the application may be configured to communicate with a server (such as a card issuer server that activates the customer's card). The application may then display a message indicating successful activation of the card. The card activation will then be complete.

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

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

[0181] At box 1220, one or more portions of the dynamically generated data may be transmitted to an application of the device via NFC or other wireless communication. For example, tapping the card near the device may allow the device's application to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to help activate the card, tapping the card may direct the device or prompt the customer to a software application store to download an associated application to activate the card. In some examples, the user may be prompted to fully position, place, or orient the card toward the surface of the device, such as at an angle or flat on, near, or adjacent to the surface of the device. In response to the fully adjusted position, placement, and / or orientation of the card, the device may proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

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

[0183] At block 1240, one or more servers may decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and may decrypt it to compare the received data with recorded data accessible to the one or more servers. If the resulting comparison of the one or more decrypted portions of the data performed by the one or more servers produces a successful match, the card may be activated. If the resulting comparison of the one or more decrypted portions of the data performed by the one or more servers produces 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 including the number of attempts to permit 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 a request to call, email, or text message an associated service for assistance in activating the card; or another notification, such as a phone call on his or her device indicating an unsuccessful attempt at card verification and a request to call, email, or text message an associated service for assistance in activating the card; or another notification, such as an email indicating an unsuccessful attempt at card verification and a request to call, email, or text message an associated service for assistance in activating the card.

[0184] At block 1250, one or more servers may transmit a return message based on the successful activation of the card. For example, the device may be configured to receive an output from one or more servers indicating the successful activation of the card by the one or more servers. The device may be configured to display a message indicating the successful activation of the card. Once the card is activated, the card may be configured to not continue to dynamically generate data to avoid fraudulent use. In this manner, the card may not be activated thereafter, and the one or more servers are notified that the card has been activated.

[0185] In another example scenario, a customer wants to access a 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 may see first-level account information (e.g., recently purchased items) and be able to perform first-level account options (e.g., pay for a credit card). However, if the user attempts to access second-level account information (e.g., spending limits) or perform second-level account options (e.g., transfers to an external system), he or she must have a second-level factor authentication. Therefore, the application requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps his or her credit card against the mobile device, and the application verifies that 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.

[0186] It is understood that a large amount of commercial and entertainment activities are conducted through software applications, and the number of applications installed on the client devices of ordinary users continues to increase. Rather than requiring the installation and / or launching of an application on a client device, example embodiments of the present disclosure provide systems and methods in which a gesture of a contactless card can be configured to transmit a uniform resource locator (URL) with an encrypted one-time password and initiate one or more calls to a server for authorization in order to authorize access to one or more services associated with the server.

[0187] System and method described herein are configured to deliver one-time passwords using a link such as a URL. In particular, an encrypted payload can be delivered in a URL string, and the URL string is dynamically generated by one or more applets. In some examples, the encrypted payload can include a password. The encrypted payload can be configured to verify identity, which can be used for URL personalization of a specific individual. As further explained below, the encrypted payload can be attached to the end of the URL and processed separately from the main URL string. In some examples, a server can receive a payload, and the server can be configured to utilize symmetric key decryption to decrypt the payload, so that authorized access to one or more services associated with the back end. In other examples, a server can receive a payload, and the server can be configured to utilize public key decryption to decrypt the payload, so that authorized access to one or more services associated with the back end. Rather than requiring an application to be installed and / or launched on a client device, the systems and methods disclosed herein do not require an application to be installed on a client device in order for a URL to work, such that a gesture generated by a contactless card can be configured to transmit a URL with an encrypted one-time password and initiate one or more calls to a server for authorization, thereby authorizing access to one or more services associated with the server, including but not limited to activation and launching of a pre-logged-in website. The systems and methods described herein can be configured to operate on one or more of a variety of user devices, including but not limited to devices such as payment terminals or systems, kiosks, etc., running Operating system equipment, including but not limited to For example run Operating system equipment and operation Operating system of the device.

[0188] Fig.13A system 1300 is shown that is configured to deliver a one-time password using a link. The system 1300 may include an encrypted payload system that includes a contactless card 1305, a client device 1310, and one or more servers 1320. Although Fig.13 A single example of a component is shown, but the system 1300 may include any number of components. The contactless card 1305, the client device 1310, and the one or more servers 1320 may refer to the previous reference Figure 1A , Figure 1B , Figure 5A and Figure 5B The same or similar components as explained above, such as the contactless card 105, the client device 110, and the server 120.

[0189] Contactless card 1305 may include, but is not limited to, processor 1307 and memory 1309. Memory 1309 may include one or more applets 1311. One or more applets 1311 may be configured to dynamically generate a payload that is attached to a link. In some examples, the encrypted payload may include a password. The encrypted payload may be configured to verify an identity that may be used for link personalization for a specific individual. By attaching a one-time password to a link, restrictions on operating systems that do not allow reading of complete NDEF messages may be avoided. In some examples, the payload may include a delimiter. For example, a delimiter may be configured to delimit the start and end portions and may be depicted by a symbol to identify the payload. As described below, one or more symmetric key decryption algorithms may be used to decrypt the payload. In other examples, one or more public key decryption algorithms may be used to decrypt the payload. The payload may be generated by one or more random number generator algorithms.

[0190] The contactless card 1305 may be configured to transmit a link with an attached payload to the client device 1310. In some examples, the transmission may occur via one or more gestures. For example, the one or more gestures may include one or more taps, swipes, or other gestures or any combination thereof. The link may be configured to launch one or more applications 1316 executable on the client device 1310. In some examples, at least one gesture may be configured to trigger one or more pre-programmed URLs for a single or multiple services, including but not limited to the activation process of the contactless card 1305 by one or more servers 1320. In some examples, one or more services may include web-based services that do not need to be installed on the client device 1310. In addition, the user or one or more servers 1320 may determine which service should occur after the activation process of the contactless card 1305 in response to the first gesture. This may include but is not limited to a phone call, email, or text message initiated by customer service; directed to a website and logged in.

[0191] In some examples, different gestures, such as different taps, swipes, gestures, or any combination thereof, may indicate corresponding services. For example, a tap may indicate a service, such as an activation process of a contactless card 1305. A second tap may indicate another service, such as a call, email, or text message initiated by customer service. In some examples, at least one of the gestures may be configured to trigger a redirection to one or more websites by one or more servers 1320. In some examples, at least one of the gestures may be configured to trigger one or more servers 1320 to generate at least one notification. As described below, the notification may be transmitted to the client device 1310 to access one or more applications 1316. In some examples, the activation process of the contactless card 1305 may occur before launching the application 1316 or website.

[0192] Client device 1310 may include, but is not limited to, processor 1312, memory 1314, and one or more applications 1316. Client device 1310 may communicate with contactless card 1305. In some examples, client device 1310 may be one or more of a variety of user devices, including but not limited to devices such as payment terminals or systems, self-service machines, devices running Devices with operating systems, including but not limited to iPhone For example run Operating system equipment and operation Operating system of the device.

[0193] The client device 1310 may be configured to receive a link from the contactless card 1305. In some examples, the client device 1310 may be configured to transmit a payload to the one or more servers 1320. The client device 1310 may be configured to request access to a plurality of services associated with the one or more servers 1320.

[0194] One or more servers 1320 may communicate with client device 1310. One or more servers 1320 may be configured to receive a payload from client device 1310 via one or more applications 1316. In some examples, one or more servers 1320 may be configured to parse and decrypt the payload after launching one or more applications 1316. In some examples, one or more servers 1320 may be configured to decrypt the encrypted payload via one or more symmetric key decryption algorithms. In other examples, one or more servers 1320 may be configured to decrypt the encrypted payload via one or more public key decryption algorithms. One or more servers 1320 may be configured to send one or more notifications to client device 1310 based on a state associated with decryption of the payload. Based on one or more notifications received from one or more servers 1320, client device 1310 may be authorized to access multiple services associated with one or more servers 1320. In some examples, one or more services may include web-based services that do not need to be installed on client device 1310.

[0195] In some examples, at least one notification may include an authentication message transmitted from one or more servers 1320 to client device 1310. In some examples, at least one notification may be transmitted to client device 1310 to access a previously authorized website. In some examples, at least one notification may include a failure message transmitted from one or more servers 1320 to client device 1310. For example, one or more servers 1320 may trigger a predetermined delay, which may be configured to be adjusted by a predetermined amount for each occurrence of a decryption failure of the payload, thereby allowing the payload to be successfully decrypted within the allocated predetermined amount. In some examples, each occurrence of a decryption failure denies login to a user of client device 1310, thereby prohibiting them from logging back in for 60 seconds. Based on each occurrence of a decryption failure, one or more servers may gradually increase this time.

[0196] Fig.14 A method 1400 for delivering a one-time password using a link is shown. In some examples, the method may include steps for authorizing access. The method 1400 may refer to the above Fig.13 Components that are the same or similar to the components described.

[0197] At block 1410, method 1400 may include dynamically generating, by the contactless card, a payload appended to the string. The payload may be encrypted by the contactless card. In some examples, the encrypted payload may include a password. The encrypted payload may be configured to verify an identity that may be used to personalize the string for a particular individual. The payload may include a delimiter. For example, the delimiter may be configured to delimit a beginning and an end portion and may be depicted by a symbol to identify the payload. The payload may be generated by one or more random number generator algorithms.

[0198] At block 1420, method 1400 may include establishing data communication between the client device and the contactless card to transfer the payload via one or more gestures. In some examples, the transmission may occur via one or more gestures. For example, the one or more gestures may include one or more taps, swipes, swipes, or any combination thereof. The string may be configured to launch one or more applications executable on the client device.

[0199] At block 1430, method 1400 may include transmitting the string and the attached payload to the client device via one or more gestures by the contactless card. At block 1440, method 1400 may include receiving the payload from the client device via one or more applications at one or more servers. At block 1450, method 1400 may include decrypting the payload by the one or more servers after launching the one or more applications. In some examples, one or more symmetric key decryption algorithms may be used to decrypt the encrypted payload. In other examples, one or more public key decryption algorithms may be used to decrypt the encrypted payload.

[0200] At block 1460, method 1400 may include transmitting, by one or more servers, one or more messages to a client device based on a state associated with decryption of the payload. In some examples, at least one message may include an authorization message transmitted from the one or more servers to the client device. In some examples, at least one message may include a failure message, which may be transmitted from the one or more servers to the client device. For example, one or more servers may trigger a predetermined delay, and the one or more servers may be configured to be adjusted by a predetermined amount for each occurrence of a decryption failure of the payload, thereby allowing the payload to be successfully decrypted within the allocated predetermined amount. In some examples, each occurrence of a decryption failure denies login to a user of the client device, thereby prohibiting them from re-logging in for 60 seconds. Based on each occurrence of a decryption failure, the one or more servers may gradually increase this time.

[0201] In some examples, at least one gesture made by the contactless card to the client device can be configured to trigger one or more servers to generate at least one message. For example, the message can be transmitted to the client device to access a previously authorized website. In some examples, at least one gesture can be configured to trigger one or more servers to generate at least one message. For example, the message can be transmitted to the client device to access one or more applications. In some examples, at least one gesture can be configured to trigger one or more pre-programmed URLs directed to a single or multiple services, including but not limited to the activation process of the contactless card by one or more servers. In some examples, one or more services may include web-based services that do not need to be installed on the client device. In addition, the user or one or more servers can determine which service should occur after the activation process of the contactless card in response to the first gesture. This can include but is not limited to a phone call, email, or text message initiated by customer service; directed to a website and log in. In some examples, different gestures, such as different taps, swipes, gestures, or any combination thereof, can indicate corresponding services. For example, a tap can indicate a service, such as an activation process for a contactless card. A second tap can indicate another service, such as a phone call, email, or text message initiated by customer service. In some examples, at least one gesture can be configured to trigger redirection by one or more servers to one or more websites. In some examples, the activation process of the contactless card can occur before launching the application or website.

[0202] At block 1470 , method 1400 may include authorizing, at the client device, access to a plurality of resources associated with the one or more servers based on the one or more messages received from the one or more servers.

[0203] 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 a card or other movement of a card).

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

[0205] In this description, many specific details have been set forth. However, it should be understood that the embodiments of the disclosed technology can be practiced without these specific details. In other cases, well-known methods, structures, and techniques are not shown in detail to avoid confusing the understanding of this description. Reference 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. indicates that one or more embodiments of the disclosed technology described in this way may include specific features, structures or characteristics, but not every implementation must include the specific features, structures or characteristics. In addition, although the phrases "in one example", "in one embodiment" or "in one implementation" can be used repeatedly, it does not necessarily refer to the same example, embodiment or implementation.

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

[0207] 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 only in a general and descriptive sense and not for purposes of limitation.

[0208] 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 content included. The patentable scope of certain embodiments 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 the same structural elements as 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. An encrypted payload system comprising: A contactless card comprising a processor and a memory, wherein the memory comprises a plurality of applets, wherein one or more of the applets are configured to dynamically generate an encrypted payload comprising a one-time password appended to a uniform resource locator URL; a client application comprising instructions for execution on a client device comprising a processor and a memory; and one or more servers in communication with the client application; wherein the contactless card is configured to transmit a URL with an attached payload to the client application via one or more gestures, the one or more gestures comprising one or more taps, swipes, swipes, or any combination thereof, wherein the URL is configured to launch the client application; wherein the one or more servers are configured to receive the payload from the client application; wherein the one or more servers are configured to parse and decrypt the payload after launching of the client application; wherein the one or more servers are configured to transmit at least one notification to the client application based on a status associated with decryption of the payload; wherein, based on at least one notification received from the one or more servers, the client application is authorized to access a plurality of services associated with the one or more servers; wherein each of the one or more gestures corresponds to a different service among the plurality of services; and The one or more gestures include a first gesture for triggering an activation process of the contactless card and a second gesture for initiating a phone call.

2. The encrypted payload system of claim 1, wherein: The payload includes a delimiter.

3. The encrypted payload system of claim 1, wherein: The at least one notification includes an authentication message returned to the client application.

4. The encrypted payload system of claim 1, wherein: The at least one notification includes a failure message, which is returned to the client application, causing a predetermined time delay to be triggered by the one or more servers, and for each decryption failure of the payload, the predetermined time delay is increased by a predetermined amount to allow successful decryption of the payload within the predetermined amount.

5. The encrypted payload system of claim 1, wherein: The payload is decrypted using one or more symmetric key decryption algorithms.

6. The encrypted payload system of claim 1, wherein: The payload is generated by one or more random number generator algorithms.

7. The encrypted payload system of claim 1, wherein: The client application is configured to request access to a plurality of services associated with the one or more servers.

8. The encrypted payload system of claim 1, wherein: The payload is decrypted using one or more public key decryption algorithms.

9. The encrypted payload system of claim 1, wherein: At least one gesture triggers the one or more servers to redirect to a website.

10. The encrypted payload system of claim 1, wherein: At least one gesture triggers the one or more servers to generate the at least one notification, which is transmitted to the client application for access.

11. A method for authorizing access, comprising: dynamically generating, by the contactless card, a payload including a one-time password appended to the uniform resource locator URL, the payload being encrypted by the contactless card; establishing communication between a client application and the contactless card, the client application comprising instructions for execution on a client device via one or more gestures, the one or more gestures comprising one or more taps, swipes, swipes, or any combination thereof, wherein the URL is configured to launch the client application; transmitting, by the contactless card via the one or more gestures, the URL and the attached payload to the client application; receiving, at one or more servers, a payload from the client application; upon initiation of the client application, decrypting, by the one or more servers, the payload; transmitting, by the one or more servers, at least one message to the client application based on a status associated with the decryption of the payload; and at the client application, authorizing access to a plurality of services associated with the one or more servers based on at least one message received from the one or more servers, wherein each of the one or more gestures corresponds to a different service among the plurality of services; and The one or more gestures include a first gesture for triggering an activation process of the contactless card and a second gesture for initiating a phone call.

12. The method for authorizing access according to claim 11, wherein: The payload includes a delimiter.

13. The method for authorizing access according to claim 11, wherein: The payload is decrypted using one or more public key decryption algorithms.

14. The method for authorizing access according to claim 11, wherein: The payload is generated by one or more random number generator algorithms.

15. The method for authorizing access according to claim 11, wherein: The at least one message comprises an authentication message transmitted to the client application.

16. The method for authorizing access according to claim 11, wherein: The at least one message comprises a failure message, which is transmitted to the client application, causing a predetermined time delay to be triggered by the one or more servers, and for each decryption failure of the payload, the predetermined time delay is increased by a predetermined amount to allow successful decryption of the payload within the predetermined amount.

17. The method for authorizing access according to claim 11, wherein: At least one gesture by the contactless card to the client application triggers the one or more servers to generate at least one message, which is transmitted to the client application to access a previously authorized website.

18. The method for authorizing access according to claim 11, wherein: At least one gesture triggers the one or more servers to generate the at least one message, which is transmitted to the client application for access.

19. The method for authorizing access according to claim 11, wherein: The payload is decrypted using one or more symmetric key decryption algorithms.

20. A contactless card, comprising: one or more processors and memory, wherein the memory includes one or more applets, wherein the one or more applets are configured to dynamically generate an encrypted payload including a one-time password appended to a uniform resource locator URL, wherein the encrypted payload is configured to verify identity in order to personalize the URL; wherein the contactless card is configured to transmit the URL with the attached payload to a client application, the client application including instructions for execution on a client device via one or more gestures, the one or more gestures including one or more taps, swipes, swipes, or any combination thereof, wherein the URL is configured to initiate the client application to decrypt the encrypted payload based on one or more notifications to authorize access to a plurality of services, wherein each of the one or more gestures corresponds to a different service among the plurality of services, and The one or more gestures include a first gesture for triggering an activation process of the contactless card and a second gesture for initiating a phone call.

Images