System and method for generating a shared key for a transaction card

Abstract

Systems and methods for generating a shared key for a transaction card are provided. An example system can include a transaction card including a card private key and a card public key derived from the card private key, a server including a server private key and a server public key derived from the server private key, and a user device. The user device can be configured to initiate a communication session, read the card public key, and transmit the card public key to the server. The server can generate a shared key from the card public key and the server private key, receive the server public key from the server, and transmit the server public key to the transaction card. The transaction card can generate the same shared key from the server public key and the card private key.

Description

Cross-references to related applications

[0001] This application claims priority to U.S. Patent Application No. 18 / 403,001, filed January 3, 2024. The entire contents of the aforementioned patent application are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to data security, and more particularly to systems and methods for generating shared keys for transaction cards. Background Technology

[0003] Transaction cards can be authenticated using a symmetric key exchanged between the card itself and the backend server. In a typical system, when a card is issued, it is pre-configured with a shared key, and the server also has a shared key. They each use their shared key to create a symmetric key. Typically, these shared keys are generated and stored on the card itself before it is issued to the user.

[0004] However, these conventional methods are inconvenient in some situations. For example, when a transaction card is reissued or a new transaction card is issued on a vending machine, a new shared key is usually required for the reissued or new card. This necessitates transmitting the new shared key between the reissued or new card and the backend server, which can introduce security risks.

[0005] These and other shortcomings exist. Therefore, there is a need for systems and methods to overcome these shortcomings in order to dynamically generate shared keys between the transaction card and the backend server. Summary of the Invention

[0006] In some aspects, the technology described herein relates to a system for generating a shared key for a transaction card, the system comprising: a transaction card including a card private key and a card public key derived from the card private key; a server including a server private key and a server public key derived from the server private key; and a user equipment configured to: activate a communication field, read the card public key, transmit the card public key to the server, wherein the server generates a shared key based on the card public key and the server private key, receive the server public key from the server, and transmit the server public key to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0007] In some aspects, the technology described herein relates to a method for generating a shared key for a transaction card, the system comprising: a transaction card providing a card private key and a card public key derived from the card private key; a server providing a server private key and a server public key derived from the server private key; and a communication field initiated by a user equipment, wherein the user equipment reads the card public key, transmits the card public key to the server, wherein the server generates a shared key based on the card public key and the server private key, the user equipment receives the server public key from the server, and transmits the server public key to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0008] In some aspects, the technology described herein relates to a non-transitory computer-readable medium containing computer-executable instructions that, when executed by a computer hardware device, enable the computer hardware device to perform a program comprising: opening a communication field; reading a card public key from a card upon entering the communication field; transmitting the card public key to a server, wherein the server generates a shared key based on the card public key and a server private key; receiving a server public key from a server; and transmitting the server public key to a transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0009] The following will explain in more detail the further features of the disclosed system and method, and the advantages therefrom, with reference to specific example embodiments shown in the accompanying drawings. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of a system for dynamically generating a shared key between a transaction card and a backend server, according to an example embodiment.

[0011] Figure 2 According to the example embodiment Figure 1 A schematic diagram illustrating a series of interactions between the various components of the system.

[0012] Figure 3 It is a contactless card, according to an example embodiment, that can be used to enhance transaction messages to prevent fraud.

[0013] Figure 4 According to the example embodiment Figure 3 A schematic diagram of the processor for the contactless card in A.

[0014] Figure 5 This is a flowchart of a method for dynamically generating a shared key for a transaction card on the backend server side, according to an example embodiment.

[0015] Figure 6 This is a flowchart of a method for dynamically generating a shared key for a transaction card on the transaction card side, according to an example embodiment.

[0016] Figure 7 This is a schematic diagram illustrating the tapping of a transaction card onto a mobile device according to an example embodiment.

[0017] Figure 8 This is a flowchart of a method for generating ciphertext using a shared key on the transaction card side, according to an example embodiment.

[0018] Figure 9 This is a flowchart of a method for verifying ciphertext using a shared key on the backend server side, according to an example embodiment.

[0019] Figure 10 This is a flowchart of a method for dynamically generating a shared key between a transaction card and a backend server, according to an example embodiment. Detailed Implementation

[0020] The following description of the embodiments provides non-limiting representative examples of reference numbers to specifically describe the features and teachings of different aspects of the invention. The described embodiments should be considered as being practiced alone or in combination with other embodiments described herein. A review of the description of the embodiments should enable those skilled in the art to learn and understand the different descriptive aspects of the invention. The description of the embodiments is intended to facilitate an understanding of the invention such that other embodiments not specifically covered but within the knowledge of those skilled in the art upon reading the description of the embodiments will be understood to be consistent with the application of the invention.

[0021] The features and teachings of the embodiments described can be combined in any suitable manner. Those skilled in the art will recognize that this embodiment can be practiced without one or more specific features and teachings of a particular embodiment. In other instances, additional features and teachings that may not be present in all embodiments may be identified in some embodiments. Those skilled in the art will understand that the features and teachings of any embodiment can be combined interchangeably with the features and teachings of any other embodiment.

[0022] The key can be distributed during card manufacturing to create a symmetric key associated with both the transaction card and the user's identity. This key can then be used for identity assertion and card authentication to work with applications that act as card authenticators. Mobile devices have secure elements capable of storing and processing the keys used for Message Authentication Code (MAC) construction and encryption; however, providing these keys securely to both the mobile device and the backend authentication system simultaneously is challenging.

[0023] This disclosure provides a shared key negotiation protocol and subsequent key processing method. In this disclosure, any number of key negotiation protocols (such as Diffie-Hellman or Elliptic Curve Diffie-Hell (ECDH)) can be used to create keys in parallel on both the mobile device side and the backend verification server side. These key negotiation protocols can use split components, one of which is shared with the other party, while the other remains secret. Both parties ultimately compute the same shared key to create the shared key. The shared key can then be pre-installed in the mobile device's secure element / keychain and / or transaction card.

[0024] On the backend server verification side, the generated shared key is encrypted using a key encryption key and stored in a database associated with the user's identity linked to the mobile device. Before this association is accepted, the user's identity can be established through multi-factor authentication or endorsement by an authoritative body.

[0025] For backend server verification, the transaction card message can be parsed to find the unique identifier (UID) of the transaction card. The encryption key contained in the transaction card message is provided to the hardware security module (HSM) of the backend server, and appropriate decryption and MAC verification can be performed in the HSM based on a shared key that is already stored in the HSM or dynamically generated at the time.

[0026] In addition to ECDH, the exemplary embodiments of this disclosure can also be implemented with any other number of key algorithms, such as Triple Data Encryption Algorithm (3DES) and Advanced Encryption Standard (AES).

[0027] Figure 1 A system 100 for dynamically generating a shared key between a transaction card and a backend server, according to an example embodiment, is shown. As discussed further below, system 100 may include user equipment 110, card 120, server 130, database 140, and network 150. Although Figure 1 A single instance of a component is shown, but system 100 may include any number of components.

[0028] User equipment 110 may be associated with a user of the issued card 120. User equipment 110 may be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, servers, network devices, personal computers, workstations, telephones, handheld personal computers, personal digital assistants, thin clients, fat clients, internet browsers, mobile devices, kiosks, or other computer or communication devices. For example, network-enabled computer devices may include iPhones, iPods, iPads, or any other mobile devices running Apple's iOS® operating system from Apple®, any devices running Microsoft's Windows® Mobile operating system, any devices running Google's Android® operating system, and / or any other smartphones, tablets, or similar wearable mobile devices.

[0029] User equipment 110 may include a processor 111, memory 112, and applications 113. Processor 111 may be a processor, microprocessor, or other processor, and user equipment 110 may include one or more of these processors. Processor 111 may include processing circuitry that may include additional components, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, which perform the functions described herein as needed.

[0030] Processor 111 may be coupled to memory 112. Memory 112 may be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, and user equipment 110 may include one or more of these memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times. Memory 112 may be configured to store one or more software applications, such as application 113, as well as other data, such as a user's shopping and financial account information.

[0031] Application 113 may include one or more software applications that include instructions for execution on user equipment 110. In some examples, user equipment 110 may execute one or more applications, such as software applications, that are capable of, for example, networking with one or more components of system 100, transmitting and / or receiving data, and performing the functions described herein. After execution by processor 111, application 113 may provide the functions described herein, specifically, running and performing the steps and functions in the processing flow described below. For example, application 113 may be executed to authenticate a user. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. Application 113 may provide a GUI through which a user can view and interact with other components and devices within system 100. The GUI may be formatted as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), or, depending on the application used by the user to interact with system 100, in any other suitable form for presentation on a display device.

[0032] User equipment 110 may also include a display 114 and an input device 115. The display 114 may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input device 115 may include any device available to and supported by user equipment 110 for inputting information into user equipment 110, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices can be used to input information and interact with the software and other devices described herein.

[0033] System 100 may include card 120, which will be referred to below. Figure 3 and Figure 4 To elaborate further: Card 120 can be any type of card, such as a contactless card, security card, payment card, ID card, and similar cards. Card 120 can be issued to users by financial institutions.

[0034] Card 120 can be configured to transmit a unique card identifier and a ciphertext-containing cryptographic payload to User Equipment 110 upon being tapped. User Equipment 110 can be configured to read the unique card identifier and the ciphertext-containing cryptographic payload from Card 120 after Card 120 enters its communication field. User Equipment 110 can then transmit the unique card identifier and the ciphertext-containing cryptographic payload to Server 130.

[0035] Card 120 can perform authentication and numerous other functions that may require the user to carry a separate physical token in addition to card 120. By employing a contactless interface, card 120 can provide a method for interaction and communication between the user's device (such as a mobile phone or user device 110) and the card itself. For example, the Europay, Mastercard, and Visa (EMV) protocols, which underpin many credit card transactions, include an authentication process sufficient for the Android® operating system but challenging iOS® due to its more restrictive use of Near Field Communication (NFC), which is limited to read-only mode. The exemplary embodiment of card 120 described herein is capable of utilizing NFC technology. Card 120 may include a substrate 121 and a contact pad 122. Detailed information on example contactless cards 120 will be provided later. Figure 3 and Figure 4 The description is in the middle.

[0036] Server 130 may be a backend server associated with an institution (such as a financial institution that issues card 120) and may be configured to communicate with user equipment 110. The institution associated with server 130 may issue card 120 to users and thus may authenticate users based on card 120.

[0037] Server 130 may be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, servers, network devices, personal computers, workstations, telephones, handheld personal computers, personal digital assistants, thin clients, fat clients, internet browsers, mobile devices, kiosks, or other computer or communication devices. For example, a network-enabled computer device may include an iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system from Apple®, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0038] Server 130 may include processor 131, memory 132, and application 133. Processor 131 may be a processor, microprocessor, or other processor, and server 130 may include one or more such processors. Processor 131 may include processing circuitry that may include additional components, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, which perform the functions described herein as needed.

[0039] Processor 131 may be coupled to memory 132. Memory 132 may be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, and server 130 may include one or more such memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times. Memory 132 may be configured to store one or more software applications, such as application 133, as well as other data, such as user financial account information and contactless card information.

[0040] Application 133 may include one or more software applications, such as a card authentication module, which includes instructions for execution on server 130. In some examples, server 130 may execute one or more applications, such as software applications, that implement, for example, network communication with one or more components of system 100, transmission and / or reception of data, and performance of the functions described herein. After execution by processor 131, application 133 may provide the functions described herein, specifically, execute and perform the steps and functions in the processing flow described below. For example, the card authentication module of application 133 may be executed to authenticate a user based on contactless card 120. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. Application 133 may provide a GUI through which a user can view and interact with other components and devices within system 100. The GUI may be formatted as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), or, depending on the application used by the user to interact with system 100, any other suitable form for presentation on a display device.

[0041] Server 130 may also include a display 134 and an input device 135. Display 134 may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input device 135 may include any device available to and supported by server 130 for inputting information into server 130, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0042] Database 140 may be one or more databases configured to store data, including but not limited to user's private information, user's financial account, contactless card information, online merchant account information, user transactions, and merchant records indicating corresponding merchants. Database 140 may include relational databases, non-relational databases, or other database implementations and any combination thereof, including multiple relational databases and non-relational databases. In some examples, database 140 may include a desktop database, a mobile database, or an in-memory database. Furthermore, database 140 may be hosted internally by server 130 or externally by server 130, such as by a server, a cloud-based platform, or any storage device that communicates with server 130.

[0043] System 100 may include one or more networks 150. In some examples, network 150 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect user equipment 110, card 120, server 130, and database 140. For example, network 150 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiple access based system, code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi and / or similar networks.

[0044] Additionally, network 150 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Furthermore, network 150 may support Internet networks, wireless communication networks, cellular networks, or similar networks, or any combination thereof. Network 150 may also include one network or any number of exemplary types of networks mentioned above, operating independently or collaboratively with each other. Network 150 may utilize one or more protocols coupled to one or more network elements. Network 150 may convert other protocols to or from one or more protocols of network devices. Although network 150 is depicted as a single network, it should be understood that, according to one or more examples, network 150 may include multiple interconnected networks, such as, for example, the Internet, service provider networks, cable television networks, enterprise networks (such as credit card association networks), and home networks. Network 150 may also include or be configured to create one or more forward channels and one or more secure backward channels, wherein the forward channel may be publicly accessible and communication through the forward channel is observable, and the backward channel may be not publicly accessible and communication through the backward channel is not observable.

[0045] In some examples, communication between user equipment 110, server 130, and card 120 using network 150 may utilize one or more forward channels and one or more secure backward channels. The forward channel may employ a communication protocol that uses publicly accessible and / or insecure communication channels, allowing communication sent to user equipment 110, server 130, and / or card 120 to originate from any other device, whether user equipment 110, server 130, and / or card 120 are known or unknown, as long as that device possesses the addresses (e.g., network addresses, Internet Protocol (IP) addresses) of user equipment 110, server 130, and / or card 120. Exemplary forward channels include, but are not limited to, the Internet, open networks, and other publicly accessible communication networks. In some examples, communication sent using a forward channel is susceptible to unauthorized observation by another device. In some examples, forward channel communication may include Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL) communication, HTTP Secure (HTTPS) communication, and browser-based communication with servers or other devices.

[0046] A secure backchannel can be a communication protocol employing a secure and / or publicly inaccessible communication channel. Secure backchannel communication sent to user equipment 110, server 130, and / or card 120 may not originate from any single device, but may originate only from a selected number of parties. In some examples, the selected number of devices may include known, trusted, or otherwise previously authorized devices. Exemplary secure backchannels include, but are not limited to, closed networks, private networks, virtual private networks, offline private networks, and other dedicated communication networks. In some examples, communication sent using a secure backchannel may not be subject to unauthorized observation by another device. In some examples, secure backchannel communication may include Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL) communication, HTTP Secure (HTTPS) communication, and browser-based communication with servers or other devices.

[0047] Figure 2 Example Figure 200 illustrates a series of interactions between components of a system 100 according to an example embodiment. Figure 2 Can be quoted and Figure 1 The same or similar components shown include user equipment, servers, databases, and cards.

[0048] When a card, such as card 120, is issued to a user, the card is pre-loaded with a master key, a unique card identifier, a public key, and a private key paired with the public key. The user can tap card 120 against user equipment 110. After tapping card 120, user equipment 110 can transmit NFC prompts and / or queries to card 120. User equipment 110 may include an NFC interface configured to establish NFC communication with other NFC-enabled devices (card 120 in this embodiment). In some of these embodiments, the NFC interface of user equipment 110 may be or include an NFC receiver configured to selectively activate a magnetic field for establishing near-field communication with an NFC transmitter. When a passive NFC tag or other NFC-enabled device is brought into the magnetic field and within NFC communication range of user equipment 110, the NFC interface of user equipment 110 is configured to establish NFC communication. When card 120 is brought into the communication range of user equipment 110 (e.g., when card 120 is tapped to user equipment 110 by the user), the NFC interface of user equipment 110 is specifically configured to communicate with the NFC-enabled card 120. As used herein, tapping card 120 to user equipment 110 may not indicate physical contact between card 120 and user equipment 110. Tapping card 120 to user equipment 110 may indicate that card 120 has entered the NFC communication field of user equipment 110. In response, card 120 may transmit its public and private keys to user equipment 110. Therefore, at step 205, user equipment 110 may receive the public and private keys of card 120.

[0049] In step 210, user equipment 110 can transmit the card public key of card 120 to server 130. Because it is the card public key, there is no security issue of transmitting the card public key to server 130 via network 150.

[0050] At step 215, server 130 may store the public key of card 120 in database 140. At step 220, server 130 may retrieve the server public key and the server private key paired with the server public key from database 140.

[0051] At step 225, server 130 may transmit its server public key to user equipment 110. As used herein, the card public key and card private key of card 120 and the server public key and server private key of server 130 are key pairs suitable for key exchange protocols such as elliptic curve cryptography.

[0052] In step 230, user equipment 110 can generate a shared key based on the server public key of server 130 and the card private key of card 120. In step 235, user equipment 110 transmits the shared key to card 120. Card 120 can store the shared key on card 120.

[0053] At step 240, server 130 can independently generate the same shared key based on server 130's private key and card 120's public key. At step 245, server 130 can store the same shared key in database 140.

[0054] As mentioned above, transaction cards can be pre-configured with a unique card identifier and a master key during manufacturing. The transaction card is based on a symmetric cryptographic system, which relies on a distributed key distributed according to factors such as the master key, the unique card identifier, and a shared key. However, transmitting the shared key between the transaction card and the back-end verification server may expose the data security to risks. In this disclosure, the same shared key can be independently generated by the user equipment and the back-end verification server through a key negotiation protocol, which can improve data security.

[0055] This disclosure allows for the dynamic generation of a shared key and the distribution of other keys after a transaction card has been issued to a user. For example, the card may be newly issued or reissued to a user at a vending machine. Exemplary embodiments of this disclosure can securely unlock the card and allow the storage of a new shared key and other new distributed keys within the card. The card can be unlocked by a user device or a card reader of the vending machine.

[0056] Protocols such as ECDH can be used to generate shared keys for cards and for authentication, which can then be stored on the card. By applying ECDH, a user device / card can provide a backend server with the public key associated with the card while retaining the private key associated with it. Similarly, a backend server can provide a user device / card with the private key associated with it while maintaining the public key associated with it. The same shared key can be generated dynamically and independently by the user device / card and the backend server. For example, as... Figure 2 As shown, the user device / card can generate the same shared key using the public key associated with the backend server and the private key associated with the card. Similarly, the backend server can independently generate the same shared key using the public key associated with the card and the private key associated with the backend server. In this way, the shared key does not need to be transmitted between the backend server and the user device / card, which improves data security.

[0057] The shared key can be stored on the card. Alternatively, it can be stored on a backend server for card authentication. Preferably, the backend server can store the necessary components for regenerating the shared key for card authentication, such as storing the public key associated with the card and the private key associated with the backend server in the backend server's HSM. The backend server's HSM may require firmware to recreate the shared key and other distributed keys on the backend server. For example, the HSM may need to implement a specific key distribution algorithm to generate the shared key and other distributed keys on the backend server. The specific key distribution algorithm may include a static ECDH to maintain a consistent shared key for the card. The specific key distribution algorithm may also include a seed key for deriving keys.

[0058] In some embodiments, multi-factor authentication for a user can be performed on the user's device to generate a shared key for the card. For example, multi-factor authentication may include the user's login credentials (username and password) and a one-time password, etc.

[0059] Figure 3 Describes what can be used as Figure 1 The contactless card 300 in system 100. For example, Figure 1 Card 120 in the document may be the contactless card 300 described herein. The contactless card 300 is configured to communicate with user equipment 110 of system 100. The contactless card 300 may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider 305 (such as a bank associated with server 130) displayed on the front or back of the contactless card 300. In some examples, the contactless card 300 is not a payment card and may include, but is not limited to, ID cards, membership cards, and transportation cards. In some examples, the contactless card 300 may include a dual-interface contactless payment card.

[0060] The contactless card 300 may include a substrate 310, which may include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical properties conforming to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card 300 may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 300 according to this disclosure may have different characteristics, and this disclosure does not require the contactless card 300 to be implemented as a payment card.

[0061] The contactless card 300 may also include identification information 315 displayed on the front and / or back of the contactless card 300, and a contact pad 320. The contact pad 320 may be configured to establish contact with another communication device, such as a user equipment, smartphone, laptop, desktop computer, point-of-sale (PoS) terminal, vending machine, or tablet computer. The contactless card 300 may also include processing circuitry, an antenna, and other components. These components may be located behind the contact pad 320 or elsewhere on the substrate. The contactless card 300 may also include an EMV of a magnetic stripe or magnetic tape or an integrated circuit chip, which may be located on the back of the contactless card 300.

[0062] Figure 4 An example contact pad 405 of a contactless card 300 is shown. The contact pad 405 of the contactless card 300 may include processing circuitry 410 for storing and processing information, including a processor 420 and a memory 425. It should be understood that the processing circuitry 410 may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware.

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

[0064] In some embodiments, memory 425 may also store public and private card encryption keys. In some embodiments, the private and public encryption keys may be permanently hardwired into memory 425. In various embodiments, memory 425 may store instructions for generating encrypted information and transmitting it to a receiving device (e.g., user equipment 110). Such encrypted information may be or include encrypted verification blocks or signatures, which can be used to authenticate and verify the presence of card 300 during transaction processing. In some embodiments, the encrypted information may be unique for a specific communication (e.g., a specific NFC transmission of card 300).

[0065] Memory 425 may be configured to store one or more applets 430, one or more counters 435, and a unique customer identifier 440 (also referred to as the card's unique identification number, as described above). The one or more applets 430 may include one or more software applications, such as Java card applets, configured to execute on one or more contactless cards. However, it should be understood that the one or more applets 430 are not limited to Java card applets, but may be any software application that can operate on a contactless card or other device with limited memory. The one or more applets 430 may include EMV applets. The one or more counters 435 may include numeric counters sufficient to store integers. The unique customer identifier 440 may include a unique alphanumeric identifier assigned to a user of the contactless card 300, and the identifier distinguishes the user of the contactless card 300 from other contactless card users. In some examples, the customer identifier 440 may identify both the customer and the account assigned to that customer, and may also identify the contactless card 300 associated with the customer's account.

[0066] The processor 420 and memory 425 elements of the exemplary embodiments described above are described with reference to contact pad 405, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of contact pad 405, or completely separated from it, or as further elements beyond the processor 420 and memory 425 elements located within contact pad 405.

[0067] In some examples, the contactless card 300 may include one or more antennas 415. The one or more antennas 415 may be positioned within the contactless card 300 and around the processing circuitry 410 of the contact pad 405. For example, the one or more antennas 415 may be integrated with the processing circuitry 410, and the one or more antennas 415 may be used in conjunction with an external gain coil. As another example, the one or more antennas 415 may be located outside the contact pad 405 and the processing circuitry 410.

[0068] In one embodiment, the coil of the contactless card 300 can act as the secondary winding of an air-core transformer. A terminal (such as user equipment 110) can communicate with the contactless card 300 by cutting off power or amplitude modulation. The contactless card 300 can infer data transmitted from the terminal using gaps in the contactless card's power connection, the function of which can be maintained by one or more capacitors. The contactless card 300 can perform backhaul communication by switching loads or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference.

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

[0070] The contactless card 300 can be configured to communicate with the user equipment 110 via a communication interface configured to establish communication with the user equipment 110. The communication interface can be configured for contact-based communication, in which case the interface can have electronic circuitry and contact pads on the surface of the contactless card 300 for establishing direct electrical communication between the card 300 and the user equipment 110. Alternatively or additionally, the communication interface can be configured for contactless communication with the user equipment 110. In such embodiments, the communication interface may be or include an NFC communication interface configured to communicate with other NFC communication devices when the card 300 is within a predetermined NFC range. In some embodiments, the card 300 may include a second communication interface configured to establish short-range communication with the user equipment 110 via Bluetooth or other short-range communication methods. In such embodiments, the card 300 may have a short-range communication antenna included in or connected to the short-range communication interface. The card 300 may also include a power management system for managing power distribution during NFC transactions.

[0071] Figure 5 A flowchart is shown for a method for dynamically generating a shared key for a transaction card on the backend server side, according to an example embodiment. Figure 5 Can be quoted and Figures 1 to 4The same or similar components shown include user equipment, servers, databases, and contactless cards. Method 500 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0072] At step 505, server 130 may generate a public key and a private key for server 130. The public key and private key of server 130 may be a key pair suitable for a key exchange protocol such as elliptic curve cryptography.

[0073] At step 510, server 130 can receive the public key of card 120 from user equipment 110. The public key of card 120 is pre-installed on card 120 during its manufacture. When card 120 is tapped onto user equipment 110, card 120 can transmit its public key to user equipment 110. User equipment 110 can then transmit the public key of card 120 to server 130.

[0074] At step 515, server 130 can generate a shared key based on server 130's private key and card 120's public key by using a key negotiation protocol such as ECDH.

[0075] At step 520, server 130 may store the public key of card 120 on database 140 so that when card 120 is verified for future transactions, the same shared key can be regenerated by server 130 based on the private key of card 120.

[0076] At step 525, server 130 may further store the shared key on database 140. Although the shared key can be stored on database 140 for later verification of card 120, the same shared key is preferably regenerated when verifying card 120 in the future.

[0077] Figure 6 A flowchart of an example method 600 for dynamically generating a shared key for a transaction card on the transaction card side, according to an example embodiment, is shown. Figure 6 Can be quoted and Figures 1 to 5 The same or similar components shown include user equipment, servers, databases, and contactless cards. Method 600 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0078] At step 605, the public and private keys of card 120 are generated. When card 120 is issued to a user, card 120 may be pre-configured with a master key, a unique card identifier, and its public and private keys. The user can tap card 120 against user equipment 110. After tapping card 120, card 120 can transmit its public and private keys to user equipment 110.

[0079] At step 610, user equipment 110 may receive the public key of server 130. The private key of server 130 is stored by server 130, such as in database 140.

[0080] At step 615, user equipment 110 can generate a shared key based on the public key of server 130 and the private key of card 120. The shared key can be generated using a key negotiation protocol such as ECDH based on the public key of server 130 and the private key of card 120.

[0081] At step 620, user equipment 110 transmits a shared key to card 120. Card 120 may store the shared key on card 120.

[0082] Figure 7 Figure 700 illustrates tapping a transaction card onto a mobile device according to an example embodiment. Figure 7 Can be quoted and Figures 1 to 6 The same or similar components shown include user equipment, servers, databases, and contactless cards.

[0083] Figure 7 A diagram illustrating Near Field Communication (NFC) according to an exemplary embodiment is shown. Generally, NFC transmits data via electromagnetic radio fields, enabling two or more devices to communicate with each other without contact. NFC operates at a frequency of 13.56 MHz over the ISO / IEC 18000-3 air interface, with data rates ranging from 106 kbit / s to 424 kbit / s. When two NFC-enabled devices are placed within a very close distance (e.g., a few centimeters), they can perform transactions. NFC is beneficial for consumer transactions because it allows for near-instantaneous information reading. The receiving device can read the transmitted data the instant it is sent. Therefore, human error is greatly reduced. Furthermore, NFC reduces the time required to read cards. Consumers do not need to swipe their cards through a reader; they simply need to touch their card or user device to an NFC-enabled reader. In addition, NFC reduces the risk of interference from fraudsters. Because NFC devices can only communicate over very short distances, intercepting information transmitted between devices is extremely difficult.

[0084] Some examples of NFC communication include NFC card emulation, where a smartphone acts as a smart card, allowing users to perform transactions such as payments. As another example, NFC reader communication allows devices to read information stored on NFC tags embedded in labels or smart posters. As yet another example, NFC peer-to-peer communication allows two NFC-enabled devices to communicate with each other to exchange information.

[0085] The NFC standard covers communication protocols and data exchange formats, and is based on existing RFID standards, including ISO / IEC 14443 and FeliCa. These standards include ISO / IEC 18092 and those defined by the NFC Forum.

[0086] exist Figure 7 In this context, user equipment 705 (such as user equipment 110) and contactless card 710 (such as card 120) interact within an NFC field 715. User equipment 705 refers to... Figure 1 Further explanation. (Refer to contactless card 710) Figure 3 and Figure 4 Further explanation: Both the user equipment 705 and the contactless card 710 can support NFC technology. The user equipment 705 and the card 710 are in close contact with each other so that they can exchange information within the communication field 715, for example, by tapping the contactless card 710 onto the user equipment 705 as described above.

[0087] Figure 8 This is a flowchart of a method 800 for generating ciphertext using a shared key on the transaction card side, according to an example embodiment. Figure 8 Can be quoted and Figures 1 to 7 The same or similar components shown include user equipment, servers, databases, and contactless cards. Method 800 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0088] When a transaction is made using card 120, card 120 can be tapped onto user device 110, such as... Figure 7 As shown. At step 810, card 120 can update a counter to increment the counter. This counter can be updated with each session between card 120 / user equipment 110 and server 130. The counter can include a digital counter sufficient to store an integer. Card 120 can increment the counter once or multiple times.

[0089] As described above, the card 120 can have a pre-configured master symmetric key. At step 815, the card 120 can use the master symmetric key to generate an Encryption Session Key (ENC Session Key) and a Message Authentication Code (MAC) Session Key using an appropriate symmetric cryptographic algorithm. This algorithm can include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. The ENC Session Key and the MAC Session Key can be referred to as scatter keys. In some examples, the symmetric algorithm used to process the scatter values ​​can include any symmetric cryptographic algorithm used to generate a scatter symmetric key of the desired length as needed. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms such as 3DES or AES128; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC.

[0090] The Card 120 can use a master symmetric key to process the counter to generate two session keys: an ENC (encryption) session key and a MAC session key. The Card 120 can also use the master symmetric key to encrypt the counter with a selected symmetric encryption algorithm to create the two session keys.

[0091] At step 820, card 120 can generate a MAC using a MAC session key pair counter, a unique customer identifier, and a shared key. The shared key is generated using card 120's private key and server 130's public key and is then stored on card 120. The customer identifier may include a unique alphanumeric identifier assigned to the user of the contactless card, and the identifier distinguishes the user of the contactless card from other contactless card users. In some examples, the customer identifier may identify both the customer and the account assigned to that customer, and may further identify the contactless card associated with that customer account.

[0092] At step 825, card 120 encrypts the MAC using the ENC session key. After encryption, the MAC can become ciphertext. In some examples, cryptographic operations other than encryption can be performed, and multiple cryptographic operations can be performed using distributed symmetric keys before transmitting protected data.

[0093] In some examples, the MAC ciphertext can be a digital signature used to verify user information. Other digital signature algorithms (such as public-key asymmetric algorithms, like the Digital Signature Algorithm and RSA) or zero-knowledge protocols can be used to perform this verification.

[0094] At step 830, card 120 transmits ciphertext to user equipment 110. User equipment 110 may further transmit the ciphertext to server 130 for verification. The ciphertext may include applet information of card 120, a unique customer identifier, a counter, and an encrypted MAC address.

[0095] Figure 9 This is a flowchart of a method 900 for verifying ciphertext using a shared key on the backend server side, according to an example embodiment. Figure 9 Can be quoted and Figures 1 to 8 The same or similar components shown include user equipment, servers, databases, and contactless cards. Method 900 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0096] User equipment 110 can transmit the first ciphertext of card 120 to server 130 for verification. In step 905, the server receives the first ciphertext generated by card 120 from user equipment 110.

[0097] In step 910, server 130 may increment a counter value associated with card 120. This counter value may be stored in a database and associated with card 120 and the user of card 120.

[0098] In step 915, server 130 can retrieve the public key of card 120 and the private key of server 130 from database 140. The public key of card 120 was previously received by server 130 from user equipment 110.

[0099] In step 920, server 130 generates the same shared key based on the public key of card 120 and the private key of server 130. The same shared key is generated by a key negotiation protocol (such as the ECDH encryption method), and user equipment 110 also uses this protocol to generate the same shared key.

[0100] In step 925, server 130 may use the unique customer identifier, counter value and / or master key of card 120 to generate two session keys: an ENC (encryption) session key and a MAC (message authentication code) session key.

[0101] In step 930, server 130 uses the MAC session key to generate a MAC against the counter, unique customer identifier, and shared key.

[0102] In step 935, the server encrypts the MAC using the ENC session key. After encryption, the MAC can become a second ciphertext.

[0103] In step 940, server 130 may compare the first ciphertext and the second ciphertext to determine whether the first ciphertext matches the second ciphertext.

[0104] In step 945, server 130 can verify the first ciphertext. If it is determined that the first ciphertext matches the second ciphertext, the first ciphertext can be verified. Card 120 can then be verified accordingly.

[0105] Figure 10 This is a flowchart of a method 1000 for dynamically generating a shared key between a transaction card and a backend server, according to an example embodiment. Figure 10 Can be quoted and Figures 1 to 9 The same or similar components shown include user equipment, servers, databases, and contactless cards. Method 1000 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0106] In step 1005, a transaction card, such as card 120, is provided. The transaction card has a pre-configured private key and a public key derived from the private key. The transaction card may also have a pre-configured master key for deriving other keys.

[0107] In step 1010, a server, such as server 130, is provided. The server has a pre-configured private key and a public key derived from the private key. The server may also have a pre-configured master key used to derive other keys.

[0108] In step 1015, a user equipment such as user equipment 110 activates a communication field. User equipment 110 can then communicate data with a transaction card and / or a server through the communication field.

[0109] In step 1020, the user equipment receives the card's public key from the card. For example, the user equipment can read the card's public key by tapping the card.

[0110] In step 1025, the user equipment transmits the card public key to the server. The server generates a shared key from the card public key and the server private key according to the key negotiation protocol. The server may store the shared key in a database such as database 140.

[0111] In step 1030, the user equipment receives the server public key from the server.

[0112] In step 1035, the user equipment transmits the server public key to the transaction card. The transaction card generates the same shared key from the server public key and the card private key according to the same key negotiation protocol.

[0113] In some embodiments, the user equipment can generate the same shared key from the server's public key and the card's private key according to the same key negotiation protocol. The user equipment can then transmit the same shared key to the transaction card.

[0114] In some aspects, the technology described herein relates to a system for generating a shared key for a transaction card, the system comprising: a transaction card including a card private key and a card public key derived from the card private key; a server including a server private key and a server public key derived from the server private key; and a user equipment configured to: activate a communication field, read the card public key, transmit the card public key to the server, wherein the server generates a shared key based on the card public key and the server private key, receive the server public key from the server, and transmit the server public key to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0115] In some respects, the technology described herein relates to a system in which a card can store a shared key in a card memory.

[0116] In some respects, the technology described herein relates to a system in which the communication field includes at least one selected from the group consisting of near field communication (NFC), radio frequency identification (RFID), or Bluetooth.

[0117] In some respects, the technology described herein relates to a system in which the card is newly issued or recently issued.

[0118] In some respects, the technology described herein relates to a system in which both the card public key and the server public key are further derived from shared public values.

[0119] In some respects, the technology described herein relates to a system in which a shared public value is a unique identifier associated with the card.

[0120] In some respects, the technology described herein relates to a system in which a user equipment initiates a second communication field and receives a shared key from a transaction card.

[0121] In some respects, the technology described herein relates to a system in which a server encrypts a shared key with a key encryption key, and then stores the encrypted shared key in a data storage unit.

[0122] In some respects, the technology described herein relates to a system in which a server transmits an authentication request to a user equipment before storing a key, and then receives authentication credentials from the user equipment.

[0123] In some aspects, the technology described herein relates to a method for generating a shared key for a transaction card, the system comprising: providing a transaction card including a card private key and a card public key derived from the card private key; providing a server including a server private key and a server public key derived from the server private key; a user equipment (UE) initiating a communication field; the UE reading the card public key; the UE transmitting the card public key to the server, wherein the server generates a shared key based on the card public key and the server private key; the UE receiving the server public key from the server; and the UE transmitting the server public key to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0124] In some respects, the techniques described herein relate to a method in which the communication field includes at least one selected from the group consisting of a near-field communication (NFC) field, a radio frequency identification (RFID) field, or Bluetooth.

[0125] In some respects, the techniques described herein relate to a method, and also include authenticating user equipment based on a shared key.

[0126] In some respects, the technology described herein relates to a method that also includes automatically initiating a key exchange process when proximity to a transaction card is detected.

[0127] In some respects, the technology described herein relates to a method in which a user device and a transaction card are associated with the same user.

[0128] In some respects, the techniques described herein relate to a method that also includes requesting authentication credentials from a user associated with a user equipment prior to initiating a key exchange process.

[0129] In some respects, the techniques described herein involve a method that also includes generating a unique transaction-specific shared key for each transaction.

[0130] In some aspects, the technology described herein relates to a method, wherein the method further includes: receiving a request for a shared key from a server by a user equipment; transmitting the shared key from the user equipment to the server; and receiving a verification response from the server by the user equipment, the verification response indicating that the shared key from the card matches the shared key on the server.

[0131] In some respects, the techniques described herein relate to a method in which the method further includes generating a unique session-specific shared key for each transaction.

[0132] In some respects, the techniques described herein relate to a method in which the encrypted data includes at least one selected from a group consisting of unique user identification data, unique card data, or time data.

[0133] In some aspects, the technology described herein relates to a non-transitory computer-readable medium containing computer-executable instructions that, when executed by a computer hardware device, enable the computer hardware device to perform the following procedures: opening a communication field; reading a card public key from a card upon entering the communication field; transmitting the card public key to a server, wherein the server generates a shared key based on the card public key and a server private key; receiving a server public key from the server; and transmitting the server public key to a transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

[0134] Throughout this disclosure, terms such as “bank” or “issuing bank” are used, and it is to be understood that this disclosure is not limited to a particular bank or type of bank. Rather, this disclosure includes any type of bank, account and / or card issuer, or other entity involved in creating, issuing or providing accounts or cards associated with an account.

[0135] As used herein, the term "account" is not limited to a specific type of account. Rather, it should be understood that the term "account" can refer to a variety of accounts, including but not limited to financial accounts (e.g., credit accounts, debit accounts), membership accounts, loyalty accounts, subscription accounts, service accounts, utility accounts, transportation accounts, and physical access accounts. It should also be understood that this disclosure is not limited to accounts issued by a specific entity.

[0136] In some examples, exemplary programs according to this disclosure described herein can be executed by processing means and / or computing means (e.g., computer hardware means). Such processing and / or computing means can be, for example, all or part of a computer / processor, or include, but are not limited to, a computer / processor that may include, for example, one or more microprocessors, and uses instructions stored on computer-accessible media (e.g., RAM, ROM, hard disk drives, or other storage devices). For example, the computer-accessible media may be part of the memory of a first device, user equipment, server, or other computer hardware means.

[0137] In some examples, a computer-accessible medium (e.g., storage devices as described herein, such as hard disks, floppy disks, memory sticks, CD-ROMs, RAM, ROMs, etc., or combinations thereof) may be provided (e.g., for communication with a processing device). The computer-accessible medium may contain executable instructions thereon. Additionally, or alternatively, a storage device may be provided separately from the computer-accessible medium, which may provide instructions to the processing device to configure the processing device, for example, to perform certain exemplary programs, processes, and methods as described herein.

[0138] It should be noted further that the systems and methods described herein can be tangibly embodied in one or more physical media, such as, but not limited to, optical discs (CDs), digital versatile optical discs (DVDs), floppy disks, hard disks, read-only memory (ROM), random access memory (RAM), and other physical media capable of storing data. For example, data storage devices may include random access memory (RAM) and read-only memory (ROM), which can be configured to access and store data and information, as well as computer program instructions. Data storage may also include storage media or other suitable types of storage (such as, for example, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disks, optical discs, floppy disks, hard disks, removable magnetic tape cassettes, flash drives, and any type of tangible and non-transitory storage media), in which files constituting an operating system, applications (including, for example, web browser applications, email applications, and / or other applications), and data files can be stored. Data storage devices for network-enabled computer systems can include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases such as those created and maintained using software from, for example, 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 or cloud storage), or any other storage mechanism. Furthermore, these diagrams illustrate various components (e.g., servers, computers, processors, etc.). Functions described as performing at various components can be performed at other components, and the components can be combined or separated. Other modifications are also possible.

[0139] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing and / or processing devices, or downloaded to external computers or external storage devices via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). This network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing and / or processing device.

[0140] Computer-readable program instructions used to perform the operations of this invention may be assembly 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, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and similar languages, and traditional procedural programming languages ​​such as 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 a local area network (LAN) or a wide area network (WAN), or the connection may be established to an external computer (e.g., via the Internet through an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be personalized using state information from the computer-readable program instructions to perform aspects of the invention.

[0141] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for carrying out the functions specified herein. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to operate in a certain manner, such that the computer-readable storage medium in which the instructions are stored constitutes an article of writing comprising instructions for carrying out aspects of the functions specified herein.

[0142] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to perform a series of operational steps on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus or other device perform the function specified herein.

[0143] Implementations of the various techniques described herein can be carried out in digital electronic circuits, or in computer hardware, firmware, software, or combinations thereof. Implementations can be carried out as computer program products, for example, computer programs tangibly embodied in an information carrier, such as in a machine-readable storage device or in a propagating signal, for execution or control of their operation by a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). Computer programs (such as one or more computer programs as described above) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to execute on a single computer, or on multiple computers at a single site or distributed across multiple sites and interconnected via a communication network.

[0144] The method steps can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating output. The method steps can also be executed by special-purpose logic circuitry (e.g., FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit)), and the apparatus can be implemented as special-purpose logic circuitry.

[0145] Throughout this disclosure, unless the context clearly specifies otherwise, the following terms will have at least the meaning explicitly relevant herein. The term “or” means inclusive “or”. Furthermore, the terms “a,” “an,” and “the” mean one or more, unless otherwise specified or the context clearly indicates that they refer to the singular form.

[0146] Numerous specific details have been set forth in this specification. However, it should be understood that embodiments of the disclosed technology can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description. References to “some examples,” “other examples,” “an example,” “example,” “various examples,” “an embodiment,” “an embodiment,” “some embodiments,” “example embodiments,” “various embodiments,” “an implementation,” “implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that one or more embodiments of the disclosed technology thus described may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, the repeated use of the phrases “in an example,” “in an embodiment,” or “in an implementation” does not necessarily refer to the same example, embodiment, or implementation, although it may.

[0147] As used herein, unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe common objects merely indicates that different instances of similar objects are referenced, and does not imply that the objects described must be in a given sequence in time, space, rank, or any other way.

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

[0149] This written description uses examples to disclose certain embodiments of the disclosed technology, including best practices, and also enables those skilled in the art to practice certain embodiments of the disclosed technology, including making and using any device or system and performing any combined methods. The patentable scope of certain embodiments of the disclosed technology is defined in the claims and may include other examples that would occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that are indistinguishable from the literal language of the claims, or if they include equivalent structural elements that differ only in non-substantially from the literal language of the claims.

Claims

1. A system for generating a shared key for a transaction card, the system comprising: A transaction card, which includes a card private key and a card public key derived from the card private key; The server includes a server private key and a server public key derived from the server private key; and The user equipment is configured as follows: Activate the communication field. Read the card's public key. The card's public key is transmitted to the server, whereby the server generates a shared key based on the card's public key and the server's private key. Receive the server public key from the server, and The server public key is transmitted to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

2. The system according to claim 1, wherein, The card stores the shared key in the card memory.

3. The system according to claim 1, wherein, The communication field includes at least one selected from the group consisting of near field communication (NFC), radio frequency identification (RFID), or Bluetooth.

4. The system according to claim 1, wherein, The card is newly issued or recently issued.

5. The system according to claim 1, wherein, The card public key and the server public key are further derived from shared public values.

6. The system according to claim 5, wherein, The shared public value is a unique identifier associated with the card.

7. The system according to claim 1, wherein, The user equipment activates the second communication field and receives the shared key from the transaction card.

8. The system according to claim 1, wherein, The server encrypts the shared key using a key encryption key, and then stores the encrypted shared key in the data storage unit.

9. The system according to claim 8, wherein, Before storing the key, the server transmits an authentication request to the user equipment and then receives authentication credentials from the user equipment.

10. A method for generating a shared key for a transaction card, the method comprising: Provides a transaction card that includes a card private key and a card public key derived from the card private key; A server that provides a private key and a public key derived from the private key; The communication field is initiated by the user equipment; The user equipment reads the card's public key; The user equipment transmits the card public key to the server, wherein the server generates a shared key based on the card public key and the server private key; The user equipment receives the server public key from the server; and The user equipment transmits the server public key to the transaction card, wherein the card generates the same shared key based on the server public key and the card private key.

11. The method according to claim 10, wherein, The communication field includes at least one selected from the group consisting of near field communication (NFC), radio frequency identification (RFID), or Bluetooth.

12. The method of claim 10, further comprising authenticating the user equipment based on the shared key.

13. The method of claim 10, further comprising automatically initiating a key exchange process upon detection of proximity to the transaction card.

14. The method of claim 10, wherein, The user equipment and the transaction card are associated with the same user.

15. The method of claim 10, further comprising requesting authentication credentials from a user associated with the user equipment before initiating a key exchange process.

16. The method of claim 10, further comprising generating a unique transaction-specific shared key for each transaction.

17. The method according to claim 10, further comprising: The user equipment receives a request for the shared key from the server; The shared key is transmitted from the user equipment to the server; as well as The user equipment receives an authentication response from the server, the authentication response indicating that the shared key from the card matches the shared key on the server.

18. The method according to claim 10, wherein, The method also includes generating a unique session-specific shared key for each transaction.

19. The method according to claim 18, wherein, The encrypted data includes at least one of the following: unique user identification data, unique card data, or time data.

20. A non-transitory computer-readable medium comprising computer-executable instructions, which, when executed by a computer hardware device, cause the computer hardware device to perform a program comprising the following operations: Enable communication field; Read the card public key from the transaction card upon entering the communication field; The card's public key is transmitted to the server, wherein the server generates a shared key based on the card's public key and the server's private key; Receive the server public key from the server; and The server public key is transmitted to the transaction card, wherein the transaction card generates the same shared key based on the server public key and the card private key.

Images