Technology for providing secure cryptographic authentication, verification, feature access, and payment between contactless cards and communication devices

Abstract

A system and method for providing secure cryptographic authentication, verification, feature access, and payment between a contactless card and a communication device is provided. An exemplary communication device includes a system-on-chip, generates a communication field, prompts the communication device to tap the contactless card, reads the contactless card after entering the communication field, performs authentication of the contactless card, and executes a payment transaction after successful authentication of the contactless card.

Description

[Technical Field]

[0001] This application is a continuation-in-part of U.S. patent application Ser. No. 18 / 207,831, filed June 9, 2023, entitled "Techniques To Process Contactless Card Functions In A Multiple Banking Systems Environment," and claims priority to U.S. provisional patent application Ser. No. 63 / 437,979, filed January 9, 2023, entitled "Techniques To Provide Secure Cryptographic Authentication, Verification, Functionality Access, And Payments Between Contactless Cards And Communication Devices," the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] Contactless card products have become widespread and ubiquitous, fundamentally changing the way financial transactions are viewed and conducted in today's society. Contactless card products are most commonly represented by plastic or metal card-like components provided to customers through credit card issuers (e.g., banks and other financial institutions). Using the card, authorized customers or cardholders can purchase services and / or goods without the immediate, direct exchange of cash. Data security and transaction integrity are critical to the businesses and customers facilitating these transactions. This need continues to grow as electronic transactions conducted with contactless cards constitute an increasingly large share of commercial activity. Therefore, there is a need to provide businesses and users with appropriate solutions that overcome current shortcomings in providing contactless card data security, authentication, validation, access functionality, and payments.

[0003] In one aspect, the communication device includes a system on a chip (SoC), which generates a communication area, displays a prompt to tap a contactless card on the communication device, reads the contactless card after entering the communication area, performs contactless card authentication, and performs a payment transaction after successful contactless card authentication.

[0004] In one aspect, a method performed by a communication device including a system on a chip (SoC) includes generating a communication area, displaying a prompt on the communication device to tap a contactless card, reading the contactless card after entering the communication area, performing authentication of the contactless card, and performing a payment transaction after successful authentication of the contactless card.

[0005] In one aspect, a non-transitory computer-readable medium comprises instructions for execution by a communication device, which, when executed, cause the communication device to perform a procedure including generating a communication area, displaying a prompt on the communication device to tap a contactless card, reading the contactless card after entering the communication area, performing authentication of the contactless card, and performing a payment transaction after successful authentication of the contactless card. [Brief explanation of the drawings]

[0006] The various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in which:

[0007] [Figure 1] FIG. 1 shows data transmission according to an embodiment. [Figure 2] FIG. 2 illustrates data transmission according to an embodiment. [Figure 3] FIG. 3 shows a contactless card according to an embodiment. [Figure 4] FIG. 4 shows components of a contactless card according to an embodiment. [Figure 5]FIG. 5 shows a sequence flow according to the embodiment. [Figure 6] FIG. 6 shows a data structure according to an embodiment. [Figure 7] FIG. 7 is a diagram of a key system according to an embodiment. [Figure 8] FIG. 8 is a flowchart of a method for generating a cryptogram according to an embodiment. [Figure 9] FIG. 9 illustrates the process of key diversification according to an embodiment. [Figure 10] FIG. 10 illustrates a method for card validation according to an embodiment. [Figure 11] FIG. 11 illustrates a method for cryptographic authentication and function access for a contactless card according to an embodiment. [Figure 12] FIG. 12 illustrates a method for cryptographic authentication and function access for a contactless card according to an embodiment. [Figure 13] FIG. 13 illustrates a multi-issuer system according to an embodiment. [Figure 14A] FIG. 14A shows a system according to an embodiment. [Figure 14B] FIG. 14B shows a system according to an embodiment. [Figure 15] FIG. 15 shows a system according to an embodiment. [Figure 16] FIG. 16 shows a sequence flow according to the embodiment. [Figure 17A] FIG. 17A shows a sequence flow according to the embodiment. [Figure 17B] FIG. 17B shows a sequence flow according to the embodiment. [Figure 17C] FIG. 17C shows a sequence flow according to the embodiment. [Figure 18] FIG. 18 shows a flowchart of a method for key identification according to an embodiment. [Figure 19] FIG. 19 shows a flowchart of a method for key generation according to an embodiment. [Figure 20] FIG. 20 shows a flowchart of generating a cipher according to an embodiment. [Figure 21]FIG. 21 shows a flowchart of a method for encrypting a cipher according to an embodiment. [Figure 22] FIG. 22 shows a flowchart of a method for calculating a message authentication code according to an embodiment. [Figure 23] FIG. 23 shows a message according to the embodiment. [Figure 24] FIG. 24 shows a flowchart of a method for establishing a session and performing a function according to an embodiment. [Figure 25] FIG. 25 illustrates a distributed network authentication system according to an embodiment. [Figure 26] FIG. 26 shows a flowchart of a method performed by a distributed network authentication system according to an embodiment. [Figure 27] FIG. 27 illustrates a computer architecture according to an embodiment. [Figure 28] FIG. 28 illustrates a communication architecture according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] The following description of the embodiments provides non-limiting representative examples, using reference numerals to specifically describe the features and teachings of various aspects of the present invention. It should be recognized that the described embodiments can be implemented independently of the description of the embodiments or in combination with other embodiments. Those skilled in the art who review the description of the embodiments should be able to learn and understand various aspects of the present invention. The description of the embodiments is not specifically exhaustive, but should facilitate understanding of the present invention to the extent that other embodiments within the knowledge of those skilled in the art who read the description of the embodiments will be understood to be consistent with the application of the present invention.

[0009] Embodiments may generally be directed to enabling contactless card functionality in a multi-issuer computing environment. These functions may include tap-to functionality that allows a user to tap a contactless card to a device, such as a mobile device, to perform a function. For example, a user may utilize a contactless card to verify identity, make a payment, launch an application, log in to an application, auto-fill a form or field, navigate to a specific website or app on the device, unlock a door, activate the contactless card, etc.

[0010] The system described herein may enable users to perform these functions in a multi-issuer environment. Furthermore, the system described herein enables card issuers, such as banks, to issue contactless cards with tap-to functionality to their customers while maintaining a high level of security. The system described differs from past solutions because it provides a single platform for multiple issuers or banks that offer tap functionality. Traditionally, each issuer or bank was required to configure and maintain its own system to provide contactless card features. This included maintaining its own hardware, software, databases, security protocols, etc., which could be very expensive for the issuer or bank to maintain. However, the system described allows the issuer or bank to offload most of the processing, storage, and security functions to a neutral or central system. More specifically, the central system is configured to provide contactless card features to multiple issuers while maintaining a high level of security and data integrity. Each issuer's functionality and data can be independently managed and protected, with each individual issuer or bank having access to its own data or functionality. More particularly, these features may be provided by an exchange system configured to process and perform the functions of each contactless card in a secure manner. Additional benefits for issuers may include providing highly secure authentication options for the mobile web, which typically lacks the strong authentication options available in native applications.

[0011] Furthermore, embodiments described herein support tap-to mobile web experiences on both major mobile platforms (iOS®, Android®) by leveraging App Clips® with WebNFC® and a Javascript® SDK. For iOS®, embodiments include providing a Tap To software development kit (SDK) that includes functionality and services for performing the operations described herein on the iOS® platform. The SDK may be installed in a host application, such as a native app or a web browser app, including App Clips®. The SDK provides functionality support for near-field communication between a mobile device and a contactless card, installing native apps via App Clips®, and the ability to hide portions of data and / or display. As one example, the SDK may be configured to download and install apps from an app store, such as Apple's® App Store.

[0012] In an Android® operating system environment, embodiments include utilizing a Javascript SDK. The Javascript SDK may be installed on a website, for example, via the website's source code. The Javascript SDK also includes functionality to support NFC communication between a mobile device and a contactless card via WebNFC®. The Javascript SDK may also include functionality to provide customizable user interface (UI) functionality and obfuscation. In embodiments, the Javascript SDK supports websites that utilize Hypertext Transfer Protocol Secure (HTTPS) and supports the React® library. Embodiments are not limited in this manner, and any UI library may be supported.

[0013] The embodiments described herein disclose systems and methods for secure authentication, communication, verification, and payment between contactless cards and communication devices configured to communicate with the contactless cards. The communication devices may include, but are not limited to, client devices, point-of-sale (POS) terminals, kiosks, cash registers, automated teller machines (ATMs), access point devices, network-enabled computers, and mobile devices (such as smartphones). The communication devices can potentially interface with servers or other communication devices to authenticate contactless cards, communicate with contactless cards, verify user and / or contactless card information, conduct contactless card payment transactions, and access contactless card functionality.

[0014] In embodiments, the systems and methods described herein provide for authentication of a contactless card using a communication device. The communication device may create a communication field, e.g., a near-field communication (NFC) field, for communication with the contactless card and may be configured to prompt a user to tap, swipe, or hold the contactless card in proximity to the communication device. After receiving a tap, swipe, or hold gesture of the contactless card within the communication field, secure communication between the contactless card and the communication device may begin. Data exchange between the contactless card and the communication device can be used to authenticate the contactless card, further enabling the functionality and processing as described herein.

[0015] Contactless card authentication may be performed, for example, by systems and methods described herein. Once authenticated, the communications device may provide access to one or more additional features. This may include displaying one or more additional user interfaces and access to the additional features. In some examples, the additional user interface may process a payment transaction. In some examples, the additional user interface may request additional verification from the user. In some examples, the additional user interface may provide access to the additional features.

[0016] In embodiments, the communications device may operate using a combination of computer system components (e.g., a processor, memory for primary and secondary storage, input / output devices, and input / output interfaces) to perform the functions and processes described herein. In other examples, the communications device may operate using one or more systems-on-chip (SoCs) that include integrated circuits having one or more of the above-described components to perform the functions and processes described herein.

[0017] The systems and methods described herein provide several advantages. For example, the use of communications devices, such as communications devices utilizing one or more SoCs, allows the functions and processes described herein to be implemented across a wide range of devices. This can be accomplished while advantageously minimizing the need for hardware and software integration into the communications device.

[0018] As another example, to perform the functions and processes described herein, contactless card issuers need only provide information, including information used for authentication, when needed, which can reduce fees charged by card issuers or other organizations providing the data.

[0019] As another example, the functions and processes described herein may be performed by a communications device alone or in conjunction with one or more services or other communications devices. One or more servers or other communications entities may be provided and / or operated by a card issuing institution and / or other organizations involved in providing goods or services or processing transactions. Performance of some or all of the functions and processes described herein by a communications device may simplify these functions and processes by reducing the number of organizations that need to be involved. Additionally, performance of some or all of the functions and processes described herein by a communications device may better coordinate the functions and processes that need to be performed with a single tap, swipe, or presentation of a contactless card to the communications device.

[0020] As another example, the systems and methods described herein further verify a user to enable the provision of additional functionality, such as entertainment content, sports content, other media content, discounts, promotions, loyalty rewards, reward points, and / or other additional functionality for interacting with the user on the communication device. In some examples, these offers can be made prior to executing a payment transaction, so that the payment transaction (e.g., payment amount) can accurately reflect these offers.

[0021] All of the foregoing examples provide numerous advantages with respect to contactless card data security, authentication, verification, feature access, and payment. It is understood that these and further advantages may be achieved by combining one or more of the foregoing examples. It is further understood that example elements, features, and functions described herein are interchangeable and capable of being interchangeably combined.

[0022] To generally refer to the notation and nomenclature used herein, one or more portions of the detailed descriptions which follow may be presented in terms of program procedures executed on a computer or network of computers. 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. A procedure here, and generally, is conceived to be a self-consistent sequence of operations leading to a desired result. These operations are operations requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0023] Further, these operations are often referred to in terms commonly associated with mental activities performed by a human operator, such as adding or comparing. However, no such capability of a human operator is necessary, or desirable in most cases, for any of the operations forming part of one or more of the embodiments described herein. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program written and stored in accordance with the teachings herein, and / or specially constructed apparatus or digital computers for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for a variety of these machines will be apparent from the description provided herein.

[0024] 1 illustrates a data transmission system 100 according to an embodiment. As described further below, the system 100 may include a contactless card 102, a client device 104, a network 106, and a server 108. Although FIG. 1 illustrates a single instance of the components, the system 100 may include any number of components.

[0025] The system 100 may include one or more contactless cards 102, which are described further below. In some embodiments, the contactless cards 102 may communicate wirelessly with the client device 104, by way of example only, using NFC.

[0026] System 100 may include client device 104, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include a computing or communication device, including, but not limited to, a server, a network appliance, a personal computer (PC), a workstation, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, a contactless card, a point-of-sale (POS) terminal, a kiosk, a cash register, an automated teller machine (ATM), an access point device, or other device. Client device 104 may also be a mobile device, such as an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® Mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices.

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

[0028] In some examples, a client device 104 of system 100 may execute one or more applications, such as software applications that enable network communication with one or more components of system 100, to send and / or receive data.

[0029] The client device 104 may communicate with one or more servers via one or more networks 106 and may operate as a front-end and back-end pair with the server 108, respectively. The client device 104 may send one or more requests to the server 108, for example, from a mobile device application executing on the client device 104. The one or more requests may be associated with retrieving data from the server 108. The server 108 may receive one or more requests from the client device 104. Based on the one or more requests from the client device 104, the server 108 may be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 108 may be configured to transmit the received data to the client device 104, where the received data is responsive to the one or more requests.

[0030] The system 100 may include one or more networks 106. In some examples, the network 106 may be one or more wireless networks, wired networks, or a combination of wireless and wired networks, and may be configured to connect the client devices 104 to the server 108. For example, the network 106 may include one or more of an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, a network of the IEEE 802.11 family, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0031] Additionally, network 106 may include a global network such as, but not limited to, telephone lines, optical fiber, IEEE Ethernet 802.3, a wide area network, a wireless personal area network, a LAN, or the Internet. Additionally, network 106 may support an Internet network, a wireless communication network, a cellular network, or the like, or a combination thereof. Network 106 may further include one network operating as a standalone network or in conjunction with one another, or any number of the exemplary types of networks described above. Network 106 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 106 may also translate the protocol of one or more network devices to or from other protocols. Although network 106 is described as a single network, it should be understood that, according to one or more examples, network 106 may comprise multiple interconnected networks, such as, for example, the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0032] The system 100 may include one or more servers 108. In some examples, the server 108 may include one or more processors coupled with memory. The server 108 may be configured as a central system, server, or platform that controls and accesses various data at different times to perform multiple workflow operations. The server 108 may be configured to connect to one or more databases. The server 108 may be connected to at least one client device 104. The server 108 may be a dedicated server computer, a blade server, or any processor-controlled device capable of supporting the system 100, including a personal computer, a laptop computer, a notebook computer, a palmtop computer, a network computer, a mobile device, a wearable device, or a network-enabled computer.

[0033] FIG. 2 illustrates a data transmission system according to an embodiment. System 200 may have one or more servers 202 and may include a transmitting or transmitting device 204 and a receiving or receiving device 208, for example, in communication over a network 206. Transmitting device 204 may be equivalent to or similar to client device 104 described above with reference to FIG. 1. Receiving device 208 may be equivalent to or similar to client device 104 described above with reference to FIG. 1. Network 206 may be equivalent to or similar to network 115 described above with reference to FIG. 1. Server 202 may be equivalent to or similar to server 120 described above with reference to FIG. 1. Although FIG. 2 illustrates a single instance of components of system 200, system 200 may include any number of the illustrated components.

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

[0035] It is also important that the same key is not used too many times. If a key is used or reused too frequently, it can be compromised. Each time a key is used, it gives an attacker additional samples of data processed by cryptographic algorithms that use the same key. The more data an attacker has about how data is processed with the same key, the greater the chance that the attacker will discover the value of the key. Frequently used keys can be compromised by a variety of different attacks.

[0036] Furthermore, each time a symmetric encryption algorithm is executed, it can potentially leak information, such as side channel data, about the key used during the symmetric encryption operation. Side channel data may include minute power fluctuations that occur when the encryption algorithm executes while using the key. Enough side channel data can be measured to potentially leak enough information about the key to allow an attacker to decrypt it. Using the same key for data exchange can repeatedly leak data processed by the same key.

[0037] However, by limiting the number of times a particular key is used, one limits the amount of side-channel data an attacker can gather, thereby reducing exposure to this and other types of attacks. As further described herein, parties involved in an exchange of cryptographic information (e.g., sender and receiver) can independently generate keys from an initial shared master symmetric key in combination with a counter value, thereby periodically replacing the shared symmetric key used in situations requiring any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and receiver, the above-mentioned attack becomes impossible.

[0038] Returning to FIG. 2 , system 200 may be configured to implement key diversification. For example, a sender and a receiver may wish to exchange data (e.g., original confidential data) via their respective devices 204 and 208. As noted above, a single instance of a sending device 204 and a receiving device 208 may be included, but it is understood that more than one sending device 204 and more than one receiving device 208 may be involved, so long as each party shares the same shared secret symmetric key. In some examples, the sending device 204 and the receiving device 208 may be provisioned with the same master symmetric key. Furthermore, any party or device holding the same secret symmetric key may perform the functions of the sending device 204, and any similar party holding the same secret symmetric key may perform the functions of the receiving device 208. In some examples, the symmetric key may comprise a shared secret symmetric key that is kept secret from all parties other than the sending device 204 and the receiving device 208 involved in exchanging secure data. It is further understood that both the transmitting device 204 and the receiving device 208 may be provided with the same master symmetric key, and further 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 may be referred to as a counter value. The counter value may include a number that changes each time data is exchanged between the transmitting device 204 and the receiving device 208.

[0039] The system 200 may include one or more networks 206. In some examples, the network 206 may be one or more wireless networks, wired networks, or a 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 the server 202. For example, the network 206 may include one or more of an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network, a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, a network of the IEEE 802.11 family, Bluetooth, NFC, RFID, Wi-Fi, etc.

[0040] Additionally, network 206 may include a global network such as, but not limited to, telephone lines, optical fiber, IEEE Ethernet 802.3, a wide area network, a wireless personal area network, a LAN, or the Internet. Additionally, network 206 may support an Internet network, a wireless communication network, a cellular network, or the like, or a combination thereof. Network 206 may further include one network operating as a standalone network or in conjunction with one another, or any number of the exemplary types of networks described above. Network 206 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 206 may also translate the protocols of one or more network devices to or from other protocols. Although network 206 is described as a single network, according to one or more examples, it should be understood that network 206 may comprise multiple interconnected networks, such as, for example, the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

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

[0042] In block 210, when the sending device 204 prepares to process the sensitive data in a symmetric encryption operation, the sender may update a counter. Additionally, the sending device 204 may select an appropriate symmetric encryption algorithm, which may include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the diversification value may include a symmetric encryption algorithm used as needed to generate a diversified symmetric key of a desired length. 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 is understood that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as multiple iterations of the symmetric algorithm with different input data and the same master key may generate multiple outputs that can be combined as needed to generate a key of sufficient length.

[0043] In block 212, the sending device 204 may employ the selected encryption algorithm and may process the counter value using a master symmetric key. For example, the sender may select a symmetric encryption algorithm and may use a counter that updates with each interaction between the sending device 204 and the receiving device 208. The sending device 204 may encrypt the counter value with the selected symmetric encryption algorithm using the master symmetric key, generating a diversified symmetric key.

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

[0045] In block 214, the diversified symmetric key may be used to process the sensitive data before transmitting the results to the receiving device 208. For example, the sending device 204 may encrypt the sensitive data using a symmetric encryption algorithm that uses the diversified symmetric key, with the output including the protected encrypted data. The sending device 204 may transmit the protected encrypted data, along with the counter value, to the receiving device 208 for processing.

[0046] In block 216, the receiving device 208 may first take the counter value and then perform the same symmetric encryption using the counter value as the input to the encryption and the master symmetric key as the key for the encryption. The output of the encryption may be the same diversified symmetric key value generated by the sender.

[0047] In block 218, the receiving device 208 takes the protected encrypted data and uses a symmetric decryption algorithm in conjunction with the diversified symmetric key to decrypt the protected encrypted data.

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

[0049] The next time sensitive data needs to be transmitted from the sender to the receiver via the sending device 204 and the receiving device 208, respectively, a different counter value may be selected to generate a different diversified symmetric key. By processing the counter value with the master symmetric key and the same symmetric encryption algorithm, both the sending device 204 and the receiving device 208 may independently generate the same diversified symmetric key. This diversified symmetric key is used to protect the sensitive data instead of the master symmetric key.

[0050] As described above, both the transmitting device 204 and the receiving device 208 initially have a shared master symmetric key. The shared master symmetric key is used to encrypt the original secret data. The diversified symmetric key is generated independently by both the transmitting device 204 and the receiving device 208 and is therefore never transmitted between the two parties. Therefore, an attacker cannot obscure the diversified symmetric key, and the attacker cannot see any data processed with the master symmetric key. Only counter values ​​are processed with the master symmetric key, not the secret data. As a result, side-channel data reduction for the master symmetric key is revealed. Furthermore, the operation of the transmitting device 204 and the receiving device 208 may be governed by symmetric requirements for how frequently to generate a new diversification value, and therefore a new diversified symmetric key. In an embodiment, a new diversification value, and therefore a new diversified symmetric key, may be generated for each exchange between the transmitting device 204 and the receiving device 208.

[0051] In some examples, the key diversification value may include a counter value. Other non-limiting examples of key diversification values ​​include a random nonce generated each time a new diversified key is needed, a random nonce transmitted from the transmitting device 204 to the receiving device 208, a complete counter value transmitted from the transmitting device 204 and the receiving device 208, a portion of a counter value transmitted from the transmitting device 204 and the receiving device 208, a counter maintained independently by the transmitting device 204 and the receiving device 208 but not transmitted between the two devices, a one-time password exchanged between the transmitting device 204 and the 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 generate multiple diversified keys. For example, a counter may be used as a key diversification value. Additionally, a combination of one or more of the example key diversification values ​​described above may be used.

[0052] In another example, a portion of the counter may be used as a key diversification value. When multiple master key values ​​are shared between parties, multiple diversified key values ​​may be obtained by the systems and processes described herein. A new diversification value, and therefore a new diversified symmetric key, may be generated as frequently as necessary. In the most secure case, a new diversification value may be generated for each exchange of sensitive data between the sending device 204 and the receiving device 208. In effect, this can generate a single-use key, such as a single-use session key.

[0053] 3 illustrates an example configuration of a contactless card 102, which may include a payment card such as a contactless card, credit card, debit card, or gift card issued by a service provider, with the service provider's indicia 302 displayed on the front or back of the contactless card. In some examples, the contactless card 102 may be unrelated to payment cards and may include, but is not limited to, identification cards. In some examples, transaction cards may include dual interface, contactless payment cards, rewards cards, etc. The contactless card 102 may include a substrate 308, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 102 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may conform to the ISO / IEC 14443 standard, although it is understood that the contactless card 102 according to the present disclosure may have other characteristics and the present disclosure does not require a transaction card as implemented in a payment card.

[0054] The contactless card 102 may also include identification information 306 displayed on the front and / or back of the card, and a connection pad 304. The connection pad 304 may include one or more pads and may be configured to establish a connection with another client device, such as an ATM, a user device, a smartphone, a laptop, a desktop, or a tablet computer via a transaction card. The connection pad may be designed according to one or more standards, such as ISO / IEC 7816, and may be capable of communicating according to EMV protocols. The contactless card 102 may also include processing circuitry, an antenna, and other components, as further described in FIG. 4 . These components may be located behind the connection pad 304 or in other locations on the substrate 308, such as in another layer of the substrate 308, and may be electrically and physically associated with the connection pad 304. The contactless card 102 may also include a magnetic stripe or tape, which may be located on the back of the card (not shown in FIG. 3 ). The contactless card 102 may also include a near field communication (NFC) device coupled to an antenna capable of communicating via an NFC protocol, although embodiments are not limited in this respect.

[0055] 2, the connection pad 304 of the contactless card 102 may include processing circuitry 416, including a processor 402, memory 404, and one or more interfaces, for storing, processing, and communicating information. It is understood that the processing circuitry 416 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, as needed to perform the functions described herein.

[0056] The memory 404 may be read-only, write-once, or read / write memory, such as RAM, ROM, EEPROM, etc., and the contactless card 102 may include one or more of these memories. Read-only memory may be factory-programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once and read many times. Write-once memory may be programmed at a time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but may be read many times. Read / write memory may be programmed after leaving the factory and may be reprogrammed many times. Read / write memory may be read many times after leaving the factory. In some cases, the memory 404 may be encrypted memory, utilizing an encryption algorithm executed by the processor 402 to encrypt data.

[0057] The memory 404 may be configured to store one or more applets 408, one or more counters 410, one or more customer identifiers 414, and an account number 412, which may be a virtual account number. The one or more applets 408 may comprise one or more software applications configured to run one or more contactless cards, such as a Java Card applet. However, the applets 408 are not limited to Java Card applets and may instead be any software application capable of operating a contactless card or other device with limited memory. The one or more counters 410 may comprise a numeric counter sufficient to store an integer. The customer identifier 414 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 102, which identifier can 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 the customer, and may further identify the contactless card 102 associated with the customer's account. As described above, the account number 412 may include thousands of disposable virtual account numbers associated with the contactless card 102. The applet 408 of the contactless card 102 may be configured to manage the account number 412 (e.g., by selecting the account number 412, marking the selected account number 412 as used, and sending the account number 412 to the mobile device for auto-filling by an auto-fill service).

[0058] Although the processor 402 and memory elements of the foregoing exemplary embodiments have been described with reference to the connection pads 304, the present disclosure is not limited thereto. These elements may be implemented outside of, and entirely separate from, the connection pads 304, or may be implemented as additional elements in addition to the processor 402 and memory 404 elements located within the connection pads 304.

[0059] In some examples, the contactless card 102 may include one or more antennas 418. The one or more antennas 418 may be disposed within the contactless card 102 around the processing circuit 416 on the connection pad 304. For example, the one or more antennas 418 may be integrated into the processing circuit 416, or the one or more antennas 418 may be used in conjunction with an external booster coil. As another example, the one or more antennas 418 may be external to the connection pad 304 and the processing circuit 416.

[0060] In an embodiment, the coil of the contactless card 102 may act as the secondary of an air-core transformer. The terminal may communicate with the contactless card 102 by cut power or amplitude modulation. The contactless card 101 may infer data transmitted from the terminal using gaps in the contactless card's power connection, and functionality may be maintained via one or more capacitors. The contactless card 102 may detect load modulation in the terminal's coil through interference. More generally, using the antenna 418, processor 402, and / or memory 404, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0061] As described above, contactless card 102 may be built on a software platform capable of operating a smart card or other device with limited memory, such as JavaCard, and one or more applications or applets may be securely executed. Applet 408 may be added to contactless card 102 to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. Applet 408 may be configured to respond to one or more requests, such as a near-field exchange request, from a reader, such as a mobile NFC reader (e.g., a mobile device or point-of-sale terminal), and generate an NDEF message comprising the cryptographically secure OTP encoded as an NDEF text tag.

[0062] An example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 408 may be configured to encode the OTP as a text tag of known type NDEF Type 4. In some examples, an NDEF message may include one or more records. The applet 408 may be configured to add one or more static tag records in addition to the OTP record.

[0063] In some examples, one or more applets 408 may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data is presented that may indicate the authenticity of the contactless card. Based on the one or more applets 408, an NFC read of the tag may be processed, and the data may be transmitted to a server, such as a server in a banking system, where the data may be verified.

[0064] In some examples, the contactless card 102 and the server may contain certain data to ensure the card is properly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation occurs, the counter 410 may be configured to increment. In some examples, each time data from the contactless card 102 is read (e.g., by a mobile device), the counter 410 is sent to the server for validation to determine (as part of the validation) whether the counter 410 is equal to the server's counter.

[0065] One or more counters 410 may be configured to prevent replay attacks. For example, if a cryptogram is captured and replayed, it will be immediately rejected when the counter 410 is read, used, or passed on. If a counter 410 has not been used, it may be replayed. In some instances, the counter that increments on the card is different from the counter that increments with the transaction. The contactless card 101 cannot determine the application transaction counter 410 because there is no communication between the applet 408 on the contactless card 102 and the application transaction counter 410.

[0066] In some examples, counter 410 may be out of sync. In some examples, counter 410 may increment to account for accidental reads that initiate transactions, such as oblique reads, but the application does not process counter 410. In some examples, when mobile device 110 powers up, NFC may be enabled and device 110 may be configured to read available tags, but no action is taken in response to the read.

[0067] To synchronize the counter 410, an application, such as a background application, may be executed that is configured to detect when the mobile device 110 wakes up, synchronize with the banking system's server, indicate the reading that occurred upon detection, and advance the counter 104. In another example, hashed one-time passwords may be utilized, such that a range of synchronization deviations may be tolerated. For example, if within a threshold of 10, the counter 410 may be configured to advance. However, if within another threshold, such as 10 or 1000, a request may be processed through one or more applications to perform a resynchronization that requires the user to perform one or more taps, gestures, or other methods via the device. If the counter 410 increments in the proper order, the user's actions may be known.

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

[0069] During the contactless card 102 creation process, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include symmetric keys that may be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by hardware in the contactless card 102. Using a key diversification process, one or more keys may be derived from a master key based on uniquely identifiable information for each institution requesting a key.

[0070] In some examples, to overcome the drawback of the 3DES algorithm, which may be susceptible to vulnerabilities, a session key may be derived (such as a unique key per session), but instead of using a master key, a unique card-derived key and counter may be used as diversification data. For example, each time the contactless card 101 is used in operation, a different key may be used to generate the message authentication code (MAC) and perform the encryption. This results in three layers of encryption. The session key may be generated by one or more applets and derived using one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation) using an application transaction counter.

[0071] Furthermore, the increments for each card are unique and may be assigned by personalization or may be assigned algorithmically by identifying some information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some instances, the increments may also vary with successive reads, such that one card increments by 1, 3, 5, 2, 2, ... and so on. The specific order or algorithmic order may be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for replay attacks to generalize from a small set of card cases.

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

[0073] 5 is a timing diagram illustrating an example of a sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. Sequence flow 500 may include contactless card 102 and client device 104, which may include application 502 and processor 504.

[0074] At line 508, the application 502 communicates with the contactless card 102 (e.g., after bringing the contactless card 102 into proximity). The communication between the application 502 and the contactless card 102 may enable NFC data transfer between the application 502 and the contactless card 102 for contactless card 102 that is sufficiently close to a card reader (not shown) of the client device 104.

[0075] At line 506, after communication is established between the client device 104 and the contactless card 102, the contactless card 102 generates a message authentication code (MAC). In some examples, this may occur when the contactless card 102 is read by the application 502. In particular, this may occur when reading a Near Field Data Exchange (NDEF) tag, which may be generated according to an NFC data exchange format, such as an NFC reader. For example, a reader application, such as the application 502, may send a message, such as an applet selection message, along with the applet ID of the applet that generates the NDEF. After confirming the selection, a sequence of a select file message followed by a read file message may be sent. For example, the sequence may include "select function file," "read function file," and "select NDEF file." At this point, a counter value maintained by the contactless card 102 may be updated or incremented, followed by "read NDEF file." At this point, a message may be generated that includes a header and a shared secret. A session key may then be generated. A MAC cipher may be generated from the message and may include a header and a shared secret. The MAC cipher may then be concatenated with one or more blocks of random data, and the MAC cipher and random number (RND) may be encrypted with a session key. The cipher and header may then be concatenated, encoded as ASCII hexadecimal, and returned in an NDEF message (in response to a "read NDEF file" message).

[0076] In some examples, the MAC cryptogram may be transmitted as an nDEF tag, and in other examples, the MAC cryptogram may be included in a uniform resource indicator (e.g., a formatted string, etc.). In some examples, the application 502 may be configured to send a request to the contactless card 102, the request including instructions to generate the MAC cryptogram.

[0077] At line 510, contactless card 102 transmits the MAC code to application 502. In some examples, transmission of the MAC code occurs via NFC, although this disclosure is not limited in this respect. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 512, application 502 communicates the MAC code to processor 504.

[0078] At line 514, the processor 504 verifies the MAC ciphertext according to instructions from the application 122. For example, the MAC cipher may be verified as in the following example: In some examples, the verification of the MAC cipher may be performed by a device other than the client device 104, such as a server of a banking system in data communication with the client device 104. For example, the processor 504 may output the MAC cipher for transmission to a server of the banking system that can verify the MAC cipher. In some examples, the MAC cipher may serve as a digital signature for verification purposes. Other digital signature algorithms may be used to perform this verification, such as a digital signature algorithm and a public key symmetric algorithm such as the RSA algorithm.

[0079] FIG. 6 illustrates an NDEF short record layout (SR=1) data structure 600 according to an embodiment. One or more applets may be configured to encode the OTP as an NDEF Type 4 known type text tag. In some examples, an NDEF message may include one or more records. An applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to: tag type: known type, text, encoded English (en); applet ID: D2760000850101; function: read-only access; encoding: The authentication message may be encoded as ASCII hexadecimal. Type-Length-Value (TLV) data may be provided as personalization parameters that may be used to generate the NDEF message. In an embodiment, an authentication template may include a first record with a known index to provide the actual dynamic authentication data.

[0080] FIG. 7 shows a diagram of a system 700 configured to implement one or more embodiments of the present disclosure. As described below, during the contactless card generation process, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include symmetric keys that can be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm is used by EMV and is implemented by hardware in contactless cards. Using a key diversification process, one or more keys may be derived from a master key based on information that is uniformly identifiable to each institution requesting the keys.

[0081] With respect to master key management, two issuer master keys 702, 726 may be required for each portion of a portfolio to which one or more applets are issued. For example, the first master key 702 may include an issuer cryptographic generation / authentication key (Iss-Key-Auth), and the second master key 726 may include an issuer data encryption key (Iss-Key-DEK). As described further herein, the two issuer master keys 702, 726 are diversified into card master keys 708, 720 that are unique to each card. In some examples, the network profile record ID (pNPR) 522 and diversification key index (pDKI) 724 may be used as back-office data to identify the issuer master keys 702, 726 for use in cryptographic processing for authentication. The authentication system may be configured to obtain the values ​​of pNPR 722 and pDKI 724 for contactless cards at the time of authentication.

[0082] In some examples, to improve the security of the solution, a session key (e.g., a unique key per session) may be derived without using a master key, and a unique card-derived key and counter may be used as diversification data as described above. For example, a different key may be used to generate a message authentication code (MAC) and perform encryption each time the card is used in an operation. Regarding session key generation, the keys used to generate ciphers and encrypt data in one or more applets may include a session key based on a key unique to the card (Card Authentication Key (Card-Key-Auth) 708 and Card Data Encryption Key (Card-Key-Dek) 720). The session keys (Authentication Session Key (Auth-Session-Key) 732 and Data Encryption Session Key (DEK-Session-Key) 710) may be generated by one or more applets and derived by using the Application Transaction Counter (pATC) 704 with one or more algorithms. Only the lower two bytes of the four-byte pATC 704 are used to apply one or more algorithms to the data. In some examples, a 4-byte session key derivation method may include F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(four bytes)F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(four bytes)SK:={(AL(MK)[F1]||ALG(MK)[F2]}, where ALG may include 3DES ECB and MK may include a derived master key unique to the card.

[0083] As described herein, one or more MAC session keys may be derived using the lower two bytes of the pATC 704 counter. With each tap of the contactless card, the pATC 704 is configured to be updated, and the card master keys, i.e., card authentication key 508 and card data encryption key 720, are further diversified into session keys, i.e., authentication session key 732 and data encryption session key 710. The pATC 704 may be initialized to zero upon personalization or applet initialization. In some examples, the pATC counter 704 may be initialized at or before personalization and configured to increment by one with each NDEF read.

[0084] Additionally, the updates on each card may be unique and assigned by personalization, or may be assigned algorithmically by a pUID or other identifying information. For example, even-numbered cards may be incremented or decremented by 2, and odd-numbered cards may be incremented or decremented by 5. In some examples, the updates may vary with successive reads, such that one card increments 1, 3, 5, 2, 2, ... and so on. The specific order or algorithmic order may be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for replay attacks to generalize from a small set of card cases.

[0085] The authentication message may be delivered as the contents of a text NDEF record in hex-ASCII format. In some examples, it may contain only the authentication data and an 8-byte random number followed by a MAC of the authentication data. In some examples, the random number may precede the cipher A and be one block long. In other examples, there may be no limit on the length of the random number. In further examples, all of the data (i.e., the random number and cipher together) may be a multiple of the block size. In these examples, an additional 8-byte block may be appended to the block generated by the MAC algorithm. As another example, if the algorithm employed uses 16-byte blocks, multiples of that block size may also be used, or the output may be automatically or manually padded to a multiple of the block size.

[0086] The MAC may be performed with a function key (authentication session key) 732. The cryptographically specified data may be processed with ALG_DES_MAC8_ISO9797_1_M2_ALG3, which correlates to the javacard.signature method:EMV ARQC verification method. The key used in this calculation may include a session key, i.e., authentication session key 732, as described above. As described above, the lower two bytes of the counter may be used to diversify into one or more MAC session keys. As described above, the authentication session key 732 may be used to MAC data 706, and the resulting data or cipher A 714 and random number RND may be encrypted using data encryption 710 to generate cipher B or output 718, which is sent in the message.

[0087] In some examples, one or more HSM commands may be processed to decrypt such that the last 16 bytes (binary, 32 hex) may include 3DES symmetric encryption using a random zero IV and CBC mode followed by MAC authentication data. The key used in this encryption may include a data encryption session key 710 derived from a card data encryption key 720. In this case, the ATC value for session key derivation is the least significant byte of the counter pATC 704.

[0088] The following format shows an example embodiment of the binary version: Additionally, in some examples, the first byte may be set to ASCII 'A'. TIFF2026501787000002.tif140153 TIFF2026501787000003.tif182149

[0089] Another exemplary format is shown below: In this example, the tag may be encoded in hexadecimal format. TIFF2026501787000004.tif125136 TIFF2026501787000005.tif177148

[0090] The UID field of the received message may be expanded to derive a card master key (card authentication key 708 and card data encryption key 720) for the particular card from the master keys, i.e., issuer authentication key 502 and issuer data encryption key 726. Using the card master keys (card authentication key 508 and card data encryption key 720), the counter (pATC) field of the received message may be used to derive a session key (authentication session key 732 and data encryption session key 710) for the particular card. Cipher B 718 may be decrypted using cipher A 714 and the data encryption session key to generate RND, which may then be discarded. The UID field may be used to look up the contactless card's shared secret, which, along with the message's version (Ver), UID, and pATC field, may be processed through an encrypted MAC to generate a MAC output, such as MAC', using the regenerated authentication session key. If MAC' is the same as cipher A, this indicates that the message decryption and MAC checks all passed. The pATC may then be read to determine if it is valid.

[0091] During an authentication session, one or more ciphers may be generated by one or more applications. For example, the one or more ciphers may be generated as a 3DES MAC using method 2 of the ISO 9797-1 algorithm padding via one or more session keys, such as authentication session key 732. Input data 706 may take the following format: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the number in brackets may include a length in bytes. In some examples, the shared secret may be generated by one or more random number generators configured to ensure that the random number is unpredictable via one or more secure processes. In some examples, the shared secret may include a random 4-byte binary number injected into the card during personalization known by the authentication service. During an authentication session, the shared secret may not be provided to the mobile application by one or more applets. Method 2 padding may include adding a required 0x "80" byte to the end of the input data and optional 0x "00" bytes to the end of the result data up to an 8-byte boundary. The resulting cipher may contain an 8-byte length.

[0092] In some instances, one advantage of encrypting an unshared random number as the first block with a MAC cipher is that it acts as an initialization vector while using the CBC (blockchain) mode of a symmetric encryption algorithm. This allows for block-to-block "scrambling" without requiring the pre-establishment of either a fixed or dynamic IV.

[0093] By including an application transaction counter (pATC) as part of the data included in the MAC cipher, the authentication service may be configured to determine whether values ​​transmitted with the plaintext data have been tampered with. Furthermore, by including the version in one or more ciphers, it is difficult for an attacker to intentionally falsify the version of an application and weaken the strength of the encryption solution. In some examples, the pATC may start at zero and be incremented by one each time one or more applications generate authentication data. The authentication service may be configured to track the pATC used during an authentication session. In some examples, when authentication data uses a pATC that is equal to or less than a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and authentication may be denied. In some examples, when the pATC is greater than a previous received value, it may be evaluated to determine whether it is within an acceptable range or threshold; if it is beyond or outside that range or threshold, the verification may be deemed unsuccessful or unreliable. In MAC operation 712, data 706 is processed through a MAC and encrypted using the authentication session key 732 to generate a MAC output (cipher A) 714.

[0094] It is desirable for the MAC cipher 714 to be encrypted to provide additional protection against brute force attacks that expose the keys on the card. In some examples, the data or cipher A 714 included in the ciphertext may include a random number (8), cipher(8). In some examples, the number in brackets may include a length in bytes. In some examples, the random number may be generated by one or more random number generators configured to ensure that the random number is unpredictable through one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include a data encryption session key 710. In encryption operation 716, the data or cipher A 714 and RND are processed using the data encryption session key 510 to generate encrypted data, cipher B 718. The data 714 may be encrypted using 3DES in cipher block chaining mode to ensure that an attacker needs to perform an attack on all ciphertext. Other algorithms, such as the Advanced Encryption Standard (AES), may be used, by way of non-limiting example. In some instances, an initialization vector of 0x'0000000000000000' may be used. An attacker attempting to brute force decrypt the key used to encrypt this data will be unable to determine whether the correct key was used, as correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.

[0095] In order for the authentication service to verify one or more cryptographic elements provided by one or more applets, the following data must be transmitted in the clear from one or more applets to the mobile device during an authentication session: a version number to determine the cryptographic approach used and the message format for verifying the cryptographic element, allowing for future changes to the approach; a pUID to obtain the cryptographic asset and derive the card key; and a pATC to derive the session key used for the cryptographic element.

[0096] 8 illustrates a method 800 for generating a cryptogram. For example, in block 802, a Network Profile Record ID (pNPR) and a Derived Key Index (pDKI) may be used to identify which issuer master key to use in a cryptographic process for authentication. In some examples, the method may include performing authentication to obtain values ​​of pNPR and pDKI for a contactless card during authentication.

[0097] At block 804, the issuer master key may be diversified by binding it to a card unique ID number (pUID) and PAN sequence number (PSN) of one or more applets, for example, a payment applet.

[0098] In block 806, an authentication card key and a data encryption card key (unique card key) may be generated by diversifying the issuer master key to generate a session key that can be used to generate a MAC cipher.

[0099] In block 808, the keys used to generate ciphers and encrypt data in one or more applets may include session keys in block 1030 that are based on keys unique to the card (authentication card key and data encryption card key). In some examples, these session keys may be generated by one or more applets and derived using the pATC, resulting in an authentication session key and a data encryption session key.

[0100] 9 shows an example process 900 illustrating key diversification according to an embodiment. Initially, the sender and receiver may be provided with two different master keys. For example, the first master key may include a data encryption master key and the second master key may include a data integrity master key. The sender has a counter value that may be updated in block 902, and other data, such as protected data, that may be securely shared with the receiver.

[0101] In block 904, the counter value may be encrypted by the sender using a data encryption master key to generate a data encryption derived session key, and the counter value may also be encrypted by the sender using a 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 may be used during both encryptions.

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

[0103] The protected data is processed in a cryptographic MAC operation by the sender using a data integrity session key and a cryptographic MAC algorithm in block 906. The protected data, including the plaintext and the shared secret, may be used to generate a MAC using one of the session keys (the authentication session key).

[0104] The protected data may be encrypted by the sender using the data encryption derived session key in conjunction with a symmetric encryption algorithm in block 908. In some examples, the MACs are combined with equal amounts of random data, e.g., 8 bytes each, and encrypted using a second session key (the data encryption session key).

[0105] At block 910, the encrypted MAC is transmitted from the sender to the receiver along with sufficient information to identify additional secret information (eg, a shared secret, a master key, etc.) for verification of the encryption.

[0106] In block 912, the recipient uses the received counter value to independently derive two derived session keys from the two master keys, as described above.

[0107] In block 914, the data encryption-derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Additional processing occurs on the exchanged data. In some instances, after the MAC is extracted, it may be desirable to regenerate and match the MAC. For example, when verifying the encryption, it may be decrypted using a properly generated session key. The protected data may be reconstructed for verification. A MAC operation may be performed using a properly generated session key to determine if the decrypted MAC matches. When the MAC operation is an irreversible process, the only way to verify is to attempt to regenerate it from the source data.

[0108] At block 916, the data integrity derived session key is used in combination with a cryptographic MAC operation to verify that the protected data has not been altered.

[0109] In some examples of the methods described herein, successful authentication can be advantageously verified when it is determined whether the following conditions are met: First, the ability to verify the MAC indicates that the derived session key was correct. The MAC is likely correct only if decryption is successful and produces a correct MAC value. Successful decryption may indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Because the derived session key is generated using a master key known only to the sender (e.g., sending device) and receiver (e.g., receiving device), it can be trusted that the contactless card that originally generated and encrypted the MAC is indeed authentic. Furthermore, the counter values ​​used to derive the first and second session keys may be shown to be valid and may be used to perform authentication operations.

[0110] The two derived session keys may then be discarded, and the next iteration of the data exchange may update the counter value (returning to block 902) and generate a new set of session keys (at block 910). In some examples, the combined random data may be discarded.

[0111] 10 illustrates a method 800 for card activation according to an embodiment. For example, card activation may be accomplished by a card, a device, and one or more servers. The contactless card, the device, and the one or more servers may refer to the same or similar components as previously described, such as the contactless card 102, the client device 104, and the server.

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

[0113] At block 1004, one or more portions of the dynamically generated data may be communicated to an application on the device via NFC or other wireless communication. For example, tapping a card near the device may enable an application on the device to read one or more portions of data associated with the contactless card. In some examples, if the device does not include an application to support card activation, tapping the card may prompt the device to download an associated application for activating the card or may prompt the customer to navigate to a software application store. In some examples, the user may be asked to sufficiently gesture, place, or orient the card toward a surface of the device, e.g., on or near, adjacent to, at an angle, or flat on the surface of the device, etc. In response to sufficient gesture, placement, and / or orientation of the card, the device may proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0114] In block 1006, one or more portions of the data may be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data may be sent from the device to a card issuer server for card activation.

[0115] At block 1008, one or more servers may decrypt one or more encrypted portions of the data via the systems and methods described herein. For example, one or more servers may receive encrypted data from the device and decrypt the data to compare the received data with record data accessible to the one or more servers. If the one or more servers compare the one or more decrypted portions of the data and a match is successful, the card may be activated. If the one or more servers compare the one or more decrypted portions of the data and a match is unsuccessful, one or more actions may be taken. For example, in response to a failed 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 a user can make to activate the card. Alternatively, the user may receive a notification, such as a message on the device, indicating that the card authentication attempt has failed and to call, email, or text message an associated service for support in activating the card, or another notification, such as a phone call on the device, indicating that the card authentication attempt has failed and to call, email, or text message an associated service for support in activating the card, or another notification, such as an email on the device, indicating that the card authentication attempt has failed and to call, email, or text message an associated service for support in activating the card.

[0116] In block 1010, the one or more servers may send a reply message based on successful activation of the card. For example, the device may be configured to receive output from the one or more servers indicating successful activation of the card by the one or more servers. The device may be configured to display a message indicating successful activation of the card. Once the card is activated, the card may be configured to cease dynamically generating data to avoid fraudulent use. In this manner, the card may not subsequently be activated, and the one or more servers are notified that the card has already been activated.

[0117] 11 illustrates an exemplary method 1100 for contactless card cryptographic authentication and feature access. The exemplary embodiment of method 1100 may be performed by a communications device (e.g., a network-enabled computer) that interacts with the contactless card.

[0118] Method 1100 begins at block 1102, where a communication device may prompt a user to tap, swipe, or hold a contactless card near the communication device. The communication device may create a communication region to enable contactless communication with the contactless card. The communication region may enable NFC, Bluetooth, radio frequency identification (RFID), Wi-Fi, and / or another type of contactless communication.

[0119] In some examples, before requiring the user to tap, swipe, or swipe the contactless card, the communications device may prompt the user to check the contactless card to verify that it has the proper functionality for use in the systems and methods described herein. Such functionality may be indicated by a graphic, drawing, logo, mark, or other indicia on the card, or may be known to the user through the user's knowledge of the account associated with the contactless card. In other examples, the communications device does not display this prompt, and instead, once the contactless card is in communication range, a determination is made as to whether the contactless card has the proper functionality. If the contactless card does not have the proper functionality, method 1100 may proceed to another process for completing the payment transaction and / or for identification or verification.

[0120] Once the contactless card is within the communication range, secure communication may begin between the contactless card and the communication device in block 1104. The communication device may read the contactless card and obtain data, for example, by processes described herein. The data exchanged between the contactless card and the communication device may include data payload, cryptography, and / or other data described herein. The data exchanged between the contactless card and the communication device may be used to authenticate the contactless card, for example, by systems and methods described herein.

[0121] At block 1106, a notification signal that the contactless card has been read may be transmitted. The notification signal may include data obtained from the contactless card. In some examples, the communications device includes an SoC, and the SoC may receive the notification signal. In other examples, the communications device does not include an SoC, and the notification signal may be received by, for example, a processor. Receipt of the notification signal enables the SoC and / or processor to perform further functions and processing described herein.

[0122] The communications device may perform contactless card authentication at block 1108. The contactless card may be authenticated, for example, by the systems and methods described herein.

[0123] If the contactless card authentication is successful, method 1100 may proceed to block 1110. At block 1110, the communications device may display additional user interfaces. Example user interfaces may include user interfaces that request additional verification, user interfaces that display data, user interfaces for access point devices, and user interfaces that provide access to additional functionality.

[0124] At block 1112, the communications device may provide access to one or more additional features. As described herein, access to the one or more additional features may include, but is not limited to, entertainment content, sports content, other media content, discounts, promotions, loyalty rewards, reward points, and / or other additional features for interacting with a user at the communications device.

[0125] In block 1114, the communications device may perform the payment transaction. In some examples, the payment transaction may involve a contactless card, and / or another account associated with the contactless card, and / or a user associated with the contactless card. If necessary, the communications device may require a second tap, swipe, or waving of the contactless card over a communications area of ​​the communications device. In some examples, the payment transaction may include a Europay, Mastercard, and Visa (EMV) transaction. In examples where one or more additional features are accessed, the payment transaction may reflect this access.

[0126] Returning to block 1108, if contactless card authentication fails, the method 1100 may proceed to block 1116, and the communications device may perform the payment transaction as described herein.

[0127] As described herein, a communications device may display one or more user interfaces. Example user interfaces may include a user interface that solicits additional verification. Exemplary user interfaces that solicit additional verification may include, but are not limited to, a user interface that requests submission of login credentials (e.g., username, phone number, account number, password, one-time password, personal identification number (PIN)), a user interface that requests age verification (e.g., submission of driver's license), a user interface that requests address information, and a user interface that requests biometric information (e.g., face scan, fingerprint scan, retina scan, voice input).

[0128] Examples of user interfaces may include user interfaces that display data. Exemplary user interfaces that display data include, but are not limited to, a user interface that displays data about a user card account, such as a credit card, debit card, or gift card (e.g., account balance, transaction history, pending available funds, available credit), a user interface that displays data about a loyalty or rewards account (e.g., reward points balance, points redemption options, past points redemptions, loyalty status), a user interface that displays data about a merchant account, such as a goods provider or service provider (e.g., a retailer account, an online vendor account, a subscription service, an entertainment venue account, such as sports, movies, music, etc.), a user interface that displays data about a public service account, such as a credit card, debit card, or gift card account ... public service account, such as a credit card, debit card, or gift card account (e.g., account balance, transaction history, pending available funds, available credit), a user interface that displays data about a public service account, such as a credit card, debit card, or gift card account (e.g., account balance, transaction history, pending available funds, available credit), a user interface that displays data about a loyalty or rewards account (e.g., reward points balance, points redemption The user interfaces may include user interfaces that display data regarding joint accounts (e.g., electric utility accounts, water utility accounts, gas utility accounts), user interfaces that display data regarding financial accounts such as savings, checking, or brokerage accounts (e.g., account balances, deposits, withdrawals, transaction activity, pending transactions, payment due dates, bill payment activity), user interfaces that display data regarding travel accounts (e.g., tickets, schedules, upcoming reservations, past trips), and user interfaces that display data regarding access point accounts such as building access accounts, warehouse access accounts, and vehicle access accounts (e.g., access status, current permissions, access history, upcoming new access permissions, upcoming access permission expiration dates).

[0129] Example user interfaces may include user interfaces that provide access to additional functionality. Exemplary user interfaces that provide access to additional functionality may include, but are not limited to, user interfaces that display content, rewards, or other information. Exemplary user interfaces that display content may include, but are not limited to, user interfaces that display entertainment content (e.g., movies, music, music videos, television programs, comedy, plays (live or recorded)), sports content (e.g., professional sports games, college sports games, sports highlights (live or recorded)), and other media content (e.g., news programs, documentaries, quizzes). Exemplary user interfaces that provide access to rewards may include, but are not limited to, user interfaces that display rewards information (e.g., applying points to transactions, accumulating points for transactions), loyalty program information (e.g., loyalty program status, rewards point balance, frequent flyer mile balance, redemption options, past redemption history, loyalty status).

[0130] Exemplary user interfaces may include user interfaces for access point devices, including, but not limited to, user identification information, user input interfaces (e.g., entering login credentials, barcode scanning, quick response code scanning), biometric user interfaces (e.g., face scanning, fingerprint scanning, retina scanning, voice input), and photo input interfaces (e.g., taking an image or video of a user).

[0131] As described herein, the communications device may provide access to additional functionality, which may include access to accounts and the ability to conduct transactions using accounts, including, but not limited to, access to credit cards, debit cards, gift cards, loyalty or rewards accounts, merchant accounts such as product or service providers (e.g., retailer accounts, online vendor accounts, subscription services, entertainment venue accounts for sports, movies, music, etc.), utility accounts (e.g., utility accounts for electricity, water, gas, etc.), financial accounts such as savings, checking, brokerage accounts (e.g., account balances, deposits, withdrawals, transaction activity, pending transactions, payment due dates, bill payment activity, etc.), travel accounts (e.g., tickets, schedules, upcoming reservations, past trips, etc.), access point accounts (e.g., access status, current permissions, access history, upcoming new access permissions, upcoming access permission expiration dates, etc.), and combinations thereof.

[0132] Additional functionality may further include, but is not limited to, access to entertainment content (movies, music, music videos, television programs, comedy shows, plays, etc., live or recorded), sports content (professional sports games, college sports games, sports highlights, etc., live or recorded), other media content (news programs, documentaries, quizzes, etc.), rewards (applying reward points to transactions, earning reward points for transactions, etc.), loyalty program information (loyalty program status, reward point balance, frequent flyer miles balance, redemption options, past redemptions, loyalty status, etc.), discounts and / or promotions applicable to current, past, or future transactions, access to buildings, rooms, lockers, storage units, vehicles (cars, trucks, buses, ships, boats, planes, helicopters, etc.), and combinations thereof.

[0133] 12 illustrates an exemplary method 1200 for contactless card cryptographic authentication and feature access. The exemplary embodiment of method 1100 may be performed by a communication device (e.g., a network-enabled computer) and / or other device that interacts with the contactless card and backend.

[0134] Method 1200 begins at block 1202, where a communication may display a prompt to a user to tap, swipe, or hold a contactless card near a communication device. The communication device may generate a communication field that enables contactless communication with the contactless card. The communication field may enable NFC, Bluetooth, radio frequency identification (RFID), Wi-Fi, and / or another type of contactless communication.

[0135] In some examples, before requiring the user to tap, swipe, or swipe the contactless card, the communications device may prompt the user to check the contactless card to ensure it has the proper functionality for use in the systems and methods described herein. Such functionality may be indicated by a graphic, drawing, logo, mark, or other indicia on the card, or may be known to the user through the user's knowledge of the account associated with the contactless card. In other examples, the communications device may not display this prompt, and instead, once the contactless card is in communication range, a determination is made as to whether the contactless card has the proper functionality. If the contactless card does not have the proper functionality, method 1200 may proceed to another process for completing the payment transaction and / or for identification or verification.

[0136] Once the contactless card enters the communication range, secure communication between the contactless card and the communication device may begin in block 1204. The communication device may read the contactless card and obtain data, for example, by processes described herein. The data exchanged between the contactless card and the communication device may include a data payload, a cryptogram, and / or other data described herein. The data exchanged between the contactless card and the communication device may be used to authenticate the contactless card, for example, by systems and methods described herein.

[0137] At block 1206, a notification signal that the contactless card has been read may be transmitted. The notification signal may include data obtained from the contactless card. In some examples, the communications device includes an SoC, and the SoC may receive the notification signal. In other examples, the communications device does not include an SoC, and the notification signal may be received by, for example, a processor. Receipt of the notification signal enables the SoC and / or processor to perform further functions and processing described herein.

[0138] At block 1208, the communications device may transmit the data obtained from the contactless card to a backend. The backend may include, for example, one or more receiving devices and / or network-enabled computers, such as, for example, one or more servers in data communication with the communications device. The backend may determine where to route the data obtained from the contactless card for authentication. For example, the data may be sent to one or more receiving devices and / or network-enabled computers associated with a particular authority, such as an issuing authority and / or a verification authority, for authentication to be performed, and at block 1210, the data may be routed accordingly, as described herein.

[0139] At block 1212, one or more receiving devices and / or network-enabled computers that receive the data obtained from the contactless card can perform authentication of the contactless card. The contactless card can be authenticated, for example, by systems and methods described herein. At block 1214, the results of the contactless card authentication can be sent to a backend and returned to the communication device. Blocks 1208, 1210, 1212, and 1214 of method 1200 can be performed by systems and methods described herein.

[0140] If the contactless card authentication is successful, method 1200 may proceed to block 1216. At block 1216, the communications device may display additional user interfaces. Examples of user interfaces may include user interfaces that request additional verification, user interfaces that display data to the user, user interfaces of the access point device, and user interfaces that provide access to additional functionality.

[0141] At block 1218, the communications device may provide access to one or more additional features. As described herein, access to the one or more additional features may include, but is not limited to, entertainment content, sports content, other media content, discounts, promotions, loyalty rewards, reward points, and / or other additional features for interacting with a user at the communications device.

[0142] At block 1220, the communications device may perform a payment transaction. In some examples, the payment transaction may involve a contactless card, and / or another account associated with the contactless card, and / or a user associated with the contactless card. If necessary, the communications device may require a second tap, swipe, or waving of the contactless card over a communications area of ​​the communications device. In some examples, the payment transaction may include a Europay, Mastercard, and Visa (EMV) transaction. In examples where one or more additional features are accessed, the payment transaction may reflect this access.

[0143] Returning to block 1214, if contactless card authentication fails, the method 1200 may proceed to block 1222, and the communications device may perform the payment transaction as described herein.

[0144] 13 illustrates an example multi-issuer system 1300 configured to operate in accordance with embodiments described herein. System 1300 may include a computing system configured to enable functions performed with contactless cards, such as contactless card 1302 and encryption techniques described herein. These functions may include performing transactions and other functions, such as authenticating a user and tapping functions. Tapping functions may include tapping to auto-fill a field on a mobile device, tapping to launch an application on a mobile device, tapping to open a door, tapping to activate a card, and other tapping operations.

[0145] System 1300 illustrates a high-level configuration that enables multiple users to use contactless cards issued by one or more issuers to perform operations, including transactions with merchant systems. In the illustrated example, system 1300 includes several banking systems 1306a, retailer systems 1306b, other financial systems 1306c, and government systems 1306d. The transaction systems may be configured to perform transactions for users to purchase goods and services with the contactless cards. Additionally, these systems may be configured to provide customer verification services via the contactless cards. This is not a limiting example.

[0146] System 1300 may be configured to perform various actions for a customer, an issuing bank, a merchant, etc. These actions may be initiated by a customer using contactless card 1302 to exchange information between contactless card 1302 and other systems in system 1300. Depending on the action being performed, such as a tap to launch an application, a tap to auto-fill text, a tap to authenticate, a tap to make a transaction, etc., data may be routed and sent to various systems in system 1300 to perform the respective action.

[0147] For example, the contactless card 1302 may initiate a transaction with one of the merchant systems when tapped to another device, such as a mobile device 1304, which may be configured to further communicate with one of the other systems, such as a hosted service. These services may include, but are not limited to, a verification service and a commerce service. The other services may be configured to perform operations that allow the customer to perform any number of tap functions.

[0148] As will be described in more detail, the mobile device 1304 may communicate data from the contactless card 1302 to another system, such as one or more services 110 configured to provide transaction services and other operations. The data may be routed to a particular service 110 by the exchange system 1308 in a secure, encrypted manner, as described herein. In an embodiment, the data may be provided in encryption.

[0149] To provide services in a multi-issuer environment, system 1300 includes an exchange system 1308, or hub system, configured to communicate data between systems (such as banks, retailers, other financial institutions, and governments) and the back-end processing services of participating banks. The exchange system 1308 enables any number of banks and different financial institutions to issue contactless cards with transaction capabilities, validation capabilities, and the like, and to perform operations seamlessly while maintaining a high level of security for sensitive data. As will be described in more detail, the exchange system 1308 enables mobile devices, merchant systems, and central communication systems to communicate with data from many issuing banks to conduct transactions and other functions.

[0150] For example, a customer may attempt to execute a transaction for goods or services (retailer system 1306b). The customer may initiate the transaction via a mobile device or interaction with a point-of-sale (POS) terminal. The device or terminal can send a message for the transaction to the exchange system 1308, which can further determine how to process the message and complete the transaction. The message may include encrypted and unencrypted portions. The encrypted portion may contain sensitive data that can be used by the issuing bank system function to process the transaction, and the unencrypted portion may contain data that can be used by the exchange system 1308 to route the message and data to the correct issuing bank system function via services such as application programming interfaces and merchant services. The exchange system 1308 may communicate with the mobile device 1304 and then the merchant backend system (106) to first validate the contactless card and user, establish a commerce session between the mobile device, the merchant service, and the merchant system, and enable the transaction to be executed in a secure manner.

[0151] In embodiments, the exchange system 1308 may include management services that may be utilized to onboard card issuers, verifiers, and merchants to the system to provide contactless card services. In one example, the exchange system may onboard issuers / verifiers by generating unique identifiers to identify the issuers / verifiers and storing a mapping between the unique identifiers and the issuers / verifiers in a data store, such as a verification HSM. The unique identifiers may also be provided to the issuer system so that the issuer may provide each contactless card with a unique identifier for provision during transactions and other operations.

[0152] Any number of banks or financial institutions may offer several services 110 or functionality that can be utilized by customers, merchants, and banks to process transactions and provide services 110, including validating customers and their contactless cards. These services may include validation services and commerce services. These services may be hosted on a central platform, such as a cloud-based system, and each bank may have its own services. Furthermore, each bank's services 110 may be hosted on the same central platform, and the exchange system 1308 may determine which bank's services 110 to invoke via an API based on information in the message.

[0153] In embodiments, system 1300 may also perform deployment operations to deploy merchants and merchant systems operating in the exchange system 1308 environment. In embodiments, deploying a merchant may include generating a unique identifier associated with the merchant and providing the unique identifier to the merchant, such as issuing a merchant certificate. System 1300 may also enable the merchant and issuer to exchange data, such as key pairs, for securely performing operations without exposing sensitive data to exchange system 1308. System 1300 may also enable the merchant to configure and set up one or more deployments, such as configuring data domains to support the merchant's use cases.

[0154] System 1300 may also perform onboarding operations for card issuers. For example, system 1300 may enable a bank or card issuer to generate a unique identifier, such as an Issuer ID, that can be used to uniquely identify the issuer when performing validation and other functions. System 1300 may also enable a bank or issuer to generate and / or distribute key pairs with merchants and other service providers. These and other details are provided in the description below.

[0155] 14A and 14B illustrate an example of a system 1400 configured according to embodiments described herein. In some examples, system 1400 may provide a more detailed view of system 1300 and its components. The illustrated system 1400 includes one or more systems for processing transactions, performing validation functions, and supporting other functionality for contactless cards issued in a multi-issuer environment. In an embodiment, system 1400 includes one or more issuer systems 1402, a personalization system 1404, one or more merchant systems 1406, and an exchange system 2808. The exchange system 2808 may include additional systems for providing functionality to the multiple issuer systems; these systems may include a hub network and a validation system.

[0156] These systems may be configured with hardware and software elements to perform the functions described herein. For example, each system may be configured with one or more servers, processors, memory, storage, network hardware, input / output devices, etc. to process instructions according to embodiments. Furthermore, each system may support and implement several application programming interfaces (APIs) that allow interoperability between each system while maintaining a high level of security.

[0157] In an embodiment, system 1400 includes at least one issuer system 1402. Issuer system 1402 may have several components and provide functionality for issuing contactless cards to customers, authenticating customers, conducting transactions, and enabling other contactless card tap operations. In one example, issuer system 1402 includes functionality for issuing cards, including processing network contactless card requests, maintaining a system of record (SoR), and providing service offerings.

[0158] In one example, the issuer system 1402 may generate card unique identifiers (pUIDs), each of which may be associated with the cardholder and contactless card when issued. The pUIDs may be used as part of the verification process, and the issuer system 1402 may store the pUIDs in a database associated with the cardholder, for example. The pUIDs may be written to the System of Record and provided to the personalization system 1404 for physically generating and issuing the contactless cards. In some examples, the pUIDs may be communicated to the personalization system 1404 in a batch or batch file. For example, the issuer system 1402 may include a process for generating batches of pUIDs and functionality for communicating the batches, such as embossed file batches, to the personalization system 1404. The personalization system 1404 may configure, physically generate, and issue the contactless cards, as described in more detail below.

[0159] In some examples, issuer system 1402 may provide additional functionality. In some examples, issuer system 1402 may maintain at least some functionality to perform verification operations for customers once a contactless card is issued. For example, issuer system 1402 may include functionality and APIs that a device, such as a mobile device running issuer mobile app 1410, uses to verify information initially received from a contactless card. The device may communicate data from the contactless card to issuer system 1402 via one or more APIs, such as an API provided by MFA service 1414, and issuer system 1402 may verify the information based on information stored in a database. Issuer system 1402 may return the results to the device.

[0160] In other examples, the issuer system 1402 may delegate the verification operation to the exchange system 1430. In these examples, the issuer system 1402 may also receive data from the contactless card via a device, such as a mobile device, and through an API. The issuer system 1402 may then transmit the data to the exchange system 1430, which may perform the verification operation. In either case, the issuer system 1402 may return a verification result to the device. The device, such as a mobile device, may use the result as part of a verification request, such as accessing a mobile app, as part of a multi-factor authentication operation, or to enable another function.

[0161] In embodiments, system 1400 includes a personalization system 1404 for performing actions on contactless cards to issue contactless cards to customers. For example, personalization system 1404 may obtain and / or generate data that can be copied to each contactless card for each customer. The data may be unique to each customer and may include information such as account number, customer name, expiration date, card verification value (CVV), etc. In embodiments, personalization system 1404 may store the data in secure memory, such as a hardware security module (HSM) on the contactless card. The data may be provided to issuer system 1402 and / or exchange system 1430 so that contactless card actions, such as verification, authentication, tapping, etc., can be performed.

[0162] The personalization system 1404 may also generate a unique key for each contactless card. Each contactless card may have a unique pair of keys that can be further used to generate a derived key used to perform cryptographic operations on data for communicating the data in a secure manner. Each card's unique key may be based on and / or associated with the issuer bank, for example, via a bank identification number (BIN). Additionally, the issuer system 1402 and / or the exchange system 1430 may have a set of unique keys for each card that can be used to perform verification operations by being able to generate the same derived key for decrypting data received from the contactless card during a verification or transaction process.

[0163] The personalization system 1404 may also install one or more applets on the card. The applets may be used to perform various functions, including performing cryptographic operations and generating messages and codes containing data for performing card validation and transactions. In some examples, the personalization system 1404 installs applets to perform functions and may include an applet version number. System versioning may be required so that other systems can operate accordingly. The system version determines the applet version and validation logic embedded on the card by the personalization system 1404. For example, a first-party system may operate under version 0100, while a central system using the app may operate under another version, such as version 0200, which simplifies implementation and enables authentication networks. JavaCard and MultOS implementations of the applet may share the same version number.

[0164] The personalization system 1404 may also include additional applets that perform additional functions. For example, each card may include an applet configured to communicate with other devices via wired and / or wireless communication. In some examples, communication may be based on the Europay, Mastercard, and Visa (EMV) standards, the ISO / IEC 7816 standard for contactless cards, and the ISO / IEC 14443 standard for contactless cards.

[0165] System 1400 further includes an exchange system 1430 that can provide multiple banks or issuers with the ability to perform contactless card tap operations, such as verification, transactions, etc., while maintaining a high level of data security and separation between each issuer's data. For example, exchange system 1430 provides a set of functions and APIs configured to provide services to multiple issuers to perform verification, transactions, and other contactless card operations. In some examples, exchange system 1430 may be maintained and provided by a central system owned and operated by an institution separate from any card issuer.

[0166] In an embodiment, the exchange system 1430 may include several components, including an exchange system 1430 and a verification system 1432. The exchange system 1430 may include a set of hub services 1416, such as a routing service, a workflow service, an administration service, an authentication service, a usage service, an analytics service, and a hub management service 1418.

[0167] In embodiments, the exchange system 1430 and services are configured to allow multiple issuers to work together. For example, the exchange system 1430 is configured to route messages and data from devices and contactless cards to issuers of cards corresponding to the service. For example, Bank A issues contactless cards and provides Service A, and the exchange system 1430 is configured to process messages and data from contactless cards issued by Bank A to Service A. In embodiments, the exchange system 1430 may use information in the messages and data to determine where to send the messages and data.

[0168] The exchanger system 1430 and services also enable the merchant system 1406 to process transactions for multiple and different issuers. For example, the exchanger system 1430 may include an API that can be used by a merchant backend to obtain PII and a VCN associated with a cardholder performing a transaction. The exchanger system 1430 may also include an API configured to initiate a session, such as a transaction session, and provide a verification token to a merchant app on a mobile device based on a contactless card running on the mobile device.

[0169] The exchange system 1430 may also include validation functions and validation APIs, such as validation service 1420, for performing validation operations, and commerce services 1422, which include functions and APIs for performing transaction services. The exchange system 1430 may include a message validation service 1424 configured to communicate with validation functions / APIs for providing cryptographic validation services 1426. The cryptographic validation service 1426 includes a tap algorithm and is connected to a validation HSM 1428 for performing validation operations. Each API is described in more detail below.

[0170] In embodiments, system 1400 includes several systems that provide contactless card-based features and services. At least some of these services may be performed by a contactless card and another device, such as a mobile device. More specifically, the mobile device may execute one or more apps that may be configured to operate with the features and APIs provided by system 1400. In one example, the one or more apps may be developed using a software development kit that includes instructions and functions that operate with the features and APIs. The mobile apps may include issuer mobile apps 1410, such as a banking app and merchant mobile app 1412. However, embodiments are not limited in this regard, and other applications, such as web browsers, mini- or micro-apps (e.g., App Clips), operating systems, and the like, may be configured to operate and utilize the features provided by system 1400.

[0171] 15 illustrates an example of a system 1500 according to embodiments described herein. System 1500 includes additional devices and systems configured to enable tap-to-play card services for contactless card issuers. Specifically, system 1500 enables any number of issuer systems to provide card services to clients via a switching fabric, i.e., exchange system, in a secure manner.

[0172] In an embodiment, the exchange system includes one or more nodes 1504 configured to perform routing operations. Each exchange node 1504 includes a session and nonce generator 1506, message routers 1508, 1510, an operational data 1512 store, and a metrics store 1514. Furthermore, although each node may be similarly configured and share configuration, each exchange node 1504 may independently process and route messages and requests to appropriate systems, such as merchant systems and issuer systems. Each node 1504 is configured to act as a trusted intermediary, for example, between issuer systems, merchant systems 1522, and / or verification systems 1524. Each exchange node 1504 is configured to route each message to the correct issuer system while maintaining data security. For example, the exchange node 1504 may route messages between issuer systems and merchant systems while preventing the node from accessing sensitive data within the messages.

[0173] The exchange system may be configured as a server system including a collection of hardware, software, and network components that work together to provide services to clients. The hardware components may include one or more computers, storage devices, and network adapters. The server computers are configured to run server applications, such as applications executable on each node 1504. In some examples, each server computer may be configured to operate one or more nodes, such as in a virtual environment. The storage devices are configured to store data accessed by the applications, and the network adapters are used to connect the server computers to a network.

[0174] Each server computer may be configured to run software including an operating system, applications, and security software. 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 connections and attacks.

[0175] In some embodiments, the nodes 1504 may operate in a cloud-based computing environment, e.g., a collection of hardware, software, and network components that enable the provision of cloud computing services. The exchange nodes 1504 and computing services may be provided over the Internet and accessed from anywhere in the world with an Internet connection. In embodiments, clients 1536 may access the exchange nodes 1504 through the Domain Name System 1502 or Domain Name System (DNS). The DNS 1502 is a hierarchical and decentralized naming system for computers, services, and other resources connected to the Internet or other networks. It associates various information with domain names assigned to each registered participant. In one example, the DNS 1502 may translate known names to software running on the clients 1536 to route data to one or more exchange nodes 1504 in the exchange system. In embodiments, the DNS 1502 may generate numbers, such as Internet Protocol (IP) addresses, address records (A records), or alternative host names (C-name records). 16 shows an example sequence 1600 for a client to identify and resolve an identifier for one of the nodes 1504 in the exchange system. Broadly speaking, the Domain Name System 1502 translates well-known domain names into the numeric Internet Protocol (IP) addresses needed to locate and identify computer services and devices in underlying network protocols. The client uses the global DNS system to select the best node to use, as illustrated in sequence 1600.

[0176] In an embodiment, the client 1536 communicates with the exchange system to perform one or more partner services 1532, such as conducting transactions with merchants, verifying customers, or performing other tap functions. Once the client 1536 identifies the exchange node 1504 and resolves an address for communicating with the exchange node 1504, the client 1536 may send one or more messages to the exchange node 1504 to authenticate and perform operations. The exchange node 1504 includes an authentication 1510 function configured to authenticate the client 1536. In an embodiment, the client 1536 sends a message or authentication request to the exchange node 1504 with the following header set: X-Sb-Api-Key:<Client API Key> X-Sb-Dvc-Fngrprnt: Device-specific device fingerprint

[0177] The client API key may have the following example structure: 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum, with values, names, and meanings described in Table 1.

[0178] [Table 1]

[0179] The exchange node 1504 may authorize or authenticate clients 1536 or users, and the exchange node 1504 may utilize additional components, such as a session and nonce generator 206 and a message router 208, to perform its operations. Note that the verifier's verification system 224 does not interact with the merchant system 222, and vice versa. The node 204 mediates all communications.

[0180] In an embodiment, the exchange system utilizes Hyperledger Fabric 1520 to manage synchronization of shared operational data 1512 and member management over the network. Hyperledger Fabric 1520 is assigned a ledger framework with a permissioned network model where only authorized participants can connect to the network and access data stored in the ledger.

[0181] In embodiments, a Hyperledger Fabric 1520 may be created by creating a set of one or more peers, an ordering service, and channels. Once the network is created, the system 1500 deploys chaincode to the network or nodes 1504 that are authorized to access the fabric. Chaincode is code that runs on the blockchain and implements the logic of network control 1526 and operational data 1512. Once the chaincode is deployed, each of the exchange nodes 1504 is configured to invoke transactions on the blockchain to add data, such as operational data, to the blockchain. The exchange nodes 1504 or another device can query the ledger to retrieve the data. The ledger is a dedicated database that stores all data being added to the blockchain.

[0182] All nodes 1504 keep a log of independently verifiable operations that can be sent to a centralized aggregator to build a picture of network-wide usage. At a central level, the system 1500 can manage network operational data and management status and have a centralized view of network usage, which can be aggregated and abstracted to appropriate levels.

[0183] 16 shows an example sequence 1600 of a client utilizing DNS to resolve and communicate with one or more nodes of a switch system. The sequence 1600 shown includes a client 1536, a DNS 1502, and a switch node 1504. At 1602, the sequence 1602 includes the client 1536 sending a request for the text record "swichboard.{domain}.{tld}" to a default DNS server. The text record may be pre-configured in the client app and / or client SDK. At 1604, the DNS 1502 returns one or more records. The DNS record structure may include: Root Record: ·Name:swichboard.{domain}.{tld} Type: TXT Resolution: ·{nodename_1}.{operator_a}.{region_i}.switchboard.{domain}.{tld}, ·{nodename_2}.{operator_a}.{region_i}.switchboard.{domain}.{tld}, ·{nodename_1}.{operator_b}.{region_ii}.switchboard.{domain}.{tld}, ·{nodename_2}.{operator_b}.{region_ii}.switchboard.{domain}.{tld}, * etc. ·Used For determining where there are active nodes Node Record: ·Name:{nodename}.{operator}.{region}swichboard.{domain}.{tld} Type: A / AAAA or CNAME ·Resolution:Actual node hostname or IP ·Used For:Communicating with a node 1504

[0184] In an embodiment, the client 1536 may determine the current time zone at 1606. For example, the client app or SDK may use a function to get the current time zone, such as JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone. This embodiment is not limited thereto, and the app or SDK may determine the time zone through another / different function call. At 1608, the client 1536 is configured to map the time zone to an identifier for a region or a shortened version of a region. One example includes America / New_York -> na-e. The region may be based on a DNS name, for example. Table 2 shows an example of a mapping between time zones and regions.

[0185] [Table 2]

[0186] Embodiments are not limited to these examples, and other time zone and region mappings may be used. Furthermore, in embodiments, regions may be represented as a bidirectional graph structure with edges representing geographical adjacencies. For example, na-e <-> na-w,sa <-> na-w,sa <-> na-e. This representation is useful for node selection.

[0187] At 1610, the client may identify or select the DNS record option returned at 1604 by region. If there are multiple matches, the client may randomly select one. If no node is available in the region, the client may determine and use the data graph of neighboring regions to select a node in the closest region where a node is available, at 1612. For example, even if there is no node in sa, there is a node connected to na-e, and na-e is selected. In some embodiments,

[0188] At 1614, the client may resolve the hostname of the selected node. In an embodiment, the client 1536 may automatically resolve the hostname using a default resolver in the client's HTTP request. At 1616, the domain name system 1502 may return the results. At 1618, the client 1536 may communicate with the exchange node 1504 and begin processing to interact with the exchange.

[0189] 17A-17C illustrate an exemplary sequence 1700 for performing operations between a contactless card and services provided by a card issuer and / or merchant. The illustrated sequence 1700 includes operations and communications performed by the contactless card 102, the client 1536 including a client app 1790 and a client sdk 1792, the DNS 1786, the exchange system including one or more exchange nodes 1504, the partner services 1532 including merchants and / or verifiers 1788, and the control service 1534 including the client server 1784 or system. In an embodiment, the client app 1790 may be any application configured to run on the client 1536, such as a banking app, a merchant app, a social media app, a travel app, a gaming app, a productivity app, an entertainment app, etc. In an embodiment, the client app 1790 includes a web browser that serves websites and pages. The client apps 1790 may include and / or utilize a client sdk 1792, which may be a set of instructions that enables the client apps 1790 to communicate with other components of the exchange system.

[0190] In an embodiment, at 1702, a client 1536 including a client app may send a request and establish a session with a client server 1784 so that results can be associated with the correct client device or user. The request establishes a connection between the client device and the client server, which may be an issuer server. At 1704, the client server 1784 generates a session and client session information. At 1706, the client server 1784 returns session information, such as client session information. In an embodiment, the client session information may be client implementation-specific user session identification information.

[0191] At 1708, the client 1536 may initiate a contactless card authentication process at the client 1536. For example, the client 1536 may invoke a function and / or pass information to the client 1536 to initiate authentication via a contactless card. At 1710-1714, the client 1536 may utilize DNS to identify a node and establish communication with the node. Specifically, at 1710, the client 1536 including the client sdk 1792 may send a request for a switch hostname, and at 1712, the DNS 1786 may return information including one or more hostnames. At 1714, the client 1536 may determine a switch node to communicate with. FIG. 16 shows an example of a more detailed sequence of a process for establishing communication with a switch node.

[0192] At 1716, the client 1536 may send a session request to the exchange system 108. In embodiments, the session request may be a function request in the form of <FUNCTION REQUEST>. In embodiments, the function request may be data / function that the client wants to request once the contactless card is validated. The function may be any service described herein, such as authenticating a user, performing a transaction, requesting auto-fill data, etc. At 418, the exchange system 108 may generate a nonce and a signed session token. The signed session token may be a JSON Web Token (JWT). When the JWT is generated, the following elements should be set: iss: unique ID of the current node nonce: 8 hexadecimal characters, randomly generated nonce exp: expiry timestamp (+5 minutes) client_id: The client ID of the requesting client sub: The fingerprint of the requesting client's device sid: Any session information sent by the client Scope: The function that is requested to be performed

[0193] A nonce may be a unique random byte generated to ensure the non-reproducibility of messages carried by a contactless card. The nonce is critical to the security and operation of the exchange system. The validity of the nonce is tracked by binding it to a session, which can be verified by any member of the platform. As described, a session is a JSON Web token signed using a node-specific private key issued by the network. These JWTs can be verified by the system with the corresponding public key by verifying that they were issued by the principal or an authorized agent. A signed session token is a JWT-generated token that establishes the validity and expiration date of the nonce and associates a contactless card tap with the current client session. For example, a signed session token includes a <NONCE>, a <CLIENT SESSION INFO>, and a <FUNCTION REQUEST> signed with a <NODE PRIVATE KEY>, where the node private key is the private key of the exchange system 108. The exchange system 108 may include a node public / private key pair that is used to sign and verify JWTs.

[0194] At 1720, the exchange system 108 may return the session information to the client 1536. The session information may include a signed session token (<SIGNED SESSION TOKEN> ), nonce <nonce>, Terms of Use<FUNCTION TOS> , and Terms of Use Version<TOS VERSION> The feature terms of use may be terms of use that the user must agree to in order to allow the client to perform the requested function, and the terms of use version may be a version of the terms of use. At 422, the client sdk 236 may determine and / or receive the user's agreement to the terms of use. In one example, the client sdk 236 obtains and records the user's agreement to the <feature terms of use> at <CONSENT DATE> along with the <TERMS OF USE VERSION>. The agreement date may be a timestamp of the user's agreement to the terms of use.

[0195] At 1724, the client 1536 exchanges one or more messages with the contactless card. In one example, the exchange may be based on the contactless card being tapped to the client device. In an embodiment, the client sdk 236 may provide data to the contactless card for use during the session to perform functions. The data may be provided to the 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 a nonce to provide a level of security that messages received from the card are 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 an example of an NDEF message format.

[0196] [Table 3]

[0197] In an embodiment, an updated MAC may be calculated to protect the control indicator. As illustrated in flow 2200 of Figure 22, the MAC M is determined by calculating a 10-byte MAC of the update data U with the update MAC card key (MCK).

[0198] At 1724, the contactless card may generate and provide a message to a client device including client sdk 1536. The data in the message may be utilized by the systems described herein to perform the requested function. One example of a message is shown and described as message 2300 in FIG. 23.

[0199] At 1726, a client including client sdk 1536 may send a message and information to the exchange system 108. The message may be, for example, a message received from a contactless card, such as message 2300. In addition, client sdk 1536 may send the agreement date, terms of use version, and a signed session token to the exchange system 108. The exchange system 108 may use the information to ensure the session is valid. At 1728, the exchange system 108 verifies that the signed session token is valid, e.g., that it contains a previously generated nonce, which is a previously provided signed session token, and is in the message.

[0200] In some embodiments, the exchange system 108 is configured to determine to which issuer system or client server the message should be routed for processing. At 1730, the exchange system 108 may determine the issuer ID by extracting it from the message received from the contactless card via the client SDK. As described, the issuer ID identifies the issuer of the contactless card 102.

[0201] In an embodiment, the exchange system 108 is configured to generate and communicate secure communications with issuer systems, such as client server 1784 and verifier 1788. At 1732, the exchange system 108 sends a request for a key to the client server 1784. The key may be used to perform the secure communications. In one example, the key request may be an Elliptic Curve Diffie-Hellman (ECDH) key request. Embodiments are not limited thereto, and alternative key protocols may be used, such as Supersingular Homogeneous Mapping Diffie-Hellman Key Exchange (SIDH or SIKE), Private / Public Key Pairing (RSA), etc.

[0202] At 1734, the client server 1784 generates part of the key. In some examples, the client server 1784 may generate half of the ECDH key for encryption / decryption of PII. Specifically, the client server 1784 may generate a <CLIENT EC PUBLIC KEY> and a <CLIENT EC PRIVATE KEY> using the elliptic curve P256. The client EC public key and the client EC private key are the first half of the ECDH key negotiation.

[0203] At 1736, the client server 1784 saves the generated portions of the keys in storage. Specifically, the client server 1784 may save the <CLIENT EC PUBLIC KEY> and <CLIENT EC PRIVATE KEY> with a <KEY ID>, which the client server uses to identify portions of the ECDH keys, e.g., to generate the entire ECDH key, so that the client server can cache the ephemeral EC public / private keys for later completion of the ECDH key. In one example, the keys may be stored in a secure memory location and may be used when PII is received for the session.

[0204] In an embodiment, the client server 1784 may return the public key portion along with the key ID to the exchange system 108 at 1738. The exchange system 108 may store the public key portion along with the key ID for later use, for example, for generating ECDH keys. At 1740, the exchange system 108 may request verification to be performed by the verifier 1788. In one example, the exchange system 108 may send the request verification as follows: request verification <message>, <signed session token>, <client EC public key>, <agreement date>, and <terms of use version>. The verifier 488 makes an out-of-band request for a public key to the exchange system 108 to verify the session at 442. At 444, the exchange system 108 may provide the node's public key, i.e., <NODE PUBLIC KEY>. Further, at 446, 488 may use the node's public key to verify the secure session token.

[0205] In embodiments, verifier 1788 may verify the message at 1748. In embodiments, verifier 1788 may perform several verifications, including ensuring that the nonce in the message is correct along with additional information, such as the card's unique identifier (pUID) and counter value (pATC), etc. In embodiments, verifier 1788 may perform other methods of verification as described herein.

[0206] At 1750, the verifier 1788 may store information associated with the session. For example, the verifier 1788 may store the <Terms of Use Version> and <puid>The verifier 1788 may also generate other key portions, such as ECDH keys. For example, 1788 may generate the <issuer EC public key> and the <issuer EC private key> using the elliptic curve P256. The issuer EC public key and the issuer EC private key may be the second half of the ECDH key negotiation.

[0207] At 1754, the verifier 1788 may generate a complete ECDH key. For example, the verifier 1788 may generate a complete ECDH key from <issuer EC private key> and <client EC public key>.<ECDHキー> The ECDH key is the final key generated using ECDH key negotiation.

[0208] The verifier 1788 may utilize an ECDH key to encrypt data for the function. For example, in some instances, when the verifier 1788 verifies a message, the verifier 1788 may perform a function request in 456 to generate a result of the function and encrypt the result with an ECDH key. For example, the verifier 488 may perform a <function request> to generate a <function result>,<ECDHキー> The result of the function may be any result based on the requested function, such as verifying the card.

[0209] At 1758, the verifier 1788 may return the result of the function to the exchange system 108. In some examples, the result of the function is returned encrypted. For example, the verifier 1788 may return <encrypted result of function> and <issuer EC public key>.

[0210] In an embodiment, the exchange system 108 sends the result of the function to the client server 1784 for processing. For example, the exchange system 108 may send <encrypted function result>, <key ID>, <issuer EC public key>, and <signed session token>. At 1762 and 1764, the client server 1784 may make a request to the exchange system 108 and receive the public key from the exchange system 108. In some examples, the exchange may be performed over an out-of-band communication channel. The public key for the node may be <node public key>. The public key may be used to verify the sender of the function result, etc. At 1766, 1784 may verify the signed session key with the node's public key <node public key> to verify the sender of the information. At 1768, the client server 1784 may extract the client information from the signed session token. For example, the client server 1784 may extract the <client session information> from the <signed session token>, that is, extract the client implementation-specific user session identification information.

[0211] Additionally, at 1770, the client server 1784 may obtain the client private key using the key ID. Specifically, the client server 1784 may obtain and remove the <client private key> from the cache using the <key ID>. At 1772, the client server 1784 may generate or calculate an ECDH key. For example, the client server 1784 may generate or calculate an ECDH key using the <client public key> + <issuer EC public key>.<ECDHキー> The client server 1784 may then decrypt the result of the function with the calculated key in 1774. Specifically, the client server 1784 may compute<ECDHキー> At 1776, the client server 1784 associates the session with the result of the function.

[0212] In an embodiment, the exchange system 108 may return the result of the function, whether it completed successfully or not, to the client sdk 1792 at 1792. Further, the client sdk 1792 may notify the client app 1790 of the result at 1780. The client app 1790 may utilize the feature at 1782. For example, the client app 1790 may communicate with the client server 1784 to continue the feature using the <client session information> to obtain the edited <function result>.

[0213] 18 shows a flow 1800 of example operations for identifying an issuer master key and generating a unique card master key or application key. In some examples, these operations may be performed off-card during personalization and then stored in the card's memory. Additionally, the issuer master key may be utilized to generate a card master key. The card master key may be known as an application key or UDK. Each contactless card may have one or more UDKs.

[0214] In embodiments, each contactless card includes one or more applications, such as an authentication application, and is given a unique 16-digit identifier (pUID) at the time of personalization. Each contactless card may also receive an application key, which may be known as a unique card key (UDK) or card master key using the pUID. In some examples, these operations are performed off-card, and the resulting key is populated during personalization. However, in other examples, one or more of these operations may be performed on the card, such as at the time of manufacture, each time an operation is performed on the key, etc.

[0215] At 1802, an embodiment includes a system configured to generate several issuer master key sets and assign each a unique 3-byte pKey identifier (pKey ID). As described, the system described herein can support many card issuers, and each card issuer may have its own set of one or more unique issuer master keys, which may be identified by a pKey ID. For each application, e.g., an authentication application, the system may perform the operations described in blocks 1804 through 1814.

[0216] At block 1804, the system assigns a pKey ID to the card or pUID, a unique hexadecimal digital identifier for the card application. At block 1806, the system begins generating a UDK for the card. At block 1808, the system generates a 16-digit quantity (X) from the 16-digit pUID. In one example, the 16-digit X may be generated by randomly rearranging the 16-digit pUID. In another example, X may be the same as the 16-digit pUID. Embodiments are not limited in this regard, and other techniques may be used to generate X from the 16-digit pUID. In embodiments, the 16-digit quantity X may be used to generate one or more UDKs.

[0217] In block 1810, the system calculates or computes (ZL) by encrypting X with the issuer master key. An encryption algorithm such as DES or a DES variant may be utilized in embodiments. Embodiments are not limited in this respect; other example encryption algorithms include public key algorithms such as AES or (RSA).

[0218] At block 1812, the system calculates or computes ZR by XORing X with FFFFFFFFFFFFFFFF and encrypting the result with the issuer master key. Again, an encryption algorithm such as DES, AES, RSA, etc. may be used to encrypt the XOR result. At block 1814, the system generates the application key or UDK. Specifically, the system concatenates ZL with ZR to create the application key. Embodiments are not limited to concatenating the two parts (ZL and ZR); they may be combined using other techniques. Additionally, the above process may be performed any number of times to generate additional application keys, for example, by using different master issuer keys.

[0219] 19 illustrates a first flow 1900 for generating a unique encrypted session key (ASK) and a second flow 1908 for generating a unique encrypted session key (DESK), according to an embodiment. The operations described in flow 1900 and flow 1908 may be performed on a contactless card.

[0220] In 1902, a contactless card including circuitry computes SKL by encrypting [ATC[2]||ATC[3]||'F0'||'00'||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]]] with an application key, such as the key generated in flow 1800. Further, in block 1904, the contactless card computes SKR by encrypting [ATC[2]||ATC[3]||'0F'||'00'||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]]] with the application key. Finally, in block 1906, the contactless card concatenates SKL to SKR to create an authentication session key (ASK). In an embodiment, the ASK is used to perform operations utilizing the contactless card, such as encrypting an encrypted MAC.

[0221] Also, in an embodiment, the card applet supports session key diversification to generate a unique encryption session key DESK, as shown in flow 1908. In block 1910, the contactless card including the circuitry calculates SKL by encrypting [ATC[2]||ATC[3]||'F0'||'00'||'00'||'00'||'00'||'00'] with a data encryption key (DEK). Further, in block 1912, the contactless card calculates SKR by encrypting [ATC[2]||ATC[3]||'0F'||'00'||'00'||'00'||'00'||'00'] with the data encryption key. In 1914, the contactless card concatenates SKL to SKR to produce a data encryption session key.

[0222] Figure 20 shows an example flow 2000 that may be performed by a contactless card or circuitry thereon to generate a cryptogram for performing the operations described herein, for example, as seen in Figure 23. The cryptogram C is determined by computing a MAC over 32 bytes of transaction data using an authentication session key (ASK). Flow 1900 of Figure 19 shows and explains generating an ASK according to embodiments described herein.

[0223] In block 1802, the contactless card including the circuit calculates T = [pVersion (2 bytes) || pIssuerID (3 bytes) || pKeyID (3 bytes) || pUID (8 bytes) || pATC (4 bytes) || nonce (4 bytes) || pSHSEC (4 bytes) || '80' || '00 00 00']. In one example, pVersion is an applet version number, pIssuer is an issuer identifier, pKeyID includes data identifying a set of card issuer master keys for the contactless card, pUID is a card unique identifier assigned to the contactless card, pATC is a card counter value, nonce is a nonce provided while communicating with another device as described herein, and pSHSEC is a value indicating compliance with a Secure Hardware Security Evaluation Criteria.

[0224] The contactless card may process the data to generate a cryptogram. In block 1804, the contactless card divides T into four blocks of 8-byte data: T = T1||T2||T3||T4. In 1806, the contactless card calculates B = DES(ASKL)[T1], where ASKL is a portion of ASK, e.g., the "left" half of the key, based on the Data Encryption Standard or other symmetric encryption algorithm. In block 1808, the contactless card calculates B = [B XOR T2], and in block 1810, the contactless card calculates B = DES(ASKL)[B], where DES is the encryption algorithm. In block 1812, the contactless card calculates B = [B XOR T3], and in block 1814, the contactless card calculates B = DES(ASKL)[B]. In block 1816, the contactless card calculates B=[B XOR T4], and in block 1818, the contactless card calculates B=DES(ASKL)[B]. In block 1820, the contactless card calculates B=DES -1 Calculate (ASKR)[B], where DES -1 is the reciprocal operation of DES, and ASKR is a portion of ASK, for example the right half. In block 422, the contactless card computes the cipher C=DES(ASKL)[B].

[0225] In embodiments, the contactless card may encrypt the cipher to further protect the data. Figure 21 shows an example flow 2100 for encrypting the cipher with a Data Encryption Session Key (DESK) (Figure 19, flow 1908) that is used to encrypt in Cipher Block Chaining mode (CBC).

[0226] In block 2102, a contactless card including circuitry is configured to generate an 8-byte random number [RND]. In block 2104, the contactless card calculates E1 = DES3(DESK)[RND], where DES3 is a symmetric encryption algorithm such as the Triple Data Encryption Standard. In block 2106, the contactless card calculates B = [E1] XOR [C], where C is the cipher generated in flow 2000. In block 2108, the contactless card calculates E2 = DES3(DESK)[B], where B was calculated in flow 2000 of FIG. 20 above. In block 2110, the contactless card generates a 16-byte encrypted payload E = [E1] || [E2].

[0227] In an embodiment, the device or contactless card decrypts payload E according to flow 2120. In block 2112, the device determines or obtains payload E. In block 2114, the device determines or obtains payload E according to flow 2120. -1 (DESK)[E1]. In block 2116, the device calculates B=DES3 -1 (DESK)[E2] and in block 2118 the device calculates C=[E1]XOR[B].

[0228] 22 shows an example flow 2200 for calculating a message authentication code (MAC). The operation of flow 2200 is by circuitry in the contactless card. In some examples, the MAC may be an updated MAC. In embodiments, the updated MAC is included in data communicated from the contactless card 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 an NDEF message.

[0229] In an embodiment, the updated MAC may be calculated to protect the control indicator and may include the updated date / time. For example, the updated MAC M may be determined by calculating a 10-byte MAC of the updated data U with the updated MAC card key (MCK) as follows:

[0230] At block 2202, an embodiment includes determining data to process through some calculations. In one example, data U is equal to [control indicator (2 bytes)||modified time (8 bytes)||'80'||'00 00 00 00 00']. For the calculations, the data may be divided into two separate portions. Specifically, at block 2204, data U is divided into two blocks of 8-byte data, U=U1||U2. Further, operations may be performed on U1 and U2.

[0231] At block 2206, an embodiment includes applying an algorithm to the first portion (U1) of the data. In one example, a result B may be calculated as B=DES(MCKL)[U1], where DES is a Data Encryption Standard algorithm using the first portion (L) of the MAC card key (MCKL).

[0232] At block 2208, additional operations may be performed on result B. Specifically, result B may be exclusive ORed (XORed) with a second portion of data (U2).

[0233] The updated result B may be further processed in block 2210. For example, result B may be further processed by applying the DES algorithm, again using MCKL, to B. Result B from block 2210 may be further processed in block 2212. Specifically, result B may be processed with the second part (R) of the MCK (MCKR) by the inverse of the DES. In block 2214, a MAC M may be determined by applying the DES algorithm, again using MCKL, to result B from block 2212.

[0234] 23 shows an example of a message 2300 that may be communicated by a contactless card to perform the functions described herein. One or more fields in the message 2300 may be utilized to route the message 2300 through a switching system and to perform authentication / verification techniques.

[0235] In an embodiment, message 2300 includes a field for applet version 2302, a field for issuer optional indicator 2304, a field for issuer identifier 2306, a field for pKey ID 2308, a field for pUID 2310, a field for pATC 2312, a field for nonce 2314, and an encrypted cipher 2316.

[0236] In embodiments, the fields may be plaintext or encrypted. For example, the applet version 2302 field may contain a plaintext applet version. The applet version, which indicates the applet version installed on the contactless card, may be used by other systems to determine how to handle the message 2300 when communicated. For example, different applet versions require different validation logic, e.g., older messages may be routed through an issuer system to perform various operations for validation, while new messages may be routed through an exchange system to perform various operations, including validation.

[0237] In an embodiment, message 2300 includes a field for issuer optional indicator 2304, which includes issuer data and may be set during personalization. Additionally, message 2300 includes a field for issuer identifier 2306, which may include a unique ID assigned to an institution issuing a card, such as an issuer. For example, each issuer ID may be used by exchange system 1508 to route the message and its contents to the appropriate service associated with the particular issuer.

[0238] In an embodiment, message 2300 includes a pKeyID 2308 field. In some examples, the pKeyID 2308 field may include data identifying a set of master keys for the card issuer. The issuer's set of master keys may utilize a respective card's set of derived master keys or unique derived keys (UDKs). Additionally, the respective card's set of master keys (UDKs) may be generated during card personalization. The card's UDK may be used to generate a session key used to generate application cryptography. The session key generated by the card may be regenerated by a system, such as a verifier system, which uses pKeyID to identify the issuer master key for regenerating the session key by the system to perform verification.

[0239] In an embodiment, each contactless card 1502 is given a unique 16-digit identifier (pUID) at the time of personalization. The derivation of the card applet's unique key using the pUID is performed off-card. The resulting application key is populated during card personalization. In an 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 described in flow 1800 of FIG. 18.

[0240] The message 2300 may include a pUID 2310 field that contains the card's unique identifier assigned to the contactless card at the time of personalization. The pUID 2310 field data may be an alphanumeric combination used to uniquely identify each card and associated with a user.

[0241] In an embodiment, message 2300 includes a pATC 2312 field configured to hold a counter value. The counter value, in one example, holds the number of reads (taps) made on the contactless card in hexadecimal format. Additionally, the counter value may be used to generate a session key for encrypting at least a portion of the message.

[0242] In an embodiment, each time a message 2300 is generated, a new session key is derived and used to generate one or more portions of the message 2300. Specifically, the session key is used to calculate a cryptographic MAC (application cipher). The applet on the card supports a session key derivation option to generate a unique cryptographic session key (ASK) as described in flow 1900 of FIG. 19 and a unique cryptographic session key (DESK) as described in flow 1908. The generation of the cipher is described in flow 600 and flow 2100. Furthermore, the cipher may be decrypted by flow block 2108.

[0243] In embodiments, some of the data provided in message 2300 is static and is set on the card during card personalization, while other data is dynamic and may be generated by the card during operation, for example when a read operation is performed. Note that in some instances, the static information may be updateable but may require the customer and the card to perform a secure update process that may be controlled by the issuer.

[0244] In embodiments, contactless card 1502 may communicate messages between devices, such as mobile devices, during a read operation. For example, in response to contactless card 1502 being tapped against the surface of a device, e.g., held within wireless communication range, a read operation may be performed on contactless card 1502, and contactless card 1502 may generate and provide a message to the device. For example, upon coming within range, contactless card 1502 and the device may perform one or more exchanges with contactless card 1502 to send a message to the device. Step 424 of FIG. 4A illustrates one example of an exchange.

[0245] The wireless communication may follow a wireless protocol such as near field communication (NFC), Bluetooth, WiFi, etc. In some examples, messages may be communicated between the contactless card 1502 and the device via wired means such as the connection pad 304 and according to the EMV protocol.

[0246] 24 illustrates an example routine 2400 according to embodiments described herein. At block 2402, the routine 2400 includes receiving a request from a client device to establish a session for performing a function performed at least in part by a node in the system utilizing a contactless card. In some examples, the node may be one of multiple nodes in an exchange system. The node may have been previously selected by the sending device via a DNS operation performed.

[0247] At block 2404, the routine 2400 includes generating, by the node, session information comprising a nonce and a signed session token corresponding to a session for performing the function. The nonce and / or signed session token may be utilized by the system to perform the functions described herein while ensuring that nodes routing data are authenticated, that messages from contactless cards are authenticated, and to keep track of sessions for the functions.

[0248] At block 2406, the routine 2400 includes sending, by the node, session information to the client device. The client device may communicate with the contactless card to receive data from the card to authenticate and perform functions. In some examples, the client device may send a nonce from the node to the contactless card. The contactless card may utilize the nonce when generating a message to send back to the client device, and ultimately, the node may incorporate the nonce into an encrypted portion of the message, for example (see FIG. 23).

[0249] At block 2408, the routine 2400 includes receiving, by the node, a message from the contactless card via the client device. The message may be generated by the contactless card. FIG. 23 shows an example of a message 2300. In some embodiments, the node verifies the message. For example, the node may verify the nonce in the message and the signed session token.

[0250] At block 2410, the routine 2400 extracts, by the node, from the message an issuer identifier associated with the issuer of the contactless card. In some examples, the issuer identifier may be in clear text form.

[0251] At block 2412, the routine 2400 identifies, by the node, a device associated with the issuer identifier. For example, the node may perform a lookup to determine a server associated with the issuer identifier and the function to be performed.

[0252] At block 2414, the routine 2400 communicates with the device to securely perform the function by the node.

[0253] Figure 25 illustrates a distributed network authentication system 1100 according to an example embodiment. As described further below, the system 1100 may include a client node 2502, an API 2504, a network 2506, a distributed ledger node 2510, a mapping 2512, and a client device 2514. Figure 25 illustrates just example components, but the system 1100 may include any number of components.

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

[0255] In some examples, the client node 2502 may execute one or more applications, such as software applications, that enable network communication with one or more components of the system 1100, transmit and / or receive data, and perform the functions and processes described herein.

[0256] The client node may include an API 2504. For example, a variety of different APIs may be provided to applications (e.g., running on a computing device such as a network-enabled computer) that can interact with the service. For example, an application running on a device (such as a smartphone, smartwatch, tablet, laptop, or other device) may interact with a web-based service by calling the API 2504 to interact with the service, such as by making a remote call to an API to interact with the web-based service.

[0257] The API 2504 may be provided in the form of a library containing specifications of routines, data structures, object classes, and variables. In some cases, for example, for a representational state transfer (REST) ​​service, an API (e.g., a REST API or RESTful API, or an API that embodies some RESTful practices) is a specification of remote calls exposed to an API consumer (e.g., an application running on a client computing device can be a consumer of the REST API by making remote calls to the REST API). A REST service generally refers to a software architecture for coordinating components, connectors, and / or other elements within a distributed system (such as a distributed hypermedia system).

[0258] Client node 2502 can communicate with one or more other components of system 1100, either directly or via network 2506. Network 2506 can comprise one or more wireless networks, wired networks, or any combination of wireless and wired networks, and can be configured to connect the components of system 1100. While Figure 25 shows communication between components of system 1100 via network 2506, it will be understood that any component of system 1100 can communicate directly with another component of system 1100, for example, without involving network 2506.

[0259] The system 1100 includes a validation node 2508, which may be a network-enabled computer as described herein. In some examples, the validation node 2508 may be a server, which may be a dedicated server computer, a blade server, or a personal computer, which may be a laptop computer, a notebook computer, a palmtop computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1100.

[0260] In some examples, the validator node 2508 may execute one or more applications, such as software applications, that enable network communication with one or more components of the system 1100, transmit and / or receive data, and perform the functions and processes described herein.

[0261] In some examples, each validator node can be associated with a routing number that identifies the organization that controls the keys in the authentication namespace. The authentication namespace can be associated with one or more particular organizations, a particular set of cards, or a particular set of security keys (e.g., master keys, diversification keys, session keys) associated with an organization, set of cards, or type of card.

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

[0263] In some examples, the distributed ledger node 2510 may execute one or more applications, such as software applications, that enable network communication with one or more components of the system 1100, transmit and / or receive data, and perform the functions and processes described herein.

[0264] The distributed ledger node 2510 may include a mapping 2512. In some examples, the mapping 2512 may be in the form of one or more databases. Exemplary databases may include, but are not limited to, a relational database, a non-relational database, a hierarchical database, an object-oriented database, a network database, and combinations thereof. The one or more databases may be centralized or distributed. The one or more databases may be hosted internally by any component of the system 1100, or the one or more databases may be hosted externally to any component of the system 1100. In some examples, the one or more databases may be included in the distributed ledger node 2510; in other examples, the one or more databases may be stored external to the distributed ledger node 2510 but in data communication with the distributed ledger node 2510. The one or more databases may be implemented in 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, Pragmatic Extraction and Reporting Language, Extensible Markup Language, and Common Gateway Interface. Queries formed to one or more databases may be implemented in the same database programming language used to implement the one or more databases. For example, if one or more databases are SQL databases, queries formed to the databases may be formed in SQL (e.g., SELECT column1, column2 FROM table1, table2 WHERE column2='value';). It is understood that one or more databases may be implemented in any database programming language, and that the programming implementation of the queries may be adjusted as needed for compatibility with one or more databases and to reflect the particular information being queried.

[0265] In some examples, one or more databases may be included within distributed ledger node 2510. In other examples, one or more databases may be remote from distributed ledger node 2510 but not in data communication with distributed ledger node 2510. Data communication between one or more databases and distributed ledger node 2510 may be direct data communication or data communication over a network, such as network 2506.

[0266] In some examples, client node 2502 may be in data communication with distributed ledger node 2510. Distributed ledger node 2510 may include mappings 2512. Mappings 2514 may include, for example, a mapping between validating node addresses and validating node 2508, a mapping between routing numbers and validating node addresses, and / or a mapping between routing numbers and validating node 2508. In some examples, mapping 2512 may include a digital signature associated with an organization authorized to verify routing numbers. Based on one or more of these associations, client node 2502 can invoke the validating node for validation and / or provide instructions to a client device to reach the appropriate validating node. This may be accomplished by invoking a verification API associated with validating node 2508.

[0267] In some examples, iterations of the mappings described herein, such as mapping 2512, may also include software or applet version numbers, which may be used to identify a validating node or a validating node address, or to select one validating node among multiple validating addresses.

[0268] In some examples, client node 2502 and distributed ledger node 2510 can be authorized (e.g., allowed to participate in the network) using certificates and / or cryptographic authentication mechanisms (e.g., non-fungible tokens, etc.). Certificates and / or cryptographic authentication mechanisms may be issued, for example, by a consortium authority or other governing body associated with the distributed network. If authorized with the appropriate authority, distributed ledger node 2510 can update mapping 2512 to reflect, for example, different associations between routing numbers, validator node addresses, and validators. In some examples, levels of authority may be issued. For example, if client node 2502 has the ability to route data to validator node 2508 (or other validator nodes), client node 2502 may be granted a certain level of authority. As another example, if distributed ledger node 2510 has the ability to update mapping 2512, then distributed ledger node 2510 may have a different, higher level of authority.

[0269] The system 1100 may include a client device 2514, which may be a network-enabled computer as described herein. The distributed ledger node 2514 may be a server, which may be a dedicated server computer, a blade server, or a personal computer, which may be a laptop computer, a notebook computer, a palmtop computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1100. The client device 2514 may also be a mobile device. For example, the mobile device may include an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices. In some examples, the client device 2514 may be a smart card (e.g., a contactless card or a contact-based card), or the like, in data communication with another network-enabled computer not shown in FIG. 25 .

[0270] In some examples, the client device 2514 can execute one or more applications, such as software applications, that enable network communication with one or more components of the system 1100, transmit and / or receive data, and perform the functions and processes described herein.

[0271] In some examples, upon receiving an authentication request, the client device 2514 may call the client node 2502 (e.g., via an API). The call may include a routing number and / or applet or software version number, and the client node 2502 may query the distributed ledger node 2510 and mapping 2512. If the query returns the identity of the validator node (e.g., validator node 2508) and / or validator node address associated with the routing number and / or applet or software version, the client node 2502 may reply to the client device 2514. The client device 2514 may proceed to authenticate with the validator node. The authentication may be performed by systems and methods described herein, such as cryptographic generation, encryption, transmission, decryption, and verification, as described herein.

[0272] In some examples, the client node 2502 can coexist with the verification node 2508. In these examples, the client node 2502 can process the authentication in a single call from the client device 2514. In some examples, this is acceptable only if the complete authentication transmission (e.g., encryption as described herein) is allowed to be sent to the client node uninvolved in the authentication.

[0273] In some examples, if the client node 2502 receives a routing number from the client device 2514 that is not processed locally, the client node 2502 may return a code indicating that the routing number will not be processed, along with the validator node address of the responsible validator node. The client device 2514 may then send a complete authentication transmission to the validator node 2508 using the received validator node address.

[0274] In some examples, a client node 2502 may enter a distributed network with different authorities. For example, a client node 2502 may be a read-only router for data. As another example, a client node 2502 may have authority to send messages to a distributed ledger node 2510 that update one or more routing paths for one or more routing numbers. However, the client node 2502 is prevented from updating one or more routing paths for one or more routing numbers of other organizations that control or grant authority to other routing numbers associated with the client node 2502. As another example, a distributed ledger node 2510 may include agreements and / or records that can verify the authority of a particular organization to modify a particular routing record based on its digital signature. As another example, a consortium organization or other governing body that controls a distributed network may have additional privileges, including, but not limited to, adding new members (e.g., client nodes, distributed ledger nodes, validating nodes, and / or client devices), adding new signing credentials, adding new keys, adding new certificates, and revoking any of the foregoing. In some examples, such authority may be delegated to client nodes 2502, distributed ledger nodes 2510, and / or validator nodes 2508. However, delegation may not be required if security, legal, and financial conditions are met.

[0275] In some examples, one or more APIs can facilitate communication between components of system 1100 over network 2506. In other examples, one or more APIs are not required. Rather, components of system 1100 can communicate directly with or be dedicated to one or more specific organizations, allowing the specific organizations to maintain control over data transmitted to, from, or through unspecified organizations. This may further improve data security and hinder detection of data traffic patterns by unspecified organizations.

[0276] In some examples, an organization may establish standards for nodes with APIs based on the intended function of those nodes. For example, a first standard may be established for data routing nodes, and a second standard may be established for nodes that perform mapping and / or authentication functions. As another example, a routing API, a mapping API, and a verification API may be established, allowing the same device or hardware configuration to perform these functions. However, the use of keys, including private keys, by the validating nodes 2508 for authentication may require storage of the keys in one or more HSMs to increase the security of the keys and ensure that the keys are not stored in memory.

[0277] 26 illustrates a method 2600 performed by a distributed network authentication system according to an example embodiment. For example, the method may be performed by the distributed network authentication system 2500 and / or by another distributed network authentication system.

[0278] At block 2602, the client device may send an authentication request to the client node. The authentication request may include, but is not limited to, a routing number, a software version number, and / or an applet version number. The request may be made by an API call or other communication between the client device and the client node.

[0279] In block 2604, after receiving the authentication request, the client node may send a query (e.g., via an API call) to the distributed ledger node, which includes the mapping, and to which the distributed ledger node may submit the query.

[0280] At block 2606, the query may return the validator node's identity and / or validator node address, and the distributed ledger node may transmit this identity to the client node.

[0281] The client node may transmit the identifying information to the client device at block 2608. After receiving the identifying information, the client device may proceed with authentication using the identified validator node and / or validator node address at block 2610.

[0282] 27 illustrates an embodiment of an exemplary computer architecture 2700 suitable for implementing the various embodiments described above. In one embodiment, computer architecture 2700 may include or be implemented as part of one or more systems or devices described herein.

[0283] As used herein, the terms "system" and "component" refer to any network-related entity, hardware, a combination of hardware and software, software, or software in execution, examples of which are intended to be provided by exemplary computational computer architecture 2700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. For example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other by various types of communication media to coordinate operations. Coordination may involve unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over communication media. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may use data messages instead. Such data messages may be transmitted over a variety of connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0284] Computing architecture 100 may include various common computing elements such as one or more processors, multi-core processors, co-processors, 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 implementation by computing architecture 100.

[0285] 27, computing architecture 100 includes a processor 2712, a system memory 2704, and a system bus 2706. Processor 2712 may be any of various commercially available processors.

[0286] The system bus 2706 provides an interface for system components, including, but not limited to, the system memory 2704, to the processor 2712. The system bus 2706 may be any of a variety of bus structures, which may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may connect to the system bus 608 through a slot architecture. Examples of slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0287] Computing architecture 100 may include or be implemented in various articles of manufacture. The articles of manufacture may include a computer-readable storage medium 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 be implemented, at least in part, as instructions contained on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

[0288] The system memory 2704 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double 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 memory such as ferroelectric polymer memory, Ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (such as USB memory sticks, solid-state drives (SSDs)), and other types of storage media suitable for storing information. In the embodiment shown in FIG. 27, the system memory 2704 may include non-volatile memory 2708 and / or volatile memory 2710. The basic input / output system (BIOS) may be stored in non-volatile memory 2708 .

[0289] The computer 2702 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 2730, a magnetic disk drive 2716 for reading from or writing to a removable magnetic disk 2720, and an optical disk drive 2728 for reading from or writing to a removable optical disk 2732 (e.g., a CD-ROM or DVD). The hard disk drive 2730, the magnetic disk drive 2716, and the optical disk drive 2728 may be connected to the system bus 2706 by an HDD interface 2714, a FDD interface 2718, and an optical disk drive interface 2734, respectively. The HDD interface 2714 for implementing an external drive may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0290] The drives and associated computer-readable media provide volatile and / or nonvolatile data storage, data structures, computer-executable instructions, etc. For example, several program modules may be stored on the drives, nonvolatile memory 2708, and volatile memory 2710, including an operating system 2722, one or more applications 2742, other program modules 2724, and program data 2726. In one embodiment, the one or more applications 2742, other program modules 2724, and program data 2726 may include, for example, various applications and / or components of the systems described herein.

[0291] A user can enter commands and information into the computer 2702 through one or more wired / wireless input devices, such as a keyboard 2750 and a pointing device such as a mouse 2752. Other input devices may include a microphone, infrared (IR) remote, radio frequency (RF) remote, game pad, stylus pen, card reader, dongle, fingerprint reader, glove, graphics tablet, joystick, keyboard, retina reader, touch screen (capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 2712 through an input device interface 2736 that is coupled to the system bus 2706, but may also be connected to other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0292] A monitor 2744 or other type of display device is also connected to the system bus 2706 via an interface, such as a video adapter 2746. The monitor 2744 may be internal or external to the computer 2702. In addition to the monitor 2744, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0293] The computer 2702 may operate in a networked environment using logical connections via wired and / or wireless communications with one or more remote computers, such as a remote computer 2748. The remote computer 2748 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and typically includes many or all of the elements shown relative to the computer 2702, although for purposes of brevity, only a memory and / or storage device 2758 is shown. The illustrated logical connections include wired and / or wireless connections to a local area network 2756 and / or a wider network (e.g., a wide area network 2754). Such LAN and WAN networking environments are commonplace in offices and businesses to facilitate enterprise-wide computer networking, such as an intranet. All of these networks may be connected to a global communications network, such as the Internet.

[0294] When used in a local area network 2756 networking environment, the computer 2702 is connected to the local area network 2756 through a wired and / or wireless communication network interface or adapter 2738. The network adapter 2738 can facilitate wired and / or wireless communication with the local area network 2756 and may also include a wireless access point for communicating with the wireless capabilities of the network adapter 2738.

[0295] When used in a wide area network 2756 networking environment, the computer 2702 may include a modem 2740, or be connected to a communication server on the wide area network 2754, or have other means for establishing communications over the wide area network 2754, such as via the Internet. The modem 2740, which may be internal or external and may be a wired and / or wireless device, connects to the system bus 2706 via the input device interface 2736. In a networked environment, program modules described relative to the computer 2702, or portions thereof, may be stored in the remote memory and / or storage device 2758. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0296] The computer 2702 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.11 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth™ wireless technologies, etc. Thus, communication may be structured like a traditional network, or may be simple ad-hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

[0297] The various elements of the devices described herein may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, registers, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may 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 program interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or combinations thereof. However, the determination of whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as desired computational 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 required for a particular implementation.

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

[0299] 28 is a block diagram illustrating an exemplary communications architecture 2800 suitable for implementing the various embodiments described above. The communications architecture 2800 includes various common communications elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to being implemented by the communications architecture 2800, which may be consistent with the systems and devices described herein.

[0300] 28, communication architecture 2800 includes one or more client(s) 2802 and server(s) 2804. Server(s) 2804 may implement one or more of the functions and embodiments described herein. Client(s) 2802 and server(s) 2804 are operatively connected to one or more respective client data store(s) 2806 and server data store(s) 2808 that can be used to store information local to the respective client(s) 2802 and server(s) 2804, such as cookie(s) and associated contextual information.

[0301] The clients 2802 and the servers 2804 may communicate information with each other using a communications framework 2810. The communications framework 2810 may implement any known communications technology and protocol. The communications framework 2810 may be implemented as a packet-switched network (such as a public network such as the Internet, or a private network such as a corporate intranet), a circuit-switched network (such as the public switched telephone network), or a combination of packet-switched and circuit-switched networks (using appropriate gateways and translators).

[0302] Communications framework 2810 may implement various network interfaces arranged to accept, communicate, and connect to communications networks. A network interface may be considered a specialized type of input / output (I / O) interface. The network interface may use connection protocols including, but not limited to, direct connect, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000 Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. Furthermore, multiple network interfaces may be used in connection with various communications network types. For example, multiple network interfaces may be used to enable communications across broadcast, multicast, and unicast networks. If processing requirements dictate higher speeds and capacity, a distributed network controller architecture may similarly be used to pool, load balance, and otherwise increase the communications bandwidth required for clients 2802 and servers 2804. The communications network may be any one or combination of wired and / or wireless networks, including, but not limited to, direct interconnections, secured custom connections, private networks (such as corporate intranets), public networks (such as the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operating missions as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, other communications networks, and the like.

[0303] It is further noted that the systems and methods described herein may be tangibly embodied in one or more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, a read-only memory (ROM), a random access memory (RAM), and other physical media capable of storing data. For example, data storage may include random access memory (RAM) and read-only memory (ROM), which may be configured to access and store data and information and computer program instructions. Data storage may also include storage media or other suitable types of memory (e.g., RAM, ROM, programmable read-only memory (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, flash drive, any type of tangible and non-transitory storage medium, etc.), and may store files comprising an operating system, application programs, such as a web browser application, an email application, and / or other applications, and data files. Data storage in a network-enabled computer system may include electronic information, files, and documents stored in a variety of ways, including as flat files, indexed files, hierarchical databases, relational databases (such as databases created and maintained using software from Oracle® Corporation or the like), Microsoft® Excel files, Microsoft® Access files, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online storage or cloud storage), or other storage mechanisms. Additionally, the figures show various components (e.g., servers, computers, processors, etc.) separately.The functions described as being performed by various components may be performed by other components, the various components may be combined or separated, and other variations may also be made.

[0304] In the foregoing specification, various embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes may be made and additional embodiments may be implemented without departing from the broader scope of the invention as set forth in the claims. The specification and drawings are accordingly to be regarded in an illustrative rather than a restrictive sense.< / puid> < / nonce>

Claims

1. 1. A communications device including a system on a chip (SoC), The communication device Generate a communication area, displaying a prompt on the communication device to tap a contactless card; After entering the communication area, the contactless card is read; Performing authentication of the contactless card; executing a payment transaction after successful authentication of said contactless card; Communication devices.

2. After the successful authentication and before the payment transaction, the communications device displays one or more user interfaces; the one or more user interfaces include at least one selected from the group of a user interface requesting additional verification, a user interface displaying data, a user interface of an access point device, and a user interface providing access to additional functionality; The communication device of claim 1 .

3. after displaying the one or more user interfaces, the communication device provides access to one or more functions; the one or more features include at least one selected from the group of access to media content, discounts, promotions, loyalty rewards, and reward points; The communication device of claim 2.

4. the access to media content includes at least one selected from the group of access to entertainment content and access to sports content; The communication device of claim 3.

5. In authenticating the contactless card, the communication device receiving an encrypted code from said swiping of said contactless card; Generate an authentication session key, Generate an encryption session key, decrypting the encrypted cipher using the encrypted session key; verifying the encryption using the authentication session key; The communication device of claim 1 .

6. The SoC stores an authentication diversification key, an encryption diversification key, and a counter value; the authentication session key is generated using the authentication diversification key, the counter value, and a cryptographic algorithm; the encrypted session key is generated using the encryption diversification key, the counter value, and the encryption algorithm; The communication device of claim 5.

7. the communications device receiving an issuer identifier from the swiping of the contactless card; the issuer identifier identifies at least one selected from a group of an identifier of the contactless card and a device associated with the identifier of the contactless card; The communication device of claim 1 .

8. After an authentication failure, the communication device executes the payment transaction. The communication device of claim 1 .

9. 1. A method performed by a communications device including a system on a chip (SoC), comprising: The method comprises: generating a communication area; displaying a prompt on the communication device to tap a contactless card; reading the contactless card after entering the communication area; performing authentication of the contactless card; executing a payment transaction after successful authentication of the contactless card; Including, method.

10. further comprising displaying one or more user interfaces after the successful authentication and before the payment transaction; the one or more user interfaces include at least one selected from the group of a user interface requesting additional verification, a user interface displaying data, a user interface of an access point device, and a user interface providing access to additional functionality; 10. The method of claim 9.

11. the one or more user interfaces include one or more user interfaces for requesting additional verification; the one or more user interfaces for requesting additional verification include at least one selected from the group of a user interface requesting submission of login credentials, a user interface requesting age verification, a user interface requesting address information, and a user interface requesting biometric information; The method of claim 10.

12. the biometric information includes at least one selected from the group consisting of a face scan, a fingerprint scan, a retina scan, and a voice input; The method of claim 11.

13. providing access to one or more functions after displaying the one or more user interfaces; the one or more functions include at least one selected from the group of: access to one or more accounts; and the ability to conduct transactions using the one or more accounts. The method of claim 10.

14. the one or more accounts include at least one selected from the group of a rewards account, a merchant account, a utility account, a financial account, a securities account, a travel account, and an access point account; 14. The method of claim 13.

15. the one or more accounts include at least one selected from the group of credit cards, debit cards, and gift cards; 14. The method of claim 13.

16. 1. A non-transitory computer-readable medium comprising instructions for execution by a communications device, the instructions causing the communications device to: generating a communication area; displaying a prompt on the communication device to tap a contactless card; reading the contactless card after entering the communication area; performing authentication of the contactless card; executing a payment transaction after successful authentication of the contactless card; Performing steps including Non-transitory computer-readable medium.

17. The procedure comprises: and displaying one or more user interfaces after the successful authentication. the one or more user interfaces include at least one selected from the group of a user interface requesting additional verification, a user interface displaying data, a user interface of an access point device, and a user interface providing access to additional functionality; 17. The non-transitory computer-readable medium of claim 16.

18. The additional functionality includes access to buildings, rooms, lockers, storage units, and vehicles.

20. The non-transitory computer-readable medium of claim 17.

19. the additional functionality includes access to at least one selected from the group of loyalty program status, reward points balance, frequent flyer miles balance, redemption options, and past redemption history; 20. The non-transitory computer-readable medium of claim 17.

20. the one or more user interfaces include a user interface of one or more access point devices; the user interface of the one or more access point devices includes at least one selected from the group of a user input interface, a biometric user interface, and a photo input interface; 20. The non-transitory computer-readable medium of claim 17.

Images