Systems and methods for providing contactless cards for transactions

Abstract

Systems and methods for providing contactless cards for transactions are disclosed. In an exemplary transaction configuration system, an authentication server receives a session creation request from a backend server to configure a contactless card, and transmits a session creation response and a session token to the backend server. The authentication server receives, from the backend server, an authentication process function request including encrypted data associated with the contactless card, decrypts the encrypted data to produce a decrypted authentication code, and compares the decrypted authentication code to an expected authentication code. Upon the unsuccessful comparison, the authentication server transmits a notification to the back-end server indicating the unsuccessful authentication to the back-end server. After successful comparison, the authentication server transmits a session identifier and a capital primary account associated with the session creation request to the back-end server.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 524,601, filed June 30, 2023, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0003] Contactless card products have become so ubiquitous and pervasive that they have fundamentally changed how financial transactions and business processes are viewed and conducted in today's society. Contactless card products are most commonly represented by plastic or metal card-like components issued and provided to customers by credit card issuers such as banks and other financial institutions. Using the card, authorized customers or cardholders are able to purchase services and / or goods without immediately exchanging cash. Data security and transaction integrity are critical to the businesses and customers facilitating these transactions. This demand continues to grow as electronic transactions performed using contactless cards constitute an increasingly larger share of business activity. Therefore, there is a need for a suitable solution for businesses and users that overcomes current shortcomings to provide data security, authentication, and verification for contactless cards. Summary of the Invention

[0004] In one aspect, a transaction configuration system includes an authentication server comprising a processor and a memory storing expected authentication codes for contactless cards. The authentication server receives a session creation request from a backend server for provisioning a contactless card, transmits a session creation response and a session token to the backend server, receives an authentication process function request from the backend server including encrypted data associated with the contactless card, decrypts the encrypted data to generate a decrypted authentication code, compares the decrypted authentication code with the expected authentication code, transmits a notification indicating unsuccessful authentication to the backend server after an unsuccessful comparison, and transmits a session identifier and a funds master account associated with the session creation request after a successful comparison.

[0005] The transaction configuration system may also include: an authentication server receiving a request from a backend server to establish a virtual card number (VCN) autofill procedure, receiving a qualification request associated with a contactless card from a token server, and, after determining that the contactless card is qualified, sending a notification indicating qualification to the token server.

[0006] The transaction configuration system may also include: wherein the authentication function request further includes at least one selected from the group of session identifier, consent date and device identifier.

[0007] The transaction configuration system may also include: where the authentication function request also includes a wallet identifier associated with the digital wallet.

[0008] The trading configuration system may also include: where the authentication function request includes one or more risk signals.

[0009] The transaction configuration system may also include: one or more of the risk signals including at least one selected from the group of device phone number, email address, account risk score, device risk score, Internet Protocol (IP) address, device geolocation, account-to-device binding identifier, and device-to-account binding age.

[0010] The transaction configuration system may also include: where device phone numbers and email addresses are hashed.

[0011] The transaction configuration system may also include: the authentication process function request further includes one or more risk signals, and the one or more risk signals are generated by the backend server.

[0012] The transaction configuration system may also include: wherein, before transmitting the session identifier and the encrypted master fund account, the authentication server assesses one or more risk signals, and after determining, based on one or more risk signals, that the authentication process function request is fraudulent, transmits a notification indicating a fraudulent transaction to the backend server.

[0013] The transaction configuration system may also include: an authentication server that evaluates one or more risk signals and determines, based on one or more risk signals, that the authentication process function request is not fraudulent before transmitting the session identifier and the encrypted master fund account.

[0014] In one aspect, a transaction configuration method performed by an authentication server, the authentication server including a processor and a memory, the method comprising receiving a session creation request for configuring a contactless card from a backend server; transmitting a session creation response and a session token to the backend server; receiving an authentication process function request from the backend server including encrypted data associated with the contactless card; decrypting the encrypted data to generate a decrypted authentication code; comparing the decrypted authentication code with an expected authentication code associated with the contactless card; transmitting a notification indicating unsuccessful authentication to the backend server after an unsuccessful comparison; and transmitting a session identifier and a funds master account associated with the session creation request after a successful comparison.

[0015] The method may also include: the master fund account being encrypted before transmission.

[0016] The method may also include: wherein the authentication process function request further includes one or more risk signals, and the one or more risk signals are generated by a backend server.

[0017] The method may also include: assessing one or more risk signals before transmitting the session identifier and the encrypted master fund account; and, after determining that the authentication process function request is fraudulent based on one or more risk signals, transmitting a notification indicating a fraudulent transaction to a backend server.

[0018] The method may also include: assessing one or more risk signals; and determining, based on one or more risk signals, that the authentication process function request is not fraudulent before transmitting the session identifier and the encrypted master fund account.

[0019] The method may further include: wherein the authentication function request also includes at least one selected from the group of session identifier, consent date and device identifier.

[0020] The method may also include: wherein the authentication function request further includes a wallet identifier associated with the digital wallet.

[0021] In one aspect, a non-transitory computer-readable medium containing instructions, wherein, when executed by a processor, the instructions cause the processor to perform a process comprising the following steps: receiving a session creation request from a backend server for configuring a contactless card; transmitting a session creation response and a session token to the backend server; receiving an authentication process function request from the backend server including encrypted data associated with the contactless card; decrypting the encrypted data to generate a decrypted authentication code; comparing the decrypted authentication code with an expected authentication code associated with the contactless card; transmitting a notification indicating unsuccessful authentication to the backend server after an unsuccessful comparison; and transmitting a session identifier and a funds master account associated with the session creation request after a successful comparison.

[0022] The non-transitory computer-readable medium may also include the process, which further includes: receiving a request from a back-end server to establish a virtual card number (VCN) autofill procedure, receiving an eligibility request associated with the contactless card from a token server, and, after determining that the contactless card is eligible, transmitting a notification indicating eligibility to the token server.

[0023] The non-transitory computer-readable medium may also include: wherein the authentication function request further includes at least one selected from the group of session identifier, consent date and device identifier.

[0024] Other technical features will be obvious to those skilled in the art from the following figures, description and claims. Attached Figure Description

[0025] The following is a brief description of several views of the accompanying drawings, which illustrate various aspects of some embodiments of this disclosure. The drawings are described in more detail below.

[0026] Figure 1 A data transmission system according to an example embodiment is shown.

[0027] Figure 2 A data transmission system according to an example embodiment is shown.

[0028] Figure 3 A contactless card according to one embodiment is shown.

[0029] Figure 4 The components of a contactless card according to an example embodiment are shown.

[0030] Figure 5 A sequence diagram according to an example embodiment is shown.

[0031] Figure 6 A data structure according to an example embodiment is shown.

[0032] Figure 7 A key system according to an example embodiment is shown.

[0033] Figure 8 A method according to an example embodiment is shown.

[0034] Figure 9 A method according to an example embodiment is shown.

[0035] Figure 10 A method according to an example embodiment is shown.

[0036] Figure 11 A system according to an example embodiment is shown.

[0037] Figure 12 A sequence diagram according to an example embodiment is shown.

[0038] Figure 13A A sequence diagram according to an example embodiment is shown.

[0039] Figure 13B A sequence diagram according to an example embodiment is shown.

[0040] Figure 13C A sequence diagram according to an example embodiment is shown.

[0041] Figure 14 A data structure according to an example embodiment is shown.

[0042] Figure 15 A method according to an example embodiment is shown.

[0043] Figure 16 A system according to an example embodiment is shown.

[0044] Figure 17 A method according to an example embodiment is shown.

[0045] Figure 18 A sequence diagram according to an example embodiment is shown.

[0046] Figure 19A A sequence diagram according to an example embodiment is shown.

[0047] Figure 19B A sequence diagram according to an example embodiment is shown.

[0048] Figure 20A A sequence diagram according to an example embodiment is shown.

[0049] Figure 20B A sequence diagram according to an example embodiment is shown.

[0050] Figure 21 A computer architecture according to an example embodiment is shown.

[0051] Figure 22 A communication architecture based on an example embodiment is shown. Detailed Implementation

[0052] The following description of exemplary embodiments provides non-limiting representative examples, with reference to figures used to specifically describe the features and teachings of different aspects of the invention. The described embodiments should be considered as being able to be implemented alone or in combination with other embodiments described from the embodiments. Those skilled in the art who review the description of the embodiments should be able to learn and understand the different descriptive aspects of the invention. The description of the embodiments is intended to promote an understanding of the invention to the extent that other implementations 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.

[0053] Furthermore, the features, advantages, and characteristics described in the exemplary embodiments can be combined in any suitable manner. Those skilled in the art will recognize that embodiments can be practiced without one or more specific features or advantages of the embodiments. In other instances, additional features and advantages may be recognized in some embodiments but may not be present in all embodiments. Those skilled in the art will understand that the features, advantages, and characteristics described in any embodiment can be combined interchangeably with the features, advantages, and characteristics of any other embodiment.

[0054] This document discloses example embodiments of systems and methods for secure cryptographic authentication of contactless cards to execute transactions (including but not limited to financial transactions). As contactless cards have become ubiquitous, the ability to securely communicate with, authenticate with, and execute transactions using contactless cards is essential for many entities.

[0055] The systems and methods described in this article for data security, authentication, and transactions using contactless cards offer numerous advantages. For example, these systems and methods can provide a better customer experience and higher conversion rates. In some examples, conversion rates can be calculated for card configuration, card account archiving, and transactions.

[0056] As another example, the systems and methods described herein allow users to add cards for use with a transaction processing entity by tapping the card onto a client device. Users can interact with a user interface (such as one presented by the transaction processing entity) for card tapping, card reading by the client device, providing terms and conditions and receiving user consent, and providing the card to the transaction processing entity.

[0057] As another example, the systems and methods described herein allow for data exchange between transaction processing entities and other entities such as card entities (e.g., card issuing entities, card verification entities). Exemplary data to be exchanged may include telephone numbers (e.g., telephone numbers associated with users and / or accounts associated with the card) and a set of risk signals employed by the transaction processing entity for card configuration purposes (e.g., with payment processing entities). The data to be exchanged may also include data related to wallets or other accounts maintained by the transaction processing entity, such as device identifiers, wallet identifiers, server session identifiers, and client session identifiers.

[0058] As another example, the systems and methods described herein provide a sequence of operations to be performed by a transaction processing entity and another entity, such as a card entity associated with the issuance and / or verification of a contactless card. In some examples, after the card is tapped onto a client device, an application associated with the transaction processing entity reads the card and selects an applet to perform authentication and / or card configuration functions on the client device. The application may transmit a card configuration request to a server associated with the card entity, and the card configuration request may include a payload associated with the applet, a device identifier, a wallet identifier, a server session identifier, a client session identifier, and / or one or more risk signals. The server may perform authentication and / or verification of the contactless card and / or the card configuration request. The server may transmit a push configuration notification to a server associated with the transaction processing entity, and the push configuration notification may include a session identifier, a wallet identifier, an OPC, a funding primary account number (FPAN), and an expiration date. The server associated with the transaction processing entity may acknowledge the push configuration notification in a notification transmitted to the server associated with the card entity. The server associated with the card entity may acknowledge this acknowledgment by transmitting a notification to the application.

[0059] As another example, the system and method can provide a series of operations for configuration between a transaction processing entity (e.g., its associated application or server) and a card entity (e.g., its associated application or server). In some examples, the transaction processing entity may transmit to the card entity an app payload, a wallet identifier, a session identifier (e.g., a server session identifier, a client session identifier), a phone number associated with the client device, user, and / or account (associated with the card), and / or one or more risk signals. The card entity can configure the card with the card information and share the card information with the backend associated with the transaction processing entity. The transaction processing entity can save the card archive to the account. The transaction processing entity can exchange app payloads with the payment processing network to generate one or more device-specific numbers.

[0060] As another example, the systems and methods described herein provide risk signals. Exemplary risk signals may include, but are not limited to, account age, account change data, account identifier, account risk score, account-to-device binding age, customer email, customer phone number, device geolocation, device identifier, device internet protocol (IP) address, device name, device operating system and version, device risk score, primary account number (PAN) and PAN identifier, PAN input pattern, PAN source indicator, payment method attempts, configuration decisions and codes, and usage speed.

[0061] As another example, the systems and methods described herein provide a sequence of operations for a push configuration application programming interface (API). In some examples, the API can be associated with a transaction processing entity. A user can choose to add a card used with the transaction processing entity to an application running on a client device, and this application can be associated with the card entity. The application can transmit instructions to the push configuration software development kit (SDK) for creating a push configuration session, and the push configuration SSD can transmit a device identifier, wallet identifier, and server session identifier to the application. The application can transmit the device identifier, wallet identifier, and session identifier to a backend associated with the card entity, and the backend associated with the card entity can acknowledge the transmission by sending a notification to the application. The application can transmit instructions to the push configuration SSD to create a server push configuration, which may include the device identifier, wallet identifier, session identifier, billing address associated with the card, user associated with the card and / or account associated with the card, and card display name. The application can then wait for the results of subsequent activities. The backend associated with the card entity can send a push configuration notification to the backend associated with the transaction processing entity, which may include the session identifier, wallet identifier, OPC, FPAN, and expiration date. The backend associated with the transaction processing entity can acknowledge the notification by sending a notification to the backend associated with the card entity. The backend associated with the transaction processing entity can save the card archive to the transaction processing entity's account. The push configuration software development kit can provide the device tokenization process and send notifications of activity results to the application, which may include token results, card results, token reference identifiers, and one or more error notifications.

[0062] As another example, the systems and methods described herein can provide the utilization of card taps to add cards associated with a transaction processing entity. In some examples, a virtual card number (VCN) can be created and / or registered for the card.

[0063] In some cases, the contactless card functionalities discussed in this article can be used in multi-issuer computing environments. These functionalities can include tap functionality, where users can tap their contactless cards on a device, such as a mobile device, to perform functions. For example, users can use their contactless cards to verify their identity, make payments, launch applications, log in to applications, autofill forms or fields, navigate to applets on a specified network location or device, unlock doors, initiate contactless card transactions, verify themselves, and so on.

[0064] The systems discussed here enable users to perform these functions in a multi-issuer environment. Furthermore, the systems discussed herein allow card issuers or payment providers (such as banks) to issue contactless cards with tap functionality to customers while maintaining high security. The systems discussed differ from previous solutions because they provide a single platform for multiple issuers to offer tap functionality. Traditionally, each issuer must build and maintain its own system to provide contactless card features. This includes maintaining its own hardware, software, databases, security protocols, etc., which can become very costly for issuers. However, the embodiments discussed allow issuers to offload most of the processing, storage, and security functions to a neutral or central system. As will be discussed in more detail, the central system is configured to provide contactless card features for multiple issuers while maintaining high security and data integrity. Each issuer's functionality and data can be managed and protected separately, preventing another issuer from accessing another issuer's data or functionality. As will be discussed in more detail, these features can be provided by a switchboard system configured to securely process and execute each contactless card function. Additional benefits for publishers could include providing highly secure authentication options for mobile networks, which are often lacking in the robust authentication options available in native applications.

[0065] Furthermore, the embodiments discussed herein utilize App Clips and Javascript Software Development Kit (SDK) and WebNFC On two major mobile platforms (iOS) Android Supports tap-to-connect mobile network experience on iOS. Implementation examples include providing a touch software development kit, including in iOS The platform provides the functions and services that perform the operations discussed in this article. The SDK can be installed into the main application, such as a native app or a web browser app, and includes App Clips. Supported. The SDK provides functional support for near-field communication between mobile devices and contactless cards, via App Clips. Install native applets and provide the ability to blur data and / or display portions. In one example, the SDK can be configured to be downloaded from an app store (such as Apple's). Download and install the app from the App Store.

[0066] In Android In an operating system environment, the implementation includes using the JavaScript SDK. The JavaScript SDK can be installed into a website, for example, via source code. The JavaScript SDK also includes installation via WebNFC. It supports NFC communication between mobile devices and contactless cards. The JavaScript SDK may also include features providing a customizable user interface (UI) and obfuscation capabilities. In this embodiment, the JavaScript SDK supports websites using Hypertext Transfer Protocol Secure (HTTPS) and supports React. Library. Implementation examples are not limited to this approach and may support UI libraries.

[0067] Referring generally to the symbols and nomenclature used herein, one or more parts of the following detailed description can be presented in terms of a program procedure that can be executed on a computer or computer network. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. The process herein, and generally, is conceived as a self-consistent sequence of operations that leads to a desired result. These operations are those that require physical manipulation of physical quantities. Typically, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. Primarily for reasons of common use, these signals are sometimes referred to as bits, values, elements, symbols, characters, items, numbers, or such terms as proves convenient. However, it should be noted that all these and similar terms are to be associated with appropriate physical quantities and are merely convenient notations applied to those quantities.

[0068] Furthermore, these manipulations are often referred to using terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such ability of a human operator is not necessary, or in most cases not desirable. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings herein, and / or including devices or digital computers specifically constructed for the desired purpose. The various embodiments also relate to devices or systems for performing these operations. These devices can be specifically constructed for the desired purpose. The necessary structures for the various such machines will be apparent from the given description.

[0069] Referring now to the accompanying drawings, wherein the same reference numerals are consistently used to refer to the same elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding thereof. However, it will be apparent that novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate the description thereto. All modifications, equivalents, and substitutions are intended to cover within the scope of the claims.

[0070] Figure 1 A data transmission system 100 according to an example embodiment is shown. As discussed further below, system 100 may include a contactless card 102, a client device 104, a network 106, and a server 108. Although Figure 1 A single instance of a component is shown, but system 100 may include any number of components.

[0071] System 100 may include one or more contactless cards 102, as explained further below. In some embodiments, the contactless card 102 may wirelessly communicate with the client device 104 using NFC, as in the example.

[0072] System 100 may include client device 104, which may be a network-enabled computer. As mentioned herein, a network-enabled computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, networked appliances, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, thick clients, internet browsers, or other devices. Client device 104 may also be a mobile device; for example, a mobile device may include devices from Apple. iPhone, iPod, iPad, or running Apple's iOS Any other mobile device running the operating system, or Microsoft Windows. Any device running the Mobile operating system, or Google's Android. Any device with an operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

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

[0074] In some examples, the client device 104 of system 100 may execute one or more applications, such as software applications, which enable, for example, network communication, transmission and / or reception of data with one or more components of system 100.

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

[0076] System 100 may include one or more networks 106. In some examples, network 106 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 104 to server 108. For example, network 106 may include one or more of the following: fiber optic network, passive optical network, cable network, internetwork, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11 networking family, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi and / or the like.

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

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

[0079] Figure 2 A data transmission system according to an example embodiment is illustrated. System 200 may include, for example, a transmitter or transmission device 204, and a receiver or receiving device 208, communicating with one or more servers 202 via network 206. The transmitter or transmission device 204 may be the same as those referenced above. Figure 1The client device 110 discussed in A is the same as or similar to the one mentioned above. The receiver or receiving device 208 may be the same as described above. Figure 1 The client device 110 discussed in A is the same as or similar to that discussed above. Network 206 can be referenced above. Figure 1 The network discussed in A is similar to 115. Server 202 can be referenced above. Figure 1 The server discussed in A is similar to server 120. Although Figure 2 A single instance of the components of system 200 is shown, but system 200 may include any number of the components shown.

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

[0081] Importantly, the same key should not be used too many times. If a key is used or reused too frequently, it can become compromised. Each time a key is used, it provides an attacker with additional data samples that are processed by the cryptographic algorithm using the same key. The more data an attacker possesses that is processed using the same key, the greater the likelihood that the attacker can discover the key value. Frequently used keys can be included in a variety of different attacks.

[0082] Furthermore, each time a symmetric cryptographic algorithm is executed, it can reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data can include minute power fluctuations that occur while the cryptographic algorithm is being executed using the key. Sufficient measurements can be taken from the side-channel data to reveal enough information about the key, thus allowing an attacker to recover the key. Using the same key to exchange data will repeatedly reveal data processed by the same key.

[0083] However, by limiting the number of times a specific key will be used, the amount of side-channel data an attacker can collect is limited, thus reducing exposure and other types of attacks. As further described herein, in situations where any form of key exchange is required to keep parties synchronized, the parties involved in the exchange of cryptographic information (e.g., the sender and receiver) can independently generate keys from an initial shared master symmetric key combined with a counter value, thereby periodically replacing the shared symmetric key in use. By periodically changing the shared secret symmetric key used by the sender and receiver, the attacks described above become impossible.

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

[0085] System 200 may include one or more networks 206. In some examples, network 206 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect one or more transmitting devices 204 and one or more receiving devices 208 to server 202. For example, network 206 may include one or more of the following: fiber optic network, passive optical network, cable network, internetwork, satellite network, wireless LAN, Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11 network family, Bluetooth, NFC, RFID, Wi-Fi and / or the like.

[0086] Furthermore, network 206 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 802.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 206 may support interconnected networks, wireless communication networks, cellular networks, or the like, or any combination thereof. Network 206 may also include a single network or any number of exemplary types of networks mentioned above, operating as independent networks or cooperatively with each other. Network 206 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 206 may be converted to one or more protocols of network devices or converted from other protocols to one or more protocols of network devices. Although network 206 is depicted as a single network, it should be recognized that, according to one or more examples, network 206 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

[0087] In some examples, one or more transmitting devices 204 and one or more receiving devices 208 can be configured to communicate with each other and transmit and receive data without traversing network 206. For example, communication between one or more transmitting devices 204 and one or more receiving devices 208 can occur via at least one of NFC, Bluetooth, RFID, Wi-Fi and / or the like.

[0088] At block 210, the sender may update the counter when the transmitting device 204 is preparing to process sensitive data using symmetric cryptographic operations. Furthermore, the transmitting device 204 may select an appropriate symmetric cryptographic algorithm, which may include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process diverse values ​​may include any symmetric cryptographic algorithm used to generate diverse symmetric keys of the desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES128; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. It will be appreciated that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as processing the symmetric algorithm multiple times with different input data and the same master key can produce multiple outputs, which can be combined as needed to generate a sufficiently long key.

[0089] At block 212, the transmitting device 204 can employ a selected cryptographic algorithm and use a master symmetric key to process the counter value. For example, the sender can choose a symmetric encryption algorithm and use a counter that is updated with each conversation between the transmitting device 204 and the receiving device 208. The transmitting device 204 can then use the master symmetric key to encrypt the counter value using the selected symmetric encryption algorithm, thereby creating a diversified symmetric key.

[0090] In some examples, the counter value may not be encrypted. In these examples, at block 212, the counter value can be transmitted between transmitting device 204 and receiving device 208 without encryption.

[0091] At block 214, a diversified symmetric key can be used to process sensitive data before sending the result to receiving device 208. For example, transmitting device 204 can encrypt sensitive data using a symmetric encryption algorithm that uses a diversified symmetric key, where the output includes protected encrypted data. Transmitting device 204 can then transmit the protected encrypted data along with a counter value to receiving device 208 for processing.

[0092] At block 216, receiving device 208 may first take a counter value, and then use the counter value as input to encryption and the master symmetric key as the key for encryption to perform the same symmetric encryption. The output of the encryption may be the same diversified symmetric key value created by the sender.

[0093] At block 218, receiving device 208 can then take the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm and a variety of symmetric keys.

[0094] At block 220, the original sensitive data can be revealed as a result of decrypting the protected encrypted data.

[0095] The next time sensitive data needs to be transmitted from the sender to the receiver via the corresponding transmitting device 204 and receiving device 208, different counter values ​​can be selected to generate different diversified symmetric keys. By using the master symmetric key and processing the counter value with the same symmetric encryption algorithm, both the transmitting device 204 and the receiving device 208 can independently generate the same diversified symmetric key. This diversified symmetric key (instead of the master symmetric key) is used to protect the sensitive data.

[0096] As explained above, both transmitting device 204 and receiving device 208 initially possess a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Because the diversification symmetric key is created independently by both transmitting device 204 and receiving device 208, it is never transmitted between them. Therefore, an attacker cannot intercept this diversification symmetric key, and an attacker will never see any data processed using the master symmetric key. Only counter values ​​are processed using the master symmetric key, not sensitive data. As a result, reduced side-channel data regarding the master symmetric key is revealed. Furthermore, the operation of transmitting device 204 and receiving device 208 can be governed by the following symmetric requirement: how often to create new diversification values ​​and therefore new diversification symmetric keys. In one embodiment, new diversification values ​​and therefore new diversification symmetric keys can be created for each exchange between transmitting device 204 and receiving device 208.

[0097] In some examples, the key diversification value may include a counter value. Other non-limiting examples of the key diversification value include: a random nonce generated each time a new diversification key is needed; a random nonce sent from transmitting device 204 to receiving device 208; the full value of the counter value sent from transmitting device 204 and receiving device 208; a portion of the counter value sent from transmitting device 204 and receiving device 208; a counter maintained independently by transmitting device 204 and receiving device 208 but not sent between the two devices; a one-time password exchanged between transmitting device 204 and receiving device 208; 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. Further, combinations of one or more exemplary key diversification values ​​described above may be used.

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

[0099] Figure 3An example configuration of a contactless card 102 is shown, which may include a contactless card issued by a service provider, a payment card (such as a credit card, debit card, or gift card), as indicated by the service provider mark 302 displayed on the front or back of the contactless card 102. In some examples, the contactless card 102 is not related to a payment card and may include, but is not limited to, an ID card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 102 may include a substrate 308, which may include a single layer or one or more laminates composed of plastics, metals, 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 102 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may otherwise conform to the ISO / IEC 14443 standard. However, it will be recognized that the contactless card 102 according to this disclosure may have different characteristics, and this disclosure does not require the transaction card to be implemented in a payment card.

[0100] The contactless card 102 may also include identification information 306 displayed on the front and / or back of the card, and a contact pad 304. The contact pad 304 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop computer, or tablet computer) via the transaction card. The contact pad may be designed according to one or more standards (such as the ISO / IEC 7816 standard) and enable communication according to the EMV protocol. The contactless card 102 may also include a processing circuit system, an antenna, and other components, as will be... Figure 4 This will be discussed further. These components may be located behind the contact pad 304 or elsewhere on the substrate 308, such as within different layers of the substrate 308, and may be electrically and physically coupled to the contact pad 304. The contactless card 102 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card. Figure 3 (Not shown in the image). The contactless card 102 may also include an antenna-coupled near-field communication (NFC) device capable of communicating via the NFC protocol. Embodiments are not limited to this approach.

[0101] like Figure 4As shown, the contact pad 304 of the contactless card 102 may include a processing circuitry 416 for storing, processing, and transmitting information. This processing circuitry includes a processor 402, a memory 404, and one or more interfaces 406. It will be appreciated that the processing circuitry 416 may include additional components, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as required to perform the functions described herein.

[0102] Memory 404 can be a read-only memory, a write-once-read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 102 may include one or more of these memories. Read-only memory can be programmed by the manufacturer to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-once / read-many memory can be programmed at some point after the memory chip has been manufactured. Once programmed, the memory cannot be rewritten but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can also be read multiple times after leaving the factory. In some instances, memory 404 can be encrypted memory, which uses an encryption algorithm executed by processor 402 to encrypt data.

[0103] Memory 404 can be configured to store one or more applets 408, one or more counters 410, a customer identifier 414, and an account 412, which may be a virtual account. The one or more applets 408 may include one or more software applications configured to execute on one or more contactless cards, such as Java. The Card app is not limited to Java Card; however, it will be appreciated that the app 408 is not limited to Java Card but can be any software application operable on contactless cards or other devices with limited memory. One or more counters 410 may include numeric counters sufficient to store integers. The customer identifier 414 may include a unique alphanumeric identifier assigned to the user of the contactless card 102, and the identifier may distinguish the contactless card user from other contactless card users. In some examples, the customer identifier 414 may identify both the customer and the account assigned to that customer, and may also identify the contactless card 102 associated with the customer account. As previously mentioned, the account 412 may include thousands of one-time use virtual accounts associated with the contactless card 102. The contactless card 102 app 408 may be configured to manage the account 412 (e.g., to select the account 412, mark the selected account 412 as used, and transmit the account 412 to a mobile device for autofilling by an autofill service).

[0104] The processor 402 and memory elements of the foregoing exemplary embodiments are described with reference to contact pad 304, but this disclosure is not limited thereto. It will be appreciated that these elements may be implemented outside of or completely separated from contact pad 304, or implemented as additional elements besides the processor 402 and memory 404 elements located within contact pad 304.

[0105] In some examples, 102 may include one or more antennas 418. One or more antennas 418 may be placed within the contactless card 102 and around the processing circuitry 416 of the contact pad 304. For example, one or more antennas 418 may be integrated with the processing circuitry 416, and one or more antennas 418 may be used in conjunction with an external boost coil. As another example, one or more antennas 418 may be externally positioned on the contact pad 304 and the processing circuitry 416.

[0106] In this embodiment, the coil of the contactless card 102 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 102 by cutting off power or by amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained by one or more capacitors. The contactless card 102 can communicate in reverse by switching the load or load modulation on the contactless card coil. Load modulation can be detected in the terminal's coil by interference. More generally, using antenna 418, processor 402, and / or memory 404, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth, and / or Wi-Fi.

[0107] As explained above, the contactless card 102 can be built on a software platform operable on smart cards or other devices with limited memory, such as JavaCard, and one or more applications or applets can be securely executed. An applet 408 can be added to the contactless card to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The applet 408 can be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader, e.g., a mobile device or point-of-sale terminal) and generate an NDEF message that includes a password-secure OTP encoded as an NDEF text tag.

[0108] An example of NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 408 can be configured to encode the OTP into NDEF Type 4 known text tags. In some examples, an NDEF message may include one or more records. In addition to OTP records, applets 408 can be configured to add one or more static tag records.

[0109] In some examples, one or more applets 408 can be configured to emulate RFID tags. The RFID tag may include one or more polymorphic tags. In some examples, different cipher data is presented each time the tag is read, and this data can indicate the reliability of the contactless card. Based on one or more applets 408, NFC readings of the tag can be processed, the data can be transmitted to a server, such as a bank's server, and the data can be verified at the server.

[0110] In some examples, the contactless card 102 and the server may include data that allows the card to be correctly identified. The contactless card 102 may include one or more unique identifiers (not shown). A counter 410 may be configured to increment each time a read operation occurs. In some examples, each time data is read from the contactless card 102 (e.g., by a mobile device), the counter 410 is sent to the server for verification, and it is determined whether the counter 410 equals (as part of the verification) the server's counter.

[0111] One or more counters 410 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 410 has been read, used, or otherwise ignored. If counter 410 has not yet been used, it can be replayed. In some examples, the counter incremented on the card is different from the counter incremented for a transaction. Contactless card 102 cannot determine the application of transaction counter 410 because there is no communication between the applets 408 on contactless card 102.

[0112] In some examples, counter 410 may lose synchronization. In some examples, counter 410 may increment to handle unexpected reads that initiate a transaction, such as reads at an angle, but the application will not process counter 410. In some examples, NFC may be enabled when mobile device 10 is woken up, and device 110 may be configured to read available tags, but will not take action in response to the read.

[0113] To keep counter 410 synchronized, an application, such as a background application, can be executed. This application would be configured to detect when mobile device 110 wakes up and synchronize with the bank's system server to indicate reads that have occurred due to the detection, then move counter 104 forward. In other examples, a hashed one-time password could be used to allow for out-of-sync windows. For example, if within a threshold of 10, counter 410 could be configured to move forward. However, if within a different threshold number, such as 10 or 1000, requests for resynchronization could be processed, which would involve one or more applications requesting the user to tap, gesture, or otherwise indicate once or multiple times via the user's device. If counter 410 increments in the appropriate order, it becomes possible to know that the user has done so.

[0114] The key diversification technique described herein with reference to counter 410, master key, and diversification key is an example of encryption and / or decryption using key diversification techniques. This example key diversification technique should not be considered a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0115] During the creation process of the contactless card 102, two unique cryptographic keys can be assigned to each card. These cryptographic keys may include a symmetric key, which can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware within the contactless card 102. Through a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity requiring a key.

[0116] In some examples, to overcome the vulnerability of the 3DES algorithm, session keys (such as a unique key for each session) can be derived instead of using the master key. The unique card-derived key and counter can be used for diversification. For example, each time the contactless card 101 is used in operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. This results in three layers of cryptography. Session keys can be generated by one or more applets and derived using an application transaction counter with one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Public Session Key Derivation).

[0117] Furthermore, the increment for each card can be unique and assigned either through personalized allocation or algorithmically through some identifying information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5. In some examples, the increment can also vary in terms of sequential reading, allowing a card to increment in a repeating order of 1, 3, 5, 2, 2, ... The specific order or algorithmic order can be defined during personalization or in one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0118] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format.

[0119] Figure 5 This is a sequence diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. Sequence stream 500 may include a contactless card 102 and a client device 104, which may include an application 502 and a processor 504.

[0120] At point 508, application 502 communicates with contactless card 102 (e.g., after being brought near contactless card 102). Communication between application 502 and contactless card 102 may involve contactless card 102 being sufficiently close to a card reader (not shown) of client device 104 to enable NFC data transfer between application 502 and contactless card 102.

[0121] At line 506, after communication has been established between client device 104 and contactless card 102, contactless card 102 generates a Message Authentication Code (MAC) password. In some examples, this can occur when contactless card 102 is read by application 502. Specifically, this can occur during the reading of a near field data exchange (NDEF) tag (such as NFC reading), which can be created according to an NFC data exchange format. For example, a reader application (such as application 502) can transmit a message with an app ID that generates the app via NDEF, such as an app selection message. Upon confirmation of the selection, a sequence of select file messages followed by read file messages can be transmitted. For example, the sequence could include "select function file", "read function file", and "select NDEF file". At this time, a counter value held by contactless card 102 can be updated or incremented, which can be followed by "read NDEF file". At this time, a message can be generated, which may include a header and a shared secret. A session key can then be generated. A MAC cipher can be created from a message, which may include a header and a shared secret. The MAC cipher can then be concatenated with one or more blocks of random data, and the MAC cipher and random number (RND) can be encrypted using a session key. Afterward, the cipher and header can be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

[0122] In some examples, the MAC cipher may be transmitted as an NDEF tag, and in other examples, the MAC cipher may be included with a Uniform Resource Indicator (e.g., as a format string). In some examples, application 502 may be configured to transmit a request to contactless card 102 that includes instructions for generating the MAC cipher.

[0123] At line 510, contactless card 102 sends the MAC password to application 502. In some examples, the transmission of the MAC password occurs via NFC; however, this disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 512, application 502 transmits the MAC password to processor 504.

[0124] At line 514, processor 504 verifies the MAC cipher according to instructions from application 122. For example, the MAC cipher can be verified as explained below. In some examples, MAC cipher verification can be performed by a device other than client device 104 (such as a server of a banking system communicating with client device 104). For example, processor 504 can output the MAC cipher for transmission to a server of the banking system, which can verify the MAC cipher. In some examples, the MAC cipher can act as a digital signature for verification purposes. Other digital signature algorithms, such as public-key asymmetric algorithms (e.g., digital signature algorithms and RSA algorithms) or zero-knowledge protocols, can be used to perform this verification.

[0125] Figure 6 A short record layout (SR=1) data structure 600 for NDEF according to an example embodiment is shown. One or more applets can be configured to encode OTP into text tags of a known type 4 for NDEF. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: known type, text, encoding English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalized parameter that can be used to generate the NDEF message. In an embodiment, the authentication template may include a first record having a known index for providing actual dynamic authentication data.

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

[0127] Regarding master key management, two issuer master keys 702 and 726 may be needed for each part of a product family that distributes one or more applets. For example, the first master key 702 may include an issuer password generation / authentication key (Iss-Key-Auth), and the second master key 726 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 702 and 726 are diversified into card master keys 708 and 720, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 522 and Derived Key Index (pDKI) 724, which are background data, can be used to identify which issuer master keys 702 and 726 will be used in the password process for authentication. The system performing authentication can be configured to retrieve the values ​​of pNPR 722 and pDKI 724 for contactless cards during authentication.

[0128] In some examples, to improve the security of the solution, session keys (such as a unique key for each session) can be derived. However, instead of using a master key, it is better to use a unique card-derived key and counter as diversification data, as explained above. For example, each time the card is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. Regarding session key generation, the key used to generate passwords and encrypt data in one or more applets can include session keys based on the card's unique key (Card-Key-Auth 708 and Card-Key-Dek 720). Session keys (Aut-Session-Key 732 and DEK-Session-Key 710) can be generated by one or more applets and derived using an Application Transaction Counter (pATC) 704 and one or more algorithms. To fit the data into one or more algorithms, only the two lower-order bytes of the 4-byte pATC 704 are used. In some examples, the four-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 include 3DES ECB and MK may include the card-uniquely derived master key.

[0129] As described in this document, one or more MAC session keys can be derived using the lower two bytes of the pATC 704 counter. The pATC 704 is configured to be updated with each tap of the contactless card, and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 720 are further diversified into session keys Aut-Session-Key 732 and DEK-Session-KEY 710. The pATC 704 can be initialized to zero during personalization or applet initialization. In some examples, the pATC counter 704 can be initialized during or before personalization and can be configured to increment by 1 with each NDEF read.

[0130] Furthermore, updates for each card can be unique and assigned either through personalization or algorithmically through pUID or other identifying information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, updates can also vary in the order of reading, allowing a card to increment in a repeating sequence of 1, 3, 5, 2, 2, ... The specific order or algorithmic order can be defined during personalization or in one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0132] MAC can be performed using the function key (AUT-Session-Key) 732. The data specified in the cipher can be processed using the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 to be associated with the EMV ARQC authentication method. The key used for this calculation can include the session key AUT-Session-Key 732, as explained above. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As explained below, AUT-Session-Key 732 can be used for MAC data 706, and the resulting data or cipher A 714 and random number RND can be encrypted using DEK-Session-Key 710 to create cipher B or output 718 sent in the message.

[0133] In some examples, one or more HSM commands can be processed for decryption, such that the final 16 bytes (binary, 32-byte hexadecimal) can include 3DES symmetric encryption using CBC mode, where the zero IV of the random number is followed by MAC authentication data. The key used for this encryption can include a session key DEK-Session-Key 710 derived from Card-Key-DEK 720. In this case, the ATC value used for deriving the session key is the least significant byte of the counter pATC 704.

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

[0135]

[0136]

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

[0138]

[0139]

[0140] The UID field of the received message can be extracted to derive the card master key (Card-Key-Auth 708 and Card-Key-DEK 720) for that specific card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 726. Using the card master key (Card-Key-Auth 508 and Card-Key-DEK 720), the counter (pATC) field of the received message can be used to derive the session key (Aut-Session-Key 732 and DEK-Session-Key 710) for that specific card. Password B718 can be decrypted using DEK-Session-KEY, which produces password A 714 and RND, and RND can be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the message version, UID, and pATC fields, can be processed using the recreated Aut-Session-Key via the password MAC to create a MAC output, such as 'MAC'. If the MAC address matches the cipher A 714, this indicates that message decryption and the MAC check have both passed. The pATC can then be read to determine its validity.

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

[0142] In some examples, one benefit of encrypting an unshared random number as the first block along with the MAC cipher is that it acts as an initialization vector when using the CBC (Block Chaining) mode of a symmetric encryption algorithm. This allows for block-to-block "scrambling" without having to pre-establish fixed or dynamic IVs.

[0143] By including the Application Transaction Counter (pATC) as part of the data included in the MAC cipher, the authentication service can be configured to determine whether the value conveyed in the plaintext data has been tampered with. Furthermore, by including the version in one or more ciphers, it is difficult for an attacker to intentionally distort the application version to attempt to weaken the strength of the cipher solution. In some examples, the pATC can start from zero and be updated to 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated message can be rejected. In some examples, when the pATC is greater than a previously received value, this can be estimated to determine if it is within an acceptable range or threshold, and if it exceeds the range or threshold or is outside of it, the verification can be considered a failure or unreliable. In MAC operation 712, data 706 is processed via MAC using the Aut-Session-Key 732 to produce an encrypted MAC output (cipher A) 714.

[0144] To provide additional protection against brute-force attacks on the exposed key, it is expected that the MAC cipher 714 is encrypted. In some examples, the data or cipher A 714 to be included in the ciphertext may include: a random number (8) and a cipher (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that can be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include DEK-Session-Key 710. In encryption operation 716, the data or cipher A 714 and RND are processed using DEK-Session-Key 710 to produce encrypted data, i.e., cipher B 718. The data 714 may be encrypted using 3DES in ciphertext block chaining mode to ensure that an attacker must run any attack within all the ciphertext. As a non-limiting example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' can be used. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key has been used, because due to its random appearance, correctly decrypted data will be indistinguishable from incorrectly decrypted data.

[0145] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile device during the authentication session: version number, used to determine the cipher method used and the message format used to verify the password, which allows the method to be changed in the future; pUID, used to retrieve the cipher asset and derive the card key; and pATC, used to derive the session key used for the cipher.

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

[0147] At block 804, the issuer master key can be diversified by combining it with the card’s unique ID number (pUID) and the PAN serial number (PSN) of one or more applets (e.g., payment applets).

[0148] At block 806, Card-Key-Auth and Card-Key-DEK (unique card key) can be created by diversifying the issuer's master key to generate a session key, which can be used to generate a MAC cipher.

[0149] At block 808, the key used to generate the password and encrypt data in one or more applets may include the session keys from block 806, which are based on the card-unique keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and derived using pATC to produce session keys Aut-Session-Key and DEK-Session-Key.

[0150] Figure 9 An exemplary process 900, illustrating key diversification according to one example, is depicted. Initially, the sender and receiver may be equipped with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value that can be updated at block 902, as well as other data that can be securely shared with the receiver, such as data to be protected.

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

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

[0153] At block 906, the data to be protected is processed using a cryptographic MAC operation by the sender using a data integrity session key and a cryptographic MAC algorithm. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0154] At block 908, the data to be protected can be encrypted by the sender using a session key derived from the data encryption, combined with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data, for example, in 8-byte lengths, and then encrypted using a second session key (DEK-Session-Key).

[0155] At block 910, the encrypted MAC, along with sufficient information identifying additional secret information (such as the shared secret, master key, etc.), is transmitted from the sender to the receiver for password verification.

[0156] At block 912, the receiver uses the received counter value to independently derive two derived session keys from the two master keys as explained above.

[0157] At block 914, the session key derived from the data encryption is combined with a symmetric decryption operation to decrypt the protected data. Further processing of the exchanged data then occurs. In some examples, after the MAC is extracted, it is expected that the MAC will be regenerated and matched. For example, when verifying a password, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. The MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Because the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0158] At block 916, the data integrity-derived session key is used in conjunction with the cipher MAC operation to verify that the protected data has not been modified.

[0159] Some examples of the methods described herein can advantageously confirm when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is correct. A MAC can only be considered correct if decryption is successful and a correct MAC value is generated. Successful decryption indicates 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 transmitting device) and the receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed authentic. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

[0160] After this, the two derived session keys can be discarded, and the next iteration of the data exchange will update the counter value (returning to block 902), and (at block 910) a new set of session keys can be created. In some examples, the combined random data can be discarded.

[0161] Figure 10A method 1000 for card activation according to an example embodiment is illustrated. For example, card activation can be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components explained above, such as contactless card 102, client device 1804, and server.

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

[0163] In block 1004, one or more portions of dynamically generated data can be transmitted to the device's application via NFC or other wireless communications. For example, tapping a card close to the device can allow the device's application to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application for auxiliary card activation, tapping the card can guide the device or prompt the customer to go to an app store to download the associated application to activate the card. In some examples, the user can be prompted to gesture, place, or orient the card adequately toward the device's surface, such as placing it at an angle or flat on, near, or close to the surface of the device. In response to the card's adequate gesture, placement, and / or orientation, the device can continue transmitting one or more encrypted portions of the data received from the card to one or more servers.

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

[0165] In block 1008, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and decrypt it to compare the received data with record data accessible to one or more servers. If the comparison of one or more decrypted portions of the data by one or more servers yields a successful match, the card may be activated. If the comparison of one or more decrypted portions of the data by one or more servers yields an unsuccessful match, one or more procedures may occur. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold including the number of attempts the user is allowed to activate the card. Alternatively, the user may receive a notification, such as a message on his or her device indicating an unsuccessful attempt at card verification, and a call, email, or text message sent to the associated service to assist in card activation; or another notification, such as a phone call on his or her device indicating an unsuccessful attempt at card verification, and a call, email, or text message sent to the associated service to assist in card activation; or another notification, such as an email indicating an unsuccessful attempt at card verification, and a call, email, or text message sent to the associated service to assist in card activation.

[0166] In block 1010, one or more servers may send a return message based on successful card activation. For example, the device may be configured to receive output from one or more servers indicating successful card activation by one or more servers. The device may be configured to display a message indicating successful card activation. Once the card has been activated, it may be configured to stop dynamically generating data to prevent fraudulent use. In this way, the card may not be activated thereafter, and one or more servers will be notified that the card has been activated.

[0167] Figure 11 An example of system 1100 according to an embodiment discussed herein is shown. System 1100 includes additional devices and systems configured to enable contactless issuers to provide card services via tap-to-pay. Specifically, system 1100 enables any number of issuer systems to provide card services to their clients in a secure and reliable manner through an exchange structure (i.e., an exchange system).

[0168] In this embodiment, the exchange system includes one or more nodes 1104 configured to perform routing operations. Each exchange node 1104 may include a session and nonce generator 1106, a message router 1108, an authentication 1110, operational data storage 1112, and a metric storage 1114. Furthermore, each of the nodes may be configured identically and share a configuration, but each exchange node 1104 may independently process messages and requests and route them to appropriate systems, such as merchant systems and publisher systems. For example, each of the nodes 1104 is configured to act as a trust intermediary between the publisher system, the merchant system 1122, and / or the authentication system 1124. Each exchange node 1104 is configured to route each message to the correct publisher system while maintaining data security. For example, an exchange node 1104 may route messages between the publisher system and the merchant system without access to private data within the messages.

[0169] The switching system 1100 can be configured as a server system having a collection of hardware, software, and network components that work together to provide client services. The hardware components may include one or more server computers, storage devices, and network adapters. The server computers are configured to run server applications, such as those that can be executed on each of the nodes 1104. In some cases, each of the server computers may be configured to operate one or more nodes, for example, in a virtual environment. The storage devices are configured to store data accessed by applications, and the network adapters are used to connect the server computers to a network.

[0170] Each server computer can be configured to run software, including an operating system, applications, and security software. The network components of a server system include network switches, routers, and firewalls. Network switches are used to connect server computers to other devices on the network. Routers are used to route traffic between different networks. Firewalls are used to protect the server system from unauthorized access and attacks.

[0171] In some embodiments, node 1104 may operate in a cloud-based computing environment, such as a collection of hardware, software, and network components capable of delivering cloud computing services. Switching node 1104 and computing services are delivered via the Internet and can be accessed from anywhere in the world via an Internet connection. In embodiments, client 1136 may access switching node 1104 via DNS 1102 or the Domain Name System (DNS). DNS 1102 is a hierarchical and distributed naming system for computers, services, and other resources connected to the Internet or other networks. It associates various pieces of information with domain names assigned to each registered participant. In one example, DNS 1102 may translate known names of software executing on client 1136 to route data to one or more of the switching nodes 1104 in the switching system. In embodiments, DNS 1102 may generate numbers such as Internet Protocol (IP) addresses, address records (A-records), or other hostnames (C-name records). Figure 12 An example sequence 1200 is shown, illustrating an identifier for one of the nodes 1104 used by a client to identify and resolve the exchange system. At a higher level, DNS 1102 translates known domain names into digital Internet Protocol (IP) addresses required for locating and identifying computer services and devices with underlying network protocols. Clients use the global DNS system to select the best node to use, as discussed in sequence 1200.

[0172] In this embodiment, client 1136 communicates with the switching system to perform one or more of partner services 1132, such as transacting with merchants, verifying customers, or other tap-to-open functions. Once client 1136 identifies switching node 1104 and resolves the address for communicating with switching node 1104, client 1136 can send one or more messages to switching node 1104 for authentication and to perform operations. Switching node 1104 includes authentication 1110 functionality configured to authenticate client 1136. In this embodiment, client 1136 sends a message or authorization request to switching node 1104 with the following header set:

[0173]

[0174] The CLIENT API KEY can have the following example structure: 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum, where Table 1 describes the values, names, and meanings:

[0175]

[0176] Table 1

[0177] Exchange node 1104 can authorize or authenticate clients 1136 or users, and exchange node 1104 can perform these operations using additional components such as session and nonce session and node generator 1106 and message router 1108. Note that authentication system 1124 never interacts with merchant system 1122, and vice versa. Node 1104 coordinates all communication.

[0178] In this embodiment, the switching system can utilize the Hyperledger Structure 1120 to manage cross-network synchronized shared operational data 1112 and membership management. The Hyperledger Structure 1120 is a distributed ledger framework with a permissioned network model, where only authorized participants can join the network and access the data stored on the ledger.

[0179] In this embodiment, the hyperledger structure 1120 can be generated by creating one or more sets of peers, subscribing services, and channels. Once the network is created, system 1100 deploys chaincode to the network, or node 1104 is granted access to the structure. Chaincode is code that runs on the blockchain and executes network control 1126 and operational data 1112 logic codes. Once the chaincode is deployed, each of the exchange nodes 1104 is configured to invoke transactions on the blockchain to add data to the blockchain, such as operational data. Exchange node 1104 or another device can query the ledger to retrieve data. The ledger is a distributed database that stores all data added to the blockchain.

[0180] All nodes 1104 maintain independent, verifiable logs of their actions, which can be transmitted to a centralized aggregator to construct a picture of overall network usage. System 1100 can manage network operation data and administration at a central level, with a centralized view of network usage aggregated and abstracted to the appropriate level.

[0181] Figure 12 An example sequence 1200 is shown, illustrating a client using DNS to resolve and communicate with one or more nodes in a switching system. Sequence 1200 includes a client 1136, DNS 1102, and a switching node 1104. At 1202, sequence 1202 includes the client 1136 sending a request to the default DNS server for the text record switchboard.{domain}.{tld}. The text record may be pre-configured in the client applet and / or client SDK. At 1204, DNS 1102 returns one or more records. The DNS record structure may include the following:

[0182]

[0183] In this embodiment, client 1136 can determine the current time zone at 1206. For example, a client applet or SDK could utilize a function to get the current time zone, such as in JavaScript: `Intl.DateTimeFormat().resolvedOptions().timeZone`. The embodiment is not limited to this approach, and the applet or SDK could determine the time zone via another / different function call. At 1208, client 1136 is configured to map the time zone to a region or a short version identifier of that region. One example includes Americas / New York -> NA-E. For example, the region might be based on a DNS name. Table 2 shows several examples of time zone mapping to regions:

[0184]

[0185] Table 2

[0186] The embodiments are not limited to these examples, and other time zone-to-region mappings can be utilized. Furthermore, and in the embodiments, regions can also be represented as a bidirectional graph structure, where edges represent geographical neighbors. For example, na-e<->na-w and sa<->na-w and sa<->na-e. This representation is useful for node selection.

[0187] At 1210, client 1136 can identify or select the DNS record option returned at 1204 for that zone. If multiple matches exist, client 1136 can randomly select one. At 1212, if no node is available in the zone, client 1136 can determine and use a data graph of neighboring zones to select the node in the nearest zone where the node is available. For example, sa has no node but is connected to na-e, which has a node, and therefore na-e is selected. In some embodiments,

[0188] At 1214, the client can resolve the hostname of the selected node. In this embodiment, client 1136 can automatically resolve the hostname using the client's default HTTP request resolver. At 1216, DNS 1102 can return the result. And at 1218, client 1136 can communicate with exchange node 1104 and begin the process of interacting with the exchange node.

[0189] Figures 13A to 13CAn example sequence 1300 is illustrated for performing operations between a contactless card and services provided by the card issuer and / or merchant. The illustrated sequence 1300 includes actions and communications performed by a contactless card 102, a client 1136 including a client application 1390 and a client SDK 1392, a DNS 1386, an exchange system including one or more nodes 1104, a partner service 1132 including a merchant and / or authenticator 1388, and a control service 1134 including a client server 1384 or a system. In embodiments, the client application 1390 can be any application configured to run on the client 1136, such as a banking app, a merchant app, a social media app, a travel app, a game app, a productivity app, an entertainment app, and the like. In embodiments, the client application 1390 includes a web browser that provides websites and pages. The client application 1390 can include and / or utilize the client SDK 1392, which can be a set of instructions that enables the client application 1390 to communicate with other components of the exchange system.

[0190] In an embodiment, such as Figure 13A As shown, at 1302, client 1136, including a client applet, can send a request and establish a session with client server 1384, allowing the result to be associated with the correct client device or user. This request establishes a relationship between the client device and the client server (which may be a publisher server). At 1304, client server 1384 generates a session and a CLIENT SESSION INFORMATION. At 1306, client server 1384 returns session information, such as the CLIENT SESSION INFORMATION. In this embodiment, the CLIENT SESSION INFORMATION may be client-specific user session identification information.

[0191] At 1308, client 1136 can initiate a contactless card authentication process with client 1136. For example, client 1136 can call a function and / or pass information to client 1136 to initiate authentication via contactless card 102. At 1310 to 1314, client 1136 can use DNS to identify a node and establish communication with that node. Specifically, at 1310, client 1136, including client SDK 1392, can send a request for the hostname of the exchange node, and at 1312, DNS 1386 can return information including one or more hostnames. At 1314, client 1136 can determine the exchange node to communicate with. Figure 12 An example of a more detailed sequence of the process of establishing communication with exchange node 1104 is shown.

[0192] At point 1316, client 1136 can send a request for a session to switching system 1100. In an embodiment, the request for a session may be directed to a format...<FUNCTION REQUEST> The function request. In this embodiment, FUNCTIONREQUEST can be the data / function that client 1136 wants to request once contactless card 102 has been authenticated. This function can be used for any service discussed herein, such as authenticating a user, executing a transaction, requesting auto-population of data, etc. At 1318, exchange system 1100 can generate a nonce and a signed session token. The signed session token can be a JSON Web Token (JWT). When generating a JWT, the following elements should be set:

[0193]

[0194] The nonce can be a unique random byte generated to ensure the non-repeatability of messages associated with the contactless card 102. The nonce is crucial for the security and operation of the exchange system. Nonce validity is tracked by binding it to a session that can be verified by any member of the platform. As mentioned, a session is a JSON Web Token (JWT) signed using a node-specific private key issued by the network. These JWTs can be verified by systems with corresponding public keys, and they can also be verified by confirming that it was issued by us or an authorized representative. The signed session token is a token generated from the JWT to establish the validity and expiration of the nonce and associate the contactless card tap with the current client session. For example, a signed session token includes...<NODE PRIVATE KEY> Signature <nonce>,<CLIENT SESSION INFO> and <functionrequest>The NODE PRIVATE KEY is the private key of the exchange system 1100. The exchange system 1100 may include a NODEPUBLIC / PRIVATE KEY, which is a key pair used for signing and verifying JWTs.

[0195] At 1320, the switching system 1100 can return session information to the client 1136. The session information may include a signed session token (<SIGNED SESSION TOKEN> NONCE <nonce>Functional Service Terms <functiontos>and the terms of service<TOS VERSION> FUNCTION TOS can be the terms of service that the user must agree to in order to allow the client to perform the requested function, and TOS VERSION can be the version of the terms of service. At 1322, the client SDK 1392 can determine and / or receive the user's consent to the terms of service. In one example, the client SDK 1392 captures and records the user's...<CONSENT DATE> above<TOS VERSION> right<FUNCTION TOS> The user's consent. CONSENTDATE can be the timestamp of the user's consent to TOS.

[0196] At 1324, client 1136 exchanges one or more messages with the contactless card. In one example, the exchange may be based on the contactless card being lightly tapped against the client device. In an embodiment, client SDK 1392 may provide data to contactless card 102 for use during a session to perform this function. The data may be provided to contactless card 102 in an NDEF message. In one example, the data is written to the card in NDEF format using a binary update command. The data may include NONCE to provide a security level that the message received from the card is part of the same session. Additionally, the data may include additional information, such as one or more control bits, to control the format generated by the contactless card. Table 3 below shows examples of NDEF message formats.

[0197]

[0198] Table 3

[0199] In this embodiment, an updated MAC can be calculated to protect the control indicator. Specifically, MAC M is determined by calculating the MAC on 10 bytes of updated data U using the updated MAC card key (MCK), as shown below. Figure 14 As described, message 1400.

[0200] At point 1324, the contactless card can generate and provide messages to devices that include client SDK 1392. The data in the messages can be used by the systems discussed herein to perform the requested functions. Figure 14 An example message, message 1400, is shown and discussed in the text.

[0201] At 1326, a client including client SDK 1392 can send messages and information to exchange system 1100. This message can be received from contactless card 102, such as message 1400. Additionally, client SDK 1392 can send the agreement date, TOS version, and signed session token to exchange system 1100. Exchange system 1100 can use this information to ensure the session is valid. At 1328, exchange system 1100 verifies that the signed session token is valid, for example, it is a previously provided signed session token and includes a previously generated nonce within the message.

[0202] In some embodiments, the switching system 1100 is configured to determine which issuer system or client server it should route a message to for processing. At 1330, the switching system 1100 can determine the issuer ID by extracting the issuer ID from messages received from the contactless card 102 via the client SDK 1392. As mentioned, the issuer ID identifies the issuer of the contactless card 102.

[0203] Figure 13B from Figure 13A Continuing with sequence 1300. In this embodiment, the exchange system 1100 is configured to generate secure communication and communicate with a issuing system, such as client server 1384 and verifier 1388, regarding this secure communication. At 1332, the exchange system 1100 sends a request for a key to client server 1384. The key can be used to perform the secure communication. In one example, the key request could be an elliptic curve Diffie-Hellman (ECDH) key request. The embodiment is not limited to this approach. Alternative key protocols can be used, such as supersingular homologous Diffie-Hellman key exchange (SIDH or SIKE), private / public key pairing (RSA), etc.

[0204] At position 1334, client server 1384 generates a portion of the key. In some instances, client server 1384 can generate half of the ECDH key for PII encryption / decryption. Specifically, client server 1384 can generate it using elliptic curve P256.<CLIENT EC PUBLIC KEY> and<CLIENT EC PRIVATE KEY> CLIENT ECPUBLIC KEY and CLIENT EC PRIVATE KEY constitute the first part of ECDH key negotiation.

[0205] At position 1336, the client server 1384 stores a portion of the generated key in a storage device. Specifically, the client server 1384 may store...<KEY ID> of<CLIENT EC PUBLIC KEY> and<CLIENT ECPRIVATE KEY> The KEY ID is used by the client server to cache its short-lived EC public / private key for later ECDH key completion, such as identifying ECDH key portions to generate the complete ECDH key. In one example, the key can be stored in a secure memory location and can be used when a PII is received for a session.

[0206] In one embodiment, client server 1384 can return the public key portion along with the KEY ID to exchange system 1100 at 1338. Exchange system 1100 can store the public key portion along with the KEY ID for later use, such as generating an ECDH key. At 1340, exchange system 1100 can request validation to be performed by validator 1388. In one example, exchange system 1100 can request validation as Request validation. <message>,<SIGNED SESSIONTOKEN> ,<CLIENT EC PUBLIC KEY> ,<CONSENT DATE> and<TOS VERSION> To send. At 1342, verifier 1388 can make an out-of-band request to exchange system 1100 based on the public key returned to verify the session. At 1344, exchange system 1100 can provide the node's public key, i.e.<NODE PUBLIC KEY> Furthermore, at point 1346, verifier 1388 can use the node's public key to verify the secure session token.

[0207] In one embodiment, verifier 1388 may verify the message at 1348. In another embodiment, verifier 1388 may perform a number of verifications, including ensuring that the nonce in the message, along with additional information such as the card's unique identifier (pUID) and counter value (pATC), is correct.

[0208] At position 1350, validator 1388 can store information associated with the session. For example, validator 1388 can...<CONSENT DATE> and<TOS VERSION> and <puid>They are stored together. The validator 1388 can also generate another part of the key, such as an ECDH key. For example, 1388 can generate it using elliptic curve P256.<ISSUER EC PUBLIC KEY> and<ISSUER EC PRIVATE KEY> The ISSUER EC PUBLIC KEY and ISSUER EC PRIVATE KEY can be the latter part of the ECDH key negotiation.

[0209] At position 1354, verifier 1388 can generate the complete ECDH key. For example, verifier 1388 obtains from...<ISSUER ECPRIVATE KEY> and<CLIENT EC PUBLIC KEY> generate<ECDH KEY> The ECDH KEY is the final key generated using ECDH key negotiation.

[0210] Validator 1388 can utilize the ECDH key to encrypt data used for functions. For example, if in some instances, validator 1388 validates a message, it can execute a function request at 1356 to create a function result and encrypt the result with the ECDH key. For example, validator 1388 can execute...<FUNCTION REQUEST> To create<FUNCTION RESULT> and use<ECDH KEY> Encrypt it. The result can be any result based on the requested function (such as card verification).

[0211] At point 1358, verifier 1388 can return the functional result to exchange system 1100. In some instances, the functional result is returned encrypted. For example, verifier 1388 can return...<ENCRYPTED FUNCTION RESULT> and<ISSUER ECPUBLIC KEY> .

[0212] Figure 13C from Figure 13B Continuing with sequence 1300. In an embodiment, at 1360, the switching system 1100 sends the functional result to the client server 1384 for processing. In one example, the switching system 1100 may send...<ENCRYPTEDFUNCTION RESULT> ,<KEY ID> ,<ISSUER EC PUBLIC KEY> and<SIGNED SESSION TOKEN> At points 1362 and 1364, client server 1384 can request and receive public keys from exchange system 1100. In some instances, the exchange can be performed via out-of-band communication channels. The node's public key can be...<NODE PUBLIC KEY> The public key can be used to verify the sender of the functional result, etc. At position 1366, the client server at position 1384 can use the node's public key.<NODE PUBLIC KEY> This is used to verify the signed session key, thereby verifying the sender of the message. At 1368, client server 1384 can extract client information from the signed session token. For example, client server 1384 can extract client information from...<SIGNED SESSION TOKEN> Extract<CLIENT SESSION INFO> This means extracting specific user session identification information from the client.

[0213] Furthermore, at address 1370, client server 1384 can retrieve the client's private key using the KEY ID. Specifically, client server 1384 can use...<KEY ID> Retrieve from cache and remove<CLIENT PRIVATE KEY> At position 1372, client server 1384 can generate or compute ECDH keys. For example, client server 1384 can use...<CLIENT PRIVATE KEY> +<ISSUER EC PUBLIC KEY> To calculate<ECDH KEY> At position 1374, client server 1384 can use the calculated key to decrypt the function result. Specifically, client server 1384 can use...<ECDH KEY> Decrypt<ENCRYPTED FUNCTION RESULT> To determine<FUNCTION RESULT> At position 1376, the client server at position 1384 associates the function result with the session.

[0214] In an embodiment, the switching system 1108 can return a function completion result to the client SDK 1392 at 1378, indicating whether the function was successfully completed. Furthermore, at 1380, the client SDK 1392 can notify the client application 1390 of the result. At 1382, the client application 1390 can utilize this feature. For example, 1382 can communicate with the client server 1384 to use...<CLIENTSESSION INFO> To obtain the edited<FUNCTION RESULT> This allows the characteristic to continue.

[0215] Figure 14 An example of message 1400 is shown, which can be communicated by a contactless card to perform the functions described herein, such as in Figures 13A to 13C The fields discussed herein. One or more fields in message 1400 can also be used to route message 1400 through the switching system and perform authentication / verification techniques.

[0216] In this embodiment, message 1400 includes an app version 1402 field, a publisher self-indicator 1404 field, a publisher identifier 1406 field, a pKey ID 1408 field, a pUID 1410 field, a pATC 1412 field, a nonce 1414 field, and an encrypted password 1416.

[0217] In this embodiment, the field can be plain text or encrypted. For example, the applet version 1402 field may include plain text indicating the applet version. The applet version indicates which applet version is installed on the contactless card and can be used by other systems to determine how to handle message 1400 during communication. For example, different applet versions may require different authentication logic; older messages may be routed through the publisher system to perform various authentication operations, while newer messages may be routed through the exchange system to perform various operations, including authentication.

[0218] In this embodiment, message 1400 includes a publisher autonomy indicator field 1404, which may include publisher data and be set during personalization. Additionally, message 1400 includes a publisher identifier field 1406, which may include a unique ID assigned to an issuing entity (e.g., a publisher). For example, each publisher may be assigned a unique identifier during onboarding operations upon joining the system. The publisher ID can be used by the exchange system 1108 to route messages and their content to the appropriate service associated with that particular publisher.

[0219] In this embodiment, message 1400 includes a pKey ID 1408 field. In some instances, the pKey ID 1408 field may include data identifying a master key set for the card issuer. The issuer's master key set may utilize a derived master key set or a unique derived key (UDK) for each card. Furthermore, during card personalization, each card may generate its own master key set (UDK). The card's UDK can be used to generate a session key, which is used to generate an application cipher. The session key generated by the card can be regenerated by a system (e.g., an authenticator system) using the pKey ID to identify the issuer's master key, so that the system can regenerate the session key to perform authentication.

[0220] In this embodiment, each contactless card 102 is given a unique 16-bit decimal digital identity (pUID) during personalization. The unique key for deriving the card applet using the pUID is performed off-card. The resulting application key is injected during card personalization. In this embodiment, the card's application key is the same as the card's derived master key or UDK. The process for deriving the application key (UDK) is further described relative to other diagrams in this disclosure.

[0221] Message 1400 may include a pUID 1410 field, which includes a unique card identifier assigned to the contactless card during personalization. The pUID 1410 field data may be a combination of alphanumeric characters used to uniquely identify each card and associate it with the user.

[0222] In one embodiment, message 1400 includes a pATC 1412 field configured to hold a counter value. In one example, the counter value is stored in hexadecimal format as a read (tap) count performed on the contactless card. Furthermore, the counter value can be used to generate a session key to encrypt at least a portion of the message.

[0223] In this embodiment, each time message 1400 is created, a new session key is derived and used to generate one or more parts of message 1400. Specifically, the session key is used to calculate the MAC (Applied Cipher). The card's applet supports session key derivation options to generate a unique cipher session key ASK and a unique encrypted session key (DESK).

[0224] In this embodiment, some of the data provided in message 1400 is static and is set on the card during card personalization, while other data is dynamic and can be generated by the card during operation, such as when a read operation is being performed. Note that in some instances, the static information may be updatable, but may require the customer and card to undergo a secure update process, which may be controlled by the issuer.

[0225] In an embodiment, the contactless card 102 can communicate messages between devices, such as a mobile device, during a read operation. For example, in response to the contactless card 102 being lightly touched to the surface of a device (e.g., brought into wireless communication range), a read operation can be performed on the contactless card 102, and the contactless card 102 can generate a message and provide it to the device. For example, once within range, the contactless card 102 and the device can perform one or more exchanges to allow the contactless card 102 to send a message to the device.

[0226] Wireless communication can be based on wireless protocols such as Near Field Communication (NFC), Bluetooth, WiFi, and the like. In some instances, messages can be communicated between the contactless card 102 and the device via a wired means (e.g., via a contact pad) and according to the EMV protocol.

[0227] As discussed above, the contactless card 102 may be deployed with a unique card key, such as a UDK, which is generated from the issuer's master key and used to generate the session key. The generation of the UDK and session keys (ASK and DESK) is discussed below. Furthermore, the contactless card can use the generated key to generate encrypted data or passwords including data as discussed herein. The encrypted data can be encrypted using the session key, which changes each time the data is encrypted. In one embodiment, the session key is generated from the card master key or a unique diversification key stored on the contactless card 102. The unique diversification key can be generated from the issuer's master key. For example, in some instances, the operation to generate the unique diversification key can be performed outside the card during personalization and then stored in the card's memory. Additionally, one or more issuer master keys can be used to generate the card master key. The card master key may also be referred to as an application key or UDK. Each contactless card may have one or more UDKs.

[0228] In this embodiment, each contactless card includes one or more applications, such as an authentication application, which is given a unique 16-bit identity (pUID) during personalization. Each contactless card may also receive application keys, which may also be referred to as a unique card key (UDK) using the pUID or a card master key. In some cases, these operations are performed off-card, and the resulting key is injected during personalization. However, in other cases, one or more of the operations may be performed on the card, for example, during manufacturing, each time an operation is performed with the key, etc.

[0229] The embodiments include a system configured to generate multiple issuer master key sets and assign a unique three-byte pKey identifier (pKey ID) to each master key set. As mentioned, the system discussed herein can support many card issuers, and each card issuer can have one or more of its own unique issuer master key sets, identifiable by a pKey ID. For each application (such as an authentication application), the system can perform the following operations to generate an application key or UDK.

[0230] In this embodiment, the system assigns a pKey ID to the card or pUID, which is a unique 16-bit decimal number identity for the card application. The system initiates the generation of the card's UDK. Specifically, the system generates a 16-bit number (X) based on the 16-bit pUID. In one example, the 16-bit X can be generated by randomly rearranging the 16-bit pUID. In another example, X can be the same as the 16-bit pUID. The embodiment is not limited to this approach, and other techniques can be used to generate X based on the 16-bit pUID. In this embodiment, the 16-bit number X can be used to generate one or more UDKs.

[0231] In this example, the system computes or estimates the first part (ZL) by encrypting X with the issuer's master key. Encryption algorithms such as DES or DES variants can be used in the embodiment. The embodiment is not limited to this approach, and other examples of encryption algorithms include AES and public-key algorithms such as RSA.

[0232] The system estimates or calculates the second part ZR by performing an XOR operation on X with FFFFFFFFFFFFFFF and encrypting the result with the issuer's master key. Similarly, encryption algorithms such as DES, AES, RSA, etc., can be used to encrypt the XOR result. The system generates an application key or UDK. Specifically, the system concatenates ZL and ZR to form the application key. The embodiment is not limited to concatenating the two parts (ZL and ZR). They can be combined using other techniques. Furthermore, the above process can be performed any number of times to generate additional application keys, for example, by utilizing different master issuer keys. In the embodiment, the contactless card 102 stores the generated application key or UDK.

[0233] In this embodiment, the contactless card 102 uses an application key or UDK to generate a session key for each piece of encrypted data generated. Below is a process flow that can be performed by the contactless card to generate a unique cryptographic session key (ASK).

[0234] To generate the ASK, the contactless card 102 calculates the SKL by encrypting [ATC[2] || ATC[3] || 'F0' || '00' || [ATC[0] || [ATC[1] | [ATC[2] || [ATC[3]]] using the application key. Furthermore, the contactless card 102 calculates the SKR by encrypting [ATC[2] || ATC[3] || '0F' || '00' || [ATC[0] || [ATC[1] || [ATC[2] || [ATC[3]]] using the application key. Finally, the contactless card 102 concatenates the SKL and SKR to form the Authentication Session Key (ASK). In this embodiment, the ASK is used to perform operations using the contactless card 102, such as encrypting the PIN MAC.

[0235] In this embodiment, the contactless card 102 also supports session key derivation to generate a unique encrypted session key DESK. The contactless card 102 calculates SKL by encrypting [ATC[2] || ATC[3] || 'F0' || '00' | '00' || '00' || '00' || '00' ] using the data encryption key (DEK) or UDK. In addition, the contactless card 102 calculates SKR by encrypting [ATC[2] || ATC[3] || '0F' || '00' || '00' || '00' || '00' || '00' ] using the DEK or UDK. The contactless card 102 concatenates SKL and SKR to form a data encryption session key (DESK).

[0236] In this embodiment, the contactless card 102 uses a session key to generate encrypted data or a password. Specifically, the contactless card 102 generates a password C by calculating a MAC on 32-byte transaction data T using an Authentication Session Key (ASK).

[0237] The contactless card 102 can process data to generate a password. Specifically, the contactless card 102 divides T into four 8-byte data blocks: T = T1 || T2 || T3 || T4. The contactless card 102 calculates B = DES(ASKL)[T1], where ASKL is a data encryption standard or another symmetric encryption algorithm, and ASKL is a part of ASK, such as the "left" half of the key. The contactless card 102 calculates B = [B XOR T2], and also calculates B = DES(ASKL)[B], where DES is the encryption algorithm. The contactless card 102 calculates B = [B XOR T3], and also calculates B = DES(ASKL)[B]. The contactless card 102 calculates B = [B XOR T4], and also calculates B = DES(ASKL)[B]. The contactless card 102 calculates B = DES -1 (ASKR)[B], where DES -1 It is the reciprocal of the DES operation, and ASKR is a part of ASK, such as the right half. The contactless card 102 calculates the password C = DES(ASKL)[B].

[0238] In this embodiment, the contactless card 102 can also encrypt the password to further protect the data. For example, the contactless card 102 can generate an 8-byte random number [RND], and the card calculates E1 = DES3(DESK)[RND], where DES3 is a symmetric encryption algorithm, such as the Triple Data Encryption Standard. The contactless card 102 then calculates B = [E1] XOR [C], where C is the generated password, as discussed above. The contactless card 102 calculates E2 = DES3(DESK)[B], where B is calculated above. Furthermore, the contactless card 102 generates a 16-byte encrypted payload E = [E1] || [E2].

[0239] In this embodiment, the device or contactless card 102 can decrypt the payload E by determining, receiving, or retrieving the payload E. The device calculates RND = DES3. -1 (DESK) [E1]. Device determination B = DES3 -1 (DESK)[E2], and the device calculates C = [E1] XOR [B].

[0240] In this embodiment, a Message Authentication Code (MAC) is generated or calculated contactlessly. In some cases, the MAC may be an updated MAC. In this embodiment, the updated MAC is included in the data communicating from the contactless card 102 to another device (such as a mobile device, a point-of-sale (POS) terminal, or any other type of computer). In one example, the updated MAC may be included in the NDEF message.

[0241] In an embodiment, an updated MAC can be calculated to protect the control indicator and includes the updated date / time. For example, the updated MAC M is determined by calculating the MAC on 10 bytes of updated data U using the updated MAC card key (MCK), as shown below.

[0242] The implementation involves determining the data to be processed through multiple estimations and calculations. In one example, data U equals [control indicator (2 bytes) || update date and time (8 bytes) || '80' || '00 00 00 00 00']. For the calculations, the data can be divided into two separate parts. Specifically, data U is divided into two 8-byte data blocks, where U = U1 || U2. Furthermore, operations can be performed on U1 and U2.

[0243] The embodiment includes applying the algorithm to the first part (U1) of the data. In one example, the result B can be computed, where B = DES(MCKL)[U1], where DES is the data encryption standard algorithm using the first part (L) (MCKL) of the MAC card key.

[0244] In addition, extra operations can be performed on the result B. Specifically, the result B can be XORed with the second part of the data (U2).

[0245] The updated result B can be further processed. For example, result B can be further processed by applying the DES algorithm to B again using MCKL. As a result, inverse DES can be processed under the second part (R) of MCK (MCKR), and MAC M can be determined by applying the DES algorithm under MCKL to result B.

[0246] Figure 15 An example of method 1500 according to the embodiments discussed herein is shown. In block 1502, method 1500 includes receiving a request from a client device by a node in the system to establish a session to perform a function, wherein the function is performed at least in part using a contactless card (such as contactless card 102). In some cases, the node may be one of multiple nodes in the switching system. The node may be pre-selected by the sending device via a DNS operation performed.

[0247] In block 1504, method 1500 includes a node generating session information corresponding to a session to perform the function, wherein the session information includes a nonce and a signed session token. The nonce and / or the signed session token can be used by the system to perform the function described herein, while ensuring that the node routing the data is authenticated, the messages from the contactless card are authenticated, and maintaining a record of the session for the function.

[0248] In block 1506, method 1500 includes sending session information from the node to the client device. The client device can communicate with a contactless card to receive data from the card, thereby authenticating and performing functions. In some cases, the client device can send a nonce from the node to the contactless card. The contactless card can use the nonce communication to return to the client device when generating a message. Finally, the node, for example, incorporates it into the cipher portion of the message (see...). Figure 14 ).

[0249] In block 1508, method 1500 includes receiving a message from a contactless card via a client device. This message may be generated by the contactless card. Figure 14 An example of message 1400 is shown. In some embodiments, the node verifies the message. For example, the node may verify the nonce and the signed session token in the message.

[0250] In block 1510, method 1500 involves the node extracting the issuer identifier from the message, which is associated with the issuer of the contactless card. In some cases, the issuer identifier may be in plaintext format.

[0251] In block 1512, method 1500 involves a node identifying the device associated with the issuer identifier. For example, a node may perform a lookup to determine the server associated with the issuer identifier and the function to be performed.

[0252] In block 1514, method 1500 involves the node communicating with the device to securely perform the function.

[0253] Figure 16 A distributed network authentication system 1600 according to an example embodiment is illustrated. As discussed further below, system 1600 may include client node 1602, API 1604, network 1606, distributed ledger node 1610, mapping 1612, and client device 1614. Although Figure 16 A single instance of the component is shown, but the system 1600 may include any number of components.

[0254] System 1600 may include client node 1602, which may be a network-enabled computer as described herein. In some examples, client node 1602 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, laptop, notebook computer, handheld computer, network computer, mobile device, wearable device, or any processor control device capable of supporting system 1600.

[0255] In some examples, client node 1602 may execute one or more applications (such as software applications) that are capable of, for example, communicating over a network with one or more components of system 1600, transmitting and / or receiving data, and performing the functions and processes described herein.

[0256] Client nodes may include API 1604. For example, various different APIs can be provided for applications that can interact with services (e.g., those executing on computing devices, such as network-enabled computers). For example, applications executing on devices (e.g., smartphones, smartwatches, tablets, laptops, or other devices) interact with services by calling API 1604, such as by performing remote calls to the API to interact with network-based services.

[0257] API 1604 can be provided as a library, which includes specifications for routines, data structures, object classes, and variables. In some cases, such as for representative state transfer (REST) ​​services, an API (e.g., a REST API or RESTful API, or an API embodying some RESTful practices) is a specification for remote calls exposed to API clients (e.g., an application running on a client computing device can become a client of a REST API by making remote calls to it). REST services typically refer to the software architecture used to coordinate components, connectors, and / or other elements within a distributed system (e.g., a distributed hypermedia system).

[0258] Client node 1602 can communicate directly or via network 1606 with one or more other components of system 1600. Network 1606 may include one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and can be configured to connect components of system 1600. Although Figure 16 The diagram illustrates communication between components of system 1600 via network 1606, but it should be understood that any component of system 1600 may communicate directly with another component of system 1600, for example, without involving network 1606.

[0259] System 1600 may include an authentication node 1608, which may be a network-enabled computer as described herein. In some examples, authentication node 1608 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, laptop, notebook computer, handheld computer, network computer, mobile device, wearable device, or any processor control device capable of supporting system 1600.

[0260] In some examples, the verification node 1608 may execute one or more applications (such as software applications) that are capable of, for example, communicating with one or more components of the system 1600 over a network, transmitting and / or receiving data, and performing the functions and processes described herein.

[0261] In some examples, each authentication node can be associated with a route number, and the route number identifies the entity that controls the keys for the authentication namespace. The authentication namespace can be associated with one or more of a specific entity, a specific card set, or a specific set of security keys (e.g., master key, diversity key, session key) associated with an entity, card set, or card type.

[0262] System 1600 may include distributed ledger node 1610, which may be a network-enabled computer as described herein. In some examples, distributed ledger node 1610 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, laptop, notebook computer, handheld computer, network computer, mobile device, wearable device, or any processor-controlled device capable of supporting system 1600.

[0263] In some examples, the distributed ledger node 1610 may execute one or more applications (such as software applications) that are capable of, for example, communicating with one or more components of the system 1600 over a network, transmitting and / or receiving data, and performing the functions and processes described herein.

[0264] Distributed ledger node 1610 may contain mapping 1612. In some examples, mapping 1612 may be in the form of one or more databases. Exemplary databases may include, but are not limited to, relational databases, non-relational databases, hierarchical databases, object-oriented databases, web databases, and any combination thereof. The one or more databases may be centralized or distributed. The one or more databases may be hosted internally by any component of system 1600, or the one or more databases may be hosted externally by any component of system 1600. In some examples, the one or more databases may be contained within distributed ledger node 1610, while in other examples, the one or more databases may be stored externally to distributed ledger node 1610 but communicate with distributed ledger node 1610 for data. The one or more databases may be implemented using a database programming language. Exemplary database programming languages ​​include, but are not limited to, Structured Query Language (SQL), MySQL, Hypertext Markup Language, JavaScript, Hypertext Preprocessor Language, Utility Extraction and Reporting Language, Extensible Markup Language, and Common Gateway Interface. Queries performed on the one or more databases may be implemented using the same database programming language used to implement the one or more databases. For example, if one or more databases are SQL databases, queries can be performed on the databases using SQL (e.g., SELECT column1, column2 FROM table1, table2 WHERE column2='value';). It should be understood that one or more databases can be implemented using any database programming language, and the programming implementation of queries can be adapted as needed to be compatible with one or more databases and to reflect the specific information to be queried.

[0265] In some examples, one or more databases may be contained within distributed ledger node 1610. In other examples, one or more databases may be located remotely from distributed ledger node 1610 but communicate with it. The data communication between one or more databases and distributed ledger node 1610 may be direct data communication or data communication via a network (such as network 1606).

[0266] In some examples, client node 1602 can communicate with distributed ledger node 1610. Distributed ledger node 1610 may contain mapping 1612. Mapping 1614 may include, for example, a mapping between a validator node address and a validator node 1608, a mapping between a route number and a validator node address, and / or a mapping between a route number and a validator node 1608. In some examples, mapping 1612 may include a digital signature associated with an entity that has the authority to verify the route number. Based on one or more of these associations, client node 1602 may invoke a validator node for verification and / or provide direction to the client device to reach the appropriate validator node. This can be achieved by invoking the verification API associated with validator node 1608.

[0267] In some examples, the iterations of the mappings described herein (such as mapping 1612) may also include a software or app version number. The version number can be used to identify a verification node or verification node address, or to select among multiple verification addresses for a single verification node.

[0268] In some examples, client node 1602 and distributed ledger node 1610 can be authorized (e.g., allowed to join the network) using credential and / or cryptographic authentication mechanisms (e.g., non-fungible tokens). These credential and / or cryptographic authentication mechanisms can be issued by, for example, a consortium or other administrative entity associated with the distributed network. If appropriate permissions are granted, distributed ledger node 1610 can update mapping 1612 to reflect, for example, different associations between routing numbers, validator node addresses, and validator nodes. In some examples, permission levels can be issued. For example, if client node 1602 is to be used to route data to validator node 1608 (or another validator node), client node 1602 can be given a certain level of permissions. As another example, if distributed ledger node 1610 is to have the ability to update mapping 1612, distributed ledger node 1610 can have different, higher-level permissions.

[0269] System 1600 may include client device 1614, which may be a network-enabled computer as described herein. In some examples, distributed ledger node 1614 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, laptop, notebook computer, handheld computer, network computer, mobile device, wearable device, or any processor-controlled device capable of supporting System 1600. Client device 1614 may also be a mobile device; for example, a mobile device may include one from Apple. iPhone, iPod, iPad, or running Apple iOS Any other mobile device running Microsoft Windows operating system. Any device running Google's Android mobile operating system Any device with an operating system, and / or any other smartphone, tablet, or similar wearable mobile device. In some examples, client device 1614 can be connected to... Figure 16 Another network, not shown, enables the computer to perform data communication, such as a smart card (e.g., a contactless card or a contact-based card).

[0270] In some examples, client device 1614 may execute one or more applications (such as software applications) that are capable of, for example, communicating over a network with one or more components of system 1600, transmitting and / or receiving data, and performing the functions and processes described herein.

[0271] In some examples, upon receiving an authentication request, client device 1614 may invoke (e.g., via an API) client node 1602. This invocation may include a route number and / or an applet or software version number, and client node 1602 may query distributed ledger node 1610 and mapping 1612. Once the query returns the identifier of the validator node (e.g., validator node 1608) and / or the validator node address associated with that route number and / or applet or software version, client node 1602 can reply to client device 1614. Client device 1614 can then proceed with authentication with the validator node. Authentication can be performed by systems and methods such as those described herein, including the generation, encryption, transmission, decryption, and verification of passwords as described herein.

[0272] In some examples, client node 1602 may co-reside with authentication node 1608. In these examples, client node 1602 may handle authentication in a single call from client device 1614. In some examples, this may be acceptable only if it allows the complete authentication transfer (e.g., the password as described herein) to be sent to a client node that is not involved in authentication.

[0273] In some examples, if client node 1602 receives a route number from client device 1614 that has not been processed by its location, client node 1602 can return a code indicating that the route number has not been processed, along with the address of the authentication node that can be responsible for authentication. Client device 1614 can then use the received authentication node address to send a complete authentication transmission to authentication node 1608.

[0274] In some examples, client node 1602 may enter the distributed network with varying permissions. For instance, client node 1602 may be a read-only router for data. As another example, client node 1602 may have permission to send messages to distributed ledger node 1610 to update one or more routing paths for one or more route numbers. However, client node 1602 will be prevented from updating one or more routing paths for one or more route numbers for other entities that control other route numbers not associated with client node 1602 or for which such permission has not been granted. As another example, distributed ledger node 1610 may contain contacts and / or records that can verify the permissions of a specific entity to modify a specific routing record based on its digital signature. As yet another example, a consortium or other administrative entity controlling the distributed network may have additional privileges, but not limited to adding new members (e.g., client nodes, distributed ledger nodes, verification nodes, and / or client devices), adding new signing credentials, adding new keys, adding new credentials, and revoking any of the foregoing. In some examples, the above permissions can be delegated to client node 1602, distributed ledger node 1610, and / or validator node 1608 if security, legal, and / or financial conditions are met; however, delegation is not required.

[0275] In some examples, one or more APIs can facilitate communication between components of system 1600 via network 1606. In other examples, one or more APIs are not required. Instead, components of system 1600 can communicate directly and / or be dedicated to one or more specific entities, allowing those entities to prevent data from being transmitted to, from, or via non-specific entities. This can further enhance data security and prevent detection of data traffic patterns by non-specific entities.

[0276] In some examples, entities can establish standards for nodes with APIs based on the expected functionality of these nodes. For instance, a first standard can be established for data routing nodes, and a second standard can be established for nodes performing mapping and / or authentication functions. As another example, routing APIs, mapping APIs, and authentication APIs can be established, which can allow the same device or hardware configuration to perform these functions. However, the use of keys (including the secret key used for authentication by authentication node 1608) may require storing the keys in one or more HSMs to improve key security and ensure that the keys never enter memory.

[0277] Figure 17 A method 1700 performed by a distributed network authentication system according to an example embodiment is shown. For example, the method may be performed by a distributed network authentication system 1600 and / or by another distributed network authentication system.

[0278] In block 1702, the client device can send an authentication request to the client node. The authentication request may include, but is not limited to, a route number, software version number, and / or applet version number. The request can be made via API calls or other communication between the client device and the client node.

[0279] In block 1704, after receiving an authentication request, a client node can send a query to a distributed ledger node (e.g., via an API call). The distributed ledger node contains mappings, and the distributed ledger node can submit queries to these mappings.

[0280] In block 1706, a query can return the identifier and / or address of the validator node, and the distributed ledger node can transmit this identifier to the client node.

[0281] In block 1708, the client node can transmit the identifier to the client device. In block 1710, after receiving the identifier, the client device can continue to authenticate using the identified authentication node and / or authentication node address.

[0282] Figure 18 An operation sequence 1800 according to an example embodiment is shown. For example, operation sequence 1800 may be executed by components of data transmission system 100, exchange system 1100, and distributed authentication system 1600 (such as contactless card 102 and node 1104); however, it should be understood that the execution of operation sequence 1800 is not limited thereto. In some embodiments, operation sequence 1800 may be executed by merchant service provider 1802, node 1104, and transaction processor 1804.

[0283] In step 1806, the contactless card 102 is tapped onto a merchant service provider 1802, which may be a client device as described herein. In some examples, the client device communicates data with one or more servers associated with the merchant to perform the functions of the merchant service provider. Exemplary merchant service providers may include, but are not limited to, websites, digital wallets, applications on personal computing devices, mobile computing devices, and point-of-sale devices. The client device may be configured to present one or more user interfaces to prompt the tapping of the contactless card 102, including associated information, instructions, and terms and conditions.

[0284] In step 1808, the contactless card 102 can be read by an application running on the client device during the tap, such as through NFC reading. Through this reading, a small application stored in the memory of the contactless card 102 can be identified and selected to perform functions such as authentication and card configuration. Additionally, data can be read from the contactless card 102, including data used for the aforementioned functions.

[0285] In 1810, the application can transmit a card configuration request to node 1104. The card configuration may include data associated with the contactless card 102, necessary for initiating configuration and, in some embodiments, for further authentication, including a payload associated with the selected applet, a device identifier, a wallet identifier, a server session identifier, a client session identifier, a funds master account (FPAN), an expiration date, and any combination thereof.

[0286] In step 1812, in response to receiving a card configuration request, node 1104 may perform verification of the card configuration request. In some embodiments, node 1104 may perform one or more authentication processes and / or one or more verification processes, including the authentication and verification processes described herein.

[0287] In step 1814, after verification, node 1104 can send a configuration notification to transaction processor 1804. The configuration notification may include a configuration notification to the server associated with the transaction processing entity, and the pushed configuration notification may include sessionID, walletID, OPC, FPAN, and / or expiration date.

[0288] In step 1816, in response to receiving a configuration notification, transaction processor 1804 can send a notification to node 1104 indicating that the configuration notification has been received. In step 1818, node 1104 can also send a notification indicating receipt to merchant service provider 1802.

[0289] In some embodiments, multiple data exchanges may be established between a transaction processing entity and other entities, such as a card issuing entity or a card verification entity. In these embodiments, the data to be exchanged may include telephone numbers (e.g., telephone numbers associated with a user and / or an account associated with the card) and a set of risk signals employed by the transaction processing entity for card configuration purposes (e.g., with a payment processing entity). The telephone number can be used as a means of verifying that a client device receiving a card tap is associated with a user, a card, and / or an account associated with the user and / or the card. The risk signal set can be provided to allow the card entity to understand and use it to improve future conversions.

[0290] Exemplary data to be exchanged may also include data related to wallets or other accounts maintained by the transaction processing entity, such as device ID, wallet ID, server session ID, and client session ID. In some examples, some or all of this data may be the same as the data generated by the server-side push configuration SDK when a request to create a push configuration session (e.g., createPushProvisionSession) is made. The clientSessionID may be required for push configuration notification calls (e.g., / pushProvisioningNotification).

[0291] In some embodiments, multiple operations may be performed by the transaction processing entity and another entity, such as a card entity associated with the issuance and / or verification of the contactless card. After the card is tapped on the client device, an application associated with the transaction processing entity reads the card and selects an applet to perform authentication and / or card configuration functions on the client device. The application may transmit a card configuration request to a server associated with the card entity, and the card configuration request may include a payload associated with the applet, deviceID, walletID, serverSessionID, clientSessionID, and / or one or more risk signals. The server may perform authentication and / or verification of the contactless card and / or the card configuration request. The server may transmit a push configuration notification to the server associated with the transaction processing entity, and the push configuration notification may include sessionID, walletID, OPC, Funds Master Account (FPAN), and expiration date. The server associated with the transaction processing entity may acknowledge the push configuration notification in a notification transmitted to the server associated with the card entity. The server associated with the card entity may acknowledge this acknowledgment by transmitting a notification to the application.

[0292] In some embodiments, multiple operations are provided for push configuration between a transaction processing entity (e.g., its associated application or server) and a card entity (e.g., its associated application or server). In some examples, the transaction processing entity may send to the card entity an app payload, walletID, session identifier (e.g., serverSessionID, clientSessionID), a phone number associated with the client device, user, and / or account (associated with the card), and / or one or more risk signals. The card entity may configure the card with the card information and share the card information with a backend associated with the transaction processing entity. The transaction processing entity may save the card archive to the account. The transaction processing entity may exchange app payloads with the payment processing network to generate one or more device-specific numbers (e.g., Device Master Account (DPAN)).

[0293] In some embodiments, one or more user interfaces may be presented to provide users with guidance, information, and instructions to facilitate interaction with the systems and methods described herein. For example, one or more user interfaces may provide the use of card tapping to add cards associated with a transaction processing entity for purposes such as adjusting settings, adding payment methods, and / or viewing terms and conditions. In some examples, virtual card numbers (VCNs) may be created and / or registered for the cards.

[0294] Exemplary user interfaces used with the systems and methods described herein may include a first user interface that displays a settings menu on a client device. A second user interface may display a payment method settings menu. A third user interface may display an interface for adding a payment method. A fourth user interface may display adding a card, the terms and conditions associated with the added card, and a request for user consent.

[0295] Exemplary user interfaces used with the systems and methods described herein may include a first user interface that displays instructions and guidance for tapping a card onto a client device. A second user interface may display an interface for reading and verifying the tapped card. A third user interface may display saved payment methods, archived payments, and options for selecting a payment method.

[0296] In some embodiments, one or more user interfaces may be presented to provide users with guidance, information, and instructions to facilitate interaction with the systems and methods described herein. For example, one or more user interfaces may allow a user to add a card for use with a transaction processing entity by tapping the card onto a client device. Users can interact with user interfaces, such as those presented by the transaction processing entity, for card tapping, card reading by the client device, providing terms and conditions and receiving user consent, and configuring the card to the transaction processing entity.

[0297] An exemplary user interface for use with the systems and methods described herein may include a first user interface for requesting a user to tap their card on a client device. In some examples, the first user interface may be the same as the user interface used for tap-to-mark functionality (e.g., Europay, Mastercard, and Visa (EMV) tap-to-mark functionality). If an SDK is present on the client device, the SDK may take precedence over the systems and methods described herein. A second user interface may display an indication that the card is being read and / or that the card has been read. The card entity brand may be displayed after the card has been read. In some examples, a green path configuration may be provided instead of a yellow path option. If one or more risk signals are detected, the user will be automatically taken to an agreement screen. A third user interface may display the terms and conditions from the card entity for adding the card to the DPAN. In some examples, the DPAN may be associated with a transaction processing entity. The terms and conditions may apply to adding the card as well as other functions such as VCN registration and autofill. A fourth user interface may display the result of adding the card. The card may be displayed as a payment option to be used with the transaction processing entity, as it has been configured for the transaction processing entity.

[0298] Exemplary risk signals may include, but are not limited to: Account Age (the date the customer opened his or her account with a third party); Account Change Date (the date the customer last modified information about the third-party account); Account ID (a unique identifier for the account holder, such as a wallet account holder, which may be a hash value); Account Risk Score (a third party's assessment of the risk of the third-party account (e.g., 1-high / red; 5-low) with a reason code); Account-to-Device Binding ID (e.g., an account-to-device binding identifier); Account-to-Device Binding Age (the number of days this device has been used by this account); Customer Email (Hash) (an email address used with the purchase and / or configuration request); Customer Name (the customer name used with the purchase and / or configuration request); Customer Phone Number (the customer phone number used with the configuration); Device Geolocation (latitude / longitude at the time of the configuration request); Device ID (a unique identifier, such as a MAC address, International Mobile Equipment Identity (IMEI), or other identifiers that uniquely identify the customer's device). Device IP address (IP address of the device the customer is using); Device name (device name assigned by the user); Device operating system, version (label and / or identifier of device operating system and version); Device risk score (third-party assessment of device risk (e.g., 1-high / red; 5-low) with reason code); Device type, model (device form factor (phone, watch); manufacturer and model); PAN and / or PAN identifier (master account) (in some instances, proxy identifier of PAN, such as PAN hash); PAN entry mode (how the user enters PAN (e.g., camera, manual button, etc.)); PAN source indicator (how PAN was obtained by a third party (e.g., wallet, third-party property, checkout, etc.)); Payment method attempts (number of times payment cards have been tried to be added to this account in the past 24 hours); Configuration decision, code (recommendation decision and reason code for the configuration); and usage rate (number of times configurations and transactions have been attempted on this account over a period of time, such as the past 24 hours or the past year).

[0299] Figure 19A An example sequence diagram 1900 is shown for configuring a form of payment (FoP) on a website, application, or other form of online service to execute payment transactions. In this example sequence diagram 1900, the system includes a third-party application 1902, a third-party backend server 1904, an authentication server 1906, a token service provider 1908, and an issuer third-party host 1910. The third-party application 1902 may include third-party applications that accept the form of payment. For example, the third-party application 1902 may include payment applications from Google, Apple, Microsoft, PayPal, VenMo, or CashApp, such as Google Wallet, Apple Wallet, or Apple Pay, or any other suitable payment application. The third-party application 1902 may also include various applications or websites that accept payments. In the example above, Google's YouTube platform, Play Store, Android app, or Chrome could be example platforms that accept payments. Similarly, Apple products, Microsoft, PayPal, VenMo, CashApp, and other websites or applications include applications or websites that accept the form of payment. For example, the website or application can be on a user's mobile device (such as a smartphone, tablet, mobile phone, iPad). It can be executed on a tablet or any other suitable mobile device.

[0300] The third-party backend server 1904 may include servers or other systems that operate and maintain the third-party application 1902. For example, the third-party backend server 1904 may include a web application for accepting payments or a web server for any other website. As another example, the third-party backend server 1904 may include application servers, such as Google or Apple servers that serve their respective wallets or payment platforms.

[0301] Authentication server 1906 is a server or other system that provides authentication services for payment transactions. In some examples, authentication server 1906 may include an authentication server from the exchange system 1100 described herein. Authentication server 1906 may be controlled and operated by the contactless card issuer or by another entity.

[0302] The token service provider 1908 includes, for example, a server operated by a payment card service provider. For instance, the token service provider 1908 could be operated and maintained by Visa, Mastercard, American Express, or any other suitable payment card service provider. The issuer third-party host 1910 is a server or service provided by the issuer of the contactless card described herein. The issuer third-party host 1910 is provided to communicate with the token service provider 1908 to verify the creditworthiness of the account associated with the contactless card and to assist in performing various other checks to ensure the account is suitable for configuration.

[0303] At 1912, a user accessing the third-party application 1902 on their mobile device or another computing device selects a button or other icon on their mobile device to add their contactless card as a form of payment on the website or application. In some embodiments, the selection of the button or other icon is an option to add a form of payment by tapping their card. For example, the button or icon displayed by the website or application may include the phrase "Add by tap," instructing the user to "tap" their card onto their mobile device to configure their payment form (e.g., contactless card) to their account on the website or application. In response to the user selecting the button, their phone then executes the application to prompt them to tap their card. The user then taps their card, and at 1914, the mobile device performs a read of the contactless card, for example, using NFC Data Exchange Format (NDEF) and Europay, Mastercard, and Visa (EMV). During the NDEF and EMV reads, the third-party application 1902 determines whether the user's contactless card has a specific applet that operates on it. During NDEF and EMV reading, third-party application 1902 will obtain encrypted data from the contactless card, including the authentication code and other data about the contactless card, such as the card's primary account (PAN), expiration date, CVV, and other encrypted data. At 1916, if the applet is not operating on the contactless card or does not exist on the contactless card, the configuration can stop, and the third-party backend server 1904 and third-party application 1902 can perform EMV transactions (or other types of transactions) for the payment transaction.

[0304] At 1918, the user equipment is provided with terms and conditions from third-party application 1902. On the user's mobile device, the user is asked to accept the terms and conditions. If the user does not accept, the process terminates. However, in sequence diagram 1900, at 1920, the user accepts the terms and conditions provided by the third party. After the user accepts the terms and conditions, at 1922, a card configuration request is sent from third-party application 1902 to third-party backend server 1904 to configure the contactless card that was lightly touched to the user's mobile device at 1912.

[0305] At point 1924, after the third-party backend server 1904 receives a card configuration request from the third-party application 1902, the third-party backend server 1904 sends a session creation request to the authentication server 1906 to create a session for configuring the contactless card to the third-party application 1902. In some embodiments, the session creation request includes the user's mobile device's device identifier (ID), the user's wallet ID if a digital wallet is being used, the session ID of the session, and the client ID. This information is used by the authentication server 1906 to verify with the third-party backend server 1904 that the device ID and wallet ID are available for use by a website or application that the user wishes to configure their payment method for (e.g., when the contactless card is tapped against the mobile device).

[0306] At 1926, a session creation response is sent from authentication server 1906 to third-party backend server 1904, indicating that a session has been created and that the session token is shared with third-party backend server 1904. At 1928, third-party backend server 1904 then generates a risk signal. The risk signal is used to help prevent fraud. In some embodiments, the risk signal includes a fully hashed device phone number associated with a user account associated with third-party application 1902. The risk signal also includes a fully hashed email address associated with a user account associated with third-party application 1902. In some embodiments, the risk signal may also include a risk score for the user's device and the account associated with third-party application 1902. The risk signal may also include the Internet Protocol (IP) address of the user's device connected to third-party application 1902, the device's geographic location, the user device-to-account binding identifier (ID), and the device-to-account age.

[0307] At point 1930, the third-party backend server 1904 will send an authentication process function request to the authentication server 1906. The authentication process function request includes encrypted data from the contactless card, session ID, consent date, the risk signal generated above, wallet ID of the user's digital wallet linked to the third-party application 1902, and the user's device ID.

[0308] At 1932, authentication server 1906 uses a decryption algorithm to decrypt the encrypted data from the contactless card and compares the decrypted authentication code with the expected authentication code of the contactless card. At 1934, if authentication fails, authentication server 1906 sends a notification indicating failure to third-party backend server 1904, causing the configuration process to stop and causing third-party backend server 1904 and third-party application 1902 to execute an EMV transaction (or other type of transaction) for the payment transaction. If authentication succeeds, authentication server 1906 is configured to assess risk signals to determine the likelihood that the current configuration request is fraudulent. Furthermore, at 1934, if the risk assessment indicates that the configuration request (e.g., an authentication process function request) may be fraudulent, authentication server 1906 sends a notification indicating a fraudulent transaction to third-party backend server 1904, causing the configuration process to stop and causing third-party backend server 1904 and third-party application 1902 to execute an EMV transaction (or other type of transaction) for the payment transaction.

[0309] At step 1936, if authentication is successful and the risk assessment indicates the configuration request is unlikely to be fraudulent, authentication server 1906 returns the session ID, wallet ID, encrypted Funds Master Account (FPAN), card expiration, user's address, and / or OPC to third-party backend server 1904. If OPC is not provided, the following operations 1940, 1942, 1944, 1946, and 1948 are skipped, and flowchart 1900 transitions directly from operation 1938 to 1950. OPC is optional but can be used if the Device Master Account (DPAN) for contactless cards is not supported by certain applications and websites.

[0310] At 1938, the third-party backend server 1904 then stores the FPAN in the data storage device, associates it with the user's account, and indicates in the data storage device that the user account's FPAN has been authenticated. At 1940, the third-party backend server 1904 then sends a request to the token service provider 1908 to register the PAN. In this operation, the OPC and session ID are sent, but the FPAN is not sent because the OPC is being sent.

[0311] At point 1942, the token service provider 1908 communicates with the issuer third-party host 1910 requesting to register the PAN during the configuration process to configure the user's contactless card to the third-party application 1902. The issuer third-party host 1910 evaluates the request and determines whether the user's account is trustworthy. If not, the process terminates, and the contactless card is not configured to the third-party application 1902. If the user's account is trustworthy, at point 1944, the issuer third-party host 1910 sends a response to the token service provider 1908 instructing them to do so.

[0312] Figure 19B It comes from Figure 19A This is a continuation of sequence diagram 1900. At 1946, the token service provider 1908 checks to ensure that certain parameters are set to correctly configure the contactless card for the third-party application 1902. For example, in some embodiments, the token service provider 1908 may check to ensure that the panSource parameter is set to PUSH. In some cases, if an OPC is sent, the token service provider 1908 automatically sets the panSource parameter to PUSH, but otherwise this is a rule defined by the issuer.

[0313] At point 1948, the token service provider 1908 returns an activated token to the third-party application 1902, indicating that the contactless card can be configured for the user account of the third-party application 1902.

[0314] At 1950, the third-party backend server 1904 determines whether the Bank Identification Number (BIN) associated with the contactless card allows the user to register a Virtual Card Number (VCN) autofill procedure. If so, the third-party backend server 1904 sends a request to the authentication server 1906 to establish the VCN autofill procedure and marks the request as authenticated.

[0315] At 1952, the third-party backend server 1904 sends a Credit Master Account (CPAN) creation request to the token service provider 1908. This request includes the FPAN, session ID, and CPAN TRID (TILA-RESPA Integrated Disclosure). At 1954, the token service provider 1908 sends a request to the authentication server 1906 to determine if the account is eligible for CPAN creation, and this request also includes the FPAN, session ID, and CPAN TRID. At 1956, based on analysis of the FPAN, session ID, and CPAN TRID, if the account has good credit, the authentication server 1906 sends a message to the token service provider 1908 instructing them to do so. At 1958, the token service provider 1908 creates the CPAN and sends it to the third-party backend server 1904 in a message. At 1960, the third-party backend server 1904 then stores the generated CPAN and marks it as authenticated by the authentication server 1906. Then, the third-party backend server 1904 retrieves the contactless card information and configures the card for the digital wallet, or alternatively saves the contactless card as a payment method associated with the third-party application 1902.

[0316] At 1962, the verified FPAN was archived by third-party application 1902 and marked or indicated as being authenticated using authentication server 1906. DPAN was used for transactions with third-party application 1902, and at 1964, CPAN was used to archive contactless card information under third-party application 1902.

[0317] Figure 20A Flowchart 2000 illustrates an example embodiment of a system for improving Merchant Card Not Present (CNP) approval and transactions. In some embodiments, the system includes a merchant 2002 (e.g., a merchant server associated with the merchant), a third-party server 2004, an authentication application 2006, an authentication server 2008, an issuer server 2010, and a credit card network server 2012. In some embodiments, merchant 2002 may be located at a point-of-sale (POS) system or on an online merchant website. For example, merchant 2002 may have both a physical sales location and an online store. Transaction requests from users may be received at a physical sales location (e.g., at a POS system), or transactions may be initiated on the online store or on the merchant's mobile application.

[0318] The third-party server 2004 can be maintained and operated by an organization that facilitates authentication, payment optimization, and fraud prevention. The authentication application 2006 is a front-end service provided by the authentication server 2008. For example, the authentication application 2006 can generate pop-ups or other applications that provide prompts and other data to the user's mobile device to prompt the user to initiate the authentication process. The authentication server 2008 operates a back-end system that communicates with the authentication application 2006 to assist in authenticating user accounts. The authentication server 2008 is also configured to provide authentication signatures to decrypt and verify authentication codes.

[0319] The Issuer Server 2010 is a server maintained by the contactless card issuer and performs the various operations described herein. The Credit Card Network Server 2012 is a credit card network device operated and maintained by one or more credit card network companies.

[0320] At point 2014, merchant 2002 receives a transaction request from a user with a contactless card. In response to the transaction request from the user, merchant 2002 sends a message to third-party server 2004 to initiate the pre-authorization verification process.

[0321] At 2016, third-party server 2004 determines whether a user possesses a contactless card capable of communicating with authentication application 2006 and authentication server 2008 to perform authentication of the contactless card. In some cases, the bank identification number (BIN) range of the contactless card may be used to determine whether the contactless card is capable of communicating with authentication application 2006 and authentication server 2008 for authentication. Alternatively, merchant 2002 may also be provided with the user's contact information, such as their phone number, and the user's contact information and BIN (and / or BIN range) may be used to determine whether the user's contactless card or another card possessed by the user is capable of communicating with authentication application 2006 and authentication server 2008 for authentication.

[0322] In 2018, third-party server 2004 sends a request to authentication server 2008 to initiate an authentication session to authenticate the contactless card and thus the user's identity. In 2020, in response to this request, authentication server 2008 returns a JavaScript Object Notation (JSON) Web Token (JWT) to third-party server 2004 to facilitate authentication of the contactless card by authentication server 2008. In 2022, in response to receiving the JWT, third-party server 2004 sends a request for a Universal Resource Locator (URL) for the authentication experience to authentication server 2008. Alternatively, a Quick Response (QR) code can be requested. In 2024, authentication server 2008 sends the authentication experience URL (or QR code) to third-party server 2004, and in 2026, the URL or QR code is sent to merchant 2002 for display to the user on their mobile devices or their desktop computers. The URL or QR code can also be displayed on the merchant's POS system.

[0323] At point 2028, Merchant 2002 displays a URL for the user to choose from, and the user selects a URL. Alternatively, if the transaction is taking place at a POS terminal or on the user's desktop, a QR code can be displayed, and the user can scan the QR code on their mobile device. By selecting a URL or scanning a QR code on their mobile device, an authentication application is initiated on the user's mobile device, creating an authentication session between Merchant 2002 and Authentication Application 2006. At point 2030, Authentication Application 2006 initiates the authentication experience, and the user is prompted to tap their contactless card against their mobile device. At point 2032, the user taps their card against their mobile device, and in response, encrypted data is sent from the contactless card to the mobile device and then forwarded to Authentication Application 2006 for authentication. The encrypted data includes, among other things, an encrypted authentication code used to verify the identity of the user and the contactless card.

[0324] At point 2034, encrypted data including the authentication code is sent to authentication server 2008 to decrypt the encrypted data, including the authentication code, using a decryption algorithm. At point 2036, authentication server 2008 sends a message to authentication application 2006 indicating that the encrypted data has been successfully decrypted and the authentication code has been verified or confirmed. At point 2038, authentication server 2008 sends a similar message to third-party server 2004 to indicate that the encrypted data has been successfully decrypted. At point 2040, third-party server 2004 sends a pre-authorization response to merchant 2002 to indicate that the authentication request has been verified and the contactless card has been authorized for the transaction. This verifies that the user actually possesses the card and that the transaction is unlikely to be fraudulent.

[0325] Figure 20B It comes from Figure 20A This is a continuation of sequence diagram 2000. At 2042, third-party server 2004 sends a message to issuer server 2010 presenting enhanced decision data (EDD) with an authentication result flag. The authentication result flag indicates that the contactless card has been authenticated by authentication server 2008. In response, at 2044, issuer server 2010 sends a unique transaction reference identifier (ID) back to third-party server 2004.

[0326] At step 2046, merchant 2002 submits an authorization request to credit card network server 2012 to authorize the transaction. In some embodiments, operations 2046 and 2042 are performed simultaneously. Operations 2042 and 2044 represent an enhanced decision-making process between third-party server 2004 and issuer server 2010, while operation 2046 and subsequent operations are performed between merchant 2002, issuer server 2010, and credit card network server 2012.

[0327] At point 2048, the credit card network server 2012 forwards or sends the transaction request to the issuer server 2010, and at point 2050, the issuer server 2010 uses its rules engine to calculate the fraud risk, which is calculated by considering the authentication result from operation 2036. At point 2052, the issuer server 2010 sends a response to the credit card network server 2012, indicating a low fraud risk and authorizing the transaction to proceed. At point 2054, the credit card network server 2012 sends a message to the merchant 2002, indicating that the transaction request has been authorized, and the merchant 2002 is permitted to allow the transaction to proceed.

[0328] Figure 21 An embodiment of an exemplary computer architecture 2100 suitable for implementing the various embodiments described above is illustrated. In one embodiment, the computer architecture 2100 may include or be implemented as part of one or more systems or devices discussed herein.

[0329] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities, whether hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 2100. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. By way of example, both an application running on a server and the server itself can be components. One or more components may reside within a process and / or an execution thread, and components may be located on a single computer and / or distributed across two or more computers. Furthermore, components may be communicatively coupled to each other via various types of communication media to coordinate operation. This coordination may involve one-way or two-way information exchange. For example, components may transmit information in the form of signals transmitted through a communication medium. This information may be implemented as signals dispatched to various signal lines. In such a distribution, each message is a signal. However, further examples may alternatively employ data messages. Such data messages can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0330] Computing architecture 100 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to those implemented by computing architecture 100.

[0331] like Figure 21 As shown, the computing architecture 100 includes a processor 2112, a system memory 2104, and a system bus 2106. The processor 2112 can be any of a variety of commercially available processors.

[0332] System bus 2106 provides an interface to processor 2112 for system components, including but not limited to system memory 2104. System bus 2106 can be any of a variety of bus architectures, which can further utilize any of a variety of commercially available bus architectures to interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses. Interface adapters can be connected to system bus 608 via slot architectures. Example slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, PCMCIA, and similar architectures.

[0333] The computing architecture 100 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium that can be read and executed by one or more processors to enable the performance of the operations described herein.

[0334] System memory 2104 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memories such as ferroelectric polymer memories, austenite memories, phase-change or ferroelectric memories, silicon-silicon oxide-silicon nitride-silicon oxide-silicon (SONOS) memories, magnetic cards or optical cards, device arrays such as redundant array of independent disk drives (RAID), solid-state storage devices (e.g., USB storage devices, solid-state drives (SSDs)), and any other type of storage media suitable for storing information. Figure 21 In the illustrated embodiment, system memory 2104 may include non-volatile memory 2108 and / or volatile memory 2110. The basic input / output system (BIOS) may be stored in non-volatile memory 2108.

[0335] Computer 2102 may include various types of computer-readable storage media in the form of one or more low-speed storage units, including an internal (or external) hard disk drive 2130, a disk drive 2116 for reading from or writing to a removable disk 2120, and an optical disc drive 2128 for reading from or writing to a removable optical disc 2132 (e.g., a CD-ROM or DVD). Hard disk drive 2130, disk drive 2116, and optical disc drive 2128 may be connected to system bus 2106 via HDD interface 2114, FDD interface 2118, and optical disc drive interface 2134, respectively. HDD interface 2114 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0336] The drive and associated computer-readable medium provide volatile and / or non-volatile storage for data, data structures, computer-executable instructions, and so on. For example, multiple program modules may be stored in the drive and non-volatile memory 2108 and volatile memory 2110, including an operating system 2122, one or more applications 2142, other program modules 2124, and program data 2126. In one embodiment, one or more applications 2142, other program modules 2124, and program data 2126 may include various applications and / or components of, for example, the systems discussed herein.

[0337] Users can input commands and information to computer 2102 through one or more wired / wireless input devices, such as keyboard 2150 and pointing devices such as mouse 2152. Other input devices may include microphones, infrared (IR) remote controls, radio-frequency (RF) remote controls, game controllers, styluses, card readers, dongles, fingerprint readers, gloves, drawing tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, touchpads, sensors, styluses, and the like. These and other input devices are typically connected to processor 2112 via input device interface 2136, which is coupled to system bus 2106, but may also be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc.

[0338] Monitor 2144 or other types of display devices are also connected to system bus 2106 via an interface (such as video adapter 2146). Monitor 2144 can be built into or external to computer 2102. In addition to monitor 2144, the computer typically includes other peripheral output devices, such as speakers, printers, etc.

[0339] Computer 2102 can operate in a networked environment using logical connections to one or more remote computers (such as one or more remote computers 2148) via wired and / or wireless communications. The one or more remote computers 2148 can be workstations, server computers, routers, personal computers, laptops, microprocessor-based entertainment devices, peer-to-peer devices, or other common network nodes, and typically include many or all of the elements described relative to computer 2102, although for brevity only memory and / or storage devices 2158 are shown. The depicted logical connections include wired / wireless connections to local area networks 2156 and / or larger networks (e.g., wide area networks 2154). Such LAN and WAN network environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks, such as the Internet.

[0340] When used in a local area network (LAN) 2156 network environment, computer 2102 connects to LAN 2156 via a wired and / or wireless communication network interface or network adapter 2138. Network adapter 2138 facilitates wired and / or wireless communication with LAN 2156, which may also include a wireless access point configured thereon for communicating with the wireless functionality of network adapter 2138.

[0341] When used in a wide area network (WAN) 2154 network environment, computer 2102 may include modem 2140, or a communication server connected to WAN 2154, or have other means for establishing communication on WAN 2154, such as via the Internet. Modem 2140, which may be built-in or external and wired and / or wireless, is connected to system bus 2106 via input device interface 2136. In a network environment, program modules described relative to computer 2102 or parts thereof may be stored in remote memory and / or storage device 2158. It will be appreciated that the network connections shown are exemplary and other means of establishing communication links between computers may be used.

[0342] Computer 2102 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operable in wireless communication (e.g., IEEE 802.11 air modulation technology). Among other things, this includes at least Wi-Fi (or wireless fidelity), WiMax, and Bluetooth. TM Wireless technology. Therefore, communication can be a predefined structure like a regular network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to connect computers to each other, connect to the internet, and connect to wired networks (which use the media and functions related to IEEE 802.3).

[0343] The various elements of the devices described earlier herein can include a variety of hardware elements, software elements, or combinations thereof. Examples of hardware elements can include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements can include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware and / or software components can vary depending on any number of factors, such as desired computing speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints as desired by a given implementation.

[0344] The components and features of the device described above can be implemented using any combination of discrete circuit systems, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Further, where appropriate, the features of the device can be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof. It should be noted that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuit".

[0345] Figure 22 This is a block diagram depicting an exemplary communication architecture 2200 suitable for implementing the various embodiments described above. Communication architecture 2200 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to those implemented by communication architecture 2200 and may be consistent with the systems and devices discussed herein.

[0346] like Figure 22 As shown, the communication architecture 2200 includes one or more clients 2202 and servers 2204. Server 2204 may implement one or more of the functions and embodiments discussed herein. Clients 2202 and servers 2204 are operatively connected to one or more corresponding client data storage devices 2206 and server data storage devices 2208, which can be used to store information local to the respective client 2202 and server 2204, such as cookies and / or associated context information.

[0347] Client 2202 and server 2204 can use communication framework 2210 to transmit information to each other. Communication framework 2210 can implement any well-known communication technology and protocol. Communication framework 2210 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as an enterprise intranet, etc.), a circuit-switched network (e.g., the public switched telephone network), or a combination of packet-switched and circuit-switched networks (with suitable gateways and converters).

[0348] The communication framework 2210 can implement various network interfaces arranged to receive, communicate, and connect to a communication network. A network interface can be considered a specialized form of input / output (I / O) interface. Network interfaces can employ connectivity protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted-pair 10 / 100 / 1000 Base T, etc.), Token Ring, wireless network interfaces, cellular network interfaces, IEEE 802.7 ax network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, etc. Furthermore, multiple network interfaces can be used to interface with various communication network types. For example, multiple network interfaces can be employed to allow communication over broadcast, multicast, and unicast networks. If processing requirements specify a greater amount of speed and capacity, a similar distributed network controller architecture can be employed to pool, load balance, and otherwise increase the communication bandwidth required by one or more clients 2202 and one or more servers 2204. The communication network can be any and a combination of wired and / or wireless networks, including but not limited to direct interconnection, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), Operational Missions as Nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

[0349] As described herein, the systems and methods of this disclosure offer numerous benefits. For example, the systems and methods of this disclosure can provide a single tap transaction flow for contactless cards through first-party and third-party entry points. This transaction flow can be configured and registered for transactions using DPAN, CPAN, VCN, and FPAN-supported cards, as described herein. The transaction flow described herein results in higher conversion rates for configuring digital wallets and contactless cards. The transaction flow described herein further results in lower challenge rates for VCN retrieval.

[0350] The systems and methods disclosed herein enable consistent user interface processing for transactions. Such transactions may include card authentication and configuration transactions as described herein, as well as EMV transactions and other transactions. As described herein, if the authentication or verification process fails, an EMV transaction or other transaction may be executed.

[0351] By reusing existing configuration flows where applicable, the systems and methods disclosed herein can achieve lower implementation costs. Furthermore, lower implementation costs can be achieved by employing a single implementation model for authenticating and verifying transactions, whereas EMV transactions typically require different implementation methods.

[0352] The systems and methods disclosed herein can achieve lower first-party and third-party fraud rates using verified CPANs and FPANs. Furthermore, using verified CPANs and FPANs for transactions provides improved authentication.

[0353] The systems and methods disclosed herein enable additional authentication methods. Such authentication may not be applicable to EMV transactions.

[0354] The systems and methods of this disclosure can improve transaction performance through improved read latency. When compared to EMV transactions, the read latency implemented by the systems and methods of this disclosure exhibits improved read latency.

[0355] The systems and methods disclosed herein can reduce the risks associated with CNP approval and transactions by improving the balance between rejecting fraudulent transactions and avoiding the wrongful rejection of legitimate transactions. Through the authentication and verification provided by the systems and methods described herein, transactions can be found to be legitimate and approved, even considering risk signals that could lead to their wrongful rejection as fraudulent.

[0356] Note 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, a data storage device 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. The data storage device may also include storage media or other suitable types of memory (e.g., such as 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, any type of tangible and non-transitory storage media), in which files including operating systems, 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 may include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases, such as those from Oracle. The database created and maintained by the Corporation's software, Microsoft Excel file, Microsoft Access files, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage devices (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 various components can be combined or separated. Other modifications are also possible.

[0357] Throughout this disclosure, references are made to cards, such as contact-based cards and contactless cards. It should be understood that this disclosure is not limited to any particular type of card, and rather, it covers contact-based cards, contactless cards, or any other type of card. Further, this disclosure is not limited to cards for a specific purpose (e.g., payment cards, gift cards, ID cards, membership cards, transportation cards, access cards), cards associated with a specific type of account (e.g., credit accounts, debit accounts, membership accounts), or cards issued by a specific entity (e.g., commercial entities, financial institutions, government entities, social clubs). Rather, it should be understood that this disclosure includes cards for any purpose, account association, or issuing entity.

[0358] As used herein, the term "card entity" may include, but is not limited to, financial institutions (such as banks). However, it should be understood that the term "card entity" is not limited thereto, and this disclosure may include corporations, state, local and federal governments, and any other entity that issues, personalizes, activates, authenticates and / or verifies cards for use in transactions.

[0359] As used herein, the term "tap" may include, but is not limited to, tapping a card on a device. However, it should be understood that the term "tap" is not limited to a specific gesture, and this disclosure may include tapping, swiping, waving, and / or any combination thereof.

[0360] As used herein, the term "transaction" may include, but is not limited to, financial transactions. However, it should be understood that the term "transaction" is not limited thereto, and this disclosure may include financial transactions, identity verification transactions, region access transactions, user authentication transactions, membership verification transactions, eligibility verification transactions, and any other operations involving the card.

[0361] Various embodiments have been described in the foregoing description with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented without departing from the broader scope of the invention as set forth in the following claims. Therefore, the description and drawings should be considered illustrative rather than restrictive.< / puid> < / message> < / functiontos> < / nonce> < / functionrequest> < / nonce>

Claims

1. A transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server: receives a session creation request from a backend server for provisioning the contactless card, transmits a session creation response and a session token to the backend server, receives an authentication process function request from the backend server including encrypted data associated with the contactless card, decrypts the encrypted data to produce a decrypted authentication code, compares the decrypted authentication code to the expected authentication code, transmits a notification to the backend server indicating an unsuccessful authentication after an unsuccessful comparison, and transmits a session identifier and a funding primary account number associated with the session creation request after a successful comparison.

2. The transaction configuration system of claim 1, wherein, the authentication server: receives a request from the backend server for establishing a virtual card number (VCN) autofill program, receives an eligibility request from a token server associated with the contactless card, and transmits a notification to the token server indicating eligibility after determining that the contactless card is eligible.

3. The transaction configuration system of claim 1, wherein, the authentication function request further includes at least one selected from the group of the session identifier, a consent date, and a device identifier.

4. The transaction configuration system of claim 3, wherein, the authentication function request further includes a wallet identifier associated with a digital wallet.

5. The transaction configuration system of claim 3, wherein, the authentication function request includes one or more risk signals.

6. The transaction configuration system of claim 5, wherein, the one or more risk signals include at least one selected from the group of a device phone number, an email address, an account risk score, a device risk score, an internet protocol (IP) address, a device geographic location, an account-to-device binding identifier, and a device-to-account binding age.

7. The transaction configuration system of claim 6, wherein, the device phone number and the email address are hashed.

8. The transaction provisioning system of claim 1, wherein: the authentication process function request further includes one or more risk signals, and the one or more risk signals are generated by the backend server.

9. The transaction configuration system of claim 8, wherein, prior to transmitting the session identifier and the encrypted funding primary account number, the authentication server: evaluates the one or more risk signals, and transmits a notification to the backend server indicating a fraudulent transaction after determining that the authentication process function request is fraudulent based on the one or more risk signals.

10. The transaction configuration system of claim 8, wherein, the authentication server: evaluates the one or more risk signals, and determines that the authentication process function request is not fraudulent based on the one or more risk signals prior to transmitting the session identifier and the encrypted funding primary account number.

11. A transaction provisioning method performed by an authentication server, the authentication server comprising a processor and a memory, the method comprising: receiving a session creation request from a backend server for provisioning a contactless card; transmitting a session creation response and a session token to the backend server; receiving an authentication process function request from the backend server including encrypted data associated with the contactless card; decrypting the encrypted data to produce a decrypted authentication code; comparing the decrypted authentication code to an expected authentication code associated for the contactless card; after an unsuccessful comparison, transmitting a notification to the backend server indicating an unsuccessful authentication, and after a successful comparison, transmitting a session identifier and a primary account number associated with the session creation request.

12. The method of claim 11, wherein, the primary account number is encrypted prior to transmission.

13. The method of claim 11, wherein: the authentication process function request further includes one or more risk signals, and the one or more risk signals are generated by the backend server.

14. The method of claim 13, further comprising: prior to transmitting the session identifier and the encrypted primary account number: the one or more risk signals are evaluated; and after determining that the authentication process function request is fraudulent based on the one or more risk signals, transmitting a notification to the backend server indicating a fraudulent transaction.

15. The method of claim 13, further comprising: evaluating the one or more risk signals; and prior to transmitting the session identifier and the encrypted primary account number, determining that the authentication process function request is not fraudulent based on the one or more risk signals.

16. The method of claim 11, wherein, the authentication function request further includes at least one selected from the group of the session identifier, a consent date, and a device identifier.

17. The method of claim 11, wherein, the authentication function request further includes a wallet identifier associated with a digital wallet.

18. A non-transitory computer-readable medium containing instructions, wherein, the instructions, when executed by the processor, cause the processor to perform a process comprising: receiving, from a backend server, a session creation request for configuring a contactless card; transmitting, to the backend server, a session creation response and a session token; receiving, from the backend server, an authentication process function request including encrypted data associated with the contactless card; decrypting the encrypted data to produce a decrypted authentication code; comparing the decrypted authentication code to an expected authentication code associated for the contactless card; after an unsuccessful comparison, transmitting a notification to the backend server indicating an unsuccessful authentication, and after a successful comparison, transmitting a session identifier and a primary account number associated with the session creation request.

19. The non-transitory computer-readable medium of claim 18, the process further comprising: receiving, from the backend server, a request to establish a virtual card number (VCN) autofill program, receiving, from a token server, an eligibility request associated with the contactless card, and after determining that the contactless card is eligible, transmitting a notification to the token server indicating eligibility.

20. The non-transitory computer-readable medium of claim 18, wherein, the authentication function request further includes at least one selected from the group of the session identifier, a consent date, and a device identifier.

Images