Key recovery based on contactless card authentication

Abstract

A system, method, apparatus, and computer readable medium for key recovery based on contactless card cryptography. A server may receive a request from an application to recover a private key for a digital wallet, the request including a first cryptogram generated by the contactless card. The server may decrypt the first cryptogram based on a key for the contactless card. The server may determine a unique identifier for the contactless card and a diversification factor associated with the digital wallet based on the decryption. The server may generate a private key based on the unique identifier and the diversification factor. The server may transmit the private key to the application over a network.

Description

[Technical field]

[0001] This application claims priority to U.S. patent application Ser. No. 17 / 551,670, entitled "Key Recovery Based on Contactless Card Authentication," filed on December 15, 2021. The contents of the aforementioned application are incorporated herein by reference in their entirety. [Background technology]

[0002] Digital wallets offer many advantages, but they also pose security and privacy challenges. The most common risks include theft and loss (or forgetting) of access keys. Additionally, custodial wallets are tied to a specific institution and do not allow portability. Proxy wallets are at risk of security breaches and theft, which could compromise access keys. Hardware wallets may provide recovery seeds, but these seeds are prone to theft and other types of loss (for example, if the user cannot remember the seed or find a record of the seed). Summary of the Invention

[0003] Systems, methods, apparatus, and computer readable media for contactless card authentication based key recovery. In one aspect, the method comprises: receiving, by a server, a request from an application to recover a private key for the digital wallet, the request including a first cryptogram generated by the contactless card; the server decrypting the first ciphertext based on the contactless card key; the server determining, based on the decryption, a unique identifier for the contactless card and a diversification factor associated with a digital wallet within a hardware security module; the server generating the private key based on the unique identifier and the diversification factor; the server transmitting the private key to the application over a network; Includes.

[0004] To easily identify the description of a particular element or act, the most significant digit(s) of a reference number refers to the number of the figure in which that element is first introduced. [Brief description of the drawings]

[0005] [Figure 1A] FIG. 1A illustrates one aspect of the subject matter according to one embodiment. [Figure 1B] FIG. 1B illustrates one aspect of the subject matter according to one embodiment. [Figure 1C] FIG. 1C illustrates one aspect of the subject matter according to one embodiment. [Figure 2A] FIG. 2A illustrates one aspect of the subject matter according to one embodiment. [Figure 2B] FIG. 2B illustrates one aspect of the subject matter according to one embodiment. [Figure 2C] FIG. 2C illustrates one aspect of the subject matter according to one embodiment. [Figure 3A] FIG. 3A illustrates one aspect of the subject matter according to one embodiment. [Figure 3B] FIG. 3B illustrates one aspect of the subject matter according to one embodiment. [Figure 4] FIG. 4 illustrates a routine 400 according to one embodiment. [Diagram 5] FIG. 5 illustrates a routine 500 according to one embodiment. [Figure 6] FIG. 6 illustrates a routine 600 according to one embodiment. [Figure 7A] FIG. 7A illustrates a contactless card according to one embodiment. [Figure 7B] FIG. 7B illustrates a contactless card 104 according to one embodiment. [Figure 8] FIG. 8 illustrates a data structure 800 according to one embodiment. [Figure 9] FIG. 9 illustrates an example of a system 900 according to an embodiment. [Figure 10]FIG. 10 illustrates an example of a logical model 1000 according to an embodiment. [Figure 11] FIG. 11 illustrates an example of a logical model 1100 according to an embodiment. [Figure 12] FIG. 12 illustrates a computer architecture 1200 according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006]

[0005] Embodiments disclosed herein provide techniques for securely recovering cryptographic keys used to access digital wallets, such as cryptocurrency wallets, using contactless cards. To create a digital wallet, a computing device may instruct a contactless card to generate a cryptogram. An application executing on the computing device may receive the cryptogram via wireless communication with the contactless card and send the cryptogram to a server for verification. Once the server verifies the cryptogram, the server may create a private key necessary to access or perform operations using the digital wallet. The server may then create a public key corresponding to the private key and generate a wallet address for the digital wallet based on the public key. The server may then store in a hardware security module (HSM) one or more inputs to the cryptographic algorithm used to create the private key. The inputs may include one or more keys associated with the contactless card, a unique identifier for the contactless card, and a diversification factor. In some embodiments, the key is stored in the HSM while the unique identifier and diversification factor may be provided as inputs to the HSM to diversify the private key (e.g., the unique identifier and diversification factor do not need to be stored in the HSM).

[0007] The server may securely transmit the private key, public key, and wallet address to the application, which may generate a digital wallet and store therein the private key, public key, and wallet address. In some embodiments, when a user attempts to access the digital wallet, cryptographic verification using a contactless card may be used to authenticate access to the digital wallet. If the cryptographic verification is not successful, the user may be restricted from accessing the wallet, increasing wallet security.

[0008] Because an obfuscated version of the private key is stored in the digital wallet, a user may lose, forget, or otherwise be unable to provide the private key as a prerequisite for performing a transaction (e.g., cryptocurrency transfer) with the digital wallet. Advantageously, embodiments disclosed herein provide a secure solution for recovering a private key using a contactless card. Typically, to recover a private key, the contactless card may generate a cryptogram that is verified by a server. If the server is able to verify the cryptogram, the input used to generate the private key may be provided to the HSM. The server may then recreate the private key and send the recreated private key in one or more parts to the requesting application and / or device.

[0009] Advantageously, embodiments disclosed herein provide a secure technique for recovering a private key used to access a digital wallet using cryptography generated by a contactless card. By utilizing cryptograms, embodiments of the present invention may securely verify a user's identity while minimizing the risk of fraud. Furthermore, doing so ensures that the private key is only recovered if the user has access to a contactless card that facilitates cryptographic verification with the server. Furthermore, by requiring cryptographic verification as a prerequisite for accessing the digital wallet or recovering the private key, the security of the digital wallet is enhanced.

[0010] Generally referring to the notation and nomenclature used herein, the detailed descriptions herein may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to effectively convey the substance of their work to others skilled in the art.

[0011] The steps here are generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0012] Further, the manipulations performed are often expressed in terms, such as adding or comparing, which are typically associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations forming part of one or more of the embodiments described herein. Rather, the operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers or similar devices.

[0013] Some embodiments may be described using the terms "coupled" and "connected" and their derivatives. These terms are not necessarily intended as synonyms. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0014] Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may comprise a computer, either specially constructed for the required purposes, or selectively activated or reconfigured by a computer program stored in the computer. The procedures presented herein are not inherently related to any particular computer or other apparatus. Programs written in accordance with the teachings herein may employ a variety of machines, although it may also be convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description.

[0015] Referring now to the drawings, like reference numerals are used to refer to like elements throughout the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. However, it is possible to practice the novel embodiments without these specific details. In other instances, structures and devices are shown in block diagram form for ease of explanation. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

[0016] In the figures and accompanying description, "a," "b," "c" (and similar designators) are intended to be variables representing any positive integers. Thus, for example, if an implementation sets the value of a to 5, then a complete set of components 123, denoted as components 123-1 through 123-a (or 123a), may include components 123-1, 123-2, 123-3, 123-4, and 123-5. The embodiments are not limited in this context.

[0017] 1A illustrates an exemplary computing architecture, also referred to as a system, 100 consistent with disclosed embodiments. Although computing architecture 100 illustrated in FIGS. 1A-1C includes a limited number of elements in a particular topology, it will be understood that computing architecture 100 may include more or fewer elements in alternative topologies as needed for a particular implementation.

[0018] The computing architecture 100 includes one or more computing devices 102, one or more servers 106, and one or more contactless cards 104. The contactless cards 104 represent any type of card, such as a credit card, a debit card, an ATM card, a gift card, a payment card, a smart card, etc. The contactless cards 104 may include one or more communication interfaces 124, such as a radio frequency identification (RFID) chip, configured to communicate with a communication interface 124 (also referred to herein as a “card reader,” “wireless card reader,” and / or “wireless communication interface”) of the computing device 102 via NFC, the EMV standard, or other short-range protocols for wireless communication. Although NFC is used herein as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and / or Wi-Fi.

[0019] Computing device 102 represents any number and type of computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, a virtualized computing system, a merchant terminal, a point-of-sale system, a server, a desktop computer, etc. A mobile device may be used as an example of computing device 102, but is not considered to be limiting of the present disclosure. Server 106 represents any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, etc. Although not shown for clarity, computing device 102, contactless card 104, and server 106 each include one or more processor circuits for executing programs, codes, and / or instructions.

[0020] As shown, the memory 108 of the contactless card 104 includes an applet 110, a counter 116, one or more master keys 114, one or more diversified keys 120, a unique ID 112, a Primary Account Number (PAN) sequence number 156, and one or more Unique Derived Keys (UDKs) 118. The unique ID 112 is any identifier that uniquely identifies the contactless card 104 compared to other contactless cards 104. The PAN sequence 156 may include a counter value stored by the contactless card 104. The applet 110 is executable code configured to perform some or all of the operations described herein. The counter 116 is a value that is synchronized between the contactless card 104 and the server 106. The counter 116 may comprise a numerical value that changes each time data is exchanged between the contactless card 104 and the server 106 (and / or the contactless card 104 and the computing device 102). The counter 116, the master key 114, the diversified key 120, the UDK 118, the PAN sequence 156, and / or the unique ID 112 are used to provide security for the system 100, as described in more detail below.

[0021] As shown, memory 132 of computing device 102 includes an instance of operating system 134. Examples of operating systems include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, operating system 134 includes account application 136. Account application 136 allows a user to perform various account-related operations, such as managing a digital wallet, processing transactions using a wallet, processing blockchain and / or cryptocurrency transactions, activating a payment card, viewing account balances, purchasing items, processing payments, and the like. In some embodiments, a user authenticates using authentication credentials to access certain features of account application 136. For example, authentication credentials may include a username (or login) and password, biometric credentials (fingerprint, Face ID, etc.), and the like.

[0022] As shown, the memory 126 of the server 106 includes an authentication application 138 and an account database 128. The account database 128 typically includes information related to an account holder (e.g., one or more users), the account holder's one or more accounts, and the account's one or more contactless cards 104.

[0023] As previously discussed, the account application 136 may be used to create, manage, access, or otherwise use a digital wallet. A digital wallet allows one party to conduct electronic transactions with another party. In some embodiments, the digital wallet is a cryptocurrency wallet that stores private and / or public keys for cryptocurrency. The cryptocurrency may be any type of cryptocurrency, such as Bitcoin, Ethereum, etc. To create a digital wallet, a user must authenticate to the account using authentication credentials. The account application 136 then prompts the user to tap the contactless card 104 to the computing device 102.

[0024] In the embodiment shown in FIG. 1A, a user may tap contactless card 104 to computing device 102 (or bring contactless card 104 within communication range of communication interface 124 of device 102). Account application 136 then instructs applet 110 to generate ciphertext 122. Ciphertext 122 may be generated based on any suitable encryption technique. In some embodiments, ciphertext 122 may be based on unique ID 112 of contactless card 104. In some embodiments, applet 110 may include ciphertext 122 and an unencrypted identifier (e.g., counter 116, PAN sequence 156, unique ID 112, and / or other unique identifiers) as part of a data package that includes ciphertext 122. In at least one embodiment, the data package is an NDEF file.

[0025] As mentioned above, the computing architecture 100 is configured to implement key diversification to protect data, which may be referred to herein as a key diversification technique. In general, the server 106 (or other computing device) and the contactless card 104 may be provisioned with the same master key 114 (also referred to as a master symmetric key). More specifically, each contactless card 104 is programmed with an individual master key 114 with a corresponding pair within a hardware security module (HSM) 130 of the server 106. For example, when the contactless card 104 is manufactured, a unique master key 114 may be programmed into the memory 108 of the contactless card 104. Similarly, the unique master key 114 may be stored in a record 142 within the HSM 130.

[0026] Additionally, when a particular card 104 is manufactured, the UDK 118 may be diversified from the master key 114 via an HSM function that takes as input a diversification factor and a reference to a master key 114 index in the HSM 130 (e.g., an index into record 142). In some embodiments, the diversification factor may be the unique ID 112 and the PAN sequence 156 of the contactless card 104. The UDK 118 may be stored in the contactless card 104 and in record 142 in the HSM 130. The master key 114 and the UDK 118 may be kept private from all parties other than the contactless card 104 and the server 106, thereby enhancing the security of the system 100. Although shown as stored in record 142, in some embodiments the counter 116 and / or the PAN sequence 156 are not stored in the HSM 130. For example, the unique ID 112, the counter 116, and the PAN sequence 156 may be stored in the account database 128.

[0027] In some embodiments, to generate the ciphertext 122, the applet 110 may provide the UDK 118, the unique ID 112, and the diversification factor as inputs to an encryption algorithm, thereby generating the diversified key 120. In some embodiments, the diversification factor is the counter 116. In other embodiments, the PAN sequence 156 is the diversification factor. The diversification key 120 may be used to encrypt some data, such as the diversification factor (e.g., the counter 116 and / or the PAN sequence 156) or other sensitive data. The applet 110 and the server 106 may be configured to encrypt the same types of data to facilitate the ciphertext decryption and / or verification process.

[0028] As mentioned above, the UDK 118 of the contactless card 104 and the server 106 may be used in combination with the counter 116 to enhance security using key diversification. As mentioned above, the counter 116 is configured with a value that is synchronized between the contactless card 104 and the server 106. The counter 116 may include a numerical value that changes each time data is exchanged between the contactless card 104 and the server 106 (and / or the contactless card 104 and the computing device 102). When preparing to transmit data (e.g., the server 106 and / or the device 102), the applet 110 of the contactless card 104 may increment the counter 116. The applet 110 of the contactless card 104 provides the UDK 118, the unique ID 112, and the counter 116 as inputs to an encryption algorithm, which generates the diversified key 120 as an output. The encryption algorithms include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of encryption algorithms include symmetric encryption algorithms such as 3DES and AES107, symmetric HMAC algorithms such as HMAC-SHA-256, symmetric CMAC algorithms such as AES-CMAC, and the like. Examples of key diversification techniques are described in detail in U.S. patent application Ser. No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety. In some embodiments, the PAN sequence 156 is used as an input to the encryption algorithm instead of the counter 116, e.g., the diversified key 120 is generated by encrypting the UDK 118, the unique ID 112, and the PAN sequence 156.

[0029] The applet 110 then uses the diversified key 120 and the data as inputs to an encryption algorithm to encrypt some of the data (e.g., the unique ID 112, the counter 116, the PAN sequence 156, the command, and / or other data). For example, encrypting the unique ID 112 with the diversified key 120 may generate an encrypted unique ID 112 (e.g., ciphertext 122). As previously mentioned, the applet 110 and the server 106 may be configured to encrypt the same data.

[0030] In some embodiments, the two diversified keys 120 may be generated based on, for example, one or more portions of the input to the encryption function. In some embodiments, the two diversified keys 120 may be generated based on two different master keys 114, two different UDKs 118, the unique ID 112, and the counter 116 (or the PAN sequence 156). In such embodiments, a message authentication code (MAC) may be generated using one of the diversified keys 120, and the MAC may be encrypted using the other one of the diversified keys 120. The MAC may be generated based on any suitable data input to the MAC algorithm, such as the secret data, the unique ID 112, the counter 116, and / or the PAN sequence 156. More generally, the applet 110 and the server 106 may be configured to generate the MAC based on the same data. In some embodiments, the ciphertext 122 is included in a data package, such as an NDEF file. The account application 136 may then read the data package including the ciphertext 122 via the communication interface 124 of the computing device 102.

[0031] 1B illustrates an embodiment in which the account application 136 sends the ciphertext 122 to the server 106. The server 106 may provide the ciphertext 122 to the authentication application 138 and / or HSM 130 for validation, at least in part, based on an instance of the master key 114 and / or UDK 118 stored by the server 106. In some embodiments, the authentication application 138 and / or HSM 130 may use the unencrypted unique ID 112 provided to the server 106 to identify the UDK 118 (or master key 114) and counter 116. In an example in which the PAN sequence 156 is used to generate the ciphertext 122, the server 106 may use the unencrypted unique ID 112 to identify the PAN sequence 156 in the account database 128 and / or HSM 130. In some examples, the authentication application 138 provides the UDK 118, the unique ID 112, and the counter 116 as inputs to an encryption function of the HSM 130, which generates one or more diversified keys 120 as outputs. In other embodiments, the server encrypts the UDK 118, the unique ID 112, and the PAN sequence 156 to generate the diversified key 120. The resulting diversified key 120, which may correspond to the diversified key 120 of the contactless card 104, may be used to decrypt the ciphertext 122 and / or verify the decrypted MAC. For example, the server 106 may generate a MAC based on the same data as the applet 110, e.g., the secret data, the unique ID 112, the counter 116, and / or the PAN sequence 156. If the MAC generated by the server 106 matches the decrypted MAC in the ciphertext 122, the server 106 may verify or authenticate the ciphertext 122.

[0032] Regardless of the decryption technique used, the authentication application 138 and / or HSM 130 may successfully decrypt the ciphertext 122 and verify the MAC to verify or authenticate the ciphertext 122. If the decryption and / or MAC verification are successful, the authentication application 138 and / or HSM 130 may generate a digital wallet 144 for the user. Generally, creating a digital wallet 144 requires the generation of a private key 146. In some embodiments, a random number is provided as input to an encryption (or hash) algorithm, such as the SHA-2 algorithm or other suitable algorithm, to generate a private key 146 of any length. In other embodiments, the unique ID 112 of the contactless card 104 and the PAN sequence 156 are concatenated and provided as input to a hash algorithm to generate the private key 146. In other embodiments, the unique ID 112 of the contactless card 104 and the counter 116 are concatenated and provided as input to a hash algorithm to generate the private key 146.

[0033] In other embodiments, the master key 114, the unique ID 112, and the counter 116 of the contactless card 104 are concatenated and provided as inputs to a hashing algorithm to generate the private key 146. In embodiments in which the master key 114 is used to generate the private key 146, the first master key 114 of the contactless card 104 may be used to generate the ciphertext 122 and the second master key 114 of the contactless card 104 may be used to generate the private key 146, where the first master key 114 and the second master key 114 are different keys. In other embodiments, one of the diversification keys 120, the unique ID 112, and the counter 116 of the contactless card 104 are concatenated and provided as inputs to a hashing algorithm to generate the private key 146. In other embodiments, one of the UDKs 118, the unique ID 112, and the counter 116 of the contactless card 104 are concatenated and provided as inputs to a hashing algorithm to generate the private key 146. Regardless of the input used to generate the private key 146, in some embodiments, the input to the hashing algorithm to generate the private key 146 includes a salt (e.g., random data).

[0034] The private key 146 may then be used to generate a corresponding public key 148. In some embodiments, the public key 148 may be generated based on the private key 146 using an Elliptic Curve Digital Signature Algorithm (ECDSA). In some embodiments, the public key 148 may be concatenated (or compressed), for example, using a hashing algorithm. In some embodiments, a salt is used to generate the public key 148. A wallet address 150 may be generated for the digital wallet 144 based on the public key 148, for example, by hashing the public key 148. Although the digital wallet 144 is shown as being stored in the HSM 130, in some embodiments, the digital wallet 144 is not persistently stored in the HSM 130. Instead, elements used to recreate the private key 146 may be stored in the HSM 130 and / or the account database 128, as described in more detail herein. For example, the unique ID 112 and the counter 116 may be stored in the HSM 130 and / or the account database 128. In another example, the unique ID 112 and the PAN sequence 156 may be stored in the HSM 130 and / or the account database 128.

[0035] In some embodiments, the private key 146 and / or the public key 148 may be further diversified, for example to create hierarchical deterministic keys. For example, the private key 146 may be diversified using the counter 116, the unique ID 112, the salt value 154, or other predefined seed value. In doing so, the private key 146 may be diversified. Similarly, the public key 148 may be diversified using the counter 116, the unique ID 112, the salt value 154, or other predefined seed value to create a diversified public key 148. In such an embodiment, any seed value used to diversify the private key 146 and / or the public key 148 may be stored in the recovery record 152 of the account database 128 and / or the HSM 130. More generally, the private key 146 and / or the public key 148 may be diversified using a seed value multiple times, thereby generating a tree (or hierarchy) of diversified private keys 146 and / or diversified public keys 148. In such embodiments, one or more paths in the tree (or hierarchy) may be used to specify different diversified keys. More generally, each node in the tree may correspond to a diversified public key and / or a diversified child key. Given the private and public keys of a node in the tree, one may derive the diversified private and public keys of all descendant nodes in the tree. Additionally, each leaf node in the tree may correspond to a diversified public key and / or a diversified child key. In some embodiments, the paths are further used to specify attributes of the transaction, such as the currency, the amount of the currency, the first wallet address of the transaction (e.g., the sending wallet address), the second wallet address of the transaction (e.g., the recipient wallet address), and other attributes. These attributes may be stored in a particular node in the tree.

[0036] Returning to decryption, if the authentication application 138 is unable to decrypt the ciphertext 122 (and / or is unable to verify the MAC), then the authentication application 138 does not verify the ciphertext 122. In such an instance, the authentication application 138 may decide to refrain from generating a digital wallet. The authentication application 138 may send an indication of the failed decryption and / or verification to the computing device 102.

[0037] 1C illustrates an embodiment in which the authentication application 138 transmits the digital wallet 144 to the computing device 102. As shown, the account application 136 transmits the digital wallet 144, which includes a private key 146, a public key 148, and a wallet address 150. (Memory 132 and / or non-volatile storage (not shown for clarity). The account application 136 may hash, encrypt, or otherwise obfuscate the private key 146, the public key 148, and / or the wallet address 150. The account application 136 may protect the digital wallet 144 using authentication controls, such as a username and password, biometric information, etc. Additionally and / or alternatively, the account application 136 may require cryptographic decryption and / or verification using the contactless card 104 in order to access the digital wallet 144 (e.g., the contactless card 104 generates a cryptogram that is verified by the server 106 as described herein). Further, in some embodiments, the account application 136 may require the user to provide the private key 146 in order to access or perform operations using the digital wallet 144. More generally, the account application 136 may provide various interfaces for accessing, using, and otherwise managing the digital wallet 144.

[0038] In some embodiments, the digital wallet 144 may be stored in a cloud-based wallet, such as, for example, the server 106 or another computing system that provides a cloud-based wallet service to a client. The embodiments are not limited in this context. The cloud-based wallet may provide an interface for accessing and otherwise using the digital wallet 144, for example, via the account application 136.

[0039] As shown, the server 106 has created a recovery record 152 in the account database 128 based on the creation of the digital wallet 144. The recovery record 152 includes the unique ID 112, the diversification factor 158 (e.g., counter 116 and / or PAN sequence 156), and the salt 154 (if used) for generating the private key 146. In some embodiments, the recovery record 152 may be indexed based on the wallet address 150 of the wallet 144. In other embodiments, the recovery record 152 may be indexed based on the record 142 of the HSM 130 that stores the key for the contactless card 104. In other embodiments, the recovery record 152 is indexed based on the unique ID 112 of the contactless card 104. The recovery record 152 may then be used to recreate the private key 146, for example, based on the unique ID 112, the diversification factor 158, and / or the salt 154 and an appropriate algorithm. In embodiments where the diversification key 120, UDK 118, or master key 114 are used to generate the private key 146, advantageously, to improve security, the diversification key 120, UDK 118, or master key 114 are not stored in the recovery record 152. In such embodiments, the HSM 130 stores the master key 114, UDK 118, and / or diversification key 120 used to recreate the private key 146, while the unique ID 112, diversification factor 158, and / or salt 154 may be stored in the account database 128.

[0040] 2A is a schematic diagram 200 illustrating an embodiment in which a user requests recovery of a private key 146. As shown, to recover the private key 146, the account application 136 instructs the user to tap the contactless card 104 to the computing device 102, which causes the contactless card 104 to generate a cryptogram 208. The cryptogram 208 may be generated as described above with reference to the cryptogram 122. For example, the applet 110 may increment the counter 116 and encrypt one or more of the UDK 118, the unique ID 112, and the counter 116 to generate one or more diversified keys 120. The one or more diversified keys 120 may be used to generate a MAC based on some data and to encrypt the MAC and / or the data. In some embodiments, a MAC is generated based on the wallet address 150 and one of the diversified keys 120. In such an embodiment, the wallet address 150 and the MAC are encrypted using another one of the diversified keys 120 to generate the cryptogram 208. As another example, the public key 148 may be used to generate a MAC and then the public key 148 may be encrypted with the MAC.

[0041] 2B illustrates an embodiment in which the account application 136 sends the ciphertext 208 to the server 106 for verification. In general, the server 106 may increment the counter 116 and encrypt the UDK 118 of the contactless card 104, the unique ID 112, and the counter 116 to generate one or more diversified keys 120 that correspond to the keys generated by the contactless card 104. The one or more diversified keys 120 may be used to decrypt the ciphertext 208 and / or verify the MAC.

[0042] If the server 106 can decrypt the ciphertext 208 and / or verify the MAC, the server 106 may recreate the private key 146 based on the recovery record 152. In embodiments where the wallet address 150 is encrypted with the ciphertext 208, the recovery record 152 may be indexed (e.g., searched for) based on the wallet address 150, and the server 106 may access the recovery record 152 using the decrypted wallet address 150. In embodiments where the public key 148 is encrypted with the ciphertext 208, the server 106 may recreate the wallet address 150 using the public key 148 and index the account database 128 using the regenerated wallet address 150. In other embodiments, the account database 128 is indexed using the unique ID 112 to identify the recovery record 152. In such embodiments, the unique ID 112 is determined based on an unencrypted version of the unique ID 112 included in the ciphertext 208.

[0043] Once the server 106 identifies the recovery record 152, it may use the recovery record 152 to recreate the private key 146. For example, the unique ID 112, diversification factor 158, and salt 154 (if used) of the recovery record 152 may be provided as inputs to a function of the HSM 130 used to initially create the private key 146. In this way, the private key 146 is recreated.

[0044] In some embodiments, the server 106 further recreates the private key 146 based on the master key 114 or the UDK 118. For example, the server 106 may provide the master key 114 of the contactless card 104 and data in the recovery record 152 (e.g., the unique ID 112, the diversification factor 158, the optional salt 154) as inputs to a function of the HSM 130 used to create the private key 146. In this way, the private key 146 is recreated. As another example, the server 106 may provide the UDK 118 of the contactless card 104 and data in the recovery record 152 (e.g., the unique ID 112, the diversification factor 158, the optional salt 154) as inputs to a function of the HSM 130 used to create the private key 146. In this way, the private key 146 is recreated.

[0045] In some embodiments, the UDK 118, the unique ID 112, the diversification factor 158, and any salt 154 are input into a function of the HSM 130 to generate a diversified key 120 that is used to generate the private key 146. The diversified key 120, the diversification factor 158, and any salt 154 may be provided as inputs to a function of the HSM 130 to recreate the private key 146.

[0046] On the other hand, if HSM 130 is unable to decrypt ciphertext 122 and / or unable to verify the MAC, HSM 130 does not verify ciphertext 122. In such an example, authentication application 138 decides to refrain from recovering private key 146. Authentication application 138 may send an indication of the failed decryption and / or MAC verification to computing device 102. In such an embodiment, the user is restricted from using recovery record 152 to recover private key 146.

[0047] FIG. 2C illustrates an embodiment in which the HSM 130 recreates the private key 146 based on the recovery record 152 and transmits the private key 146 to the account application 136. In some embodiments, the server 106 may transmit the private key 146 in one or more data portions. More generally, the server 106 may transmit the private key 146 using a secure connection with the computing device 102. The computing device 102 may then display the private key 146 and allow the user to recover the private key 146. The user may then use the private key 146 to perform one or more operations using the digital wallet 144 and / or any cryptocurrency associated with the digital wallet 144. For example, the private key 146 may be used to generate a transaction in the blockchain 906.

[0048] In some embodiments, the private key 146 is not transmitted to the computing device 102. For example, in a cloud-based wallet embodiment, the private key 146 may be used to sign a transaction or other type of data. In such an example, a user may authenticate their account with the account application 136 using account authentication credentials and provide details of the intended transaction (e.g., a purchase, a cryptocurrency transfer, etc.). The account application 136 may provide the transaction details to the server 106. In some embodiments, the account application 136 provides the transaction details in a ciphertext and / or a data package that includes the ciphertext. The ciphertext may be similar to the ciphertext 122 and / or the ciphertext 208. The server 106 may then obtain the data used to diversify the key from the recovery record 152 (e.g., the unique ID 112, the counter 116, the PAN sequence 156, and / or the salt 154). The data from the recovery record 152 is provided to the HSM 130, which uses the data from the recovery record and the master key 114 and / or the UDK 118 to generate a digital signature for the transaction. In this way, the necessary signature is generated for the transaction. For example, the public key 148 can be used to verify the transaction by generating a valid signature. In such an example, the transaction may be added to the blockchain to reflect the verified transaction.

[0049] 3A is a schematic diagram 300a illustrating an embodiment of tapping a contactless card 104 to a computing device 102, for example to recover a private key 146. As described above, when the contactless card 104 is tapped to the computing device 102, the applet 110 may generate a ciphertext (e.g., ciphertext 122 and / or ciphertext 208). The ciphertext and other data (e.g., unencrypted unique ID 112) may be included in a data package, such as an NDEF file, that is read by the computing device 102. The computing device 102 may then transmit the ciphertext to the server 106 for verification (e.g., decryption and / or MAC verification) as described herein.

[0050] FIG. 3B is a schematic diagram 300b illustrating an embodiment in which the server 106 verifies the ciphertext generated in FIG. 3A. Based on the verification, the server 106 may recreate the private key 146 based on the recovery record 152. The server 106 may then transmit the private key 146 to the account application 136. As shown, the account application 136 displays the private key 146 as a string of characters on a display. In some embodiments, a matrix code 302 may be generated to represent the private key 146. The matrix code 302 may then be scanned to determine the private key 146.

[0051] The operation of the disclosed embodiments may be further described with reference to the following figures. Some of the figures may include logic flows. Although the figures presented herein may include specific logic flows, it will be appreciated that the logic flows are merely providing examples of how the general functionality described herein may be implemented. Furthermore, unless otherwise indicated, the specific logic flows do not necessarily have to be performed in the order presented. Furthermore, in some embodiments, not all operations shown in the logic flows are required. Furthermore, a given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. The embodiments are not limited in this context.

[0052] 4 illustrates an embodiment of a logic flow or routine 400. Logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 400 may include some or all of the operations for creating a digital wallet. The embodiments are not limited in this context.

[0053] At block 402, the server 106 may receive a request to generate a digital wallet from the account application 136 running on the computing device 102. The request may include a ciphertext generated by the contactless card 104 and sent to the computing device 102. At block 404, the server may decrypt the ciphertext by generating one or more diversified keys 120 based on the master key 114, the UDK 118, and the counter 116. The server 106 may further validate the ciphertext, for example, to determine whether a MAC generated by the server 106 matches a MAC in the decrypted ciphertext.

[0054] At block 406, the server 106 generates a private key 146 based on successful decryption and / or verification of the ciphertext at block 404. The private key 146 may be based on inputs to the encryption function of the HSM 130. The inputs may include the unique ID 112 and a diversification factor 158 (e.g., the counter 116 and / or the PAN sequence 156 of the contactless card 104). In some embodiments, the inputs may further include the master key 114, the UDK 118, and / or the diversification key 120. At block 408, the server 106 may generate a public key 148 based on the private key 146. The server may further create a wallet address 150 for the digital wallet 144 based on the public key 148. At block 410, the server may send the private key 146, the public key 148, and the wallet address 150 to the application. In block 412, the server 106 stores the one or more inputs used to generate the private key in the account database 128 (eg, the unique ID 112 and the diversification factor 158).

[0055] 5 illustrates an embodiment of a logic flow or routine 500. Logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 500 may include some or all of the operations for accessing a digital wallet. The embodiments are not limited in this context.

[0056] At block 502, the routine 500 receives, by the server 106, a request from an account application 136 executing on the computing device 102 to access the digital wallet 144, including a ciphertext. At block 504, the server 106 may decrypt the ciphertext by generating one or more diversified keys 120 based on the master key 114, the UDK 118, and the counter 116. The server 106 may further verify the ciphertext, for example, determining whether a MAC generated by the server 106 matches a MAC in the decrypted ciphertext. At block 506, the server may generate an authentication based on the successful decryption and verification. The authentication typically indicates that the requested access to the digital wallet 144 is permitted. At block 508, the server sends the authentication to the account application 136. The authentication causes the account application 136 to grant the requested access to the digital wallet 144. However, in some embodiments, a private key 146 is further required to access the digital wallet 144.

[0057] 6 illustrates an embodiment of a logic flow or routine 600. Logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 600 may include some or all of the operations for recovering a private key for a digital wallet. The embodiments are not limited in this context.

[0058] At block 602, the routine 600 receives a request by the server 106 from the account application 136 to recover the private key 146 of the digital wallet 144. The request may include a ciphertext generated by the contactless card 104 based on the key diversification (e.g., based on the master key 114, the UDK 118, and one or more diversification keys 120). At block 604, the server 106 may decrypt the ciphertext by generating one or more diversification keys 120 based on the master key 114, the UDK 118, and the counter 116. The server 106 further validates the ciphertext, for example, to determine whether a MAC generated by the server 106 matches a MAC in the decrypted ciphertext.

[0059] At block 606, the server 106 may determine the unique ID 112 of the contactless card 104 and the diversification factor 158 (e.g., the counter 116 and / or the PAN sequence 156) in the account database 128 based on the decryption and verification. At block 608, the server 106 recreates the private key 146 based on the unique ID 112, the diversification factor 158, and the optional salt 154. In some embodiments, the server 106 recreates the private key 146 based on the master key 114, the unique ID 112, the diversification factor 158, and the optional salt 154. In some embodiments, the server 106 recreates the private key 146 based on the UDK 118, the unique ID 112, the diversification factor 158, and the optional salt 154. In some embodiments, the server 106 recreates the private key 146 based on the diversification key 120, the unique ID 112, the diversification factor 158, and the optional salt 154. In block 610, the server 106 transmits the recreated private key 146 over the network to the account application 136.

[0060] FIG. 7A is a schematic diagram 700 illustrating an example configuration of a contactless card 104, which may include a payment card, such as a credit card, debit card, or gift card issued by a service provider, which may display a service provider mark 702 on the front or back of the contactless card 104. In some examples, the contactless card 104 may not be related to a payment card and may include, but is not limited to, an identification card. In some examples, transaction cards may include dual interface contactless payment cards, loyalty cards, and the like. The contactless card 104 includes a substrate 704, which may include a single layer or one or more laminated layers composed of plastic, metal, or 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 104 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard and the transaction card may conform to the ISO / IEC 14443 standard. However, it is understood that a contactless card 104 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.

[0061] The contactless card 104 may also include identification information 706 displayed on the front and / or back of the card, and a contact pad 708. The contact pad 708 may include one or more pads and may be configured to establish a connection with another client device, such as an ATM, a user device, a smartphone, a laptop, a desktop, or a tablet computer, via 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 104 may also include processing circuitry, an antenna, and other components, as further described in FIG. 7B. These components may be located behind the contact pad 708 or elsewhere on the substrate 704 (e.g., in another layer of the substrate 704) and electrically and physically coupled to the contact pad 708. The contactless card 104 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 7A). The contactless card 104 may also include a near field communication (NFC) device coupled with an antenna capable of communicating via an NFC protocol. The embodiment is not limited to this method.

[0062] 7B, the contact pad 708 of the contactless card 104 may include processing circuitry 710 for storing, processing, and communicating information, including a processor 712, memory 108, and one or more communication interfaces 124. It is understood that the processing circuitry 710 may include additional components such as processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware necessary to perform the functions described herein.

[0063] The memory 108 may be read-only, write-once, or read / write memory, such as RAM, ROM, EEPROM, etc., and the contactless card 104 may include one or more of these memories. Read-only memory may be programmed at the factory as read-only or one-time programmable. One-time programming provides the opportunity to write once and read many times. Write-once / read-multiple times memory may be programmed at a time after the memory chip leaves the factory. Once programmed, the memory cannot 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 be read many times after leaving the factory. In some cases, the memory 108 may be an encrypted memory that encrypts data using an encryption algorithm executed by the processor 712.

[0064] The memory 108 may be configured to store one or more applets 110, one or more counters 116, a unique ID 112, a master key 114, a UDK 118, a diversified key 120, and a PAN sequence 156. The one or more applets 110 comprise one or more software applications configured to run on the one or more contactless cards 104, such as a Java Card applet. However, it is understood that the applet 110 is not limited to a Java Card applet and may be any software application operable on a contactless card or other memory-limited device. The one or more counters 116 may include a numeric counter sufficient to store an integer number. The unique ID 112 comprises a unique alphanumeric identifier assigned to the contactless card 104 that distinguishes the contactless card 104 from other contactless cards 104. In some examples, the unique ID 112 may identify both a customer and an account assigned to the customer.

[0065] Although the processor 712 and memory elements of the foregoing example embodiments are described with reference to the contact pad 708, the disclosure is not limited thereto. It will be appreciated that these elements may be implemented external to the contact pad 708, may be implemented entirely separately, or may be implemented as additional elements in addition to the processor 712 and memory 108 elements disposed within the contact pad 708.

[0066] In some examples, the contactless card 104 may include one or more antennas 714. The one or more antennas 714 may be disposed within the contactless card 104 and around the processing circuitry 710 on the contact pads 708. For example, the one or more antennas 714 may be integrated with the processing circuitry 710, or the one or more antennas 714 may be used with an external booster coil. As another example, the one or more antennas 714 may be external to the contact pads 708 and the processing circuitry 710.

[0067] In one embodiment, the coil of the contactless card 104 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 104 by interrupting or amplitude modulating power. The contactless card 104 may infer data transmitted from the terminal using gaps in the power connection of the contactless card 104 that are functionally maintained through one or more capacitors. The contactless card 104 may transmit communication back by switching or load modulating the load of the coil of the contactless card 104. Load modulation may be detected at the coil of the terminal due to interference. More generally, using the antenna 714, the processor 712, and / or the memory 108, the contactless card 104 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0068] As described above, the contactless card 104 may be built on a software platform capable of running on a smart card or other memory-limited device, such as a Java Card, to securely execute one or more applications or applets. An applet 110 may be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 110 may be configured to respond to one or more requests (e.g., a near-field data exchange request) from a reader, such as a mobile NFC reader (e.g., the mobile computing device 102 or a POS terminal), and generate an NDEF message that includes the encrypted, secure OTP encoded as an NDEF text tag. The NDEF message may include a ciphertext, such as ciphertext 122 or ciphertext 208, or other data.

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

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

[0071] In some examples, the contactless card 104 and the server may include specific data so that the card is properly identified. The contactless card 104 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 116 may be configured to increment. In some examples, each time data from the contactless card 104 is read (e.g., by a mobile device), the counter 116 is sent to the server for validation, and it is determined (as part of the validation) whether the counter 116 is equal to the server's counter.

[0072] One or more counters 116 may be configured to prevent replay attacks. For example, if a cryptogram is captured and replayed, it will be immediately rejected if the counter 116 is read, used, or otherwise passed on. If the counter 116 is not used, it may be replayed. In some examples, the counter incremented on the contactless card 104 is different from the counter incremented for the transaction. Because there is no communication between the applets 110 on the contactless card 104, the contactless card 104 cannot determine the application transaction counter 116. In some examples, the contactless card 104 may include a first applet 440-1, which is a transaction applet, and a second applet 440-2. Each applet 440-1 and 440-2 may include a counter 116.

[0073] In some examples, the counter 116 may become out of sync. In some examples, considering an accidental read that initiates a transaction, such as an oblique read, the counter 116 may increment but the application may not process the counter 116. In some examples, when the device 102 is powered up, NFC is enabled and the computing device 102 may be configured to read available tags, but no action is taken in response to the read.

[0074] To keep the counter 116 in sync, an application such as a background application is executed and configured to detect when the computing device 102 has started and advance the counter 116 in sync with a server of the banking system, which detects that a read has occurred. In another example, a hashed one-time password may be utilized and a window of incorrect synchronization may be accommodated. For example, the counter 116 may be configured to advance if within a threshold of 10. However, if within a different threshold number, such as 10 or 600, a request to perform a re-synchronization may be processed, as requested via one or more applications that the user taps, gestures, or otherwise indicates via the device one or more times. When the counter 116 increments in the proper order, the user may know that the operation has been performed.

[0075] The key diversification technique described herein with reference to counter 116, master key 114, UDK 118, and diversification key 120 is one example of an encryption and / or decryption key diversification technique. This example key diversification technique applies to other types of key diversification techniques as well, and is not to be considered limiting of the disclosure.

[0076] During the contactless card 104 creation process, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may consist of symmetric keys that can be used to both encrypt and decrypt data. In EMV, the Triple DES (3DES) algorithm may be used, which is implemented by the contactless card 104 hardware. 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.

[0077] In some examples, to overcome deficiencies in the 3DES algorithm that may be susceptible to vulnerabilities, a session key may be derived (such as a unique key per session), but rather than using a master key, a unique card derivation key (such as UDK118) and a counter may be used as diversification data. For example, each time the contactless card 104 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 is generated by one or more applets and derived using an application transaction counter with one or more algorithms (EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation Definition).

[0078] Additionally, the increment for each card is unique and may be assigned by personalization or algorithmically by some identifying information. For example, odd cards may increment by 2 and even cards may increment by 5. In some instances, the increment may also change with successive reads, such that one card may increment by 1, 3, 5, 2, 2, … and so on and so forth. The specific sequence or algorithmic sequence may be defined at the time of personalization or may be defined from one or more processes derived from the unique identifier. This makes it difficult for a replay attacker to generalize from a small number of card instances.

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

[0080] FIG. 8 illustrates an NDEF short record layout (SR=1) data structure 800 according to one embodiment. One or more applets 110 may be configured to encode the OTP as a text tag of known type in NDEF type 4. In some examples, an NDEF message is composed of one or more records. An applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include: tag type: known type, text, encoded English (en); applet ID: D2760000850101; function: read-only access; encoding: authentication message may be encoded as ASCII hex; type-length-value (TLV) data may be provided as a personalization parameter that may be used to generate the NDEF message, including but not limited to: a first record with a known index to provide the actual dynamic authentication data. Data structure 800 may include ciphertext, such as ciphertext 122 and ciphertext 208, and other data provided by applet 110.

[0081] 9 illustrates a schematic diagram of an example system 900 consistent with disclosed embodiments. The system 900 may comprise a system that can access a blockchain 906 via a network 902.

[0082] The system 900 may generate a trustless record of interactions using a blockchain 906. Additionally, the blockchain 906 may be distributed across multiple computing systems, providing increased confidence in the validity of the records stored in the blockchain 906. Thus, the disclosed system provides an innovative technical solution to at least the above-mentioned technical problems in conventional systems.

[0083] The user system 904 may include a computing device 102. The user system 904 may be configured to process transactions using the digital wallet 144 according to the disclosed embodiments. The user system 904 may be comprised of a computing device such as a server, a workstation, a desktop, or a mobile device (such as a laptop, a tablet, a phablet, a smartphone, a smartwatch, or a similar mobile computing device). As described below with respect to FIG. 12, the user system 904 may be configured with a display and an input / output interface. The user system 904 may be configured to interact with a user (not shown) using the display and the input / output interface.

[0084] The member system 908 may be configured to process transactions according to the disclosed embodiments. The member system 908 may include one or more computing devices, such as a server, a workstation, a desktop computer, or a dedicated computing device. The member system 908 may be standalone or may be part of a subsystem, which may be part of a larger system. For example, the member system 908 may be associated with a commercial institution. The member system 908 may include distributed servers that are remotely located and communicate with other systems of the financial institution over a public network or a dedicated private network.

[0085] The member system 908 may be configured to receive a request to process a transaction using the cryptocurrency in the digital wallet 144. In some embodiments, the member system 908 may be configured to receive the request from another element of the system 900, such as another member system 908 or a user system 904. The member system 908 may be configured to interact with the blockchain 906 to process the transaction request.

[0086] The member system 908 may be configured to store the message in the blockchain 906 according to disclosed embodiments. In some aspects, the member system 908 may be configured to add a block containing the message to the blockchain 906. In various aspects, the member system 908 may be configured to provide the message to an authorized system. The authenticated system may be configured to add a block containing the message to the blockchain 906. The message may include a transaction record, as described below with respect to FIG. 10.

[0087] The blockchain 906 may comprise a distributed data structure consistent with disclosed embodiments. The blockchain 906 may be a private blockchain. For example, authorized systems may store a copy of the blockchain 906. These authorized systems may be configured to add blocks to the blockchain 906 and publish the blocks to other authorized systems. The authorized systems may be configured to receive messages from other systems for publishing to the blockchain 906. These other systems may have read-only access to the blockchain 906. In some embodiments, one or more of the member systems 908 are authorized systems. In some embodiments, one or more of the user systems 904 are authorized systems. As described in detail with respect to FIG. 9, the blockchain 906 may be configured to store messages (including transactions) from the member systems.

[0088] Network 902 may be configured to provide communication between the components of Figure 9. For example, network 902 may be any type of network (including infrastructure) that provides communication, exchanges information, and / or facilitates information exchange, such as the Internet, a local area network, or other suitable connection that enables authentication system 900 to send and receive information between components of authentication system 900.

[0089] FIG. 10 illustrates a logical model 1000 of an example blockchain 906 consistent with disclosed embodiments. The blockchain 906 may comprise a number of such blockchains maintained by many different systems (e.g., member systems 908 or other systems). Such an example blockchain may comprise blocks, such as block 1006a through block 1006d. The blocks may include messages, such as message 1008a through message 1008d. In general, the blocks may include a header (such as headers 1002a through 1002d) that uniquely identifies each block. The headers 1002a through 1002d may include a hash value generated by a hash function. A hash function is a function that can be used to map input data of any size to a fixed-size hash value. For example, the header may include at least one of a hash value of the previous block, a hash value generated based on the messages in the block (such as a Merkle root), and a timestamp. Consistent with disclosed embodiments, the system 900 may require that blocks added to the blockchain 906 satisfy at least one of a proof-of-work condition and a digital signature condition. For example, the headers 1002a-1002d may include a nonce selected to ensure that the header satisfies the proof-of-work conditions 1004a-1004d. As a non-limiting example, the proof-of-work conditions 1004a-1004d may require that the hash of the header falls within a predetermined range of values. As an additional example, the header may be digitally signed using an authenticated system cryptographic key (e.g., private key 146), and the digital signature may be included in the header. This digital signature may be verified using a key available to members of the system 900.

[0090] FIG. 11 illustrates a logical model 1100 of a message 1008b stored in a blockchain (e.g., an element of blockchain 906) consistent with disclosed embodiments. In some embodiments, the message 1008b may comprise index information 1102. In certain aspects, the index information 1102 may comprise information identifying a user. For example, the index information 1102 may be at least one of the user's full name, email address, phone number, or other non-sensitive personal information. In various aspects, the index information 1102 may include one or more references to a previous block in a private blockchain. For example, the index information 1102 may include one or more references to one or more previous blocks associated with the same user. The references may include, by way of non-limiting example, a hash of a previous block in the blockchain associated with the same user. In some aspects, the index information 1102 may be obfuscated or encrypted according to methods known to those of skill in the art. For example, the index information 1102 may be encrypted using a cryptographic key, such as the private key 146. As a further example, the index information 1102 may comprise a hash of at least one of the user's full name, email address, phone number, or other non-sensitive personal information.

[0091] The message 1008b may comprise additional information 1104, according to disclosed embodiments. The additional information 1104 may include transaction details, such as the amount of cryptocurrency to be transferred from one digital wallet 144 to another digital wallet 144. In various aspects, the additional information 1104 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, the root system information 1104 may be encrypted using an encryption key, such as the private key 146.

[0092] Message 1008b may comprise an authentication record 1106, consistent with disclosed embodiments. In some aspects, authentication record 1106 may comprise information that enables a subsequent audit of the transaction. For example, authentication record 1106 may identify at least one of the member system 908, the commercial entity associated with member system 908, and the purpose of authentication record 1106 (e.g., transaction details). In some aspects, authentication record 1106 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, authentication record 1106 may be encrypted using an encryption key, such as private key 146.

[0093] Consistent with disclosed embodiments, an encryption key, such as private key 146, may be used to encrypt elements of a message in a block. In some aspects, such encryption keys may be associated with members of the authentication system 900 (e.g., member system 908). In various aspects, at least some encryption keys may be associated with an authenticated system. Consistent with disclosed embodiments, a corresponding encryption key, such as public key 148, may be used to decrypt encrypted message elements. For example, if an element of a message in a block is encrypted with a symmetric key, the same symmetric key may be used to decrypt the encrypted element. As another example, if an element of a message in a block is encrypted with private key 146, the corresponding public key 148 may be used to decrypt the encrypted element. In some aspects, the corresponding encryption key may be available to a member of the authentication system (e.g., member system 908).

[0094] 12 illustrates an embodiment of an exemplary computer architecture 1200 suitable for implementing various embodiments described above. In one embodiment, computer architecture 1200 may include or be implemented as part of computing architecture 100.

[0095] The terms "system" and "component" as used in this application are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 1200. 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. As an example, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer or distributed across two or more computers. Furthermore, components can be communicatively coupled to each other by various types of communication media to coordinate operations. Coordination can include unidirectional or bidirectional information exchange. For example, components can communicate information in the form of signals communicated over the communication media. Information can be implemented as signals assigned to various signal lines. In such an assignment, each message becomes a signal. However, in further embodiments, a data message can be used instead. Such data messages may be transmitted over a variety of connections. Example connections include parallel interfaces, serial interfaces, and bus interfaces.

[0096] Computer architecture 1200 may include various common computing elements such as one or more processors, multi-core processors, co-processors, memory units, chip sets, 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 computer architecture 1200.

[0097] 12, the computer architecture 1200 includes a computer 1212 that includes a processor 1202, a system memory 1204, and a system bus 1206. The processor 1202 may be any of a variety of processors commercially available. The computer 1212 may represent the computing device 102 and / or the server 106.

[0098] The system bus 1206 provides an interface for system components including the system memory 1204 to the processor 1202. The system bus 1206 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 connect to the system bus 1206 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0099] Computer architecture 1200 may include or be implemented in a variety of articles of manufacture. The articles of manufacture may include a computer readable storage medium for storing logic. Examples of computer readable storage media include any tangible medium capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or re-writable memory. 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, and the like. An embodiment may also be implemented, at least in part, as instructions contained in a non-transitory computer readable medium, which may be read and executed by one or more processors to perform the operations described herein.

[0100] The system memory 1204 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 (USB memory, solid state drives (SSD), etc.), and other types of storage media suitable for storing information. In the embodiment shown in FIG. 12, the system memory 1204 may include non-volatile memory 1208 and / or volatile memory 1210. The basic input / output system (BIOS) can be stored in non-volatile memory 1208 .

[0101] The computer 1212 may include various types of computer readable storage media in the form of one or more low-speed memory units, such as an internal (or external) hard disk drive 1214, a magnetic disk drive 1216 that reads from or writes to a removable magnetic disk 1218, and an optical disk drive 1220 that reads from or writes to a removable optical disk 1222 (such as a CD-ROM or DVD). The hard disk drive 1214, the magnetic disk drive 1216, and the optical disk drive 1220 may be connected to the system bus 1206 by a HDD interface 1224, a FDD interface 1226, and an optical disk drive interface 1228, respectively. The HDD interface 1224 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0102] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules can be stored in the drives and nonvolatile memory 1208 and volatile memory 1210, including an operating system 1230, one or more applications 1232, other program modules 1234, and program data 1236. In one embodiment, the one or more applications 1232, other program modules 1234, and program data 1236 can include, for example, various applications and / or components of the system 100.

[0103] A user may enter commands and information into the computer 1212 through one or more wired or wireless input devices, such as a keyboard 1238 and a pointing device, such as a mouse 1240. Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (capacitive, resistive, etc.), trackballs, track pads, sensors, styluses, etc. These and other input devices are often connected to the processor 1202 through an input device interface 1242 that is coupled to the system bus 1206, but may 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.

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

[0105] The computer 1212 may operate in a networked environment using wired and / or wireless communication logical connections to one or more remote computers, such as a remote computer 1248. The remote computer 1248 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and typically includes many or all of the elements described relative to the computer 1212, although for purposes of brevity, only a memory and / or storage device 1250 is shown. The logical connections shown include a local area network 1252 and wired / wireless connections to larger networks, such as a wide area network 1254. Such LAN and WAN networking environments are commonplace in offices and companies, facilitating enterprise-wide computer networks, such as an intranet, all of which may connect to a global communications network, such as the Internet.

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

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

[0108] The computer 1212 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 radio modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth wireless technologies. Thus, the communication can be of a predefined structure, such as a traditional network, or simply ad-hoc communication between at least two devices. A Wi-Fi network uses radio technologies called IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide secure, reliable, and high-speed wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0109] The various elements of the apparatus as described above with reference to Figures 1A-12 may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include apparatus, 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, chip sets, 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 determination of whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as the computational speeds, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints desired for a given implementation.

[0110] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic in a processor, which, when read by a machine, causes the machine to produce logic that performs the techniques described herein. Such representations, known as "IP cores," may be stored on tangible machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that produce the logic or processors. Some embodiments may be implemented using a machine-readable medium or article that may store instructions or sets of instructions that, when executed by a machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such machines may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may, for example, be any suitable type of memory unit, memory device, memory article, memory medium, storage device, memory article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disks, floppy disks, compact disk-read only memory (CD-ROM), compact disk-recordable (CD-R), compact disk-rewriteable (CD-RW), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

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

[0112] It will be appreciated that the exemplary devices depicted in the block diagrams above may represent one functional illustration of many potential implementations. Thus, the division, omission, or inclusion of block functions depicted in the accompanying figures does not necessarily infer that hardware components, circuits, software, and / or elements for implementing these functions are necessarily divided, omitted, or included in the embodiments.

[0113] At least one computer-readable storage medium may contain instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein.

[0114] Some embodiments may be described using the phrase "one embodiment" or "an embodiment", along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places throughout this specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise specified, it is recognized that the features described above can be used together in any combination. Thus, features described separately may be employed in combination with each other, unless the features are indicated as being incompatible with each other.

[0115] It is emphasized that the Abstract of the Disclosure is provided to enable the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, it will be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all features of a single disclosed embodiment. Accordingly, the following claims are incorporated herein with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprising" and "in" are used as the plain English equivalents of the respective terms "comprising" and "in". Furthermore, terms such as "first", "second", "third", etc. are used merely as labels and are not intended to impose numerical requirements on their subject matter.

[0116] The foregoing includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

[0117] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future filed applications that claim priority to this application may claim the disclosed subject matter in a different manner, and generally may include any set of one or more limitations as variously disclosed or otherwise set forth herein.

Claims

1. 1. A method comprising: receiving, by a server, from an application, encrypted data and a request to generate a digital wallet, the encrypted data being generated by the contactless card based on a contactless card key; decrypting the encrypted data by the server based on a key of the contactless card; generating, by the server, a private key based on decryption of the encrypted data; generating, by the server, a public key based on the private key, and generating a wallet address for the digital wallet based on the public key; sending, by the server, the private key, the public key, and / or the wallet address to the application; A method for providing the above.

2. The encrypted data is generated by the contactless card using a diversification key, a diversification factor, and the key of the contactless card, which are generated using an encryption algorithm. The method of claim 1.

3. The server generates the private key using at least one input, the method further comprising storing, by the server, the at least one input. The method of claim 1.

4. The method further comprises: by the server, obtaining the at least one input and recovering the private key by regenerating the private key using the at least one input; and by the server, The method of claim 1.

5. The method of claim 1, wherein the at least one input includes an identifier of the contactless card and a diversification factor. The method of claim 4.

6. The method of claim 1, wherein the at least one input includes a primary account number (PAN) sequence number of the contactless card. The method of claim 4.

7. The method of claim 1, wherein the at least one input includes an application transaction counter (ATC) for the contactless card. The method of claim 4.

8. The method of claim 7, wherein the at least one input is indexed based on the wallet address. The method of claim 4.

9. A non-transitory computer-readable storage medium that, when executed by a processor, causes the processor to: receiving, from an application, first encrypted data and a request to generate a digital wallet, the first encrypted data being generated by the contactless card based on a contactless card key; decrypting the first encrypted data based on the contactless card key; generating a private key based on decryption of the first encrypted data; generating a public key based on the private key; and generating a wallet address for the digital wallet based on the public key; sending the wallet address to the application; A computer-readable storage medium containing instructions for causing a computer to:

10. The instructions to the processor: generating the private key using at least one input; storing said at least one input; Further, 10. The computer-readable storage medium of claim 9.

11. The instructions to the processor: receiving second encrypted data generated by the contactless card and a transaction request; obtaining the at least one stored input; generating a signature for the transaction using the at least one input; Further, The computer-readable storage medium of claim 10.

12. The method according to claim 1, wherein the at least one input includes an identifier of the contactless card and a diversification factor. The computer-readable storage medium of claim 11.

13. The at least one input includes a primary account number (PAN) sequence number of the contactless card. The computer-readable storage medium of claim 11.

14. The at least one input includes an application transaction counter (ATC) of the contactless card. The computer-readable storage medium of claim 11.

15. The instructions further cause the processor to: transmitting the private key to the application; 10. The computer-readable storage medium of claim 9.

16. A processor; a memory storing instructions that, when executed by the processor, cause the processor to: The instructions cause the processor to: receiving encrypted data and a request to generate a digital wallet from an application, the encrypted data being generated by the contactless card based on a contactless card key; decrypting the encrypted data based on a copy of the contactless card key; generating a private key based on decrypting the encrypted data; generating a public key based on the private key; and generating a wallet address for the digital wallet based on the public key; sending the digital wallet comprising the private key, the public key, and the wallet address to the application; to carry out Computing equipment.

17. The instructions further include: generating a copy of the contactless card key using an encryption algorithm and a diversification factor before decrypting the encrypted data; 17. The computing device of claim 16.

18. The processor generates the private key using at least one input, and the instructions further include causing the processor to: storing said at least one input; indexing the at least one input based on a unique identifier associated with the contactless card; to carry out 17. The computing device of claim 16.

19. The instructions further include: recovering the private key by obtaining the at least one input and regenerating the private key using the at least one input; to carry out 17. The computing device of claim 16.

20. The method according to claim 20, wherein the at least one input includes an identifier of the contactless card and a diversification factor.

17. The computing device of claim 16.

Images