Non-custodial techniques for fine-grained encryption and decryption

Abstract

Non-custodial techniques for fine-grained encryption and decryption are provided. One example method can include receiving, via a user interface, a selection of a data object to encrypt from a plurality of data objects in a data package, receiving a message from a remote server, generating an encryption key for the data object using the message, encrypting the data object using the encryption key, creating the encrypted data object, storing at least a portion of the message associated with the encrypted data object in a metadata file, encrypting the metadata file using the user's encryption key to create the encrypted metadata file, and transmitting the encrypted data object and the encrypted metadata file to a database for storage.

Description

[Technical Field]

[0001] The present invention relates generally to data storage, and more particularly to non-custodial techniques for encryption and decryption of data at a fine-grained level. [Background technology]

[0002]

[0002] Modern web applications and other online software platforms collect and store large amounts of user-generated data. This data is often monetized by the platform, for example, to generate advertising revenue. While users are permitted to export and monetize this data, efficiently and securely storing large amounts of sensitive data can be challenging for users. Users may not be familiar with file encryption and decryption technologies. Furthermore, users may be hesitant to entrust their sensitive data to a third-party storage provider. Summary of the Invention [Means for solving the problem]

[0003]

[0003] Various examples of employing non-custodial techniques for data encryption and decryption are described. One example of non-custodial encryption includes receiving, via a user interface, a selection of a data object to be encrypted from multiple data objects in a data package, receiving a message from a remote server, generating an encryption key for the data object using a token message, encrypting the data object using the encryption key to create the encrypted data object, storing at least a portion of the message associated with the encrypted data object in a metadata file, encrypting the metadata file using a user's encryption key to create the encrypted metadata file, and transmitting the encrypted data object and the encrypted metadata file for storage in a database.

[0004] An exemplary client device for non-custodial encryption may include a communications interface, a non-transitory computer-readable medium, and a processor communicatively coupled to the communications interface and the non-transitory computer-readable medium. The processor may be configured to execute processor-executable instructions stored on the non-transitory computer-readable medium and to receive, via a user interface, a selection of data objects for encryption from a data package, the data package comprising a plurality of data objects, receive a message from a remote server, the message comprising a secret token associated with the data objects, generate an encryption key for the data objects using the message, encrypt the data objects using the encryption key to create encrypted data objects, store the secret token in a metadata file, encrypt the metadata file using a user's public key, and send the encrypted data objects and the encrypted metadata file to a database for storage.

[0005]

[0005] An example method for decryption by a remote server may include receiving a request for a data object from an exchange platform. The data object is stored in a database as an encrypted data object. The example method of decryption may also include sending a notification message to the client device requesting a response from the client device regarding the request and receiving a response message from the client device acknowledging the request. The example method for decryption may further include having the database send an encrypted metadata file to the client device upon receiving the response message, the encrypted metadata file including a secret token associated with the encrypted data object, the encrypted metadata file being encrypted with a user public key, the client device being configured to decrypt the encrypted metadata file using a user private key paired with the user public key to identify the secret token associated with the encrypted data object, the client device being configured to generate a cryptographic signature using the secret token associated with the encrypted data object and sending the cryptographic signature to the exchange platform, the exchange platform being configured to generate a decryption key using the cryptographic signature.

[0006]

[0006] Another example method of decryption by an exchange server includes requesting access to a data object associated with a user from a remote server, receiving a data package from the remote server comprising a plurality of encrypted data objects, the data object corresponding to one encrypted data object of the plurality of encrypted data objects, receiving a decryption key associated with the encrypted data object, the decryption key not associated with any other encrypted data object of the plurality of encrypted data objects, and decrypting the encrypted data object using the decryption key.

[0007]

[0007] An example system for decryption may include a non-transitory computer-readable medium, a communications interface, and a processor communicatively coupled to the communications interface and the non-transitory computer-readable medium. The processor may be configured to execute processor-executable instructions stored on the non-transitory computer-readable medium to receive a request for a data object from an exchange platform, the data object being stored as an encrypted data object in a database, send a notification message to the client device requesting a response from the client device regarding the request, receive a response message from the client device acknowledging the request, and, upon receiving the response message, cause the database to send an encrypted metadata file to the client device. The encrypted metadata file comprises a secret token associated with the encrypted data object, and the encrypted metadata file is encrypted with a user public key. The client device is configured to decrypt the encrypted metadata file using a user private key paired with the user public key, generate a decryption key using the secret token associated with the encrypted data object, and send the decryption key to the exchange platform. The exchange platform is configured to decrypt the data object using the decryption key.

[0008] These examples are not intended to limit or define the scope of the present disclosure, but rather to provide examples to aid in its understanding. Specific examples are described in greater detail in the detailed description. Advantages offered by the various examples may be further understood by examining this specification. [Brief explanation of the drawings]

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more specific examples and, together with the description of the examples, serve to explain the principles and implementations of the particular examples. [Figure 1] 1 illustrates an exemplary system for fine-grained encryption and decryption using non-custodial techniques. [Figure 2] 1 illustrates an exemplary system in which a client device encrypts a data object. [Figure 3] 1 illustrates an exemplary data package containing multiple data objects. [Figure 4] 10 illustrates an example of a signing request sent from a remote server to a client device. [Figure 5] 1 shows an exemplary metadata file. [Figure 6] 1 illustrates an exemplary system in which an exchange platform decrypts an encrypted data object. [Figure 7] 4 illustrates an exemplary request sent from an exchange platform to a remote server to access a data object. [Figure 8] 1 illustrates an exemplary method for fine-grained encryption using non-custodial techniques. [Figure 9] 1 illustrates an exemplary method for decrypting a non-custodial encrypted data object. [Figure 10] 1 illustrates an exemplary computing device suitable for use in an exemplary system or method employing non-custodial techniques for encrypting and decrypting data at a fine-grained level in the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0010]

[0020] Examples are described herein in the context of non-custodial techniques for encrypting and decrypting data. Those skilled in the art will appreciate that the following description is for illustrative purposes only and is not intended to be limiting in any way. Reference will now be made in detail to the embodiments illustrated in the accompanying drawings. Like reference indicators are used throughout the drawings and the following description to refer to the same or similar items.

[0011]

[0021] For clarity, not all of the routine features of the examples described herein are shown and described. Of course, it will be understood that in developing any such actual implementation, many implementation-specific decisions will need to be made to achieve the developer's particular goals, such as compliance with application and business-related constraints, and that these particular goals will vary from implementation to implementation and from developer to developer.

[0012]

[0022] For various reasons, users may wish to store data with a storage provider. For example, storing large amounts of data locally may simply be inconvenient. As another example, users may wish to provide their data to a third party for revenue generation. If the data is sensitive, users who wish to store their data with a storage provider must trust that the storage provider will respect and maintain their privacy. Encrypting data after it is transferred to the storage provider is an inadequate solution because privacy may be compromised before encryption. Furthermore, this approach requires that the means and secrets associated with encrypting the data remain in the hands of the storage provider. In particular, if the storage provider encrypts the data itself, it must also retain the encryption keys used for encryption, potentially compromising user privacy if the storage provider is compromised by a malicious attacker.

[0013]

[0023] One solution to this problem is for users to encrypt their data and send the encrypted data to the storage provider. However, this presents users with the technical challenges of operating encryption software and key management. For most users, the risks and challenges associated with key management alone are great enough to make manual encryption an impractical solution. Therefore, a technology is needed that allows users to encrypt data before sending it to a storage provider without requiring specialized knowledge of encryption technology and without ceding control of the encryption secret to the storage provider. That is, users can seamlessly encrypt their own data using only a secret that they can hold or generate before sending it to the storage provider.

[0014]

[0024] Another problem arises when users want to share or monetize only parts of their encrypted data. If user data is encrypted in a single package, users may not know where their content is stored. It is also difficult to share specific parts with third parties without disclosing the entire data package. Decrypting files on the client device and then sending them to third parties can strain the client device's processing power and consume a large amount of network bandwidth, especially for large files.

[0015]

[0025] To address these issues, examples of non-custodial techniques for encrypting and decrypting data at a granular level are described herein. In one example, a remote server provides a web application for encrypting data objects on a client device, and a user downloads the web application via a web browser. The user can then use the web application running in the web browser to select and encrypt data objects, and upload and store the encrypted data objects in a database.

[0016]

[0026] Using a web application, a user can select and encrypt data objects in a data package from local storage on the client device. Data objects can be folders (or hierarchical folder structures) or data files of any format. Data packages are user-managed; that is, the user owns or controls access to the data package. A data package can contain data generated or owned by the user, such as through the use of a specific service application. A data package can be a multi-level data package with different hierarchical levels. In one example, a multi-level data package is a zip folder containing three levels: the top level is the zip folder; the second level contains two or more folders within the zip folder; and the third level contains the data files within each folder in the second level. Folders and data files at various levels, excluding the top-level folder, can be selected for encryption. That is, the web application can encrypt all folders and data files contained in a zip folder, but the zip folder itself is not encrypted. This method allows for fine-grained encryption of multi-level data packages.

[0017]

[0027] In this example, when a user is ready to upload a first data object from a multilevel data package, the user clicks an "Upload" button on the web application, and a dialog box appears that allows the user to select the first data object to encrypt and then upload it to the storage system. Selecting the first data object generates an encryption request to a remote server. The remote server responds by randomly generating a first secret token (e.g., "abcd1234"). A first signature request is sent to the web application. The first signature request includes the first secret token and information about a first signature algorithm. The first signature request instructs the web application to cryptographically sign the first secret token using the first signature algorithm specified in the first signature request and create a first cryptographic signature using a private key available only to the user. The first cryptographic signature can be a randomly generated string. For example, the signature is a hexadecimal value such as 0x1e99398d.

[0018]

[0028] The first cryptographic signature is then converted into a text string and used as input to a first symmetric encryption algorithm. The first symmetric encryption algorithm uses the first cryptographic signature to generate a first symmetric encryption key. The first data object is then encrypted using the symmetric encryption key to create a first encrypted data object. The first encrypted data object is then uploaded to a storage provider's database for storage.

[0019]

[0029] Meanwhile, the first token message is stored in a metadata file along with a description of the first data package. The metadata file may also include a location or address where the first encrypted data object is stored, such as a uniform resource locator (URL) for the first encrypted data object. The metadata file may also include information related to the first signature algorithm. The web application, the remote server, or the storage provider does not store either the first cryptographic signature or the first symmetric encryption key. Instead, they are generated by the web application using cryptographic information accessible only to the user, such as an electronic wallet or other cryptographic key storage mechanism. Thus, the selected data object is protected by both the user's unique access to the private key and the secret token provided by the remote server.

[0020]

[0030] The user can then select a second data object from the same multi-level data package from which the first data object was selected. When the user selects the second data object to encrypt and uploads it via the web application, a second encryption request is generated to the remote server. The remote server responds by randomly generating a second secret token. A second signature request is then sent to the web application. The second signature request includes a second token message containing the second secret token and information about a second signature algorithm. The second signature request instructs the web application to cryptographically sign the second secret token using the second signature algorithm specified in the second signature request and create a second cryptographic signature using a private key available only to the user. The second signature algorithm may be the same or different from the first signature algorithm used to create the first cryptographic signature. The second cryptographic signature is used as input to a second symmetric encryption algorithm. The second symmetric encryption algorithm uses the second cryptographic signature to generate a second symmetric encryption key. The second symmetric encryption algorithm may be the same as or different from the first symmetric encryption algorithm used to create the first symmetric encryption key. The second data object is then encrypted using the second symmetric encryption key to create a second encrypted data object. The second encrypted data object is then uploaded and stored in a storage provider's database. Meanwhile, the second secret token is stored in a metadata file along with a description of the second data package. The metadata file may also include a location or address where the first encrypted data object is stored, such as a URL for the second encrypted data object. The metadata file may also include information related to the second signature algorithm.

[0021]

[0031] Similarly, a user can select other data objects within the same multi-level data package, encrypt them individually, and upload them as other encrypted data objects. Similarly, the secret tokens generated for the selected other data objects are stored in a metadata file along with a description of the selected other data packages. The metadata file may also include the location or address where each other encrypted data object is stored, such as a URL for each other encrypted data object. The metadata file may also include information related to other signature algorithms used. The metadata file is a JavaScript Object Notation (JSON) file. Once all data objects that the user intends to encrypt and upload have been encrypted and uploaded, the user encrypts the metadata file using the user's encryption key. In some examples, the metadata file is encrypted with a public key, and the public key and private key are paired to create an encrypted metadata file. The encrypted metadata file is uploaded and stored in the storage provider's database.

[0022]

[0032] The remote server then publishes a schema for the encrypted data objects from the multi-level data package and the associated encrypted metadata file. The schema includes a name or description of each encrypted data object. The schema also includes a description of the data structure of the multi-level data package from which the encrypted data objects are selected. The schema further includes contact information for the user who owns the encrypted data object. The remote server, the storage provider, or another party can identify the data structure of the multi-level data package and the names or descriptions of the encrypted data objects, but cannot own or access the content of the encrypted data objects. In other words, the remote server can provide non-custodial encryption for the data package. The storage provider can store encrypted data objects, but cannot store unencrypted data objects or information necessary to decrypt the encrypted data objects.

[0023]

[0033] At a later date, a third party, such as an exchange platform, can send a request to the remote server seeking access to specific data objects owned by the user. The user can grant the exchange platform access to the requested specific data objects without providing access to all encrypted data objects. The exchange platform can be an application ecosystem consisting of one or more applications related to a specific product or service. The one or more applications can collect user data to create or improve the product or service. The exchange platform can be a marketplace platform that can monetize the data. In some examples, the exchange platform is a third-party platform. In some examples, the exchange platform is part of the remote server. In some examples, one or more applications on the exchange platform send a request message to the remote server to access specific data objects based on a schema published by the remote server. In some examples, the exchange platform itself sends a request message to the storage system to access specific data. The request message can be a JSON web token. The request message can include a range of required data, such as user transaction data at a specific store.

[0024]

[0034] In this example, a third-party exchange platform sends a request message for access to a data object. Upon receiving the request message, the remote server sends a notification message to the user who owns the requested data object, which is encrypted and stored at the storage provider. The notification message appears on the client device associated with the user as a web design element, such as a pop-up window or modal. The notification message includes options the user can select regarding the request, such as "Allow" or "Deny." If the user chooses to allow the request, the storage provider sends an encrypted metadata file to the user and transmits the encrypted data object to the third-party exchange platform. The user decrypts the encrypted metadata file in the web application using the user's unique private key. The owner then uses the private key to sign a token message stored in the metadata file corresponding to the encrypted data object and generates a cryptographic signature using the signature algorithm associated with the private token. The web application transmits the cryptographic signature for decrypting the encrypted data object to the third-party exchange platform. The remote server records the access request and the user's decision regarding the access request.

[0025]

[0035] Upon receiving the cryptographic signature of the encrypted data object, the third-party exchange platform uses the cryptographic signature as input to the same symmetric encryption algorithm that was used to encrypt the requested data object to obtain a symmetric decryption key that can decrypt the encrypted data object. The symmetric decryption key is the same as the symmetric encryption key used to encrypt the requested data object.

[0026]

[0036] The third-party exchange platform may also encrypt the decrypted data object using the remote server's public key and upload the public key encrypted data to the third-party exchange platform. Once the public key encrypted data is uploaded to the third-party exchange platform, the remote server may perform a fraud check. The fraud check may be initiated by the remote server to protect the integrity of the data, or by a user with whom the data object is supposed to be associated.

[0027]

[0037] In this example, the remote server initiates a fraud check on the data object provided by the third-party exchange platform. The remote server requests access to the corresponding data object from each user, similar to how the exchange platform obtains access to the requested data object from each user. Because each user has authorized the exchange platform to access the requested data, the non-custodial protocol is waived. When each user authorizes the request by sending a corresponding cryptographic signature to the remote server, the remote server decrypts the encrypted data object stored by the storage provider. Meanwhile, the remote server decrypts the public-key-encrypted data object using the private key paired with the public key. The remote server then compares the data object decrypted from the encrypted data object stored by each user on the storage provider with the data decrypted from the public-key-encrypted data object by the exchange platform. If the two data match, the data on the exchange platform can be authenticated. If the two data do not match, the data on the exchange platform cannot be authenticated. In other words, the data provided by the third-party exchange platform may be fraudulent.

[0028]

[0038] The non-custodial technology for encrypting and decrypting data at a granular level described herein provides users with greater control over their data, including preventing third parties from accessing user data without the user's consent. By encrypting data at a granular level, users can grant access only to requested user data without disclosing other user data. A metadata file provides a map of encrypted user data and their respective encryption / decryption solutions, allowing users to track data properties. A published schema of encrypted user data allows third parties to identify data to which they may wish to gain access. Third-party decryption reduces the load on the client device's processor, especially for large media files.

[0029]

[0039] This example is provided to introduce the reader to the general subject matter discussed herein, and the disclosure is not limited to this example. The following sections describe various additional non-limiting examples and examples of non-custodial techniques for encrypting and decrypting data.

[0030]

[0040] Referring to Figure 1, Figure 1 illustrates an exemplary system 100 for fine-grained encryption and decryption using non-custodial techniques. The exemplary system 100 includes a client device 102, a remote server 114, a storage provider 116, and an exchange platform 132, which are connected via one or more networks (collectively, networks 112).

[0031]

[0041] The client device 102 is a traditional computing device, such as a desktop or laptop computer, with a processor and computer-readable media, connected to a remote server 114, a storage provider 116, and an exchange platform 132 via a network 112. The client device 102 may also be a mobile device, such as a tablet or smartphone. The network 112 may include the Internet, any local area network ("LAN"), metro area network ("MAN"), wide area network ("WAN"), cellular network (e.g., 3G, 4G, 4G LTE, 5G), or any combination thereof.

[0032]

[0042] The client device 102 has access to a data object 118 containing user-specific data, such as confidential data. The data object may be a folder 118-1 or a data file 118-2. The data object may be stored in any suitable file structure selectable by the user and identifiable by the remote server web application 126 when launched in the web browser 120 on the client device 102. In some examples, the data object 118 is stored in the local storage module 104. However, the data object 118 may be stored anywhere typically accessible to the client application, such as a network drive, an external drive, or locally mounted cloud storage. The client device 102 includes a web browser 120 or similar application used to connect to the remote server 114 and storage provider 116 over the network 112. Native desktop applications on a desktop computer or dedicated mobile applications on a smartphone may also be used. The web browser 120 may include additional applications in the form of browser extensions, plug-ins, other add-ons, etc. The web browser 120 may be a blockchain browser suitable for accessing web3 decentralized applications. The web browser 120 may also have an integrated blockchain wallet. The memory module 124 temporarily stores data during program execution.

[0033]

[0043] In some examples, the web browser 120 includes a signing module 106, a key store 108, and an encryption module 122. These components may be installed as extensions to the web browser 120 or may reside within the browser runtime, for example, by Javascript code downloaded from a web application. In some examples, these components are standalone applications that run outside of the web browser 120. In some examples, some or all of these components are implemented by a blockchain wallet, which itself may be an extension to the web browser 120.

[0034]

[0044] The signature module 106 can implement one or more digital signature algorithms. Examples of digital signature algorithms that may be implemented by the signature module 106 include, but are not limited to, asymmetric encryption algorithms such as RSA (the signature operation of the Rivest-Shamir-Adleman asymmetric cryptosystem), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital Signature Algorithm). The signature module 106 obtains a private key 110 from the key store 108 to digitally sign input data to generate a cryptographic signature. In some examples, the signature module 106 requests the client device to confirm the user's intent to perform the digital signature.

[0035]

[0045] The encryption module 122 may implement one or more password-based encryption algorithms, such as an implementation of the schemes specified in IETF (Internet Engineering Task Force) RFC (Request for Comments) 8018, "PKCS [Public Key Cryptography Standards] #5: Password-Based Cryptography Specification." Such schemes include, but are not limited to, the key derivation functions PBKDF1 (Password-Based Key Derivation Function 1) and PBKDF2 (Password-Based Key Derivation Function 2) and the encryption schemes PBES1 (Password-Based Encryption Scheme 1) and PBES2 (Password-Based Encryption Scheme 2). Examples of algorithms suitable for the key derivation function PBKDF2 include, but are not limited to, HMAC (Hash-Based Message Authentication Code) with SHA (Secure Hash Algorithm)-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, and SHA-512 / 256. An example of an encryption algorithm suitable for the PBES2 encryption scheme is AES (Advanced Encryption Standard)-CBC (Cipher Block Chaining Mode)-Pad, although other algorithms may also be used.

[0036]

[0046] The key store 108 holds a private key 110 used to perform digital signatures. The private key 110 is one of a pair of keys generated in an asymmetric encryption algorithm, the other key being a public key. In an asymmetric algorithm, the security of the algorithm relies on keeping the private key secret. The private key may be used for operations such as encryption and signing, and the corresponding public key may be used for complementary operations such as decryption and signature verification. The key store 108 may be part of an extension to the web browser 120 or may reside in the memory module 124 or the web browser 120 runtime, for example, as a result of executing Javascript code in the web browser 120. The key store 108 may also be a standalone application. In some examples, the key store 108 is implemented by a blockchain wallet that includes storage of the private key 110. In some examples, the private key 110 is generated using a secret sharing algorithm such as Shamir's secret sharing. In that case, the key store 108 may hold only a portion of the private key 110, with the remaining portion being held on a remote device (not shown).

[0037]

[0047] The remote server 114 hosts a web application 126 that can coordinate non-custodial techniques for encrypting and decrypting data. In some examples, the remote server 114 hosts back-end services for the web application. The remote server also includes an encryption module 128. The encryption module 128 generates and stores a unique secret token for each encryption request from a client device associated with a user. In some examples, the secret token takes the form of binary data. In some examples, the secret token is a text string containing alphabetic or alphanumeric characters. In some examples, the secret token is a randomly generated, cryptographically secure text string. The encryption module 128 also generates a signature request that includes a token message for the user to sign. The signature request or token message may specify a signature algorithm. For example, the encryption module 128 may specify in the signature request that the client device 102 use ECDSA. The signature algorithm may be specified in the signature request so that the same signature algorithm can be used for both encryption and decryption. The remote server 114 stores only the secret token. Neither the signature generated by the client device 102 nor the private key 110 is transmitted to or stored by the remote server 114 .

[0038]

[0048] The storage provider 116 is a server that provides file storage services over the network 112. The storage provider 116 can maintain and store the encrypted data object in a database 130. In some examples, the remote server 114 and the storage provider 116 are located on the same server. In some examples, the storage provider 116 is a cloud storage provider. After the client device 102 encrypts the data object 118 using the techniques described herein, the data object 118 is uploaded to and stored in encrypted form at the storage provider 116.

[0039]

[0049] The exchange platform 132 may be an application ecosystem with one or more applications related to a particular product or service. The one or more applications may collect user data to create or improve the product or service. The exchange platform 132 may be a marketplace platform for data monetization. In some examples, the one or more applications send a request message to the remote server 114 to access particular encrypted data stored at the storage provider 116. In some examples, the exchange platform 132 itself sends a request message to the remote server 114 to access particular encrypted data stored at the storage provider 116.

[0040]

[0050] Referring to Figure 2, Figure 2 illustrates an example system 200 in which a client device 102 encrypts a data object. As described above, the client device 102 receives a web application from a remote server, such as after a user enters the address of a website maintained by the remote server. The web application includes functionality to obtain information for encrypting the data object in a data package and to upload and store the encrypted data package. The web application also allows a user to request a previously encrypted and stored data package and obtain the information necessary to generate a decryption key.

[0041]

[0051] The client device 102 allows the user to select any data package suitable for encryption. A data package may contain one or more data objects stored in a hierarchical file structure. For example, the data object 118 may be from a data package containing multiple data objects, as shown in FIG. 3.

[0042]

[0052] Referring to FIG. 3, FIG. 3 illustrates an exemplary data package 300 containing multiple data objects. In this example, the data package is a zip folder 302. The data package 300 has three hierarchical levels, including a data package level and two data object levels. The zip folder 302 is at the data package level. The zip folder 302 contains folders 304A, 304B, 304C, and html file 304D. The data objects 304A-304D are at the same hierarchical level, i.e., the first data object level. In this example, folder 304A contains text file 306A, folder 304B contains json file 306B, and folder 304C contains json file 306C. As shown in FIG. 3, the data objects 306A-306C are at the same hierarchical level, i.e., the second data object level. Because both files and folders (or paths) can be data objects, it should be understood that, according to examples in accordance with the present disclosure, a single encryption key can be used to encrypt individual files or to encrypt an entire folder (or path) including subfolders (or subpaths). However, top-level folders (or paths) are typically not encrypted as a whole, as such a strategy may not allow for the individual selection and encryption of individual data objects, as discussed in this description.

[0043]

[0053] Data package 300 can be encrypted at a granular level, such as by encrypting individual files or folders independently of other files or folders within the data package. In the illustrated example, data package 300 is not encrypted into a single encrypted data object, but rather each individual data object is encrypted individually as an encrypted data object. Specifically, zip folder 302 is not encrypted as a single encrypted data package; instead, several data objects within zip folder 302 are individually selected for encryption. As shown, data objects 304A-304C are individually selected for encryption, but data object 304D is not selected for encryption. Similarly, data objects 306A-306C can also be individually selected for encryption.

[0044]

[0054] 2, when a user selects a data object 118 to encrypt and store, the client device 102 sends an encryption request to the remote server 114 to obtain a token for generating an encryption key. Upon receiving the request, the remote server 114 generates a signature request 202, receives the encryption request from the client device 102, and sends it to the client device 102. FIG. 4 illustrates an example system 400 for a signature request 202.

[0045]

[0055] 4, the client device 102 receives the signature request 202, and the signature module 106 on the client device 102 processes the signature request 402. The signature request 402 includes a token message 406 generated by the remote server 114. The token message 406 includes a random token 410 that corresponds to the request from the client device 102. The token 410 is unique to each request from the client device 102. In some examples, the token message 406 may include text 412 describing the secret token 410 that can be displayed to a user. In some examples, the text 412 is intended to make the token message 406 easier for a user to understand. Without the text 412, the token message 406 would include only the secret token 410, which may be incomprehensible to some users.

[0046]

[0056] In some examples, the signature request 402 specifies a signature algorithm 404 that the client device 102 uses when signing the private token. For example, the signature request 402 may specify that the client device 102 use ECDSA, allowing the same signature algorithm to be used for both encryption and decryption. The signature request may also (or instead) include a signature method call 408. The signature method call 408 may instruct the signature module 106 to sign some data according to an application programming interface (API) specification. For example, the signature method call 408 may correspond to an API specification published by a blockchain organization, such that the signature method call 408 is available to the client device 102 of the signature module 106 regardless of implementation details. In some examples, the signature method call 408 may specify a signature algorithm. In other examples, the signature method call 408 may implicitly support only one algorithm. For example, the signature method call 408 may be "eth_sign," a signature method that may be implemented on the client device 102. In this example, the API documentation may specify a particular signature algorithm to be used by the implementing client device 102. In some cases, the specified signature algorithm is ECDSA. Other methods may also be used. For example, some implementations may use "eth_signTypedData" from EIP (Ethereum Improvement Proposal)-712, which also implicitly specifies the signature algorithm and hash algorithm used by the client device 102.

[0047]

[0057] Returning to FIG. 2 , when the client device 102 receives the signature request 202, the signature module 106 of the client device 102 begins processing the signature request 202. The signature module 106 may select a signature algorithm 204 specified in the signature algorithm 404 of the signature request 402. In some examples, the signature algorithm 204 is implicitly selected by the signature method call 408 used in the signature request 402. The selected signature algorithm 204 processes the token message 406 with the private key 110 obtained from the key store 108 to generate a cryptographic signature 206. The signature algorithm 204 first computes a cryptographic hash of the token message 406 and then signs the resulting hash. For example, a SHA-3 or Keccak hash algorithm may be used to compute the cryptographic hash of the token message 406, and then an ECDSA asymmetric signature algorithm may be used to sign the resulting hash. The cryptographic signature 206 may be represented as a text string. In some examples, the cryptographic signature 206 is a cryptographic hash value.

[0048]

[0058] The cryptographic signature 206 is then sent to the encryption module 122 of the client device 102. The cryptographic signature 206 is used by a password-based symmetric encryption algorithm 208 to derive a symmetric encryption key 210. Because a symmetric encryption algorithm uses the same key for both encryption and decryption, the security of the symmetric algorithm depends on the security of the key. In this example, the symmetric encryption key 210 is derived from the cryptographic signature 206 received from the signature module 106. In some examples, the password-based symmetric encryption algorithm 208 can use a salt or an iteration number to enhance the security of the generated symmetric encryption key 210. The password-based symmetric encryption algorithm 208 then encrypts the selected data object 118 to generate an encrypted data object 212. The encrypted data object 212 can only be decrypted with the same symmetric encryption key 210 used to create the encrypted data object 212. Therefore, the same password-based symmetric encryption algorithm 208 can be used in the same configuration to ensure that the same symmetric encryption key 210 is generated for both encryption and decryption.

[0049]

[0059] While this example refers to the encryption of a single data object, it should be noted that the data object could also be a folder or a path. Therefore, encrypting a single data object may require encrypting multiple data files within the folder or path using the same encryption key. Alternatively, each data file within the folder or path may be encrypted using a different encryption key generated based on an individual token for each data file being encrypted. In some examples, a user may select multiple data files to be encrypted using the same encryption key. For example, a group of data files may be a group of source code files for a common function (such as corresponding .h and .cxx files) or associated with the same information type. However, as previously mentioned, in some examples, each may be individually encrypted using a different encryption key.

[0050]

[0060] The token 410 in the signature request 202 used to generate the cryptographic signature 206 may be stored in a metadata file. A unique token 410 is provided for each individually selected data object. However, if a user chooses to encrypt multiple data objects together, such as by selecting multiple data files or a folder containing multiple files, a single unique token may be used for all selected data files. Information regarding the signature algorithm 404 used to create the cryptographic signature 206 may also be stored in the metadata file. If multiple data objects from a single data package are encrypted individually, the corresponding unique tokens may be stored in a single metadata file, which may then be encrypted and uploaded to a storage provider.

[0051]

[0061] Referring to FIG. 5, FIG. 5 illustrates an exemplary metadata file 500. The exemplary metadata file 500 includes a name 502 of a data package from which some data objects are selected for encryption. The exemplary metadata file 500 also includes an email address 504 of a user who owns the data package. The exemplary metadata file further includes information related to encrypted data objects 506A-506C. The information related to each encrypted data object includes the name of the data object, the data range of the data object, and a password for encrypting the data object. In some examples, the password is a secret token unique to each encrypted data object.

[0052]

[0062] The example metadata file does not identify the encryption technique used to encrypt each data object, although some examples may include such information. The encryption technique may be identified by an identification number, a software version number (such as the version number of a web application used to encrypt the data object), or other suitable identifying information.

[0053]

[0063] Referring again to FIG. 2, after encrypting the selected data objects and generating the appropriate metadata to include in the metadata file, the client device may ask the user whether they want to select any other data objects in the data package. In that case, the same process may be repeated until the user has selected all the data objects they want to encrypt. The data package with the encrypted data objects and corresponding metadata file can be uploaded to a storage provider for long-term storage. Notably, the encryption key used to encrypt the data objects is not transmitted for storage; it is temporary and not stored anywhere. Instead, as explained above, the information necessary to regenerate the encryption key is held solely by the user, for example, in the user's own cryptocurrency wallet, except for random tokens stored in the metadata file. However, as explained above, these random tokens themselves cannot be used to encrypt the data objects. Thus, the encrypted contents of the data package are secure and cannot be accessed without the user's permission, even if a malicious person gains access to the storage server and obtains the data package and corresponding metadata file. However, this also allows the user to grant third parties access to specific data objects in the data package.

[0054]

[0064] Referring to Figure 6, Figure 6 illustrates an exemplary system 600 in which exchange platform 132 attempts to obtain access to one or more data objects of a user. To do so, exchange platform 132 must request permission from the user, and if permission is granted, it can decrypt the requested encrypted data object 212. To do this in this example, exchange platform 132 sends a request to remote server 114 seeking access to encrypted data object 118 as encrypted data object 212. Figure 7 illustrates an exemplary request sent from exchange platform 132 to remote server 114 to access the data object.

[0055]

[0065] 7, which illustrates an exemplary request 700 sent from exchange platform 132 to remote server 114 to access data object 118. The exemplary request 700 includes a client ID 702 indicating the destination of the request message, a subject 704 indicating the owner of the requested data object, an audience 706 indicating the destination of the request message, an expiration date 708 indicating the duration (in seconds) of the request message, and a scope 710 indicating a description of the requested data object. While the example request 700 includes specific information, the request may include any suitable information, such as proposed payment information, license terms, duration of permitted access, permitted use of the identified information, or other terms or information.

[0056]

[0066] Returning to FIG. 6, upon receiving the request from the exchange platform, the remote server 114 sends a notification message to the client device 102, asking for a response to the request from the client device 102. If the client device approves the request, the remote server 114 causes the storage provider 116 to send the metadata file to the client device 102 and the encrypted data object 212 to the exchange platform 132. The client device 102 decrypts the metadata file using its unique private key and obtains the stored token message 406 corresponding to the encrypted data object 212. The signing module 106 creates a cryptographic signature 206 identical to that shown in FIG. 2 to encrypt the data object 118. The same cryptographic signature 206 is then sent to the exchange platform 132. The decryption module 134 on the exchange platform 132 includes the same password-based symmetric encryption algorithm 208 as the encryption module 122 of the client device 102, as shown in FIG. 2. The password-based symmetric encryption algorithm 208 in the decryption module 134 then uses the same signature 206 to create the same symmetric encryption key 210. The encrypted data object 212 from the storage provider 116 is then decrypted using the same symmetric encryption key 210 that encrypted the original data object 118. The unencrypted data object 118 is then made accessible to the exchange platform.

[0057]

[0067] Referring to FIG. 8, FIG. 8 illustrates an example method 800 for fine-grained encryption using non-custodial techniques. In block 802, the client device 102 receives a selection of data objects 118 to encrypt from a data package via a user interface. The data package may have a hierarchical file structure with multiple hierarchical levels, as shown in FIG. 3. The multiple hierarchical levels consist of a data package level and one or more data object levels. The data package consists of multiple data objects at one or more data object levels. In some examples, a user selects the data objects 118 using a graphical user interface. Alternatively, a web application may automatically select the data objects 118 from the data package.

[0058]

[0068] At block 804, the client device 102 receives a message from the remote server 114. The message is a signature request 202 that includes a secret token 410 associated with the selected data object, as shown in FIG. 4. The signature request 202 also includes information about the signature algorithm. The signature algorithm may be an asymmetric encryption algorithm. In some examples, the client device may send a request to encrypt multiple data objects, and accordingly, the message or signature request 202 may include multiple secret tokens 410 based on the number of data objects to be encrypted. For example, if the client device receives a request to encrypt 10 data objects, the client device may send a request to encrypt 10 data objects. The remote server 114 may generate 10 secret tokens 410 and send a single token message 406 that includes all 10 secret tokens 410.

[0059]

[0069] In block 806, the client device 102 generates an encryption key for the selected data object using the message. The signing module 106 of the client device 102 generates a cryptographic signature 206 using the secret token 410 in the signature request 202 and the user private key 110 using a signature algorithm 204. The signature algorithm may be indicated by the signature algorithm 404 in the signature request 202. The user private key 110 is maintained in the key store 108 of the client device 102. The user private key may be generated using a secret sharing algorithm. The encryption module 122 generates an encryption key 210 using the symmetric encryption algorithm and the cryptographic signature 206. The symmetric encryption algorithm may be a password-based symmetric encryption algorithm 208. The password-based symmetric encryption algorithm 208 may convert the cryptographic signature 206 into an encryption key.

[0060]

[0070] As mentioned above, in some examples, the token message 406 may include multiple secret tokens 410. Accordingly, the client device 102 may generate multiple encryption keys in block 806. Some examples may generate all of the encryption keys at once before beginning encryption of the data object, or may generate the encryption keys sequentially as the corresponding data object is ready to be encrypted.

[0061]

[0071] At block 808, the client device 102 encrypts the selected data object using the encryption key to create an encrypted data object. The encryption module 122 on the client device 102 encrypts the selected data object using the encryption key. The client device 102 can encrypt multiple data objects in a data package individually, sequentially, using multiple encryption keys. The multiple encryption keys can be individually, sequentially generated using multiple token messages in the same manner as described in the paragraph above with respect to block 806. If the data package contains multiple hierarchical levels, the data package is not encrypted at the data package level.

[0062]

[0072] At block 810, the client device 102 stores at least a portion of the message in a metadata file. The at least a portion of the message stored in the metadata file is a secret token 410. In some examples, the client device stores a description and a URL of the encrypted data object in addition to the secret token associated with the encrypted data object. The client device may also store additional information, such as the identified signature algorithm 404 or the identified signature method call 408. Furthermore, some examples may store the entire message, which is the signature request 202. If multiple data objects in the data package are encrypted, the metadata file includes multiple secret tokens 410 associated with the multiple encrypted data objects and the corresponding descriptions and URLs of the encrypted data objects.

[0063]

[0073] At block 812, the client device 102 encrypts the metadata file using the user's encryption key, which may be a user public key paired with a user private key unique to the user associated with the client device 102. This means that only the user who possesses the private key can decrypt the encrypted metadata file.

[0064]

[0074] In block 814, the client device 102 sends the encrypted data object and the encrypted metadata file to the database 130 for storage. The database 130 is in the storage provider 116. Both the encrypted data object and the encrypted metadata file are stored in the storage provider 116. However, the storage provider cannot access the data in the encrypted data object or the encrypted metadata file because the storage provider cannot decrypt the encrypted data object and the encrypted metadata file without the private key held by the user who owns the data object.

[0065]

[0075] The user may select additional data objects to encrypt and upload, and the process is the same as described in Figure 8. This allows the user to individually select multiple data objects to encrypt and upload them in sequence. However, it should be understood that multiple data objects can be automatically encrypted without having to manually select each data object. For example, the user can select a folder with multiple data files in multiple subfolders. The web application then automatically checks all subfolders, requests a token for each file, automatically encrypts each file individually, and automatically creates a metadata file in a manner similar to Figure 8.

[0066]

[0076] Referring to FIG. 9, FIG. 9 illustrates an example method 900 for decrypting a non-custodial encrypted data object. In block 902, the remote server 114 receives a request for a data object from the exchange platform 132 or other third party. The data object is encrypted with an encryption key and stored in the database 130 of the storage provider 116. The exchange platform 132 in this example is an application ecosystem or data marketplace platform, but in other examples, it may be any third party interested in gaining access to the encrypted data object. One or more applications on the exchange platform or the exchange platform itself can send a request for access to a specific data object belonging to a particular user. The request may be a JSON web token. The request includes an identification of the data object. The remote server can identify the owner of the data object. In some examples, the request may include additional information such as the party owning the requested data object, the identity of the party to whom the request message is sent, the expiration date of the request, and the scope of the requested data object. The request may also include other appropriate information, such as proposed payment information, license terms, the duration of permitted access, the proposed use of the requested data, or other terms or information.

[0067]

[0077] In block 904, the remote server 114 sends a notification message to the client device 102 associated with the owner of the data object, soliciting a response from the client device 102 regarding the request. In this example, the notification message is displayed on the client device 102 as a web element, such as a pop-up window or modal. However, in some examples, the message may be sent via other transmission mechanisms, such as a text message, email, or social media message. Such other transmission mechanisms may identify information associated with the request, may include an option to respond directly via the same transmission mechanism, or may include a link to access a web application to approve or deny the request. The notification message may include options the user can select regarding the request, such as "allow" or "deny."

[0068]

[0078] In block 906, the remote server receives a response message approving the request from the client device 102. If the authorized user can select "Allow" in the notification message displayed on the client device 102, a response message approving the request is generated and sent to the remote server.

[0069]

[0079] In block 908, upon receiving the response message, the remote server 114 causes the database 130 to send an encrypted metadata file to the client device 102. The encrypted metadata file consists of a secret token associated with the encrypted data object. The encrypted metadata file is encrypted with the user's public key. Upon receiving the encrypted metadata file from the database 130, the client device 102 decrypts the encrypted metadata file using the user private key paired with the user public key to identify the secret token associated with the requested data object. The client device 102 generates a cryptographic signature using the secret token and the user private key.

[0070]

[0080] In some examples, the client device 102 sends a cryptographic signature to the exchange platform 132. The exchange platform 132 includes a decryption module 134 that employs the same password-based symmetric encryption algorithm 208 as the encryption module 122 of the client device. The decryption module 134 generates a decryption key using the cryptographic signature from the client device. The decryption key is the same as the encryption key used to encrypt the requested data object in the encryption module 122 of the client device 102. In some examples, the client device 102 generates a decryption key using the cryptographic signature using the password-based encryption algorithm and sends the decryption key to the exchange platform 132. The decryption key is the same as the encryption key used to encrypt the requested data object. The exchange platform 132 then decrypts the data object using the decryption key.

[0071]

[0081] In some examples, the client device 102 may send the cryptographic signature to a remote server, which may forward it to the exchange platform. While the exchange platform may be provided with access to the encrypted data object, the transfer may be facilitated in some cases. In some examples, to protect privacy, the exchange platform may provide the client device 102 with a public key, such as in a cryptographically signed message, either directly or via the remote server 114. The client device 102 then uses the cryptographic signature in the message to verify the authenticity of the public key and uses the public key to encrypt the cryptographic signature required to decrypt the data object. The data object can then be sent to the exchange platform, either directly or via the remote server 114. Such a technique allows decryption information to be sent to the exchange platform without disclosing it to another party, such as the remote server 114.

[0072]

[0082] Referring to FIG. 10 , FIG. 10 illustrates an exemplary computing device 1000 suitable for use in an exemplary system or method employing non-custodial techniques for encrypting and decrypting data at a fine-grained level in the present disclosure. The exemplary computing device 1000 includes a processor 1010 that communicates with a memory 1020 and other components of the computing device 1000 using one or more communication buses 1002. The processor 1010 is configured to execute processor-executable instructions stored in the memory 1020 to perform one or more methods employing non-custodial techniques for encrypting data according to various examples, such as some or all of the exemplary methods 800 and 900 described above with respect to FIGS. 8 and 9 . In this example, the computing device 1000 also includes one or more user input devices 1050, such as a keyboard, mouse, touchscreen, microphone, or the like, for accepting user input. The computing device 1000 also includes a display 1040 for providing visual output to the user.

[0073]

[0083] Computing device 1000 may also include one or more audio / visual input devices 1052 to enhance a user's ability to provide input to or receive input from multimedia applications or features, such as video conferencing, entertainment applications, accessibility features, VR headsets, etc.

[0074]

[0084] Computing device 1000 also includes a communications interface 1030. In some examples, communications interface 1030 may enable communications using one or more networks, including a local area network (“LAN”), a wide area network (“WAN”) such as the Internet, a metropolitan area network (“MAN”), point-to-point or peer-to-peer connections, etc. Communications with other devices may be performed using any suitable network protocol. For example, one suitable network protocol may include Internet Protocol (“IP”), Transmission Control Protocol (“TCP”), User Datagram Protocol (“UDP”), or a combination thereof, such as TCP / IP or UDP / IP.

[0075]

[0085] Although some example methods and systems described herein are described in terms of software running on various machines, the methods and systems may also be implemented as hardware, such as a field-programmable gate array (FPGA), specifically configured to perform various methods according to the present disclosure. For example, examples may be implemented in digital electronic circuitry, or computer hardware, firmware, software, or a combination thereof. In one example, a device may include one or more processors. The processor comprises a computer-readable medium, such as a random access memory (RAM), coupled to the processor. The processor executes computer-executable program instructions stored in the memory, such as executing one or more computer programs. Such processors may include microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and state machines. Such processors may also include programmable electronic devices, such as programmable logic devices (PLCs), programmable interrupt controllers (PICs), programmable logic devices (PLDs), programmable read-only memories (PROMs), electronically programmable read-only memories (EPROMs or EEPROMs), or other similar devices.

[0076]

[0086] Such a processor may comprise, for example, one or more non-transitory computer-readable media, or may be in communication with such media, capable of storing processor-executable instructions that, when executed by the processor, cause the processor to perform a method according to the present disclosure executed or assisted by the processor. Examples of non-transitory computer-readable media include, but are not limited to, electronic, optical, magnetic, or other storage devices capable of providing processor-executable instructions to a processor, such as the processor of a web server. Other examples of non-transitory computer-readable media include, but are not limited to, floppy disks, CD-ROMs, magnetic disks, memory chips, ROMs, RAMs, ASICs, configured processors, all optical media, all magnetic tapes or other magnetic media, or other media readable by a computer processor. The described processors and processes may reside in one or more structures and be distributed across one or more structures. A processor may comprise code for executing a method (or portion of a method) according to the present disclosure.

[0077]

[0087] The foregoing description of several examples has been presented for purposes of illustration and description only, and is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Numerous modifications and adaptations will be apparent to those skilled in the art without departing from the spirit and scope of the invention.

[0078]

[0088] Reference herein to an example or embodiment means that a particular feature, structure, operation, or other characteristic described in connection with that example may be included in at least one embodiment of the present disclosure. The present disclosure is not limited to the particular example or implementation so described. The appearance of the phrases "in one example," "in one example," "in one implementation," or "in one implementation," or variations thereof, in various places herein do not necessarily refer to the same example or implementation. A particular feature, structure, operation, or other characteristic described herein in connection with one example or implementation may be combined with other features, structures, operations, or other characteristics described with respect to other examples or implementations.

[0079]

[0089] The use of the word "or" herein is intended to encompass both inclusive and exclusive OR conditions, i.e., A or B or C includes any or all of the following alternative combinations, depending on the particular application: A only, B only, C only, A and B only, A and C only, B and C only, and A, B and C.

Claims

1. receiving, via a user interface, a selection of a data object to encrypt from a plurality of data objects in a data package; receiving a message from a remote server; generating an encryption key for the data object using the message; encrypting the data object with the encryption key to create an encrypted data object; storing at least a portion of the message associated with the encrypted data object in a metadata file; encrypting the metadata file using a user's encryption key to create an encrypted metadata file; transmitting the encrypted data object and the encrypted metadata file to a database for storage; A method for providing

2. the message includes a secret token associated with the data object and information about a signature algorithm, and the at least one portion of the message stored in the metadata file is the secret token associated with the data object; generating an encryption key for the selected data object using the message, generating a cryptographic signature using the private token and a user private key, using the signature algorithm indicated in the message; generating said encryption key using said cryptographic signature via a password-based symmetric encryption algorithm; The method of claim 1 , comprising:

3. The method of claim 2 , wherein the signature algorithm is an asymmetric cryptographic algorithm.

4. The method of claim 2 , wherein the user private key is generated using a secret sharing algorithm.

5. The method of claim 2 , wherein the user's encryption key for encrypting the metadata file is a public key paired with the user's private key.

6. 2. The method of claim 1, wherein the data package has a hierarchical file structure with multiple hierarchical levels, the multiple hierarchical levels including a data package level and one or more data object levels, and the data package includes multiple data objects at the one or more data object levels.

7. 7. The method of claim 6, further comprising the step of individually encrypting the plurality of data objects with a plurality of encryption keys, the plurality of encryption keys being generated using corresponding plurality of tokens received from the remote server, and wherein encryption of the plurality of data objects does not include encryption at the data package level.

8. The method of claim 1 , wherein the metadata file further includes a description of the encrypted data object.

9. The method of claim 1 , wherein the metadata file is a JavaScript Object Notation (JSON) file.

10. receiving a request for a data object from an exchange platform, wherein said data object is stored in a database as an encrypted data object; sending a notification message to the client device requesting a response from the client device regarding the request; receiving a response message from the client device acknowledging the request; upon receiving the response message, causing the database to send an encrypted metadata file to the client device, the encrypted metadata file including a secret token associated with the encrypted data object, the encrypted metadata file being encrypted with a user public key, the client device being configured to decrypt the encrypted metadata file using the user private key paired with the user public key to identify the secret token associated with the encrypted data object, the client device being configured to generate a cryptographic signature using the secret token associated with the encrypted data object and send the cryptographic signature to the exchange platform, the exchange platform being configured to generate a decryption key using the cryptographic signature; A method comprising:

11. 11. The method of claim 10, wherein the exchange platform is configured to generate the decryption key using the cryptographic signature with a password-based symmetric encryption algorithm, the data object is encrypted using an encryption key generated by the password-based symmetric encryption algorithm, and the decryption key and the encryption key are identical.

12. The method of claim 10 , wherein the data object comprises one or more media files.

13. The method of claim 10 , wherein the request is a JSON Web Token.

14. The method of claim 10 , wherein the notification message is displayed as a web element on the client device.

15. a communication interface; a non-transitory computer-readable medium; a processor communicatively coupled to the communications interface and the non-transitory computer-readable medium, the processor configured to execute processor-executable instructions stored on the non-transitory computer-readable medium; receiving, via a user interface, a selection of a data object to encrypt from a data package containing a plurality of data objects; receiving a message from a remote server, the message including a secret token associated with the data object; generating an encryption key for the selected data object using the secret token; encrypting the data object with the encryption key to create an encrypted data object; storing the secret token in a metadata file; encrypting the metadata file using the user's public key to create an encrypted metadata file; a processor that transmits the encrypted data object and the encrypted metadata file to a database for storage; A client device comprising:

16. the processor generates a cryptographic signature using the secret token and a user private key, using a signature algorithm indicated in the message; 16. The client device of claim 15, further configured to execute processor-executable instructions stored on the non-transitory computer-readable medium to generate the encryption key using the cryptographic signature via a password-based symmetric encryption algorithm.

17. 16. The client device of claim 15, wherein the data package has a hierarchical file structure including multiple hierarchical levels, the multiple hierarchical levels including a data package level and one or more data object levels, and the data package includes multiple data objects at the one or more data object levels.

18. 20. The client device of claim 17, wherein the processor is further configured to execute processor-executable instructions stored on the non-transitory computer-readable medium to individually encrypt the plurality of data objects with a plurality of encryption keys, the plurality of encryption keys corresponding to a plurality of secret tokens, and wherein encryption of the plurality of data objects does not include encryption at the data package level.

19. a non-transitory computer-readable medium; a communication interface; a processor, the processor communicatively coupled to the communications interface and the non-transitory computer-readable medium, the processor configured to execute processor-executable instructions stored on the non-transitory computer-readable medium; receiving, from the exchange platform, a request for a data object to be stored in a database as an encrypted data object; sending a notification message to the client device requesting a response from the client device regarding the request; receiving a response message from the client device acknowledging the request; a processor that, upon receiving the response message, causes the database to send an encrypted metadata file to the client device, the encrypted metadata file including a secret token associated with the encrypted data object, the encrypted metadata file being encrypted with a user public key, the client device being configured to decrypt the encrypted metadata file using a user private key paired with the user public key, the client device being configured to generate a decryption key using the secret token associated with the encrypted data object and send the decryption key to the exchange platform, the exchange platform being configured to decrypt the data object using the decryption key; A system comprising:

20. 20. The system of claim 19, wherein the client device is configured to generate the decryption key by generating a cryptographic signature using the secret token and the user's private key, and using the cryptographic signature to generate the decryption key using a password-based symmetric encryption algorithm.

Images