HK40107801A - Key recovery based on contactless card authentication - Google Patents

Description

Key recovery based on contactless card authentication

Cross-references to related applications

This application claims priority to U.S. Patent Application Serial No. 17/551,670, filed December 15, 2021, entitled “KEY RECOVERY BASED ON CONTACTLESS CARD AUTHENTICATION”. The contents of the foregoing application are incorporated herein by reference in their entirety.

Background Technology

Digital wallets offer many advantages but also present security and privacy challenges. The most common risks include theft and loss (or forgetting) of access keys. Furthermore, custodial wallets are tied to specific institutions and do not allow for portability. Proxy wallets are vulnerable to security breaches and/or theft, leading to the disclosure of access keys. Hardware wallets can provide recoverable seeds, but these seeds are susceptible to theft and/or other types of loss (e.g., when users cannot recall their seeds or cannot find their records of them).

Summary of the Invention

Systems, methods, apparatus, and computer-readable media for key recovery based on contactless card authentication. In one aspect, a method includes: receiving from an application a request by a server for recovering a private key for a digital wallet, the request including a first password generated from the contactless card; decrypting the first password by the server based on a key for the contactless card; determining, based on the decryption, a unique identifier for the contactless card and a diversification factor associated with the digital wallet in a hardware security module; generating a private key by the server based on the unique identifier and the diversification factor; and transmitting the private key to the application via a network.

Attached Figure Description

To facilitate the identification of any particular element or behavior in the discussion, the highest significant digit in the figure reference numerals refers to the figure number in which the element is first introduced.

Figure 1A illustrates one aspect of the subject matter according to one embodiment.

Figure 1B illustrates one aspect of the subject matter according to one embodiment.

Figure 1C illustrates one aspect of the subject matter according to one embodiment.

Figure 2A illustrates one aspect of the subject matter according to one embodiment.

Figure 2B illustrates one aspect of the subject matter according to one embodiment.

Figure 2C illustrates one aspect of the subject matter according to one embodiment.

Figure 3A illustrates one aspect of the subject matter according to one embodiment.

Figure 3B illustrates one aspect of the subject matter according to one embodiment.

Figure 4 illustrates routine 400 according to one embodiment.

Figure 5 illustrates routine 500 according to one embodiment.

Figure 6 illustrates routine 600 according to one embodiment.

Figure 7A illustrates a contactless card according to one embodiment.

Figure 7B shows a contactless card 104 according to one embodiment.

Figure 8 illustrates a data structure 800 according to one embodiment.

Figure 9 shows an example of system 900 according to an embodiment.

Figure 10 shows an example of a logic model 1000 according to an embodiment.

Figure 11 shows an example of a logic model 1100 according to an embodiment.

Figure 12 illustrates a computer architecture 1200 according to one embodiment.

Detailed Implementation

The embodiments disclosed herein provide techniques for securely recovering password keys used to access digital wallets, such as cryptocurrency wallets, using contactless cards. To create a digital wallet, a computing device can instruct a contactless card to generate a password. An application running on the computing device can receive the password via wireless communication with the contactless card and transmit it to a server for verification. If the server verifies the password, it can create a private key required for accessing or otherwise performing operations using the digital wallet. The server can then create a public key corresponding to the private key and generate a wallet address for the digital wallet based on that public key. The server can then store one or more inputs to a cryptographic algorithm used to create the private key in a hardware security module (HSM). These 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 may be stored in the HSM, while the unique identifier and diversification factor may be provided as input to the HSM for diversifying the private key (e.g., the unique identifier and diversification factor do not need to be stored in the HSM).

The server can securely transmit the private key, public key, and wallet address to the application, which can then generate a digital wallet and store the private key, public key, and wallet address within it. In some embodiments, when a user attempts to access the digital wallet, password verification using a contactless card can be used to authenticate access. If password verification fails, user access to the wallet may be restricted, thereby enhancing wallet security.

Because digital wallets store an obscure version of the private key, users may lose, forget, or otherwise be unable to provide the private key as a prerequisite for performing transactions using the digital wallet (e.g., transferring cryptocurrency). Advantageously, the embodiments disclosed herein provide a secure solution for recovering private keys using contactless cards. Typically, to recover a private key, the contactless card can generate a password that is verified by a server. If the server can verify the password, the input used to generate the private key can be provided to the HSM. The server can then recreate the private key and transmit the recreated private key to the requesting application and/or device in one or more parts.

Advantageously, the embodiments disclosed herein provide security techniques for recovering private keys used to access digital wallets using a PIN generated from a contactless card. By utilizing the PIN, embodiments of this disclosure can securely verify a user's identity with minimal risk of fraudulent activity. Furthermore, this ensures that the private key can only be recovered when the user has access to the contactless card, which facilitates PIN verification with the server. Additionally, the security of the digital wallet is enhanced by requiring PIN verification as a prerequisite for accessing the digital wallet and/or recovering the private key.

Referring generally to the notation and nomenclature used herein, the detailed description herein can be presented in terms of programming programs that execute on a computer or computer network. These program descriptions and representations are used by those skilled in the art to effectively convey the substance of their work to those skilled in the art.

The procedures described here are (and generally) conceived as a self-consistent sequence of operations that leads to the desired result. These operations are those that require physical quantities. Typically, though not strictly necessary, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient, sometimes, primarily for common purposes, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. However, it should be noted that all these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

Furthermore, the operations performed typically refer to terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. This ability of a human operator is not necessary in any of the operations described herein, or in most cases is not desirable, as these operations form part of one or more embodiments. Instead, the operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers or similar devices.

Some embodiments may be described using the terms “coupled” and “connected” along with their derivatives. These terms are not necessarily intended to be synonyms with each other. 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 also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

Various embodiments also relate to apparatus or systems for performing these operations. Such apparatus may be specifically constructed for the desired purpose, or it may include a computer selectively activated or reconfigured by a computer program stored therein. The programs presented herein are not inherently associated with a particular computer or other apparatus. Various machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the desired method steps. The desired structures for various of these machines will become apparent from the given description.

Referring now to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding thereof. However, novel embodiments may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form to aid in their description. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

In the accompanying drawings and description, the designations “a”, “b”, and “c” (and similar designations) are intended to represent variables of any positive integer. Thus, for example, if the implementation is set to a = 5, then a complete set of components 123 illustrated as components 123-1 to 123-a (or 123a) may include components 123-1, 123-2, 123-3, 123-4, and 123-5. Embodiments are not limited in this context.

Figure 1A depicts an exemplary computing architecture 100, also referred to as a system, consistent with the disclosed embodiments. Although the computing architecture 100 shown in Figures 1A through 1C has a limited number of elements in a particular topology, it will be appreciated that the computing architecture 100 may include more or fewer elements in alternative topologies, as desired for a given implementation.

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 card 104 represents any type of card, such as a credit card, debit card, ATM card, gift card, payment card, and smart card, etc. The contactless card 104 may include one or more communication interfaces 124, such as a radio frequency identification (RFID) chip, configured to communicate with the communication interface 124 of the computing device 102 (also referred to herein as a "reader," "wireless reader," and/or "wireless communication interface") via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used herein as an example communication protocol, this disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and/or Wi-Fi.

Computing device 102 represents any number and type of computing devices, such as smartphones, tablets, wearable devices, laptops, portable gaming devices, virtualized computing systems, merchant terminals, point-of-sale systems, servers, and desktop computers, etc. Mobile devices may be used as examples of computing device 102, but should not be considered as limiting this disclosure. Server 106 represents any type of computing device, such as servers, workstations, computing clusters, cloud computing platforms, and virtualized computing systems, etc. Although not depicted for clarity, computing device 102, contactless card 104, and server 106 each include one or more processor circuits, for example, to execute programs, code, and/or instructions.

As shown in the figure, the memory 108 of the contactless card 104 includes an applet 110, a counter 116, one or more master keys 114, one or more variability keys 120, a unique ID 112, a primary account number (PAN) serial number 156, and one or more unique derived keys (UDKs) 118. The unique ID 112 can be any identifier that uniquely identifies the contactless card 104 relative to other contactless cards 104. The PAN serial number 156 can include a count 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 synchronized between the contactless card 104 and the server 106. The counter 116 can include a number 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). Counter 116, master key 114, diversification key 120, UDK 118, PAN sequence 156 and/or unique ID 112 are used to provide security in system 100 as described in more detail below.

As shown in the figure, the memory 132 of the computing device 102 includes an instance of an operating system 134. Example operating systems include [example operating systems not specified]. As shown, the operating system 134 includes an account application 136. The account application 136 allows users to perform various account-related operations, such as managing digital wallets, processing transactions using the wallet, processing blockchain and/or cryptocurrency transactions, activating payment cards, viewing account balances, purchasing items, and processing payments, etc. In some embodiments, users can authenticate using authentication credentials to access certain features of the account application 136. For example, authentication credentials may include a username (or login name) and password, as well as biometric credentials (e.g., fingerprint, facial ID, etc.), etc.

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

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

In the embodiment depicted in Figure 1A, a user can tap the contactless card 104 against the computing device 102 (or otherwise bring the contactless card 104 into the communication range of the communication interface 124 of the device 102). The account application 136 can then instruct the applet 110 to generate a password 122. The password 122 can be generated based on any suitable cryptographic technique. In some embodiments, the password 122 can be based on the unique ID 112 of the contactless card 104. In some embodiments, the applet 110 may include the password 122 and an unencrypted identifier (e.g., a counter 116, a PAN sequence 156, a unique ID 112, and/or any other unique identifier) as part of a data packet including the password 122. In at least one embodiment, the data packet is an NDEF file.

As stated, the computing architecture 100 is configured to implement key diversification to secure data, which may be referred to herein as a key diversification technique. Typically, the server 106 (or another computing device) and the contactless card 104 may be pre-assigned the same master key 114 (also referred to as the master symmetric key). More specifically, each contactless card 104 is programmed with a different master key 114 having a corresponding pair in the hardware security module (HSM) 130 of the server 106. For example, when the contactless card 104 is manufactured, the 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 in the HSM 130.

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

In some embodiments, to generate password 122, applet 110 can provide UDK 118, unique ID 112, and diversification factor as input to the cryptographic algorithm to generate diversification key 120. In some embodiments, the diversification factor is counter 116. In other embodiments, PAN sequence 156 is the diversification factor. Diversification key 120 can then be used to encrypt some data, such as the diversification factor (e.g., counter 116 and/or PAN sequence 156) or other sensitive data. Applet 110 and server 106 can be configured to encrypt the same type of data to facilitate password decryption and/or verification processes.

As stated, the UDK 118 of the contactless card 104 and the server 106 can be used in conjunction with a counter 116 to enhance security using key diversification. As stated, the counter 116 includes a value synchronized between the contactless card 104 and the server 106. The counter 116 can include a number 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 ready to send data (e.g., to the server 106 and/or the device 102), the applet 110 of the contactless card 104 can increment the counter 116. The applet 110 of the contactless card 104 can then provide the UDK 118, the unique ID 112, and the counter 116 as input to a cryptographic algorithm, which produces a diversified key 120 as output. Cryptographic algorithms may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms, etc. Non-limiting examples of cryptographic algorithms may include symmetric encryption algorithms such as 3DES or AES107; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in more detail in U.S. Patent Application 16/205,119, filed November 29, 2018. The entire contents of the aforementioned patent application are incorporated herein by reference. In some embodiments, a PAN sequence 156 is used instead of a counter 116 as input to the cryptographic algorithm to generate a diversification key 120, for example, by encrypting UDK 118, a unique ID 112, and the PAN sequence 156.

Applet 110 can then use a diversity key 120 and data as input to a cryptographic algorithm to encrypt some data (e.g., a unique ID 112, a counter 116, a PAN sequence 156, a command, and/or any other data). For example, encrypting a unique ID 112 with a diversity key 120 can result in an encrypted unique ID 112 (e.g., a password 122). As stated, applet 110 and server 106 can be configured to encrypt the same data.

In some embodiments, two diversification keys 120 may be generated, for example, based on one or more portions input to a cryptographic function. In some embodiments, two diversification keys 120 are generated based on two different master keys 114, two different UDKs 118, a unique ID 112, and a counter 116 (or PAN sequence 156). In this embodiment, one of the diversification keys 120 is used to generate a message authentication code (MAC), and the other of the diversification keys 120 can be used to encrypt the MAC. The MAC can be generated based on any suitable data input to the MAC algorithm, such as sensitive data, a unique ID 112, a counter 116, and/or a PAN sequence 156. More generally, applet 110 and server 106 can be configured to generate MACs based on the same data. In some embodiments, a password 122 is included in a data packet such as an NDEF file. Account application 136 can then read the data packet including password 122 via communication interface 124 of computing device 102.

Figure 1B depicts an embodiment in which account application 136 transmits password 122 to server 106. Server 106 may provide password 122 to authentication application 138 and/or HSM 130 for verification, at least in part, based on an instance of master key 114 and/or UDK 118 stored by server 106. In some embodiments, authentication application 138 and/or HSM 130 may use an unencrypted unique ID 112 provided to server 106 to identify UDK 118 (or master key 114) and counter 116. In an example where PAN sequence 156 is used to generate password 122, server 106 may use the unencrypted unique ID 112 to identify PAN sequence 156 in account database 128 and/or HSM 130. In some examples, authentication application 138 may provide UDK 118, unique ID 112, and counter 116 as input to a cryptographic function of HSM 130, which produces one or more diversity keys 120 as output. In other embodiments, the server encrypts UDK 118, unique ID 112, and PAN sequence 156 to generate a diversity key 120. The resulting diversity key 120 may correspond to the diversity key 120 of contactless card 104, which can be used to decrypt cipher 122 and/or verify the MAC once decrypted. For example, server 106 may generate a MAC based on the same data as app 110 (such as sensitive data, unique ID 112, counter 116, and/or PAN sequence 156). If the MAC generated by server 106 matches the decrypted MAC in cipher 122, server 106 can verify or otherwise authenticate cipher 122.

Regardless of the decryption technology used, authentication application 138 and/or HSM 130 can successfully decrypt password 122 and verify the MAC, thereby verifying or authenticating password 122. If decryption and/or MAC verification is successful, authentication application 138 and/or HSM 130 can generate a digital wallet 144 for the user. Typically, to create digital wallet 144, a private key 146 can be generated. In some embodiments, a random number is provided as input to an encryption (or hash) algorithm, such as the SHA-2 algorithm or any other suitable algorithm, to generate a private key 146 of any length. In other embodiments, the unique ID 112 and PAN sequence 156 of contactless card 104 are concatenated and provided as input to a hash algorithm to generate private key 146. In other embodiments, the unique ID 112 and counter 116 of contactless card 104 are concatenated and provided as input to a hash algorithm to generate private key 146.

In other embodiments, the master key 114, unique ID 112, and counter 116 of the contactless card 104 are concatenated and provided as input to a hash algorithm to generate a private key 146. In embodiments where the master key 114 is used to generate the private key 146, a first master key 114 of the contactless card 104 may be used to generate a password 122, and a second master key 114 of the contactless card 104 may be used to generate the private key 146, wherein the first master key and the second master key are different keys. In other embodiments, one of the diversity keys 120 of the contactless card 104, unique ID 112, and counter 116 are concatenated and provided as input to a hash algorithm to generate the private key 146. In other embodiments, one of the UDKs 118 of the contactless card 104, unique ID 112, and counter 116 are concatenated and provided as input to a hash algorithm to generate the private key 146. Regardless of the input used to generate private key 146, in some embodiments, salt (e.g., random data) is included in the input of the hash algorithm used to generate private key 146.

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

In some embodiments, private key 146 and/or public key 148 can be further diversified, for example, to create hierarchical deterministic keys. For example, private key 146 can be diversified using counter 116, unique ID 112, salt value 154, or any other predetermined seed value. Doing so diversifies private key 146. Similarly, public key 148 can be diversified using counter 116, unique ID 112, salt value 154, or any other predetermined seed value to create diversified public key 148. In this embodiment, any seed value used to diversify private key 146 and/or public key 148 can be stored in account database 128 and/or recovery record 152 of HSM 130. More generally, private key 146 and/or public key 148 can be diversified multiple times using seed values to generate a tree (or hierarchy) of diversified private key 146 and/or diversified public key 148. In such embodiments, one or more paths of the tree (or hierarchy) can be used to specify different diversified keys. More generally, each node in the tree can correspond to a diversified public key and/or diversified subkeys. Given the private and public keys of a node in the tree, diversified private and public keys can be derived for all descendant nodes in the tree. Furthermore, each leaf node in the tree can correspond to a diversified public key and/or diversified subkeys. In some embodiments, the path is further used to specify attributes for the transaction, such as currency, the amount of currency, a first wallet address for the transaction (e.g., the sender's wallet address), a second wallet address for the transaction (e.g., the receiver's wallet address), and any other attributes. These attributes can be stored in a given node of the tree.

Returning to decryption, if authentication application 138 cannot decrypt password 122 (and/or cannot verify the MAC), then authentication application 138 does not make password 122 valid. In this example, authentication application 138 determines to suppress the generation of a digital wallet. Authentication application 138 may transmit an indication of failed decryption and/or verification to computing device 102.

Figure 1C depicts an embodiment in which authentication application 138 transmits digital wallet 144 to computing device 102. As shown, account application 136 may store digital wallet 144 (in memory 132 and/or non-volatile memory, not shown for clarity), which includes private key 146, public key 148, and wallet address 150. Account application 136 may hash, encrypt, or otherwise obfuscate private key 146, public key 148, and/or wallet address 150. Account application 136 may protect digital wallet 144 with authentication controls such as username and/or password, biometric credentials, etc. Additionally and/or alternatively, account application 136 may require password decryption and/or authentication using contactless card 104 to access digital wallet 144 (e.g., contactless card 104 generates a password verified by server 106 as described herein). Furthermore, in some embodiments, the account application 136 may require a user to provide a private key 146 to access the digital wallet 144 and/or perform operations using the digital wallet 144. More generally, the account application 136 may provide various interfaces to access, use, or otherwise manage the digital wallet 144.

In some embodiments, digital wallet 144 may be stored in a cloud-based wallet, such as on server 106 or another computing system that provides cloud-based wallet services to clients. Embodiments are not limited in this context. The cloud-based wallet may provide an interface for accessing or otherwise using digital wallet 144 (e.g., via account application 136).

As shown in the figure, server 106 has created a recovery record 152 in account database 128 based on the creation of digital wallet 144. Recovery record 152 includes a unique ID 112 for generating private key 146, a diversification factor 158 (e.g., counter 116 and/or PAN sequence 156), and any salt 154 (if used). In some embodiments, recovery record 152 may be indexed based on wallet address 150 of wallet 144. In other embodiments, recovery record 152 may be indexed based on record 142 of HSM 130 storing the key of contactless card 104. In other embodiments, recovery record 152 is indexed based on unique ID 112 of contactless card 104. Recovery record 152 can then be used to recreate private key 146, for example, based on unique ID 112, diversification factor 158, and/or salt 154, and an appropriate algorithm. In embodiments where the diversification key 120, UDK 118, or master key 114 is used to generate the private key 146, advantageously, the diversification key 120, UDK 118, or master key 114 is not stored in the recovery record 152 to improve security. In this embodiment, the HSM 130 may store 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.

Figure 2A is a schematic diagram 200 illustrating an embodiment in which a user requests the recovery of private key 146. As shown, to recover private key 146, account application 136 may instruct the user to tap contactless card 104 against computing device 102, causing contactless card 104 to generate password 208. Password 208 may be generated as described above with reference to password 122. For example, applet 110 may increment counter 116 and encrypt one or more UDKs 118, unique IDs 112, and counter 116 to generate one or more diversification keys 120. The one or more diversification keys 120 may be used to generate a MAC based on some data and encrypt the MAC and/or the data. In some embodiments, the MAC is generated based on wallet address 150 and one of diversification keys 120. In this embodiment, wallet address 150 and MAC are encrypted using another key from diversification keys 120 to generate password 208. As another example, public key 148 may be used to generate MAC, and public key 148 may be encrypted using MAC.

Figure 2B depicts an embodiment in which the account application 136 transmits the password 208 to the server 106 for verification. Typically, the server 106 may increment a counter 116 and encrypt the UDK 118, unique ID 112, and counter 116 of the contactless card 104 to generate one or more diversified keys 120 corresponding to the key generated by the contactless card 104. These one or more diversified keys 120 can be used to decrypt the password 208 and/or verify the MAC.

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

Once server 106 recognizes recovery record 152, recovery record 152 can be used to recreate private key 146. For example, the unique ID 112, diversity factor 158, and salt 154 (if used) of recovery record 152 can be provided as input to a function in HSM 130 used for the initial creation of private key 146. Doing so recreates private key 146.

In some embodiments, server 106 further recreates private key 146 based on master key 114 or UDK 118. For example, server 106 can provide the master key 114 of contactless card 104 and data from recovery record 152 (e.g., unique ID 112, diversity factor 158, and any salt 154) as input to the function in HSM 130 used to create private key 146. Doing so recreates private key 146. As another example, server 106 can provide the UDK 118 of contactless card 104 and data from recovery record 152 (e.g., unique ID 112, diversity factor 158, and any salt 154) as input to the function in HSM 130 used to create private key 146. Doing so also recreates private key 146.

In some embodiments, UDK 118, unique ID 112, diversification factor 158, and any salt 154 are input to a function in HSM 130 to generate a diversification key 120 for generating private key 146. The diversification key 120, diversification factor 158, and any salt 154 can be provided as input to a function in HSM 130 to recreate private key 146.

On the other hand, if HSM 130 cannot decrypt password 122 and/or verify the MAC, then HSM 130 does not make password 122 effective. In this example, authentication application 138 determines to suppress the recovery of private key 146. Authentication application 138 may transmit an indication of failed decryption and/or MAC verification to computing device 102. In this embodiment, the user is restricted from using recovery record 152 to recover private key 146.

Figure 2C depicts an embodiment in which HSM 130 has recreated private key 146 based on recovery record 152 and transmitted private key 146 to account application 136. In some embodiments, server 106 may transmit private key 146 in one or more data portions. More generally, server 106 may use a secure connection to computing device 102 to transmit private key 146. Computing device 102 may then display private key 146, thereby allowing the user to recover private key 146. The user may then use private key 146 to perform one or more operations using digital wallet 144 and/or any cryptocurrency associated with digital wallet 144. For example, private key 146 may be used to generate transactions in blockchain 906.

In some embodiments, private key 146 is not transmitted to computing device 102. For example, in a cloud-based wallet embodiment, private key 146 can be used to sign transactions or other types of data. In this example, a user can authenticate their account in account application 136 using account authentication credentials and provide details of the intended transaction (e.g., purchase, cryptocurrency transfer, etc.). Account application 136 can provide the transaction details to server 106. In some embodiments, account application 136 provides the transaction details in a password and/or a data packet including that password. The password can be similar to password 122 and/or password 208. Server 106 can then retrieve data used to diversify their keys from recovery record 152 (e.g., unique ID 112, counter 116, PAN sequence 156, and/or salt 154). The data from recovery record 152 can be provided to HSM 130, which uses the data from recovery record and master key 114 and/or UDK 118 to generate a digital signature for the transaction. Doing so generates the signature required for the transaction. For example, by generating a valid signature, a transaction can be verified using public key 148. In this example, the transaction can be added to the blockchain to reflect the verified transaction.

Figure 3A is a schematic diagram 300a illustrating an embodiment in which a contactless card 104 is tapped onto a computing device 102 (e.g., to recover private key 146). As stated, when the contactless card 104 is tapped onto the computing device 102, an applet 110 can generate a password (e.g., password 122 and/or password 208). This password, along with any other data (e.g., an unencrypted unique ID 112), can be included in a data packet, such as an NDEF file, which is read by the computing device 102. The computing device 102 can then transmit the password to a server 106 for verification as described herein (e.g., decryption and/or MAC verification).

Figure 3B is a schematic diagram 300b illustrating an embodiment in which server 106 verifies the password generated in Figure 3A. Based on this verification, server 106 can recreate the private key 146 based on recovery record 152. Server 106 can then transmit the private key 146 to account application 136. As shown, account application 136 can then display the private key 146 as a string of characters on a display. In some embodiments, a matrix code 302 can be generated to represent the private key 146. Doing so allows scanning of the matrix code 302 to determine the private key 146.

Operations for the disclosed embodiments can be further described with reference to the following drawings. Some of the drawings may include logical flows. Although such diagrams presented herein may include specific logical flows, it should be understood that logical flows merely provide examples of how general functionality as described herein can be implemented. Furthermore, a given logical flow does not necessarily have to be executed in the order presented unless otherwise stated. Moreover, in some embodiments, not all actions illustrated in a logical flow may be necessary. Furthermore, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited in this context.

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

In block 402, server 106 may receive a request to generate a digital wallet from account application 136 running on computing device 102. This request may include a password generated by contactless card 104 and transmitted to computing device 102. In block 404, the server may decrypt the password by generating one or more diversity keys 120 based on master key 114, UDK 118, and counter 116. Server 106 may further verify the password, for example, by determining that the MAC generated by server 106 matches the MAC in the decrypted password.

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

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

In block 502, routine 500 receives a request for access to digital wallet 144 from account application 136 executing on computing device 102 via server 106. This request includes a password. In block 504, server 106 can decrypt the password by generating one or more diversity keys 120 based on master key 114, UDK 118, and counter 116. Server 106 can further verify the password, for example, by determining that the MAC generated by server 106 matches the MAC in the decrypted password. In block 506, the server can generate an authorization based on successful decryption and verification. This authorization typically indicates that the requested access to digital wallet 144 will be permitted. In block 508, the server transmits the authorization to account application 136. This authorization causes account application 136 to grant the requested access to digital wallet 144. However, in some embodiments, access to digital wallet 144 further requires a private key 146.

Figure 6 illustrates an embodiment of logic flow or routine 600. Logic flow 600 may be representative of 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. Embodiments are not limited in this context.

In block 602, routine 600 receives a request from account application 136 via server 106 to recover private key 146 for digital wallet 144. This request may include a password generated by contactless card 104 based on key diversification (e.g., based on master key 114, UDK 118, and one or more diversification keys 120). In block 604, server 106 can decrypt the password by generating one or more diversification keys 120 based on master key 114, UDK 118, and counter 116. Server 106 may further verify the password, for example, by determining that the MAC generated by server 106 matches the MAC in the decrypted password.

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

Figure 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 whose service provider mark 702 is displayed on the front or back of the contactless card 104. In some examples, the contactless card 104 is not associated with a payment card and may include, but is not limited to, an identity card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 104 may include a substrate 704, which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 104 may have physical characteristics conforming to the ID-1 format of the ISO/IEC 7816 standard, and the transaction card may otherwise conform to the ISO/IEC 14443 standard. However, it should be understood that the contactless card 104 according to this disclosure may have different features, and this disclosure does not require the implementation of a transaction card as a payment card.

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 is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop, or tablet) via the transaction card. The contact pad may be designed according to one or more standards, such as the ISO/IEC 7816 standard, and enable communication according to the EMV protocol. The contactless card 104 may also include processing circuitry, antennas, and other components, as will be further discussed in FIG. 7B. These components may be located behind the contact pad 708 or elsewhere on the substrate 704, such as within different layers of the substrate 704, and may be electrically and physically coupled to the contact pad 708. The contactless card 104 may also include a magnetic stripe or magnetic 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 to an antenna capable of communicating via the NFC protocol. Embodiments are not limited in this manner.

As shown in Figure 7B, the contact pad 708 of the contactless card 104 may include processing circuitry 710 for storing, processing, and transmitting information. Processing circuitry 710 includes a processor 712, a memory 108, and one or more communication interfaces 124. It should be understood that processing circuitry 710 may include additional components necessary for performing the functions described herein, including a processor, memory, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware.

Memory 108 may be a read-only memory, a write-once-read-many memory, or a read/write memory, such as RAM, ROM, and EEPROM, and the contactless card 104 may include one or more of these memories. Read-only memory can be factory-programmable to read-only or one-time programmable. One-time programmable provides the opportunity to write once and then read multiple times. Write-once/read-many memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but it can be read multiple times. Read/write memory can be programmed and reprogrammed multiple times after leaving the factory. Read/write memory can also be read multiple times after leaving the factory. In some instances, memory 108 may be an encrypted memory that uses an encryption algorithm executed by processor 712 to encrypt data.

Memory 108 can 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 diversity key 120, and a PAN sequence 156. The one or more applets 110 may include one or more software applications, such as card applets, configured to execute on one or more contactless cards 104. However, it should be understood that applet 110 is not limited to Java card applets, but can be any software application operable on a contactless card or other device with limited memory. The one or more counters 116 may include numeric counters sufficient to store integers. The unique ID 112 may include a unique alphanumeric identifier assigned to the contactless card 104, and this identifier can distinguish the contactless card 104 from other contactless cards 104. In some examples, the unique ID 112 may identify both a customer and the account assigned to that customer.

The processor 712 and memory elements of the foregoing exemplary embodiments have been described with reference to contact pad 708, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of or completely separate from contact pad 708, or as additional elements besides the processor 712 and memory 108 located within contact pad 708.

In some examples, the contactless card 104 may include one or more antennas 714. The one or more antennas 714 may be placed within the contactless card 104 and surrounding the processing circuitry 710 of the contact pad 708. For example, the one or more antennas 714 may be integrated with the processing circuitry 710 and may be used in conjunction with an external boost coil. As another example, the one or more antennas 714 may be external to the contact pad 708 and the processing circuitry 710.

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

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

An example of NDEF OTP is the NDEF Short Record Layout (SR=1). In this example, one or more applets 110 can be configured to encode the OTP into text tags of a known NDEF Type 4 type. In some examples, the NDEF message may include one or more records. Applet 110 can be configured to add one or more static tag records in addition to the OTP record.

In some examples, one or more applets 110 can be configured to simulate RFID tags. RFID tags may include one or more polymorphic tags. In some examples, different PIN data that can indicate the authenticity of a contactless card is presented each time the tag is read. Based on one or more applets 110, NFC readings of the tag can be processed, data can be transmitted to a server, such as a bank's server, and the data can be verified at the server.

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

One or more counters 116 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 116 has been read, used, or otherwise passed. If counter 116 has not yet been used, it can be replayed. In some examples, the counter incremented on the contactless card 104 is different from the counter incremented for transactions. The contactless card 104 cannot determine the application transaction counter 116 because there is no communication between the applets 110 on the contactless card 104. In some examples, the contactless card 104 may include a first applet 440-1, which may be a transaction applet, and a second applet 440-2. Each applet 440-1 and 440-2 may include a corresponding counter 116.

In some examples, counter 116 may be out of sync. In some examples, to account for unexpected reads that initiate a transaction, such as reads at an angle, counter 116 may increment, but the application does not process counter 116. In some examples, when device 102 is woken up, NFC may be enabled and computing device 102 may be configured to read available tags, but no action is taken in response to the read.

To keep counter 116 synchronized, an application (such as a background application) can be configured to detect when computing device 102 wakes up and synchronizes with the bank system's server, indicating reads that occur due to the detection, and then move counter 116 forward. In other examples, a hashed one-time password can be used to allow a window of desynchronization to be accepted. For example, if it is within a threshold of 10, counter 116 can be configured to move forward. However, if it is within a different threshold number, such as 10 or 600, a request to perform resynchronization can be processed, which requests the user to tap, gesture, or otherwise indicate once or multiple times via one or more applications through the user's device. If counter 116 increments in the appropriate order, it can be known that the user has done so.

The key diversification technique described herein with reference to counter 116, master key 114, UDK 118, and diversification key 120 is an example of an encryption and/or decryption key diversification technique. This example key diversification technique should not be considered as a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

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

In some examples, to overcome the limitations of the 3DES algorithm (which can be vulnerable to vulnerabilities), session keys (such as a unique key for each session) can be derived instead of using the master key. Unique card-derived keys (e.g., UDK118) and counters can be used as diversification data. For example, each time a contactless card 104 is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and to perform encryption. This creates a triple encryption layer. Session keys can be generated by one or more applets and derived using an application transaction counter along with one or more algorithms (as defined in EMV 4.3Book 2A1.3.1 Common Session Key Derivation).

Furthermore, the increment for each card can be unique and can be assigned either through personalization or algorithmically based on some identifying information. For example, odd-numbered cards can increment by 2 and even-numbered cards can increment by 5. In some examples, the increment can also vary during sequential readings, allowing a card to increment in the sequence 1, 3, 5, 2, 2, ... . Specific sequences or algorithmic sequences can be constrained during personalization or defined from one or more processes derived from a unique identifier. This makes it more difficult for replay attackers to generalize from a small number of card instances.

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

Figure 8 illustrates an NDEF short record layout (SR=1) data structure 800 according to an example embodiment. One or more applets 110 can be configured to encode OTP into a known type text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: known type, text, encoding English (en); applet ID: D2760000850101; capability: read-only access; encoding: the authentication message may be encoded in ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalized parameter that can be used to generate the NDEF message. In an embodiment, the authentication template may include a first record having a known index for providing the actual dynamic authentication data. Data structure 800 may include passwords such as password 122 or password 208 and any other data provided by applet 110.

Figure 9 illustrates a schematic diagram of an exemplary system 900 consistent with the disclosed embodiments. System 900 may include a system that can access blockchain 906 via network 902.

System 900 can use blockchain 906 to generate non-reputable records of interactions. Furthermore, blockchain 906 can be distributed across multiple computing systems, encouraging trust in the validity of records stored in blockchain 906. In this way, the disclosed system provides an innovative technical solution to at least the aforementioned technical problems compared to conventional systems.

User system 904 may include computing device 102. User system 904 may be configured to process transactions using digital wallet 144, consistent with the disclosed embodiments. User system 904 may include computing devices such as servers, workstations, desktops, or mobile devices (e.g., laptops, tablets, phablets, smartphones, smartwatches, or similar mobile computing devices). As described below with respect to FIG12, user system 904 may be configured with a display and input/output interfaces. User system 904 may be configured to interact with a user (not shown) using the display and input/output interfaces.

Member system 908 can be configured to process transactions, consistent with the disclosed embodiments. Member system 908 may include one or more computing devices, such as servers, workstations, desktop computers, or dedicated computing devices. Member system 908 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example, member system 908 may be associated with a business organization. Member system 908 may include a distributed server that is remotely located and communicates with other systems of the financial institution via a public network or a dedicated private network.

Member system 908 can be configured to receive requests for processing transactions using cryptocurrency via digital wallet 144. In some embodiments, member system 908 can be configured to receive requests from another element of system 900, such as another member system 908 and/or user system 904. Member system 908 can be configured to interact with blockchain 906 to process transaction requests.

Member system 908 can be configured to store messages in blockchain 906, consistent with the disclosed embodiments. In some aspects, member system 908 can be configured to add a block containing the message to blockchain 906. In various aspects, member system 908 can be configured to provide the message to the authorization system. The authorization system can be configured to add a block containing the message to blockchain 906. As described below with respect to Figure 10, the message may include transaction records.

Blockchain 906 may include a distributed data structure consistent with the disclosed embodiments. Blockchain 906 may be a private blockchain. For example, authorizing systems may store copies of blockchain 906. These authorizing systems may be configured to add blocks to blockchain 906 and publish blocks to other authorizing systems. Authorizing systems may be configured to receive messages from other systems for publication in blockchain 906. These other systems may have read-only access to blockchain 906. In some embodiments, one or more member systems 908 are authorizing systems. In some embodiments, one or more user systems 904 are authorizing systems. As described in detail with respect to Figure 9, blockchain 906 may be configured to store messages from member systems, including transactions.

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

Figure 10 depicts a logical model 1000 of an exemplary blockchain 906, consistent with the disclosed embodiments. Blockchain 906 may include many such blockchains maintained by many different systems (e.g., member system 908, or other systems). This exemplary blockchain may include blocks, such as blocks 1006a to 1006d. Blocks may include messages, such as messages 1008a to 1008d. Typically, blocks may include headers, such as headers 1002a to 1002d, which uniquely identify each block. Headers 1002a to 1002d may include hash values generated by a hash function. A hash function is any function that can be used to map input data of arbitrary size to hash values of fixed size. For example, the header may include at least one of the hash value of the previous block, a hash value generated based on any message in the block (e.g., a Merkle root), and a timestamp. Consistent with the disclosed embodiments, system 900 may require blocks added to blockchain 906 to satisfy at least one of a proof-of-work condition and a digital signature condition. For example, headers 1002a to 1002d may include random numbers selected to ensure that the header satisfies proof-of-work conditions 1004a to 1004d. As a non-limiting example, proof-of-work conditions 1004a to 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 with a cryptographic key of the authorized system (e.g., private key 146), and this digital signature may be included in the header. This digital signature can be verified using a key available to members of system 900.

Figure 11 depicts a logical model 1100 of message 1008b stored in a blockchain (e.g., an element of blockchain 906), consistent with the disclosed embodiments. In some embodiments, message 1008b may include index information 1102. In some aspects, index information 1102 may include information identifying a user. For example, index information 1102 may be at least one of the user's full name, email address, telephone number, or other non-sensitive personal information. In various aspects, index information 1102 may include one or more references to earlier blocks in a private blockchain. For example, index information 1102 may include one or more references to one or more earlier blocks associated with the same user. As a non-limiting example, a reference may include a hash of a previous block in a blockchain associated with the same user. In some aspects, index information 1102 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, index information 1102 may be encrypted with a cryptographic key (such as private key 146). As an additional example, index information 1102 may include a hash of at least one of the user's full name, email address, telephone number, or other non-sensitive personal information.

Message 1008b may include additional information 1104, consistent with the disclosed embodiments. This additional information 1104 may include transaction details, such as the amount of cryptocurrency being transferred from one digital wallet 144 to another. 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 a cryptographic key such as private key 146.

Message 1008b may include authentication record 1106, consistent with the disclosed embodiments. In some aspects, authentication record 1106 may include information enabling subsequent auditing of the transaction. For example, authentication record 1106 may identify at least one of member system 908, a business 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 with a cryptographic key such as private key 146.

A cryptographic key, such as private key 146, can be used to encrypt elements of a message within a block, consistent with the disclosed embodiments. In some aspects, this cryptographic key can be associated with a member of authentication system 900 (e.g., member system 908). In various aspects, at least some cryptographic keys can be associated with an authorization system. A corresponding cryptographic key, such as public key 148, can be used to decrypt encrypted message elements, consistent with the disclosed embodiments. For example, when elements of a message within a block are encrypted using a symmetric key, the same symmetric key can be used to decrypt the encrypted elements. As another example, when elements of a message within a block are encrypted using private key 146, the corresponding public key 148 can be used to decrypt the encrypted elements. In some aspects, the corresponding cryptographic key can be available to members of the authentication system (e.g., member system 908).

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

As used herein, the terms “system” and “component” are intended to refer to computer-related entities, 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 can 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, an execution thread, a program, and/or a computer. By way of example, an application running on a server and a server can both be components. One or more components may reside within an executing process and/or thread, and components may be localized on a single computer and/or distributed across two or more computers. Furthermore, components may communicatively couple to each other to coordinate operation via various types of communication media. This coordination may involve one-way or two-way exchange of information. For example, components may transmit information in the form of signals transmitted via a communication medium. This information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

Computer architecture 1200 includes various general-purpose computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so on. However, embodiments are not limited to those implemented by computer architecture 1200.

As shown in Figure 12, the computer architecture 1200 includes a computer 1212, which includes a processor 1202, system memory 1204, and a system bus 1206. The processor 1202 can be any of various commercially available processors. The computer 1212 can represent computing device 102 and/or server 106.

System bus 1206 provides an interface for system components (including, but not limited to, system memory 1204) to processor 1202. System bus 1206 may be any of several types of bus structures that can be further interconnected to memory buses (with or without memory controllers), peripheral buses, and local buses using any of a variety of commercially available bus architectures. Interface adapters may be connected to system bus 1206 via slot architectures. Example slot architectures may 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, and Personal Computer Memory Card International Association (PCMCIA), etc.

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

System memory 1204 may include computer-readable storage media in the form of one or more high-speed memory cells of various types, 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), and erasable programmable ROM (EPROM). This includes electrically erasable programmable ROM (EEPROM), flash memory, polymer memory (such as ferroelectric polymer memory), bidirectional memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SNONOS) memory, magnetic or optical cards, device arrays such as Redundant Array of Independent Disks (RAID) drives, solid-state memory devices (e.g., USB storage, solid-state drives (SSDs)), and any other type of storage medium suitable for storing information. In the embodiment shown in Figure 12, system memory 1204 may include non-volatile 1208 and/or volatile 1210. The basic input/output system (BIOS) may be stored in non-volatile 1208.

Computer 1212 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including internal (or external) hard disk drive 1214, disk drive 1216 for reading from or writing to removable disk 1218, and optical disc drive 1220 for reading from or writing to removable optical disc 1222 (e.g., CD-ROM or DVD). Hard disk drive 1214, disk drive 1216, and optical disc drive 1220 may be connected to system bus 1206 via HDD interface 1224, and FDD interface 1226 and optical disc drive interface 1228, respectively. HDD interface 1224 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

The drive and associated computer-readable medium provide volatile and/or non-volatile storage for data, data structures, and computer-executable instructions, etc. For example, multiple program modules may be stored in the drive and non-volatile 1208, and in the volatile 1210, including an operating system 1230, one or more application programs 1232, other program modules 1234, and program data 1236. In one embodiment, one or more application programs 1232, other program modules 1234, and program data 1236 may include, for example, various application programs and/or components of system 100.

Users can input commands and information into computer 1212 through one or more wired/wireless input devices, such as keyboard 1238 and pointing devices (such as mouse 1240). Other input devices may include microphones, infrared (IR) remote controls, radio-frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, tracking pads, sensors, and styluses, etc. These and other input devices are typically connected to processor 1202 via input device interface 1242 coupled to system bus 1206, but can be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, and IR interfaces, etc.

Monitor 1244 or other types of display devices are also connected to system bus 1206 via an interface (such as video adapter 1246). Monitor 1244 can be internal or external to computer 1212. In addition to monitor 1244, computers typically include other peripheral output devices, such as speakers, printers, etc.

Computer 1212 can operate in a networked environment using logical connections to one or more remote computers (such as remote computer 1248) via wired and/or wireless communications. Remote computer 1248 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 1212, although for simplicity only memory and/or storage device 1250 is shown. The depicted logical connections include wired/wireless connections to local area networks 1252 and/or larger networks (e.g., wide area networks 1254). Such LAN and WAN networking environments are commonplace in offices and companies and are beneficial for enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks such as the Internet.

When used in a local area network (LAN) 1252 networking environment, computer 1212 connects to LAN 1252 via a wired and/or wireless communication network interface or network adapter 1256. Network adapter 1256 facilitates wired and/or wireless communication to LAN 1252 and may also include a wireless access point configured thereon for communicating with the wireless functionality of network adapter 1256.

When used in a wide area network (WAN) 1254 networking environment, computer 1212 may include modem 1258, or a communication server connected to WAN 1254, or other means for establishing communication via WAN 1254, such as via the Internet. Modem 1258, which may be internal or external and wired and/or wireless, is connected to system bus 1206 via input device interface 1242. In a networking environment, program modules or portions thereof depicted relative to computer 1212 may be stored in remote memory and/or storage device 1250. It should be understood that the network connections shown are exemplary, and other means of establishing communication links between computers may be used.

Computer 1212 is operable to communicate with wired and wireless devices or entities using IEEE 802 series standards, such as wireless devices operable in wireless communication (e.g., IEEE 802.11 air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth ^™ wireless technologies. Therefore, communication can be a predefined structure like a regular network or simply self-organizing communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to interconnect computers, connect to the Internet, and connect to wired networks (using IEEE 802.3 related media and functions).

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

One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium, representing various logic within a processor, which, when read by a machine, causes the machine to manufacture the logic to perform the techniques described herein. This representation, referred to as an "IP core," can be stored on a tangible, machine-readable medium and provided to various clients or manufacturing facilities for loading into a manufacturing machine that manufactures the logic or processor. Some embodiments can be implemented, for example, using a machine-readable medium or article of manufacture that can store instructions or instruction sets, which, if executed by a machine, can cause the machine to perform the methods and/or operations according to the embodiments. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and can be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article of manufacture may include, for example, any suitable type of memory cell, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage cell, such as memory, removable or non-removable medium, erasable or non-erasable medium, writable or rewritable medium, digital or analog medium, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic medium, magneto-optical medium, removable memory card or disk, various types of digital multifunction disc (DVD), magnetic tape, cassette tape or the like. 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., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

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

It will be appreciated that the exemplary device shown in the block diagrams described above may represent a functionally descriptive example of many potential implementations. Therefore, the division, omission, or inclusion of block functions depicted in the figures does not imply that hardware components, circuits, software, and/or elements used to implement these functions are necessarily divided, omitted, or included in the embodiments.

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

Some implementations may be described using the expressions "an embodiment" or "an embodiment" together 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 in the specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise stated, the features described above are considered to be used in any combination. Thus, any feature discussed individually may be used in combination with each other unless it is noted that the features are incompatible with each other.

It should be emphasized that this summary of the disclosure is provided to allow the reader to quickly determine the nature of the technical disclosure. The intended understanding is that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of simplifying the disclosure. The approach of this disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly mentioned in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the following claims are incorporated herein by reference, wherein each claim stands independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as concise English equivalents to the corresponding terms “comprising” and “wherein,” respectively. Furthermore, the terms “first,” “second,” “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

The foregoing description includes examples of the disclosed architecture. It is certainly impossible to describe every conceivable combination of components and/or methods, but those skilled in the art will recognize that many further combinations and permutations are possible. Therefore, the novel architecture is intended to encompass all such changes, modifications, and variations falling within the spirit and scope of the appended claims.

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 this disclosure to the precise forms disclosed. Many modifications and variations are possible based on this disclosure. The scope of this disclosure is not limited by this detailed description but by the appended claims. Future applications claiming priority to this application may claim the disclosed subject matter in different ways and may generally include any set of one or more limitations as differently disclosed or otherwise demonstrated herein.

Claims (20)

1. A method comprising: The server receives a request from the application to recover the private key used for the digital wallet, the request including a first password generated by the contactless card; The server decrypts the first password based on the key used for the contactless card; The server determines the unique identifier of the contactless card and the diversity factors associated with the digital wallet based on the decryption. The server generates the private key based on the unique identifier and the diversification factor; and The server transmits the private key to the application via the network. 2. The method according to claim 1, wherein the diversification factor includes the application master account (PAN) serial number of the contactless card. 3. The method of claim 1, wherein the diversification factor includes the application transaction counter (ATC) of the contactless card. 4. The method of claim 1, further comprising, before receiving the request: The server receives a second password generated by the contactless card from the application. The server decrypts the second password; The server generates the private key based on the decryption of the second password; The server generates a public key based on the private key, and generates a wallet address for the digital wallet based on the public key; and The server transmits the private key, the public key, and the wallet address to the application. 5. The method of claim 4, wherein the unique identifier and the diversification factor of the contactless card are determined based on the wallet address of the digital wallet. 6. The method according to claim 5 further includes generating the wallet address of the digital wallet based on the decryption of the first password. 7. The method of claim 1, wherein the server further determines a salt value associated with the digital wallet, wherein the server further generates the private key based on the salt value, the method further comprising: The application accesses the digital wallet based on the private key. 8. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: Receive a request from the application to recover the private key used for the digital wallet, the request including a first password generated by the contactless card; The first password is decrypted based on the key used for the contactless card; Based on the decryption, a unique identifier for the contactless card and a diversity factor associated with the digital wallet are determined; The private key is generated based on the unique identifier and the diversity factors; and The private key is transmitted to the application via the network. 9. The non-transitory computer-readable storage medium of claim 8, wherein the diversification factor includes the application master account (PAN) serial number of the contactless card. 10. The non-transitory computer-readable storage medium of claim 8, wherein the diversification factor includes the application transaction counter (ATC) of the contactless card. 11. The non-transitory computer-readable storage medium of claim 8, wherein the instruction further causes the processor to: before receiving the request: Receive a second password generated by the contactless card from the application; Decrypt the second cipher; The private key is generated based on the decryption of the second cipher; A public key is generated based on the private key, and a wallet address for the digital wallet is generated based on the public key; and The private key, the public key, and the wallet address are transmitted to the application. 12. The non-transitory computer-readable storage medium of claim 11, wherein the unique identifier and the diversification factor of the contactless card are determined based on the wallet address of the digital wallet. 13. The non-transitory computer-readable storage medium of claim 12, wherein the instructions further configure the computer to generate the wallet address of the digital wallet based on the decryption of the first password. 14. The non-transitory computer-readable storage medium of claim 8, wherein the processor further determines a salt value associated with the digital wallet, and wherein the processor further generates the private key based on the salt value. 15. A computing device, comprising: Processor; and A memory storing instructions that, when executed by the processor, cause the processor to: The application receives a request to recover the private key used for the digital wallet, the request including a first password generated from the contactless card; The first password is decrypted based on the key used for the contactless card; Based on the decryption, a unique identifier for the contactless card and a diversity factor associated with the digital wallet are determined; The private key is generated based on the unique identifier and the diversity factors; and The private key is transmitted to the application via the network. 16. The computing device of claim 15, wherein the diversification factor includes the application master account (PAN) serial number of the contactless card. 17. The computing device of claim 15, wherein the diversification factor includes the application transaction counter (ATC) of the contactless card. 18. The computing device of claim 15, wherein the instruction further causes the device to: before receiving the request: Receive a second password generated by the contactless card from the application; Decrypt the second cipher; The private key is generated based on the decryption of the second cipher; A public key is generated based on the private key, and a wallet address for the digital wallet is generated based on the public key; and The private key, the public key, and the wallet address are transmitted to the application. 19. The computing device of claim 18, wherein the unique identifier and the diversification factor of the contactless card are determined based on the wallet address of the digital wallet, wherein the instructions further configure the processor to generate the wallet address of the digital wallet based on the decryption of the first password. 20. The computing device of claim 15, wherein the processor further determines a salt value associated with the digital wallet, and wherein the processor further generates the private key based on the salt value.