Technique for providing secure cryptographic authentication of contactless cards by decentralized entities

Abstract

Exemplary embodiments disclose systems and methods for secure cryptographic authentication of contactless cards by a distributed entity. In exemplary embodiments, a distributed network authentication system may include a client node and a distributed ledger node in data communication with the client node. The distributed ledger may include a database storing a mapping. The client node may receive an authentication request from a client device and, in response to the authentication request, send a query to the distributed ledger node. The distributed ledger node may receive the query from the client node, send the query to the database, receive at least one identity selected from the group of a validator node and a validator node address from the database in response to the query, and send the identity to the client node.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 18 / 244,838, filed September 11, 2023, and U.S. Provisional Patent Application No. 63 / 405,749, filed September 12, 2022, the disclosures of which are incorporated herein by reference in their entireties.

[0002] Field of Disclosure The present disclosure relates to techniques for providing secure cryptographic authentication of contactless cards by distributed entities. [Background technology]

[0003] Contactless card products have become so widely known and ubiquitous that they have fundamentally changed the way financial transactions and transactions are valued and conducted in today's society. Contactless card products are most commonly represented by plastic card-like elements offered and 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 and direct exchange of cash. Data security and transaction integrity are crucial to the businesses and customers facilitating these transactions. This need continues to grow as electronic transactions conducted with contactless cards account for an ever-greater proportion of commercial activity. Therefore, there is a need to provide businesses and users with appropriate solutions that overcome current shortcomings to provide data security, authentication, and verification for contactless cards. Summary of the Invention

[0004] In some aspects, the technology described herein relates to a distributed network authentication system including: a client node; and a distributed ledger node in data communication with the client node, the distributed ledger including a database storing mappings; the client node configured to receive authentication requests from the client device and to send queries to the distributed ledger node in response to the authentication requests; the distributed ledger node configured to receive queries from the client node, send the queries to the database, receive at least one identifier (ID) selected from the group of validating nodes and validating node addresses from the database in response to the queries, and send the ID to the client node.

[0005] In some aspects, the techniques described herein relate to a method performed by a distributed network authentication system including a client node and a distributed ledger node, the method including: the client node receiving an authentication request from a client device; in response to the authentication request, the client node sending a query to the distributed ledger node; the distributed ledger node receiving the query from the client node; the distributed ledger node sending the query to a database; the distributed ledger node receiving at least one identity selected from a group of validating nodes and validating node addresses from the database in response to the query; and the distributed ledger node sending the identity to the client node.

[0006] In some aspects, the technology described herein relates to a non-transitory computer-readable medium including instructions for execution by a distributed network authentication system including a distributed ledger node including a database, the instructions, when executed, causing the distributed network authentication system to perform a procedure including receiving a query from a client node; sending the query to the database; receiving at least one identity selected from the group of validator nodes and validator node addresses from the database in response to the query; and sending the identity to the client node.

[0007] In some aspects, the technology described herein relates to a non-transitory computer-readable medium, wherein the distributed network authentication system further includes a client node, and the method further includes the client node receiving an authentication request from a client device, and in response to the authentication request, the client node sending a query to the distributed ledger node. [Brief explanation of the drawings]

[0008] To easily identify the description of any particular element or operation, the most significant digit(s) of a reference number refers to the figure number in which that element is first introduced. [Figure 1] FIG. 1 illustrates a data transmission system according to one embodiment. [Figure 2] FIG. 1 illustrates a data transmission system according to one embodiment. [Figure 3] FIG. 1 illustrates a contactless card, according to one embodiment. [Figure 4] FIG. 2 illustrates contactless card components, according to one embodiment. [Figure 5] FIG. 1 illustrates a sequence flow according to one embodiment. [Figure 6] FIG. 2 illustrates a data structure according to one embodiment. [Figure 7] FIG. 1 is a diagram of a key system, according to one embodiment. [Figure 8]1 is a flowchart of a method for generating a ciphertext, according to one embodiment. [Figure 9] 1 is a flowchart of a method illustrating key diversification, according to one embodiment. [Figure 10] 1 is a flowchart of a method for card activation, according to one embodiment. [Figure 11] FIG. 2 illustrates a data payload according to one embodiment. [Figure 12] FIG. 1 illustrates a personalization and verification system, according to one embodiment. [Figure 13] FIG. 1 illustrates a distributed network authentication system, according to one embodiment. [Figure 14] FIG. 1 illustrates a method performed by a distributed network authentication system, according to one embodiment. [Figure 15] FIG. 1 illustrates a computer architecture, according to one embodiment. [Figure 16] FIG. 1 illustrates a communication architecture, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Various embodiments are described herein with reference to the accompanying drawings. It will be apparent, however, that various modifications and changes can be made to the various embodiments, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense, and not in a restrictive sense.

[0010] Exemplary embodiments herein disclose a system and method for secure cryptographic authentication of contactless cards by distributed entities. As contactless cards become ubiquitous, it is necessary for many entities distributed across different countries, industries, and locations to be able to securely communicate, authenticate, and verify contactless cards.

[0011] The systems and methods described herein for providing data security, authentication, and validation for contactless cards offer many advantages. For example, the systems and methods described herein enable routing of card tap requests to many different card validators by adding an issuer ID to the data payload communicated between the card and various other devices (e.g., client devices and / or servers).

[0012] As another example, card personalization can be decoupled from card verification, which advantageously allows multiple entities to perform verification securely, consistently, and without unnecessary exchange of sensitive data. In some examples described herein, decoupling card personalization from verification may be achieved by adding a key identifier to data payloads communicated between the card and various other devices (e.g., client devices and / or servers). In other examples described herein, decoupling card personalization from verification may be achieved by deriving a shared secret value from a master key. In yet other examples described herein, decoupling card personalization from verification may be achieved by avoiding the use of Permanent Account Number (PAN) Sequence Numbers (PSNs) for key derivation.

[0013] As another example, a challenge can be incorporated to advantageously avoid or reduce the risk of preplay and / or replay attacks. In some examples, a challenge may be generated, linked to the session, and then written to the card. The challenge can be used in generating encrypted data, such as a ciphertext, and session validation can be added to the validation logic.

[0014] As a further example, additional improvements to data security, authentication, and validation can be made, such as using custom NFC specifications, dormant applets, signed hashes of card product customer identifiers, centralized validators, and general-purpose cryptography to advantage.

[0015] As a further example, it may be advantageous to distribute authentication functionality across a decentralized network. This may be done without establishing a central authority; instead, a distributed ledger may be implemented to coordinate authentication and transaction routing among different entities. In some examples, the different entities may be one or more of financial entities, merchants, service providers, other card issuing entities, and other entities that store keys for authentication. The different entities may act as, or in addition to, a consortium authority or other administrative entity associated with the network.

[0016] Distributing authentication functionality across a network can advantageously allow different entities to participate in providing data security, authentication, and verification for contactless cards. In addition, different entities may be able to manage their own resources. Furthermore, different entities may provide access to client applications (e.g., e-commerce applications) across a wider range of contactless cards than any single entity could provide. Maintaining and, as needed, updating a distributed ledger creates a decentralized network that meets the current needs of different entities at any given time. These functions can be achieved while maintaining the secure communication, authentication, and verification described herein.

[0017] In some instances, one or more client nodes may be established that provide services to an application programming interface (API), and in some instances, each client node may be associated with a routing number, while in other instances, no such association may be made.

[0018] Through the API, client nodes can look up validating node addresses (e.g., uniform resource indicators (URIs), uniform resource locators (URLs), or other links) to validating nodes. Validating node addresses can be pre-configured as primary and secondary (e.g., via Domain Name System (DNS) or other implementations) to provide backup redundancy. Load balancer services, such as DNS services, can provide load balancing and data traffic direction.

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

[0020] In some examples, a client node can communicate data with one or more distributed ledger nodes. The distributed ledger nodes can include mappings, such as in the form of a database. The mappings can include, for example, a mapping between validator node addresses and validator nodes, a mapping between routing numbers and validator node addresses, and / or a mapping between routing numbers and validator nodes. In some examples, the mappings can include digital signatures associated with particular entities that have the authority to verify particular routing numbers. Based on one or more of these associations, the client node can invoke the validator node for validation and / or provide instructions to the client device to reach the appropriate validator node. This can be accomplished by invoking a validation API associated with the validator node.

[0021] In some examples, the aforementioned mapping iterations 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 among multiple validating addresses for a single validating node.

[0022] In some examples, client nodes and distributed ledger nodes may be authorized (e.g., enabled to participate in the network) with the aid of certificates and / or cryptographic authentication mechanisms (e.g., non-fungible tokens), which may be issued, for example, by a consortium authority or other administrative entity associated with the network.

[0023] In some examples, a distributed ledger node with appropriate authority can update the mapping to reflect different associations between, for example, routing numbers, validator node addresses, and validator nodes.

[0024] In some examples, tiered authority can be issued. For example, a client node that functions to route data to one or more validator nodes can be given a particular level of authority. As another example, a distributed ledger node that has the ability to update mappings can have a different, higher level of authority.

[0025] In some examples, upon receiving the authentication request, the client device may call the client node (e.g., via an API). The call may include a routing number and / or applet or software version number, and the client node may query a mapping included in the distributed ledger node. If the query returns the identity of the validator node and / or validator node address associated with that routing number and / or applet or software version, the client node may respond to the client device. The client device may then proceed with authentication with the validator node. Authentication may be performed by the systems and methods described herein, for example, by generating, encrypting, transmitting, decrypting, and verifying ciphertext, etc., as described herein.

[0026] In some examples, the client node may coexist with the validator node. In these examples, the client node may handle authentication with a single call from the client device. In some examples, this may only be acceptable if the entire authentication transmission (e.g., the ciphertext described herein) is allowed to be sent to a client node that is not involved in the authentication.

[0027] In some examples, if a client node receives a routing number from a client device that has not been processed by its location, the client node may return a code indicating that the routing number has not been processed, along with the validator node address of the responsible validator node. The client device may then send the entire authentication transmission to the responsible validator node using the received validator node address.

[0028] In some examples, client nodes can enter a distributed network with different permissions. For example, a client node can be a read-only router for data. As another example, a client node can have the authority to send messages to a distributed ledger node that updates one or more routing paths for one or more routing numbers. However, the client node is prevented from updating one or more routing paths for one or more routing numbers for other entities that control other routing numbers not associated with the client node or that did not grant this authority. As another example, a distributed ledger node can include contracts and / or records that can verify the authority of a particular entity to modify a particular routing record based on its digital signature. As another example, a consortium authority or other administrative entity that controls the distributed network can 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 instances, if security, legal, and / or financial conditions are met, the aforementioned powers may be delegated to one or more client nodes, distributed ledger nodes, and / or validator nodes, although delegation is not required.

[0029] All of the foregoing examples provide many advantages with respect to contactless card data security, authentication, and verification. It will be appreciated that these and further advantages may be achieved by a combination of one or more of the foregoing examples.

[0030] 1 illustrates a data transmission system 100 according to an exemplary embodiment. As discussed further below, 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 example of a component, system 100 may include any number of components.

[0031] The system 100 may include one or more contactless cards 102, described further below. In some embodiments, the contactless cards 102 may communicate wirelessly with the client device 104, using, in one example, NFC.

[0032] System 100 may include client device 104, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include computing or communication devices, including, but not limited to, a server, network appliance, personal computer, workstation, telephone, handheld PC, smart card (e.g., contactless card or contact-based card), personal digital assistant, thin client, fat client, internet browser, or other device. Client device 104 may also be a mobile device, which may include, for example, an Apple® iPhone®, iPod®, iPad®, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0033] The client device 104 device may include 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-resistant hardware, as necessary to perform the functions described herein. The client device 104 may further include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat-panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. 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 touchscreen, keyboard, mouse, cursor control device, touchscreen, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0034] In some examples, a client device 104 of system 100 may execute one or more applications, such as, for example, software applications that enable network communication with one or more components of system 100, send and / or receive data, and perform the functions and processes described herein.

[0035] The client device 104 can communicate with one or more servers 108 over one or more networks 106 and can operate as a respective front-end to back-end pair with the server 108. The client device 104 can send one or more requests to the server 108, for example, from a mobile device application running on the client device 104. The one or more requests may be associated with retrieving data from the server 108. The server 108 can 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 can 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 can be configured to send the received data to the client device 104, where the received data is in response to the one or more requests.

[0036] The system 100 may include one or more networks 106. In some examples, the network 106 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks and may be configured to connect 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 mobile communications system, 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, the IEEE 802.11 family of networks, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and / or the like.

[0037] 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 any combination thereof. Network 106 may further include one network or any number of networks of the above exemplary types, operating as a standalone network or in cooperation with one another. Network 106 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 106 may translate to or from one or more protocols of network devices. While network 106 is shown as a single network, it should be understood that, according to one or more examples, network 106 may include multiple interconnected networks, such as the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0038] The system 100 may include one or more servers 108. In some examples, the server 108 may include one or more processors coupled to memory. In some examples, the server may be a network-enabled computer. The server 108 may be configured as a central system, server, or platform for controlling and retrieving 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 execute one or more applications, such as, for example, software applications that enable network communication with one or more components of the system 100, send and / or receive data, and perform the functions and processes described herein. The server 108 may communicate data with one or more components of the system 100 via one or more networks and / or one or more intermediate devices (e.g., one or more network-enabled computers).

[0039] In some examples, server 108 may be a dedicated server computer, a blade server, or may be a personal computer, 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 100. In some examples, server 108 may be one or more client devices 104. While FIG. 1 shows a single server 108, it is understood that other embodiments may use multiple servers or multiple computer systems as needed or desired to support users, and may also use backup or redundant servers to prevent network downtime in the event of a failure of a particular server. In some examples, server 108 may be a dedicated server computer, such as a blade server, or may be a personal computer, 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 100.

[0040] In some examples, the exemplary procedures according to the present disclosure described herein may be performed by a processing arrangement and / or a computing arrangement (e.g., a computer hardware device). Such an apparatus may be, or may include, all or part of a computer and / or processor that may include, for example, but is not limited to, one or more microprocessors and that can use instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device). For example, the computer-accessible medium may be part of the memory of the contactless card 102, the client device 104, the server 108, and / or other computer hardware device.

[0041] In some examples, a computer-accessible medium (e.g., a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a collection thereof) may be provided (e.g., in communication with a processing device). The computer-accessible medium may contain executable instructions. Additionally or alternatively, a storage arrangement may be provided separate from the computer-accessible medium, for example, as described herein above. The storage arrangement may provide instructions to the processing arrangement, configuring the processing device to perform certain example procedures, processes, and methods.

[0042] FIG. 2 illustrates a data transmission system according to an exemplary embodiment. System 200 may include a sending or transmitting device 204 and a receiving or receiving device 208 that communicates with one or more servers 202, for example, via a network 206. Sending or transmitting device 204 may be the same as or similar to contactless card 102 or client device 104 discussed above with reference to FIG. 1A. Receiving or receiving device 208 may be the same as or similar to client device 104 discussed above with reference to FIG. 1A. Network 206 may be similar to network 115 discussed above with reference to FIG. 1A. Server 202 may be similar to server 108 discussed above with reference to FIG. 1A. Although FIG. 2 illustrates a single example of components of system 200, system 200 may include any number of the illustrated components.

[0043] 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.

[0044] It is also important that the same key is not used multiple times. If a key is used or reused too frequently, it may be compromised. Each time a key is used, it provides an attacker with an additional sample of data that has been processed by a cryptographic algorithm using the same key. The more data an attacker has that has been processed with the same key, the more likely the attacker will be able to discover the value of the key. Frequently used keys can be involved in a variety of different attacks.

[0045] Additionally, each time a symmetric cryptographic algorithm is executed, it may reveal information, such as side channel data, about the key used during the symmetric cryptographic operation. The side channel data may include minute power fluctuations that occur as the cryptographic algorithm executes using the key. Enough of the side channel data may reveal enough information about the key to allow the key to be recovered by an attacker. Using the same key to exchange data repeatedly reveals data processed by the same key.

[0046] However, limiting the number of times a particular key is used 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, the parties involved in the exchange of cryptographic information (e.g., sender and receiver) can generate keys independently from an initial shared master symmetric key in combination with a counter value, thereby periodically rotating the shared symmetric key being used, with the attendant needing to resort to some form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and receiver, the attacks described above become impossible.

[0047] Referring back to FIG. 2 , the system 200 may be configured to implement key diversification. For example, a sender and a receiver may desire to exchange data (e.g., original confidential data) via their respective devices 204 and 208. As described above, a single instance of a transmitting device 204 and a receiving device 208 may be included, but it is understood that one or more transmitting devices 204 and one or more receiving devices 208 may be involved so long as each party shares the same shared secret symmetric key. In some examples, the transmitting device 204 and the receiving device 208 may be provisioned with the same master symmetric key. Furthermore, it is understood that any party or device holding the same secret symmetric key may perform the functions of the transmitting device 204, and similarly, any party holding the same secret symmetric key may perform the functions of the receiving device 208. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties other than the transmitting device 204 and the receiving device 208 involved in the exchange of 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 that a portion of the data exchanged between the transmitting device 204 and the receiving device 208 includes at least a portion of the 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.

[0048] The system 200 may include one or more networks 206. In some examples, the network 206 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks and may be configured to connect the one or more transmitting devices 204 and the 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 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, an IEEE 802.11 family network, Bluetooth, NFC, RFID, Wi-Fi, and / or the like.

[0049] Additionally, network 206 may include a global network such as, but not limited to, telephone lines, optical fiber, IEEE Ethernet 902.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 any combination thereof. Network 206 may further include one network or any number of networks of the above exemplary types, operating as a standalone network or in cooperation with one another. Network 206 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 206 may translate one or more protocols of network devices to or from other protocols. While network 206 is shown as a single network, it should be understood that, according to one or more examples, network 206 may include multiple interconnected networks, such as the Internet, a service provider's network, a cable television network, an enterprise network such as a credit card association network, and a home network.

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

[0051] In block 150, when the sending device 204 prepares to process the sensitive data in a symmetric cryptographic operation, the sender may update a counter. In addition, the sending device 204 may select an appropriate symmetric cryptographic 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 any symmetric cryptographic 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 processing multiple iterations of the symmetric algorithm with different input data and the same master key can generate multiple outputs that can be combined as needed to generate a key of sufficient length.

[0052] In block 152, the sending device 204 may obtain the selected encryption algorithm and process the counter value using a master symmetric key. For example, the sender may select a symmetric encryption algorithm and use a counter that updates with each conversation between the sending device 204 and the receiving device 208. The sending device 204 may then encrypt the counter value with the selected symmetric encryption algorithm using the master symmetric key to create a diversified symmetric key.

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

[0054] In block 154, 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 then transmit the protected encrypted data, along with the counter value, to the receiving device 208 for processing.

[0055] In block 156, the receiving device 208 may first obtain the counter value and then perform the same symmetric encryption using the counter value as 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 created by the sender.

[0056] In block 158, the receiving device 208 may then obtain the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm together with the diversified symmetric key.

[0057] At block 220, the protected encrypted data may be decrypted to reveal the original sensitive data.

[0058] The next time sensitive data needs to be transmitted from a sender to a receiver via the respective sending device 204 and receiving device 208, a different counter value may be selected that generates 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 can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the sensitive data.

[0059] As described above, both the transmitting device 204 and the receiving device 208 initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original secret data. The diversified symmetric keys are created independently by both the transmitting device 204 and the receiving device 208 and are therefore never transmitted between them. Therefore, an attacker cannot intercept the diversified symmetric key, and the attacker never sees 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, reduced side-channel data regarding the master symmetric key is revealed. Furthermore, the operations of the transmitting device 204 and the receiving device 208 may be governed by symmetric requirements regarding the frequency of creating new diversification values, and therefore new diversified symmetric keys. In one embodiment, a new diversification value, and therefore a new diversified symmetric key, may be created with each exchange between the transmitting device 204 and the receiving device 208.

[0060] 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, the full value of a counter transmitted from the transmitting device 204 and the receiving device 208, a portion of a counter 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 them, a one-time passcode 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 create multiple diversified keys. For example, a counter may be used as the key diversification value. Additionally, a combination of one or more of the example key diversification values ​​described above may be used.

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

[0062] FIG. 3 illustrates an exemplary 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, as displayed as service provider indicia 302 on the front or back of the contactless card 102. 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, loyalty cards, and the like. The contactless card 102 may include a substrate 308, which may include a single layer or one or more laminates 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, while the transaction card may otherwise conform to the ISO / IEC 14443 standard. However, it is understood that a contactless card 102 according to the present disclosure may have different characteristics, and the present disclosure does not require the transaction card to be implemented as a payment card.

[0063] The contactless card 102 may also include identification information 306 displayed on the front and / or back of the card and a contact pad 304. The contact pad 304 may include one or more pads and be configured to establish contact with another client device, such as an automated teller machine (ATM), a user device, a smartphone, a laptop, a desktop, or a tablet computer, via the transaction card. The contact pad may be designed according to one or more standards, such as the ISO / IEC 7816 standard, and may enable communication according to the EMV protocol. The contactless card 102 may also include processing circuitry, an antenna, and other components, as further discussed in FIG. 4. These components may be located behind the contact pad 304 or elsewhere on the substrate 308, for example, within a different layer of the substrate 308, and may be electrically and physically coupled to the contact pad 304. The contactless card 102 may also include a magnetic strip or tape that may be positioned 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 the NFC protocol. The embodiments are not so limited.

[0064] 2, the contact pad 304 of the contactless card 102 may include processing circuitry 416 for storing, processing, and communicating information, including a processor 402, memory 404, and one or more interfaces 406. It will be 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 tamper-resistant hardware, as needed to perform the functions described herein.

[0065] The memory 404 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 102 may include one or more of these memories. Read-only memory 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 read-multiple memory may be programmed at a time after the memory chip leaves the factory. Once the memory is programmed, it may not be rewritten but may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Read / write memory may also be read many times after leaving the factory. In some cases, the memory 404 may be encrypted memory that utilizes an encryption algorithm executed by the processor 402 on encrypted data.

[0066] The memory 404 may be configured to store one or more applets 408, one or more counters 410, a customer identifier 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 on one or more contactless cards, enable data communication, and implement the functions and processes described herein, such as a Java Card applet. However, it is understood that the applet(s) 408 are not limited to Java Card applets and may instead be any software application capable of operating on a contactless card or other device with limited memory. The one or more counters 410 may include a numeric counter sufficient to store an integer. The customer identifier 414 may include 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 can identify both the customer and the account assigned to that customer, and can further identify the contactless card 102 associated with the customer's account. As described above, the account number(s) 412 can include thousands of one-time virtual account numbers associated with the contactless card 102. The applet(s) 408 of the contactless card 102 can be configured to manage the account number(s) 412 (e.g., select the account number(s) 412, mark the selected account number(s) 412 as used, and send the account number(s) 412 to a mobile device for auto-fill by an auto-fill service).

[0067] Although the processor 402 and memory elements of the foregoing exemplary embodiments are described with reference to the contact pads 304, the present disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pads 304, or may be completely separate from the contact pads, or may be implemented as additional elements located within the contact pads 304 in addition to the processor 402 and memory 404 elements.

[0068] In some examples, the contactless card 102 can include one or more antennas 418. The one or more antennas 418 may be disposed within the contactless card 102 and around the processing circuit 416 on the contact pad 304. For example, the one or more antennas 418 may be integral with 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 contact pad 304 and the processing circuit 416.

[0069] In one embodiment, the coil of the contactless card 102 can function as the secondary of an air-core transformer. The terminal can communicate with the contactless card 102 by interrupting power or amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using gaps in the contactless card's power connection, which may be maintained functionally via one or more capacitors. The contactless card 102 can communicate back by switching or load modulating the load on the contactless card's coil. Load modulation can be detected in the terminal's coil through interference. More generally, using the antenna(s) 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.

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

[0071] An example of an NDEFOTP is the NDEF short record layout (SR=1). In such an example, one or more applet(s) 408 can be configured to encode the OTP as a text tag of the well-known type NDEF Type 4. In some examples, an NDEF message can include one or more records. The applet(s) 408 can be configured to add one or more static tag records in addition to the OTP record.

[0072] In some examples, the 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 can indicate the authenticity of the contactless card. Based on the one or more applets 408, an NFC read of the tag may be processed, the data may be transmitted to a server, such as a server in a banking system, and the data may be verified by the server.

[0073] In some examples, the contactless card 102 and the server may contain specific data so that the card can be properly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter(s) 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(s) 410 are sent to the server for verification, which determines (as part of the verification) whether the counter(s) 410 equal the server's counter.

[0074] The one or more counters 410 may be configured to prevent replay attacks. For example, if a ciphertext is captured and replayed, the ciphertext is immediately rejected if the counter(s) 410 are read, used, or otherwise passed. The counter(s) 410 can be replayed if they are not used. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. The contactless card 101 is not available to determine the application transaction counter(s) 410 because there is no communication between the applet(s) 408 on the contactless card 102.

[0075] In some examples, the counter(s) 410 may become out of sync. In some examples, the counter(s) 410 may increment to account for accidental reads that initiate transactions, such as reads at an angle, but the application does not process the counter(s) 410. In some examples, when the mobile device 110 wakes up, NFC may be enabled and the device 110 may be configured to read available tags, but no action is performed in response to the read.

[0076] To keep the counter(s) 410 synchronized, an application may be executed, such as a background application, that would be configured to detect when the mobile device 110 wakes up, synchronize with the banking system's server, indicate that a read has occurred due to the detection, and then advance the counter 104. In another example, a hashed one-time password may be utilized, so that a window of mis-synchronization may be accommodated. For example, if within a threshold of 10, the counter(s) 410 may be configured to advance. However, if within a different threshold number, such as 10 or 1000, a request to perform a re-synchronization may be processed, which the user requests via one or more applications that they tap, gesture, or otherwise indicate one or more times via their device. If the counter(s) 410 increment in the appropriate sequence, the user may know that they have done so.

[0077] The key diversification technique described herein with reference to counter(s) 410, master keys, and diversified keys is one example of an encryption and / or decryption key diversification technique. This exemplary key diversification technique should not be considered limiting of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0078] 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 within the contactless card 102. A key diversification process may be used to derive one or more keys from a master key based on uniquely identifiable information for each entity that requires a key.

[0079] In some examples, to overcome the shortcomings of the 3DES algorithm, which may be susceptible to vulnerabilities, a session key (such as a unique key per session) can be derived, but rather than using a master key, a unique card-derived key and counter can be used as diversification data. For example, each time the contactless card 101 is used in operation, a different key may be used to create 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 by using an application transaction counter with one or more algorithms (as defined in EMV4.3Book2A1.3.1CommonSessionKeyDerivation).

[0080] Additionally, the increment for each card may be unique, assigned by personalization, or algorithmically assigned by some identifying information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some instances, the increment may also vary over successive reads, such that one card may successively increment by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This can make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0082] 5 is a timing diagram illustrating an example 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.

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

[0084] 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) cryptogram. In some examples, this may occur when the contactless card 102 is read by the application 502. In particular, this may occur during a read, such as an NFC read of a Near Field Communication Data Exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader application such as application 502 may send a message such as an applet selection message with the applet ID of an NDEF generation applet. Upon confirming the selection, a sequence of select file messages followed by a read file message may be sent. For example, the sequence may include "select file," "read file," and "read 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, which may include a header and a shared secret value. A session key may then be generated. A MAC ciphertext may be created from the message, which may include a header and a shared secret value. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with a session key. The ciphertext and header may then be concatenated, encoded as ASCII hex, and returned in NDEF message format (in response to a "read NDEF file" message).

[0085] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples, the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string). 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.

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

[0087] At line 514, the processor 504 verifies the MAC ciphertext according to instructions from the application 122. For example, the MAC ciphertext may be verified as described below. In some examples, verification of the MAC ciphertext 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 ciphertext for transmission to a server of the banking system, which can verify the MAC ciphertext. In some examples, the MAC ciphertext may serve as a digital signature for verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero-knowledge protocols, may be used to perform this verification.

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

[0089] FIG. 7 shows a diagram of a system 700 configured to implement one or more embodiments of the present disclosure. As described below, two cryptographic keys can be uniquely assigned to each card during the contactless card creation process. The cryptographic keys can include symmetric keys that can be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by hardware within the contactless card. A key diversification process can be used to derive one or more keys from a master key based on uniquely identifiable information for each entity that requires a key.

[0090] 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 unique card master keys 708, 720 for each card. In some examples, a network profile record ID (pNPR) and / or derived key index (pDKI) 722, as well as a unique ID number (pUID) and / or PAN sequence number (PSN) 724 as back-office data, may be used to identify which issuer master key 702, 726 should be used in the cryptographic process for authentication. A system performing authentication may be configured to look up the pNPR, pDKI722 and pUID, PSN724 values ​​of the contactless card at the time of authentication.

[0091] In some examples, to increase the security of the solution, a session key (such as a unique key per session) can be derived, but rather than using a master key, as described above, a unique card-derived key and counter can be used as diversification data. For example, a different key may be used to create a message authentication code (MAC) and perform encryption each time the card is used during operation. With regard to session key generation, the key used to generate ciphertext and encrypt data within one or more applets may include a session key based on a card-unique key (Card-Key-Auth 708 and Card-Key-Dek 720). The session keys (Auth-Session-Key 732 and DEK-Session-Key 710) may be generated by one or more applets and derived by using an application transaction counter (pATC) 704 in one or more algorithms. Only the two lowest bytes of the four-byte pATC 704 are used to adapt the data to one or more algorithms. In some examples, a 4-byte session key derivation method may include F1:=PATC(lowest 2 bytes)||'F0'||'00'||PATC(4 bytes) F1:=PATC(lowest 2 bytes)||'0F'||'00'||PATC(4 bytes) SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG may include 3DESECB and MK may include a card-unique derived master key.

[0092] As described herein, the lower two bytes of the pATC 704 counter can be used to derive one or more MAC session keys. At each tap of the contactless card, the pATC 704 is configured to be updated, and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 720 are further diversified into session keys Auto-Session-Key 732 and DEK-Session-KEY 710. The pATC 704 may be initialized to 0 upon personalization or applet initialization. In some examples, the pATC counter 704 may be initialized at or before personalization and configured to increment by 1 upon each NDEF read.

[0093] Additionally, updates for each card may be unique, assigned by personalization, or algorithmically assigned by pUID or other identifying information. For example, odd-numbered cards may increment or decrement by 2, while even-numbered cards may increment or decrement by 5. In some examples, updates may also vary over successive reads, such that one card may successively increment by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

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

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

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

[0097] The following format represents an example embodiment of the binary version: Additionally, in some examples, the first byte may be set to an ASCII "A." [Table 1] [Table 2]

[0098] Another exemplary format is shown below: In this example, the tag may be encoded in hexadecimal format. [Table 3] [Table 4]

[0099] The UID field of the received message can be extracted to derive the card master keys (Card-Key-Auth 708 and Card-Key-DEK 720) for that particular card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 726. The card master keys (Card-Key-Auth 508 and Card-Key-DEK 720) can be used to derive the session keys (Auto-Session-Key 732 and DEK-Session-Key 710) for that particular card using the counter (pATC) field of the received message. Ciphertext B 718 may be decrypted using the DEK-Session-KEY, which produces ciphertext A 714 and RND, which may be discarded. The UID field can be used to retrieve the contactless card's shared secret value, which, along with the Ver, UID, and pATC fields of the message, can be processed through a cryptographic MAC using the recreated Auto-Session-Key to produce a MAC output such as MAC'. If the MAC' is the same as the ciphertext A 714, this indicates that the message decryption and MAC checks all pass. The pATC can then be read to determine if it is valid.

[0100] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, the one or more ciphertexts may be generated using ISO 9797-1 algorithm 3 as a 3DESMAC with method 2 padding over one or more session keys, such as Aut-Session-Key 732. Input data 706 may take the following format: version (2), pUID (8), pATC (4), shared secret value (4). In some examples, the number in parentheses may include the length in bytes. In some examples, the shared secret value may be generated by one or more random number generators, which may be configured to ensure that the random numbers are unpredictable, via one or more secure processes. In some examples, the shared secret value may include a random 4-byte binary number injected into the card at a personalization time known by the authentication service. During an authentication session, the shared secret value may not be provided to the mobile application by one or more applets. Padding in Method 2 may include adding a required 0x'80' byte to the end of the input data and possibly adding 0x'00' bytes to the end of the resulting data up to an 8-byte boundary. The resulting ciphertext may be 8 bytes in length.

[0101] 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, allowing for "scrambling" between blocks without the need to pre-establish either a fixed or dynamic IV.

[0102] By including an application transaction counter (pATC) as part of the data included in the MAC ciphertext, the authentication service may be configured to determine whether values ​​communicated in the clear have been tampered with. Furthermore, including the version in one or more ciphertexts makes it difficult for an attacker to intentionally falsify the application version in an attempt to weaken the strength of the cryptographic solution. In some examples, the pATC may start at zero and be updated by one each time one or more applications generate authentication data. The authentication service may be configured to track the pATC used during an authentication session. In some examples, if authentication data uses a pATC that is less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authentication may be rejected. In some examples, if the pATC is greater than a previous value received, it may be evaluated to determine whether it is within an acceptable range or threshold; if it exceeds or is outside the range or threshold, the verification may be considered failed or unreliable. In MAC operation 712, data 706 is processed through a MAC using the Aut-Session-Key 732 to produce an encrypted MAC output (Ciphertext A) 714.

[0103] To provide additional protection against brute force attacks that expose the key on the card, MAC ciphertext 714 is desirably encrypted. In some examples, the data or ciphertext A 714 included in the ciphertext may include a random number (8), ciphertext(8). In some examples, the number in parentheses may include the length in bytes. In some examples, the random number may be generated by one or more random number generators, which may be configured to ensure that the random number is unpredictable via 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 DEK-Session-Key 710. In encryption operation 716, data or ciphertext A 714 and RND are processed using the DEK-Session-Key 510 to generate ciphertext B 718, which is the encrypted data. Data 714 is encrypted using 3DES in cipher block chaining mode to ensure that an attacker must perform any attack across all of the ciphertext. Other algorithms, such as the Advanced Encryption Standard (AES), may also be used, as a non-limiting example. In some instances, an initialization vector of 0x'00000000000000000' can be used. An attacker attempting to brute force the key used to encrypt this data would be unable to determine when the correct key was used, because correctly decrypted data would be indistinguishable from incorrectly decrypted data due to its random appearance.

[0104] In order for the authentication service to verify one or more cryptograms provided by one or more applets, the following data must be communicated in plaintext from one or more applets to the mobile device during an authentication session: a version number to determine the cryptographic approach used and a message format for verifying the cryptogram, allowing for future changes to the approach; a pUID to look up the cryptographic asset and derive the card key; and a pATC to derive the session key used for the cryptogram.

[0105] 8 illustrates a method 800 for generating a ciphertext. 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 the encryption process for authentication. In some examples, the method may include performing authentication and looking up the values ​​of pNPR and pDKI on the contactless card at the time of authentication.

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

[0107] In block 806, the Card-Key-Auth and Card-Key-DEK (Unique Card Key) can be created by diversifying the issuer master key to generate a session key that can be used to generate a MAC ciphertext.

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

[0109] 9 shows an example process 900 illustrating key diversification according to one example. Initially, the sender and receiver may be provisioned 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 data to be protected, that may be protected for sharing with the receiver.

[0110] At 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.

[0111] 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.

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

[0113] The data to be protected 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 MAC is combined with an equal amount of random data, e.g., each 8 bytes in length, and then encrypted using a second session key (DEK-Session-Key).

[0114] At block 910, the encrypted MAC is transmitted from the sender to the receiver along with sufficient information to identify additional secret information (e.g., a shared secret value, a master key, etc.) to verify the ciphertext.

[0115] At block 912, the recipient independently derives two derived session keys from the two master keys using the received counter values, as described above.

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

[0117] 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.

[0118] Some examples of the methods described herein can advantageously confirm when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key was proper. The MAC can be correct only if decryption is successful, resulting in the proper MAC value. Successful decryption can indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Because the derived session key is created 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 created and encrypted the MAC is indeed authentic. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform authentication operations.

[0119] 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 a new set of session keys may be created (at block 910). In some examples, the combined random data may be discarded.

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

[0121] 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 disclosed herein.

[0122] 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 in proximity to 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 assist with card activation, tapping the card may instruct the device to download an associated application for activating the card or prompt the customer to a software application store. In some examples, the user may be prompted to sufficiently gesture, position, or orient the card, such as placing it toward the surface of the device, at an angle, or flat on, near, or in close proximity to the surface of the device. In response to sufficient gesture, positioning, 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.

[0123] At 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.

[0124] At block 1008, one or more servers may decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from the device and decrypt it to compare the received data and record the data accessible to the one or more servers. If the resulting comparison of one or more decrypted portions of the data by the one or more servers results in a successful match, the card may be activated. If the resulting comparison of one or more decrypted portions of the data by the one or more servers results in an unsuccessful match, one or more processes may be performed. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold that includes the number of attempts the user is allowed to make to activate the card. Alternatively, the user may receive a notification on their device, such as a message indicating an unsuccessful attempt to verify the card, and call, email, or text message an associated service for assistance in activating the card, or receive another notification on their device, such as a phone call, indicating an unsuccessful attempt to verify the card, and call, email, or text message an associated service for assistance in activating the card, or receive another notification, such as an email, indicating an unsuccessful attempt to verify the card, and call, email, or text message an associated service for assistance in activating the card.

[0125] In block 1010, the one or more servers may send a return message based on successful activation of the card. For example, the device may be configured to receive an output from the one or more servers indicating successful activation of the card by the one or more servers. The device may also be configured to display a message indicating successful activation of the card. Once the card is activated, the card may be configured to cease dynamic generation of data to prevent fraudulent use. In this way, the card cannot be subsequently activated, and the one or more servers are notified that the card has already been activated.

[0126] 11 shows an example of a data payload 1100 transmitted by a transmitting device, e.g., a network-enabled computer, to a receiving device, e.g., a network-enabled computer. In some examples, the data payload may be transmitted to the receiving device by a tap on the transmitting device or to an intermediate device that transmits the payload to the receiving device. In some examples, the transmitting device may be a contactless card and the receiving device may be a server in data communication directly with the contactless card over a network, via one or more intermediate devices (e.g., a network-enabled computer and / or an ATM).

[0127] The data payload 1100 may include one or more data fields. As shown in FIG. 11 , the data payload 1100 may include an applet version field 1102, an issuer ID field 1104, a unique identifier field 1106, a counter field 1108, and a ciphertext field 1110. In some examples, these fields may be plain text. The applet version field 1102 may include data regarding a version of an applet or other software running on the sending device. In some examples, different applet or software versions may require different personalization and / or validator logic. The issued identifier field 1104 may include data identifying an issuer or other entity associated with the sending device. The unique identifier field 1106 may include data regarding an identifier associated with the sending device, a customer or user, and / or an account associated with the customer or user. The counter field 1108 may include data regarding a counter, which may be in hexadecimal format, for example. The ciphertext field 1110 may include data regarding a ciphertext.

[0128] The data payload 1100 provides several advantages. First, the data payload 1100 provides the data communication, data security, card authentication, and validation advantages described herein. As another example, the inclusion of the issuer ID field 1104 allows the data payload 1100 to be routed to the appropriate issuing entity (or appropriate validator entity, if different from the issuing entity) for validation. This allows the separation of the issuing entity or the entity that performed personalization of the sending device (e.g., the contactless card issuing entity, if the sending device is a contactless card) from the validator entity. Thus, any validator entity authorized to perform validation, not just the issuing entity or the entity that performed personalization of the sending device, can be identified in the issuer ID field 1104.

[0129] As another example, the inclusion of the unique identifier field 1106 allows for a namespace specific to an individual entity, i.e., the unique identifier field 1106 can take the namespace for the issuing entity or validator entity to further provide separation between personalization and validation.

[0130] As mentioned above, data payload 1100 enables routing to a specific entity, such as an issuing entity or a validator entity. A key advantage of data payload 1100 is that this routing is scalable across many messages, many issuing entities, and many validator entities.

[0131] 12 illustrates an example of a system 1200 configured in accordance with the exemplary embodiments discussed herein. The illustrated system 1200 includes one or more systems for supporting personalization and verification of transmitting devices, such as contactless cards. The illustrated system 1200 includes a card system of record (SoR) 1150, a personalization system 1220, a database 1230, a validator system 1240, and a hardware security module (HSM) 1250. While FIG. 12 illustrates a single example of a component, the system 1200 may include any number of components.

[0132] Under certain exemplary applet or application versions, verification may require access to database 1230. In these examples, a new contactless card may be added to database 1230 upon personalization. This dependency between personalization and verification may be undesirable in some examples, such as when the personalization and verification functions are performed by different parties and / or entities. In some examples, a shared secret value may be stored in database 1230.

[0133] Under other exemplary applet or application versions, verification does not require access to database 1230, but instead uses only the data payload and / or data from another message. In these examples, personalization and verification may be separated, and the above dependency may be eliminated. In some examples, existing patterns may be used with EMV. In some examples, a shared secret value is not transmitted between devices and is not recorded in database 1230. Thus, these examples have the advantage that personalization and verification operate independently.

[0134] The following paragraphs describe various examples of functionality that may be implemented in the systems and methods described herein. Several modifications can be made to decouple verification (and the request for access to the database to perform the verification) from the database. First, a key pointer may be included in the data payload transmitted between devices (e.g., between a sending device and a receiving device), and the key pointer may replace the request for a database lookup upon receipt of the data payload. Second, the shared secret value may be modified to be derived from a master key instead of being stored in and looked up from a database. In some examples, modifying the shared secret value is not a change to an applet or other software application. Third, one or more key derivation processes can be modified to avoid and / or stop the use of PSNs.

[0135] In some examples, the shared secret value may be derived from a master key. This may provide several advantages, including eliminating the need to store sending device-level secrets (e.g., card-level secrets) in a database. This may further eliminate the need to communicate shared secret values ​​between devices (e.g., between a sending device and a receiving device). Additionally, this may protect secrets in request data (e.g., contactless card request data) communicated between devices.

[0136] In some examples, the shared secret value can be derived from a third key. The third key can be a key previously used to perform an operation on the sending device and / or the receiving device, or the third key can be a key that has not been used before. In some examples, the shared secret value can be personalized to the applet or other software application as done, thereby avoiding the need to modify the applet or other software application. To minimize the footprint for potential attacks, the shared secret value can be encrypted before involving the sending device.

[0137] In some examples, one or more key derivation processes can avoid or eliminate the use of the PSN. In these examples, the need to look up the PSN from a database to generate a unique diversified key (UDK) is eliminated. This avoids dependency on and retrieval of information from a database. Thus, device personalization and validation (e.g., card personalization and validation) can be performed independently.

[0138] In some examples, instead of being derived from 14 digits of the pUID and PSN, the diversified key can be derived from the master key using 16 digits from the pUID. In these examples, entropy is not reduced, and further, this change can favorably affect personalization, applets or other software, and verification. For example, the encryption master key can be used with 16 digits from the pUID to derive the encryption UDK. As another example, the authentication master key can be used with 16 digits from the pUID to derive the authentication UDK.

[0139] In some examples, a challenge can be incorporated to avoid or reduce the risk of preplay and / or replay attacks. A contactless card can transmit data communications, for example, by NFC, and such communications can be intercepted by other readers, for example, NFC readers, and later replayed to circumvent security requirements. This can be countered by binding the contactless card's transmission, for example, a cryptogram, to the session time (e.g., time and / or device).

[0140] For example, a server (or other network-enabled computer) may generate a challenge, which may be linked to the session. The challenge may be written to the contactless card (e.g., in an applet contained in the contactless card's memory) when the contactless card is in the communication field. The contactless card may use the challenge to generate and / or calculate a cryptogram. Additionally, session validation may be added to the validation logic as part of the validation described herein.

[0141] In some instances, writing a challenge can provide many benefits, including significantly improving security and reducing false positives based on application transaction counter (ATC) issues.

[0142] In some examples, writing the challenge may be implemented by modifying the configuration of the contactless card. For example, the contactless card (e.g., an applet contained in the memory of the contactless card) may be provided with a new internal record containing a new configuration file. The contactless card may be configured to support an optional WRITE BINARY to facilitate sending a challenge to the card. The contactless card may be configured to support processes that include a challenge and processes that do not include a challenge. Additionally, the cryptographic techniques utilized by the contactless card may be configured to support processes that include a challenge and processes that do not include a challenge.

[0143] In some examples, writing the challenge can be implemented by modifying the configuration of one or more software development kits (SDKs) included in contactless cards, client devices, servers, and other network-enabled computers used by the systems and methods described herein. For example, the SDK can be updated to implement NDEF reading at the application protocol data unit (APDU) level. The SDK can be updated to determine the process flow by querying an applet function file. Additionally, the SDK can be updated to request a challenge from the validator.

[0144] In some examples, writing a challenge may be implemented by modifying the configuration of the validator. For example, the validator may be updated to support generating and providing challenges. The validator may be updated to support generating and providing sessions. Additionally, the validator may be updated to support validation policies based on version numbers, including but not limited to applet and / or software version numbers.

[0145] In some examples, additional improvements to data security, authentication, and validation can be made. For example, the use of custom NFC specifications can expedite performance and simplify the NFC protocol. The use of dormant applets can enable volume deployment prior to commercial agreement with an issuing entity (e.g., a contactless card issuing entity). The use of a signed hash of the card product customer identifier can simplify policy decisions, which can enable confirmation of instances owned by the appropriate customer without a mapping file that associates identifiers (e.g., unique identification numbers) with customer numbers. The use of a centralized validator, such as a key in a hub, can enable a light-touch deployment model to the issuing entity (e.g., for production readiness). Additionally, the use of general-purpose cryptography (e.g., root of trust) can enable deployment on general-purpose cloud hardware security modules (HSMs).

[0146] 13 illustrates a distributed network authentication system 1300 according to an example embodiment. As discussed further below, the system 1300 may include a client node 1302, an API 1304, a network 1306, a distributed ledger node 1310, a mapping 1312, and a client device 1314. While FIG. 13 illustrates a single example of a component, the system 1300 may include any number of components.

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

[0148] In some examples, client node 1302 may execute one or more applications, such as, for example, software applications that enable network communication with one or more components of system 1300, send and / or receive data, and perform the functions and processes described herein.

[0149] The client node may include an API 1304. For example, various 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 (e.g., a smartphone, smartwatch, tablet, laptop, or other device) interacts with a web-based service by invoking the API 1304 to interact with the service, such as by making a remote call to the API to interact with the web-based service.

[0150] The API 1304 may be provided in the form of a library containing specifications of routines, data structures, object classes, and variables. In some cases, such as a representative state transition (REST) ​​service, the API (e.g., a REST API or RESTful API, or an API embodying some RESTful practices) is a specification of remote calls exposed to API consumers (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 (e.g., a distributed hypermedia system).

[0151] Client node 1302 can communicate with one or more other components of system 1300 directly or through network 1306. Network 1306 can include one or more of a wireless network, a wired network, or any combination of wireless and wired networks and can be configured to connect the components of system 1300. While FIG. 13 shows communication between components of system 1300 through network 1306, it will be understood that any component of system 1300 can communicate directly with another component of system 1300, for example, without involving network 1306.

[0152] The system 1300 can include a validation node 1308, which can be a network-enabled computer as described herein. In some examples, the validation node 1308 can be a server, which can be a dedicated server computer, a blade server, or can be a personal computer, laptop computer, notebook computer, palmtop computer, network computer, mobile device, wearable device, or any processor-controlled device capable of supporting the system 1300.

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

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

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

[0156] In some examples, the distributed ledger node 1310 may execute one or more applications, such as, for example, software applications that enable network communication with one or more components of the system 1300, send and / or receive data, and perform the functions and processes described herein.

[0157] The distributed ledger node 1310 may include a mapping 1312. In some examples, the mapping 1312 may be in the form of one or more databases. Exemplary databases may include, but are not limited to, relational databases, non-relational databases, hierarchical databases, object-oriented databases, network databases, and any combination thereof. The one or more databases may be centralized or distributed. The one or more databases may be hosted internally by any component of the system 1300, or the one or more databases may be hosted externally to any component of the system 1300. In some examples, the one or more databases may be included in the distributed ledger node 1310; in other examples, the one or more databases may be stored external to the distributed ledger node 1310 but may be in data communication with the distributed ledger node 1310. 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 Data Acquisition and Reporting Language, Extensible Markup Language, and Common Gateway Interface. Queries made to one or more databases can 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 made to the databases can be made in SQL (e.g., SELECT column1,column2 FROM table1,table2 WHERE column2='value';). It will be understood that one or more databases can be implemented in any database programming language, and that the programming implementation of the queries can be tailored as needed for compatibility with one or more databases and to reflect the particular information to be queried.

[0158] In some examples, the one or more databases may be included within the distributed ledger node 1310. In other examples, the one or more databases may be remote from the distributed ledger node 1310 but may be in data communication with the distributed ledger node 1310. The data communication between the one or more databases and the distributed ledger node 1310 may be direct data communication or data communication over a network, such as network 1306.

[0159] In some examples, the client node 1302 can be in data communication with a distributed ledger node 1310. The distributed ledger node 1310 can include mappings 1312. The mappings 1312 can include, for example, a mapping between a validating node address and the validating node 1308, a mapping between a routing number and the validating node address, and / or a mapping between a routing number and the validating node 1308. In some examples, the mappings 1312 can include a digital signature associated with an entity authorized to verify the routing number. Based on one or more of these associations, the client node 1302 can invoke the validating node for validation and / or provide instructions to the client device to reach the appropriate validating node. This can be accomplished by invoking a verification API associated with the validating node 1308.

[0160] In some examples, iterations of the mappings described herein, such as mapping 1312, 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 among multiple validating addresses for a single validating node.

[0161] In some examples, client nodes 1302 and distributed ledger nodes 1310 can be authorized (e.g., allowed to participate in the network) with the help of certificates and / or cryptographic authentication mechanisms (e.g., non-fungible tokens). The certificates and / or cryptographic authentication mechanisms may be issued, for example, by a consortium authority or other administrative entity associated with the distributed network. Given appropriate authority, the distributed ledger node 1310 can update the mapping 1312 to reflect, for example, different associations between routing numbers, validator node addresses, and validators. In some examples, tiered authority can be issued. For example, a client node 1302 can be granted a certain level of authority if it functions to route data to the validator node 1308 (or other validator node). As another example, a distributed ledger node 1310 can have a different, higher level of authority if it has the ability to update the mapping 1312.

[0162] The system 1300 can include a client device 1314, which can be a network-enabled computer as described herein. In some examples, the distributed ledger node 1314 can be a server, which can be a dedicated server computer, a blade server, or can be a personal computer, laptop computer, notebook computer, palmtop computer, network computer, mobile device, wearable device, or any processor-controlled device capable of supporting the system 1300. The client device 1314 can also be a mobile device, for example, a mobile device may include an Apple® iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device. In some examples, the client device 1314 can communicate data with another network-enabled computer not shown in FIG. 13 , such as a smart card (e.g., a contactless or contact-based card).

[0163] In some examples, client device 1314 may execute one or more applications, such as, for example, software applications that enable network communication with one or more components of system 1300, send and / or receive data, and perform the functions and processes described herein.

[0164] In some examples, upon receiving the authentication request, the client device 1314 may call the client node 1302 (e.g., via an API). The call may include a routing number and / or applet or software version number, and the client node 1302 may query the distributed ledger node 1310 and mapping 1312. If the query returns the identity of the validator node (e.g., validator node 1308) and / or validator node address associated with that routing number and / or applet or software version, the client node 1302 may respond to the client device 1314. The client device 1314 may then proceed with authentication with the validator node. Authentication may be performed by the systems and methods described herein, for example, by generating, encrypting, transmitting, decrypting, and verifying ciphertext, etc., as described herein.

[0165] In some examples, the client node 1302 may be co-located with the verification node 1308. In these examples, the client node 1302 may handle the authentication with a single call from the client device 1314. In some examples, this may only be acceptable if the entire authentication transmission (e.g., the ciphertext described herein) is allowed to be sent to a client node that is not involved in the authentication.

[0166] In some examples, if the client node 1302 receives a routing number from the client device 1314 that has not been processed by its location, the client node 1302 may return a code indicating that the routing number has not been processed, along with the validator node address of the responsible validator node. The client device 1314 may send the entire authentication transmission to the validator node 1308 using the received validator node address.

[0167] In some examples, a client node 1302 can enter the distributed network with different permissions. For example, the client node 1302 can be a read-only router for data. As another example, the client node 1302 can have the authority to send messages to the distributed ledger node 1310 to update one or more routing paths for one or more routing numbers. However, the client node 1302 is prevented from updating one or more routing paths for one or more routing numbers for other entities that control other routing numbers not associated with the client node 1302 or that did not grant this authority. As another example, the distributed ledger node 1310 can include contracts and / or records that can verify the authority of a particular entity to modify a particular routing record based on its digital signature. As another example, a consortium authority or other administrative entity that controls the distributed network can have additional privileges, including, but not limited to, adding new members (e.g., client nodes, distributed ledger nodes, validator nodes, and / or client devices), adding new signing credentials, adding new keys, adding new certificates, and also revoking any of the foregoing. In some examples, if security, legal, and / or financial conditions are met, the aforementioned authority may be delegated to the client node 1302, the distributed ledger node 1310, and / or the validator node 1308, although delegation is not required.

[0168] In some examples, one or more APIs can facilitate communication between components of system 1300 over network 1306. In other examples, one or more APIs are not required. Rather, components of system 1300 can communicate directly with and / or be dedicated to one or more designated entities, allowing the designated entities to prevent data from being transferred to, from, or through undesignated entities. This can further promote data security and avoid detection of data traffic patterns by undesignated entities.

[0169] In some examples, an entity 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 node 1308 for authentication may require storing the keys in one or more HSMs to promote key security and ensure that the keys never enter memory.

[0170] 14 illustrates a method 1400 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 1300 and / or by another distributed network authentication system.

[0171] In block 1402, 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 via an API call or other communication between the client device and the client node.

[0172] In block 1404, 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, to which the distributed ledger node may send the query.

[0173] At block 1406, the query may return the validator node's ID and / or validator node address, and the distributed ledger node may send this ID to the client node.

[0174] The client node may transmit the ID to the client device at block 1408. After receiving the ID, the client device may proceed to authenticate with the identified validator node and / or validator node address at block 1410.

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

[0176] As used herein, the terms “system” and “component” are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing computer architecture 1500. 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. By way of 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 the communication media. Information may be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections, example connections including parallel interfaces, serial interfaces, and bus interfaces.

[0177] Computing architecture 1500 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 with computing architecture 1500.

[0178] 15, computing architecture 1500 includes a processor 1512, a system memory 1504, and a system bus 1506. Processor 1512 may be any of various commercially available processors.

[0179] The system bus 1506 provides the processor 1512 with an interface for system components, including, but not limited to, the system memory 1504. The system bus 1506 can be any of several types of bus structures that can be further interconnected 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 can be connected to the system bus 1508 via a slot architecture. Exemplary slot architectures 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.

[0180] Computing architecture 1500 may include or be implemented in a variety of articles of manufacture. The article 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 also be implemented at least in part as instructions contained in or 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.

[0181] The system memory 1504 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 (e.g., USB memory, solid-state drives (SSDs), and any other type of storage medium suitable for storing information. In the illustrated embodiment shown in FIG. 15 , the system memory 1504 may include nonvolatile 1508 and / or volatile 1510. A basic input / output system (BIOS) may be stored in the nonvolatile 1508.

[0182] The computer 1502 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 1530, a magnetic disk drive 1516 that reads from and writes to a removable magnetic disk 1520, and an optical disk drive 1528 that reads from and writes to a removable optical disk 1532 (e.g., a CD-ROM or DVD). The hard disk drive 1530, the magnetic disk drive 1516, and the optical disk drive 1528 may be connected to the system bus 1506 by an HDD interface 1514, a FDD interface 1518, and an optical disk drive interface 1534, respectively. The HDD interface 1514 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0183] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. A number of program modules may be stored on the drives and in nonvolatile 1508 and volatile 1510, including, for example, an operating system 1522, one or more applications 1542, other program modules 1524, and program data 1526. In one embodiment, the one or more applications 1542, other program modules 1524, and program data 1526 may include, for example, various applications and / or components of the systems discussed herein.

[0184] A user can enter commands and information into the computer 1502 through one or more wired / wireless input devices, such as a keyboard 1550 and a pointing device such as a mouse 1552. Other input devices can 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 (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 1512 through an input device interface 1536 coupled to the system bus 1506, but can also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0185] A monitor 1544 or other type of display device is also connected to the system bus 1506 via an interface, such as a video adapter 1546. The monitor 1544 may be internal or external to the computer 1502. In addition to the monitor 1544, a computer typically includes other peripheral output devices such as speakers, printers, etc.

[0186] The computer 1502 can operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as remote computer(s) 1548. The remote computer(s) 1548 can be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment appliance, a peer device, or other common network node, and typically includes many or all of the elements described relative to the computer 1502, although for purposes of brevity, only a memory and / or storage device 1558 is shown. The logical connections shown include wired / wireless connections to a local area network 1556 and / or larger networks, e.g., a wide area network 1554. Such LAN and WAN networking environments are commonplace in offices and businesses and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

[0187] When used in a local area network 1556 networking environment, the computer 1502 is connected to the local area network 1556 through a wired and / or wireless communication network interface or adapter 1538. The network adapter 1538 can facilitate wired and / or wireless communication to the local area network 1556, and the local area network may also include a wireless access point disposed thereon to communicate with the wireless functionality of the network adapter 1538.

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

[0189] The computer 1502 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 over-the-air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, communication can be in a predefined structure, similar to a traditional network, or simply 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).

[0190] The various elements of a device such as those 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, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory 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, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the decision 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 desired for a given implementation.

[0191] 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. Furthermore, 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."

[0192] 16 is a block diagram illustrating an exemplary communications architecture 1600 suitable for implementing various embodiments as described above. Communications architecture 1600 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 implementation with communications architecture 1600, which may be consistent with the systems and devices discussed herein.

[0193] 16, communication architecture 1600 includes one or more client(s) 1602 and server(s) 1604. The server(s) 1604 can implement one or more features and embodiments discussed herein. The client(s) 1602 and server(s) 1604 are operatively connected to one or more respective client data store(s) 1606 and server data store(s) 1608 that can be employed to store information local to the respective client(s) 1602 and server(s) 1604, such as cookie(s) and / or associated contextual information.

[0194] The client(s) 1602 and server(s) 1604 can communicate information with each other using a communication framework 1610. The communication framework 1610 can implement any well-known communication technology and protocol. The communication framework 1610 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., the public switched telephone network), or a combination of packet-switched and circuit-switched networks (with appropriate gateways and converters).

[0195] The communications framework 1610 can implement various network interfaces configured to accept, communicate, and connect to communications networks. A network interface can be considered a specialized form of input / output (I / O) interface. The network interfaces can 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 can be used to participate in various communications network types. For example, multiple network interfaces can be used to enable communications over broadcast, multicast, and unicast networks. If processing requirements dictate a greater amount of speed and capacity, a distributed network controller architecture can similarly be used to pool, load balance, and otherwise increase the communications bandwidth needed by the client(s) 1602 and server(s) 1604. The communications network may be any one and combination of wired and / or wireless networks, including, but not limited to, direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operating missions as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communications networks.

[0196] It should be noted that the systems and methods described herein may be tangibly embodied in one of several 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 data storage. For example, a data storage device may include a random access memory (RAM) and a read-only memory (ROM) that may be configured to access and store data and information as well as computer program instructions. A data storage device may also include a storage medium or other suitable type of memory (e.g., RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, flash drive, any type of tangible non-transitory storage medium, etc.) and may store files including an operating system, application programs including, for example, a web browser application, an email application, and / or other applications, as well as data files. The data storage of a network-enabled computer system may include electronic information, files, and documents stored in a variety of ways, including, for example, flat files, indexed files, hierarchical databases, relational databases such as databases created and maintained with software from, for example, Oracle® Corporation, Microsoft® Excel files, Microsoft® Access files, solid-state storage devices that may include flash arrays, hybrid arrays, or server-side products, enterprise storage that may include online or cloud storage, or any other storage mechanism. Additionally, the diagrams show various components (e.g., servers, computers, processors, etc.) separately.Functionality described as being performed by various components may be performed by other components, various components may be combined or separated, and other variations may be made.

[0197] In some aspects, the technology described herein relates to a distributed network authentication system including: a client node; and a distributed ledger node in data communication with the client node, the distributed ledger including a database storing mappings; the client node configured to receive authentication requests from the client device and to send queries to the distributed ledger node in response to the authentication requests; and the distributed ledger node configured to receive the queries from the client node, send the queries to the database, receive from the database in response to the queries at least one identity selected from the group of validator nodes and validator node addresses, and send the identity to the client node.

[0198] In some aspects, the technology described herein relates to a distributed network authentication system, wherein the client node is further configured to transmit an ID to the client device.

[0199] In some aspects, the technology described herein relates to a distributed network authentication system, further including a validator node, the validator node configured to communicate with client devices and to perform authentication related to authentication requests.

[0200] In some aspects, the technology described herein relates to a distributed network authentication system, wherein a validator node is associated with a validator node address.

[0201] In some aspects, the technology described herein relates to a distributed network authentication system, wherein the authentication includes at least one selected from the group of a routing number, a software version number, and an applet version number.

[0202] In some aspects, the technology described herein relates to a distributed network authentication system, wherein an authentication request includes an application programming interface (API) call between a client device and a client node.

[0203] In some aspects, the technology described herein relates to a distributed network authentication system, wherein the mapping includes at least one selected from the group of a mapping between a validator node address and a validator node, a mapping between a routing number and a validator node address, and a mapping between a routing number and a validator node.

[0204] In some aspects, the technology described herein relates to a distributed network authentication system, where the mapping includes a digital signature associated with an entity, and the entity is authorized to verify a particular routing number.

[0205] In some aspects, the technology described herein relates to a distributed network authentication system, wherein the mapping includes at least one selected from the group of a software version number and an applet version number.

[0206] In some aspects, the technology described herein relates to a distributed network authentication system, wherein at least one selected from the group of a software version number and an applet version number identifies a validating node.

[0207] In some aspects, the technology described herein relates to a distributed network authentication system, wherein at least one selected from the group of a software version number and an applet version number identifies a validating node address.

[0208] In some aspects, the techniques described herein relate to a method performed by a distributed network authentication system including a client node and a distributed ledger node, the method including: the client node receiving an authentication request from a client device; in response to the authentication request, the client node sending a query to the distributed ledger node; the distributed ledger node receiving the query from the client node; the distributed ledger node sending the query to a database; the distributed ledger node receiving at least one identity selected from a group of validating nodes and validating node addresses from the database in response to the query; and the distributed ledger node sending the identity to the client node.

[0209] In some aspects, the technology described herein relates to a method, wherein the distributed network authentication system further includes a validation node, the method further including the client device communicating with the validation node, and the validation node performing authentication associated with the authentication request.

[0210] In some aspects, the technology described herein relates to a method, wherein a validator node includes a hardware security module storing one or more keys, and wherein authentication is performed using the one or more keys.

[0211] In some aspects, the technology described herein relates to a method, further including a client node sending a message to a distributed ledger node updating one or more routing paths for one or more routing numbers.

[0212] In some aspects, the technology described herein relates to a method, in which a client node is assigned one or more authorities that enable updating of one or more routing paths for one or more routing numbers.

[0213] In some aspects, the technology described herein relates to a method, wherein one or more privileges are assigned to one or more entities associated with a client node, the one or more entities being associated with one or more routing paths for one or more routing numbers.

[0214] In some aspects, the technology described herein relates to a method, further including a distributed ledger node verifying one or more authorities before updating one or more routing paths for one or more routing numbers.

[0215] In some aspects, the technology described herein relates to a non-transitory computer-readable medium including instructions for execution by a distributed network authentication system including a distributed ledger node including a database, the instructions, when executed, causing the distributed network authentication system to perform a procedure including receiving a query from a client node; sending the query to the database; receiving at least one identity selected from the group of validator nodes and validator node addresses from the database in response to the query; and sending the identity to the client node.

[0216] In some aspects, the technology described herein relates to a non-transitory computer-readable medium, wherein the distributed network authentication system further includes a client node, and the method further includes the client node receiving an authentication request from a client device, and in response to the authentication request, the client node sending a query to the distributed ledger node.

[0217] The present disclosure is not limited with respect to the specific embodiments described herein, but is intended as an illustration of various aspects. As will be apparent, many modifications and variations can be made without departing from its spirit and scope. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of the present disclosure may be apparent from the foregoing exemplary description. The steps described herein need not be performed in the same order or with the same degree of separation as discussed. Similarly, various steps can be omitted, repeated, or combined, as necessary to achieve the same or similar purpose. Such modifications and variations are intended to be included within the scope of the appended exemplary claims. The present disclosure is to be limited only by the terms of the appended exemplary claims, along with the full scope of equivalents to which such exemplary claims are entitled. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting.

[0218] In the foregoing specification, various preferred embodiments have been described with reference to the accompanying drawings. However, it may be apparent that various modifications and changes can be made to the various embodiments, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense, rather than a restrictive sense.

Claims

1. 1. A distributed network authentication system, comprising: A client node; a distributed ledger node in data communication with the client node, the distributed ledger including a database storing the mapping; Equipped with The client node: Receives an authentication request from a client device; Sending a query to the distributed ledger node in response to the authentication request. It is configured as follows: The distributed ledger node: receiving the query from the client node; sending the query to the database; receiving at least one identifier (ID) selected from the group of a validating node and a validating node address from the database in response to the query; Sending the ID to the client node It is configured as follows: A distributed network authentication system.

2. The distributed network authentication system of claim 1 , wherein the client node is further configured to transmit the ID to the client device.

3. The verification node further comprises: The verification node: communicating with the client device; Perform authentication regarding the authentication request It is configured as follows: The distributed network authentication system of claim 1 .

4. The distributed network authentication system of claim 3 , wherein the validator node is associated with the validator node address.

5. The distributed network authentication system of claim 1 , wherein the authentication includes at least one selected from the group of a routing number, a software version number, and an applet version number.

6. The distributed network authentication system of claim 1 , wherein the authentication request comprises an application programming interface (API) call between the client device and the client node.

7. 2. The distributed network authentication system of claim 1, wherein the mapping comprises at least one selected from the group of a mapping between the validator node address and the validator node, a mapping between a routing number and the validator node address, and a mapping between a routing number and the validator node.

8. the mapping includes a digital signature associated with the entity; The entity is authorized to validate a particular routing number; The distributed network authentication system of claim 1 .

9. The distributed network authentication system of claim 1 , wherein the mapping includes at least one selected from the group of a software version number and an applet version number.

10. 10. The distributed network authentication system of claim 9, wherein the at least one selected from the group of a software version number and an applet version number identifies the validating node.

11. 10. The distributed network authentication system of claim 9, wherein the at least one selected from the group of a software version number and an applet version number identifies the validating node address.

12. 1. A method performed by a distributed network authentication system including a client node and a distributed ledger node, comprising: receiving an authentication request from a client device at the client node; In response to the authentication request, the client node sends a query to the distributed ledger node; receiving the query from the client node by the distributed ledger node; the distributed ledger node sending the query to the database; the distributed ledger node receiving from the database in response to the query at least one identity selected from the group of a validating node and a validating node address; transmitting the ID by the distributed ledger node to the client node; A method comprising:

13. The distributed network authentication system further comprises the verification node; The method comprises: the client device communicating with the validator node; the validating node performing authentication related to the authentication request; further comprising: The method of claim 12.

14. the validator node comprises a hardware security module storing one or more keys; the authentication is performed using the one or more keys; The method of claim 13.

15. 13. The method of claim 12, further comprising the client node sending a message to the distributed ledger node updating one or more routing paths for one or more routing numbers.

16. The method of claim 15 , wherein the client node is assigned one or more authorities that enable the updating of the one or more routing paths for the one or more routing numbers.

17. the one or more privileges are assigned to one or more entities associated with the client node; the one or more entities are associated with the one or more routing paths for the one or more routing numbers; 17. The method of claim 16.

18. 20. The method of claim 17, further comprising the distributed ledger node verifying the one or more authorities before updating the one or more routing paths for one or more routing numbers.

19. 1. A non-transitory computer-readable medium comprising instructions for execution by a distributed network authentication system comprising a distributed ledger node including a database, the instructions, when executed, causing the distributed network authentication system to: receiving a query from a client node; sending the query to the database; receiving from the database in response to the query at least one identity selected from the group of a validating node and a validating node address; transmitting the ID to the client node; A non-transitory computer-readable medium for carrying out a procedure including:

20. A non-transitory computer-readable medium, comprising: The distributed network authentication system further comprises the client node; The procedure comprises: receiving an authentication request from a client device at the client node; In response to the authentication request, the client node sends the query to the distributed ledger node; and further comprising: Non-transitory computer-readable medium.

Images