Non-custodial technology for data encryption and decryption

Abstract

[0006] A system and method employing non-custodial techniques for encrypting and decrypting data is provided. An example method includes sending a request for encryption to a first remote server, receiving a first response from the first remote server including a secret token, generating a first cryptographic signature using the secret token, generating a first cryptographic key based on the first cryptographic signature, encrypting one or more files using the first cryptographic key, and transmitting the one or more encrypted files to a second remote server.

Description

[Technical Field]

[0001] This application relates generally to data storage, and more particularly to non-custodial techniques for encrypting and decrypting data. [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 allowing users 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 trust 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 method includes sending an encryption request to a first remote server, receiving a first response from the first remote server including a secret token, generating a first cryptographic signature using the secret token, generating a first cryptographic key based on the first cryptographic signature, encrypting one or more files using the first cryptographic key, and transmitting the one or more encrypted files to a second remote server.

[0004]

[0004] An example system includes a communications interface, a non-transitory computer-readable medium, and one or more processors communicatively coupled to the communications interface and the non-transitory computer-readable medium, the one or more processors configured to execute processor-executable instructions stored on the non-transitory computer-readable medium to send an encryption request to a first remote server, receive a first response from the first remote server including a secret token, generate a first cryptographic signature using the secret token, generate a first cryptographic key based on the first cryptographic signature, encrypt one or more files using the first cryptographic key, and transmit the one or more encrypted files to a second remote server.

[0005]

[0005] An example of a non-transitory computer-readable medium comprises processor-executable instructions configured to cause one or more processors to send an encryption request to a first remote server, receive a first response from the first remote server comprising a secret token, generate a first cryptographic signature using the secret token, generate a first cryptographic key based on the first cryptographic signature, encrypt one or more files using the first cryptographic key, and send the one or more encrypted files to a second remote server.

[0006] These illustrative examples are not set forth to limit or define the scope of the present disclosure, but rather to provide examples to aid in its understanding. Specific examples are set forth and further detailed in the detailed description. Advantages offered by the various examples can be further understood by examining this specification. [Brief explanation of the drawings]

[0007] 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 shows an example of a system that employs non-custodial techniques for encrypting and decrypting data. [Figure 2] 1 illustrates an example system in which a client device receives a message signing request sent from a remote server. [Figure 3] 1 illustrates an example system in which a client device digitally signs a message. [Figure 4] 1 illustrates an example system in which a client device encrypts one or more files. [Figure 5] An example of how non-custodial techniques can be used to encrypt data is shown. [Figure 6] 1 illustrates an example of how non-custodial techniques can be used to decrypt data. [Figure 7] 1 illustrates a signature request being processed on a client device according to an example. [Figure 8] 1 illustrates an example of a system in which private keys are distributed among multiple remote authentication servers. [Figure 9] Here is an example of how to construct a private key: [Figure 10] 1 illustrates an example of a computing device suitable for use in systems and methods that employ non-custodial techniques for encrypting and decrypting data. DETAILED DESCRIPTION OF THE INVENTION

[0008]

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

[0009]

[0019] 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 must be made to achieve the particular goals of the developer, 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.

[0010]

[0020] For a variety of reasons, users may wish to store data with a third-party 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 third party 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 data encryption 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.

[0011]

[0021] One solution to this problem is for users to manually encrypt their data before sending it 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.

[0012]

[0022] Therefore, a technique is needed that allows users to encrypt data before sending it to a storage provider without requiring special knowledge of encryption techniques and without ceding control of the encryption secret to the storage provider. That is, storage providers must provide users with a means to seamlessly encrypt their own data using only secrets that the users possess or can generate before sending it to the storage provider.

[0013]

[0023] To address these issues, in one example system, a user first uses a web application running in a web browser to specify one or more files to be encrypted and stored at a third-party storage provider. The storage provider maintains a web application that includes an "upload" button. When the user clicks the "upload" button, a dialog box appears that allows the user to select one or more files to encrypt and then upload them to the storage provider. This sends an encryption request to the storage provider.

[0014]

[0024] In this example, the storage provider responds by first generating a secret token, which is a randomly generated string (e.g., "abcd1234"). This token is included in a signing request sent to the user's web browser. The signing request instructs the user's browser to cryptographically sign the secret token using a private cryptographic key available only to the user. The user enters a password known only to the user to allow software running in the web browser to cryptographically sign the secret token using their private key. The cryptographic signature is created using an algorithm that produces an output that can only be generated by someone with access to the private key and the randomly generated string. The signature takes the form of a hexadecimal value, for example, 0x1e99398d.

[0015]

[0025] In this example, this signature is converted into a text string and used as input to a symmetric password-based encryption algorithm. This algorithm uses the cryptographic signature to generate a symmetric encryption key. The symmetric encryption key can then be used by a web application running in a web browser to encrypt a user-specified file. At this point, the signature used to generate the symmetric encryption key and the symmetric encryption key itself are removed from memory and never persistently stored anywhere. Thus, the user's data is protected both by the benefit that the user has access only to their private key and by the benefit that the storage provider knows the user's private token. A malicious actor would need both to access the user's encrypted data.

[0016]

[0026] In this example, the encrypted file is sent to the storage provider and stored there. However, the encryption key used to encrypt the file is not provided to the storage provider, so the storage provider cannot access the file even if it has possession of the user's private token. Because only the user possesses the private key and the means to access it, only the user can generate the signature that is used as the basis for generating the symmetric encryption key.

[0017]

[0027] In this example, the reverse process is used to access the file later. In this example, the storage provider's web application contains a button labeled "Download," which the user may click, indicating their intention to download the encrypted data. Clicking the "Download" button sends a request to the storage provider to decrypt the file. The storage provider responds by sending a signature request to the user's browser, again containing the user's secret token, along with the encrypted file. The signature request instructs the web application running in the user's browser to cryptographically sign the secret token again using the user's private key. This signature is used as input to the same password-based encryption algorithm used to generate the symmetric encryption key used to encrypt the file. As before, this algorithm uses the cryptographic signature to generate a symmetric encryption key. Because the same information was used, the same symmetric encryption key used previously to encrypt the file is generated again and can now be used to decrypt the file. Again, the signature and symmetric encryption key themselves are removed from memory and are not persistently stored.

[0018]

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

[0019]

[0029] Referring to Figure 1, Figure 1 illustrates an example of a system 100 that employs non-custodial techniques for data encryption and decryption. The system includes a client device 102, a remote server 114, and a storage provider 116, which are connected via one or more networks, collectively referred to as networks 112.

[0020]

[0030] The client device 102 may be any suitable computing or communications device. For example, the client device 102 may be a conventional computing device, such as a desktop or laptop computer having a processor and computer-readable media, connected to a remote server 114 and a storage provider 116 via the Internet or other suitable computer network 112. Suitable networks 112 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. Alternatively, other types of computing devices, such as tablets or smartphones, may be used.

[0021]

[0031] The client device 102 has access to one or more files 118 containing sensitive data. In some examples, the files 118 are stored on the local storage module 104. However, the files 118 can be stored anywhere that a client application would normally have access to, 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 can also be used. The web browser 120 may include additional applications in the form of browser extensions, plug-ins, or other add-ons. 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.

[0022]

[0032] In some examples, the web browser 120 includes the signing module 106, the key store 108, and the encryption / decryption module 122. These components may be installed as extensions to the web browser 120 or may be present in the browser runtime, for example, via Javascript code downloaded from a web application. In some examples, these components are standalone applications that run outside the web browser 120. In some examples, some or all of these components are implemented by a blockchain wallet. The blockchain wallet itself may be an extension to the web browser 120. A blockchain wallet app may provide implementations of components of the client device 102. The blockchain wallet app may use standard application programming interfaces (APIs), which may include signature methods, digital signature algorithms, symmetric algorithms, asymmetric algorithms, or other components that can be used to implement one or more modules of the client device 102. Alternatively, the modules of the client device 102 may be implemented in the web browser 120 by a remote server 114, for example, using Javascript code. The blockchain wallet may be implemented in a web browser 120 using a web application provided by a remote server 114, for example, using Javascript code.

[0023]

[0033] The signature module 106 implements 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 cryptographic signature algorithms such as RSA (the signing operation of the Rivest-Shamir-Adelman 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 102 to confirm the user's intent to perform the digital signature.

[0024]

[0034] The encryption / decryption module 122 implements one or more password-based encryption algorithms, such as an implementation of the schemes specified in the IETF (Internet Engineering Task Force) Request for Comments (RFC) 8018, "PKCS [Public Key Cryptography Standards] #5: Password-Based Cryptography Specification" publication. 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, SHA (Secure Hash Algorithm)-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, and HMAC8 (Hash-Based Message Authentication Code with SHA-512 / 256). In these examples of Secure Hash Algorithms, the value following the letters SHA represents the size in bits of the cryptographic hash or digest. For example, SHA-512 refers to a 512-bit cryptographic hash. One example of an encryption algorithm suitable for the PBES2 encryption scheme is AES (Advanced Encryption Standard)-CBC (Cipher Block Chaining)-Pad, although other algorithms may also be used.

[0025]

[0035] The key store 108 holds a private key 110 used to perform digital signatures. The private key 110 is either a public key or one of a pair of keys generated to implement an asymmetric encryption algorithm, the other key being a public key. In asymmetric algorithms, 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, while 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 and may reside in the memory module 124 or during the execution of the web browser 120, for example, as a result of Javascript code executing 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).

[0026]

[0036] The remote server 114 hosts an application that orchestrates non-custodial techniques for encrypting and decrypting data. The remote server 114 may host a web application 126. In some examples, the remote server 114 hosts backend services for a mobile application. The remote server also includes an encryption module 128. The encryption module 128 generates a secret token, which may be unique for a particular user, and stores it in a database 130, tied to each client device 102. In some examples, the secret token may take the form of binary data. In some embodiments, the secret token is a text string. The string may be the same for all users, or may be different for all users. In some embodiments, the secret token may be a cryptographically secure, randomly generated text string. The encryption module 128 also generates a signature request, which may specify a signature algorithm. For example, the encryption module 128 may specify that the client device 102 use ECDSA. The same signature algorithm may be specified to be used during both encryption and decryption. In other examples, the signature algorithm may be implicitly included in a method call included in the signature request, as described in more detail below. The remote server 114 stores only the private token. In some examples, neither the signature generated by the client device 102 nor the private key 110 is transmitted to or stored by the remote server 114.

[0027]

[0037] The storage provider 116 is a server that provides file storage services over the network 112. The storage provider 116 holds and stores the encrypted file 118. 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. For example, the remote server 114 may hold a web application that coordinates non-custodial techniques for data encryption and decryption. After the client device 102 encrypts the file 118 using the techniques described herein, the file 118 may be uploaded to and stored in encrypted form on the storage provider 116.

[0028]

[0038] Referring to FIG. 2, FIG. 2 illustrates an example system 200 that receives a message signing request 202 sent from a remote server 114 after a client device 102 sends a request to store an encrypted file 118 to a storage provider 116. The signing request 202 is received by the client device 102 and processed by the signing module 106. The signing request 202 includes a message 206 generated by the remote server 114, which includes a secret token 210 corresponding to the client device 102. The message 206 may include text 212 that includes the secret token 210. The secret token 210 may be unique for each client device 102. The text 212 may be the same for each client device. In some examples, the text 212 is intended to allow a user to easily understand the message. Without the text 212, the message 206 would include only the secret token 210, which may be incomprehensible to some users. In some examples, the signing request 202 specifies a signature algorithm 204 that the client device 102 should use to sign the secret token. For example, the signature request 202 may specify that the client device 102 use ECDSA. The same signature algorithm may be specified for both encryption and decryption. The signature request may also (or instead) include a signature method call 208. The signature method call 208 instructs the signature module 106 to sign some data according to an API specification. For example, the signature method call 208 may correspond to an API specification published by a blockchain organization so that the signature method call 208 can be used by the client device 102 of the signature module 106 regardless of implementation details. In some examples, the signature method call 208 may specify a signature algorithm. In other examples, the signature method call 208 may implicitly support only one algorithm. For example, the signature method call 208 may be "eth_sign," a signature method that can be implemented by 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 be used. For example, some implementations may use "eth_signTypedData" from EIP (Ethereum Improvement Proposal)-712, which also implicitly specifies the signature and hash algorithms used by the client device 102.

[0029]

[0039] FIG. 3 illustrates an example system 300 in which a client device 102 digitally signs a message 206. The message 206 is processed by a signature module 106. The signature module 106 may select a signature algorithm 302 based on the algorithm 204 specified in the signature request 202. In some examples, the signature algorithm 204 is implicitly selected by the signature method call 208 used in the signature request 202. The selected signature algorithm 302 processes the message 206 with a private key 110 obtained from the key store 108 to generate a signature 304. A signature algorithm 320 first computes a cryptographic hash of the message 206 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 message 206, and then an ECDSA asymmetric signature algorithm may be used to sign the resulting hash. The signature 304 may be represented as a text string. In some examples, the signature 304 may be a cryptographic hash value.

[0030]

[0040] FIG. 4 illustrates an example system 400 in which a client device 102 encrypts one or more files 118. In FIG. 4, the encryption / decryption module 122 receives a signature 304 from the signature module 106. The signature 304 is used by a symmetric password-based encryption algorithm 402 to derive a symmetric encryption key 404. A symmetric encryption algorithm is one in which the same key is used for both encryption and decryption. The security of the symmetric algorithm relies entirely on the security of the key. In this example, the symmetric encryption key 404 is derived from the signature 304 received from the signature module 106. During decryption, the same signature 304 is received from the signature module 106 and used to generate the same symmetric encryption key 404. In some examples, the symmetric password-based encryption algorithm 402 employs a salt or an iteration count to enhance the security of the generated symmetric encryption key 404. The symmetric password-based encryption algorithm 402 then receives one or more files 118 as input, encrypts the files 118, and generates one or more encrypted files 406. An encrypted file 406 can only be decrypted with the same symmetric encryption key 404 that was used to encrypt it. Therefore, the same symmetric password-based encryption algorithm 402 must be used in the same configuration to ensure that the same generated symmetric encryption key 404 is used both when encrypting and when decrypting.

[0031]

[0041] In the decryption process, the encryption / decryption module 122 receives the signature 304 from the signature module 106. The signature 304 is used by a symmetric password-based encryption algorithm 402 to derive a symmetric encryption key 404. The symmetric password-based encryption algorithm 402 then receives one or more encrypted files 406 as input and decrypts the encrypted files 406 to generate one or more decrypted files 118.

[0032]

[0042] FIGS. 5-6 and 9 illustrate example methods employing non-custodial techniques for data encryption. These methods may be implemented by the client device 102 of the system 100 or any other system. These methods may be read with reference to the systems of FIGS. 1-4 or 7-8 for illustrative purposes. It should be understood that these example methods provide specific methods for employing non-custodial techniques for data encryption. Other sequences of operations may be performed according to alternative examples. For example, alternative examples of the present invention may perform the steps outlined above in a different order. Furthermore, individual operations illustrated by these methods may include multiple sub-operations that may be performed in various sequences depending on the individual operation. Furthermore, additional operations may be added or removed depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0033]

[0043] Referring to FIG. 5 , the method 500 includes, at step 502, the client device 102 sending an encryption request to the remote server 114. As described above, the client device 102 may include a web browser 120 extension. The extension may be a blockchain wallet. In another example, the client device 102 may execute a web application in the web browser 120 that includes Javascript code sent from the remote server 114. The encryption request may specify one or more files 118 to be encrypted. In some examples, the encryption request may include details about the client device 102, such as the type and version of the web browser 120 extension. The encryption request may specify API methods supported by the client device 102.

[0034]

[0044] In step 504, the client device 102 receives a response from the remote server 114 that includes the secret token 210. In some examples, the response includes a message signing request 202. The signing request 202 may include a method call 208 that corresponds to a standard API that specifies the encryption algorithm to use. The signing request 202 may include a message 206 that includes the secret token 210. In addition to the secret token 210, the message may include other text 212. The other text 212 may warn the user of the client device 102 to protect the security of the secret token 210.

[0035]

[0045] In step 506, the client device 102 generates a cryptographic signature 304 of the message 206, including the secret token 210. The signature 304 may be generated using a private key 110 stored on the client device 102 and is accessible only to the client device 102. The cryptographic algorithm 302 used may correspond to the method call 208 included in the signature request 202, according to a standard API specification.

[0036]

[0046] In step 508, the client device 102 uses the cryptographic signature 304 to generate an encryption key 404. As described above, the encryption key 404 may be generated by a symmetric password-based encryption algorithm.

[0037]

[0047] In step 510, the client device 102 encrypts one or more files 118 using the generated encryption key 404. As described above, the encryption key 404 may be a symmetric key generated using a symmetric password-based encryption algorithm. Once the file 118 is encrypted, both the cryptographic signature 304 and the encryption key 404 may be removed from volatile memory and not persistently stored.

[0038]

[0048] In step 512, the client device 102 sends one or more encrypted files 118 to a second remote server 116. The second remote server 116 may be a storage provider or may be the same as the remote server 114. The files 118 may be stored on the second remote server 116 until needed by some application or until the client device 102 requests a decryption operation.

[0039]

[0049] If a file 118 is required by an application, the client device 102 may need to decrypt the file 118 before providing it to the application. For example, the application may be a third-party monetization provider. A user of the client device 102 may specify a file 118 stored on a second remote server 116 for use by the third-party monetization provider. However, before sending the file 118 to the third-party monetization provider, the client device 102 may first decrypt the file, for example, using the example method 600 below. In some examples, the remote server 114 may facilitate sharing of data with the third-party monetization provider.

[0040]

[0050] FIG. 6 illustrates an example method 600 employing a non-custodial technique for data decryption. Method 600 is generally the reverse of the process described in method 500 above. In step 602, the client device 102 sends a decryption request to a remote server. In step 604, the client device 102 receives a response from the remote server including a secret token 210. In some examples, the response may include a signature request 202. In step 606, the client device 102 further receives one or more encrypted files 118 from the remote server 114. In step 608, the client device 102 generates a cryptographic signature 304 using the secret token 210. In step 610, the client device 102 generates an encryption key 404 based on the cryptographic signature 304. In step 612, the client device 102 decrypts the one or more encrypted files 118 using the encryption key 404. The same symmetric encryption key 404 may be used for both encryption and decryption operations. Again, it may happen that both the cryptographic signature 304 and the cryptographic key 404 are removed from volatile memory and are not stored persistently.

[0041]

[0051] Referring now to FIG. 7, FIG. 7 illustrates a signature request 700 being processed on a client device 102 according to an example. In this example, the signature request 700 is processed by a blockchain wallet app 716 running on the client device. As described above, components of the client device components may be implemented by the blockchain wallet app 716. The blockchain wallet app 716 may be an extension to the web browser 120. The blockchain wallet app 716 may be used to implement one or more modules of the client device 102. For example, the blockchain wallet app 716 may be used to implement the signature module 106, the key store 107, or the encryption / decryption module 122. The blockchain wallet app 716 may use a standard API, including a signature method 207, that can be used to implement one or more modules of the client device. Alternatively, the modules of the client device may be implemented in the web browser 120 by a remote server 114, for example, using Javascript code. A balance 702 for a blockchain account 714 is an example of typical details that may be displayed in a signature request 700 running on a blockchain wallet app 716. The origin of the signature request 712 corresponds to a remote server 114 of the system 100. The signature request 700 may include a message 704 that includes a secret token 710. The message 704 is included to allow a user to understand the text to be signed. The blockchain wallet app 716 may include a sign button 706 to perform the cryptographic signature and a cancel button 708 to stop the transaction.

[0042]

[0052] Referring now to FIG. 8, FIG. 8 illustrates an example system 800 in which a private key 802 is split and distributed among multiple remote authentication servers according to a secret sharing algorithm, such as Shamir's secret sharing scheme. The security of the split private key 802 is enhanced because multiple conditions must be met before a usable private key 802 can be assembled. For example, in some examples, the locally stored private key 110 may be accessible using only a password. For the split private key 802, both a password and remote login may be required. In this example, a first portion of the split key 802 is stored locally, and a second portion of the split key 802 is stored on a remote server. Once both conditions are met, the private key 802 can be assembled according to a secret sharing algorithm. The split key 802 functions as the private key 110 as usual. Any number of additional conditions may be added to enhance the security of the split private key 802. For example, a third condition may be a requirement for a hardware authentication device. In some examples, the minimum number of key portions or shares required to have a viable split private key 802 is referred to as a threshold.

[0043]

[0053] In some examples, the client device 102 includes a first portion 816 of the private key 802. The remote authentication server 810 includes a second portion 818 of the private key 802. This second portion 818 is protected by an authentication scheme provided by the remote authentication server 810. For example, a user may be required to log in to the remote authentication server 810 using a social login or other single sign-on (SSO) authentication scheme. Alternatively, the remote authentication server 810 may use a "password-less" login scheme. In some examples, a third portion 820 may be included in the recovery client device 806 to recover the key if the login credentials for the remote authentication server 810 are lost. The third portion 820 may be protected by a requirement to answer one or more security questions. In some examples, the second portion 818 of the private key may be further divided and distributed among nodes in the distributed key management network 814.

[0044]

[0054] 9 shows an example of a method 900 for assembling a split private key 802. In step 902, the client device 102 identifies a first portion 816 of the private key 802. For example, the first portion 816 may be stored locally on the client device 102. A password may be required to access the first portion 816.

[0045]

[0055] In step 904, one or more second portions 818 of the partitioned private key 802 are distributed to one or more remote authentication servers 810. As part of the initialization of the secret sharing algorithm, the private key 802 must be generated and partitioned. After the partitioning, the partitions must be reconfigured to obtain a usable key. For increased security, one or more portions may be distributed to different locations, requiring high requirements to obtain all portions. In some examples, the second portion 818 is stored on a different server. The server may be controlled by a third party with standalone authentication requirements. The remote authentication server 810 may store the second portion 818 in any suitable manner. For example, the second portion may be stored on a cloud storage provider controlled by the remote authentication server 810.

[0046]

[0056] In step 906, the client device 102 authenticates to one or more remote authentication servers 810. The authentication process of the remote authentication server 810 may use a different authentication method than the method that protects the first portion 816. For example, the first portion 816 may be protected by a password, and the second portion 818 may be protected by a social login.

[0047]

[0057] In step 908, after authentication, the client device 102 receives one or more second portions 818 of the split private key 802 from the remote authentication server 810. The remote authentication server 810 may obtain the second portions 818 from the distributed network 814 or store them in any other suitable manner.

[0048]

[0058] In step 910, client device 102 assembles first portion 816 and one or more second portions 818 to obtain private key 802. First portion 816 and one or more second portions 818 are reconstructed according to a secret sharing algorithm. Reconstructed split key 802 can be used in a manner similar to private key 110, for example, for use in signature algorithm 302.

[0049]

[0059] Referring now 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 data encryption and decryption 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 data encryption and decryption according to various examples, such as some or all of the example methods 500, 600, and 900 described above with respect to FIGS. 1-4 and 7. In this example, the computing device 1000 also includes one or more user input devices 1050, such as a keyboard, mouse, touchscreen, or microphone, for accepting user input. The computing device 1000 also includes a display 1040 for providing visual output to the user.

[0050]

[0060] The computing device 1000 may also include one or more audio / visual input devices 1052 to enhance the 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.

[0051]

[0061] Computing device 1000 also includes a communication interface 1040. In some examples, communication interface 1030 may enable communication 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. Communication 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.

[0052]

[0062] Although some examples of methods and systems 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), specially 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, including 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), and other similar devices.

[0053]

[0063] Such a processor may comprise or be in communication with media, such as one or more non-transitory computer-readable media, that may store 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 that can provide 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 that can be read by a computer processor. The described processors and processes may reside in one or more structures or 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.

[0054]

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

[0055]

[0065] Reference to an example or implementation herein means that a particular feature, structure, operation, or other characteristic described in connection with the example may be included in at least one implementation 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.

[0056]

[0066] 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, A, B and C.

Claims

1. sending a request for encryption to a first remote server; receiving a first response from the first remote server, the first response including a secret token; generating a first cryptographic signature using the secret token; generating a first cryptographic key based on the first cryptographic signature; encrypting one or more files using the first encryption key; deleting the first cryptographic signature and the first cryptographic key; transmitting the one or more encrypted files to a second remote server; A method for providing the above.

2. The method of claim 1 , wherein the second remote server is a cloud storage provider.

3. 10. The method of claim 1, further comprising identifying a private key, wherein the first cryptographic signature is generated using an asymmetric cryptographic algorithm and the private key.

4. the private key is generated using a secret sharing algorithm; identifying a first portion of the private key; distributing one or more second portions of the private key to one or more remote authentication servers; authenticating to the one or more remote authentication servers; receiving the one or more second parts of the private key from the one or more remote authentication servers; assembling the private key from the first portion and the one or more second portions; The method of claim 3 further comprising:

5. The method of claim 1 , wherein the first cryptographic key derived from the first cryptographic signature is generated using a symmetric password-based encryption algorithm.

6. sending a file decryption request to the first remote server; receiving a second response from the first remote server, the second response including the secret token; receiving the one or more encrypted files from the second remote server; generating a second cryptographic signature using the secret token, the second cryptographic signature being identical to the first cryptographic signature; generating a second cryptographic key based on the second cryptographic signature; decrypting the one or more encrypted files using the second encryption key; deleting the second cryptographic signature and the second cryptographic key; The method of claim 1 further comprising:

7. a communication interface; a non-transitory computer-readable medium; one or more processors communicatively coupled to the communications interface and the non-transitory computer-readable medium, the one or more processors executing processor-executable instructions stored on the non-transitory computer-readable medium; Sending an encryption request to a first remote server; receiving a first response from the first remote server, the first response including a secret token; generating a first cryptographic signature using the secret token; generating a first cryptographic key based on the first cryptographic signature; encrypting one or more files using the first encryption key; Deleting the first cryptographic signature and the first cryptographic key; one or more processors configured to transmit the one or more encrypted files to a second remote server. A system comprising:

8. The system of claim 7 , wherein the second remote server is a cloud storage provider.

9. The system of claim 7 , wherein the secret token is a randomly generated string.

10. 10. The system of claim 9, further comprising the step of identifying a private key, wherein the first cryptographic signature is generated using an asymmetric cryptographic algorithm and the private key.

11. the private key is generated using a secret sharing algorithm; identifying a first portion of the private key; distributing one or more second portions of the private key to the one or more remote authentication servers; authenticating to the one or more remote authentication servers; receiving the one or more second parts of the private key from the one or more remote authentication servers; assembling the private key from the first portion and the one or more second portions; The system of claim 10 further comprising:

12. 10. The system of claim 9, wherein the first cryptographic key derived from the first cryptographic signature is generated using a symmetric password-based encryption algorithm.

13. sending a file decryption request to the first remote server; receiving a second response from the first remote server, the second response including the secret token; receiving the one or more encrypted files from the second remote server; generating a second cryptographic signature using the secret token, the second cryptographic signature being identical to the first cryptographic signature; generating a second cryptographic key based on the second cryptographic signature; decrypting the one or more encrypted files using the second encryption key; deleting the second cryptographic signature and the second cryptographic key; The system of claim 7 further comprising:

14. A non-transitory computer-readable medium comprising processor-executable instructions, the processor-executable instructions configured to: causing a first remote server to send a request for encryption; receiving a first response from the first remote server, the first response including a secret token; generating a first cryptographic signature using the secret token; generating a first cryptographic key based on the first cryptographic signature; encrypting one or more files using the first encryption key; causing the first cryptographic signature and the first cryptographic key to be deleted; A non-transitory computer-readable medium configured to cause the one or more encrypted files to be transmitted to a second remote server.

15. The non-transitory computer-readable medium of claim 14 , wherein the second remote server is a cloud storage provider.

16. The non-transitory computer-readable medium of claim 14 , wherein the secret token is a randomly generated string.

17. 17. The non-transitory computer-readable medium of claim 16, further configured to identify a private key, wherein the first cryptographic signature is generated using an asymmetric cryptographic algorithm and the private key.

18. Identifying a first portion of the private key; Distributing one or more second portions of the private key to one or more remote authentication servers; authenticating to the one or more remote authentication servers; receiving the one or more second parts of the private key from the one or more remote authentication servers; 20. The non-transitory computer-readable medium of claim 17, further configured to assemble the private key from the first portion and the one or more second portions.

19. 17. The non-transitory computer-readable medium of claim 16, wherein the first cryptographic key derived from the first cryptographic signature is generated using a symmetric password-based encryption algorithm.

20. The non-transitory computer-readable medium comprises: Sending a file decryption request to the first remote server; receiving a second response from the first remote server, the second response including the secret token; receiving the one or more encrypted files from the second remote server; further configured to generate a second cryptographic signature using the secret token; the second cryptographic signature is identical to the first cryptographic signature; The non-transitory computer-readable medium generates a second cryptographic key based on the second cryptographic signature; decrypting the one or more encrypted files using the second encryption key; 15. The non-transitory computer-readable medium of claim 14, further configured to delete the second cryptographic signature and the second cryptographic key.

Images