Systems and methods for secure authentication of contactless cards

Abstract

A secure authentication system is provided, comprising a server including a processor and memory. The server is configured to generate an authentication challenge; store the authentication challenge in memory; send the authentication challenge to a user device; generate a session key based on a master key; store the session key in memory; receive an encrypted message authentication code (MAC) ciphertext incorporating the authentication challenge from the user device; decrypt the encrypted MAC ciphertext using one or more encryption algorithms and the session key; and validate the authentication challenge received from the user device.

Description

Technical Field

[0001] The present invention relates to encryption, and more particularly to systems and methods for secure authentication of contactless cards.

Background Art

[0002] Data security and transaction integrity are extremely important for companies and consumers. As electronic transactions come to occupy a large part of business activities, this need continues to grow.

[0003] Although email can be used as a tool for verifying transactions, email is vulnerable to attacks and is susceptible to hacking and other unauthorized access. Short Message Service (SMS) messages can also be used, but they are similarly at risk. Furthermore, data encryption algorithms such as the Triple DES algorithm also have similar vulnerabilities.

[0004] The use of chip-based financial cards has increased, providing more secure features than conventional technologies (e.g., magnetic stripe cards) in face-to-face or online purchases. However, for access to accounts, login authentication information (e.g., username and password) may still be required to verify the identity of the cardholder. However, if the login credentials are leaked, another person can access the user's account. Furthermore, since some contactless cards are read-only cards, there is a potential risk of replay attacks where fraudsters can collect messages from contactless cards at one location and replay them through another channel.

[0005] These and other deficiencies exist. Therefore, it is necessary to provide users with an appropriate solution to overcome these deficiencies and achieve data security, authentication, and verification of contactless cards.

Summary of the Invention

[0006] The disclosed aspects of the technology include systems and methods for secure authentication of contactless cards. Various embodiments describe systems and methods for implementing and managing secure authentication of contactless cards.

[0007] Embodiments of the present disclosure provide a secure authentication system. The system may comprise a server including a processor and memory. The server is configured to generate an authentication challenge; store the authentication challenge in memory; send the authentication challenge to a user device; generate a session key based on a master key; store the session key in memory; receive an encrypted message authentication code (MAC) ciphertext incorporating the authentication challenge from the user device; decrypt the encrypted MAC ciphertext using one or more encryption algorithms and the session key; and validate the authentication challenge received from the user device.

[0008] Embodiments of the present disclosure provide a secure authentication system. The system may include a user device including a processor and memory. The user device is configured to receive an authentication challenge from a server; send the authentication challenge to a contactless card; receive an encrypted MAC ciphertext from the contactless card; and send the encrypted MAC ciphertext to the server.

[0009] Embodiments of the present disclosure provide a contactless card. The contactless card may include: a memory containing a counter value and a card key; a communication interface; and a processor that communicates with the memory and the communication interface. The processor is configured to receive an authentication challenge from a user device when the communication interface is within the communication field of the user device, to create an encrypted MAC ciphertext using the card key, the authentication challenge, and the counter value, and to transmit the encrypted MAC ciphertext to the user device via the communication interface.

[0010] Further features of the disclosed invention and the advantages derived therefrom are described below in more detail with reference to specific exemplary embodiments shown in the accompanying drawings, where similar elements are given the same reference numerals. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a diagram of a contactless card secure authentication system according to an exemplary embodiment. [Figure 2] Figure 2 shows a sequence for providing authenticated access according to an exemplary embodiment. [Figure 3] Figure 3 is a diagram of a data transmission system according to an exemplary embodiment. [Figure 4] Figure 4 is a diagram of a system using a contactless card according to an exemplary embodiment. [Figure 5] Figure 5 is a flowchart showing a key diversification method according to an exemplary embodiment. [Figure 6A] Figure 6A is a diagram of a contactless card according to an exemplary embodiment. [Figure 6B] Figure 6B shows a contact pad of a contactless card according to an exemplary embodiment. [Figure 7] Figure 7 shows a message for communicating with a device according to an exemplary embodiment. [Figure 8] Figure 8 shows a message and message format according to an exemplary embodiment. [Figure 9] Figure 9 is a flowchart showing the key processing according to an exemplary embodiment. [Figure 10] Figure 10 is a diagram of a key system according to an exemplary embodiment. [Figure 11] Figure 11 is a flowchart of a method for generating ciphertext according to an exemplary embodiment. [Figure 12] Figure 12 is a flowchart showing the key diversification process according to an exemplary embodiment. [Figure 13]Figure 13 is a flowchart showing a contactless card secure authentication method according to an exemplary embodiment. [Figure 14] Figure 14 is a flowchart showing a contactless card secure authentication method according to an exemplary embodiment. [Figure 15] Figure 15 is a flowchart showing a server-executable contactless card secure authentication method according to an exemplary embodiment. [Figure 16] Figure 16 is a flowchart illustrating a contactless card secure authentication method that can be performed by a user device, according to an exemplary embodiment. [Figure 17] Figure 17 is a flowchart illustrating a contactless card secure authentication method that can be performed using a contactless card, according to an exemplary embodiment. [Modes for carrying out the invention]

[0012] The following description of embodiments provides non-limiting representative examples with numerical references to illustrate the features and teachings of various aspects of the present invention. Those skilled in the art will recognize from the description of embodiments that the described embodiments can be implemented separately or in combination with other embodiments, and any features and teachings of any embodiment can be combined interchangeably with any features and teachings of any other embodiment. Those skilled in the art who review the description of embodiments will be able to learn and understand the various aspects of the present invention described. The description of embodiments is intended to facilitate understanding of the present invention to the extent that other implementations, not particularly covered but within the knowledge of those skilled in the art who have read the description of embodiments, will be understood to be consistent with applications of the present invention.

[0013] An object of some embodiments of the present disclosure is to incorporate one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform authentication and many other functions that would otherwise require the user to carry another physical token in addition to the contactless card. By adopting a contactless interface, a method of interacting and communicating between the user's device (such as a mobile phone) and the card itself can be provided to the contactless card. For example, the EMV protocol that underlies many credit card transactions includes an authentication process that is sufficient for the Android (registered trademark) operating system, but is a challenge for iOS (registered trademark) which is more restricted and can only be used in a read-only manner with respect to the use of Near Field Communication (NFC). Exemplary embodiments of the contactless card described herein utilize NFC technology.

[0014] FIG. 1 shows a secure authentication system 100 for a contactless card according to an exemplary embodiment. As will be further described below, the system 100 may include a contactless card 105, a client device 110, a network 115, and a server 120. Although FIG. 1 shows a single instance of the components, the system 100 may include any number of components. In the present disclosure, the contactless card may also be referred to as a first device, and the client / user device may also be referred to as a second device.

[0015] The system 100 includes one or more contactless cards 105, which will be further described below with reference to FIGS. 6A to 6B. In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110, for example, by utilizing NFC.

[0016] The client device 110 may be a network-enabled computer. Network-enabled computers as referred to herein may include, but are not limited to, computer devices, or communication devices, such as servers, network appliances, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices. The client device 110 may also be a mobile device, such as an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® Mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices.

[0017] The client device 110 can include a processor and memory. The processor and / or memory may include processing circuitry, which may include additional components such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and anti-tampering hardware as necessary to perform the functions described herein. The client device 110 may further include a display and an input device. 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 a liquid crystal display, light emitting diode display, plasma panel, and cathode ray tube display. The input device may include any device for inputting information available and supported by the client device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder, or camcorder. These input devices can be used to input information and interact with the software and other devices described herein.

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

[0019] A client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a front-end to back-end pair with each of the servers 120. The client device 110 can send one or more requests to the server 120, for example, from a mobile device application running on the client device 110. One or more requests may be associated with retrieving data from the server 120 and / or authenticating the data by the server 120. The server 120 can receive one or more requests from the client device 110. Based on one or more requests from the client device 110, the server 120 may be configured to retrieve the requested data from one or more databases (not shown). Based on the receipt of the requested data from one or more databases, the server 120 may be configured to send the received data to the client device 110 as a response to one or more requests. Based on the receipt of the requested data from one or more databases, the server 120 may be further configured to authenticate / verify the requested data.

[0020] System 100 may include one or more networks 115. In some examples, network 115 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 110 to a server 120. For example, network 115 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless local area networks (LANs), Global System for Mobile Communication, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), and Wi-Fi.

[0021] Furthermore, network 115 may include, but is not limited to, global networks such as telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or the Internet. Additionally, network 115 can support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 115 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 115 can utilize one or more protocols of one or more network elements that are communicatively coupled together. Network 115 can translate to one or more protocols of network devices between other protocols. Although network 115 is shown as a single network, it should be understood that, as one or more examples show, network 115 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks. In this disclosure, the network (such as NFC) through which communication takes place between the contactless card 105 and the client device 110 may be referred to as the first network, and network 115 may be referred to as the second network.

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

[0023] In some examples, the exemplary procedures described herein in accordance with this disclosure can be performed by computer hardware configurations. Such computer hardware configurations may be, but are not limited to, a whole or part of a computer and / or processor that includes one or more microprocessors and uses instructions stored in a non-temporary computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device). For example, the computer-accessible medium may be a contactless card 105, a client device 110, and / or a server 120, or part of the memory of another computing and / or processing configuration.

[0024] In some examples, a computer-accessible medium (for example, a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, or a combination thereof, as described herein) is provided (for example, in communication with a computer hardware device). The computer-accessible medium may contain executable instructions. In addition, or instead of the computer-accessible medium, a storage configuration may be provided that can provide instructions to the computer hardware device. The instructions can configure the computer hardware configuration to perform specific exemplary procedures, processes, and methods, for example, as described above herein.

[0025] Figure 2 is a timing diagram showing an exemplary sequence 200 for providing authenticated access according to one or more embodiments of the present disclosure. The exemplary sequence 200 can be implemented in system 100. Figure 2 may refer to components similar to those shown in Figure 1, such as a contactless card 105 (first device), a client device 110 (second device), and a server 120. Note that the following steps in the exemplary sequence 200 may be performed in a different order, one or more of the following steps may be omitted, and / or one or more additional steps may be added to the exemplary sequence.

[0026] In step 202, server 120 can generate an authentication challenge, such as a random number, random text, or a combination thereof. The authentication challenge may be generated by the server 120's processor through an application deployed on server 120. Server 120 can then store the authentication challenge in server 120's memory and / or database.

[0027] In step 204, the server 120 sends an authentication challenge to the client device 110. The server 120 can then store the authentication challenge in the memory of the client device 110.

[0028] In step 206, the client device 110 sends an authentication challenge to the contactless card 105. The application deployed on the client device 110 communicates with the contactless card 105 (for example, after approaching the contactless card 105) for data transmission between the client device 110 and the contactless card 105. For communication between the application on the client device 110 and the contactless card 105, it may be necessary for the contactless card 105 to be close enough to the card reader (not shown) of the client device 110 to enable NFC data transfer between the application on the client device 110 and the contactless card 105.

[0029] In step 208, the contactless card 105 can generate a session key using a master key and one or more encryption algorithms. The master key and one or more encryption algorithms can be stored in the memory of the contactless card 105. The contactless card 105 can then store the session key in its memory.

[0030] In step 210, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when the contactless card 105 is read by an application on the client device 110. In particular, this may occur during reading, such as NFC reading of a Near Field Radio Data Exchange (NDEF) tag that may be created according to the NFC Data Exchange format. For example, a reader, such as an application on the client device 110, can send a message, such as an applet selection message, using the applet ID of an NDEF generation applet. Once the selection is confirmed, a series of selection file messages followed by read file messages may be sent. For example, the sequence may include "Select Capabilities file", "Read Capabilities file", and "Select NDEF file". At this point, the counter value maintained by the contactless card 105 (for example, stored in the memory of the contactless card 105) may be updated or incremented, followed by a "Read NDEF file". At this point, a MAC message containing a header, authentication challenge, and / or shared secret may be generated. A session key may then be generated. A MAC ciphertext may be constructed from the MAC message via the counter value and authentication challenge using one or more encryption algorithms and the session key, which may include a header, authentication challenge, and / or shared secret.

[0031] In step 212, the MAC ciphertext is concatenated with one or more random data blocks, and the MAC ciphertext and random numbers (RNDs) may be encrypted with a session key and / or one or more encryption algorithms. The ciphertext and header are then concatenated, encoded as ASCII hexadecimal, and can be returned in NDEF message format (in response to the "Read NDEF File" message).

[0032] In some cases, the MAC ciphertext may be transmitted as an NDEF tag, while in others, it may be included with a uniform resource indicator (e.g., as a formatted string).

[0033] In some examples, the application on the client device 110 may be configured to send a request to the contactless card 105, the request including instructions for generating a MAC ciphertext.

[0034] In step 214, the contactless card 105 transmits the encrypted MAC ciphertext to the application on the client device 110. In some examples, the transmission of the encrypted MAC ciphertext is performed via NFC, but this disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth, Wi-Fi, or other wireless data communication means.

[0035] In step 216, the application on the client device 110 transmits the encrypted MAC ciphertext to the server 120 via a network such as network 115.

[0036] In step 218, server 120 generates a session key based on the master key and can store the session key in server 120's memory or database. The master key is similarly stored in server 120's memory or database.

[0037] In step 220, server 120 can decrypt the encrypted MAC ciphertext using one or more encryption algorithms and session keys. For example, server 120 can extract a counter value and an authentication challenge from the encrypted MAC ciphertext.

[0038] In step 222, the server 120 can validate the authentication challenge by verifying the MAC ciphertext. For example, the MAC can be reconstructed by the server 120 using the session key and the authentication challenge, and the reconstructed MAC can be compared with the decrypted MAC to determine if they are the same. If they are the same, the decrypted MAC can be verified and the authentication challenge can be validated. In another example, the server 120 can compare the authentication challenge extracted from the MAC ciphertext with the authentication challenge generated by the server 120 and stored in the server 120's memory. If the two authentication challenges match, the MAC ciphertext can be verified and the authentication challenge can be validated. Thus, the contactless card 105 can be authenticated. The server 120 can also increment a counter value and store the updated counter value in the server 120's memory and / or database.

[0039] In some examples, the verification of the MAC ciphertext may be performed by the client device 110. In some examples, the MAC ciphertext can function as a digital signature for verification purposes. To perform this verification, a public-key asymmetric algorithm (e.g., a digital signature algorithm, such as the RSA algorithm) or other digital signature algorithms such as zero-knowledge protocols may be used.

[0040] Figure 3 shows a data transmission system according to an exemplary embodiment. System 300 may include a transmitting or sending device 305 (e.g., a contactless card) and a receiving or receiving device 310 (e.g., a client device) that communicate with one or more servers 320, for example, via a network 315. The transmitting or sending device 305 may be the same as or similar to the contactless card 105 described above with reference to Figure 1. The receiving or receiving device 310 may be the same as or similar to the client device 110 described above with reference to Figure 1. The network 315 may be the same as the network 115 described above with reference to Figure 1. The server 320 may be the same as the server 120 described above with reference to Figure 1. Although Figure 3 shows a single instance of the components of system 300, system 300 may include any number of the components shown. In system 300, MAC encryption may be verified by a client device (receiving device 310) rather than a server, as in Figure 1, and authentication challenges may also be validated by a client device.

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

[0042] It is also important not to reuse the same key multiple times. Frequent use or reuse of a key can compromise it. Each time a key is used, the attacker is provided with additional samples of data processed by the same encryption algorithm using that key. The more data processed with the same key an attacker possesses, the higher the chance they will discover the key's value. Frequently used keys are vulnerable to a variety of attacks.

[0043] Furthermore, each time a symmetric encryption algorithm is executed, information such as side-channel data about the key used during the symmetric encryption process may be revealed. Side-channel data may include slight power fluctuations that occur when the encryption algorithm is executed while the key is in use. Sufficient measurement of side-channel data can reveal enough information about the key to allow an attacker to recover it. Exchanging data using the same key repeatedly reveals data processed with the same key.

[0044] However, limiting the number of times a particular key is used restricts the amount of side-channel data an attacker can collect, thereby reducing exposure to this attack and other types of attacks. As further described herein, parties involved in the exchange of encrypted information (e.g., sender and receiver) can generate keys independently of the initial shared master symmetric key in combination with a counter value, thereby periodically replacing the shared symmetric key being used without having to rely on any form of key exchange to maintain the parties' synchronization. Periodically changing the shared secret symmetric key used by the sender and receiver makes the above attack impossible.

[0045] Referring again to Figure 3, System 300 may be configured to implement key diversification. For example, a sender and receiver may want to exchange data (e.g., original sensitive data such as authentication for the sending device 305) through their respective devices 305 and 310. As mentioned above, this may include a single instance of the sending device 305 and receiving device 310, but it is understood that one or more sending devices 305 and one or more receiving devices 310 can be involved, as long as each party shares the same shared secret symmetric key. In some examples, the same master symmetric key may be provisioned for the sending device 305 and receiving device 310. Furthermore, it is understood that any party or device holding the same secret symmetric key can perform the functions of the sending device 305, and similarly, any party holding the same secret symmetric key can perform the functions of the receiving device 310. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties other than the sending device 305 and receiving device 310 involved in the exchange of secure data. Furthermore, it is understood that the same master symmetric key is provided to both the transmitting device 305 and the receiving device 310, and that some of the data exchanged between the transmitting device 305 and the receiving device 310 includes at least some of the data, called a counter value. The counter value may include a numerical value that changes each time data is exchanged between the transmitting device 305 and the receiving device 310.

[0046] System 300 may include one or more networks 315. In some examples, network 315 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 305 and one or more receiving devices 310 to a server 320. For example, network 315 may include one or more such as fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless LANs, global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, and Wi-Fi.

[0047] Furthermore, network 315 may include, but is not limited to, global networks such as telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or the Internet. Additionally, network 315 can support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 315 may further include one network or any number of the exemplary types described above, either as a standalone network or working in cooperation with one another. Network 315 can utilize one or more protocols of one or more network elements that are communicatively coupled together. Network 315 can translate to one or more protocols of network devices between other protocols. While network 315 is presented as a single network, it should be understood that, as one or more examples show, network 315 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

[0048] In some examples, one or more transmitting devices 305 and one or more receiving devices 310 may be configured to communicate with each other and send and receive data without going through the network 315. For example, communication between one or more transmitting devices 305 and one or more receiving devices 310 may be performed via at least one of the following: NFC, Bluetooth, RFID, Wi-Fi, etc.

[0049] In block 325, when the transmitting device 305 is preparing to process sensitive data in a symmetric encryption process (for example, when the transmitting device 305 is brought into the NFC field of the receiving device 310), the transmitting device 305, being the sender, can update the counter. Furthermore, the transmitting device 305 can select an appropriate symmetric encryption algorithm, which may include at least one of the following: a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the divergence value may include any symmetric encryption algorithm used as needed to generate a divergence symmetric key of the desired length. Non-restrictive examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not produce a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may produce multiple outputs that can be combined as needed to generate a sufficiently long key.

[0050] In block 330, the transmitting device 305 obtains the selected encryption algorithm and processes the counter value using the master symmetric key. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated for each conversation between the transmitting device 305 and the receiving device 310. The transmitting device 305 then uses the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm and create a diversified symmetric key.

[0051] In some examples, the counter value does not need to be encrypted. In these examples, the counter value may be transmitted between the transmitting device 305 and the receiving device 310 without being encrypted in block 330.

[0052] In block 335, sensitive data can be processed using a diversified symmetric key before sending the result to the receiving device 310. For example, the transmitting device 305 may encrypt the sensitive data using a symmetric encryption algorithm with a diversified symmetric key, and the output may include protected encrypted data (such as a MAC ciphertext or encrypted MAC ciphertext). The sensitive data may include an authentication challenge. The authentication challenge may be generated by the receiving device 310 or server 320 and sent to the transmitting device 305. The transmitting device 305 can then send the protected encrypted data, along with a counter value, to the receiving device 310 for processing.

[0053] In block 340, the receiving device 310 first obtains a counter value, then uses the counter value as the input for encryption and performs the same symmetric encryption using the master symmetric key as the key for encryption. The output of the encryption may be the same diversified symmetric key value created by the sender.

[0054] In block 345, the receiving device 310 receives the protected encrypted data and decrypts the protected encrypted data (encrypted MAC ciphertext) using a symmetric decryption algorithm and a diversified symmetric key.

[0055] In block 350, the original sensitive data is revealed as a result of decrypting the protected encrypted data. For example, the authentication challenge is verified and validated.

[0056] Next, if confidential data needs to be transmitted from the sender to the receiver via the sending device 305 and receiving device 310, different counter values ​​can be selected to generate different diversified symmetric keys, and different authentication challenges may be used within the confidential data. By processing the counter values ​​using the master symmetric key and the same symmetric encryption algorithm, both the sending device 305 and the receiving device 310 can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the confidential data.

[0057] As described above, the transmitting device 305 and the receiving device 310 each initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is created independently by both the transmitting device 305 and the receiving device 310, it is not transmitted between them. Therefore, an attacker cannot intercept the diversified symmetric key and cannot see the data processed with the master symmetric key. Only counter values, not sensitive data, are processed with the master symmetric key. As a result, reduced side-channel data related to the master symmetric key is exposed. Furthermore, the processing of the transmitting device 305 and the receiving device 310 may be controlled by symmetric requirements regarding how often new diversified values, and therefore new diversified symmetric keys, are created. In one embodiment, a new diversified value, and therefore a new diversified symmetric key, may be created with each exchange between the transmitting device 305 and the receiving device 310. Furthermore, a different authentication challenge can be used for the sensitive data with each exchange between the transmitting device 305 and the receiving device 310, which further enhances the security of data transmission.

[0058] In some examples, the key diversification value may include a counter value. Other non-limiting examples of key diversification values ​​include a random nonce generated whenever a new diversification key is needed and sent from the transmitting device 305 to the receiving device 310; the full value of a counter value sent from the transmitting device 305 to the receiving device 310; a portion of a counter value sent from the transmitting device 305 to the receiving device 310; a counter held independently by the transmitting device 305 and the receiving device 310 but not transmitted between the two devices; a one-time passcode exchanged between the transmitting device 305 and the receiving device 310; and a cryptographic hash of sensitive data. In some examples, one or more portions of the key diversification value may be used by the parties to create multiple diversification keys. For example, a counter may be used as the key diversification value. Furthermore, one or more combinations of the exemplary key diversification values ​​described above may be used.

[0059] In another example, a portion of the counter may be used as a key diversification value. If multiple master key values ​​are shared between the parties, multiple diversification key values ​​may be obtained by the systems and processes described herein. New diversification values, and therefore new diversification symmetric keys, may be created as many times as necessary. In the most secure case, a new diversification value may be created for each exchange of sensitive data between the transmitting device 305 and the receiving device 310. In practice, this may create one-time use keys, such as one-time use session keys.

[0060] Figure 4 shows a system 400 that uses a contactless card with an authentication challenge. System 400 may include a contactless card 405, one or more client devices 410, a network 415, servers 420, 425, one or more hardware security modules 430, and a database 435. Although Figure 4 shows a single instance of the components, system 400 may include any number of components.

[0061] The system 400 may include one or more contactless cards 405, which will be further described below with reference to Figures 6A to 6B. In some examples, the contactless card 405 can communicate wirelessly with the client device 410, for example, by NFC communication. For example, the contactless card 405 may include one or more chips, such as radio frequency identification chips configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 405 can communicate with the client device 410 via other means, including but not limited to Bluetooth, satellite, Wi-Fi, wired communication, and / or any combination of wireless and wired connections. According to some embodiments, the contactless card 405 may be configured to communicate with the card reader 413 of the client device 410 via NFC when the contactless card 405 is within range of the card reader 413. In other examples, communication with the contactless card 405 may be performed via a physical interface such as a universal serial bus interface or a card swipe interface.

[0062] System 400 may include client devices 410 which are network-enabled computers. Network-enabled computers as referred to herein may include, but are not limited to, computer devices such as servers, network appliances, personal computers, workstations, mobile devices, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices, or communication devices. One or more client devices 410 may be mobile devices, including, for example, Apple's iPhone, iPod, iPad, or other mobile devices running Apple's iOS operating system, devices running Microsoft's Windows Mobile operating system, devices running Google's Android operating system, and / or other smartphones or similar wearable mobile devices. In some examples, client device 410 may be the same as or similar to client device 110 described with reference to Figure 1.

[0063] The client device 410 can communicate with one or more servers 420 and 425 via one or more networks 415. The client device 410 can send one or more requests to one or more servers 420 and 425 from, for example, an application 411 running on the client device 410. One or more requests may be associated with retrieving data from one or more servers 420 and 425. Servers 420 and 425 can receive one or more requests from the client device 410. Based on one or more requests from the client device 410, one or more servers 420 and 425 may be configured to retrieve the requested data from one or more databases 435 and / or generate an authentication challenge. Based on the receipt of the requested data from one or more databases 435, one or more servers 420 and 425 may be configured to send the received data / generated authentication challenge to the client device 410, the received data / generated authentication challenge in response to one or more requests.

[0064] The system 400 may include one or more hardware security modules (HSMs) 430. For example, one or more HSMs 430 may be configured to perform one or more cryptographic operations as disclosed herein. In some examples, one or more HSMs 430 may be configured as special-purpose security devices configured to perform one or more cryptographic operations. The HSMs 430 may be configured such that keys are not exposed outside the HSMs 430 and are held within the HSMs 430. For example, one or more HSMs 430 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 430 may be included in or capable of data communication with servers 420 and 425.

[0065] System 400 may include one or more networks 415. In some examples, network 415 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 410 to servers 420 and 425. For example, network 415 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, cellular networks, Internet networks, satellite networks, wireless LANs, global systems for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplex-based systems, code division multiple access-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and / or combinations thereof. As a non-limiting example, communication between the contactless card 405 and the client device 410 may include NFC communication, a cellular network between the client device 410 and the carrier, and the internet between the carrier and the backend.

[0066] Furthermore, network 415 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. Additionally, network 415 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 415 may further include one network or any number of the exemplary types described above, operating as standalone networks or in cooperation with one another. Network 415 may utilize one or more protocols of one or more network elements that are communicatively coupled. Network 415 can translate to one or more protocols of network devices between other protocols. Although network 415 is shown as a single network, it should be understood that, as one or more examples show, network 415 may include multiple interconnected networks such as the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

[0067] In various examples provided herein, a client device 410 of system 400 may run one or more applications 411 and include one or more processors 412 and one or more card readers 413. For example, one or more applications 411, such as software applications, may be configured to enable network communication with one or more components of system 400 and to send and / or receive data. Although only a single instance of the components of client device 410 is shown in Figure 4, it can be seen that any number of client devices 410 may be used. The card reader 413 may be configured to read from and / or communicate with a contactless card 405. The card reader 413 may communicate with the contactless card 405 in conjunction with one or more applications 411.

[0068] Application 411 of client device 410 can communicate with contactless card 405 using short-range wireless communication (e.g., NFC). Application 411 may also be configured to interface with a card reader 413 of client device 410, which is configured to communicate with contactless card 405. Those skilled in the art will understand that a distance of less than 20 centimeters coincides with the range of NFC.

[0069] In some embodiments, application 411 communicates with contactless card 405 via an associated reader (e.g., card reader 413).

[0070] In some embodiments, the contactless card 405 can communicate with the application 411 via NFC through the card reader 413 of the client device 410. The communication (e.g., tapping the contactless card 405 near the card reader 413 of the client device 410) allows the application 411 to read the data associated with the contactless card 405 and perform authentication of the contactless card 405 based on an authentication challenge. In some cases, the tap activates or launches the application 411, initiating one or more actions or communication with one or more servers 420 and / or 425, which may authenticate the contactless card 405 for subsequent use. In some cases, if the application 411 is not installed on the client device 410, tapping the contactless card 405 to the card reader 413 may initiate the download of the application 411 (e.g., navigation to the application download page). After installation, tapping the contactless card 405 activates or launches the application 411, and authentication of the contactless card 405 is initiated based on an authentication challenge (e.g., via application 411 or other backend communication).

[0071] According to some embodiments, the contactless card 405 may include a virtual payment card. In these embodiments, the application 411 can obtain information associated with the contactless card 405 by accessing a digital wallet implemented in the client device 410, the digital wallet including a virtual payment card. In some examples, the virtual payment card data may include one or more statically or dynamically generated virtual card numbers.

[0072] Server 420 may include a web server that communicates with database 435. Server 425 may include an account server. In some examples, server 420 may be configured to validate one or more credentials from contactless card 405 and / or client device 410 against one or more credentials in database 445. Server 425 may be configured to authorize one or more requests from contactless card 405 and / or client device 410, such as payments or transactions.

[0073] Figure 5 shows a key diversification method 500 according to an example of the present disclosure. Method 500 may include a transmitting device and a receiving device similar to the transmitting device 305 (such as a contactless card) and receiving device 310 (such as a client device) shown in Figure 3.

[0074] For example, a sender and a receiver may wish to exchange data (e.g., original sensitive data including an authentication challenge) via a sending device and a receiving device, respectively. As mentioned above, these two parties may be involved, but it is understood that one or more sending devices and one or more receiving devices may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the same master symmetric key may be provisioned for both the sending and receiving devices. Furthermore, it is understood that any party or device holding the same secret symmetric key can perform the functions of the sending device, and similarly, any party holding the same secret symmetric key can perform the functions of the receiving device. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties other than the sending and receiving devices involved in the exchange of secure data. Furthermore, it is understood that both the sending and receiving devices are provided with the same master symmetric key, and that at least a portion of the data exchanged between the sending and receiving devices includes a counter value. The counter value may include a numerical value that changes each time data is exchanged between the sending and receiving devices.

[0075] In block 510, the same master key, such as the same master symmetric key, may be provisioned to the transmitting and receiving devices. The sender may update a counter when the transmitting device is ready to process sensitive data in symmetric encryption. Furthermore, the transmitting device may select a suitable symmetric encryption algorithm, including at least one of the following: symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process the divergence values ​​may include any symmetric encryption algorithm used as needed to generate a divergence symmetric key of the desired length. Non-restrictive examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not produce a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may generate multiple outputs that can be combined as needed to produce a sufficiently long key.

[0076] The sending device retrieves the selected encryption algorithm and processes the counter value using the master symmetric key. For example, the sender can choose a symmetric encryption algorithm and use a counter that is updated for each conversation between the sending and receiving devices.

[0077] In block 520, the transmitting device uses a master symmetric key to encrypt the counter value with a selected symmetric encryption algorithm to create a diversified symmetric key. The diversified symmetric key may be used to process sensitive data before sending the result to the receiving device. For example, the transmitting device may encrypt sensitive data using a symmetric encryption algorithm with the diversified symmetric key, and the output may contain protected encrypted data. The transmitting device can then send the protected encrypted data, along with the counter value, to the receiving device for processing. In some examples, non-encryption processes may be performed, and multiple encryption processes may be performed using the diversified symmetric key before sending the protected data.

[0078] In some examples, the counter value does not need to be encrypted. In these examples, the counter value may be transmitted between the sending and receiving devices without being encrypted in block 520.

[0079] In block 530, sensitive data may be protected using one or more encryption algorithms and diversification keys. A diversified session key, created by key diversification using a counter, may be used with one or more encryption algorithms to protect sensitive data. For example, sensitive data may be processed by MAC using a first diversified session key, and the resulting output may be encrypted using a second diversified session key that produces protected data.

[0080] In block 540, a receiving device can perform the same symmetric encryption using a counter value as input to encryption and a master symmetric key as the encryption key. The output of the encryption may be the same diversified symmetric key value created by the sender. For example, a receiving device can use the counter to independently create its own copies of the first and second diversified session keys. The receiving device then uses the second diversified session key to decrypt the protected data, revealing the output of the MAC created by the sender. The receiving device can then use the first diversified session key to process the resulting data through MAC processing.

[0081] In block 550, the receiving device can validate the protected data using a diversified session key with one or more cryptographic algorithms.

[0082] In block 560, the original data, including the authentication challenge, can be validated. The data is considered valid if the output of the MAC processing (via a receiving device using the first diversified session key) matches the MAC output revealed by decryption.

[0083] Next, when sensitive data needs to be sent from the sending device to the receiving device, a different counter value may be selected, thereby generating a different diversified symmetric key, which in turn generates a different authentication challenge by the receiving device and may be written to the sending device before the sensitive data is sent. By processing the counter value using the master symmetric key and the same symmetric encryption algorithm, both the sending and receiving devices can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the sensitive data.

[0084] As described above, the transmitting and receiving devices each initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is created independently by both the transmitting and receiving devices, it is not transmitted between them. Therefore, an attacker cannot intercept the diversified symmetric key and cannot see the data processed with the master symmetric key. Only a small counter value, not sensitive data, is processed with the master symmetric key. As a result, reduced side-channel data related to the master symmetric key is exposed. Furthermore, the sender and receiver can agree, by prior arrangement or other means, on how often new diversified values, and therefore new diversified symmetric keys, will be created. In one embodiment, a new diversified value, and therefore a new diversified symmetric key, may be created with each exchange between the transmitting and receiving devices.

[0085] In some examples, the key diversification value may include a counter value. Other non-restrictive examples of key diversification values ​​include a random nonce generated whenever a new diversification key is needed and sent from the sending device to the receiving device; the full value of a counter value sent from the sending and receiving devices; a portion of a counter value sent from the sending and receiving devices; a counter held independently by the sending and receiving devices but not sent between the two devices; a one-time passcode exchanged between the sending and receiving devices; and a cryptographic hash of sensitive data. In some examples, one or more portions of the key diversification value may be used by the parties to create multiple diversification keys. For example, a counter may be used as the key diversification value.

[0086] In another example, a portion of the counter may be used as a key diversification value. When multiple master key values ​​are shared between parties, multiple diversification keys can be obtained by the systems and processes described herein. New diversification values, and therefore new diversification symmetric keys, can be created as many times as needed. In the most secure case, a new diversification value may be created each time sensitive data is exchanged between a sending and receiving device. In practice, this can create one-time use keys, such as a single session key.

[0087] In other examples, to limit the number of times a master symmetric key is used, the sender on the sending device and the receiver on the receiving device may agree that a new diversification value, and therefore a new diversified symmetric key, should only occur periodically. In one example, this may occur after a predetermined number of uses, such as every 10 transmissions between the sending and receiving devices. In another example, this may occur after a certain period of time, a certain period after transmission, or periodically (e.g., at a specified time every day; at a specified time on a specified day every week). In yet another example, this may occur each time the receiving device notifies the sending device that it wishes to change the key in the next communication. This may be controlled based on a policy and may change, for example, depending on the current risk level perceived by the receiver on the receiving device.

[0088] Figure 6A shows one or more contactless cards 600, which may include payment cards such as credit cards, debit cards, and gift cards issued by a service provider 605 indicated on the front or back of the card 600. In some examples, the contactless card 600 may include, but is not limited to, an ID card, which is not related to a payment card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 600 may comprise a substrate 610, which may comprise a single layer or one or more layers made of plastic, metal, and other materials. Exemplary substrate materials may include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 600 may have physical properties conforming to the ID-1 format of ISO / IEC 7810, or conforming to ISO / IEC 14443. However, the contactless card 600 described herein may have various characteristics, and it is understood that this disclosure does not require the contactless card to be implemented in the payment card.

[0089] The contactless card 600 may include identification information 615 displayed on the front and / or back of the card, and a contact pad 620. The contact pad 620 may be configured to establish contact with another communication device, such as a user device, smartphone, laptop, desktop, or tablet computer. The contactless card 600 may also include processing circuits, antennas, and other components not shown in Figure 6A. These components may be located behind the contact pad 620 or elsewhere on the substrate 610. The contactless card 600 may also include a magnetic stripe or tape, which may be located on the back of the card (not shown in Figure 6A).

[0090] As shown in Figure 6B, the contact pad 620 in Figure 6A may include a processing circuit 625 for storing and processing information, which may include a microprocessor 630 and memory 635. It is understood that the processing circuit 625 may include additional components, such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware, as necessary to perform the functions described herein.

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

[0092] Memory 635 may be configured to store one or more applets 640, one or more counters 645, and customer identifiers 650. The one or more applets 640 may include one or more software applications configured to run on one or more contactless cards, such as Java Card applets. However, it is understood that applet 640 is not limited to Java Card applets and may be any software application capable of running on contactless cards or other devices with limited memory. The one or more counters 645 may include numeric counters sufficient to store integers. The customer identifiers 650 may include a unique alphanumeric identifier assigned to a user of a contactless card 600, the identifier being able to distinguish a user of a contactless card from a user of another contactless card. In some examples, the customer identifiers 650 may identify both the customer and the account assigned to that customer, and further identify the contactless card associated with the customer's account.

[0093] The processor and memory elements of the exemplary embodiments described above have been described with reference to the contact pads, but the disclosure is not limited thereto. It is understood that these elements may be implemented outside of the pads 620, or completely separate from the pads 620, or as additional elements in addition to the processor 630 and memory 635 elements located within the contact pads 620.

[0094] In some examples, the contactless card 600 may have one or more antennas 655. One or more antennas 655 may be located inside the contactless card 600 and around the processing circuit 625 of the contact pads 620. For example, one or more antennas 655 may be integrated with the processing circuit 625, or one or more antennas 655 may be used with an external booster coil. In another example, one or more antennas 655 may be located outside the contact pads 620 and the processing circuit 625.

[0095] In one embodiment, the coil of the contactless card 600 can function as the secondary side of an air-core transformer. A terminal can communicate with the contactless card 600 by cutting off power or by amplitude modulation. The contactless card 600 can infer data transmitted from the terminal using the gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 600 can reply to the communication by switching the load on the contactless card's coil or by load modulation. Load modulation can be detected by interference in the terminal's coil.

[0096] As described above, the contactless card 600 may be built on a software platform that can run on smart cards or other devices with limited memory, such as JavaCard, and one or more applications or applets may be securely executed on it. Applets can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in a variety of mobile application-based use cases. The applet may be configured to respond to one or more requests, such as a near-field data exchange request from a reader such as a mobile NFC reader, and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag.

[0097] Figure 7 shows an NDEF short record layout (SR=1) 700 according to an exemplary embodiment. One or more applets may be configured to encode OTPs as well-known types of text tags of NDEF type 4. In some examples, an NDEF message may contain one or more records. The applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, English encoding (en); applet ID: D2760000850101; function: read-only access or read-write access; encoding: authentication messages can be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record with a known index for providing actual dynamic authentication data.

[0098] Figure 8 shows a message 810 and message format 820 according to an exemplary embodiment. In one example, when an additional tag is added, the first byte is modified to indicate the start of the message, but not the end, and subsequent records may be added. Since the ID length is zero, the ID length field and ID are omitted from the record. An example message is: UDK AUT key; Derived AUT session key (using 0x00000050); Version 1.0; pATC=0x00000050; RND=4838FB7DC171B89E, MAC=<calculated result 8 bytes>(<eight computed bytes> ) is included.

[0099] In some cases, data can be stored on a contactless card during personalization by implementing STORE DATA (E2) in Secure Channel Protocol 2. One or more values ​​may be read by the personalization bureau from an EMBOSS file (within the section specified by the applet ID), and one or more data storage commands may be sent to the contactless card after authentication and establishment of a secure channel.

[0100] The pUID may contain a 16-digit BCD-encoded number. In some examples, the pUID may consist of 14 digits. [Table 1]

[0101] In some examples, one or more applets may be configured to maintain a personalized state so that personalization is only permitted when unlocked and authenticated. Other states may include the standard state before personalization. When entering the exit state, one or more applets may be configured to delete the personalized data. In the exit state, one or more applets may be configured to stop responding to all Application Protocol Data Unit (APDU) requests.

[0102] One or more applets may be configured to maintain an applet version (2 bytes) used in authentication messages. In some examples, this may be interpreted as the most significant byte being the major version and the least significant byte being the minor version. The rules for each version are configured to interpret the authentication message. For example, this may include, with respect to the major version, that each major version contains a specific authentication message layout and a specific algorithm. With respect to the minor version, this may not include changes to the authentication message or encryption algorithm, but may include changes to static tag content, as well as bug fixes, security enhancements, etc.

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

[0104] In some examples, the contactless card and server may include specific data (e.g., an authentication challenge) to ensure the card is properly identified. The contactless card may include one or more unique identifiers. The counter may be configured to be updated each time a read operation is performed. The authentication challenge may be updated each time a read operation is performed. In some examples, each time the card is read, it is sent to the server for validation, and (as part of validation) it is determined whether the counters are equal. In some examples, each time the card is read, it is sent to the server for validation, and (as part of validation / authentication) it is determined whether the authentication challenge matches.

[0105] One or more counters may be configured to prevent replay attacks. For example, if a ciphertext is intercepted and replayed, the ciphertext will be immediately rejected if a counter is read, used, or otherwise passed. If a counter is not used, it may be replayed, in which case an authentication challenge can be used to prevent a replay attack. In some examples, counters updated on the card are different from counters updated for a transaction. In some examples, a contactless card may include a first applet and a second applet, which may be transaction applets. Each applet may include counters.

[0106] In some cases, counters between a contactless card and one or more servers may become out of sync. For example, a contactless card may be activated, its counters updated, and the contactless card may generate new communication, but this communication does not necessarily have to be sent for processing by one or more servers. This can cause the counters on the contactless card to become out of sync with the counters managed by one or more servers. This can happen unintentionally, for example, when the card is stored adjacent to a device (such as being carried in a pocket with the device), and when the card is read at an angle, including when the card is misaligned or positioned in a way that the contactless card is activated in the NFC field but cannot be read. When a contactless card is placed adjacent to a device, the device's NFC field is turned on, powering up the contactless card and updating the counters on the card, but the application on the device does not receive the communication.

[0107] To maintain counter synchronization, applications such as background applications may run that can detect the activation of a mobile device, synchronize with one or more servers, indicate that a read has been made due to the detection, and advance the counter. Because the counter on the contactless card and the counters on one or more servers may become out of sync, one or more servers may be configured so that the counter on the contactless card can be updated a threshold 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 an event indicating contactless card activation occurs, one or more servers may allow a counter value read from the contactless card, or a counter value within a threshold range (e.g., 1 to 10), to be valid. Furthermore, one or more servers may be configured to request a gesture associated with the contactless card, such as a user tap, if they read a counter value greater than 10 but below another threshold range value (e.g., 1000). If the user taps, authentication is successful if the counter value is within the desired or acceptable range.

[0108] Figure 9 is a flowchart of key processing 900 according to an exemplary embodiment. As shown in Figure 9, block 910 can use two Bank Identification Number (BIN) level master keys in combination with an account identifier and a card sequence number to generate two unique derived keys (UDKs) per card. In some examples, the Bank Identification Number may include a single digit or a combination of one or more digits, such as an account number or an unpredictable digit provided by one or more servers, and may be used to generate and / or diversify session keys. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.

[0109] In block 920, in contrast to master key derivation, where one unique set of keys is generated for each card, the counter can be used as diversification data because it changes with each use and provides a different session key each time. In some examples, it is desirable to use a 4-byte scheme for both operations. Thus, in block 920, two session keys (i.e., one session key from AUTKEY and one session key from ENCKEY) can be generated from the UDK for each transaction. On the card, for the MAC key (i.e., the session key created from AUTKEY), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from ENCKEY), the entire length of the OTP counter can be used as the ENC key.

[0110] In block 930, the MAC key may be used to prepare the MAC ciphertext, and the ENC key may be used to encrypt the ciphertext. For example, the ciphertext can be prepared using the MAC session key and then encrypted with the ENC key before being sent to one or more servers.

[0111] In block 940, the MAC authentication function of the payment HSM directly supports 2-byte diversification, simplifying MAC verification and processing. Decryption of the ciphertext is performed before MAC verification. Session keys are derived individually on one or more servers, generating a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0112] For contactless cards, a different unique identifier is derived, which may be associated with the primary account number (PAN) and PAN sequence number of the application encoded on the card. Key diversification can be configured to receive the identifier as input along with the master key, so that one or more keys can be created for each contactless card. In some examples, these diversified keys may include a first key and a second key. The first key may include an authentication master key (card encryption generation / authentication key - Card-Key-Auth), which can be further diversified to create a MAC session key used when generating and verifying MAC ciphertext. The second key may include an encryption master key (card data encryption key - Card-Key-DEK), which can be further diversified to create an ENC session key used when encrypting and decrypting encrypted data. In some examples, the first and second keys may be created by diversifying the issuer master key in combination with the card's unique ID number (pUID) and the payment applet's PAN sequence number (PSN). The pUID may include a 16-digit number. As mentioned above, the pUID may contain a 16-digit BCD-encoded number. In some examples, the pUID may contain a 14-digit number.

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

[0114] In other examples, such as credit cards, numbers such as account numbers or unpredictable numbers provided by one or more servers may be used to generate or diversify session keys.

[0115] Figure 10 shows a diagram of a system 1000 configured to implement one or more embodiments of the present disclosure. As described below, during the contactless card creation process, two encryption keys may be uniquely assigned to each card. The encryption keys may be symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm can be used with EMV and is implemented by the hardware of the contactless card. By using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information about each entity that requires a key.

[0116] With respect to master key management, two issuer master keys 1005, 1010 may be required for each part of a portfolio in which one or more applets are issued. For example, the first master key 1005 may contain an issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 1010 may contain an issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 1005, 1010 are diversified into card master keys 1025, 1030, which are unique for each card. In some examples, the issuer master keys 1005, 1010 can be identified using the network profile record ID (pNPR) and derived key index (pDKI) 1015 and / or the card's unique identification number (pUID) and PAN sequence number (PSN) 1020 as back-office data. The authentication system may be configured to retrieve the pNPR and pDKI1015 values ​​of the contactless card during authentication.

[0117] In some examples, session keys (such as a unique key per session) may be derived to enhance the security of the solution, but instead of using a master key, unique keys and counters derived from the card may be used as diversified data, as described above. For example, a different key may be used each time the card is used in processing to generate the Message Authentication Code (MAC) and perform encryption. Regarding the generation of session keys, the key used to generate ciphertext and encrypt data in one or more applets may be a session key based on the card's unique key (Card-Key-Auth1025 and Card-Key-Dek1030). The session key (Auth-Session-Key1035 and DEK-Session-Key1040) is generated by one or more applets and derived using the Application Transaction Counter (pATC) 1045 in one or more algorithms. Only the lower two bytes of the 4-byte pATC 1045 are used to fit the data to one or more algorithms. In some examples, a 4-byte session key derivation method may include: F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(4 bytes)F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(4 bytes)SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG may contain a 3DES ECB and MK may contain a card-unique derived master key.

[0118] As described herein, one or more MAC session keys can be derived using the lower two bytes of the pATC1045 counter. Each time the contactless card is tapped, the pATC1045 is configured to be updated, and the card master keys Card-Key-AUTH1025 and Card-Key-DEK1030 are further diversified into session keys Aut-Session-Key1035 and DEK-Session-KEY1040. The pATC1045 can be initialized to zero during personalization or applet initialization. In some examples, the pATC counter 1045 may be initialized during or before personalization and may be configured to increment by 1 with each NDEF read.

[0119] Furthermore, each card update is unique and can be assigned by personalization or by an algorithm using a pUID or other identifying information. For example, odd-numbered cards may be incremented or decremented by 2, and even-numbered cards may be incremented or decremented by 5. In some examples, the updates may be sequential reads or different, with a single card being incremented sequentially in a repeating pattern of 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for a replay attacker to generalize from a small number of card instances.

[0120] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may contain only authentication data and an 8-byte random number followed by the MAC of the authentication data. The authentication data may include the authentication challenge written to the contactless card by the client device. In some examples, the random number precedes ciphertext A and may be the length of one block. In other examples, there may be no limit to the length of the random number. In further examples, the total data (i.e., random number plus ciphertext) may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block generated by the MAC algorithm. In other examples, if the algorithm employed uses a 16-byte block, a multiple of that block size may be used, or the output may be automatically or manually padded to a multiple of that block size.

[0121] The MAC may be executed by a function key (AUT-Session-Key) 1035. The data specified in the ciphertext can be processed with the javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 and associated with the EMV ARQC verification method. The key used for this calculation may include the session key AUT-Session-Key 1035, as described above. As described above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, AUT-Session-Key 1035 may also be used in MAC data 1050, and the resulting data or ciphertext A1055 and random number RND can be encrypted using DEK-Session-Key 1040 to create ciphertext B or output 1060 sent in the message. MAC data 1050 may include an authentication challenge written to the contactless card by the client device. The authentication challenge may be generated by the client device or by the server.

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

[0123] The following format represents an exemplary embodiment of the binary version. Furthermore, in some examples, the first byte may be set to the ASCII character "A". [Table 2]

[0124] Other exemplary formats are shown below. In this example, tags can be encoded in hexadecimal format. [Table 3]

[0125] The UID field (pUID / PSN1020) of the received message can be extracted, and from the master keys Iss-Key-AUTH1005 and Iss-Key-DEK1010, the card master key (Card-Key-Auth1025 and Card-Key-DEK1030) for that particular card can be derived. Using the card master key (Card-Key-Auth1025 and Card-Key-DEK1030), and the counter (pATC) field of the received message, the session key (Aut-Session-Key1035 and DEK-Session-Key1040) for that particular card can be derived. Ciphertext B1060 can be decrypted using the DEK-Session-KEY, which generates ciphertext A1055 and an RND, the RND of which may be discarded. The UID field can be used to retrieve the shared secret of the contactless card, which, along with the message version, UID, authentication challenge, and pATC fields, is processed via an encrypted MAC using a recreated Auto-Session-Key to produce a MAC output such as MAC'. If MAC' is the same as the ciphertext A1055, this indicates that the message decryption and MAC check have all passed. The pATC can then be read to determine if it is valid, and / or the authentication challenge can be read and compared to an authentication challenge stored in the server's memory or retrieved from a database by the server to determine if it is valid.

[0126] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, one or more ciphertexts may be generated as 3DES MACs using ISO9797-1 algorithm 3 and method 2 padding via one or more session keys such as Aut-Session-Key1035. Input data 1050 can take the following format: version(2), pUID(8), pATC(4), shared secret(4), authentication challenge(4). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the shared secret may be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more secure processes. In some examples, the authentication challenge may be included in the shared secret. In some examples, the shared secret may include a random 4-byte binary number known by the authentication service and injected into the card at personalization time. During an authentication session, the shared secret may not be provided to the mobile application from one or more applets. Padding in Method 2 may include adding a required 0x'80' byte to the end of the input data and adding an optional 0x'00' byte to the end of the result data up to an 8-byte boundary. The resulting ciphertext may consist of 8 bytes in length.

[0127] In some examples, one advantage of using MAC ciphertext to encrypt non-shared random numbers as the first block is that it acts as an initialization vector while using the CBC (blockchain) mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without having to establish fixed or dynamic IVs beforehand.

[0128] By including an Application Transaction Counter (pATC) as part of the data contained in the MAC ciphertext, the authentication service may be configured to determine whether the value transmitted in clear data has been tampered with. Furthermore, by including versions in one or more ciphertexts, it becomes difficult for an attacker to deliberately falsify the application version in an attempt to weaken the strength of the encryption solution. In some examples, the pATC may start at zero and be updated by one each time one or more applications generate authentication data. The authentication service may be configured to track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC less than or equal to a previously received value by the authentication service, this may be interpreted as an attempt to replay an old message, and authentication may be rejected. In some examples, if the pATC is greater than a previously received value, this may be evaluated to determine whether it is within an acceptable range or threshold, and if it is above or below the range or threshold, the verification may be considered failed or unreliable. In MAC processing 1036, data 1050 is processed via MAC using the Aut-Session-Key 1035 to generate encrypted MAC output (ciphertext A) 1055.

[0129] To provide additional protection against brute-force attacks that would expose the key on the card, it is desirable that the MAC ciphertext A1055 be encrypted. In some examples, the data or ciphertext A1055 contained in the ciphertext may include random(8), ciphertext(8). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the random numbers may be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include DEK-Session-Key1040. In encryption process 1041, the data or ciphertext A1055 and RND are processed using DEK-Session-Key1040 to generate encrypted data, ciphertext B1060. Data 1055 is encrypted using 3DES in cryptographic blockchain mode to ensure that an attacker would have to perform an attack on all ciphertexts. As a non-restrictive example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' can be used. Successfully decrypted data will appear randomly and will be indistinguishable from incorrectly decrypted data, so an attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used.

[0130] For the authentication service to validate one or more ciphertexts provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile / client device and / or server during the authentication session: the encryption approach to be used and a version number to determine the message format for validating the encryption, so that the approach can be changed in the future; a pUID to look up the crypto asset and derive the card key; and a pATC to derive the session key used for the ciphertext.

[0131] Figure 11 shows a method 1100 for generating ciphertext. For example, in block 1110, the network profile record ID (pNPR) and derived key index (pDKI) can be used to identify the issuer master key to be used in the cryptographic process for authentication. In some examples, this method 1100 may include performing authentication to obtain the pNPR and pDKI values ​​of a contactless card at the time of authentication.

[0132] In block 1120, issuer master keys can be diversified by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of one or more applets, for example, the payment applet.

[0133] In block 1130, Card-Key-Auth and Card-Key-DEK (unique card key) may be created by diversifying the issuer master key to generate a session key that can be used to generate MAC ciphertext.

[0134] In block 1140, the key used to generate the ciphertext and encrypt data within one or more applets may include the session key in block 1130, based on the card-unique key (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and derived using pATC, resulting in the session keys Aut-Session-Key and DEK-Session-Key.

[0135] Figure 12 shows an exemplary process 1200 illustrating key diversification in one example. Initially, two different master keys may be provisioned to the sender (contactless card) and the receiver (client device). For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value that can be updated in block 1210, and other data such as protected data including an authentication challenge that can be securely shared with the receiver.

[0136] In block 1220, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption derivation session key, and the counter value may also be encrypted by the sender using the data integrity master key to generate a data integrity derivation session key. In some examples, the entire counter value or a portion of the counter value may be used during both encryptions.

[0137] In some cases, the counter value may not be encrypted. In these cases, the counter may be sent in plaintext, i.e., without encryption, between the sender and receiver.

[0138] In block 1230, the data to be protected is processed by the sender's encrypted MAC processing using a data integrity session key and an encrypted MAC algorithm. The protected data, including plaintext and shared secrets, can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0139] In block 1240, the data to be protected (the generated MAC) can be encrypted by the sender using a data encryption derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with equal amounts of random data, for example, each 8 bytes long, and encrypted using a second session key (DEK-Session-Key).

[0140] In block 1250, the encrypted MAC is sent from the sender to the receiver along with enough information to identify additional secrets (such as a shared secret containing an authentication challenge, a master key, etc.) for verification of the ciphertext.

[0141] In block 1260, the receiver uses the received counter value to derive two derived session keys individually from the two master keys, as described above.

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

[0143] In block 1280, the data integrity derived session key is used in conjunction with the cryptographic MAC processing to verify that the protected data has not been altered. If the MAC reconstructed from the MAC processing matches the decrypted MAC, the decrypted MAC is verified, and the protected data, including the authentication challenge, is validated. Furthermore, the authentication challenge contained in the MAC sent by the sender can be compared with the authentication challenge stored on the server to determine if they match.

[0144] Some examples of the methods described herein can be favorably verified if authentication is deemed successful when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is valid. The MAC can only be correct if decryption is successful and a valid MAC value is obtained. If decryption is successful, it can indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the sending device) and receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed genuine. 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 process. In addition, the MAC can only be correct and verified if the authentication challenge contained in the MAC matches the authentication challenge used by the authentication service (e.g., a server).

[0145] Subsequently, the two derived session keys may be discarded, and the next iteration of data exchange may update the counter value (returning to block 1210) and create a new set of session keys (block 1220). In some examples, the combined random data may be discarded. Furthermore, a different authentication challenge may be generated by the authentication service (e.g., server or client device) and written to the contactless card by the client device for the next iteration of data exchange.

[0146] Exemplary embodiments of the systems and methods described herein may be configured to provide security factor authentication. Security factor authentication may comprise several processes. As part of security factor authentication, a first process may include logging in and validating a user through one or more applications running on a device. As a second process, the user may perform one or more behaviors associated with one or more contactless cards in response to the successful login and validation of the first process through one or more applications. In practice, security factor authentication may include both securely proving the user's identity and performing one or more types of behaviors associated with a contactless card, including but not limited to one or more tap gestures. In some examples, one or more tap gestures may include the user tapping a contactless card on the device. In some examples, the device may include a mobile device, kiosk, terminal, tablet, or other device configured to process received tap gestures.

[0147] In some examples, a contactless card can be tapped on one or more devices, such as computer kiosks or terminals, to verify identity and receive transaction items corresponding to a purchase, such as coffee. Using contactless cards can establish a secure method of verifying identity in loyalty programs. For example, securely verifying identity to obtain or receive benefits, coupons, offers, etc., is established in a way different from simply scanning a barcode. For example, an encrypted transaction may occur between the contactless card and the device and be configured to handle one or more tap gestures. As described above, one or more applications may be configured to validate the user's identity and then prompt the user to take an action or respond, for example, via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, and healthcare information may be written back to the contactless card.

[0148] In some cases, contactless cards can be tapped on devices such as mobile devices. As mentioned above, the user's identity is verified by one or more applications, and these applications grant the user desired benefits based on the identity verification.

[0149] In some cases, contactless cards can be activated by tapping a device, such as a mobile device. For example, a contactless card can communicate with a device's application via NFC communication through the device's card reader. The communication of tapping the card near the device's card reader allows the device's application to read the data associated with the contactless card and activate the card. In some cases, activation may authorize the card to be used to perform other functions (e.g., purchases, access to accounts or restricted information, or other functions). In some cases, the tap activates or launches the device's application and initiates one or more actions or communications to one or more servers, activating the contactless card. If the application is not installed on the device, tapping the contactless card near the card reader may initiate the download of the application, such as navigating to the application's download page. After installation, tapping the contactless card activates or launches the application and initiates the activation of the contactless card, for example, via the application or other backend communication. After activation, the contactless card can be used for a variety of activities, including but not limited to commercial transactions.

[0150] In some embodiments, the exemplary authentication communication protocol can, with some modifications, mimic an EMV-standard offline dynamic data authentication protocol commonly used between transaction cards and point-of-sale (POS) devices. For example, since the exemplary authentication protocol is not used to complete the payment transaction itself with the card issuer / payment processor, some data values ​​are not required, and authentication can be performed without requiring a real-time online connection to the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system sends a transaction containing transaction values ​​to the card issuer. Whether the issuer approves or rejects the transaction depends on whether the card issuer is aware of the transaction values. On the other hand, in certain embodiments of this disclosure, transactions originating from a mobile device lack transaction values ​​associated with the POS system. Therefore, in some embodiments, a dummy transaction value (i.e., a value that is recognizable to the card issuer and sufficient to trigger activation) may be passed as part of the exemplary authentication communication protocol. In POS-based transactions, transactions can be rejected based on the number of transaction attempts (e.g., transaction counter). An overreaction to the buffer value can lead to a soft rejection, which requires further verification before approving the transaction. In some implementations, the transaction counter buffer value may be modified to avoid rejecting legitimate transactions.

[0151] In some cases, contactless cards can selectively communicate information depending on the receiving device. When tapped, the contactless card recognizes the tapped device and, based on this recognition, can provide the appropriate data to that device. This allows the contactless card to preferably transmit only the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting the transmission of data and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. Information recognition and selective communication can be applied to a variety of scenarios, including card activation, balance transfers, attempts to access accounts, commercial transactions, and reducing step-up fraud.

[0152] When a contactless card is tapped towards a device running Apple's iOS operating system, such as an iPhone, iPod, or iPad, the contactless card can recognize the iOS operating system and transmit appropriate data to communicate with the device. For example, the contactless card can provide encrypted identification information necessary to authenticate the card using an NDEF tag via NFC or similar means. Similarly, when a contactless card is tapped towards a device running the Android operating system, such as an Android smartphone or tablet, the contactless card can recognize the Android operating system and transmit appropriate data (such as encrypted identification information necessary for authentication by the methods described herein) to communicate with the device.

[0153] As another example, a contactless card tap can be directed towards a POS device, including but not limited to kiosks, cash registers, payment stations, and other terminals. When a tap is performed, the contactless card recognizes the POS device and transmits only the information necessary for the action or transaction. For example, upon recognizing a POS device used to complete a commercial transaction, the contactless card can communicate the payment information necessary to complete the transaction in accordance with the EMV standard.

[0154] In some examples, a POS device participating in a transaction may request or specify additional information provided by the contactless card, such as device-specific, location-specific, or transaction-specific information. For example, when a POS device receives data communication from a contactless card, it may recognize the contactless card and request additional information necessary to complete an action or transaction.

[0155] In some cases, a POS device could partner with an authorized retailer or other entity that is familiar with or accustomed to performing specific contactless card transactions. However, it will be clear that such a partnership is not necessary to perform the methods described.

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

[0157] In some examples, one or more applications may be activated by one or more tap gestures on a contactless card to verify the user's identity, and may be configured to determine, for example, that the activation occurred at 3:51 p.m. and the transaction was processed or executed at 3:56 p.m.

[0158] In some examples, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, one or more actions may include collecting rewards, collecting points, deciding on the most important purchase, deciding on the cheapest purchase, and / or reconfiguring into another action in real time.

[0159] In some examples, data related to tapping may be collected as biometric / gesture authentication. For example, a cryptographically secure and intercept-resistant unique identifier may be sent to one or more backend services. The unique identifier may be configured to retrieve secondary information about the individual. The secondary information may include personally identifiable information about the user. In some examples, the secondary information may be stored within a contactless card.

[0160] In some exemplary embodiments, the client / user device (such as a mobile phone) may have full read / write capabilities for the NDEF. This makes the contactless card compatible with client devices that have full read / write capabilities for the NDEF, while simultaneously maintaining backward compatibility with client devices that have read-only access to the NDEF via NFC. The card / banking application can detect whether the client device's operating system and hardware can perform read / write operations on the full NDEF file. If writing is possible, the client device can write an authentication challenge (such as a randomly generated number) to the contactless card. This authentication challenge is used to compute the ciphertext. A timestamp may be added to further enhance encryption. The ciphertext is computed and returned to a server-side validation system that also has a random number and / or a timestamp. The server-side validation system, as a backend, is flexible enough to recognize both read-only card ciphertext and read / write card ciphertext. Both can be validated by the backend. The validation is sent to the client device and authenticated for the specified customer use case.

[0161] By writing an authentication challenge to a contactless card, data transfer can be made even more secure. For example, a random number may be written to the contactless card by a client device as an authentication challenge, a server validation system can retrieve a response digitally signed or mapped with that random number from the contactless card, and the server validation system can verify whether it occurred within that session. In such embodiments, the application sending the response ciphertext message to the server validation system (i.e., the validator) first determines whether the client device can perform an NDEF file write. If this low-level write is possible, an authentication challenge may be sent to the contactless card as an additional process inserted into the normal NDEF read stream. One or more applets may be required on the contactless card to utilize such functionality. The applet can capture the authentication challenge on the contactless card and incorporate it into the MAC ciphertext for the NFC read. If the client device is a non-writable device, the applet can capture zero on the contactless card and incorporate it into the MAC ciphertext for the NFC read, or it can not capture zero on the contactless card and make zero the default. In such a case, zeros are added to the MAC ciphertext message, and the client device and / or server can determine that the authentication challenge cannot be sent from the backend to the contactless card, and the server-side validation system can validate the MAC ciphertext message assuming that zeros are incorporated into the MAC ciphertext.

[0162] Data security can be significantly enhanced by having the client device write an authentication challenge to the contactless card and the contactless card embed it in the MAC ciphertext message. Each time the contactless card is read via NFC, the authentication challenge embedded in the MAC ciphertext message will be different for that read session. For example, if a hacker records a MAC ciphertext message and later replays it, the server-side validation system will expect a MAC ciphertext response with a different authentication challenge than the one replayed by the hacker, and the MAC ciphertext message replayed by the hacker will not be validated by the server-side validation system. In other words, each time the contactless card is read, a new authentication challenge is written to the contactless card and embedded in the MAC ciphertext, overwriting the old authentication challenge. By default, the authentication challenge used by the contactless card is zero. Therefore, if no authentication challenge is sent to the contactless card, the contactless card will always include zero in the MAC ciphertext message. For the contactless card to accept an authentication challenge, an additional interface may be required in the applet or algorithm that can accept this authentication challenge and write it to the NDEF message. The contactless card incorporates this authentication challenge into the MAC ciphertext, encrypts this authentication challenge using an algorithm, and the backend server recognizes this authentication challenge used to validate its MAC ciphertext.

[0163] This method can prevent replay attacks on data. If a contactless card relies on a one-time password, such as a counter, for card authentication, the counter increments with each card read, and the server needs to track whether the last validated counter was used. If that counter is outside a certain window (e.g., a counter smaller than the current counter), the MAC response is rejected by the server. However, the problem is that, for example, if a hacker obtains a card and reads 1000 MAC ciphertexts from it, it is unlikely that the card owner will use the card the next day or within an hour to perform authentication. In that case, the hacker could obtain those MAC ciphertexts and send them from another location, which is sometimes called a replay attack. To prevent such replay attacks, the authentication challenge-response mechanism disclosed above can be used as an additional element of card authentication to improve data security. When the authentication challenge-response mechanism is implemented, the server expects a challenge to be included in the MAC ciphertext for each read session, so MAC ciphertexts replayed by a hacker will not work because they do not have an authentication challenge.

[0164] The authentication challenge can be a random number (i.e., a four-digit number) that can be a binary number or ASCII text. This is a random value that can be embedded in the MAC message. When reading or authenticating a contactless card, the backend server can generate an authentication challenge and send it to the client device performing the read. The client device then sends / writes this challenge to the contactless card and begins reading the card. The card can then execute a selection applet, select a function container, send this challenge, read a data file, and return a MAC ciphertext containing this challenge.

[0165] In some embodiments, a client device can communicate with a server via an API and perform some kind of interaction between the client device and the server. For example, if a contactless card has an older version of an applet that does not support authentication challenges, the client device may return the version number of this older applet to the server, and that version number may be handled differently by the server. At the same time, the client device may also tell the server that the MAC message should be processed in read-only mode because it was unable to perform the authentication challenge.

[0166] The authentication challenge response mechanism disclosed herein allows a card applet to perform not only selection and read operations, but also write operations, writing the authentication challenge to a field in the NDEF tag, which is another APDU. They begin with a class and instruction byte. The instruction byte is simply interpreted by the applet implementing this protocol. In addition, another instruction is added to the APDU, which is interpreted by the applet's process capabilities. Whenever an authentication challenge is requested, the server may be asked to generate a random number and send that random number to the client device, which will perform the card reading and write the random number to the card. Alternatively, the client device may actually generate a random number and send it back to the server to notify the server. In that case, the server records that the random number has not been reused. Therefore, the server needs to ensure that the random number has not been reused recently. For example, the server can store already generated random numbers in a database and compare them to determine whether the random number has been used previously or recently (e.g., within the last 10 times or the last 2 weeks).

[0167] Figure 13 is a flowchart illustrating a secure authentication method 1300 for a contactless card according to an exemplary embodiment. In step 1305, it is determined whether the user / client device can perform the write function to the NDEF tag of the contactless card. This can be determined by a banking application installed on the user device, for example, by checking the user device's OS and hardware via an API. If it is determined that the user device can perform the write function to the NDEF tag of the contactless card (the "YES" branch is selected), in step 1310, an authentication challenge is generated by the server, which receives an authentication challenge generation request from the user device each time the contactless card is read via NFC. The user device may also communicate with the server to inform the server whether it can perform the write to the card based on the determination result in step 1305. In step 1320, the server sends the generated authentication challenge to the user device, for example, via an API or the network. In step 1330, the server receives an encrypted MAC message from the user device. When the card receives an authentication challenge from the user device, it generates an encrypted MAC ciphertext incorporating the authentication challenge as described above, sends the encrypted MAC ciphertext message to the user device, and the user device then sends it to the server. In step 1340, the server decrypts the encrypted MAC message using one of the session keys, for example as described above, and retrieves the MAC ciphertext generated by the card using another session key. In step 1350, the server can reconstruct the MAC ciphertext incorporating the authentication challenge using another session key, as described above. In step 1360, the server can verify the MAC ciphertext received from the card. For example, the server compares the MAC ciphertext reconstructed by the server with the MAC ciphertext generated by and received from the card. If the two MAC ciphertexts match, the MAC ciphertext generated by and received from the card is verified and authenticated. In step 1370, the server can notify the user device of the authentication result.For example, the server can send a notification message to the user's device indicating that the card has been successfully authenticated.

[0168] Furthermore, if it is determined that the user device cannot perform the function of writing to the NDEF tag of the contactless card (the "NO" branch is selected), method 1300 may proceed to step 1350. In this scenario, no authentication challenge is generated by the server or the user device, i.e., no authentication challenge is sent / written to the card. The card generates the MAC ciphertext using the default zero. The server also reconstructs the MAC ciphertext incorporating zero as the default value.

[0169] Figure 14 is a flowchart illustrating a secure authentication method 1400 for a contactless card according to an exemplary embodiment. In step 1405, it is determined whether the user / client device can perform the write function to the NDEF tag of the contactless card. This can be determined by a banking application installed on the user device, for example, by checking the user device's OS and hardware via an API. If it is determined that the user device can perform the write function to the NDEF tag of the contactless card (the "YES" branch is selected), in step 1410, the user device generates an authentication challenge each time the contactless card is read via NFC. The user device may also communicate with the server to inform the server whether it can perform the write to the card based on the determination result in step 1305. In step 1420, the user device sends the generated authentication challenge to the card and the server, for example, via an API or the network. In step 1430, the user device receives an encrypted MAC message from the card. When the card receives the authentication challenge from the user device, it generates an encrypted MAC ciphertext incorporating the authentication challenge as described above and sends the encrypted MAC ciphertext message to the user device. In step 1440, the user device then sends the encrypted MAC ciphertext message to the server. The server uses one of the session keys, for example as described above, to decrypt the encrypted MAC message and uses another session key to retrieve the MAC ciphertext generated by the card. As described above, the server can use another session key to reconstruct the MAC ciphertext incorporating the authentication challenge. The server can verify the MAC cipher received from the card. For example, the server compares the MAC ciphertext reconstructed by the server with the MAC ciphertext generated by and received from the card. If the two MAC ciphertexts match, the MAC ciphertext generated by and received from the card is verified and authenticated. The server can notify the user device of the authentication result. For example, the server can send a notification message to the user device indicating that the card has been successfully authenticated.In step 1450, the user device can receive the authentication result from the server.

[0170] Furthermore, if it is determined that the user device cannot perform the function of writing to the NDEF tag of the contactless card (the "NO" branch is selected), method 1400 may proceed to step 1430. In this scenario, the user device does not generate an authentication challenge, i.e., no authentication challenge is sent / written to the card. The card generates a MAC ciphertext using the default zero. The server also reconstructs the MAC cipher incorporating zero as the default value. In step 1430, the user device receives the MAC cipher generated by the card using the default zero and sends it to the server.

[0171] In some embodiments, a timestamp may be generated and associated with the authentication challenge. The timestamp indicates the time the authentication challenge was generated. The timestamp may be sent and written to the card along with the associated authentication challenge. If the timestamp and its associated authentication challenge are generated by a client device, the client device can send the timestamp and its associated authentication challenge to the server. The server can validate the card based on both the authentication challenge and the timestamp.

[0172] A secure authentication system is provided as disclosed herein. The secure authentication system comprises a first device (e.g., a contactless card) having a processor and memory; a second device (e.g., a user / client device) having a processor and memory and communicating data with the first device via a first network; and a server having a processor and memory and communicating data with the second device via a second network, wherein the memory of the first device contains a master key and a counter value, and the server is configured to generate an authentication challenge and send the authentication challenge to the second device via the second network, wherein the memory of the server contains the master key and the authentication challenge. The first device is configured to receive the authentication challenge from the second device via the first network; generate a session key using the master key and one or more encryption algorithms and store the session key in the memory of the first device; generate a message authentication code (MAC) from the counter value and the authentication challenge using one or more encryption algorithms and the session key; encrypt the MAC using one or more encryption algorithms to generate an encrypted MAC ciphertext; and send the encrypted MAC ciphertext to the second device via the first network. The second device is configured to receive an authentication challenge from the server via the second network; send an authentication challenge to the first device via the first network; receive an encrypted MAC ciphertext from the first device via the first network; and send an encrypted MAC ciphertext to the server via the second network. The server is configured to generate a session key based on the master key and store the session key in the server's memory; receive an encrypted MAC ciphertext from the second device via the second network; decrypt the encrypted MAC ciphertext using one or more encryption algorithms and the session key; and validate the authentication challenge.

[0173] In a secure authentication system, the first network is a Near Field Communication (NFC) network. The authentication challenge includes a random number, a binary number, or ASCII text. The second device is configured to send the authentication challenge to the first device via the first network and write the authentication challenge in APDU format to an NDEF file stored in the first device's memory. The second device is further configured to generate the authentication challenge and send it to the server via the second network. The second device is further configured to determine whether it can send the authentication challenge to the first device in APDU format. If it determines that the second device cannot send the authentication challenge to the first device in APDU format, the authentication challenge is set to its default value of 0. The server is further configured to generate a timestamp associated with the authentication challenge and validate the authentication challenge based on the timestamp. One or more encryption algorithms include at least one of the symmetric encryption algorithm, HMAC algorithm, and CMAC algorithm. The counter value includes a one-time passcode. The master key is limited to a predetermined number of uses. The use of the master key is limited to a predetermined period.

[0174] A secure authentication method is also provided as disclosed herein. This method may include: generating an authentication challenge by a server configured to have memory containing a master key and an authentication challenge; sending the authentication challenge to a client device by the server; generating a session key based on the master key by the server and storing the session key in the server's memory; receiving an encrypted message authentication code (MAC) ciphertext from the client device by the server; decrypting the encrypted MAC ciphertext using one or more encryption algorithms and the session key by the server; and validating a card and / or an authentication challenge by the server.

[0175] In this method, an encrypted MAC ciphertext is generated by a contactless card. The contactless card is configured to have memory containing a master key and a counter value, and a processor, and to receive an authentication challenge from a client device via an NFC network; generate a session key using the master key and one or more encryption algorithms and store the session key in the contactless card's memory; generate a MAC from the counter value and the authentication challenge using one or more encryption algorithms and the session key; encrypt the MAC using one or more encryption algorithms to generate an encrypted MAC ciphertext; and transmit the encrypted MAC ciphertext to the client device via an NFC network. The contactless card's memory further contains a unique identification number, a shared secret, and an applet associated with the contactless card, and the encrypted MAC ciphertext contains one or more of the unique identification number, counter value, applet version number, authentication challenge, and shared secret. The authentication challenge is updated each time a session key is generated. The contactless card has a radio frequency identification chip and is configured to transmit at least one of a unique identification number, a counter value, and an applet version number to a client device via near-field communication. The master key is generated using the network profile record identifier and the derived key index.

[0176] A contactless card may be provided as disclosed herein. The contactless card may comprise: a memory containing one or more applets, counter values, and multiple keys; a communication interface; and one or more processors communicating with the memory and the communication interface. The one or more processors are configured to receive an authentication challenge and update the counter value when the communication interface is within range of the communication field of a client device. The one or more processors are configured to use the multiple keys, authentication challenge, and counter value to create an encrypted MAC ciphertext. The encrypted MAC ciphertext is transmitted to the client device via the communication interface.

[0177] Figure 15 is a flowchart of a secure authentication method 1500 for contactless cards, executable by a server, according to an exemplary embodiment. The server may include a processor and memory. By executing method 1500, the server may be configured to: generate an authentication challenge (step 1505); store the authentication challenge in memory (step 1510); send the authentication challenge to a user device (step 1520); generate a session key based on a master key (step 1530); store the session key in memory (step 1540); receive an encrypted Message Authentication Code (MAC) ciphertext incorporating the authentication challenge from the user device (step 1550); decrypt the encrypted MAC ciphertext using one or more encryption algorithms and the session key (step 1560); and validate the authentication challenge received from the user device (step 1570). The authentication challenge may include a random number, a binary number, or ASCII text. If the user device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of 0. The server is further configured to generate a timestamp associated with the authentication challenge and to validate the authentication challenge based on the timestamp. One or more encryption algorithms include at least one of the following: symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. The encrypted MAC cipher contains the authentication challenge. The server is further configured to reconstruct the MAC ciphertext containing the authentication challenge; compare the reconstructed MAC ciphertext with the decrypted MAC ciphertext; and if the reconstructed MAC ciphertext matches the decrypted MAC ciphertext, the authentication challenge is validated.

[0178] Figure 16 is a flowchart illustrating a method 1600 for secure authentication of a contactless card, executable by a user device, according to an exemplary embodiment. The user device may include a processor and memory. When executing method 1600, the user device is configured to receive an authentication challenge from a server (step 1610); send the authentication challenge to a contactless card (step 1620); receive an encrypted MAC ciphertext from the contactless card (step 1630); and send the encrypted MAC ciphertext to a server (step 1640). The encrypted MAC ciphertext is generated by the contactless card based on the authentication challenge. The user device is further configured to write the authentication challenge in APDU format to an NDEF file stored on the contactless card. The user device is further configured to generate an authentication challenge. The user device is further configured to determine whether the user device can write the authentication challenge to the contactless card in APDU format. If the second device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of 0. The user device is further configured to receive a notification from the server indicating that the authentication challenge has been validated. The encrypted MAC message is received from the contactless card via Near Field Communication (NFC).

[0179] Figure 17 is a flowchart illustrating a contactless card secure authentication method 1700, which can be performed by a contactless card, according to an exemplary embodiment. The contactless card may include: a memory containing a counter value and a card key; a communication interface; and a processor that communicates with the memory and the communication interface. By performing method 1700, the processor is configured to receive an authentication challenge from a user device when the communication interface is within range of the user device's communication field (step 1710), to use the card key, the authentication challenge, and the counter value to create an encrypted MAC ciphertext (step 1720), and to send the encrypted MAC ciphertext to the user device via the communication interface (step 1730). If the user device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of 0. The encrypted MAC ciphertext is encrypted using one or more encryption algorithms, including at least one of the symmetric encryption algorithm, the HMAC algorithm, and the CMAC algorithm. The processor is configured to update the counter value when the communication interface is within range of the user device's communication field, the counter value containing a one-time passcode. The card key is limited to a predetermined number of uses.

[0180] In some embodiments, the technology described herein relates to a secure authentication system including a server including a processor and memory, wherein the server is configured to generate an authentication challenge; store the authentication challenge in memory; send the authentication challenge to a user device; generate a session key based on a master key; store the session key in memory; receive an encrypted message authentication code (MAC) ciphertext incorporating the authentication challenge from the user device; decrypt the encrypted MAC ciphertext using one or more encryption algorithms and session keys; and validate the authentication challenge received from the user device.

[0181] In some embodiments, the technologies described herein relate to a secure authentication system, where the authentication challenge includes a random number, a binary number, or ASCII text.

[0182] In some embodiments, the technology described herein relates to a secure authentication system in which the authentication challenge is set to a default value of zero if it is determined that the user device is unable to write the authentication challenge to the contactless card in APDU format.

[0183] In some embodiments, the technology described herein relates to a secure authentication system, wherein the server is further configured to generate a timestamp associated with an authentication challenge and to validate the authentication challenge based on the timestamp.

[0184] In some embodiments, the technologies described herein relate to a secure authentication system, wherein one or more encryption algorithms include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms.

[0185] In some embodiments, the technologies described herein relate to a secure authentication system in which an authentication challenge is incorporated into an encrypted MAC ciphertext.

[0186] In some embodiments, the technology described herein relates to a secure authentication system, wherein the server is further configured to reconstruct a MAC ciphertext incorporating an authentication challenge; compare the reconstructed MAC ciphertext with a decrypted MAC ciphertext; and if the reconstructed MAC ciphertext matches the decrypted MAC ciphertext, the authentication challenge is validated.

[0187] In some embodiments, the technology described herein relates to a secure authentication system including a user device including a processor and memory, wherein the user device is configured to receive an authentication challenge from a server; send an authentication challenge to a contactless card; receive an encrypted MAC ciphertext from the contactless card; and send the encrypted MAC ciphertext to the server.

[0188] In some embodiments, the technology described herein relates to a secure authentication system in which an encrypted MAC ciphertext is generated by a contactless card based on an authentication challenge.

[0189] In some embodiments, the technology described herein relates to a secure authentication system, wherein the user device is further configured to write an authentication challenge in APDU format to an NDEF file stored on a contactless card.

[0190] In some embodiments, the technology described herein relates to a secure authentication system, wherein the user device is further configured to generate an authentication challenge.

[0191] In some embodiments, the technology described herein relates to a secure authentication system, wherein the user device is further configured to determine whether the user device can write an authentication challenge to a contactless card in APDU format.

[0192] In some embodiments, the technology described herein relates to a secure authentication system in which, if it is determined that the user device cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of zero.

[0193] In some embodiments, the technologies described herein relate to a secure authentication system, wherein the user device is further configured to receive a notification from the server indicating that the authentication challenge has been validated.

[0194] In some embodiments, the technology described herein relates to a secure authentication system in which an encrypted MAC ciphertext is received from a contactless card via near-field communication (NFC).

[0195] In some embodiments, the technology described herein relates to a contactless card comprising: a memory containing a counter value and a card key; a communication interface; and a processor communicating with the memory and the communication interface, wherein the processor is configured to receive an authentication challenge from a user device when the communication interface is within the communication field of the user device, to use the card key, the authentication challenge, and the counter value to create an encrypted MAC ciphertext, and to transmit the encrypted MAC ciphertext to the user device via the communication interface.

[0196] In some embodiments, the technology described herein relates to a contactless card, and if the user device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of zero.

[0197] In some embodiments, the technology described herein relates to a contactless card, wherein the encrypted MAC ciphertext is encrypted using one or more encryption algorithms, including at least one of the symmetric encryption algorithm, the HMAC algorithm, and the CMAC algorithm.

[0198] In some embodiments, the technology described herein relates to a contactless card, wherein the processor is configured to update a counter value when the communication interface is within range of the communication field of the user device, and the counter value includes a one-time passcode.

[0199] In some embodiments, the technologies described herein relate to contactless cards, where the card key is limited to a predetermined number of uses.

[0200] Furthermore, it should be noted that the systems and methods described herein can be specifically implemented on one or more physical media, including but not limited to compact discs (CDs), digital versatile discs (DVDs), floppy disks, hard drives, read-only memory (ROM), random access memory (RAM), and other physical media capable of storing data. For example, data storage may include random access memory (RAM) and read-only memory (ROM), which may be configured to access and store data and information, and computer program instructions. Data storage may also include storage media or other suitable types of memory (e.g., RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, flash drives, and any type of tangible and non-temporary storage medium), which may store operating systems, application programs including web browser applications, email applications, and / or other applications, and files including data files. Data storage in network-enabled computer systems may include electronic information, files, and documents stored in a variety of ways, such as flat files, index files, hierarchical databases, relational databases (including databases created and maintained using software such as Oracle Corporation), Microsoft Excel files, Microsoft Access files, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online storage or cloud storage), or other storage mechanisms. Furthermore, the diagram shows various components (servers, computers, processors, etc.) individually.Features described as being performed by various components may also be performed by other components, and these various components may be combined or separated. Other changes may also be made.

[0201] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing and / or processing unit, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing and / or processing unit receives computer-readable program instructions from the network and transfers such computer-readable program instructions for storage in a computer-readable storage medium within each computing and / or processing unit.

[0202] The computer-readable program instructions for performing the processing of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, such as object-oriented programming languages ​​like Java, Smalltalk, and C++, and conventional procedural programming languages ​​like the C programming language or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including local area networks (LANs) and wide area networks (WANs), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions and perform aspects of the present invention by personalizing the electronic circuit using state information of computer-readable program instructions.

[0203] These computer-readable program instructions are provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device, and can generate a machine such that instructions executed via the processor of a computer or other programmable data processing device create means for implementing the functions specified herein. These computer-readable program instructions may be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function, and as a result, the computer-readable storage medium storing the instructions includes a product containing instructions that implement embodiments of the functions specified herein.

[0204] Computer-readable program instructions are loaded into a computer, other programmable data processing device, or other device, and a series of processing steps are executed on the computer, other programmable device, or other device to generate a computer implementation process, which results in the instructions executed on the computer, other programmable device, or other device implementing the functions specified herein.

[0205] Implementations of the various technologies described herein can be implemented in digital electronic circuits, or in computer hardware, firmware, software, or combinations thereof. Implementations can be implemented as computer program products, i.e., as computer programs tangibly embodied in information carriers, such as machine-readable memory devices or propagating signals, to be executed by or control data processing devices, such as programmable processors, computers, or multiple computers. Computer programs, such as those described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to run on a single computer, on multiple computers at a single site, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0206] The method step can be performed by one or more programmable processors that execute a computer program that performs the function of processing input data and generating an output. The method step can also be performed by a dedicated logic circuit such as an FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit), and the device can also be implemented as a dedicated logic circuit.

[0207] Throughout this specification and the claims, unless the context clearly indicates otherwise, the following terms have at least the meanings expressly associated herein: The term “or” means comprehensive “or”; furthermore, the terms “a,” “an,” and “the” mean one or more unless otherwise specified or unless the context clearly indicates a singular form.

[0208] This specification provides numerous specific details. However, it should be understood that implementations of the disclosed technology can be carried out without these specific details. In other cases, well-known methods, structures, and techniques are not described in detail so as not to obscure the understanding of this description. References such as “several examples,” “other examples,” “one example,” “one example,” “various examples,” “one embodiment,” “one embodiment,” “several embodiments,” “exemplary embodiments,” “various embodiments,” “one implementation,” “one implementation,” “exemplary implementation,” “various implementations,” and “several implementations” indicate that implementations of the disclosed technology described may include certain features, structures, or characteristics, but not all implementations necessarily include certain features, structures, or characteristics. Furthermore, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” does not necessarily refer to the same example, embodiment, or implementation.

[0209] In this specification, unless otherwise specified, when ordinal adjectives such as “first,” “second,” and “third” are used to describe a common object, they simply indicate that different instances of a similar object are being referred to, and do not imply that the objects being described must be in a particular order in time, space, order, or otherwise.

[0210] While specific embodiments of the disclosed technology are described in relation to embodiments considered to be the most practical and diverse embodiments currently available, it should be understood that the disclosed technology is not limited to the disclosed embodiments, but rather is intended to cover a variety of modifications and equivalent arrangements included in the appended claims. Certain terms are used herein, but they are used only in a general descriptive sense and are not intended to be limiting.

[0211] This specification uses examples to disclose specific implementations of the disclosed technology, including the best mode, and to enable a person skilled in the art to practice specific implementations of the disclosed technology, including the creation and use of devices and systems, and the execution of incorporated methods. The patentable scope of specific embodiments of the disclosed technology is defined in the claims and may include other examples conceivable by a person skilled in the art. Such other examples are considered to be within the claims if they have structural elements that are not different from the language of the claims, or if they include equivalent structural elements that are not substantially different from the language of the claims.

Claims

1. A secure authentication system comprising a server including a processor and memory, wherein the server is Generate an authentication challenge, The authentication challenge is stored in the aforementioned memory, The authentication challenge is sent to the user device. Generate a session key based on the master key, The session key is stored in the memory, The user device receives an encrypted message authentication code (MAC) ciphertext incorporating the authentication challenge, Using one or more encryption algorithms and the session key, the encrypted MAC ciphertext is decrypted. The authentication challenge received from the user device is validated. A secure authentication system configured in such a way.

2. The secure authentication system according to claim 1, wherein the authentication challenge includes a random number, a binary number, or ASCII text.

3. The secure authentication system according to claim 1, wherein when the user device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of zero.

4. The secure authentication system according to claim 1, wherein the server is further configured to generate a timestamp associated with the authentication challenge and to validate the authentication challenge based on the timestamp.

5. The secure authentication system according to claim 1, wherein the one or more encryption algorithms include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm.

6. The secure authentication system according to claim 1, wherein the encrypted MAC ciphertext incorporates the authentication challenge.

7. The aforementioned server, Reconstruct the MAC ciphertext incorporating the aforementioned authentication challenge, Compare the reconstructed MAC ciphertext with the decrypted MAC ciphertext. The authentication challenge is validated when the reconstructed MAC ciphertext matches the decrypted MAC ciphertext. The secure authentication system according to claim 1.

8. A secure authentication system comprising a user device having a processor and memory, The user device is Receive an authentication challenge from the server, The authentication challenge is sent to the contactless card. The encrypted MAC message is received from the aforementioned contactless card. The encrypted MAC message is sent to the server. A secure authentication system configured in such a way.

9. The secure authentication system according to claim 8, wherein the encrypted MAC ciphertext is generated by the contactless card based on the authentication challenge.

10. The secure authentication system according to claim 8, further configured to write the authentication challenge in APDU format to an NDEF file stored on the contactless card.

11. The secure authentication system according to claim 8, wherein the user device is further configured to generate the authentication challenge.

12. The secure authentication system according to claim 8, wherein the user device is further configured to determine whether the user device can write the authentication challenge to the contactless card in APDU format.

13. The secure authentication system according to claim 12, wherein when the user device determines that it cannot write the authentication challenge to the contactless card in the APDU format, the authentication challenge is set to a default value of zero.

14. The secure authentication system according to claim 8, wherein the user device is further configured to receive a notification from the server indicating that the authentication challenge has been validated.

15. The secure authentication system according to claim 8, wherein the encrypted MAC ciphertext is received from the contactless card via near-field communication (NFC).

16. Memory containing counter values ​​and card keys, Communication interface, A processor that communicates with the memory and the communication interface, A contactless card equipped with, The aforementioned processor, When the communication interface is within the range of the user device's communication field, the user device receives an authentication challenge. Using the card key, the authentication challenge, and the counter value, an encrypted MAC ciphertext is created. The encrypted MAC ciphertext is transmitted to the user device via the communication interface. A contactless card configured in such a way.

17. The contactless card according to claim 16, wherein when the user device determines that it cannot write the authentication challenge to the contactless card in APDU format, the authentication challenge is set to a default value of zero.

18. The contactless card according to claim 16, wherein the encrypted MAC ciphertext is encrypted using one or more encryption algorithms, including at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm.

19. The contactless card according to claim 16, wherein the processor is configured to update the counter value when the communication interface is within the range of the communication field of the user device, and the counter value includes a one-time passcode.

20. The contactless card according to claim 16, wherein the card key is limited to a predetermined number of uses.

Images