System and method for password authentication for contactless cards

Abstract

Example embodiments of systems and methods for data transmission between a transmitting device and a receiving device are provided. In embodiments, the method includes generating a diversification key; generating an encryption result including a counter value; encrypting transmission data to produce encrypted transmission data; transmitting the encryption result and the encrypted transmission data to an application; generating an authentication diversification key; generating a session key; decrypting the encrypted transmission data and verifying the received encryption result; and upon authenticating at least one user credential, initiating one or more processes including authenticating one or more electronically generated images associated with transit ticketing information.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 351,429, filed March 12, 2019 (which is a partial continuation of and claims priority to U.S. Patent Application No. 16 / 205,119, filed November 29, 2018), and to U.S. Provisional Patent Application No. 62 / 740,352, filed October 2, 2018, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

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

[0004] Data security and transaction integrity are critical to businesses and consumers. This need continues to grow as electronic transactions constitute an increasingly larger share of commercial activity.

[0005] Email can be used to verify transactions, but it is vulnerable to attack and can be compromised by hackers or other unauthorized access. Short message services (SMS) can also be used, but these are also susceptible to compromise. Furthermore, even data encryption algorithms such as Triple DES have similar vulnerabilities.

[0006] Activating many cards (including debit cards such as credit cards and other payment cards) involves a time-consuming process where the cardholder makes a phone call or visits a website and enters or otherwise provides card information. Furthermore, while the increasing use of chip-based debit cards offers enhanced security for personal purchases compared to previous technologies (e.g., magnetic stripe cards), account access may still rely on login credentials (e.g., username and password) to verify the cardholder's identity. However, if login credentials are compromised, another person could gain access to that user's account.

[0007] These and other shortcomings exist. Therefore, appropriate solutions are needed to overcome these deficiencies, thereby providing data security, authentication, and verification for contactless cards. Furthermore, improved methods for card activation and improved authentication for account access are required. Summary of the Invention

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

[0009] Embodiments of this disclosure provide: a transmitting device having a processor and a memory, the memory of the transmitting device containing a diversified master key, transmitted data, and a counter value; an application including instructions for execution on a receiving device having a processor and a memory, the memory of the receiving device containing the master key; wherein the transmitting device is configured to: generate a diversified key using the diversified master key, one or more encryption algorithms, and the counter value; generate an encryption result including the counter value using one or more encryption algorithms and the diversified key; encrypt the transmitted data using one or more encryption algorithms and the diversified key to produce encrypted transmitted data; and transmit the encrypted result and the encrypted transmitted data to the application; and wherein the application is configured to: generate an authentication diversified key based on the master key and a unique identifier; generate a session key based on the authentication diversified key and the encryption result; decrypt the encrypted transmitted data using one or more encryption algorithms and the session key and verify the received encryption result; wherein the application is configured to initiate one or more processes when authenticating at least one user credential, the one or more processes including authenticating one or more electronically generated images associated with transportation ticketing information.

[0010] Embodiments of this disclosure provide a method for protecting one or more processes using a transmitting device and an application including instructions for execution on a receiving device. The method includes the steps of: generating a diversified key using a diversified master key, one or more encryption algorithms, and a counter value; the transmitting device including a processor and a memory, the memory of which contains the diversified master key, transmission data, and the counter value; generating an encrypted result including the counter value using one or more encryption algorithms and the diversified key; encrypting the transmission data using one or more encryption algorithms and the diversified key to produce encrypted transmission data; transmitting the encrypted result and the encrypted transmission data to an application including instructions for execution on the receiving device; generating an authentication diversified key based on the master key and a unique identifier; generating a session key based on the authentication diversified key and the encryption result; decrypting the encrypted transmission data using one or more encryption algorithms and the session key and verifying the received encryption result; and initiating one or more processes, including authenticating one or more electronically generated images associated with transportation ticketing information, when authenticating at least one user credential.

[0011] In the following, further features of the disclosed design and the advantages therefrom will be explained in more detail with reference to specific exemplary embodiments shown in the accompanying drawings, wherein like elements are indicated by like reference numerals. Attached Figure Description

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

[0013] Figure 1BThis is a diagram illustrating a sequence for providing authenticated access according to an example embodiment.

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

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

[0016] Figure 4 This is a flowchart illustrating a method for key diversification according to an example embodiment.

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

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

[0019] Figure 6 This is an illustration depicting messages used for communicating with a device according to an example embodiment.

[0020] Figure 7 This is an illustration depicting messages and message formats according to an example embodiment.

[0021] Figure 8 This is a flowchart illustrating key operations according to an example embodiment.

[0022] Figure 9 This is a diagram of a key system according to an example embodiment.

[0023] Figure 10 This is a flowchart of a method for generating a password according to an example embodiment.

[0024] Figure 11 This is a flowchart illustrating the key diversification process according to an example embodiment.

[0025] Figure 12 This is a flowchart illustrating a method for card activation according to an example embodiment.

[0026] Figure 13 This is a flowchart illustrating a method for authenticating contactless cards according to an example embodiment.

[0027] Figure 14 This is a flowchart illustrating a method for authenticating contactless cards according to an example embodiment. Detailed Implementation

[0028] 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 invention. The described embodiments should be considered as being able to be practiced separately or in combination with other embodiments described from the embodiments. Those skilled in the art who consult the description of the embodiments should be able to learn and understand the different described aspects of the invention. The description of the embodiments should help to understand the invention to such an extent that other implementations not specifically covered but within the knowledge of those skilled in the art who have read the description of the embodiments will be understood to be consistent with the application of the invention.

[0029] The purpose of some embodiments of this 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 would otherwise require the user to carry a separate physical token in addition to the contactless card itself. 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 sufficient to satisfy... Operating system, but for This presents a challenge, The use of near field communication (NFC) is more restricted because it can only be used in read-only mode. The example embodiments of contactless cards described in this article utilize NFC technology.

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

[0031] System 100 may include one or more contactless cards 105, which will be referred to below. Figures 5A to 5B Further explanation. In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110 using NFC, as in the example.

[0032] 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, computer equipment or communication equipment, including, for example, servers, network equipment, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, thick clients, internet browsers, or other devices. Client device 110 may also be a mobile device; for example, a mobile device may include devices from... iPhone, iPod, iPad, or running Apple products Any other mobile device running the operating system, or running Microsoft... Any device running the Mobile operating system, or running Google... Any device with an operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0033] Client device 110 may include a processor and memory, and it should be understood that the processing circuitry may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware. Client device 110 may also include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any device available and supported by the user device for inputting information into the user, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or portable video camera. These devices can be used to input information and interact with the software and other devices described herein.

[0034] In some examples, the client device 110 of system 100 may execute one or more applications, such as software applications, that implement network communication with one or more components of system 100 and transmit and / or receive data.

[0035] Client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a corresponding front-end to back-end pair with server 120. Client device 110 can, for example, transmit one or more requests to server 120 from a mobile device application running on client device 110. The one or more requests can be associated with retrieving data from server 120. Server 120 can receive one or more requests from client device 110. Based on the one or more requests from client device 110, server 120 can be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, server 120 can be configured to transmit the received data to client device 110 in response to the one or more requests.

[0036] System 100 may include one or more networks 115. In some examples, network 115 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 devices 110 to server 120. For example, network 115 may include a fiber optic network, a passive optical network, a cable network, the Internet, a satellite network, a wireless local area network (LAN), Global System for Mobile Communications (GSMO), a personal communications service, a personal area network (PAN), a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service (SMS), 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 one or more of the following.

[0037] Furthermore, network 115 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 115 may support the Internet, wireless communication networks, cellular networks, or any combination thereof. Network 115 may also include a single network, or any number of networks of the exemplary types mentioned above operating as independent networks or cooperating with each other. Network 115 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 115 may convert or convert other protocols to one or more protocols of network devices. Although network 115 is depicted as a single network, it should be understood that, according to one or more examples, network 115 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

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

[0039] Figure 1B This is a timing diagram illustrating example sequences for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may include a contactless card 105 and a client device 110, which may include an application 122 and a processor 124. Figure 1B Possible references include: Figure 1A Similar components are shown.

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

[0041] 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) cipher. In some examples, this may occur when the contactless card 105 is read by the application 122. Specifically, this can 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 application 122 can transmit a message (such as a mini-program selection message) with a mini-program ID that generates the NDEF. After confirming the selection, a sequence of selected file messages, followed by a file read message, can be transmitted. For example, the sequence may 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 may include a header and a shared secret can be generated. A session key can then be generated. The MAC cipher can be created based on the message, which may include a header and a shared secret. The MAC cipher can then be concatenated with one or more random data blocks, and the MAC cipher and the random number (RND) can be encrypted using a session key. Afterward, the cipher and header can be concatenated, encoded into ASCII hexadecimal, and returned in NDEF message format (in response to the "Read NDEF File" message).

[0042] In some examples, the MAC cipher may be transmitted as an NDEF label, and in other examples, the MAC cipher may be included along with a Uniform Resource Indicator (e.g., as a formatted string).

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

[0044] At step 106, the contactless card 105 sends a MAC password to the application 122. In some examples, the transmission of the MAC password occurs via NFC; however, this disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth, Wi-Fi, or other wireless data communication methods.

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

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

[0047] In some examples, MAC password verification can be performed by devices other than client device 110 (such as server 120, which communicates with client device 110). Figure 1A As shown) to perform. For example, processor 124 can output the MAC password for transmission to server 120, which can verify the MAC password.

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

[0049] Figure 2 A data transmission system according to an example embodiment is illustrated. System 200 may include, for example, a transmitting device 205 and a receiving device 210 communicating with one or more servers 220 via a network 215. The transmitting device 205 may be related to the above-referenced... Figure 1A The client device 110 discussed is the same as or similar to the one mentioned above. The receiving device 210 can be the same as the one mentioned above. Figure 1A The client device 110 discussed is the same as or similar to the one mentioned above. Network 215 may be similar to the one mentioned above. Figure 1A The discussion focuses on network 115. Server 220 can be similar to the reference above. Figure 1A The server being discussed is 120. Although... Figure 2 A single instance of the components of system 200 is shown, but system 200 may include any number of the components shown.

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

[0051] Equally important is that the same key is not used too many times. If a key is used or reused too frequently, it may be compromised. Each time the 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 possesses that has been processed with the same key, the greater the likelihood that the attacker will discover the key's value. Frequently used keys can be included in a variety of different attacks.

[0052] Furthermore, each execution of a symmetric encryption algorithm may reveal information about the key used during the symmetric encryption operation, such as side-channel data. Side-channel data can include minute power fluctuations that occur during the execution of the encryption algorithm while the key is being used. Sufficient measurements of the side-channel data can 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.

[0053] However, by limiting the number of times a specific key will be used, the amount of sidechannel data an attacker can collect is limited, thus reducing exposure to this type of attack and others. As further described herein, the parties involved in the exchange of cryptographic information (e.g., sender and receiver) can independently generate keys based on an initial shared master symmetric key, combining counter values, and thus periodically replace the shared symmetric key 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 receiver, the attacks described above become impossible.

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

[0055] System 200 may include one or more networks 215. In some examples, network 215 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 one or more transmitting devices 205 and one or more receiving devices 210 to server 220. For example, network 215 may include fiber optic networks, passive optical networks, cable networks, the Internet, satellite networks, wireless LANs, Global System for Mobile Communications (GSMO), personal communication services, personal area networks (PANs), wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time-division multiplexing-based systems, code-division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi and / or one or more others.

[0056] Furthermore, network 215 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 215 may support the Internet, wireless communication networks, cellular networks, or any combination thereof. Network 215 may also include a single network, or any number of networks of the exemplary types mentioned above operating as independent networks or cooperating with each other. Network 215 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 215 may convert or convert other protocols into one or more protocols of network devices. Although network 215 is depicted as a single network, it should be understood that, according to one or more examples, network 215 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

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

[0058] At box 225, when the sending device 205 is ready to process sensitive data using symmetric encryption, the sender can update the counter. Furthermore, the sending device 205 can select an appropriate symmetric encryption algorithm, which may include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process diverse values ​​may include any symmetric encryption algorithm used to generate diverse symmetric keys 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), 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 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 generate a sufficiently long key.

[0059] At box 230, the sending device 205 can employ a selected encryption algorithm and use a master symmetric key to process the counter value. For example, the sender can choose 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 can then use the master symmetric key to encrypt the counter value using the selected symmetric encryption algorithm, thereby creating a diversified symmetric key.

[0060] In some examples, the counter value may be unencrypted. In these examples, the counter value may be transmitted between the sending device 205 and the receiving device 210 without encryption at box 230.

[0061] At box 235, a diversified symmetric key can be used to process sensitive data before transmitting the result to receiving device 210. For example, transmitting device 205 can use the diversified symmetric key to encrypt sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. Transmitting device 205 can then transmit the protected encrypted data along with a counter value to receiving device 210 for processing.

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

[0063] At box 245, receiving device 210 can then acquire the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm and a variety of symmetric keys.

[0064] At box 250, the original sensitive data can be displayed as a result of decrypting the protected encrypted data.

[0065] When sensitive data needs to be sent from the sender to the receiver via the corresponding sending device 205 and receiving device 210, different counter values ​​can be selected to generate different diversified symmetric keys. By using the master symmetric key and the same symmetric encryption algorithm to process the counter values, both sending device 205 and receiving device 210 can independently generate the same diversified symmetric key. This diversified symmetric key (instead of the master symmetric key) is used to protect sensitive data.

[0066] As explained above, both transmitting device 205 and receiving device 210 initially possess a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Because the diversification symmetric key is created independently by both transmitting device 205 and receiving device 210, it is never transmitted between them. Therefore, an attacker cannot intercept the diversification symmetric key, and an attacker will never see any data processed using the master symmetric key. Only counter values ​​are processed using the master symmetric key, while sensitive data is not. As a result, reduced side-channel data is presented regarding the master symmetric key. Furthermore, the operation of transmitting device 205 and receiving device 210 can be controlled by the symmetric requirement of how often a new diversification value is created and thus a new diversification symmetric key is created. In an embodiment, a new diversification value and thus a new diversification symmetric key can be created for each exchange between transmitting device 205 and receiving device 210.

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

[0068] 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 system and process described herein. New diversification values ​​can be created whenever needed, and thus new diversified symmetric keys can be created. In the most secure scenario, a new diversification value can be created for each exchange of sensitive data between sending device 205 and receiving device 210. In practice, this could potentially create one-time-use keys, such as single-use session keys.

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

[0070] System 300 may include one or more contactless cards 305, which will be referred to below. Figures 5A to 5B Further explanation. In some examples, the contactless card 305 can wirelessly communicate with the client device 310, such as via NFC communication. For example, the contactless card 305 may include one or more chips, such as RFID chips, configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 305 may 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 may be configured to communicate with the reader 313 of the client device 310 via NFC when the contactless card 305 is within range of the reader 313. In other examples, communication with the contactless card 305 may be implemented via a physical interface, such as a Universal Serial Bus interface or a card swipe interface.

[0071] System 300 may include client device 310, which may be a network-enabled computer. As described herein, a network-enabled computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, network equipment, personal computers, workstations, mobile devices, telephones, handheld PCs, personal digital assistants, thin clients, thick clients, internet browsers, or other devices. One or more client devices 310 may also be mobile devices; for example, mobile devices may include devices from... iPhone, iPod, iPad, or running Apple products Any other mobile device running the operating system, or running Microsoft... Any device running the Mobile operating system, or running Google... Any device with an operating system, and / or any other smartphone or similar wearable mobile device. In some examples, client device 310 may be compatible with reference... Figure 1A or Figure 1B The client device described is the same as or similar to 110.

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

[0073] System 300 may include one or more Hardware Security Modules (HSMs) 330. For example, one or more HSMs 330 may be configured to perform one or more cryptographic operations disclosed herein. In some examples, one or more HSMs 330 may be configured as dedicated security devices configured to perform one or more cryptographic operations. HSMs 330 may be configured such that keys are never disclosed outside the HSM 330, but instead remain within the HSM 330. For example, one or more HSMs 330 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 330 may be included within servers 320 and 325, or may communicate with servers 320 and 325.

[0074] 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 wireless and wired networks, and may be configured to connect client device 315 to servers 320 and 325. For example, network 315 may include one or more of the following: fiber optic network, passive optical network, cable network, cellular network, Internet, satellite network, wireless LAN, Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi and / or any combination of their networks. As a non-limiting example, communication from contactless card 305 and client device 310 may include NFC communication, cellular network communication between client device 310 and operator, and Internet communication between operator and backend.

[0075] Furthermore, network 315 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. Additionally, network 315 may support the Internet, wireless communication networks, cellular networks, or any combination thereof. Network 315 may also include a single network, or any number of the aforementioned exemplary types of networks operating as independent networks or cooperating with each other. Network 315 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 315 may convert or convert other protocols into one or more protocols of network devices. Although network 315 is depicted as a single network, it should be understood that, according to one or more examples, network 315 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

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

[0077] Application 311 of any of the client devices 310 can communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). Application 311 can 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 those skilled in the art will understand that a distance of less than twenty centimeters is consistent with the NFC range.

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

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

[0080] According to some embodiments, the contactless card 305 may include a virtual payment card. In those embodiments, the application 311 can retrieve information associated with the contactless card 305 by accessing a digital wallet implemented on the 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.

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

[0082] Figure 4 A method 400 for key diversification according to an example of this disclosure is shown. Method 400 may include methods similar to... Figure 2 The transmitting device 205 and the receiving device 210 mentioned in the text refer to the transmitting device and the receiving device.

[0083] For example, a sender and a receiver may expect to exchange data (e.g., raw sensitive data) via a sending device and a receiving device. As mentioned above, although both parties may be involved, 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. Furthermore, it should be understood that either party or device holding the same secret symmetric key can perform the functions of the sending device, and similarly, either party holding the same secret symmetric key can perform the functions of the receiving device. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties except the sending device and the receiving device involved in exchanging secure data. It should also be understood that both the sending device and the receiving device may be provided with the same master symmetric key, and 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 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.

[0084] At box 410, the sending and receiving devices 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 encryption operations, the sender may update a counter. Furthermore, the sending device may select an appropriate symmetric encryption algorithm, which may include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process diverse values ​​may include any symmetric encryption algorithm used to generate diverse symmetric keys 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), 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 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 generate a sufficiently long key.

[0085] The sending device can employ a chosen encryption algorithm and use a master symmetric key to process the counter value. For example, the sender can choose a symmetric encryption algorithm and use a counter that is updated with each conversation between the sending and receiving devices.

[0086] At box 420, the transmitting device can then use the master symmetric key to encrypt the counter value using a selected symmetric encryption algorithm, thereby creating a diversified symmetric key. The diversified symmetric key can be used to process sensitive data before transmitting the result to the receiving device. For example, the transmitting device can use the diversified symmetric key to encrypt sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. The transmitting device can then transmit the protected encrypted data along with the counter value to the receiving device for processing. In some examples, encryption operations other than encryption can be performed, and multiple encryption operations can be performed using the diversified symmetric key before transmitting the protected data.

[0087] In some examples, the counter value may be unencrypted. In these examples, the counter value can be transmitted between the sending and receiving devices without encryption at box 420.

[0088] At box 430, one or more encryption algorithms and diversification keys can be used to protect sensitive data. A diversification session key (which can be created by diversifying the key using a counter) can be used with one or more encryption algorithms to protect sensitive data. For example, data can be processed by the MAC using a first diversification session key, and the resulting output can be encrypted using a second diversification session key to produce protected data.

[0089] At box 440, the receiving device can perform the same symmetric encryption using a counter value as input and a master symmetric key as the encryption key. The encrypted output can be the same diversified symmetric key value created by the sender. For example, the receiving device can independently create its own copies of a first diversified session key and a second diversified session key using the counter. The receiving device can then use the second diversified session key to decrypt the protected data, revealing the output of the MAC created by the sending device. The receiving device can then process the final data using the first diversified session key via MAC operations.

[0090] At box 450, the receiving device can use a variety of keys with one or more encryption algorithms to verify the protected data.

[0091] At box 460, the original data can be verified. If the output of the MAC operation (via the receiving device using the first diversified session key) matches the MAC output revealed through decryption, the data can be considered valid.

[0092] 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 using the master symmetric key and the same symmetric encryption algorithm to process the counter value, both the sending and receiving devices can independently generate the same diversified symmetric key. This diversified symmetric key (instead of the master symmetric key) is used to protect the sensitive data.

[0093] As explained above, both the sending and receiving devices initially possess a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Because the diversification symmetric key is created independently by both the sending and receiving devices, it is never transmitted between them. Therefore, an attacker cannot intercept the diversification symmetric key, and an attacker will never see any data processed using the master symmetric key. Only smaller counter values ​​are processed using the master symmetric key, while sensitive data is not. As a result, reduced side-channel data is presented regarding the master symmetric key. Furthermore, the sender and receiver can, for example, agree on how often to create new diversification values ​​and thus new diversification symmetric keys through prior arrangement or other means. In an embodiment, a new diversification value and thus a new diversification symmetric key can be created for each exchange between the sending and receiving devices.

[0094] 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 diversification key is needed, sent from the sending device to the receiving device; the full value of a counter value sent from both the sending and receiving devices; a portion of a counter value sent from both the sending and receiving devices; a counter maintained independently by the sending and receiving devices but not sent between the two devices; a one-time passcode exchanged between the sending and receiving devices; and a cryptographic hash of sensitive data. In some examples, multiple diversification keys can be created by parties using one or more portions of the key diversification value. For example, a counter can be used as the key diversification value.

[0095] In another example, a portion of the counter can be used as a key diversification value. If multiple master key values ​​are shared among the parties, multiple diversified key values ​​can be obtained through the system and process described herein. New diversification values ​​can be created whenever needed, and thus new diversified symmetric keys can be created. In the most secure scenario, new diversification values ​​can be created for each exchange of sensitive data between the sending and receiving devices. In practice, this could potentially create one-time-use keys, such as a single session key.

[0096] In other examples, such as to limit the number of times the master symmetric key is used, a new diversification value can be agreed upon by the sender at the transmitting device and the receiver at the receiving device, and thus the new diversification symmetric key will only occur periodically. In one example, this could be after a predetermined number of uses (such as every 10 transmissions between the sending and receiving devices). In another example, this could be after a certain period of time, after a transmission, or periodically (e.g., daily at a specified time; weekly at a specified time on a specified date). In yet another example, this could be whenever the receiving device signals to the sending device that it expects to change the key in the next communication. This can be controlled according to a policy and can vary due to, for example, the current level of risk perceived by the receiver at the receiving device.

[0097] Figure 5AOne or more contactless cards 500 are shown, which may include payment cards, such as credit cards, debit cards, or gift cards, issued by a service provider 505 displayed on the front or back of the card 500. In some examples, the contactless card 500 is not a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 500 may include a substrate 510, which may include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical properties conforming 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 the contactless card 500 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of contactless cards in payment cards.

[0098] 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 a connection with another communication device, such as a user equipment, smartphone, laptop, desktop computer, or tablet computer. The contactless card 500 may also include processing circuitry, an antenna, and... Figure 5A Other components not shown. These components may be located behind the contact pad 520 or elsewhere on the base 510. The contactless card 500 may also include components that can be located on the back of the card ( Figure 5A (not shown) magnetic strips or magnetic tapes.

[0099] like Figure 5B As shown, Figure 5A The contact pad 520 may include processing circuitry 525 for storing and processing information, which includes a microprocessor 530 and a memory 535. It should be understood that the processing circuitry 525 may include 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 tamper-proof hardware.

[0100] Memory 535 can be read-only memory, write-once-read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 500 can include one or more of these memories. Read-only memory can be factory-programmable or one-time programmable memory. One-time programmability provides the opportunity to write once and then read many times. Write-once / read-many memory can be programmed at some point after the memory chip has left the factory. Once programmed, the memory may not be rewritten, but it may be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

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

[0102] The processor and storage elements of the foregoing exemplary embodiments have been described with reference to the contact pad, but this 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 besides the processor 530 and memory 535 elements located within the contact pad 520.

[0103] 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 surrounding the processing circuitry 525 of the contact pad 520. For example, the one or more antennas 555 may be integrated with the processing circuitry 525, and the one or more antennas 555 may be used in conjunction with an external boost coil. As another example, the one or more antennas 555 may be external to the contact pad 520 and the processing circuitry 525.

[0104] In this 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 disconnecting power or by amplitude modulation. The contactless card 500 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained 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.

[0105] As explained above, the contactless card 500 can be built on a software platform that operates on smart cards or other devices with limited memory, such as JavaCards, and can securely execute one or more applications or applets. Applets can be added to the contactless card to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The appletter 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 that includes an encrypted and secure OTP encoded as an NDEF text tag.

[0106] Figure 6 A short NDEF record layout (SR=1) 600 according to an example embodiment is shown. One or more applets can be configured to encode OTP as NDEF type 4 (well-known type text tag). In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, encoded English (en), applet ID: D2760000850101; 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 can be used to generate the NDEF message. In an embodiment, the authentication template may include a first record having a well-known index for providing actual dynamic authentication data.

[0107] Figure 7Message 710 and message format 720 according to an example embodiment are shown. In one example, if an additional tag is to be added, the first byte can be changed to indicate the start of the message instead of the end, and subsequent records can 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; exported AUT session key (using 0x00000050); version 1.0; pATC = 0x00000050; RND = 4838FB7DC171B89E; MAC = <eight computed bytes>.

[0108] In some examples, data can be stored on the contactless card during personalization by implementing Stored Data (E2) under Secure Channel Protocol 2. One or more values ​​can be read by the personalization bureau from an EMBOSS file (in the section specified by the applet ID), and one or more Stored Data commands can be transferred to the contactless card after authentication and secure channel establishment.

[0109] A pUID can be a 16-bit BCD-encoded number. In some examples, a pUID can be 14 bits.

[0110]

[0111] In some examples, one or more mini-programs can be configured to maintain their personalized state, allowing personalization only when unlocked and authenticated. Other states may include the standard pre-personalized state. Upon entering the terminated state, one or more mini-programs can be configured to remove personalized data. In the terminated state, one or more mini-programs can be configured to stop responding to all application protocol data unit (APDU) requests.

[0112] One or more mini-applications can be configured to maintain a mini-program version (2 bytes) that can be used in authentication messages. In some examples, this can be interpreted as a most significant byte for the major version and a least significant byte for the minor version. The rules for each version are configured to interpret the authentication message: for example, regarding the major version, this could include each major version containing a specific authentication message layout and a specific algorithm. For minor versions, this might not include changes to the authentication message or encryption algorithm, or changes to static tag content, except for bug fixes, security enhancements, etc.

[0113] In some examples, one or more applets can be configured to emulate RFID tags. RFID tags can include one or more polymorphic tags. In some examples, each time a tag is read, different encrypted data is presented that can indicate the authenticity of the contactless card. Based on one or more applications, NFC reading of the tags can be handled, tokens can be transmitted to a server such as a backend server, and the tokens can be verified at the server.

[0114] In some examples, the contactless card and server may include data that allows the card to be correctly identified. The contactless card may include one or more unique identifiers. A counter may be configured to be updated each time a read operation occurs. In some examples, each time the card is read, it is transmitted to the server for verification, and the server determines whether the counters are equal (as part of the verification process).

[0115] One or more counters can be configured to prevent replay attacks. For example, if a PIN has been obtained and replayed, the PIN is immediately rejected if the counter has been read, used, or otherwise ignored. If the counter is not 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, where the first applet may be a transaction applet. Each applet may include a counter.

[0116] In some examples, the counter may become out of sync between the contactless card and one or more servers. For instance, the contactless card may be activated, causing the counter to be updated and new communications to be generated by the contactless card, but these communications may not be transmitted for processing at one or more servers. This can cause the contactless card's counter to become out of sync with the counters maintained at one or more servers. This can happen unintentionally, including, for example, when the card is stored near a device (e.g., carried in a bag with the device), and when the contactless card is read at an angle, possibly including misalignment or mispositioning of the card so that it is powered on but not readable in the NFC field. If the contactless card is positioned near a device, the device's NFC field can be turned on to power the contactless card, causing the counter thereto be updated, but no application on the device receives the communications.

[0117] To keep the counters synchronized, an application (such as a background application) can be executed. This application would be configured to detect when the mobile device wakes up and synchronize with one or more servers that indicate a read due to the detection, then advance the counters. Since the contactless card counter and one or more servers may become out of sync, one or more servers can be configured to allow the contactless card counter to be updated a threshold number or a predetermined number of times before it is read by one or more servers and is still considered valid. For example, if the counter is configured to increment (or decrement) by 1 for each occurrence indicating contactless card activation, one or more servers could 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). Furthermore, if the counter value exceeds 10 but is below another threshold range (e.g., 1000), the one or more servers could be configured to request a gesture associated with the contactless card, such as a user tap. Upon the user tap, authentication is successful if the counter value is within the expected or acceptable range.

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

[0119] At box 820, the counter can be used as diversification data because it changes with each use and provides a different session key each time, rather than a master key derivation where each card generates a unique set of keys. In some examples, a 4-byte approach is preferred for both operations. Therefore, at box 820, two session keys can be created for each transaction from the UDK: one from the AUTKEY and one from the ENCKEY. On the card, for the MAC key (i.e., the session key created from the AUTKEY), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from the ENCKEY), the full length of the OTP counter can be used for the ENC key.

[0120] At box 830, the MAC key can be used to prepare the MAC cipher, and the ENC key can be used to encrypt the cipher. For example, the MAC session key can be used to prepare the cipher, and the result can be encrypted using the ENC key before it is transmitted to one or more servers.

[0121] At box 840, MAC verification and processing are simplified because the payment HSM's MAC authentication function directly supports 2-byte variability. Password decryption occurs before MAC verification. Session keys are 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 data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0122] For contactless cards, a unique identifier may be derived that is distinctly associated with the primary account number (PAN) and PAN sequence number encoded in the card. Key diversification can be configured to utilize the master key receiving identifier as input, allowing one or more keys to 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 PIN generation / authentication key – Card-Key-Auth) and may be further diversified to create a MAC session key used when generating and verifying MAC PINs. 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 and second keys can be created by diversifying the issuer master key by combining the issuer master key with the card's unique ID number (pUID) and the payment app's PAN sequence number (PSN). The pUID may include a 16-bit numeric value. As explained above, the pUID may include a 16-bit BCD-encoded number. In some examples, the pUID may include a 14-bit numeric value.

[0123] In some examples, since the EMV session key export method can end after 2^16 uses, a counter such as a full 32-bit counter can be added to the initialization array of the diversification method.

[0124] In other examples such as credit cards, a number such as an account number or an unpredictable number provided by one or more servers can be used for session key generation and / or diversification.

[0125] Figure 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 keys can be uniquely assigned to each card. The keys may include a symmetric key that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV and implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity requiring a key.

[0126] Regarding master key management, each part of a portfolio of one or more applets issued on it may require two issuer master keys 905 and 910. 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 and 910 are diversified into card master keys 925 and 930, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 915 and the Derived Key Index (pDKI) 920, which are background data, can be used to identify which issuer master keys 905 and 910 are used in the encryption process used for authentication. The system performing authentication can be configured to retrieve the values ​​of pNPR 915 and pDKI 920 of the contactless card during authentication.

[0127] In some examples, to increase the security of the solution, session keys (such as a unique key for each session) can be derived, but instead of using the master key, a unique card-derived key and counter can be used as diversification data, as explained above. For example, each time the card is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and to perform encryption. Regarding session key generation, the key used to generate passwords and encrypt data in one or more applets can include session keys based on the card's unique key (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 by using an application transaction counter 945 with one or more algorithms. To fit the data into one or more algorithms, only the two least significant bytes of the 4-byte pATC 945 are used. In some examples, the four-byte session key export 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 the card-unique exported master key.

[0128] As described in this article, the lower two bytes of the pATC 945 counter can be used to derive one or more MAC session keys. With each tap of the 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 can be initialized to zero during personalization or applet initialization. In some examples, the pATC counter 945 can be initialized during or before personalization and can be configured to increment by 1 with each NDEF read.

[0129] Furthermore, each card's update can be unique and can be assigned through personalization or algorithmically via pUID or other identifying information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, updates can also vary during sequential reads, allowing a card to repeat in sequence with increments of 1, 3, 5, 2, 2, ... . Specific sequences or algorithmic sequences can be defined during personalization or based on one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0130] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may consist only of authentication data and an 8-byte random number (MAC) following the authentication data. In some examples, the random number may precede the password A and can be a block size. In other examples, there may be no limit to the length of the random number. In yet another example, the total data (i.e., the random number plus the password) can be a multiple of the block size. In these examples, an additional 8-byte block can be added to match the block generated by the MAC algorithm. As another example, if the algorithm used employs a 16-byte block, even a multiple of the block size can be used, or the output can be automatically or manually padded to a multiple of that block size.

[0131] MAC can be performed using the function key (AUT-Session-Key) 935. The data specified in the cipher can 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 can include the session key AUT-Session-Key 935. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As explained below, AUT-Session-Key 935 can be used for MAC data 950, and the resulting data or cipher A 955 and random number RND can be encrypted using DEK-Session-Key 940 to create cipher B or output 960 sent in the message.

[0132] In some examples, one or more HSM commands can be processed for decryption, such that the final 16 (binary, 32-hexadecimal) bytes can include 3DES symmetric encryption using CBC mode, where the fourth zero of the random number is followed by MAC authentication data. The key used for this encryption can 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 pATC945.

[0133] The following format represents an example embodiment of the binary version. Furthermore, in some examples, the first byte may be set to ASCII 'A'.

[0134]

[0135]

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

[0137]

[0138]

[0139] The UID field of the received message can be extracted to derive the card master key (Card-Key-Auth 925 and Card-Key-DEK 930) for that specific card from the master keys Iss-Key-AUTH 905 and Iss-Key-DEK 910. Using the card master key (Card-Key-Auth 925 and Card-Key-DEK 930), the counter (pATC) field of the received message can be used to derive the session key (Aut-Session-Key 935 and DEK-Session-Key 940) for that specific card. Password B 960 can be decrypted using DEK-Session-KEY, which produces password 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 message version, UID, and pATC fields, can be processed using the recreated Aut-Session-Key via an encrypted MAC to create a MAC output such as 'MAC'. If the "MAC" matches the password A 955, this indicates that message decryption and MAC checks have both passed. You can then read the pATC to determine its validity.

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

[0141] In some examples, one advantage of using MAC ciphers to encrypt non-shared random numbers for the first block is that it acts as an initialization vector when using the CBC (block-linked) mode of a symmetric encryption algorithm. This allows for "scrambling" block by block without having to pre-establish a fixed or dynamic IV.

[0142] By including the Application Transaction Counter (pATC) as part of the data included in the MAC cipher, the authentication service can be configured to determine whether the value transmitted in plaintext data has been tampered with. Furthermore, by including the version in one or more ciphers, it becomes difficult for an attacker to intentionally tamper with the application version when attempting to weaken the encryption solution. In some examples, the pATC can start from zero and be updated to 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 authentication data uses a pATC equal to or less than a previously received value by the authentication service, this could be interpreted as an attempt to replay an old message, and the authenticated message might be rejected. In some examples, when the pATC is greater than a previously received value, it can be evaluated to determine if 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 is unreliable. In MAC operation 936, data 950 is processed via MAC using the Aut-Session-Key 935 to produce an encrypted MAC output (cipher A) 955.

[0143] To provide additional protection against brute-force attacks that expose the key on the card, it is desirable to encrypt the MAC cipher 955. In some examples, the data or cipher A 955 included in the ciphertext may include: a random number (8) and a cipher (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that can be configured to ensure the random number is unpredictable through one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include DEK-Session-Key 940. In encryption operation 941, the data or cipher A 955 and RND are processed using DEK-Session-Key 940 to produce encrypted data, namely cipher B 960. The data 955 may be encrypted using 3DES in 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'00000000000000000' can be used. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key has been used, because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random occurrence.

[0144] In order for the authentication service to verify one or more passwords provided by one or more mini-programs, the following data must be transmitted from one or more mini-programs to the mobile device in plaintext during the authentication session: version number, which determines the encryption method used and the message format used for password verification, allowing the method to be changed in the future; pUID, which is used to retrieve the encrypted asset and derive the card key; and pATC, which is used to derive the session key used for the password.

[0145] Figure 10 A method 1000 for generating a password is illustrated. For example, at box 1010, the Network Profile Record ID (pNPR) and the Derived Key Index (pDKI) can be used to identify which issuer master keys are used in the encryption process used for authentication. In some examples, the method may include performing authentication to retrieve the values ​​of the pNPR and pDKI of the contactless card during authentication.

[0146] At box 1020, the issuer master key can be diversified by combining the issuer master key with the unique ID number (pUID) and PAN serial number (PSN) of the card of one or more mini-programs (such as payment mini-programs).

[0147] At box 1030, Card-Key-Auth and Card-Key-DEK (unique card keys) can be created by diversifying the issuer's master key to generate session keys that can be used to generate MAC passwords.

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

[0149] Figure 11 An exemplary process 1100 illustrating key diversification according to one example is depicted. Initially, the sender and receiver may be provided with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value that can be updated at box 1110, as well as other data (such as data to be protected) that the sender can securely share with the receiver.

[0150] At box 1120, the counter value can be encrypted by the sender using the data encryption master key to generate a data encryption-derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to generate a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryption processes.

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

[0152] At box 1130, the sender uses a data integrity session key and an encrypted MAC algorithm to process the data to be protected using encrypted MAC operations. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0153] At box 1140, the sender can encrypt the data to be protected using a session key derived from data encryption combined with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data (e.g., every 8 bytes) and then encrypted using a second session key (DEK session key).

[0154] At box 1150, the encrypted MAC is transmitted from the sender to the receiver, containing enough information to identify the additional secret information (such as the shared secret, master key, etc.) for cryptographic verification.

[0155] At box 1160, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as explained above.

[0156] At box 1170, the protected data is decrypted using the session key derived from the data encryption, in conjunction with a symmetric decryption operation. Further processing of the exchanged data is then performed. In some examples, after extracting the MAC, the desired outcome is to reconstruct and match the MAC. For example, when verifying a password, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0157] At box 1180, the session key is exported using data integrity in conjunction with the encrypted MAC operation to verify that the protected data has not been modified.

[0158] Some examples of the methods described herein can advantageously confirm when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is correct. The MAC can only be considered correct if decryption is successful and a correct MAC value is generated. Successful decryption likely indicates that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key was created using a master key known only to the sender (e.g., the sending device) and the receiver (e.g., the receiving device), it can be believed that the contactless card that initially created and encrypted the MAC is indeed authentic. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

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

[0160] Example embodiments of the systems and methods described herein can 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 via one or more applications executed on the device. As a second process, in response to successful login and verification via one or more applications, a user may participate in one or more actions associated with one or more contactless cards. In practice, security factor authentication may include securely authenticating a user's identity and participating in one or more types of actions associated with a contactless card, including but not limited to one or more tap gestures. In some examples, one or more tap gestures may include a user tapping a contactless card on the device. In some examples, the device may include a mobile device, kiosk, terminal, tablet, or any other device configured to process received tap gestures.

[0161] In some examples, contactless cards can be tapped on a device (such as one or more computer kiosks or terminals) to verify identity and receive a transaction item, such as coffee, in response to a purchase. Using contactless cards, secure methods for verifying identity can be established within loyalty programs. This provides a way to securely verify identity, unlike simply scanning a barcode card, for example, to receive rewards, coupons, offers, or benefits. For instance, encrypted transactions can occur between the contactless card and a device that can be configured to process one or more tap gestures. As explained above, one or more applications can be configured to verify a user's identity and then allow the user to act or respond to it, for example, via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, healthcare information, etc., can be written back to the contactless card.

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

[0163] In some examples, a contactless card can be activated by tapping it on a device such as a mobile device. For instance, the contactless card can communicate with the device's application via NFC communication through the device's card reader. This communication, achieved by tapping the card near the device's card reader, allows the device's application to read the data associated with the contactless card and activate it. In some examples, activation can authorize the card to perform other functions, such as purchasing, accessing an account, or other restricted information or functions. In some examples, a tap can activate or launch the device's application 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 application's download page. After installation, tapping the contactless card can activate or launch the application and then initiate contactless card activation, for example, via the application or other backend communications. Once activated, the contactless card can be used for various activities, including but not limited to commercial transactions.

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

[0165] In some embodiments, the example authentication communication protocol may mimic an offline dynamic data authentication protocol with some modifications to the EMV standard 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 the card issuer / payment processor, no data value is 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 the card issuer. Whether the issuer approves or rejects the transaction may be based on whether the issuer recognizes the transaction value. Meanwhile, in some embodiments of this disclosure, transactions originating from mobile devices lack a transaction value associated with the POS system. Therefore, in some embodiments, a spurious transaction value (i.e., a value recognizable by the card issuer and sufficient to allow activation) may be transmitted as part of the example authentication communication protocol. POS-based transactions may also be rejected based on the number of transaction attempts (e.g., a transaction counter). An attempt exceeding a buffer value may result in a soft rejection; a soft rejection requires further verification before accepting the transaction. In some embodiments, the buffer value of the transaction counter may be modified to avoid rejecting legitimate transactions.

[0166] In some examples, contactless cards can selectively transmit information based on the receiving device. Once tapped, the contactless card can identify the device targeted by the tap, and based on this identification, the card can provide the appropriate data to that device. This advantageously allows the contactless card to transmit only the information necessary to complete an immediate action or transaction (such as payment or card authentication). By limiting data transmission and avoiding unnecessary data transfers, both efficiency and data security can be improved. Information identification and selective communication can be applied to a variety of scenarios, including card activation, balance transfer, account access attempts, commercial transactions, and step-up fraud reduction.

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

[0168] As another example, a contactless card tap can be made to a POS device (including but not limited to kiosks, checkout registers, payment stations, or other terminals). When a tap is performed, the contactless card can identify the POS device and transmit only the information necessary for the action or transaction. For example, after identifying a POS device used to complete a commercial transaction, the contactless card can transmit the payment information required to complete the transaction according to the EMV standard.

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

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

[0171] In some examples, such as shopping malls, grocery stores, and convenience stores, a tap on a contactless card on a mobile device, without having to open an app, can indicate the expectation or intent to make one or more purchases using reward points, loyalty points, coupons, offers, etc. Thus, the intent behind the purchase is revealed.

[0172] In some examples, one or more applications can be configured to determine that it was initiated via one or more tap gestures of a contactless card, such that the initiation occurs at 3:51 p.m. and the transaction is processed or occurs at 3:56 p.m., in order to verify the user's identity.

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

[0174] In some examples, data can be collected from tapping behavior for biometric / gesture authentication. For instance, a unique identifier that is cryptographically secure and difficult to intercept can be transmitted to one or more backend services. The unique identifier can be configured to look up auxiliary information about an individual. Auxiliary information may include personally identifiable information about the user. In some examples, auxiliary information may be stored on a contactless card.

[0175] In some examples, the device could include an app that splits bills or checks among multiple individuals. For instance, each person might have a contactless card and might be a customer of the same issuing financial institution, but this is not required. Each of these individuals could receive push notifications on their device via the app to split the purchase. Other contactless cards could be used instead of just one card tap to indicate payment. In some examples, individuals from different financial institutions might have contactless cards to provide information to initiate one or more payment requests from the card-tapping individual.

[0176] The following example use cases illustrate examples of specific implementations of this disclosure. These are intended for illustrative purposes only and not for limiting purposes. In one scenario, a first friend (the payer) owes a second friend (the payee) money. The payer wishes to pay using a contactless card via the payee's smartphone (or other device) instead of going to an ATM or needing to exchange money via a peer-to-peer app. The payee logs into the appropriate app on their smartphone and selects the payment request option. In response, the app requests authentication via the payee's contactless card. For example, the app outputs a request for the payee to tap their contactless card display. Once the payee taps their contactless card on the screen of a smartphone with a supported app, the contactless card is read and verified. Next, the app displays a prompt indicating that the payer tapped their contactless card to send the payment. After the payer taps the contactless card, the app reads the card information and transmits the payment request to the payer's card issuer via the associated processor. The card issuer processes the transaction and sends a transaction status indicator to the smartphone. The app then outputs to display the transaction status indicator.

[0177] In another example scenario, a credit card customer may receive a new credit card (or debit card, other payment card, or any other card requiring activation) by mail. The customer can choose to activate the card via an app on his or her device (e.g., a mobile device such as a smartphone) instead of by calling a provided phone number associated with the card issuer or visiting a website. The customer can select the card activation feature from an app menu displayed on the device's screen. The app may prompt the customer to tap his or her credit card on the screen. When the credit card is tapped on the device's screen, the app can be configured to communicate with a server (such as the card issuer's server that activates the customer's card). The app can then display a message indicating successful card activation. Card activation is then complete.

[0178] Figure 12 A method 1200 for card activation according to an example embodiment is illustrated. For example, card activation can be performed by a system including a card, a device, and one or more servers. Contactless cards, devices, and one or more servers can be referenced in the preceding text. Figure 1A, Figure 1B , Figure 5A and Figure 5B Explain the same or similar components, such as contactless card 105, client device 110, and server 120.

[0179] In box 1210, the card can be configured to dynamically generate data. In some examples, this data may include information such as an account number, card identifier, card verification value, or phone number, which can be transferred from the card to the device. In some examples, one or more portions of the data may be encrypted using the systems and methods disclosed herein.

[0180] In box 1220, one or more portions of dynamically generated data can be transmitted to the device's application via NFC or other wireless communications. 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 from an app store to activate the card. In some examples, the user can be prompted to properly position, place, or orient the card toward the device's surface, such as at an angle or flat on, near, or adjacent to the device's surface. In response to the card's adequate position, placement, and / or orientation, the device can continue transmitting one or more encrypted portions of the data received from the card to one or more servers.

[0181] In box 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.

[0182] In box 1240, one or more servers may decrypt one or more encrypted portions of 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 record data accessible to one or more servers. If the comparison of one or more decrypted portions of the data performed by one or more servers yields a successful match, the card may be activated. If the comparison of one or more decrypted portions of the data performed by one or more servers yields an unsuccessful match, one or more procedures may occur. For example, in response to the 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 allow the user to activate the card. Alternatively, the user may receive notifications such as a message on his or her device indicating an unsuccessful attempt at card verification and used for calling, emailing, or texting related services 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 used for calling, emailing, or texting related services to help activate the card, or another notification such as an email indicating an unsuccessful attempt at card verification and used for calling, emailing, or texting related services to help activate the card.

[0183] In box 1250, one or more servers can transmit a return message based on successful card activation. For example, the device can be configured to receive output from one or more servers indicating that the card has been successfully activated by one or more servers. The device can be configured to display a message indicating successful card activation. Once the card is activated, the card can be configured not to continue dynamically generating data to prevent fraudulent use. In this way, the card can subsequently not be activated, and one or more servers will be notified that the card has been activated.

[0184] In another example, a customer wants to access their financial account on their mobile phone. The customer launches an app (e.g., a banking app) on their mobile device and enters their 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), they must have secondary authentication. Therefore, the app requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps their credit card on their mobile device, and the app verifies that the credit card corresponds to the user's account. Afterward, the user can view secondary account data and / or perform secondary account functions.

[0185] Figure 13 A method 1300 for authenticating a contactless card to perform a ticket issuance or authentication operation, according to an example embodiment, is described. Method 1300 may include: authenticating a contactless card for transportation tickets, event tickets, or travel boarding passes; granting access to a location; generating and receiving directions to an airport lounge or the nearest ATM, the nearest ATM without foreign transaction fees; and processing language translation, as further described herein.

[0186] Method 1300 can begin at box 1310 by establishing communication between a sending device or user equipment (such as a contactless card) and a client device or receiving device. The contactless card and the client or receiving device can be as described herein. For example, the client device can include systems such as POS devices, kiosks, terminals, tablets, mobile devices, network-enabled computers, servers, and combinations thereof, and the contactless card can be configured to transmit and receive data to and from the client device via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication).

[0187] At box 1320, method 1300 may include authenticating contactless cards according to the system and method described herein.

[0188] At box 1330, method 1300 may include performing one or more processes in response to authentication of the contactless card at box 1320. In some examples, performing one or more processes in response to authentication of the contactless card may include: authenticating a contactless card for transportation ticketing, event ticketing, travel boarding passes, granting access to a location, generating and receiving directions to the nearest ATM at an airport lounge or without foreign charges, and handling language translation.

[0189] At box 1340, method 1300 may include updating data or records on a contactless card.

[0190] Figure 14 An exemplary method for authenticating a contactless card to authenticate a ticket is described. For example, method 1400 may include authenticating a contactless card for authenticating one or more tickets, such as electronic tickets, as further described herein.

[0191] At box 1410, method 1400 may begin by establishing communication between a sending device or user device (such as a contactless card) and a client device or receiving device. The contactless card may be, and the client or receiving device may be as described herein. For example, the client device may include systems such as POS devices, kiosks, terminals, tablets, mobile devices, network-enabled computers, servers, and combinations thereof, and the contactless card may be configured to transmit and / or receive data to and / or transmit and / or receive data to the client device via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication).

[0192] At box 1420, method 1400 may include a system and method disclosed herein for authenticating a contactless card based on one or more user credentials.

[0193] At box 1430, method 1400 may include initiating an action associated with authenticating one or more electronic tickets based on the authentication of a contactless card based on box 1420. In some examples, this may include performing one or more processes in response to the authentication of a contactless card, such as authenticating a contactless card used for transportation ticketing.

[0194] In some examples, a user might expect to use his or her contactless card to authenticate transportation tickets. For example, transportation ticketing could include at least one of bus tickets, taxi tickets, bicycle tickets, car tickets, train tickets, boat tickets, or any other type of ticket associated with transportation. For example, transportation ticketing could include authenticating electronically generated tickets associated with transportation. In some examples, the system can be configured to retrieve data from the contactless card to authenticate it. The contactless card can be accessed by the user gesturing to indicate a tap, wave, or other gesture, which can be transmitted to the system via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication).

[0195] Prior to the authentication of the corresponding bus ticket, taxi ticket, bicycle ticket, car ticket, train ticket, or boat ticket (which can be performed by the system using the system), user authentication can be performed by the system or a server communicating with the system via the system and methods disclosed herein through a received tap, wave, or swipe of a contactless card. The system or server can use various parameters to authenticate the ticket, including scanning a machine-readable code image, matching account data and / or matching receipt or transaction data and / or matching user account data, or any combination thereof. The machine-readable code image can appear on the display of the user's device, which can be authenticated by the server. In some examples, when processing transportation tickets, the contactless card can be used as the user's identity to indicate that the user possesses the card and confirm that the user is indeed the identified associated user of the card. In this way, users no longer need to queue or be placed in a queue to process transportation tickets, and user access and authentication via contactless cards are improved, thus providing greater security.

[0196] At box 1440, method 1400 may include updating data or records on a contactless card.

[0197] In some examples, a user may expect to use his or her contactless card to authenticate event tickets in order to attend an event. For example, event tickets may include at least one of the following: sports event tickets, carnival or transportation tickets, conference or seminar tickets, private event tickets, public event tickets, school event tickets, or any other type of ticket associated with an event. For example, event ticketing may include authenticating an electronically generated ticket associated with one or more events. In some examples, the system may be configured to retrieve data from the contactless card to authenticate the contactless card. The contactless card may be accessed by a user gesturing to indicate a tap, wave, or other gesture, which may be transmitted to the system via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication). Prior to authentication of the corresponding sports event ticket, carnival or transportation ticket, conference or seminar ticket, private event ticket, public event ticket, or school event ticket, the user may be authenticated by the system or a server communicating with the system via the system and methods disclosed herein through the received tap, wave, or other gesture of the contactless card. The system or server can use various parameters to authenticate tickets, including scanning machine-readable code images, and / or matching account data and / or matching receipt or transaction data and / or matching user account data, or any combination thereof. The machine-readable code image can appear on the display of a user's device that can be authenticated by the server. In some examples, when processing event tickets, a contactless card can be used as the user's identity to indicate that the user possesses the card and confirm that the user is indeed the identified, associated user of the card. In this way, users no longer need to queue or be placed in a queue to process event tickets, and user access and authentication via contactless cards are improved, thus providing greater security.

[0198] In some examples, a user may expect to use his or her contactless card to authenticate a travel boarding pass. For example, a travel boarding pass may include an airplane boarding pass or any other type of boarding pass. Each of these boarding passes may be associated with a system (such as a POS device, kiosk, terminal, tablet, mobile device, server, or a combination thereof) that includes one or more readers, one or more processors, and one or more memories including one or more applications. For example, this could include authenticating an electronically generated ticket associated with one or more boarding passes. In some examples, the system may be configured to retrieve data from the contactless card to authenticate the contactless card. The contactless card may be accessed by a user gesturing to indicate a tap, wave, or other gesture, which may be transmitted to the system via short-range communication (including, but not limited to, NFC, WiFi, or Bluetooth communication). The user's authentication may be performed by the system or a server communicating with the system via the systems and methods disclosed herein using the received tap, wave, or swipe of the contactless card, prior to authentication of the corresponding boarding pass, which may be performed by the system or a server communicating with the system. The system or server can use various parameters to authenticate boarding passes, including scanning machine-readable code images, and / or matching account data and / or matching receipt or transaction data and / or matching user account data, or any combination thereof. The machine-readable code image can appear on the display of the user's device, which can be authenticated by the backend server. In some examples, the contactless card can be used as the user's identity when processing boarding passes, indicating that the user possesses the card and confirming that the user is indeed the identified, associated user of the card. In this way, users no longer need to queue or be placed in a queue to process travel boarding passes, and user access and authentication via contactless cards are improved, thus providing greater security.

[0199] In some examples, a user may expect to authenticate using his or her contactless card before entering a venue. For example, entry into a venue may include at least one of a sports venue, library venue, business venue, restaurant venue, airport venue, private venue, school venue, etc. Each of these venues may be associated with a system (such as a POS device, kiosk, terminal, tablet, mobile device, server, or a combination thereof) including one or more readers, one or more processors, and one or more memories including one or more applications. For example, granting entry may include authenticating an electronically generated image associated with granting entry to one or more venues. In some examples, the system may be configured to retrieve data from the contactless card to authenticate the contactless card. Before entering a sports venue, library venue, business venue, restaurant venue, airport venue, private venue, school venue, or school venue, user authentication may be performed by the system or a server communicating with the system via the systems and methods disclosed herein, through a tap, wave, or other gesture received from the contactless card. The system or server may use various parameters to authenticate the ticket, including scanning a machine-readable code image, and / or matching account data and / or matching receipt or transaction data and / or matching user account data, or any combination thereof. Machine-readable code images can appear on the display of a user's device that can be authenticated by a backend server. In some examples, when processing identification or user credentials for entry into a venue, a contactless card can be used as the user's identity, indicating that the user possesses the card and confirming that the user is indeed the associated user identified by the card. In this way, users no longer need to queue or be placed in a queue to process entry into a venue, and user access and authentication via contactless cards are improved, thus providing greater security.

[0200] In some examples, a user may want to determine the amount to be purchased in US dollars, and his or her contactless card can be used for this purpose. For example, by providing payment information from the contactless card, the card can be used to purchase one or more items or services. As a non-limiting example, the purchase of one or more items or services may be associated with the purchase or sale of one or more tickets. The contactless card can be configured to transmit, host, or process forms associated with the payment, and the system or server can be configured to receive payment information from the contactless card. The system may include a POS device, kiosk, terminal, tablet, mobile device, server, or a combination thereof, and includes one or more readers, one or more processors, and one or more memories including one or more applications. The contactless card can be gestured by the user to indicate a tap, wave, or other gesture, which can transmit the payment information and the user credentials stored therein to the system or server for processing and authentication via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication). In some examples, the contactless card can be configured to convert purchase amounts, which may include non-US dollar currencies, into amounts denominated in US dollars. In this way, users can obtain the dollar amount of a purchase or potential purchase without having to open and navigate a separate app on their device, or cut and paste the purchase or currency amount into the website. Therefore, users know the associated dollar amount of the purchase before actually buying an item or service, resulting in a significant reduction in workload.

[0201] In some examples, a user might expect to use his or her contactless card to obtain directions to one or more locations, such as restaurants, shops, gas stations, airport lounges, etc. For example, directions to each of these locations can be associated with a system (such as a POS device, kiosk, terminal, tablet, mobile device, server, or a combination thereof) that includes one or more readers, one or more processors, and one or more memories including one or more applications. In some examples, the system can be configured to retrieve data (such as identity information) from the contactless card to authenticate the card. In some examples, the identity information can be associated with one or more users of the contactless card. The contactless card can be gestured by the user to indicate a tap, wave, or swipe, which can be transmitted to the system via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication). The system or server can be configured to receive requests from the contactless card.

[0202] A user's mobile device can be configured to display directions in a map and / or list format based on location information (such as airport lounge information), where the airport lounge is located within a predetermined distance of the user's mobile device. As an example of an airport location, airport lounge information may include directions to and from the airport lounge, estimated duration by mode of transportation, such as walking, bus, or shuttle time, estimated arrival time, and the number of hours the airport lounge is operational. In response to a gesture from a contactless card, the system or server can be configured to provide the airport lounge information to the user's mobile device by accessing information in a database, which can be updated in real time.

[0203] In some examples, location information can be associated with intelligent wayfinding services based on identity information using smart building floor maps and signage. As a non-limiting example, the wayfinding service can be associated with one or more of physical and / or digital signs, information, landmarks, milestones, and maps. As a result of a gesture tap, wave, or swipe of a contactless card and the retrieval of identity information from the contactless card, users do not need to open and navigate separately on their mobile devices, nor do they need to search, cut, or copy and paste location information to a website to determine location orientation or other information.

[0204] In some examples, such as airport lounges, contactless cards can provide access credentials before processing a request for airport lounge information. In some examples, contactless cards may include information based on the user's account, such as the user's event or transaction history or logs for one or more airlines. In other examples, contactless cards may include information based on the user's preferences for the selected airport lounge. For example, user preferences could be vegetarian or non-vegetarian meal preferences, alcohol or non-alcoholic preferences, Admirals' Club or Loyalty Club preferences, gluten preferences, or one or more other services. In this way, users do not need to engage in the associated complexities of opening and navigating separate apps on their mobile devices, or searching, or cutting and pasting airport lounge information to a website for navigation.

[0205] In some examples, a user might expect to use his or her contactless card to obtain directions to the nearest ATM, or directions to the nearest ATM without foreign charges. In either example, directions to each of these ATMs can be provided by a system (such as a POS device, kiosk, terminal, tablet, mobile device, server, or a combination thereof). In some examples, the system can be configured to retrieve data from the contactless card to authenticate it. The contactless card can be accessed by the user through gestures indicating taps, waves, or other gestures, which can be transmitted to the system via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication). The user's mobile device or other device can be configured to display directions in a map and / or list format based on ATM information, and the user can limit ATM results to a range based on distance from the location of his or her device. In some examples, ATM information may include directions to and from the ATM, estimated duration of travel to the ATM via a mode of transportation, such as walking or bus or shuttle time, estimated arrival time, and the number of hours the ATM has been operating.

[0206] In response to a gesture from a contactless card, the system can be configured to provide ATM information to the user's mobile device by accessing this information in a database, which can be updated in real time. In some examples, the contactless card can provide access credentials before processing the request for ATM information. In some examples, the contactless card can include information based on the user's account, such as event or transaction history or logs of the user potentially belonging to one or more banks, which may indicate the user's preference for not charging foreign fees at ATMs. In this way, the user does not need to use separate apps, search for ATMs, determine directions, or navigate to an ATM that meets their criteria.

[0207] In some examples, a user might expect to use his or her contactless card to translate languages. This need may frequently arise during international travel, but it can also occur domestically, and the applicability of these examples is not limited to international travel. For example, a contactless card can be configured to transmit, and a system or server hosting or processing language-associated forms can be configured to receive requests or language information from the contactless card. The contactless card can be gestured by the user to indicate a tap, wave, or other gesture, which can transmit the request or language information and the user credentials stored therein to the system for processing and authentication via short-range communication (including but not limited to NFC, WiFi, or Bluetooth communication). In some examples, a contactless card can be configured to translate non-English text (such as French, Italian, German, Spanish, etc.) associated with applications, emails, text messages, or websites appearing on the user's device display via gestures. Conversely, it can enable applications, emails, text messages, or websites appearing on the user's device display to translate from English text to non-English text, such as French, Italian, German, Spanish, etc. In this way, users do not need to use translation apps on their mobile devices, cut or copy and paste the text in question onto the website, or use other means of translating text.

[0208] Throughout the specification, various types of accounts are mentioned, such as bank accounts, credit card accounts, and debit accounts. However, it should be understood that this disclosure is not limited to specific bank accounts and may include any financial account, as well as accounts related to entertainment, loyalty programs, utilities, and other services.

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

[0210] Throughout the specification and claims, the following terms shall take at least their explicitly associated meaning herein, unless the context clearly specifies otherwise. The term “or” is intended to mean an inclusive “or”. Furthermore, the terms “a,” “an,” and “the” are intended to mean one or more, unless otherwise stated or clearly indicated from the context to be in the singular form.

[0211] Numerous specific details have been set forth in this specification. However, it should be understood that the disclosed techniques can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification. References to “some examples,” “other examples,” “an example,” “example,” “various examples,” “an embodiment,” “an embodiment,” “some embodiments,” “example embodiments,” “various embodiments,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that one or more implementations of the disclosed techniques thus described may include specific features, structures, or characteristics, but not every implementation must include specific features, structures, or characteristics. Furthermore, the repeated use of the phrases “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.

[0212] As used herein, unless otherwise stated, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe common objects merely indicates different instances of the similar objects being referred to, and is not intended to imply that the objects described in this way must be in a given order in time, space, hierarchy, or any other way.

[0213] While some embodiments of the disclosed technology have been described in conjunction with various embodiments currently considered most practical, it should be understood that the disclosed technology is not limited to the disclosed embodiments, but rather 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 limiting purposes.

[0214] This written description uses examples to disclose certain embodiments (including best modes) of the disclosed technology and also enables any person skilled in the art to practice certain embodiments of the disclosed technology, including making and using any device or system and performing any combined methods. The patentable scope of certain embodiments of the disclosed technology is defined in the claims and may include other examples that would occur to a person skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are not substantially different from the literal language of the claims.

Claims

1. A data transmission system comprising: a transmitting device having a processor and a memory, the transmitting device's memory containing a diversified master key, transmission data, and a counter value; an application comprising instructions for execution on a receiving device having a processor and a memory, the receiving device's memory containing the master key; wherein the transmitting device is configured to: generate a diversified key using the diversified master key, one or more encryption algorithms, and the counter value, generate an encryption result comprising the counter value using the one or more encryption algorithms and the diversified key, encrypt the transmission data using the one or more encryption algorithms and the diversified key to produce encrypted transmission data, and transmit the encryption result and the encrypted transmission data to the application; and wherein the application is configured to: generate an authentication diversified key based on the master key and a unique identifier; generate a session key based on the authentication diversified key and the encryption result; and decrypt the encrypted transmission data using the one or more encryption algorithms and the session key and verify the received encryption result, wherein the application is configured to initiate one or more processes in response to verification of the transmission data upon authentication of at least one user credential.

2. The data transmission system of claim 1, wherein the one or more processes comprise authenticating information associated with at least one selected from the group consisting of event ticketing information, venue entry permission information, location information, or language information.

3. The data transmission system of claim 2, wherein authenticating information comprises matching a set of data accessible to the application.

4. The data transmission system of claim 2, wherein the location information comprises directions to at least one selected from the group consisting of an airport lounge and an ATM located within a predetermined distance based on one or more user preferences.

5. The data transmission system of claim 2, wherein the language information comprises text translated from a language other than English to English.

6. The data transmission system of claim 2, wherein the event ticketing information is authenticated by scanning at least one selected from the group consisting of a sports event ticket, a carnival or toll ticket, a conference or seminar ticket, a private event ticket, a public event ticket, a school event ticket.

7. The data transmission system of claim 2, wherein the venue entry permission information is associated with implementing one or more smart wayfinding services according to at least one selected from the group consisting of a smart floor and a smart sign.

8. The data transmission system of claim 1, wherein the receiving device comprises a server, and the encryption result and encrypted transmission data are transmitted by the transmitting device to the application via one or more intermediary devices.

9. The data transmission system of claim 1, wherein the at least one user credential is transmitted from the transmitting device to the application via near field communication. ​ 10. The data transmission system of claim 9, wherein the at least one user credential is transmitted from the transmitting device to the application via at least one selected from the group consisting of a tap gesture, a swipe gesture, and a wave gesture.

11. A method of securing one or more processes using a transmitting device and an application comprising instructions for execution on a receiving device, the method comprising the steps of: generating, by the transmitting device, a diversified key using a diversified master key, one or more encryption algorithms, and a counter value, the transmitting device comprising a processor and a memory, the transmitting device's memory containing the diversified master key, transmission data, and the counter value; generating, by the transmitting device, an encryption result comprising the counter value using the one or more encryption algorithms and the diversified key; encrypting, by the transmitting device, the transmission data using the one or more encryption algorithms and the diversified key to produce encrypted transmission data; transmitting, by the transmitting device, the encryption result and the encrypted transmission data to the application; generating, by the transmitting device, an authentication diversified key based on the master key and a unique identifier; generating, by the transmitting device, a session key based on the authentication diversified key and the encryption result; decrypting, by the transmitting device, the encrypted transmission data using the one or more encryption algorithms and the session key and verifying the received encryption result; and initiating, by the transmitting device, one or more processes in response to verification of the transmission data.

12. The method of claim 11, wherein the one or more processes comprise authenticating information associated with at least one selected from the group consisting of event ticketing information, venue entry permission information, location information, or language information.

13. The method of claim 12, wherein authenticating information comprises matching a set of data accessible to the application.

14. The method of claim 12, wherein the venue entry permission information is associated with implementing one or more smart wayfinding services according to at least one selected from the group consisting of a smart floor and a smart sign.

15. The method of claim 12, wherein the location information comprises directions to at least one selected from the group consisting of an airport lounge and an ATM located within a predetermined distance based on one or more user preferences.

16. The method of claim 12, wherein the language information comprises text translated from a non-English language to English.

17. The method of claim 12, wherein the event ticketing information is authenticated by scanning at least one selected from the group consisting of a sports event ticket, a carnival or toll ticket, a conference or seminar ticket, a private event ticket, a public event ticket, a school event ticket.

18. The method of claim 11, wherein the receiving device comprises a server, and the encryption result and encrypted transmission data are transmitted by the transmitting device to the application via one or more intermediary devices. ​ 19. The method of claim 11, wherein at least one user credential is transmitted from the sending device to the application via near field communication.

20. The method of claim 11, wherein at least one user credential is transmitted from the sending device to the application via at least one selected from the group consisting of a tap gesture, a swipe gesture, and a wave gesture.

Images