Creating and maintaining digital tokens on a blockchain using physical device identifiers

Abstract

Some aspects of the disclosure provide techniques for generating a digital token associated with an asset on a blockchain. An exemplary method generally includes receiving a request to create a digital token corresponding to an asset. A first private key is received. The first private key may be associated with a wallet in which the digital token is to be stored. A second private key is received from a physical device associated with an owner of the asset. An address of the asset is encrypted with a public key associated with the second private key. Metadata associated with the digital token is encrypted with a public key associated with the first private key. The digital token is minted on the blockchain based on the encrypted address of the asset and the encrypted metadata.

Description

[Technical field]

[0001] Introduction Aspects of the present disclosure relate to digital tokens that correspond to other assets, and more particularly, to the generation and maintenance of digital tokens on a blockchain. [Background technology]

[0002] Distributed ledgers, such as blockchains, hash chains, and other ledger systems, generally provide a mechanism for tracking transaction history associated with a physical or digital object. A distributed ledger may structure the transaction history for an object as a number of sequentially ordered nodes. An original transaction in the distributed ledger that represents the creation of an object may be a node that does not point to other nodes in the distributed ledger as predecessor nodes. Subsequent transactions may be reached by moving a pointer from the node representing the original transaction to the node representing any particular transaction. Using a distributed ledger, transactions may be processed by ensuring that objects identified in the transaction exist in the distributed ledger (e.g., to verify that the object exists and / or is a valid object against which the transaction may be performed) and to ensure that participants in the transaction are eligible to perform the transaction.

[0003] In some cases, these distributed ledgers may be used to maintain transaction histories for digital tokens that may be associated with other (physical or virtual) assets. In general, transferring ownership of these assets may include transferring both the underlying asset and the digital token associated with the asset. The transfer of the digital token may generally be accomplished by transferring the token from a current owner's wallet to a new owner's wallet based on encryption keys associated with the current and new owners. However, when information about the underlying asset associated with the digital token is stored in an unencrypted format or encrypted using a compromised encryption key, it may be possible for a malicious or unauthorized user to access and replicate the underlying asset.

[0004] Therefore, techniques are needed for securely generating and maintaining digital tokens on a blockchain. Summary of the Invention

[0005] Some embodiments provide a computer-implemented method for generating a digital token associated with an asset on a blockchain. An exemplary method generally includes receiving a request to create a digital token corresponding to an asset. A first private key is received. The first private key may be associated with a wallet in which the digital token is to be stored. A second private key is received from a physical device associated with an owner of the asset. An address of the asset is encrypted with a public key associated with the second private key. Metadata associated with the digital token is encrypted with a public key associated with the first private key. The digital token is minted on the blockchain based on the encrypted address of the asset and the encrypted metadata.

[0006] Other embodiments provide a processing system configured to perform the above-mentioned methods as well as methods further described herein; a non-transitory computer readable medium comprising instructions that, when executed by one or more processors of the processing system, cause the processing system to perform the above-mentioned methods as well as methods further described herein; a computer program product embodied on a computer readable storage medium comprising code for performing the above-mentioned methods as well as methods further described herein; and a processing system comprising means for performing the above-mentioned methods as well as methods further described herein.

[0007] The following description and the associated drawings set forth in detail certain illustrative features of the one or more embodiments.

[0008] The accompanying drawings depict several aspects of the one or more embodiments and therefore should not be considered as limiting the scope of the disclosure. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an exemplary system in which digital tokens corresponding to other assets are generated and maintained based on a physical device identifier. [Diagram 2] FIG. 1 illustrates an example pipeline for generating a digital token based on a physical device identifier. [Diagram 3] FIG. 1 illustrates example operations for generating a digital token corresponding to another asset based on a physical device identifier. [Figure 4] FIG. 1 illustrates an example pipeline for securely accessing digital tokens corresponding to other assets based on a physical device identifier. [Diagram 5] FIG. 1 illustrates an example operation for securely accessing digital tokens corresponding to other assets on a blockchain. [Figure 6] FIG. 1 illustrates an exemplary system in which embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] For ease of understanding, wherever possible, like reference numbers have been used to designate like elements that are common to the figures. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.

[0011] Digital tokens stored on a blockchain generally allow for the maintenance and transfer of ownership of various assets in a traceable manner. These tokens may be non-fungible tokens (NFTs) or unique tokens that represent ownership of a particular asset, such as a particular piece of artwork, tickets to an event, or particular data, and may not be divided into smaller parts or exchanged for other tokens. Because these tokens may not be exchangeable with other tokens, various steps may be taken to prevent the duplication of these tokens. For example, information in a token may be encrypted using an encryption system such that only the owner of the token can access the token. For example, a public-private key encryption system generally allows a digital token to be encrypted using an owner's public key such that only a party with the owner's private key can decrypt the digital token and view its contents.

[0012] However, compromising an owner's private key may enable a malicious or unauthorized user to access the digital token, perform an unauthorized transfer of the digital token to another user, generate unauthorized copies of the digital token, etc. For example, if a digital token corresponding to a digital artwork contains information identifying the location of the digital artwork (e.g., a uniform resource locator (URL) or uniform resource identifier (URI)) and the digital token is encrypted using a compromised key, a malicious user can access the underlying digital artwork and effectively counterfeit the digital artwork. By performing an unauthorized transfer of the digital token or counterfeiting the underlying asset, whether physical or digital, the link that associates ownership of the digital token with ownership of the underlying asset may be broken. In another example, if a digital token encrypted using a compromised key contains sensitive information, a malicious user can access this sensitive information and use it for unauthorized or malicious purposes.

[0013] Aspects of the present disclosure provide techniques for securely generating and maintaining digital tokens. As described in further detail herein, digital tokens may be generated based on data encrypted using multiple encryption keys. One of these encryption keys may be a public key corresponding to a private key associated with the owner of an asset associated with the digital token, and another one of these encryption keys may be a public key corresponding to a private key from a physical device associated with the owner of the asset. Different information in a digital token may be encrypted using different keys, so that if one key is compromised, only a portion of the data in the digital token may be compromised and other data in the token may be protected. For example, if a key used to encrypt metadata in a digital token is compromised but a key used to encrypt an address where the asset is located is not compromised, a malicious party may not be able to access the underlying asset associated with the digital token and copy the underlying asset or create a token with a valid reference to the address where the asset is located. By generating digital tokens using multiple keys, aspects of the present disclosure may improve the security of digital tokens stored on a blockchain, since multiple keys may be required to compromise a digital token. Compromising multiple keys can be a computationally inefficient process (e.g., a brute force attack on a 128-bit key takes 2 128 =3.4E38 decryption attempts), the use of multiple keys would increase the computational cost of breaking the encryption used on the data stored in the digital token, thus making doing so, at best, infeasible.

[0014] Exemplary Generation and Maintenance of Digital Tokens Based on Physical Device Identifiers 1 illustrates an exemplary computing environment 100 in which digital tokens corresponding to other assets are generated and maintained using a physical device identifier as one key in a set of keys used to encrypt data in the digital token. As shown, the computing environment 100 includes a token processing system and a network 120.

[0015] The token processing system 110 generally enables the generation, retrieval, and transfer of digital tokens that use multiple encryption keys to protect the security of data stored in the digital token. Generally, the token processing system 110 may be any computing device, such as a server, a compute cluster, a desktop computer, a laptop computer, a mobile computing device, an edge computing device, etc., that can generate digital tokens and generate corresponding blocks in a blockchain to prove the creation and / or transfer of the digital tokens and assets associated with the digital tokens. For example, the token processing system 110 may be configured to process transactions for a cryptocurrency network, such as the network 120. By way of example, the network 120 may be the Ethereum® network or other cryptocurrency network in which smart contracts may be defined and executed for the generation of unique digital tokens that correspond to ownership or control over associated assets. As shown, the token processing system 110 includes a token generator 112, a token retriever 114, and a token transferor 116.

[0016] The token generator 112 generally uses a key associated with the asset owner's digital wallet and a key associated with a physical device owned by the asset owner to generate (or "mint") a digital token corresponding to the underlying asset. The generated (or "minted") token may be committed to the asset owner's digital wallet, and a corresponding record may be recorded on the blockchain to prove the creation and initial ownership of the digital token and the underlying asset.

[0017] A user can request the generation of a digital token associated with an asset, whether physical or digital, by providing information about the underlying asset, a first private key, and a second private key. As described in more detail below, the first private key may be associated with a wallet owned by the asset owner, and the second private key may be associated with a physical device owned by the asset owner.

[0018] In some aspects, the asset for which a digital token is to be generated may be a digital asset, such as digital artwork, digital event tickets, digital audio and / or video files, confidential data used to generate public-facing reports (e.g., Environmental, Social, and Governance (ESG) reports), etc. The digital assets may be stored separately (e.g., stored “off-chain”) from the digital tokens stored on the blockchain 122, and the information about the underlying asset may include information identifying the location where the digital asset is stored. For example, these digital assets may be identified by a Uniform Resource Locator (URL), a Uniform Resource Identifier (URI), a content identifier in a distributed file system (e.g., Interplanetary File System (IPFS), etc.) where the digital asset is stored.

[0019] In other aspects, the asset for which a digital token is to be generated may be a physical asset. Information regarding a physical asset used to generate a digital token evidencing ownership of such an asset may include various digital counterparts to the physical asset, such as a picture of the physical asset, a digital file containing identification information for the physical asset, etc. If a digital counterpart exists for the physical asset, the information regarding the underlying asset may identify the location where the digital asset is stored, as well as the digital asset. In some aspects, if a digital counterpart does not exist for the physical asset, the information regarding the underlying asset may include information that can be used to access the physical asset, such as a security code, lock combination, etc.

[0020] In response to a request to generate a digital token corresponding to an asset, the token generator 112 may prompt the user to provide a first private key for use in encrypting metadata associated with the digital token. The first private key may be a private key associated with a wallet in which the digital token is to be stored. The token generator 112 may then use various key generation algorithms to generate a corresponding first public key such that data encrypted using the first public key is decryptable using the first private key (e.g., a private key associated with the wallet in which the digital token is to be stored). In some aspects, the token generator 112 may generate a unique public key for each digital token generated by the token generator 112.

[0021] The token generator 112 may also prompt the user, in response to a request to generate a digital token, to provide a second private key for use in encrypting information regarding the location at which the asset corresponding to the digital token is located. As with the first private key, the second private key may be used in conjunction with a variety of key generation algorithms to generate a second public key that may be used to encrypt information regarding the location at which the asset corresponding to the digital token is located.

[0022] In some aspects, the second private key may be retrieved from a physical device associated with the owner of the asset. To obtain the second private key, the token generator 112 may provide a prompt requesting that the user scan or otherwise digitally read or enter a physical identifier from the physical device. The physical identifier may be scanned or read via various data connections between the physical device and a device (e.g., a mobile phone, a laptop computer, a desktop computer, etc.) used to invoke the token generation process in the token generator 112. For example, the physical identifier may be read via a near field communication (NFC) data connection with the physical device associated with the asset owner, read from a radio frequency identifier (RFID) module (e.g., an RFID tag) embedded in the physical device, read via a Bluetooth® low energy (BLE) connection with the physical device, or read via other wired or wireless (e.g., contactless) data connection between the physical device and the device used to invoke the token generation process.

[0023] In some aspects, the token generator 112 may allow a user to manually enter and / or select a physical identifier associated with a physical device. For example, the token generator 112 may allow a user to enter data such as a serial number of the physical device, an identifier of a subscriber identity module (SIM) associated with the physical device (e.g., an Integrated Circuit Card Identification (ICCID) number), an International Mobile Equipment Identity (IMEI) associated with the physical device, an identifier of an RFID module associated with the physical device, etc. However, it should be appreciated that these are merely examples of various identifiers that may be provided as the physical identifier, and that other unique device identifiers may also or alternatively be provided as the second secret key.

[0024] After the token generator 112 generates the first public key (corresponding to the first private key) and the second public key (corresponding to the second private key), data to be embedded in the digital token may be encrypted. Metadata describing the digital token may be encrypted using the first public key, and the location of the asset associated with the digital token may be encrypted using the second public key. The metadata describing the digital token may include, for example, information defining various attributes describing a unique character of the digital token and the underlying asset. For example, in a scenario where the digital token corresponds to a playable character in a video game, the metadata describing the digital token may include information regarding the appearance of the playable character, gameplay attributes for the playable character, an inventory of items the playable character can carry, etc. In another example, in a scenario where the digital token corresponds to a report generated from confidential (e.g., market confidential) information, the metadata describing the digital token may include various data points derived from the confidential information, such as ESG score data derived from the confidential information, internal equity or debt ratings derived from the market confidential data, etc. Meanwhile, the location where the asset corresponding to the digital token is located may be encrypted using the second public key such that even if the first public key is compromised, a malicious user will not be able to effectively obtain, modify, and / or transfer the underlying asset associated with the digital token.

[0025] After encrypting the metadata and the location (or address) of the underlying asset associated with the digital token, the token generator 112 can mint the digital token on the blockchain. The digital token generally includes the encrypted metadata and the encrypted address. In minting the digital token, the token generator 112 can create the digital token and simultaneously invoke a smart contract on the blockchain to generate a record attesting to the creation of the digital token on the blockchain 122 and the initial ownership of the digital token by the wallet owner whose private key can be used to decrypt the digital token. In minting the digital token on the blockchain 122, the digital token can be stored on the blockchain 122 and the underlying asset associated with the digital token can be maintained in a separate location from the blockchain 122.

[0026] The token retriever 114 generally allows a user to view previously minted digital tokens. To provide a digital token to a user for viewing, the token retriever 114 may request an identifier for the digital token and retrieve the digital token from the blockchain 124. The retrieved digital token may include an encrypted location where the underlying asset is located and encrypted metadata, which may be encrypted using different keys to provide security for the metadata in the digital token and the location where the underlying asset is stored, as described above.

[0027] To allow the user to view the underlying asset associated with the digital token, the token extractor 114 may request a second private key from the user. Upon receipt of the second private key (which may be read via a wired or wireless connection with a physical device associated with the owner of the asset or may be manually entered, as described above), the token extractor 114 may decrypt the location of the underlying asset and provide the location of the underlying asset to the user viewing the digital token. Metadata may also be provided to the viewer in an encrypted format, and the user may decrypt the metadata using the first private key. In general, data contained in or associated with the digital token may be transmitted from the token processing system 110 to a client device (not shown) in an encrypted format and decrypted locally (at the client device), so that the decrypted data is not at risk of exfiltration in transit. In some aspects, the keys needed to decrypt the location data and the metadata in the digital token may be provided from the client device to the token extractor 114 via various key exchange mechanisms, and the digital token may be decrypted. The decrypted digital token may then be re-encrypted using a different (mutually agreed upon) set of keys, which may allow the information in the digital token to be secured in transit.

[0028] The token transferor 116 generally facilitates on-chain transfer of digital tokens and underlying assets from an initial owner to a subsequent owner. To transfer a digital token (and underlying assets), a transferor can view and unlock the digital token via the token extractor 114 and initiate the transfer process. The token transferor 116 can then request a set of keys associated with the transferee (e.g., a user to whom ownership of the digital token and underlying assets should be transferred) for use in encrypting metadata and location information in the digital token. The requested set of keys may, in some aspects, include a public key associated with a wallet to which the digital token should be transferred and a public key associated with a physical device owned by the transferee. After receiving the requested set of keys, the token transferor 116 can encrypt the metadata using the public key associated with the wallet to which the digital token should be transferred and can encrypt the location of the underlying assets using the public key associated with the physical device owned by the transferee. The updated token, now readable by anyone with the destination private key but not by the previous owner, may then persist on the blockchain 122 to prove the transfer of ownership.

[0029] In some aspects, the token transferor 116 may act as an intermediary to coordinate the transfer of the digital token and the underlying asset from the current owner (transferor) to the new owner (transferee). In such cases, the token transferor 116 may receive information identifying the transferor and the transferee and initiate a process to separately obtain the appropriate encryption and decryption keys. For example, the token transferor 116 may request the private key from the current owner of the digital token separately from requesting the public key from the new owner of the digital token. By requesting these keys separately, the token transferor 116 may prevent the new owner of the digital asset from obtaining the private key of the current owner and therefore from compromising the current owner's other digital tokens by the new owner. Furthermore, the current owner of the digital token may not have access to the new owner's public key, which may prevent the current owner of the digital token from creating new tokens using the new owner's public key.

[0030] Exemplary Pipeline for Generating Digital Tokens on a Blockchain Based on Physical Device Identifiers FIG. 2 illustrates an example pipeline 200 for generating digital tokens on a blockchain according to an embodiment of the disclosure.

[0031] As shown, the pipeline 200 begins with a wallet key entry stage 210, in which a user creating a digital token corresponding to an asset provides a private key associated with a wallet into which the digital token is to be deposited. A token generator (e.g., the token generator 112 shown in FIG. 1) may prompt the user for a private key, which the user may provide by typing the private key, scanning a physical device on which the private key is stored, etc. After the token generator receives the private key associated with the wallet into which the digital token is to be deposited, the token generator may generate a public key (e.g., a cryptographic key) using various key generation mechanisms that can generate a public key from the private key.

[0032] The pipeline 200 may proceed to a physical identifier entry stage 220. In the physical identifier entry stage 220, the token generator may request a physical identifier of a physical device owned by the owner of the digital token and the underlying asset for use in generating the digital token. A public key associated with the physical device may be derived from the physical identifier using various key generation mechanisms, which treat the physical identifier as a private key that may be used to decrypt data encrypted using the public key derived from the physical identifier. The physical identifier may be provided, for example, via reading the identifier from the physical device using a wired or wireless data connection, or via manual entry of the identifier. As described, the identifier may be read from various short-range data connections, such as an NFC connection, via reading an RFID tag, via a BLE connection, etc. In some aspects, the identifier may be an identifier associated with a SIM (e.g., an ICCID number), a serial number associated with the physical device, etc. It should be noted that the physical identifier may be any type of globally unique identifier that uniquely identifies a physical device owned by the owner of the asset and digital token.

[0033] In a metadata encryption step 230, the token generator encrypts the metadata to be carried in the digital token. As will be explained, the metadata may be derived from or otherwise encrypted using a public key associated with the private key of the digital wallet.

[0034] The location (or address) of the asset corresponding to the digital key is encrypted in an encryption asset address step 240. As will be explained, the location (or address) may be encrypted using a public key derived from the physical identifier.

[0035] In a token ownership assignment stage 250, a record may be created indicating the ownership of the token.

[0036] Finally, in a token minting stage 260, the digital token is minted and persisted on the blockchain. The digital token may be minted using encrypted metadata and encrypted address information such that multiple keys are required to decrypt the contents of the digital token and access the underlying asset corresponding to the digital token. In the token minting stage 260, the digital token may be minted by invoking one or more smart contracts that cause records to be generated on the blockchain (e.g., the blockchain 122 shown in FIG. 1) attesting to the creation of the digital token and the initial assignment of ownership of the digital token to the owner whose wallet private key was provided in the wallet key entry stage 210. The digital token minted and stored on the blockchain 122 may then be retrieved and transferred using the private key associated with the owner's wallet and the physical identifier of the owner's physical device, as described above.

[0037] 3 illustrates example operations 300 for generating a digital token corresponding to an other physical or digital asset based on a physical device identifier according to aspects of the disclosure. The operations described herein may be performed, for example, by the token generator 112 shown in FIG.

[0038] As shown, operations 300 may begin at block 310, where a request to create a digital token corresponding to an asset is received (e.g., at a token generator, such as token generator 112 shown in FIG. 1). Generally, the request to create a digital asset may include information identifying a location where the corresponding asset is stored, such as a URL or URI for the digital asset, or a physical location and access information for a physical asset. The corresponding asset may be a digital asset, such as a document or repository of confidential information, digital artwork, or the digital counterpart of a physical asset, such as a digital certificate associated with the physical asset, or the physical asset itself.

[0039] At block 320, a first private key is received (e.g., at a token generator, such as token generator 112 shown in FIG. 1). Block 320 may correspond to the wallet key entry stage 210 shown in FIG. 2. The first private key may be associated with a wallet in which the digital token is to be stored. The token generator may use various key generation mechanisms to generate a first public key, which may be used to encrypt data that may then be decrypted using the first private key.

[0040] At block 330, a second private key is received (e.g., at a token generator, such as the token generator 112 shown in FIG. 1). Block 330 may correspond to the physical identifier entry stage 220 shown in FIG. 2. The second private key may be received from a physical device associated with the owner of the asset.

[0041] In some aspects, the second private key may be received via scanning or otherwise reading data from a physical device associated with the owner of the asset via a wired or wireless connection. The wireless connection by which the second private key may be received may include, for example, an NFC connection, a connection generated by an RFID tag, a BLE connection, etc. Alternatively, the second private key may be manually entered into a data entry form and provided to the token generator.

[0042] The private key may include various physical identifiers associated with the physical device. For example, the physical identifiers may include an identifier of an NFC chip on the physical device, an identifier of an RFID tag on the physical device, etc. In another example, the physical identifiers may be various identifiers associated with a mobile device (e.g., a cellular phone) through which the digital token is being created. These identifiers may include a serial number of the physical device, an ICCID number, or other identifier of a SIM attached to the physical device, an IMEI associated with the physical device, or other globally unique identifier.

[0043] In block 340, the address of the asset is encrypted with a public key associated with the second private key (e.g., in a token generator, such as token generator 112 shown in FIG. 1 ). Block 340 may correspond to the asset address encryption stage 240 shown in FIG. 2.

[0044] In block 350, metadata associated with the digital token is encrypted with a public key associated with the first private key (e.g., in a token generator, such as token generator 112 shown in FIG. 1 ). Block 350 may correspond to the metadata encryption stage 230 shown in FIG. 2.

[0045] At block 360, the digital token is minted on the blockchain. The digital token may be minted based on the encrypted address of the asset and the encrypted metadata. In some examples, if the digital token complies with the Ethereum Comment Request 1155 (ERC-1155) standard, the encrypted address of the asset may be stored in a tokenURI field and the encrypted metadata may be stored in various metadata fields in the digital token.

[0046] The digital token may in some embodiments be an NFT with an ownership record maintained on a blockchain. In such cases, the digital token may represent a particular asset and may not be exchangeable with other digital tokens representing other assets.

[0047] In some aspects, after a digital token is minted on the blockchain, the digital token may be committed to a wallet. In committing a digital token to a wallet, a reference to the digital token may be written to the wallet. The reference to the digital token may identify a location in the blockchain (or in some other storage network) where the digital token may be located, and the wallet owner may use this information to access the digital token, view metadata stored in the digital token, access the location of assets associated with the digital token, etc.

[0048] As described, because the encrypted address of the asset and the encrypted metadata are encrypted using different keys, compromising one key may not enable a malicious user to obtain a usable version of the digital token and the underlying asset associated with the digital token. Furthermore, because different keys are used to separately encrypt the data stored in the digital token, additional computational complexity may be introduced into attempts to decrypt the digital token.

[0049] For example, assume that different 128-bit keys are used to encrypt the metadata and the address of the asset. In such a case, the digital token will have 2 128 Decrypting the metadata using the key and separately 128 Even if one key is compromised, decrypting the encrypted data using the other key is a 2-way brute force attack. 128 decryption operations, which may be a computationally infeasible problem to solve in a reasonable amount of time.

[0050] In some aspects, the metadata associated with a digital token may include a URI that identifies the location where the digital asset is stored.

[0051] In some aspects, metadata associated with a digital token may include covert data used to generate public data stored in the digital asset.

[0052] In some aspects, metadata associated with a digital token may include public data generated from private data stored in the digital asset.

[0053] In some aspects, to view the digital asset, a request to view the digital asset may be received along with the second private key. The digital token may be retrieved (e.g., from the blockchain) and the encrypted address in the digital token may be decrypted using the second private key. The decrypted address of the asset corresponding to the digital token and the encrypted metadata in the digital token may be returned. The encrypted metadata in the digital token may be decryptable using the first private key.

[0054] In some aspects, a request may be received to transfer the digital token from the wallet to a second wallet. A public key associated with the second wallet and a public key of a second physical device to be associated with the digital token may be requested. Ownership of the digital token is transferred to a user associated with the second wallet based on the first private key, the second private key, the public key associated with the second wallet, and the public key of the second physical device. To transfer ownership, the digital token may be decrypted using the first private key and the second private key, and then re-encrypted using the public key associated with the second wallet and the public key of the second physical device. A new record attesting to the transfer of the digital token to the owner of the second wallet may then be written to the blockchain. Furthermore, because the digital token has been re-encrypted using a new set of keys, the previous owner of the digital token may no longer be able to decrypt and view the metadata in the digital token and the address where the assets associated with the token are located.

[0055] Exemplary Secure Key Exchange for Generating and Maintaining Digital Tokens Based on Physical Device Identifiers As described above, the creation and transfer of digital tokens associated with other assets may involve the use of multiple cryptographic keys to commit the digital tokens to the blockchain, to access the digital tokens, and to transfer ownership of the digital tokens. To enforce security regarding the digital tokens and prevent, or at least mitigate, unauthorized creation or duplication of the digital tokens, various key exchange mechanisms may be used to protect the keys used to encrypt the digital tokens and to verify that users have permission to access the digital tokens.

[0056] Encryption keys generally differ in structure based on whether such keys are used in symmetric or asymmetric encryption schemes. In symmetric encryption schemes, the same key is used to encrypt and decrypt data. In contrast, in asymmetric encryption schemes, there are two keys: a private key and a public key. Encryption may generally be performed using the public key, and decryption may be performed using the private key. The public key is commonly known so that any party can encrypt data, but only the holder of the corresponding private key can decrypt data encrypted using the public key. Because encryption keys enable access to encrypted data, these encryption keys are generally exchanged such that a third party cannot perform a "man in the middle" attack to capture these keys.

[0057] Aspects of the present disclosure provide techniques for securely exchanging keys used in generating, encrypting, and decrypting digital tokens associated with other assets. Multiple keys may be used to protect digital tokens committed onto a blockchain, such as proof of ownership (or at least possession) of two or more keys to decrypt and access the encrypted version of the digital token (or other digital counterpart to some other asset). Additionally, one or more keys may be stored on a tamper-resistant or tamper-proof physical tag (e.g., a tamper-proof RFID tag) to further ensure the authenticity and security of both the digital tokens and other assets associated with these physical tokens.

[0058] In one example where a pair of cryptographic key sets is used to secure a digital token, a first set of keys in the pair of cryptographic key sets may be keys used in an asymmetric cryptography scheme, and a second set of keys in the pair of cryptographic key sets may be keys used in a symmetric cryptography scheme (or vice versa). To secure a digital token associated with some other asset, a first encrypted payload may be stored in memory on a physical tag attached to or integrated with the other asset. This first encrypted payload may include, for example, a unique identifier of the other asset (e.g., an RFID tag identifier or other physical device or asset identifier) ​​and may be secured using a first encryption key and information related to the current owner of the other asset (e.g., a private key associated with a wallet in which a digital token corresponding to the other asset is stored). A second related payload may be stored on-chain to prove ownership of the digital token and the asset associated with the digital token. To secure the digital token, the second payload may be encrypted using a second set of encryption keys. In some aspects, the second payload may be encrypted using a public key component of the second encryption key set such that only a holder of the private key component of the second encryption key set can decrypt and access the digital token.

[0059] FIG. 4 illustrates an example pipeline 400 for securely generating and accessing a digital token that corresponds to another asset based on a physical device identifier.

[0060] As shown, pipeline 400 includes a physical object 410, a client device 420, and a blockchain 122 communicatively coupled to one another. Physical object 410 may be an object that has an associated digital token for which a record is stored on blockchain 122. Physical object 410 may be, for example, a collectible object in which sensitive data is stored, a physical document, an electronic data storage device, or other object whose digital counterpart exists and is maintained on the blockchain.

[0061] To create a digital token, the use of a particular encryption key may be confirmed between the physical object 410 and the client device 420 via the tag reader 422. To do so, the physical object 410 may transmit, via the object tag 412, an encrypted payload that includes known or otherwise verifiable data, such as information that identifies the physical object 410 (e.g., a serial number or other unique identifier of the physical object 410 or object tag 412). The tag reader 422 may receive (or read) this encrypted payload and attempt to decrypt the encrypted payload using one or more keys. If the encrypted payload is successfully decrypted using an encryption key (e.g., the payload matches some known or otherwise verifiable data), the client device 420 may encrypt the payload using that encryption key for storage on the physical object 410. The encrypted payload stored on the physical object 410 may, in some aspects, include a private key associated with the owner or user of the client device 420 (which may be the private key component of a public-private key pair used in an asymmetric encryption scheme) and an identifier associated with the physical object 410.

[0062] The client device 420 further generates an encrypted payload to be committed to the blockchain 122. The encrypted payload may include, for example, the digital token (or a locator that allows access to the digital token) and an identifier associated with the physical object 410. To protect the digital token, the encrypted payload and other data committed to the blockchain 122 may be encrypted using a public key associated with the wallet in which the digital token should be stored. As described, the encrypted payload may generally not be recoverable by parties other than the wallet owner, since the corresponding private key should generally be kept secret and accessible only to the wallet owner.

[0063] Similar to creating a digital token, to access the digital token (e.g., for transfer from one owner to a new owner), the use of a particular encryption key may be verified between the physical object 410 and the client device 420 via the tag reader 422. A key checker 424 uses the particular encryption key to derive a wallet private key value and an identifier for the physical object 410. If the key checker 424 determines that the wallet private key derived from the encryption key provided by the physical object 410 matches a known wallet private key (e.g., a private key owned by the user of the client device 420), the key checker 424 may determine that the user of the client device 420 has possession of both the keys needed to confirm ownership of the digital token and other assets associated with the digital token (e.g., by being able to decrypt an encrypted payload from the physical object 410 or being able to derive a wallet private key from a symmetric key used by the physical object 410 to encrypt the payload) and the keys needed to decrypt the digital token.

[0064] The key checker 424 can provide information verifying ownership of the digital token and verifying ownership (or at least possession) of both keys needed to decrypt the digital token to the physical device 410. Based on receiving this verifying information, the physical device 410 can provide an identifier of its physical device to the client device 410. Generally, as described, the identifier of its physical device can be a serial number of the physical device 410, an identifier of a subscriber identity module (SIM) associated with the physical device 410 (e.g., an integrated circuit card identity (ICCID) number), an international mobile equipment identity (IMEI) associated with the physical device, an identifier of an RFID module (e.g., object tag 412) associated with the physical device 410, etc. In some aspects, the confirmation information provided to the physical device 410 may be a binary indication that the client device 420 has ownership (or at least possession) of the appropriate keys, an encrypted payload that can be decrypted by the physical device 410, a signed payload that can be verified by the physical device 410, or other data that proves ownership (or possession) of the appropriate keys involved in securing the digital token on the blockchain 122.

[0065] The token encryptor / decryptor 426 can retrieve an encrypted payload containing the digital token from the blockchain 122. In some aspects, the encrypted payload can include an encrypted uniform resource indicator (URI) and an encrypted version of the identifier of the physical device 410. Using the wallet private key, the token encryptor / decryptor 426 can attempt to decrypt the encrypted payload. If the data resulting from an attempt to decrypt the encrypted payload resolves to incomprehensible data, the user of the client device 420 may not be able to access the digital token stored on the blockchain 122. However, if decrypting the encrypted payload results in valid data and the decrypted identifier of the physical device 410 matches the actual identifier of the physical device 410, the ownership of the physical device 410 and the associated digital token can be confirmed.

[0066] The user of the client device 420 can then access the digital token and provide information about the physical device and the digital token to the transferee party. The transferee party can negotiate keys to be used to confirm future ownership of the physical object 410 and the digital token associated with the physical object 410, generate an encrypted payload, and commit the payload to the physical object 410 (e.g., on the object tag 412) and to the blockchain 122.

[0067] Although the tag reader 422, key checker 424, and token encryptor / decryptor 426 are shown as separate components, it should be recognized by one of ordinary skill in the art that these components may be separate or combined into one or more other components. In some aspects, the tag reader 422, key checker 424, and token encryptor / decryptor 426 may be deployed as components in one or more of the token generator 112, token extractor 114, and / or token transferor 116 of the token processing system 110 shown in FIG. 1.

[0068] 5 illustrates example operations 500 for securely accessing digital tokens corresponding to other assets on a blockchain. The operations 500 described herein may be performed, for example, by the token generator 112 shown in FIG. 1, the client device 420 shown in FIG. 4, etc.

[0069] As shown, the operation 500 begins at block 510 with retrieving a payload associated with a first set of encryption keys from a tag associated with a physical object having a digital token counterpart. In some aspects, the payload may be encrypted using the first set of encryption keys and may include information regarding a decryption key for the encrypted payload, including information regarding the digital token and information identifying the physical object. The tag may be, for example, an RFID tag in which the payload is stored and may be updated when ownership of the physical object and the digital token counterpart is transferred. In some aspects, the payload may be a first set of encryption keys based on other data of the digital token counterpart that can be used to access the physical object.

[0070] At block 520, the operation 500 proceeds to retrieve a second set of encryption keys and an identifier of the physical object based on the retrieved payload. In some aspects, the payload may be decrypted using an appropriate decryption key that corresponds to the encryption key used to encrypt the payload. If the payload is encrypted using a symmetric encryption scheme, the encryption key and the decryption key may be the same key. If the payload is encrypted using an asymmetric encryption scheme, the encryption key may be a public key and the decryption key may be a corresponding private key.

[0071] In some aspects, the payload may include a key or other data that may be provided as input to a key derivation function, which may be a function designed to generate one or more keys based on the input (and other data, such as encryption salts).

[0072] At block 530, the operation 500 proceeds with verifying possession of the first set of encryption keys and the second set of encryption keys. In some aspects, possession of the first set of encryption keys and the second set of encryption keys may be verified at a physical device.

[0073] At block 540, the operations 500 proceed with receiving an identifier for the physical object based on verifying possession of the first set of encryption keys and the second set of encryption keys.

[0074] At block 550, the operations 500 proceed with decrypting the payload from the blockchain, including the digital token counterpart of the physical object and an identifier of the physical token, based on the second set of encryption keys. In some aspects, decrypting the payload from the blockchain may include decrypting the encrypted payload using the second set of encryption keys. The decrypted payload may include a URI that identifies a location where the digital token counterpart of the physical token is located and an identifier of the physical object associated with the digital token counterpart.

[0075] At block 560, the operation 500 proceeds with accessing the digital token counterpart of the physical object based on the decrypted payload from the blockchain. In some aspects, the decrypted identifier of the physical object may be compared to the received identifier of the physical object to access the digital token counterpart of the physical object. If the decrypted identifier of the physical object and the received identifier of the physical object match, it may be confirmed that the holder of the second set of encryption keys is the legitimate owner of the physical object and the digital token counterpart. Based on this confirmation, access to the digital token counterpart may be granted. However, if the decrypted identifier of the physical object and the received identifier of the physical object do not match, it may be confirmed that there is a mismatch between the holder of the second set of encryption keys and the legitimate owner of the physical object, and therefore, access to the digital token counterpart for the physical object may be blocked.

[0076] Exemplary System for Generating and Maintaining Digital Tokens Based on Physical Device Identifiers Figure 6 illustrates an example system 600 configured to perform methods described herein, including, for example, operation 300 of Figure 3 and / or operation 500 of Figure 5. In some embodiments, system 600 may serve as a token processing system, such as token processing system 110 illustrated in Figure 1.

[0077] As shown, system 600 includes a central processing unit (CPU) 602, one or more I / O device interfaces 604 that may enable connection of various I / O devices 614 (e.g., keyboards, displays, mouse devices, pen input, etc.) to system 600, a network interface 606 through which system 600 is connected to a network (which may be a local network, an intranet, the Internet, or any other group of computing devices communicatively connected to one another), memory 608, and an interconnect 612. I / O devices 614 and / or network interface 606 may be used to receive requests to create, retrieve, and transfer digital tokens on the blockchain.

[0078] CPU 602 may retrieve and execute programming instructions stored in memory 608. Similarly, CPU 602 may retrieve and store application data in memory 608. Interconnect 612 transmits programming instructions and application data between CPU 602, I / O device interface 604, network interface 606, and memory 608.

[0079] CPU 602 is included to represent a single CPU, multiple CPUs, a single CPU with multiple processing cores, and the like.

[0080] Memory 608 may represent volatile memory, such as random access memory, or non-volatile memory, such as non-volatile random access memory, phase-changing random access memory, etc. As shown, memory 608 includes a token generator 620, a token extractor 630, a token mover 640, and a key data store 650.

[0081] 1 and may enable the generation of digital tokens corresponding to other assets using a first private key and a second private key. The token generator 620 may receive the first private key, which may be a private key associated with a wallet into which the digital token is to be deposited, and the second private key, which may be a physical identifier of a physical device owned by the owner of the digital token and the underlying asset for which the digital token is to be generated.

[0082] In some aspects, the second private key may be obtained by reading a physical identifier of the physical device via the physical device identifier reader 610 and its associated antenna 616, which may enable the system 600 to wirelessly read and / or write data via an NFC connection with the physical device, wirelessly read and / or write data stored on an RFID tag, wirelessly read and / or write data via a BLE connection with the physical device, etc. In some aspects, the second private key may be obtained via manual entry of a physical identifier of the physical device through the I / O device 614, via the I / O device interface 604.

[0083] A public key may be derived from the first key and the second key, and the token generator 620 may use the public keys to separately encrypt metadata about the digital token and the location where the underlying asset may be accessed. The digital token, including the separately encrypted metadata and location information, may be minted, and a record attesting to the creation of the digital token and the initial ownership of the digital token and the underlying asset by the wallet owner may be committed to a blockchain on an external network via the network interface 606.

[0084] The token retriever 630 may correspond to the token retriever 114 shown in Figure 1. Generally, the token retriever 630 may enable an owner of a digital token, or an intended person having both the first and second private keys, to retrieve the digital token and decrypt the location information and metadata stored in the digital token. The encrypted information may remain encrypted in transit from the token retriever 630 to a remote client device (e.g., via the network interface 606) such that the security of the data stored in the digital token may be maintained.

[0085] The token transferor 640 may correspond to the token transferor 116 shown in FIG. 1 and may enable an owner of the digital token and the underlying asset to transfer ownership of the digital token and the underlying asset to a transferee or new owner. To do so, the token transferor 640 may require the transferor's private key and the transferee's public key. The transferor's private key (e.g., the private key for the transferor's wallet and the physical identifier of the transferor's physical device) may be used to decrypt the metadata and address information for the underlying asset, and the transferee's public key may be used to re-encrypt the metadata and address information for the underlying asset. The token transferor 640 may then generate a record for the commitment to the blockchain on the external network via the network interface 606 that attests to the transfer of ownership of the digital token from the transferor to the transferee.

[0086] In some aspects, the first private key may be stored in a key data store 650 in memory 608. The key data store 650 may enable various encryption and / or decryption keys (e.g., public and / or private keys) to be securely maintained on the system 600 for use by the token generator 620 to encrypt metadata in the digital token, and for use by the token extractor 630 and the token transferor 640 to decrypt metadata in the digital token. To provide additional security, the second private key and the second public key may not be stored in the key data store 650 since they require presentation of the second private key and the second public key for generation, viewing, and transfer of the digital token. Compromising system 600 by not storing the second private key and the second public key in key data store 650 may still not allow malicious users to take any action with respect to digital tokens owned by the owner of system 600, since these malicious users may still not have access to the keys needed to decrypt the addresses where the underlying assets associated with the digital tokens are located.

[0087] Example clauses Example implementations are described in the following numbered clauses.

[0088] Clause 1. A method comprising: receiving a request to create a digital token corresponding to an asset; receiving a first private key associated with a wallet in which the digital token is to be stored; receiving a second private key from a physical device associated with an owner of the asset; encrypting an address of the asset with a public key associated with the second private key; encrypting metadata associated with the digital token with the public key associated with the first private key; and minting the digital token on a blockchain based on the encrypted address of the asset and the encrypted metadata.

[0089] Clause 2. The method of clause 1, wherein receiving the second private key includes reading an identifier of the physical device via a near field communication (NFC) data connection.

[0090] Clause 3. The method of clause 2, wherein the identifier of the physical device includes an identifier of an NFC chip on the physical device.

[0091] Clause 4. The method of any one of clauses 1 to 3, wherein receiving the second private key includes receiving an entry for an identifier associated with the physical device.

[0092] Clause 5. The method of clause 4, wherein the identifier comprises an associated serial number of a physical device associated with the owner of the asset.

[0093] Clause 6. The method of clause 4 or 5, wherein the identifier comprises a subscriber identity module (SIM) identifier.

[0094] Clause 7. The method of any one of clauses 4 to 6, wherein the identifier comprises an International Mobile Equipment Identity (IMEI) associated with the physical device.

[0095] Clause 8. The method of any one of clauses 4 to 7, wherein the identifier comprises an identifier of a radio frequency identifier (RFID) module of the physical device.

[0096] Clause 9. The method of any one of clauses 1 to 8, wherein the metadata associated with the digital token includes a Uniform Resource Indicator (URI) that identifies the location where the asset is stored.

[0097] Clause 10. The method of any one of clauses 1 to 9, wherein metadata associated with the digital token includes secret data used to generate the public data stored in the asset.

[0098] Clause 11. The method of any one of clauses 1 to 10, further comprising receiving a request to view the asset; receiving a second private key; retrieving the digital token; decrypting the encrypted address of the asset from the digital token using the second private key; and returning the decrypted address of the asset and the encrypted metadata in the digital token as a set of public key hashes decryptable using the first private key.

[0099] Clause 12. The method of clause 11, wherein receiving the second private key includes reading an identifier of the physical device via a near field communication (NFC) data connection.

[0100] Clause 13. The method of any one of clauses 1 to 12, further comprising: receiving a request to transfer the digital token from the wallet to a second wallet; requesting a public key associated with the second wallet and a public key of a second physical device to be associated with the digital token; and transferring ownership of the digital token to a user associated with the second wallet based on the first private key, the second private key, the public key associated with the second wallet, and the public key of the second physical device.

[0101] Clause 14. The method of any one of clauses 1 to 13, wherein the digital token comprises a non-fungible token (NFT) having an ownership record maintained on a blockchain.

[0102] Clause 15. The method of any one of clauses 1 to 14, further comprising committing the digital token to a wallet.

[0103] Clause 16. A processor-implemented method, comprising: retrieving a payload associated with a first set of encryption keys from a tag associated with a physical object having a digital token counterpart; retrieving a second set of encryption keys and an identifier for the physical object based on the retrieved payload; verifying possession of the first set of encryption keys and the second set of encryption keys; receiving an identifier for the physical object based on verifying possession of the first set of encryption keys and the second set of encryption keys; decrypting a payload from the blockchain including the digital token counterpart of the physical object and the identifier of the physical token based on the second set of encryption keys; and accessing the digital token counterpart of the physical object based on the decrypted payload from the blockchain.

[0104] Clause 17. The method of clause 16, wherein the payload associated with the first set of encryption keys includes a second set of encryption keys and an identifier of a physical object encrypted using the first set of encryption keys.

[0105] Clause 18. The method of clause 16 or 17, wherein the first set of encryption keys includes keys used in a symmetric encryption scheme.

[0106] Clause 19. The method of any one of clauses 16 to 18, wherein deriving the second set of cryptographic keys and the identifier of the physical object comprises decrypting the retrieved payload based on the first set of cryptographic keys.

[0107] Clause 20. The method of any one of clauses 16 to 19, wherein the second set of encryption keys comprises a private key counterpart to a public key used to encrypt a payload from the blockchain comprising a digital token counterpart of the physical object and an identifier of the physical object.

[0108] Clause 21. The method of any one of clauses 16 to 20, wherein verifying possession of the first set of encryption keys and the second set of encryption keys comprises comparing the retrieved second set of encryption keys to a known second set of encryption keys, comparing the retrieved identifier of the physical object to the known identifier of the physical object, and verifying possession of the first set of encryption keys and the second set of encryption keys based on determining that the retrieved second set of encryption keys matches the known second set of encryption keys and that the retrieved identifier of the physical object matches the known identifier of the physical object.

[0109] Clause 22. The method of any one of clauses 16 to 21, wherein verifying possession of the first set of encryption keys and the second set of encryption keys comprises sending an indication to a tag associated with the physical object that the first set of encryption keys and the second set of encryption keys have been verified.

[0110] Clause 23. The method of any one of clauses 16 to 22, wherein accessing the digital token counterpart of the physical object based on the decrypted payload from the blockchain comprises determining that a decrypted version of the digital token resulted in understandable data, determining that an identifier of the physical token, decrypted based on the second set of encryption keys, matches the received identifier of the physical object, and retrieving the digital token counterpart based on determining that the decrypted version of the digital token resulted in understandable data and that an identifier of the physical token, decrypted based on the second set of encryption keys, matches the received identifier of the physical object.

[0111] Clause 24. A system comprising a memory having executable instructions stored therein and a processor configured to execute the executable instructions to perform the operations of any one of clauses 1 to 23.

[0112] Clause 25. A system comprising means for performing the operations described in any one of clauses 1 to 23.

[0113] Clause 26. A non-transitory computer readable medium storing instructions which, when executed by a processor, cause the processor to perform the operations recited in any one of clauses 1 to 23.

[0114] Additional Considerations The preceding description is provided to enable those skilled in the art to practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of the elements described without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components, as appropriate. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented and a method may be practiced using any number of aspects described herein. Furthermore, the scope of the disclosure is intended to cover such apparatus or methods practiced using other structures, functions, or structures and functions in addition to or other than the various aspects of the disclosure described herein. It should be understood that the aspects of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0115] As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including single members. As an example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other permutation of a, b, and c).

[0116] The term "determining" as used herein encompasses a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, and the like. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, "determining" may include resolving, selecting, choosing, establishing, and the like.

[0117] The methods disclosed herein include one or more steps or actions for achieving the method. Method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims. Furthermore, various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions. Those means may include various hardware and / or software components and / or modules, including but not limited to circuits, application specific integrated circuits (ASICs), or processors. Generally, where there are operations illustrated in the figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.

[0118] The various example logic blocks, modules and circuits described in connection with this disclosure may be implemented or embodied in a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0119] The processing system may be implemented with a bus architecture. The bus may include any number of interconnecting buses and bridges depending on the particular application of the processing system and the overall design constraints. The bus may link various circuits together, including the processor, machine-readable media, and input / output devices, among others. A user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits, such as timing sources, peripherals, voltage regulators, power management circuits, etc., that are well known in the art and therefore will not be described further. The processor may be implemented with one or more general-purpose and / or special-purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits capable of executing software. Those skilled in the art will recognize how to best implement the functionality described for the processing system depending on the particular application and the overall design constraints imposed on the overall system.

[0120] If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Software shall be broadly construed to mean instructions, data, or any combination thereof, whether termed software, firmware, middleware, microcode, hardware description language, or otherwise. Computer-readable media includes both computer storage media and communication media, such as any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and for general processing, including the execution of software modules stored on the computer-readable storage medium. The computer-readable storage medium may be coupled to the processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral to the processor. By way of example, the computer-readable medium may include a transmission line, a carrier wave modulated by data, and / or a computer-readable storage medium with instructions stored thereon that is separate from the wireless node, all of which may be accessed by the processor through a bus interface. Alternatively or additionally, the computer-readable medium, or any portion thereof, may be incorporated into the processor, such as may be the case with a cache and / or a general-purpose register file. Examples of machine-readable storage media may include, by way of example, a RAM (random access memory), a flash memory, a ROM (read-only memory), a PROM (programmable read-only memory), an EPROM (erasable programmable read-only memory), an EEPROM (electrically erasable programmable read-only memory), a register, a magnetic disk, an optical disk, a hard drive, or any other suitable storage medium, or any combination thereof. The machine-readable medium may be embodied in a computer program product.

[0121] A software module may comprise a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across multiple storage media. A computer-readable medium may comprise several software modules. A software module includes instructions that, when executed by a device such as a processor, cause a processing system to perform various functions. A software module may include a transmitting module and a receiving module. Each software module may be in a single storage device or distributed across multiple storage devices. As an example, a software module may be loaded into RAM from a hard drive when a triggering event occurs. During execution of a software module, a processor may load some of the instructions into a cache to increase access speed. One or more cache lines may then be loaded into a general-purpose register file for execution by the processor. When referring to a function of a software module, it will be understood that such function is implemented by a processor when executing instructions from that software module.

[0122] The following claims are not limited to the embodiments set forth herein, but are to be accorded the full scope consistent with the language of the claims. Within the claims, reference to an element in the singular does not mean "only one" unless expressly stated as such, but rather means "one or more." The term "some" refers to one or more, unless expressly stated otherwise. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, unless the element is recited using the phrase "step for." All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or that later become known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is made public, regardless of whether such disclosure is expressly recited in the claims.

Claims

1. Receiving a request to create a digital token corresponding to an asset; receiving a first private key associated with a wallet in which the digital token is to be stored; receiving a second private key from a physical device associated with an owner of the asset; encrypting the address of the asset with a public key associated with the second private key; encrypting metadata associated with the digital token with a public key associated with the first private key; minting the digital token based on the encrypted address of the asset and the encrypted metadata on a blockchain; 23. A processor implementation method comprising:

2. The method of claim 1 , wherein receiving the second private key comprises reading an identifier of the physical device over a near field communication (NFC) data connection.

3. The method of claim 2 , wherein the identifier of the physical device comprises an identifier of an NFC chip on the physical device.

4. The method of claim 1 , wherein receiving the second private key comprises receiving an entry for an identifier associated with the physical device.

5. The method of claim 4 , wherein the identifier comprises an associated serial number of the physical device associated with the owner of the asset.

6. The method of claim 4 , wherein the identifier comprises a subscriber identity module (SIM) identifier.

7. The method of claim 4 , wherein the identifier comprises an International Mobile Equipment Identity (IMEI) associated with the physical device.

8. The method of claim 4 , wherein the identifier comprises an identifier of a radio frequency identifier (RFID) module of the physical device.

9. The method of claim 1 , wherein the metadata associated with the digital token includes a Uniform Resource Indicator (URI) that identifies a location where the asset is stored.

10. 10. The method of claim 1, wherein the metadata associated with the digital token includes private data used to generate public data stored in the asset.

11. receiving a request to view the asset; receiving the second private key; Retrieving the digital token; and decrypting the encrypted address of the asset from the digital token using the second private key; returning the decrypted address of the asset and the encrypted metadata in the digital token as a set of public key hashes decryptable using the first private key; The method of claim 1 further comprising:

12. The method of claim 11 , wherein receiving the second private key comprises reading an identifier of the physical device over a near field communication (NFC) data connection.

13. receiving a request to transfer the digital token from the wallet to a second wallet; Requesting a public key associated with the second wallet and a public key of a second physical device to be associated with the digital token; transferring ownership of the digital token to a user associated with the second wallet based on the first private key, the second private key, the public key associated with the second wallet, and the public key of the second physical device; The method of claim 1 further comprising:

14. 10. The method of claim 1, wherein the digital token comprises a non-fungible token (NFT) having an ownership record maintained on a blockchain.

15. 10. The method of claim 1, further comprising committing the digital token to the wallet.

16. Retrieving a payload associated with a first set of cryptographic keys from a tag associated with a physical object having a digital token counterpart; deriving a second set of encryption keys and an identifier for the physical object based on the retrieved payload; confirming possession of the first set of encryption keys and the second set of encryption keys; receiving an identifier of the physical object based on verifying possession of the first set of encryption keys and the second set of encryption keys; decrypting a payload from the blockchain, the payload including the digital token counterpart of the physical object and the identifier of a physical token, based on the second set of encryption keys; accessing the digital token counterpart of the physical object based on the decrypted payload from the blockchain; 23. A processor implementation method comprising:

17. 17. The method of claim 16, wherein the payload associated with the first set of encryption keys includes the second set of encryption keys and the identifier of the physical object encrypted using the first set of encryption keys.

18. 20. The method of claim 16, wherein the first set of encryption keys comprises keys used in a symmetric encryption scheme.

19. 17. The method of claim 16, wherein retrieving the second set of encryption keys and the identifier of the physical object comprises decrypting the retrieved payload based on the first set of encryption keys.

20. 17. The method of claim 16, wherein the second set of encryption keys comprises a private key counterpart to a public key used to encrypt the payload from the blockchain, including the digital token counterpart of the physical object and the identifier of the physical object.

21. Verifying possession of the first set of encryption keys and the second set of encryption keys includes: comparing the retrieved second set of encryption keys with a known second set of encryption keys; comparing the retrieved identifier of the physical object with a known identifier of the physical object; verifying possession of the first set of encryption keys and the second set of encryption keys based on determining that the retrieved second set of encryption keys matches the known second set of encryption keys and that the retrieved identifier of the physical object matches the known identifier of the physical object; 17. The method of claim 16, comprising:

22. 17. The method of claim 16, wherein verifying possession of the first set of encryption keys and the second set of encryption keys includes sending an indication to the tag associated with the physical object that the first set of encryption keys and the second set of encryption keys have been verified.

23. Accessing the digital token counterpart of the physical object based on the decrypted payload from the blockchain includes: determining that a decrypted version of the digital token resulted in intelligible data; determining that the identifier of the physical token decrypted based on the second set of encryption keys matches the received identifier of the physical object; retrieving the digital token counterpart based on determining that the decrypted version of the digital token resulted in intelligible data and that the identifier of the physical token decrypted based on the second set of encryption keys matches the received identifier of the physical object.

17. The method of claim 16, comprising:

Images