System and method for password authentication for contactless cards

Abstract

Example embodiments of systems and methods for data transfer between a contactless card and a receiving device are provided. In one embodiment, a contactless card can be configured to create a cryptogram based on a plurality of keys and a counter. The cryptogram can be sent to a receiving device. The contactless card can be configured to send a one-time password to the receiving device. The counter value can be adjusted each time a one-time password is generated, and the counter can be configured to increment in a non-monotonic sequence, the sequence being associated with one or more cryptographic algorithms.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. Patent Application 16 / 351,067, filed March 12, 2019, and to U.S. Patent Application 16 / 205,119, filed November 29, 2018, and to U.S. Provisional Patent Application 62 / 740,352, filed October 2, 2018, wherein patent application 16 / 351,067 is a continuation of a portion of patent application 16 / 205,119, the entire disclosure of which is incorporated herein by reference. 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 account for an increasingly larger share of commercial activity.

[0005] Email can be used to verify transactions, but it is vulnerable to attacks and unauthorized access. Short Message Service (SMS) messages can also be used, but they are also susceptible to threats. 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), requires cardholders to spend time making phone calls or visiting websites and entering or otherwise providing card information. Furthermore, while the increasing use of chip-based debit cards offers greater security than previous technologies (such as magnetic stripe cards), account access for personal purchases may still rely on login credentials (such as username and password) to verify the cardholder's identity. However, if these login credentials are compromised, others can access that user's account.

[0007] The aforementioned and other shortcomings exist. Therefore, appropriate solutions are needed to overcome these shortcomings and provide data security, authentication, and verification for contactless cards. Furthermore, an improved method for activating cards is required, along with improved authentication for account access, while preventing unauthorized personnel from guessing or speculating on authentication, credentials, or verification information. 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 one-time password system, the system comprising: a contactless card including one or more processors and a memory, wherein the memory contains at least one applet, at least one key, and a counter; and a client device application including instructions for execution on the client device, wherein: the contactless card is configured to create a password based on the at least one key and the counter, the contactless card is configured to send the password to the client device application, the contactless card is configured to send a one-time password to the client device application, the counter is adjusted each time the password is generated, and the counter is configured to increment in a non-monotonic sequence, wherein the increment is associated with one or more cryptographic algorithms.

[0010] Embodiments of this disclosure provide a method for protecting a counter-based one-time password using a contactless card. The method includes: providing a contactless card, the contactless card including one or more processors and a memory, the memory containing one or more applets, at least one key, and a counter; the one or more processors creating a password based on the at least one key and the counter; the contactless card sending the password; the contactless card sending one or more one-time passwords; wherein the counter is adjusted each time the password is generated, and wherein the counter is configured to increment in a non-monotonic sequence, the increment being associated with one or more cryptographic algorithms.

[0011] Embodiments of this disclosure provide a contactless card comprising: one or more processors, a counter, and a memory, wherein the memory contains at least one applet, wherein the contactless card is configured to: generate a one-time password, send the one-time password, and adjust the counter upon generation of each one-time password, wherein the counter is configured to increment or decrement in a non-monotonic sequence, wherein the increment or decrement value is selected to avoid premature overlap of the counter, and wherein the counter is associated with one or more cryptographic algorithms.

[0012] Other features of the disclosed design, and the advantages therefrom, are explained in more detail below with reference to specific example embodiments shown in the accompanying drawings, in which the same elements are indicated by the same reference numerals. Attached Figure Description

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

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

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

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

[0017] Figure 4 This is a flowchart illustrating a key decentralization method according to an example embodiment.

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

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

[0020] Figure 6 This is an illustration of messages communicating with a device according to an example embodiment.

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

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

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

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

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

[0026] Figure 12 This is a flowchart of a method for activating a card according to an example embodiment.

[0027] Figure 13 This is a diagram of a one-time cryptographic system according to an example embodiment.

[0028] Figure 14 This is a flowchart illustrating a method for protecting one-time passwords according to an example embodiment. Detailed Implementation

[0029] The following description of the embodiments provides non-limiting, representative example reference figures to specifically describe the features and teachings of different aspects of the invention. It should be understood that the described embodiments can be implemented separately or in combination with other embodiments described herein. By carefully reading the description of the embodiments, those skilled in the art should be able to learn and understand the different aspects of the invention described. The description of the embodiments is intended to facilitate an understanding of the invention to such extent that other implementations not specifically covered but which can be understood by those skilled in the art from reading the description of the embodiments are to be understood as consistent with the application of the invention.

[0030] 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 require the user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, a method can be provided for contactless cards to interact and communicate between the user's device (e.g., a mobile phone) and the card itself. For example, the EMV protocol, which underlies many credit card transactions, includes an authentication process sufficient to satisfy... Operating system requirements, but given This presents challenges because it imposes greater restrictions on the use of Near Field Communication (NFC), allowing it to be used only in read-only mode. The exemplary embodiments of the contactless card described herein utilize NFC technology.

[0031] 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 130. Although Figure 1A A single component instance is shown, but system 100 can include any number of components.

[0032] System 100 may include one or more contactless cards 105, as described below. Figures 5A to 5B Further explanation of the contactless card is provided. In some embodiments, the contactless card 105 may wirelessly communicate with the client device 110 using NFC.

[0033] System 100 may include client device 110, which may be a computer with network capabilities. As referred to herein, a computer with network capabilities may include, but is not limited to, computer equipment or communication equipment, such as 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... iPhone, iPod, iPad, or any other device running Apple products Mobile devices running operating systems; any device running Microsoft operating systems. Operating system devices; any device running Google. Devices with operating systems, and / or any other smartphones, tablets, or similar wearable mobile devices.

[0034] Client device 110 may include a processor and memory, and it should be understood that the processing circuitry may include other components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware necessary to perform the functions described herein. Client device 110 may further 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 device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices can be used to input information and interact with the software and other devices described herein.

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

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

[0037] 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 a wireless network and a wired network, and may be configured to connect client device 110 to server 130. For example, network 115 may include one or more of the following: fiber optic network, passive fiber optic network, cable network, Internet network, satellite network, wireless local area network (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, radio frequency identification (RFID), Wi-Fi, etc.

[0038] Furthermore, network 115 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 115 may support Internet networks, wireless communication networks, cellular networks, and any combination thereof. Network 115 may further include a single network, or any number of the aforementioned exemplary network types, which operate as independent networks or cooperate with each other. Network 115 may utilize one or more protocols of one or more network elements communicatively coupled to it. Network 115 may be converted to one or more protocols of network devices, or converted from other protocols to one or more protocols of network devices. Although network 115 is described as a single network, it should be understood that, depending on one or more examples, network 115 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks (e.g., credit card association networks), and home networks.

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

[0040] 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 132 and a processor 134. Figure 1B Can be quoted Figure 1ASimilar components are shown in the image.

[0041] In step 102, application 132 communicates with contactless card 105 (e.g., after approaching contactless card 105). Communication between application 132 and contactless card 105 includes contactless card 105 being brought close enough to the card reader (not shown) of client device 110 to enable NFC data transfer between application 132 and contactless card 105.

[0042] In step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a Message Authentication Code (MAC) password. In some examples, this can occur when the application 132 reads the contactless card 105. Specifically, this can occur when reading (e.g., NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC Data Exchange format. For example, a reader such as application 132 can send a message, such as a mini-program selection message, which has the mini-program ID that generated the mini-program's NDEF. After confirming the selection, a series of select file messages followed by a read file message can be sent. For example, this sequence can include "Select Function File", "Read Function File", and "Select NDEF File". At this time, a counter value maintained by the contactless card 105 can be updated or incremented, which can be followed by "Read NDEF File". At this time, a message can be generated, which can include a header and a shared secret. A session key can then be generated. A MAC password can be created through this message, which can 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 random number (RND) can then be encrypted using a session key. Afterward, the cipher and header can be concatenated, encoded in ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

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

[0044] In some examples, application 132 can be configured to send a request to contactless card 105 that includes instructions to generate a MAC password.

[0045] In step 106, the contactless card 105 sends a MAC password to the application 132. In some examples, the MAC password is sent via NFC, but this disclosure is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means.

[0046] In step 108, application 132 transmits the MAC password to processor 134.

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

[0048] In some examples, the MAC password verification operation can be performed by a device other than client device 110 (such as server 130 that communicates with client device 110). Figure 1A (As shown). For example, processor 134 can output a MAC password to send to server 130, which can verify the MAC password.

[0049] In some examples, a MAC cipher can be used as a digital signature for verification purposes. Other digital signature algorithms can also be used to perform this verification, such as public-key asymmetric algorithms (e.g., digital signature algorithms and RSA algorithms) or zero-knowledge protocols.

[0050] 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 devices discussed are the same or similar. 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 can be referenced above. Figure 1A The discussion on network 115 is similar. Server 220 can be referenced above. Figure 1A The server discussed is similar to 130. Although Figure 2 A single component instance of system 200 is shown, but system 200 may include any number of components shown.

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

[0052] Equally important, avoid using the same key repeatedly. Using or reusing a key too frequently can compromise its security. Each time a key is used, it provides an attacker with additional samples of data processed by the cryptographic algorithm using the same key. The more data an attacker possesses processed using the same key, the more likely they are to discover the key value. Frequently used keys can be included in various different attacks.

[0053] Furthermore, each execution of a symmetric cryptographic algorithm can potentially reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data may include subtle power fluctuations that occur while the cryptographic algorithm is being executed using the key. An attacker can take sufficient measures against the side-channel data to reveal enough information about the key to recover it. Exchanging data using the same key continuously exposes data processed through the same key.

[0054] However, by limiting the number of times a specific key is used, the amount of side-channel data an attacker can collect can be limited, thereby reducing the risk of this and other types of attacks. As further described herein, parties involved in the exchange of cryptographic information (e.g., senders and receivers) can periodically replace the shared symmetric key in use by individually generating keys from an initial shared master symmetric key combined with a counter value, requiring any form of key exchange to keep the parties synchronized. By periodically changing the shared confidential symmetric key used by the sender and receiver, the aforementioned attacks become impossible.

[0055] Return to reference Figure 2 System 200 can be configured to implement key decentralization. For example, a sender and a receiver may wish to exchange data (e.g., raw sensitive data) via their respective devices 205 and 210. As described above, although a single instance of 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 confidential symmetric key. In some examples, the same master symmetric key may be provided to sending device 205 and receiving device 210. Furthermore, it should be understood that any party or device holding the same confidential symmetric key can perform the functions of sending device 205, and similarly, any party holding the same confidential symmetric key can perform the functions of receiving device 210. In some examples, the symmetric key may include a shared confidential symmetric key that remains confidential to all other parties involved in the exchange of secure data besides sending device 205 and receiving device 210. It should also be understood that the same master symmetric key can be provided to both the transmitting device 205 and the receiving device 210, and further, 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.

[0056] System 200 may include one or more networks 215. In some examples, network 215 may be one or more wireless networks, wired networks, 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 one or more of the following: fiber optic network, passive fiber optic network, cable network, Internet network, 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, etc.

[0057] 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 Internet networks, wireless communication networks, cellular networks, and any combination thereof. Network 215 may further include a single network, or any number of the aforementioned exemplary network types, which operate as independent networks or cooperate with each other. Network 215 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 215 may be converted to one or more protocols of network devices, or converted from other protocols to one or more protocols of network devices. Although network 215 is described as a single network, it should be understood that, depending on one or more examples, network 215 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks (e.g., credit card association networks), and home networks.

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

[0059] At box 225, the sender can update the counter when the sending device 205 is ready to use symmetric cryptographic operations to process sensitive data. Additionally, the sending device 205 can select an appropriate symmetric cryptographic 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 the decentralized value can include any symmetric cryptographic algorithm that generates a decentralized symmetric key of the desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES138; 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 with different input data and the same master key may produce multiple outputs that can be combined as needed to generate a sufficiently long key.

[0060] At box 230, the sending device 205 can employ a selected cryptographic 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 with the selected symmetric encryption algorithm, thereby creating a distributed symmetric key.

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

[0062] At box 235, sensitive data can be processed using a distributed symmetric key before sending the result to receiving device 210. For example, sending device 205 can use a distributed symmetric key to encrypt the sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. Sending device 205 can then send the protected encrypted data along with a counter value to receiving device 210 for processing.

[0063] At box 240, receiving device 210 can first acquire a counter value, then use that counter value as encryption input, and perform the same symmetric encryption using the master symmetric key as the encryption key. The encrypted output may be the same as the decentralized symmetric key value created by the sender.

[0064] 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 decentralized symmetric key.

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

[0066] The next time sensitive data needs to be sent from the sender to the receiver via the corresponding sending device 205 and receiving device 210, different counter values ​​can be selected to generate different decentralized symmetric keys. By using the master symmetric key and the same symmetric cryptographic algorithm to process the counter values, both sending device 205 and receiving device 210 can independently generate the same decentralized symmetric key. This decentralized symmetric key, instead of the master symmetric key, is used to protect sensitive data.

[0067] As described above, the transmitting device 205 and the receiving device 210 initially each hold a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Since the decentralized symmetric key is created independently by the transmitting device 205 and the receiving device 210, it is never transmitted between them. Therefore, an attacker cannot intercept the decentralized 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; sensitive data is not. Therefore, the exposure of side-channel data regarding the master symmetric key is reduced. Furthermore, the operation of the transmitting device 205 and the receiving device 210 can be controlled by symmetry requirements, determining how often a new decentralized value is created, and thus a new decentralized symmetric key is created. In one embodiment, a new decentralized value and thus a new decentralized symmetric key can be created for each exchange between the transmitting device 205 and the receiving device 210.

[0068] In some examples, the key decentralization value may include a counter value. Other non-limiting examples of key decentralization values ​​include: a random nonce generated each time a new decentralization key is needed, which is 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 separately by sending device 205 and receiving device 210 but not sent between the two devices; a one-time password exchanged between sending device 205 and receiving device 210; and a cryptographic hash of sensitive data. In some examples, parties may use one or more portions of the key decentralization value to create multiple decentralization keys. For example, a counter may be used as the key decentralization value. Furthermore, combinations of one or more of the exemplary key decentralization values ​​described above may be used.

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

[0070] 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, 325; one or more hardware security modules 330; and a database 335. Although Figure 3 A single component instance is shown, but system 300 can include any number of components.

[0071] System 300 may include the following references Figures 5A to 5B One or more contactless cards 305 are further described. 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, when the contactless card 305 is within range of the card reader 313, the contactless card 305 may be configured to communicate with the card reader 313 of the client device 310 via NFC. In other examples, communication with the contactless card 305 may be implemented through a physical interface, such as a Universal Serial Bus interface or a card swipe interface.

[0072] System 300 may include client device 310, which may be a computer with network capabilities. As referred to herein, a computer with network capabilities may include, but is not limited to, computer equipment or communication equipment, such as 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... iPhone, iPod, iPad, or any other device running Apple products Mobile devices running operating systems; any device running Microsoft operating systems. Operating system devices; any device running Google. The operating system of the device, 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.

[0073] 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, send one or more requests to servers 320 and 325 via an application 311 executing on client device 310. These requests can be associated with data retrieved from 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, servers 320 and 325 can be configured to retrieve the requested data from one or more databases 335. Based on the requested data received from one or more databases 335, servers 320 and 325 can be configured to send the received data to client device 310 in response to the one or more requests.

[0074] 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 a dedicated security device configured to perform one or more cryptographic operations. HSMs 330 may be configured such that keys are never leaked outside the HSM 330, but are instead stored 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.

[0075] System 300 may include one or more networks 315. In some examples, network 315 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect client devices 315 to servers 320 and 325. For example, network 315 may include one or more of the following: fiber optic network, passive fiber optic network, cable network, cellular network, Internet network, 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 networks thereof. 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.

[0076] 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 Internet networks, wireless communication networks, cellular networks, and any combination thereof. Network 315 may further include a single network, or any number of the aforementioned exemplary network types, which operate as independent networks or cooperate with each other. Network 315 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 315 may be converted to one or more protocols of network devices, or converted from other protocols to one or more protocols of network devices. Although network 315 is described as a single network, it should be understood that, depending on one or more examples, network 315 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks (e.g., credit card association networks), and home networks.

[0077] 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 313 and one or more card readers 313. For example, one or more applications 311 (such as software applications) may be configured to, for example, enable network communication with one or more components of system 300 and send and / or receive data. It should be understood that, although Figure 3Only a single component instance 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.

[0078] Application 311 of any client device 310 can communicate with contactless card 305 using short-range wireless communication (e.g., NFC). Application 311 can be configured to interface with card reader 313 of client device 310 configured to communicate with 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 distance.

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

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

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

[0082] Server 320 may include a web server communicating with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more 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 payment and transaction requests.

[0083] Figure 4 A method 400 for key decentralization according to an example of this disclosure is shown. Method 400 may include... Figure 2 The transmitting device 205 and receiving device 210 mentioned herein are similar transmitting and receiving devices.

[0084] For example, a sender and a receiver may wish 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 can be involved as long as each party shares the same shared confidential symmetric key. In some examples, the same master symmetric key may be provided to both the sending and receiving devices. Furthermore, it should be understood that either party or device holding the same confidential symmetric key can perform the functions of the sending device, and similarly, either party holding the same confidential symmetric key can perform the functions of the receiving device. In some examples, the symmetric key may include a shared confidential symmetric key that remains confidential to all other parties involved in the exchange of secure data besides the sending and receiving devices. It should also be understood that the same master symmetric key may be provided to both the sending and receiving devices, and further, a portion of the data exchanged between the sending and receiving devices 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 and receiving devices.

[0085] At box 410, the same master key, such as the same master symmetric key, can be provided to both the sending and receiving devices. The sender can update a counter when the sending device is ready to process sensitive data using symmetric cryptographic operations. Additionally, the sending device can select an appropriate symmetric cryptographic 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 the decentralized value can include any symmetric cryptographic algorithm that generates a decentralized symmetric key of the desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES138; 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 with different input data and the same master key may produce multiple outputs that can be combined as needed to generate a sufficiently long key.

[0086] The sending device can employ a chosen cryptographic 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.

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

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

[0089] At box 430, one or more cryptographic algorithms and a decentralized key can be used to protect sensitive data. A decentralized session key, created by key decentralization using a counter, can be combined with one or more cryptographic algorithms to protect sensitive data. For example, data can be processed using a MAC with a first decentralized session key, and the resulting output can be encrypted using a second decentralized session key to produce protected data.

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

[0091] At box 450, the receiving device can combine a decentralized key with one or more cryptographic algorithms to verify the protected data.

[0092] At box 460, the original data can be verified. If the output of the MAC operation (via the receiving device using the first decentralized session key) matches the MAC output displayed after decryption, the data can be considered valid.

[0093] The next time sensitive data needs to be sent from the sending device to the receiving device, different counter values ​​can be selected to generate different decentralized symmetric keys. By using the master symmetric key and the same symmetric cryptographic algorithm to process the counter values, both the sending and receiving devices can independently generate the same decentralized symmetric key. This decentralized symmetric key, instead of the master symmetric key, is used to protect sensitive data.

[0094] As described above, the sending and receiving devices initially each hold a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Since the decentralized symmetric key is created independently by the sending and receiving devices, it is never transmitted between them. Therefore, an attacker cannot intercept the decentralized symmetric key, and an attacker will never see any data processed using the master symmetric key. Only the small counter value is processed using the master symmetric key; sensitive data is not processed in this way. Therefore, the exposure of side-channel data regarding the master symmetric key is reduced. Furthermore, the sender and receiver can, for example, agree on how often a new decentralized value is created through prior arrangements or other means, and thus create a new decentralized symmetric key. In one embodiment, a new decentralized value and thus a new decentralized symmetric key can be created for each exchange between the sending and receiving devices.

[0095] In some examples, the key decentralization value may include a counter value. Other non-limiting examples of key decentralization values ​​include: a random nonce generated each time a new decentralization key is needed, sent from the sending device to the receiving device; the full value of a counter sent from both the sending and receiving devices; a portion of a counter sent from both the sending and receiving devices; a counter maintained separately by the sending and receiving devices but not sent between them; a one-time cipher exchanged between the sending and receiving devices; and a cryptographic hash of sensitive data. In some examples, parties may use one or more portions of the key decentralization value to create multiple decentralization keys. For example, a counter may be used as the key decentralization value.

[0096] In another example, a portion of the counter can be used as the key decentralization value. If the parties share multiple master key values, multiple decentralization key values ​​can be obtained using the system and process described herein. New decentralization values ​​can be created frequently as needed, and thus new decentralization symmetric keys can be created. In the most secure scenario, a new decentralization value can be created for each sensitive data exchange between the sending and receiving devices. In practice, this can create one-time-use keys, such as one-time session keys.

[0097] In other examples, such as to limit the number of times the master symmetric key is used, the sender at the transmitting device and the receiver at the receiving device may agree to create new decentralized values ​​only periodically, and thus create new decentralized symmetric keys. In one example, this operation could occur after a predetermined number of uses, such as after every ten transmissions between the sending and receiving devices. In another example, this operation could occur after a certain period of time; after a certain period of time following a transmission, or this operation could occur periodically (e.g., at a specified time each day; at a specified time on a specified date each week). In yet another example, this operation could occur each time the receiving device signals to the sending device that it wishes to change the key in the next communication. This operation can be controlled by a policy and can be changed based on, for example, the current level of risk perceived by the receiver at the receiving device.

[0098] Figure 5AOne or more contactless cards 500 are shown. The contactless card 500 may include a payment card issued by a service provider 505 displayed on the front or back of the card 500, such as a credit card, debit card, or gift card. 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 layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical characteristics 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 contactless card to be implemented in the form of a payment card.

[0099] The contactless card 500 may also include identification information 515 displayed on the front and / or back of the card, and a contact pad 520. The contact pad 520 may be configured to establish communication with another communication device (e.g., 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 piece 520 or elsewhere on the substrate 510. The contactless card 500 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card. Figure 5A (Not shown in the image).

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

[0101] Memory 535 can be read-only memory, write-once-read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and contactless card 500 may include one or more of these memories. Read-only memory can be factory-programmed to read-only or can be programmed once. One-time programming provides the opportunity to write once and then read multiple times. Write-once / read-many memory can be programmed at some point after the memory chip leaves the factory. Once programmed, memory cannot be rewritten, but it can 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.

[0102] Memory 535 may 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 configured to execute on one or more contactless cards, such as Java Card applets. However, it should be understood that applet 540 is not limited to Java Card applets, but may include any software application that can run 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 contactless card 500, which distinguishes the user of this contactless card from users of other contactless cards. In some examples, the customer identifier 550 may identify a customer and the account assigned to that customer, and may further identify the contactless card associated with the customer's account.

[0103] The processor and memory elements of the exemplary embodiments described above are based on the contact patch, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the contact patch 520 or completely separate from the contact patch 520, or implemented as other elements besides the processor 530 and memory 535 located within the contact patch 520.

[0104] In some examples, the contactless card 500 may include one or more antennas 555. The one or more antennas 555 may be placed within the contactless card 500 and around the processing circuitry 525 of the contact patch 520. 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 located outside the contact patch 520 and the processing circuitry 525.

[0105] In one embodiment, the coil of the contactless card 500 can be used as the secondary winding of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting off power or amplitude modulation. The contactless card 500 can infer data transmitted from the terminal using gaps in the contactless card's power connection (which can be maintained by one or more capacitors). The contactless card 500 can communicate by switching the load or load modulation on the contactless card's coil. Load modulation can be detected in the terminal's coil by interference.

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

[0107] Figure 6 A short record layout (SR=1) 600 for NDEF according to an example embodiment is shown. One or more applets can be configured to encode OTP into text tags known in NDEF Class 4. 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: known type, text, encoded English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded in ASCII hexadecimal; type length value (TLV) data can be provided as a personal card issuance parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a known index for providing actual dynamic authentication data.

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

[0109] In some examples, data can be stored in the contactless card during personal card issuance by implementing STORE DATA (E2) under Secure Channel Protocol 2. One or more values ​​can be read by the personal card issuing department from the EMBOSS file (in the section specified by the Mini Program ID), and after authentication and establishment of the secure channel, one or more data storage commands can be sent to the contactless card.

[0110] A pUID can contain 16-bit BCD-encoded numbers. In some examples, a pUID can contain 14 numbers.

[0111]

[0112] In some examples, one or more applets can be configured to maintain their personal card issuance state so that personal card issuance is only allowed after unlocking and authentication. Other states can include the standard state of pre-personal card issuance. Upon entering the terminated state, one or more applets can be configured to delete personal card issuance data. In the terminated state, one or more applets can be configured to stop responding to all Application Protocol Data Unit (APDU) requests.

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

[0114] In some examples, one or more applets can be configured to simulate RFID tags. RFID tags can include one or more polymorphic tags. In some examples, different password data is displayed each time a tag is read, indicating the authenticity of the contactless card. Based on one or more applications, NFC reading of the tags can be handled, tokens can be sent to a server, such as a backend server, and the tokens can be verified on the server.

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

[0116] One or more counters can be configured to prevent replay attacks. For example, if a PIN has been obtained and replayed, the PIN should be immediately rejected if it has been read, used, or otherwise skipped by a counter. A counter can be replayed if it has not yet been used. In some examples, the counter updated on the card is different from the counter updated for a 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 one counter.

[0117] In some examples, the counter may be out of sync between the contactless card and one or more servers. For instance, a contactless card might be activated to update the counter and cause the card to generate new communication, but this communication cannot be sent to one or more servers for processing. This can result in the contactless card's counter being out of sync with counters maintained on one or more servers. This could happen unintentionally, such as when the card is placed near a device (e.g., in a pocket with the device), or when the card is misaligned or mispositioned when read at an angle, causing the contactless card to activate its NFC field but be unreadable. If the contactless card is placed near a device, the device's NFC field might activate and power the contactless card, causing the counter there to be updated, but the application on the device fails to receive the communication.

[0118] To keep the counters synchronized, an application, such as a background app, can be executed. This app is configured to detect when the mobile device wakes up and synchronize with one or more servers, indicating that a read performed due to the detection then advances the counter. Since the contactless card's counter may be out of sync with the counters of one or more servers, one or more servers can be configured to allow the contactless card's counter to be updated a threshold number or a predetermined number of times before being read by one or more servers and still be considered valid. For example, if the counter is configured to increment (or decrement) by 1 each time the contactless card is indicated to be activated, one or more servers can allow any counter value they read from the contactless card to be valid, or any counter value to be within a threshold range (e.g., from 1 to 10). Furthermore, one or more servers can be configured to request a gesture associated with the contactless card, such as a user tap, provided that the counter value it reads is greater than 10 but less than another threshold range value (e.g., 1000). After the user taps, authentication is successful if the counter value is within the expected or acceptable range.

[0119] Figure 8 This is a flowchart illustrating key operation 800 according to an example embodiment. For example... Figure 8As 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 (UDKs) for each card. In some examples, the Bank Identifier Number may include a single 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 decentralization. The UDKs (AUTKEY and ENCKEY) can be stored on the card during the personal card issuance process.

[0120] At box 820, the counter is used as decentralization data, so it changes on each use and provides a different session key each time, in contrast to master key derivation where a unique set of keys is generated for each card. In some examples, a 4-byte approach is preferably used for both operations. Therefore, at box 820, two session keys can be created for each transaction via the UDK: one from the AUTKEY and one from the ENCKEY. On the card, for the MAC key (i.e., the session key created via the AUTKEY), the two least significant bytes of the OTP counter can be used for decentralization. For the ENC key (i.e., the session key created via the ENCKEY), the full length of the OTP counter can be used for the ENC key.

[0121] At box 830, a MAC password can be prepared using a MAC key, and the password can be encrypted using an ENC key. For example, a password can be prepared using a MAC session key, and the result can be encrypted with an ENC key before being sent to one or more servers.

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

[0123] For contactless cards, a distinct unique identifier is derived, which can be associated with the Application Master Account (PAN) and PAN serial number encoded in the card. The key can be configured to receive the identifier as input to the master key, allowing one or more keys to be created for each contactless card. In some examples, these decentralized keys may include a first key and a second key. The first key may include an authentication master key (Card-Key-Auth), and can be further decentralized to create a MAC session key used when generating and verifying MAC ciphers. The second key may include an encryption master key (Card-Key-DEK), and can be further decentralized to create an ENC session key used when encrypting and decrypting password-protected data. In some examples, the first and second keys are created by combining the issuer master key with the card's unique ID number (pUID) and the payment app's PAN serial number (PSN) to decentralize the issuer master key. The pUID may include a 16-bit numeric value. As mentioned above, the pUID may include a 16-bit BCD-encoded number. In some examples, the pUID may include a 14-bit numeric value.

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

[0125] In other examples (such as credit cards), numbers provided by one or more servers (such as account numbers or unpredictable numbers) can be used to generate and / or decentralize session keys.

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

[0127] Regarding master key management, two issuer master keys 905 and 910 are required for each section of a folder containing one or more mini-programs. For example, the first master key 905 may include the issuer password generation / authentication key (Iss-Key-Auth), and the second master key 910 may include the issuer data encryption key (Iss-Key-DEK). As further explained in this document, the two issuer master keys 905 and 910 are distributed into card master keys 925 and 930, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 915 and Derived Key Index (pDKI) 920, which serve as background data, can be used to identify which issuer master keys 905 and 910 are used for authentication in password processing. The system performing authentication can be configured to retrieve the values ​​of the contactless card's pNPR 915 and pDKI 920 during authentication.

[0128] In some examples, to improve the security of the solution, session keys (e.g., unique keys for each session) can be derived instead of using a master key. As mentioned above, unique card-derived keys and counters can be used as decentralized data. For example, a different key can be used each time a card is used in an operation to create a Message Authentication Code (MAC) and 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 (Auth-Session-Key 935 and DEK-Session-Key 940) can be generated by one or more applets and can be derived using the Application Transaction Counter (pATC) 945 through 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 derivation method may include: F1 := PATC (2 low-order bytes) || 'F0' || '00' || PATC (four bytes) F1 := PATC (2 low-order bytes) || '0F' || '00' || PATC (four bytes) SK := {(ALG(MK)[F1]) || ALG(MK)[F2]}, where ALG contains the 3DES ECB and MK contains the card-unique derived master key.

[0129] As described in this article, one or more MAC session keys can be derived using the two least significant bytes of the pATC 945 counter. The pATC 945 is configured to update with each tap of the contactless card, and the card master keys Card-Key-AUTH 925 and Card-Key-DEK 930 are further distributed into session keys Aut-Session-Key 935 and DEK-Session-KEY 940. The pATC 945 can be initialized to zero during personal card issuance or app initialization. In some examples, the pATC counter 945 can be initialized at or before personal card issuance and can be configured to increment by 1 with each NDEF read.

[0130] Furthermore, each card update can be unique and can be assigned through personal card issuance or algorithmically via pUID or other identifying information. For example, odd-numbered cards increment or decrement by 2, while even-numbered cards increment or decrement by 5. In some examples, updates can also change during sequential reading, allowing a card to increment sequentially by 1, 3, 5, 2, 2, ... and so on. Specific sequences or algorithmic sequences can be defined at the time of personal card issuance or through one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to infer updates from a small number of card instances.

[0131] The authentication message can be transmitted as the content of a hexadecimal ASCII formatted text NDEF record. In some examples, it only includes authentication data followed by an 8-byte random number of the MAC. In some examples, the random number can precede the password A and can be a block size. In other examples, there is no restriction on the length of the random number. In further examples, the total data (i.e., the random number plus the password) can be a multiple of the block size. In these examples, an additional 8-byte block can be added to match the block generated by the MAC algorithm. As another example, if the algorithm used employs a 16-byte block, it can even use a multiple of the block size, or the output can be automatically or manually padded to a multiple of that block size.

[0132] 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 associate with the EMV ARQC authentication method. As mentioned above, the key used for this calculation can include the session key AUT-Session-Key 935. As mentioned above, the two low-order bytes of the counter can be used to distribute one or more MAC session keys. As described below, AUT-Session-Key 935 can be used for MAC data 950, and the resulting data or cipher A955 and random number RND can be encrypted using DEK-Session-KEY 940 to create cipher B or output 960 sent in a message.

[0133] In some examples, one or more HSM commands can be processed for decryption so that the final 16 (binary, 32 hexadecimal) bytes can include 3DES symmetric encryption using CBC mode, which includes a random number followed by a zero IV (Indexed Noise) of 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 used for the session key derivation is the least significant byte of the counter pATC 945.

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

[0135]

[0136]

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

[0138]

[0139]

[0140]

[0141] 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 a specific card using 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 to generate password A 955 and RND, which can be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the message's Ver, UID, and pATC fields, is processed using the recreated Aut-Session-Key with the MAC field to create a MAC output (e.g., MAC'). If the MAC address matches the password A 955, it indicates that both message decryption and the MAC check have passed. Then, the pATC can be read to determine its validity.

[0142] During the authentication session, one or more applications can generate one or more passwords. 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 (e.g., Aut-Session-Key 935). Input data 950 can take the form of: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses can include a 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 4-byte binary random number injected into the card at the time of issuance of the personal card known to the authentication service. During the authentication session, the shared secret is not provided to the mobile application from one or more applets. Method 2 padding can include appending a mandatory 0x'80' byte to the end of the input data and appending a 0x'00' byte to the end of the resulting data until the 8x boundary is reached. The resulting password can include a length of 8 bytes.

[0143] In some examples, one advantage of using MAC ciphers to encrypt an unshared random number as the first block is that this random number serves as an initialization vector when using the CBC (Block Chaining) mode of a symmetric encryption algorithm. This allows for "scrambling" between blocks without having to pre-establish a fixed or dynamic IV.

[0144] By including the Application Transaction Counter (pATC) as part of the data contained in the MAC cipher, the authentication service can be configured to determine whether the value transmitted in the plaintext data has been tampered with. Furthermore, by including the version in one or more ciphers, it becomes difficult for an attacker to intentionally misrepresent the application version in an attempt to weaken the cipher solution. In some examples, the pATC starts at zero and is updated by 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or less than a previously received value by the authentication service, this can be interpreted as an attempt to replay an old message, and authentication can be rejected. In some examples, if the pATC is greater than a previously received value, it can be evaluated to determine if it is within an acceptable range or threshold; if it is outside or outside that range or threshold, authentication can be considered a failure or unreliability. In MAC operation 936, the Aut-Session-Key 935 is used, and the data is processed via MAC 950 to produce an encrypted MAC output (cipher A) 955.

[0145] To provide additional protection against brute-force attacks that expose the key on the card, the MAC cipher 955 needs to be encrypted. In some examples, the data or cipher A 955 to be 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 are configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include 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, cipher B 960. The data 955 may be encrypted using 3DES in cipher block chaining mode, thus ensuring that an attacker must perform any attack on all ciphertext. As a non-limiting example, other algorithms, such as the Advanced Encryption Standard (AES), may be used. In some examples, the vector can be initialized using 0x'00000000000000000'. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used, because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random occurrence.

[0146] 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 in plaintext from one or more mini-programs to the mobile device during the authentication session: version number; which is used to determine the encryption method used and the message format used to verify the password, so that the method can 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.

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

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

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

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

[0151] Figure 11 An exemplary process 1100 for key decentralization is illustrated according to an example. Initially, two different master keys may be provided to the sender and the receiver. 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 (which can be updated at box 1110), as well as other data, such as data to be protected that is ensured to be shared with the receiver.

[0152] At box 1130, the sender can use the data encryption master key to generate a data encryption-derived session key to encrypt the counter value, and the sender can also use the data integrity master key to generate a data integrity-derived session key to encrypt the counter value. In some examples, the entire counter value or a portion of the counter value can be used between the two encryption processes.

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

[0154] At box 1130, the sender uses a data integrity session key and a cryptographic MAC algorithm to process the data to be protected via cryptographic MAC operations. A MAC can be generated using one of the session keys (AUT-Session-Key) based on the protected data (including plaintext and shared secrets).

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

[0156] At box 1150, the encrypted MAC is sent from the sender to the receiver, containing enough information to identify additional confidential information (such as shared secrets, master keys, etc.) used to verify the cipher.

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

[0158] At box 1170, the protected data is decrypted by combining a session key derived from data encryption with a symmetric decryption operation. The exchanged data then undergoes further processing. In some examples, after extracting the MAC, it needs to be reconstructed and matched. For example, when verifying a password, the password 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.

[0159] At box 1180, a session key derived from data integrity and a password MAC operation are used together to verify that the protected data has not been modified.

[0160] 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. A MAC is correct only if decryption is successful and produces the correct MAC value. Successful decryption indicates that the encrypted MAC was decrypted using the correctly derived encryption key. Since the derived session key is created using a master key known only to the sender (e.g., the sending device) and the receiver (e.g., the receiving device), it can be assumed 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.

[0161] Afterward, the two derived session keys can be discarded, and the counter value can be updated during the next iteration of data exchange (returning to box 1110), and a new set of session keys can be created (at box 1130). In some examples, combined random data can be discarded.

[0162] 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 in the first process, the user can participate in one or more actions associated with one or more contactless cards. In practice, security factor authentication may simultaneously 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, a kiosk, a terminal, a tablet computer, or any other device configured to process received tap gestures.

[0163] In some examples, a contactless card can be tapped against a device such as one or more computer kiosks or terminals to verify identity in response to the purchase of a transactional item, such as coffee. By using contactless cards, a secure method for verifying identity in loyalty programs can be established. This securely verifies identity in a way different from simply scanning a barcode, thereby enabling, for example, the acquisition of rewards, coupons, offers, or the receipt of benefits. For example, encrypted transactions can occur between the contactless card and a device that can be configured to process one or more tap gestures. As described above, one or more applications can be configured to verify a user's identity, for example, via one or more tap gestures, and then prompt the user to react or respond. In some examples, data such as reward points, loyalty points, bonus points, healthcare information, etc., can be written back to the contactless card.

[0164] In some examples, a contactless card can be tapped onto a device such as a mobile device. As mentioned above, a user's identity can be verified through one or more applications, which then grant the user the desired benefits based on the authentication.

[0165] In some examples, a contactless card can be activated by tapping it against 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 when it is 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 accounts or restricted information, or other functions. In some examples, a tap can activate or launch the device's application, 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 when it is near the card reader will initiate the application's download, for example, by navigating to the application download page. After installation, tapping the contactless card can activate or launch the application, then initiate the contactless card's 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.

[0166] 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, applet, etc., may perform activation. Activation may be performed on the client device, or the client device may simply act as a channel 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). Furthermore, depending on the type of device involved, the application may output (for transmission) different and / or additional data to the account server. For example, such data may include merchant-related information, such as merchant type and merchant ID, and information associated with the device type itself, such as POS data and POS ID.

[0167] In some embodiments, the example authentication communication protocol may mimic the offline dynamic data authentication protocol of the EMV standard typically performed between a transaction card and a point-of-sale device, with some modifications. For example, since the example authentication protocol itself is not used to complete a payment transaction with the card issuer / payment processor, certain data values ​​are not required, and authentication can be performed without 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 depends on whether the card 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 virtual transaction value (i.e., a value that the card issuer can recognize sufficient to allow activation) may be passed 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 count exceeding a buffer value may result in a mild rejection, which requires further verification before accepting the transaction. In some implementations, the buffer value of the transaction counter may be modified to avoid rejecting legitimate transactions.

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

[0169] If the contactless card taps to point to running Apple... For devices with operating systems such as iPhone, iPod, or iPad, contactless cards can be recognized. The operating system transmits appropriate data to communicate with the device. For example, a contactless card can use an NDEF tag, such as NFC, to provide the encrypted identity information necessary for card authentication. Similarly, if a contactless card is tapped to run... Operating system devices (e.g.) If it's a smartphone or tablet, then the contactless card can be recognized. The operating system transmits appropriate data to communicate with the device (e.g., encrypted identity information required for authentication via the methods described herein).

[0170] As another example, a contactless card tap can be directed at a POS device, including but not limited to kiosks, checkout counters, payment stations, or other terminals. Upon tapping, the contactless card can identify the POS device and send only the information necessary for the operation or transaction. For instance, after identifying a POS device for completing a commercial transaction, the contactless card can transmit the payment information required to complete the transaction according to the EMV standard.

[0171] In some examples, the POS device involved in the transaction can request or specify additional information that will 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 the additional information required to complete the operation or transaction.

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

[0173] In some examples, such as shopping malls, grocery stores, and convenience stores, customers can tap a contactless card on a device without having to open an app to indicate their intention or purpose to make one or more purchases using reward points, loyalty points, coupons, offers, etc. This reveals the intent behind the purchase.

[0174] In some examples, one or more apps can be configured to verify user identity by determining that they are launched via one or more tap gestures of a contactless card, launched at 3:51 p.m., and processed or a transaction occurs at 3:56 p.m.

[0175] 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 lowest-cost purchase, and / or reconfiguring to another action in real time.

[0176] In some examples, data can be collected upon a tap to perform biometric / gesture authentication. For instance, a password-protected, and difficult-to-intercept unique identifier can be sent to one or more backend services. This 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.

[0177] In some examples, the device may include an app that splits or reconciles payment bills among multiple individuals. For instance, each person may hold a contactless card and be a customer of the same issuing financial institution, but this is not required. Each of these individuals receives push notifications for split purchases on their device via the app. Instead of accepting a tap instructing payment from only one card, other contactless cards may also be used. In some examples, individuals with different financial institutions may hold contactless cards to provide information to initiate one or more payment requests from the individual tapping the card.

[0178] The following exemplary use cases describe examples of a specific implementation of this disclosure. These are for illustrative purposes only and not for limitation. In one scenario, a first friend (the payer) owes a second friend (the payee) money. The payer wants to pay using a contactless card via the payee's smartphone (or other device) instead of going to an ATM or transacting through a peer-to-peer app. The payee logs into the appropriate app on their smartphone and selects a payment request option. In response, the app requests authentication via the payee's contactless card. For example, the app outputs a display prompting the payee to tap their contactless card. Once the payee taps the contactless card on their smartphone screen with the app enabled, the contactless card is read and verified. Next, the app displays a prompt prompting the payer to tap their contactless card to make the payment. After the payer taps their contactless card, the app reads the card information and sends the payment request to the payer's card issuer via the associated processor. The card issuer processes the transaction and sends a transaction status indication to the smartphone. The app then outputs to display the transaction status indication.

[0179] In another example, 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 their device (e.g., a mobile device such as a smartphone) instead of by calling the phone number associated with the card issuer or visiting a website. The customer can select the card activation function from the app menu displayed on the device's screen. The app prompts the customer to tap their credit card on the screen. After tapping the credit card on the device screen, the app can be configured to communicate with a server (e.g., the card issuer's server that activated the customer's card). The app can then display a message indicating successful card activation. Card activation is then complete.

[0180] Figure 12 A method 1200 for card activation according to an example embodiment is illustrated. For example, card activation may be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers may refer to those previously referenced above. 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.

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

[0182] At box 1220, one or more portions of dynamically generated data can be transmitted to the device's application via NFC or other wireless communication. For example, tapping a card near the device allows 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 guide 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 perform a required gesture, placement, or orientation of the card toward the device's surface, such as placing the card at an angle or flat on, near, or close to the surface of the device. In response to performing the required gesture, placement, and / or orientation of the card, the device can continue transmitting one or more encrypted portions of the data received from the card to one or more servers.

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

[0184] At 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 by one or more servers indicates a successful match, the card may be activated. If the comparison of one or more decrypted portions of the data by one or more servers indicates a failed match, one or more procedures may occur. For example, in response to determining a failed match, the user may be prompted to tap, swipe, or wave the card again. In this case, there is a predetermined threshold including the number of attempts allowed to activate the card. Alternatively, the user may receive a notification on their device, such as a message indicating a failed card verification attempt, and call, email, or text message the associated service to request assistance in activating the card; or receive a notification on their device, such as a phone call indicating a failed card verification attempt, and call, email, or text message the associated service to request assistance in activating the card; or receive a notification, such as an email indicating a failed card verification attempt, and call, email, or text message the associated service to request assistance in activating the card.

[0185] At box 1250, one or more servers can send 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. The device can be configured to display a message indicating successful card activation. Once the card is activated, it can be configured to stop dynamically generating data, thus preventing fraudulent use. In this way, the card can be left unactivated thereafter, and one or more servers can be notified that the card has been activated.

[0186] In another example scenario, a customer wants to access their financial account on their mobile phone. The customer launches an application (e.g., a banking app) on their mobile device and enters their username and password. At this stage, the customer can see first-level account information (e.g., recently purchased items) and can perform first-level account options (e.g., paying with a credit card). However, if the user attempts to access second-level account information (e.g., spending limits) or perform second-level account options (e.g., transferring funds to an external system), they must have second-level factor authentication. Therefore, the application requests the user to provide a transaction card (e.g., a credit card) for account verification. The user then taps their credit card on their mobile device, and the application verifies that the credit card corresponds to the user's account. Afterward, the user can view second-level account data and / or perform second-level account functions.

[0187] Example embodiments of the systems and methods described herein are configured to enhance the security of counter-based one-time passwords (OTPs). Many OTP systems rely on the difficulty of brute-force attacks based on guessing all key pairs of password hashes or encryptions. However, the systems and methods disclosed herein increase the difficulty of this process, thereby improving the security of counter-based OTPs by making the plaintext components more difficult to guess and generate. Therefore, by using a different starting counter or a unique increment for each OTP device, the difficulty of inference based on one or more captured samples is increased.

[0188] Figure 13 A one-time password authentication system 1300 according to an example embodiment is illustrated. As discussed further below, system 1300 may include a contactless card 1310, a client device 1320, one or more networks 1330, and at least one server 1340. Although Figure 13 A single component instance is shown, but system 1300 can include any number of components.

[0189] System 1300 may include one or more contactless cards 1310. In some examples, the contactless card 1310 may communicate wirelessly with client device 1320, such as via NFC communication. The contactless card 1310 may refer to... Figure 5A and Figure 5B The same or similar components are shown. In some examples, the contactless card 1310 may include a substrate, a counter, a processor, and a memory containing at least one small program.

[0190] The contactless card 1310 can be configured to generate a one-time password and send it to the client device 1320, such that a counter is adjusted each time a password is generated. The client device 1320 can be configured to send the password once, and at least one server 1340 can be configured to receive the one-time password for authentication.

[0191] In some examples, the counter can be configured to start with a different value for each account. For example, the counter could start at 10 for the first account, while it could start at 100 for the second account.

[0192] In some examples, the counter can be configured to increment or decrement in a non-monotonic sequence. For example, a forward linear hash chain can be used for authentication and to avoid collisions, making it possible to generate one or more unpredictable hash values. Different increment or decrement values ​​can be used, for example. As another example, the counter could increment (or decrement) by 2 for the first account and by 7 for the second account. The increment or decrement does not need to be a single value; therefore, the increment or decrement can be based on an assigned or derived sequence. As another example, the assigned sequence could include a counter configured to increment (or decrement) by 1, then by 3, then by 9, and so on, for the first account, and by 7, then by 2, then by 5, and so on, for the second account. As another example, the assigned sequence could contain only prime numbers (e.g., 2, 3, 5, 7, 11, 13, 17, etc.), and the counter value could indicate a point in the sequence. As another example, the assigned sequence can be derived from an equation that incorporates previous counter values. As an example, and not a limitation, the sequence values ​​can be derived from the following equation: New_Value N = Previous_Value N * 3 - 1. Therefore, if Previous Value N is 1, the sequence would be 2, 5, 14, 41, 122, and so on. As another example, if the initial value is zero, the sequence begins with -1.

[0193] The incrementing or decrementing of a counter can be associated with one or more cryptographic algorithms. In some examples, one or more cryptographic algorithms can be used to create a sequence. One or more cryptographic algorithms can include one or more cryptographic hash functions that implement additional security. As an example, and not a limitation, forward linear hashing can be used. In this example, the sequence can begin with a random value, and that value can be cryptographically hashed to generate a first counter value. Subsequent counter values ​​can then be generated by cryptographically hashing the immediately preceding counter value; for example, a second counter value can be created by cryptographically hashing the first counter value, a third counter value can be created by cryptographically hashing the second counter value, and so on.

[0194] In some examples, the receiving and sending devices can each begin with a common start value and key. This key is also known to one or more servers associated with the device performing the operation. One or more cryptographic algorithms (e.g., HMAC, CMAC, symmetric encryption) can be used to encrypt the common start value to obtain a first counter value. If the length of the encrypted output is too large for the allocated memory, the output may be truncated to the required number of bytes and used as the first counter value. The truncated value can then be incremented and encrypted again to obtain the next counter value. The increment-encryption sequence can be repeated for each instance requiring a counter.

[0195] In some examples, the counter can be encrypted before each exchange. For instance, a first counter value can be generated from a starting value (e.g., a preset value, a random number, or other specified value) by encrypting the starting value. Then, a second counter value can be generated by encrypting the first counter value, and a third counter value can be generated by encrypting the second counter value, and so on.

[0196] A counter can be a driver of the cryptographic operations necessary to generate a one-time password value from a starting point. For example, a counter can determine the number of cryptographic operations required to generate a one-time password value.

[0197] In some examples, one or more cryptographic algorithms can be selected, allowing the expectation of one or more of the following cryptographic algorithms. First, the selected algorithm must be chosen based on the duration of a gesture (e.g., tap) made towards the device 1320 for the contactless card. For example, it may be desirable to avoid selecting algorithms with long durations or long processing times. Therefore, the speed of the selected algorithm depends on the processing power, memory limitations, and other associated available computing resources for performing the operations associated with the selected algorithm. Second, the selected algorithm must be chosen so that the generated output values ​​are not too large to overlap quickly. As used herein, "overlap" refers to a sequence of output values ​​that repeats itself. In some examples, the maximum value of the counter may be exceeded, and the counter may return to zero. This result is acceptable if a return to zero is expected. In a simple example of a numeric counter with a value of 1 and a maximum value of 1,000, it is allowed for the counter to reach 1,000 and then reset to 0. Conversely, it is not allowed for the counter value to repeat 1,000 times or to repeat multiple times with any value. Cryptographic techniques may produce non-overlapping counter values. Cryptographic algorithms that generate random and unpredictable values ​​sometimes produce the same values ​​as previously generated values, but this repetition is unpredictable, and the sequence itself does not repeat.

[0198] In some examples, overlap can occur when the counters exceed the value that can be represented within the number of digits allocated to the counter variable. For instance, an algorithm needs to be chosen that constrains the range of generated numbers to ensure that the counters overlap for a longer period. This helps prevent replay attacks.

[0199] In some examples, the derived sequence may include at least one of account information and session information. For account information, this information may include multiple parameters, including at least one of a unique identifier, a shared secret, a card serial number, card information and address information, card programming time, or any combination thereof and / or a portion thereof. One or more of the multiple parameters may be dynamic, such as a unique card identifier. In some examples, one or more parameters may be combined with another parameter to produce the derived sequence. By way of example and not limitation, account information can be used as a seed for a cryptographic algorithm to derive a sequence, starting point, increment or decrement, or any combination thereof. In some examples, one or more multipliers may be used to generate a string of numbers to determine the value of the increment or decrement. It should be understood that all devices utilizing one-time ciphers according to this disclosure can have the same OTP generation method and the same starting value, which simplifies and streamlines manufacturing and production. However, as described herein, by utilizing the data described above, which is unique to each OTP device, to decentralize the input or output of OTP computation, unique OTP sequences can be constructed. For session information, this information may include one or more values ​​(e.g., random values) that may be exchanged during a session established between device 1320 and at least one server 1340. For example, whenever a counter is read during a session, one or more protocols (such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL)) encrypt data transmitted between device 1320 and at least one server 1340, wherein the sequence portion of establishing the session includes exchanging random values.

[0200] System 1300 may include client device 1320, which may be a computer with network capabilities. As referred to herein, a computer with network capabilities may include, but is not limited to, computer equipment or communication equipment, such as servers, network equipment, personal computers (PCs), workstations, mobile phones, telephones, handheld PCs, personal digital assistants (PDAs), thin clients, thick clients, Internet browsers, or other devices. Client device 1320 may also be a mobile device; for example, a mobile device may include... iPhone, iPod, iPad, or any other device running Apple products Mobile devices running operating systems; any device running Microsoft operating systems. The device is an operating system; any device running the Android operating system, and / or any other smartphone or similar wearable mobile device. Device 1320 may, for example, communicate data via one or more networks 1330 and contactless card 1310.

[0201] In various examples according to this disclosure, device 1320 of system 1300 may execute one or more applications, such as one or more software applications, configured to communicate with one or more components of system 1300 and send and / or receive data. Device 1320 may communicate with at least one server 1340 via one or more networks 1330 and may operate as a corresponding front-end to back-end pair with server 1340. Device 1320 may, for example, send one or more requests to at least one server 1340 via a mobile device application executing on device 1320. The one or more requests may be associated with data retrieved from at least one server 1340. Server 1340 may receive one or more requests from device 1320. Based on one or more requests from device 1320, at least one server 1340 may be configured to retrieve the requested data from one or more databases (not shown). Based on the received requested data from one or more databases, at least one server 1340 may be configured to send the received data to device 1320 in response to one or more requests.

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

[0203] Furthermore, network 1330 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks (WANs), wireless personal area networks (WANs), local area networks (LANs), or global networks such as the Internet. Additionally, network 1330 may support Internet networks, wireless communication networks, cellular networks, and any combination thereof. Network 1330 may further include a single network, or any number of the aforementioned exemplary network types, which operate as independent networks or cooperate with each other. Network 1330 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 1330 may be converted to one or more protocols of network devices, or converted from other protocols to one or more protocols of network devices. Although network 1330 is described as a single network, it should be understood that, depending on one or more examples, network 1330 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks (e.g., credit card association networks), and home networks.

[0204] System 1300 may include at least one server 1340. In some examples, at least one server 1340 may include one or more processors coupled to memory. Server 1340 may be configured as a central system, server, or platform to control and invoke various data at different times to perform multiple workflow actions, thereby performing one or more functions described herein. Server 1340 may be configured to connect to one or more databases (not shown). Server 1340 may connect to at least one device 1320. In some examples, server 1340 may be configured to receive and authenticate a one-time password from device 1320. Authentication may include matching the one-time password against information accessible to device 1320. In some examples, device 1320 may communicate data with at least one server 1340, and at least one server 1340 may be configured to perform authentication. Authentication may include matching the one-time password against information accessible to device 1320. In some examples, device 1320 may communicate data with at least one server 1340, and at least one server 1340 may be configured to perform authentication. At least one server 1340 may be configured to provide device 1320 with a first access level associated with one or more services when authentication of the one-time password is successful. In some examples, at least one server 1340 may be configured to provide device 1320 with a second access level associated with one or more services, including restricted or constrained access, when authentication of the one-time password is unsuccessful.

[0205] Figure 14This is a flowchart illustrating the operation of a method 1400 for protecting a counter-based OTP via data communication with an OTP device, according to an example embodiment. The components used to perform steps 1410 to 1440 may refer to... Figure 13 The same or similar components shown include, but are not limited to, contactless card 1310, device 1320 (such as client device or OTP device), one or more networks 1340, and at least one server 1340.

[0206] like Figure 14 As shown, at block 1410, method 1400 may include sending one or more one-time passwords to a device. For example, a contactless card may create one or more one-time passwords and send them to an OTP device. In some examples, the contactless card may communicate wirelessly with the OTP device, such as via NFC communication. The contactless card may include a substrate, a counter, a processor (e.g., an EMV chip), and a memory containing at least one applet.

[0207] The contactless card can be configured to generate a one-time password and send it to the OTP device, causing a counter to be adjusted each time a password is generated. The counter can be adjusted using any of the methods described herein. The OTP device can be configured to send the password once, and at least one server can be configured to receive the one-time password for authentication.

[0208] At box 1420, the OTP device can receive one or more one-time passwords from a contactless card. Once received, the OTP device can send one or more one-time passwords to at least one server for verification.

[0209] At box 1430, one or more one-time passwords can be verified, and a counter can be updated. For example, at least one server can be configured to verify one or more one-time passwords received from an OTP device, wherein the contactless card counter can be updated each time the one or more one-time passwords are generated.

[0210] At box 1440, a first access level can be provided to the OTP device based on authentication. For example, at least one server can be configured to provide the OTP device with a first access level associated with one or more services upon successful authentication of one or more one-time passwords. For example, at least one server may include one or more processors coupled to memory. The at least one server may be configured as a central system, server, or platform to control and invoke various data at different times to perform multiple workflow actions, thereby performing one or more functions described herein. At least one server may be configured to connect to one or more databases (not shown). At least one server may connect to the OTP device. In some examples, at least one server may be configured to receive and authenticate a one-time password from the OTP device. Authentication may include matching the one-time password against information accessible to the OTP device. In some examples, the OTP device may communicate data with at least one server, and at least one server may be configured to perform authentication. Authentication may include matching the one-time password against information accessible to the OTP device. In some examples, the OTP device may communicate data with at least one server, and at least one server may be configured to perform authentication. At least one server may be configured to provide the OTP device with a first access level associated with one or more services upon successful authentication of a one-time password. In some examples, at least one server can be configured to provide the OTP device with a second level of access associated with one or more services, including restricted or constrained access, if the verification of a one-time password fails. Verification attempts can be repeated as needed or upon receiving another one-time password.

[0211] In other examples, the OTP device may not send a one-time password to at least one server. In these examples, upon receiving the password, the OTP device may send one or more information requests to at least one server, and the OTP device itself may perform verification of the one-time password. The OTP device may then notify at least one server of the verification result. If the verification is successful, at least one server may provide access to one or more services; if the verification fails, it may restrict or deny access, and may perform other verification attempts as described above.

[0212] 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 the card or performing other actions on the card).

[0213] Throughout the specification and claims, unless the context clearly indicates otherwise, the following terms have at least the meaning explicitly associated herein. 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 specified or clearly indicated from the context to the singular form.

[0214] Numerous specific details have been set forth in this specification. However, it should be understood that implementations of the disclosed techniques may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail to avoid obscuring the understanding of this specification. References to “some examples,” “other examples,” “an example,” “various examples,” “an embodiment,” “some embodiments,” “example embodiments,” “various embodiments,” “an implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that implementations of the disclosed techniques described in this way may include specific features, structures, or characteristics, but not every implementation must include that specific feature, structure, or characteristic. 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 this may be indicated.

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

[0216] While some implementations of the disclosed technology have been described in conjunction with what are currently considered the most practical and diverse implementations, it should be understood that the disclosed technology is not limited to the disclosed implementations, but rather is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for purposes of limitation.

[0217] This written description uses examples to disclose certain implementations of the disclosed technology, including best practices, and also enables any person skilled in the art to practice specific implementations of the disclosed technology, including making and using any device or system and performing any incorporated methods. The patentable scope of certain implementations of the disclosed technology is defined in the claims and may include other examples that would occur to a person skilled in the art. These other examples are intended to be within the scope of the claims, provided that they have structural elements that do not differ from the literal language of the claims, or that they include equivalent structural elements that do not substantially differ from the literal language of the claims.

Claims

1. A contactless card, comprising: processor; as well as The memory includes a counter. The processor is configured as follows: Generate a one-time password. Send the one-time password for authentication, and The counter is adjusted with a non-monotonic sequence each time a one-time password is generated. The non-monotonic sequence is created by one or more cryptographic algorithms.

2. The contactless card of claim 1, wherein the value of the counter is adjusted to avoid premature overlap of the counters.

3. The contactless card according to claim 1, wherein the cryptographic algorithm encrypts the starting value to obtain one or more additional counters.

4. The contactless card of claim 3, wherein the processor is further configured to truncate the output to a required number of bytes if the length of the output is too large for the allocated memory, and use the truncated output as a first counter value.

5. The contactless card of claim 4, wherein the processor is further configured to obtain the next counter value by incrementing and encrypting the truncated output.

6. The contactless card according to claim 1, wherein adjusting the counter comprises: For the first account, the counter is incremented by the first counter value, and For the second account, the counter is decremented by the next counter value.

7. The contactless card of claim 1, wherein one or more servers are configured to allow the contactless card's counter to be updated a predetermined number of times and remain valid before being read by one or more servers.

8. The contactless card of claim 1, wherein adjusting the counter comprises selecting at least one from the group consisting of incrementing the counter with the non-monotonic sequence and decrementing the counter with the non-monotonic sequence.

9. The contactless card of claim 1, wherein the one or more cryptographic algorithms include one or more cryptographic hashes to generate the counter.

10. A method for performing authentication, comprising: The processor generates a one-time password; The processor sends the one-time password for authentication; as well as The processor adjusts the counter in a non-monotonic sequence each time a one-time password is generated; The non-monotonic sequence is created by one or more cryptographic algorithms.

11. The method of claim 10, wherein the cryptographic algorithm encrypts the starting value to obtain one or more additional counters.

12. The method of claim 10, wherein adjusting the counter comprises: For the first account, the counter is incremented by the first counter value, and For the second account, the counter is decremented by the next counter value.

13. The method according to claim 12, wherein: The counter is incremented by the non-monotonic sequence, and The counter is decremented using the non-monotonic sequence.

14. The method of claim 10, wherein the counter is determined to be the number of password operations performed to generate the one-time password.

15. The method of claim 10, wherein the one or more cryptographic algorithms include one or more cryptographic hashes to generate the counter.

16. The method of claim 15, further comprising: The output is truncated to the number of bytes required for the memory allocated to the counter, and The truncated value is incremented and encrypted to obtain the next counter value.

17. A non-transitory computer-readable medium comprising computer-executable instructions, which, when executed on a processor, configure the processor to perform a program comprising the following steps: Generate a one-time password; Send the one-time password for authentication; and The counter is adjusted with a non-monotonic sequence each time a one-time password is generated. The non-monotonic sequence is created by one or more cryptographic algorithms.

18. The non-transitory computer-readable medium of claim 17, wherein the one or more cryptographic algorithms comprise forward linear hashing.

19. The non-transitory computer-readable medium of claim 17, wherein the non-monotonic sequence begins with a random value.

20. The non-transitory computer-readable medium of claim 17, wherein the counter determines the number of cryptographic operations performed to generate the one-time password value.

Images