System and method for password authentication of contactless cards

Abstract

An example embodiment of a system and method for transmitting data between transmitting and receiving devices and authorizing a transaction is provided. In an embodiment, a method includes: generating a request for at least one authentication factor when the value of the transaction exceeds a predetermined value, wherein the at least one authentication factor includes a password; receiving an authentication signal, the authentication signal including the password; and authorizing the transaction when the authentication signal is received.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 16 / 351,365, filed on March 12, 2019, which is a continuation-in-part of and claims priority to U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, and claims priority to U.S. Provisional Patent Application No. 62 / 740,352, filed on October 2, 2018, 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 to attack and can be compromised by hackers or other unauthorized access. Short message service (SMS) messages can also be used, but these are also subject to compromise. Moreover, even data encryption algorithms (such as the Triple DES algorithm) have similar vulnerabilities.

[0006] Activating many cards, including, for example, financial cards (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 identity of the cardholder. However, if the login credentials are compromised, another person may be able to access the user's account.

[0007] These and other deficiencies exist. Therefore, there is a need to provide users with appropriate solutions to overcome these deficiencies, thereby providing 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 authentication system, comprising: an authentication server; a client application, the client application comprising instructions for execution on a client device that performs data communication with the authentication server; and a contactless card, the contactless card comprising a processor and a memory; wherein the authentication server is configured to: receive a transaction request, wherein the transaction request comprises account information of an account requested to participate in the transaction and transaction information of the transaction; in response to receiving the transaction request, when the value of the transaction exceeds a predetermined value, send an authentication request to the client application requesting at least one authentication factor, wherein the at least one authentication factor comprises a password generated by placing the contactless card in a communication field of the client device; receive an authentication signal from the client device, the authentication signal comprising the password; and when the authentication signal is received, authenticate the transaction.

[0010] An embodiment of the present disclosure provides an authentication system, comprising: an authentication server that performs data communication with a network; a client application, the client application comprising instructions for execution on a client device that performs data communication with the network; and a contactless card, the contactless card comprising a processor and a memory, wherein the contactless card is associated with an account having account information; wherein the authentication server is configured to: receive a transaction request, wherein the transaction request comprises account information of an account associated with the contactless card and transaction information of a transaction; in response to receiving the transaction request, when the value of the transaction exceeds a predetermined value, send an authentication request requesting at least one authentication factor to the client application; receive an authentication signal comprising at least one authentication factor from the client application; and when the authentication signal is received from the client application, authenticate the transaction.

[0011] An embodiment of the present disclosure provides a method for authenticating a transaction, comprising the following steps: receiving a transaction verification request by an authentication server, wherein the transaction verification request includes account information of an account requested to participate in the transaction and transaction information of the transaction; in response to receiving the transaction request, when the value of the transaction exceeds a predetermined value, sending an authentication request by the authentication server to a client application including instructions for execution on a client device, the authentication request requesting at least one authentication factor, wherein the at least one authentication factor includes a password generated by placing a contactless card in a communication field of the client device; detecting the at least one authentication factor by the client application via at least one of a sensor and a communication interface; sending an authentication signal including the authentication factor by the client application to the authentication server; in response to receiving the authentication signal from the client application, verifying the at least one authentication factor by the authentication server; and authorizing the transaction by the authentication server in response to the verification of the authentication factor.

[0012] In the following, further features of the disclosed design and the advantages provided thereby will be explained in more detail with reference to specific example embodiments shown in the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a schematic 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 a diagram of an authentication system according to an example embodiment.

[0028] Fig.14 is a flow chart illustrating a method of authenticating a transaction according to an example embodiment. DETAILED DESCRIPTION

[0029] The following description of the embodiments provides non-limiting representative examples with reference to the accompanying drawings to specifically describe the features and teachings of different aspects of the present invention. The described embodiments should be considered capable of being implemented separately or in combination with other embodiments from the description of the embodiments. A person of ordinary skill in the art who consults 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 help to understand the present invention to the extent that other implementations that are not specifically covered but are within the knowledge of a person of ordinary skill in the art who has 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 invention. operating system, but for A challenge was presented. 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 1A 1 shows a data transmission system according to an example embodiment. As discussed further below, system 100 may include contactless card 105, client device 110, network 115, and server 120. Figure 1A A single instance of a component is shown, but system 100 may include any number of components.

[0032] System 100 may include one or more contactless cards 105, which will be referred to below. FIG. 5A to FIG. 5B Further explanation: In some embodiments, the contactless card 105 can communicate wirelessly 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 described herein, a network-enabled computer may include, but is not limited to, a computer device or a communication device, including, for example, a server, a network appliance, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. Client device 110 may also be a mobile device; for example, a mobile device may include a 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 device 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 may communicate with one or more servers 120 via one or more networks 115 and may operate as a respective front-end to back-end pair with the server 120. The client device 110 may 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 may be associated with obtaining data from the server 120. The server 120 may receive the one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 may be configured to obtain the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 120 may be configured to 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, the Internet, a satellite network, a wireless local area network (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, radio frequency identification (RFID), Wi-Fi, and / or others.

[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 the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. The network 115 may also include one network, or any number of the exemplary types of networks mentioned above that operate as independent networks or in cooperation 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 convert other protocols to or from other protocols to one or more protocols of network devices. 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 Possible references include Figure 1A Similar components as shown.

[0041] At step 102, application 122 communicates with contactless card 105 (e.g., after being brought near contactless card 105). Communication between application 122 and contactless card 105 may involve contactless card 105 being close enough 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 contactless card 105 is read by the application 122. In particular, this may occur when reading (such as NFC reading) a near field data exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a reader such as the application 122 can transmit a message (such as an applet selection message) having an applet ID of an applet that generates NDEF. After confirming the selection, a sequence of selected file messages followed by a read file message can be transmitted. For example, the sequence can include "select function file", "read function file" and "select NDEF file". At this time, a counter value maintained by the contactless card 105 can be updated or incremented, followed by "read NDEF file". At this time, a message that can include a header and a shared secret can be generated. Then a session key can be generated. The MAC password can be created based on the message, which can 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, this transmission 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 explained 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 encryption algorithms (such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms), it is important that the key 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 encryption 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 is processed by the encryption algorithm using the same key. The more data an attacker has that is processed with the same key, the greater the chance that the attacker can discover the value of the key. 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 small 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 involved 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 resorting to 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 desire to exchange data (e.g., original sensitive data) via the respective devices 205 and 210. As explained above, although a single instance of the sending device 205 and the receiving device 210 may be included, it should be understood that one or more wipe mixing 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 others.

[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, or any number of the exemplary types of networks mentioned above that operate as independent networks or 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 convert other protocols to or from other protocols to one or more protocols of network devices. 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 and transmit and receive data between each other without passing 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, etc.

[0059] At box 225, when the sending device 205 is ready to process sensitive data with a symmetric cryptographic operation, the sender can update the counter. In addition, the sending device 205 can select an appropriate symmetric encryption algorithm, which can include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm for processing diversified values ​​can include any symmetric encryption algorithm for generating a diversified symmetric key of a desired length as needed. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms (such as 3DES or AES128), symmetric HMAC algorithms (such as HMAC-SHA-256 algorithms), 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 encryption 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 using the master symmetric key, thereby creating a diversified symmetric key.

[0061] In some examples, the counter value may not be encrypted. In these examples, the counter value may be 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, 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 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 a symmetric decryption algorithm and the diversified symmetric key.

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

[0066] The next time sensitive data needs to be sent from 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 encryption 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 can 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. As a result, reduced side channel data about the master symmetric key is presented. Moreover, the operation of the sending device 205 and the receiving device 210 can be governed by symmetric requirements on the frequency of creating new diversified values ​​and thus creating new diversified symmetric keys. 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: a random number generated each time a new diversified key is needed and sent from the sending device 205 to the receiving device 210; the full value of the counter value sent from the sending device 205 and the receiving device 210; a portion of the counter value sent from the sending device 205 and the receiving device 210; a counter maintained independently by the sending device 205 and the receiving device 210 but not sent between the two devices; a one-time passcode 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 can be created each time, and therefore a new diversified symmetric key can be created. 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, which will be referred to below as 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, such as 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 devices, 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 may communicate with one or more servers 320 and 325 via one or more networks 315. The client device 310 may transmit one or more requests to the one or more servers 320 and 325, for example, from an application 311 executing on the client device 310. The one or more requests may be associated with obtaining data from the one or more servers 320 and 325. The servers 320 and 325 may 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 may be configured to obtain 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 may 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 instead 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 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 communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, 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 an operator, and the Internet between an operator and a backend.

[0076] In addition, the network 315 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. In addition, the network 315 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. The network 315 may also include a network, or any number of the exemplary types of networks mentioned above that operate as independent networks or in cooperation with each other. The network 315 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 315 may convert other protocols to or from other protocols to one or more protocols of network devices. Although the network 315 is depicted as a single network, it should be understood that, according to one or more examples, the network 315 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, a corporate network 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 distance of less than twenty centimeters is consistent with the NFC range as will be appreciated by those skilled in the art.

[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 the card reader 313 of the client device 310 via NFC. This communication (e.g., tapping the card near 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 tap of the card on the card reader 313 can initiate the download of the application 311 (e.g., navigate 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 obtain information associated with contactless card 305 by accessing a digital wallet implemented on client device 310, wherein the digital wallet includes the virtual payment card. In some examples, the virtual payment card data may include one or more statically or dynamically generated virtual card numbers.

[0082] Server 320 may include a network server in communication with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more 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) through 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 that 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 box 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 symmetric cryptographic operations, the sender can update the counter. In addition, the sending device can select an appropriate symmetric encryption 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 diversified values ​​may include any symmetric encryption algorithm for generating a diversified symmetric key of a desired length 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 algorithms), 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 using 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 encryption 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 encrypt the counter value using the selected symmetric encryption algorithm using the master symmetric key, thereby creating a diversified symmetric key. The diversified symmetric key may be used to process sensitive data before the result is transmitted to the receiving device. For example, the sending device may encrypt sensitive data using a symmetric encryption algorithm using a diversified symmetric key, wherein 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 encryption operations may be performed using the diversified symmetric key before the protected data is transmitted.

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

[0089] At block 430, one or more encryption 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 encryption algorithms to protect sensitive data. For example, data may be processed by a MAC using a first diversified session key, and the resulting output may be encrypted using a second diversified session key, 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 encryption. The output of the encryption may be the same 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 verify the protected data using the diversified key with one or more encryption algorithms.

[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 decryption, 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 encryption 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. Because the diversified symmetric key is independently created by both the sending device and the receiving device, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker can 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. As a result, reduced side channel data about the master symmetric key is presented. 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 key diversification values ​​include: a random number generated each time a new diversified key is needed and sent from the sending device to the receiving device; the full value of the counter value sent from the sending device and the receiving device; a portion of the counter value sent from the sending device and the receiving device; a counter maintained independently by the sending device and the receiving device but not sent between the two devices; a one-time passcode 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 can be created whenever needed, and therefore a new diversified symmetric key. In the most secure case, a new diversification value can be created for each exchange of sensitive data between the sending device and the 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, a new diversification value may be agreed upon by the sender of the sending device and the receiver of the receiving device and thus a new diversified symmetric key 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 time period, after a certain time period after a transmission, or periodically (e.g., daily at a specified time; weekly 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 that the present disclosure does not require the implementation of a contactless card in 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 can be a read-only memory, a write-once read-many memory or a read / write memory, such as a RAM, a ROM and an EEPROM, and the contactless card 500 can include one or more of these memories. The read-only memory can be a factory-programmable read-only memory or a one-time programmable memory. One-time programmability provides an opportunity to write once and then read multiple times. The write-once / read-many memory can be programmed at a certain point in time after the memory chip has been shipped. Once the memory is programmed, it may not be rewritten, but it may be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after shipping. It can also be read multiple times.

[0102] Memory 535 can be configured to store one or more applets 540, one or more counters 545 and customer identifier 550. One or more applets 540 can include one or more software applications configured to be executed on one or more contactless cards, such as Java card applets. However, it should be understood that applets 540 are not limited to Java card applets, and can instead be any software application that can operate on contactless cards or other devices with limited memory. One or more counters 545 can include digital counters sufficient to store integers. Customer identifier 550 can include a unique alphanumeric identifier assigned to a user of contactless card 500, and the identifier can distinguish the user of the 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. Applets can be added to contactless cards to provide one-time passwords (OTPs) for multifactor authentication (MFA) in various mobile application-based use cases. The applet 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 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 start of the message, rather than the end, and subsequent records may be added. Because the ID length is zero, the ID length field and the ID are omitted from the record. An example message 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 the time of 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 comprise a 16-bit BCD-encoded number. In some examples, the pUID may comprise 14 bits.

[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 standard state pre-personalization. Upon entering the terminated state, one or more applets may be configured to remove personalized data. In the 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 a version of the applet (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 of the versions are configured to interpret the authentication message: for example, with respect to major versions, this may include each major version containing a specific authentication message layout and a specific algorithm. For minor versions, this may not include changes to the authentication message or encryption algorithm, as well as 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 that can indicate the authenticity of the contactless card is presented. Based on 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 data so that the card can be correctly identified. The contactless card may include one or more unique identifiers. The counter may be configured to update each time a read operation occurs. In some examples, each time 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 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 may be a transaction applet. Each applet may include a counter.

[0117] In some examples, the counter may be out of sync between the contactless card and one or more servers. For example, the contactless card may be activated so that the counter is updated and a new communication is generated by the contactless card, but the communication may not be transmitted for processing at one or more servers. 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 stored 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 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 of the device may be turned on to power the contactless card, resulting in the counter therein being updated, but no application on the device receives the communication.

[0118] In order to keep the counter synchronized, an application (such as a background application) can be executed that will be 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 move the counter forward. Since the counter of the contactless card and 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). Moreover, if the counter value exceeds 10 but is below another threshold range value (such as 1000), the one or more servers may be configured to request a gesture associated with the contactless card, such as a user tap. By the user tap, if the counter value is within the expected or acceptable 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 the account identifier and the card serial number to generate two unique derived keys 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 UDK (AUTKEY and ENCKEY) may be stored on the card.

[0120] At box 820, the counter can be used as diversification data, since it changes with each use and provides a different session key each time, rather than a master key derivation where each card produces a unique set of keys. In some examples, it is preferred to use a 4-byte approach for both operations. Thus, at box 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] At block 830, the MAC key may be used to prepare a MAC password and the ENC key may be used to encrypt the password. For example, the MAC session key may be used to prepare the 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 verifying the MAC. The session key is independently derived at 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 that may be associated with the application primary account number (PAN) and PAN serial number encoded in the card are derived. Key diversification can be configured to receive an identifier as input using a master key so that one or more keys can be created for each contactless card. In some examples, these diversified keys may include a first key and a second key. The first key may include an authentication master key (Card 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 (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 a symmetric key that may be used for both encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and 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 on which one or more applets are 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 as background data may be used to identify which issuer master keys 905, 910 are used in the cryptographic process for authentication. The system performing the authentication may be configured to obtain the values ​​of the pNPR 915 and pDKI920 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 for creating a message authentication code (MAC) and for performing 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 945 with 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 include 3DES ECB and MK may include a card-unique 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-KEY 940. The pATC 945 may be initialized to zero at personalization or applet initialization. In some examples, the pATC counter 945 may be initialized at or before personalization and may be configured to increment by one at each NDEF read.

[0130] Further, updates for each card may be unique and may be assigned by personalization, or algorithmically assigned by pUID or other identifying information. For example, odd numbered cards may increment or decrement by 2, and even numbered cards may increment or decrement by 5. In some examples, updates may also vary in sequential reads, 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 according to one or more processes derived from a unique identifier. 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 the MAC of the authentication data may be included. In some examples, the random number may be before the password A and may be one block long. In other examples, there may be no restrictions 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 a 16-byte block, even a multiple of the block size may be used, or the output may be automatically or manually filled 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 to be 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 derived from the session key 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]

[0138]

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

[0140]

[0141]

[0142]

[0143] 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 version, UID, and pATC fields of the message can be processed using the recreated Aut-Session-Key via Cryptogram MAC 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.

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

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

[0146] 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. Moreover, by including the version in one or more passwords, it is difficult for an attacker to purposefully tamper with the application version when attempting to reduce the strength of the password solution. In some examples, the pATC can start from zero and update 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.

[0147] 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 cipher block chaining mode to ensure that an attacker must perform any attack on 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.

[0148] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plain text from 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 be changed in the future; a pUID, used to obtain cryptographic assets and derive card keys; and a pATC, used to derive session keys for the passwords.

[0149] 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 keys are used in a cryptogram process for authentication. In some examples, the method may include performing authentication to obtain the values ​​of the pNPR and pDKI of a contactless card at the time of authentication.

[0150] 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 PAN serial number (PSN) for one or more applets (eg, a payment applet).

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

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

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

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

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

[0156] At block 1130, the sender uses the data integrity session key and the cryptographic MAC algorithm to process the data to be protected using a cryptographic MAC operation. The protected data (including plaintext and shared secret) can generate a MAC using one of the session keys (AUT-Session-Key).

[0157] At block 1140, 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. 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).

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

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

[0160] At box 1170, the session key derived from the data encryption is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing of the exchanged data will then occur. In some examples, after extracting the MAC, 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.

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

[0162] 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 can only be correct if the decryption is successful and produces the correct MAC value. Successful decryption may indicate that the correctly derived encryption key is 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. Moreover, 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.

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

[0164] Example embodiments of the systems and methods described herein may be configured to provide security factor authentication. Security factor authentication may include multiple processes. As part of security factor authentication, a first process may include logging in and verifying a user through one or more applications executed on a device. As a second process, the user may participate in one or more behaviors associated with one or more contactless cards in response to successful login and verification of the first process through one or more applications. In practice, security factor authentication may include securely proving the identity of the user and participating 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 tapping a contactless card on a device by a user. In some examples, the device may include a mobile device, a kiosk, a terminal, a tablet computer, or any other device configured to process a received tap gesture.

[0165] In some examples, the contactless card can be tapped on 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, through 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.

[0166] In some examples, the contactless card can be tapped on 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.

[0167] In some examples, the contactless card can be activated by being tapped on a device such as a mobile device. For example, the contactless card can communicate with the application of the device via the card reader of the device through NFC communication. Wherein the communication of tapping the card near the card reader of the device can allow the application of the device to read the data associated with the contactless card and activate the card. In some examples, activation can authorize the card to perform other functions, such as purchasing, accessing accounts or restricted information or other functions. In some examples, tapping can activate or start the application of the device, and then initiate one or more actions or communications with one or more servers to activate the contactless card. If the application is not installed on the device, tapping the contactless card near the card reader can initiate the download of the application, such as navigating to the download page of the application. After installation, tapping the contactless card can activate or start the application, and then initiate the activation of the contactless card, for example, through 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.

[0168] 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 mini-program, etc. 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 the activation (e.g., a personal computer, a smartphone, 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.

[0169] 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, some 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 denies the transaction may be based on whether the issuer recognizes the transaction value. At the same time, in some embodiments of the present disclosure, transactions originating from a mobile device lack a transaction value associated with the POS system. Therefore, in some embodiments, a pseudo transaction value (i.e., a value that is recognizable to the card issuer and sufficient to allow activation to occur) can be passed as part of the example authentication communication protocol. POS-based transactions can also reject transactions based on the number of transaction attempts (e.g., a transaction counter). The number of attempts exceeding a buffer value may result in a soft rejection; a soft rejection 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.

[0170] In some examples, a contactless card can selectively transmit information based on the recipient device. Once tapped, the contactless card can identify the device that the tap was directed to, and based on this identification, the contactless card can provide the appropriate data for the device. This advantageously allows the contactless card to transmit only the information required to complete an immediate action or transaction (such as payment or card authentication). By limiting data transmission and avoiding unnecessary data transmission, both efficiency and data security can be improved. The identification and selective communication 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.

[0171] 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, such as NFC. Similarly, if a contactless card tap is performed against 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.

[0172] As another example, a contactless card tap can be performed against a POS device, including but not limited to a kiosk, checkout register, 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.

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

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

[0175] 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 app 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.

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

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

[0178] In some examples, data about the tapping behavior can be collected as a biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and not easily intercepted can be 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.

[0179] In some examples, the device may include an application to split a bill or check for payment among multiple individuals. For example, each person may have a contactless card and may be a customer of the same issuing financial institution, but this is not required. Each of these individuals may receive a push notification on their device through the application to split the purchase. Other contactless cards may be used instead of accepting only one card tap to indicate payment. 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.

[0180] The following example use cases describe examples of specific embodiments of the present disclosure. These are intended for explanation purposes only and not for limiting purposes. In one case, a first friend (payer) owes a second friend (payee) a sum of money. The payer wishes to pay using a contactless card through the payee's smartphone (or other device) instead of going to an ATM or needing to redeem through a peer-to-peer application. The payee logs into the appropriate application on his smartphone and selects the payment request option. In response, the application requests authentication through the payee's contactless card. For example, the application outputs a display requesting 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 the contactless card, the application reads the card information and transmits 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.

[0181] 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 through an application on his or her device (e.g., a mobile device such as a smartphone). The customer may select a card activation feature 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 on 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 is then complete.

[0182] Fig.12 A 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.

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

[0184] In box 1220, one or more portions of the dynamically generated data can be transmitted to an application of the device via NFC or other wireless communication. For example, tapping the card near the device can 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 can direct the device or prompt the customer to download the associated application to a software application store to activate the card. In some examples, the user can be prompted to adequately pose, place, or orient the card toward the surface of the device, such as at an angle or flatly placed on, near, or adjacent to the surface of the device. In response to sufficient pose, placement, and / or orientation of the card, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

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

[0186] In block 1240, one or more servers may decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and may decrypt it to compare the received data with recorded data accessible to the one or more servers. If the 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 for calling, emailing, or texting an associated service to help activate the card), or another notification (such as a phone call on his or her device indicating an unsuccessful attempt at card verification and for calling, emailing, or texting an associated service to help activate the card), or another notification (such as an email indicating an unsuccessful attempt at card verification and for calling, emailing, or texting an associated service to help activate the card).

[0187] In 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 the one or more servers indicating successful activation of the card by the one or more servers. The device may be configured to display a message indicating 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.

[0188] In another example, 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 primary account information (e.g., recent purchases) and be able to perform primary account options (e.g., pay a credit card). However, if the user attempts to access secondary account information (e.g., spending limits) or perform secondary account options (e.g., transfer to an external system), he must have secondary identity verification. Therefore, the application requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps his credit card on the mobile device, and the application verifies that the credit card corresponds to the user's account. Thereafter, the user can view secondary account data and / or perform secondary account functions.

[0189] In some embodiments of the present invention, cryptographic authentication of contactless cards can be used to provide further authentication for transactions (including payment transactions). Further authentication can provide additional levels of security for transactions, including but not limited to verifying the presence and approval of authorized users of specific accounts involved in the transaction, thereby creating cryptographic proof of the presence of authorized users for subsequent transaction verification offline, and reducing the possibility of user fraud (e.g., by later claiming that an authorized transaction was not authorized). In addition, further authentication can be provided in various situations while reducing, minimizing, or not requiring other transaction participants (e.g., suppliers, merchants, etc.) to upgrade transaction processing equipment and requirements.

[0190] Fig.13 An example system for such an implementation is shown in FIG. 1300 , which shows a system 1300 using a contactless card. Figure 3 As shown in the system 1300, the system 1300 may include a contactless card 1305, one or more client devices 1310, a network 1315, an authentication server 1320, a merchant server 1325, and a database 1330. Fig.13 A single instance of a component is shown, but system 1300 may include any number of components.

[0191] In some examples, contactless card 1305 can communicate wirelessly with client device 1310, such as NFC or other forms of wireless communication. Contactless card 1305 can refer to Figure 5A and Figure 5B The contactless card 1305 may include the same or similar components as the contactless card shown in FIG. The contactless card 1305 may include a substrate, a processor (e.g., an EMV chip), and a memory. In some examples, the contactless card 1305 may include at least one of a building access card, a credit card, a debit card, an ID card, a loyalty program card, and a transportation card.

[0192] Contactless card 1305 may also include first applet 1306 and second applet 1307. In some examples, first applet 1306 may be a different applet from second applet 1307, and both first applet 1306 and second applet 1307 may each be associated with one or more applet identifiers. In some examples, first applet 1306 may be a payment applet (e.g., a Java Card payment applet) and may be prohibited from communicating with other devices such as client device 1310. In some examples, first applet 1306 may communicate only with second applet 1307, and second applet 1307 may be configured to communicate with client device 1310 or other devices. In these examples, first applet 1306 may provide data to second applet 1307 for communicating with client device 1310 or other devices. In some examples, the second applet 1307 may be a payment applet, such as a Java Card payment applet, or the second applet 1307 may be a security applet, a communication applet, an authentication applet, a cryptographic applet, an adaptation of the foregoing applet, or other applet capable of performing the functions described herein. Fig.13 A first applet 1306 and a second applet 1307 are shown, but it should be understood that the system 1300 may include more than two applet(s), and the features and functions of each of the first applet 1306 and the second applet 1307 may be divided between and performed by multiple applet(s). It should also be understood that additional applet(s) may be included to provide additional functionality.

[0193] In some examples, the second applet 1307 can control when the data provided by the first applet 1306 can be transmitted to the client device 1310 or other device. For example, the second applet 1307 can be configured to allow the communication of data by the first applet 1306 upon completion of an authentication procedure or upon receiving a notification or signal from the authentication server 1320 that the authentication has been completed. Exemplary authentication procedures may include, but are not limited to, bringing the contactless card 1305 into the communication field of the client device 1310, providing access credentials or other identification information (e.g., a password or PIN), generating a password by the methods described herein, completing a second factor authentication, providing biometric information, and other methods described herein, or a combination thereof. The second applet 1307 can perform the authentication procedure and provide information to support the procedure, or the authentication process can be performed by the client device 1310, the authentication server 1320, or a combination thereof. In some examples, the presence of the second applet 1307 on the contactless card 1305 can cause the authentication procedure to begin.

[0194] In some examples, the first applet 1306 can be configured to transmit data directly to the client device 1310 or other device. This communication can be controlled by the second applet 1307, and the second applet 1307 can block the communication performed by the first applet 1306 until the authentication procedure is completed or the authentication notification or authentication signal is received.

[0195] In some examples, client device 1310 may be a computer device or a communication device, including, for example, a server, a network device, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device. Client device 1310 may also be a mobile device; for example, a mobile device may include a computer from iPhone, iPod, iPad or any other mobile device running Apple's iOS operating system, running Microsoft The client device 1310 may be any device running a 1320 Mobile operating system, any device running an Android operating system, and / or any other smartphone or similar wearable mobile device. The client device 1310 may communicate with one or more servers (such as an authentication server 1320 and a merchant server 1325) and a payment terminal 1335 via one or more networks 1315, and may operate as a corresponding front-end to back-end pair with one or more servers. The client device 1310 may, for example, transmit one or more requests to one or more servers from a mobile device application executing on the device 1310. The one or more requests may be associated with obtaining data from one or more servers.

[0196] System 1300 may include one or more networks 1315. In some examples, network 1315 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 1310 to one or more servers. For example, the network 1315 may include a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication (GSM), a Personal Communication Service (PCS), a Personal Area Network, a Wireless Application Protocol (WAP), a Multimedia Messaging Service (MMS), an Enhanced Messaging Service (EMS), a Short Message Service (SMS), a Time Division Multiplexing (TDM)-based system, a Code Division Multiple Access (CDMA)-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, Near Field Communication (NFC), Radio Frequency Identification (RFID), Wi-Fi and / or one or more of the following.

[0197] In addition, the network 1315 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks (WAN), wireless personal area networks, local area networks (LAN), or global networks such as the Internet. In addition, the network 1315 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. The network 1315 may also include a network, or any number of the exemplary types of networks mentioned above that operate as independent networks or in cooperation with each other. The network 1315 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 1315 may convert other protocols to or from other protocols to one or more protocols of network devices. Although the network 1315 is depicted as a single network, it should be understood that, according to one or more examples, the network 1315 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.

[0198] The system 1300 may include one or more servers, such as an authentication server 1320 and a merchant server 1325. In some examples, the one or more servers may include one or more processors coupled to a memory. The one or more servers may be configured as a central system, server, or platform for controlling and calling various data at different times to perform multiple workflow actions in order to perform one or more functions described herein. The one or more servers may contain one or more databases or communicate data with one or more databases. The one or more servers may communicate data with at least one client device 1310.

[0199] System 1300 may include a payment terminal 1335. Payment terminal 1335 may be a server, such as authentication server 1320 or merchant server 1325, or may have a different configuration. Exemplary configurations include, but are not limited to, an electronic payment kiosk, a payment reader, a cash register, or any other device suitable for participating in a transaction. Payment terminal 1335 may communicate data with other components of system 1300, including client device 1310, authentication server 1320, and merchant server 1325, via network 1315.

[0200] System 1300 may include a database 1330. Database 1330 may be a relational or non-relational database, and the data contained by database 1330 may be stored in a single database or in multiple separate databases. Database 1330 may contain, but is not limited to, account and transaction information, identification information, user information, and other information needed to support transactions and perform the functions described herein.

[0201] Fig.14 A flow chart of a method of authenticating a transaction according to an example embodiment is shown, where the method may be implemented, for example, by system 1300. At step 1402, a card transaction is initiated. For example, a card transaction may be initiated when contactless card 1305 is presented at payment terminal 1335 for payment of goods or services, which is a "card present" transaction. Alternatively, a card transaction may be initiated when contactless card 1305 is used for payment in a "card not present transaction," such as when an account number associated with a card is entered on a website to pay for goods or services.

[0202] At step 1404, a transaction request is sent to the authentication server 1320. In the case of a card present transaction, the transaction request may originate from the payment terminal 1335. Alternatively, in the case of a card not present transaction, the transaction request may originate from the client device 1310. The transaction request may initially be sent to the merchant server 1325, i.e., a server belonging to the merchant from which the goods or services are being purchased. The transaction request may then be sent from the merchant server to the authentication server 1320 through one or more intermediaries, such as a bank server or a payment institution server.

[0203] At step 1406, upon receiving the transaction request, the authentication server 1320 determines whether the requested transaction is a high-risk transaction. For example, in the case where the transaction is to be conducted with a merchant associated with a fraudulent transaction, the transaction may be a high-risk transaction. As another example, in the case where the transaction is to be conducted with a merchant located in a geographic area associated with a fraudulent transaction, the transaction may also be a high-risk transaction. Further, if the transaction does not conform to the cardholder's historical transaction pattern and is conducted at an unusual time or unusual geographic area based on the cardholder's transaction history, for example, the transaction may be designated as a high-risk transaction. High-risk transactions may additionally be those transactions conducted with abnormal frequency, or those transactions that occur within a predetermined time period of a large number of other transactions. High-risk transactions may also be those transactions conducted with other accounts, merchants, or others that are known to have fraudulent activities in the past or potential fraudulent past activities. When making a determination, the authentication server 1320 may refer to the cardholder's transaction history stored in the database 1330.

[0204] If at step 1406, the authentication server 1320 determines that the transaction is not a high risk transaction (No), the method proceeds to step 1408. At step 1408, the authentication server 1320 determines whether the value of the transaction exceeds a predetermined threshold. For example, the authentication server 1320 may determine whether the requested transaction exceeds a certain dollar amount. The predetermined threshold may be set by the cardholder, or may be automatically set by the authentication server 1320.

[0205] If, at step 1408 , the authentication server 1320 determines that the value of the transaction does not exceed the predetermined threshold, the method proceeds to step 1418 and the transaction is allowed by the authentication server 1320 .

[0206] However, if at step 1406, the authentication server 1320 determines that the transaction is a high-risk transaction (yes), the method proceeds to step 1410. Likewise, if at step 1408, the authentication server 1320 determines that the value of the transaction exceeds the predetermined value (yes), the method proceeds to step 1410. When the method proceeds to step 1410, the requested transaction is temporarily held, awaiting further authentication.

[0207] At step 1410, the authentication server 1320 sends a request for contactless card authentication to the client device 1310 via the network 1315. The request may be in the form of an in-application notification, a pop-up notification, an SMS message, an email, or any other suitable notification. The request may explain that further authentication is required to conduct the requested transaction, and may further prompt the cardholder to bring the contactless card 1305 into the communication field of the client device 1310.

[0208] For further security, in addition to bringing the contactless card 1305 into the communication field, the authentication server 1320 may additionally request the cardholder to provide biometric information, provide a PIN, provide a password, or provide other identification information to the client device 1310. The client device 1310 may verify the provided biometric information against reference biometric information stored in memory. The biometric information may include, for example, fingerprint information, optical data, facial recognition, and / or retinal information.

[0209] At step 1412 , the cardholder may bring the contactless card 1305 into the communication field of the client device 1310 upon receiving a request for contactless card authentication via the client device 1310 .

[0210] When the contactless card 1305 is in the communication field of the client device 1310, the contactless card 1305 is authenticated. The contactless card 1305 can be authenticated by any of the processes described herein. In some examples, the processor 1311 of the client device 1310 can verify the MAC password generated by the contactless card 1305. The processor 1311 can then communicate to the authentication server 1320 that the contactless card 1305 has been authenticated. Alternatively, the MAC password generated by the contactless card can be transmitted to the authentication server 1320 for verification.

[0211] If at step 1414, the contactless card is not authenticated (No), then authentication server 1320 denies the requested transaction at step 1416, thereby prohibiting the transaction from being performed. When the transaction is denied, authentication server 1320 may additionally transmit a notification to client device 1310 informing the cardholder that the transaction has been denied. The method then ends.

[0212] If the contactless card is authenticated (YES) at step 1414, authentication server 1320 allows the transaction at step 1418. When the transaction is allowed, authentication server 1320 may additionally transmit a notification to client device 1310 informing the cardholder that the transaction has been approved. The method then ends.

[0213] The system 1300 and method 1400 described herein provide improved security for transactions using contactless cards. Specifically, requiring password authentication using a contactless card and a client device can prevent situations where a cardholder loses her contactless card, the contactless card is stolen, or the information printed on the contactless card is stolen. By requiring password authentication, in addition to providing a contactless card, a person attempting to participate in a transaction must essentially prove that she also has a client device associated with the contactless card, and further prove that she can access the client device (i.e., can use a PIN, password, or biometric unlock). This reduces the possibility that the contactless card is used for fraudulent purposes. Additionally, password authentication may only be required for transactions that are high-risk transactions or for proposals for amounts exceeding a predetermined value, so that the cardholder does not burden an additional authentication layer for each transaction. Another advantage of the system 1300 and method 1400 is that security features are incorporated into the contactless card, and the use of the contactless card itself allows the security features described herein to be provided without modifying other components of the system.

[0214] In addition, requiring password authentication need not be limited to transactions in which contactless cards are used to pay for goods or services. The method 1400 described herein can be similarly applied to providing contactless cards. For example, if a cardholder attempts to provide a contactless card for an online payment service, such as Google Pay or Apple Pay, password authentication may similarly be required to verify that the person attempting to provide the contactless card actually possesses the contactless card, rather than simply using the information printed on the card. This can provide security for the use of contactless cards by individuals who may have obtained the card number, CVC, and expiration date through illegal means but do not actually possess the contactless card.

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

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

[0217] In this specification, many specific details have been set forth. However, it should be understood that the disclosed technology can be implemented without these specific details. In other cases, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this specification. References to "some examples", "other examples", "one example", "example", "various examples", "one embodiment", "embodiment", "some embodiments", "example embodiments", "various embodiments", "an implementation", "example implementation", "various implementations", "some implementations", etc. indicate 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 specific features, structures or characteristics. Further, the repeated use of the phrase "in an example", "in an embodiment" or "in an implementation" does not necessarily refer to the same example, embodiment or implementation, although it may refer to the same example, embodiment or implementation.

[0218] As used herein, unless otherwise specified, the use of ordinal adjectives "first," "second," "third," etc. to describe common objects merely indicates that different instances of similar objects are referred to and are not intended to mean that the objects so described must be in a given order temporally, spatially, hierarchically, or in any other manner.

[0219] Although some embodiments of the disclosed technology have been described in conjunction with various embodiments currently considered to be the most practical, it should be understood that the disclosed technology is not limited to the disclosed embodiments, but on the contrary, 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 descriptive sense and not for the purpose of limitation.

[0220] This written description uses examples to disclose some embodiments of the disclosed technology (including the best mode), and also enables any person skilled in the art to practice some embodiments of the disclosed technology, including making and using any device or system and performing any combined method. The patentable scope of some 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 structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements that do not differ substantially from the literal language of the claims.

Claims

1. An authentication system, comprising: Contactless card and authentication server, Wherein, the authentication server is configured as: identifying a transaction associated with a transaction request involving a user account, the transaction request being received by the authentication server from a merchant server, Identify the transaction as high risk, sending an authentication request to a client device associated with the user account, receiving a password from the client device in response to the authentication request, the password being received by the client device from the contactless card, verifying the password based on the session key using an encryption algorithm, and The transaction is authorized based on the verified password.

2. The authentication system according to claim 1, wherein the authentication server is further configured to: generating an authenticated diversified key based on the master key and the unique identifier, and The session key is generated based on the authentication diversified key. 3 . The authentication system of claim 1 , wherein the transaction is identified as high risk based on a comparison of the transaction to historical transaction patterns for the user account.

4. The authentication system according to claim 3, wherein: The transactions were conducted at times inconsistent with the historical trading patterns.

5. The authentication system according to claim 3, wherein: The transactions were conducted in geographic areas that are inconsistent with the historical transaction patterns.

6. The authentication system of claim 1, wherein the transaction is identified as high risk based on the merchant's association with fraudulent transactions.

7. The authentication system according to claim 1, wherein: identifying the transaction as high risk based on the location of the merchant, and The merchant is located in a geographic area associated with fraudulent transactions.

8. The authentication system according to claim 1, wherein: The password is generated by the contactless card and received by the client device using near field communication (NFC).

9. The authentication system according to claim 1, wherein: The authentication server is further configured to send a second authentication request for at least one selected from the group consisting of biometric information and a password, and The authentication server is further configured to delay the transaction pending the authentication request.

10. The authentication system according to claim 1, wherein the authentication server is further configured to: before sending the authentication request, comparing the value of the transaction to a threshold, and If the value of the transaction exceeds the threshold, the authentication request is sent.

11. A method for performing secure electronic authentication using a contactless card, the method comprising: identifying, by a processor of an authentication server, a transaction associated with a transaction request involving a user account, the transaction request received by the authentication server from a merchant server; identifying, by the processor of the authentication server, the transaction as high risk; The processor of the authentication server sends an authentication request to a client device in wireless communication with the contactless card, wherein the authentication request prompts the contactless card to enter a communication field of the client device; receiving, by the processor of the authentication server in response to the authentication request, a password generated by the contactless card, wherein the password is sent to the processor of the authentication server via the client device; verifying, by the processor of the authentication server, the password based on a session key using an encryption algorithm; as well as The transaction is authorized by the processor of the authentication server based on the verified password.

12. The method according to claim 11, further comprising: generating, by the processor of the authentication server, an authentication diversification key based on a master key and a unique identifier; as well as The session key is generated by the processor of the authentication server based on the authentication diversified key.

13. The method of claim 11, further comprising sending, by the processor of the authentication server, a second authentication request for at least one selected from the group consisting of biometric information and a password.

14. The method of claim 11, further comprising delaying, by the processor of the authentication server, the transaction pending the authentication request.

15. The method of claim 11, wherein identifying the transaction as high risk comprises: comparing, by the processor of the authentication server, the transaction with a historical transaction pattern for the account, and A determination is made, by the processor of the authentication server, that the transaction was conducted at a time inconsistent with the historical transaction pattern.

16. The method of claim 11, wherein identifying the transaction as high risk comprises: comparing, by the processor of the authentication server, the transaction with a historical transaction pattern for the account, and A determination is made, by the processor of the authentication server, that the transaction was conducted in a geographic area that is inconsistent with the historical transaction pattern.

17. An authentication server, comprising: processor, Wherein, the processor is configured to: identifying a transaction associated with a transaction request involving a user account, the transaction request received by the processor from a merchant server, Identify the transaction as high risk, sending an authentication request to a client device associated with the user account, receiving a password from the client device in response to the authentication request, the password being received by the client device from a contactless card present in a communication field of the client device, verifying the password based on the session key using an encryption algorithm, and The transaction is authorized based on the verified password.

18. The authentication server according to claim 17, wherein the processor is further configured to: generating an authenticated diversified key based on the master key and the unique identifier, and The session key is generated based on the authentication diversified key.

19. The authentication server of claim 17, wherein the transaction is identified as high risk based on the merchant's association with fraudulent transactions.

20. The authentication server according to claim 17, wherein: identifying the transaction as high risk based on the location of the merchant, and The merchant is located in a geographic area associated with fraudulent transactions.

Images