Systems and methods for resilient multiparty cryptography

Abstract

Systems and methods for multiparty cryptography that is resilient and gives end-users custodianship of their own cryptographic keys are provided. A method includes a trusted third party that combines secret shares received from user devices to recover a secret that is then used to perform a cryptographic operation. Another method includes using single-use public and private keys that are sent from user devices to a software which performs a cryptographic operation. A further method includes generating values that are a function of user device's secret shares, inputting the values to a DPRF function to derive a DPRF value that is used to perform a cryptographic operation. The methods further provide for key rotation for added security and key recovery in case of lost or corrupted keys or secret shares.

Description

SYSTEMS AND METHODS FOR RESILIENT MULTIPARTY CRYPTOGRAPHYTechnical Field

[0001] The following relates generally to cryptography, and more particularly to systems and methods for threshold cryptography in the context of custodianship, governance, systems resilience, and data protection.Introduction

[0002] The problem of key management exists in key -based cryptographic systems and methods. Key-based cryptographic operations depend on the protection of a key that must not be compromised. The compromise of one such key often results in a complete collapse of the system in its entirety, and can often have disastrous consequences, including data leaks, impersonations of legitimate actors by nefarious parties, reputational damage and loss of trust in the system.

[0003] Furthermore, should the key be lost, all data and operations protected by this key are often permanently destroyed. From this arises the problem of recovery: a resilient system should provide a way to resume the normal flow of operations if a key becomes unavailable.

[0004] Finally, there is the problem of custodianship: end-users often lack the proper expertise to secure their own keys. For numerous reasons, including ease of use and risk mitigation, they often defer to “trusted” third parties to handle their keys in their name. In doing so, they give up control over their own data and operations, deferring to various businesses to handle their data safely. Being completely removed from the process, they have neither insight on the internal handling of their own operations, nor any capability to react or contribute to its safekeeping. The burden of security and responsible handling of operations and data lies solely on the third party's shoulders. From the end user's perspective, this results in a need to have absolute trust in various third parties.

[0005] From the trusted third party's perspective, such a centralised approaches makes them a natural target for nefarious actors, as a single breach can have large-scale impact. While often better equipped than end users to face online threats, trusted third parties end up being the sole bearers of the responsibility of the safety of operations and data, often increasing the cost of failure to uphold such security.

[0006] To address such risks, numerous solutions have been brought forward. One such solution is to leverage hardware to secure the key. This hardware is generally referred to as Restricted Operating Environment (ROE). Two among the most prominent such technologies today are Hardware Security Modules (HSM), a well-defended digital environment where operations are restricted and closely monitored, and Trusted Platform Modules (TPM), a more affordable, though less secure, variation of the same principle. While hardware-based solutions partially alleviate the risk, they fall short of a complete answer to the problem, since they constitute a single point of failure. They limit the risks of key leakage, but once a key has been leaked, there is no second line of defense, and the problem remains whole.

[0007] The notion of splitting a key among various actors has been introduced in 1979 in Adi Shamir’s article How to Share a Secret (Shamir, A., Communications of the ACM, 1979, vol. 22, is. 11, pp. 612-613). The article introduces the notion of a secret embedded in a polynomial of degree k-1, where k is the number of participants required to recover a secret. In the key splitting scheme, the degree k-1 polynomial is evaluated at n points, and each evaluation is given to a different participant, a subset of whom can then jointly recover the secret with Lagrange interpolation. Using this scheme, a group of participants can share a secret among themselves, such that a subset of them, the size being chosen upon instantiation, can recover the secret by collaborating. This paradigm first addresses the problem of a single point of failure and can be is resilient to the loss of a single key.

[0008] Programmatic solutions have also been provided to emulate threshold cryptography. In this setting, an operation starts with the identification of valid individuals, all of whom hold a key, and the identification of a threshold. Later, a software is responsible for verifying the presence of a sufficient quantity of keys to perform a given operation. This design is prominently featured in the Bitcoin multi-signature (multisig) ecosystem, where the bitcoin scripting language is responsible for the validation of the provided keys. Note that this solution provides no mathematical guarantee that the threshold will be respected; the security of the scheme relies on the software alone.

[0009] While the above-described solutions address the problem in their own specific way, each falls short of addressing the combined issues of compromise resistance, resiliency, recovery, and custodianship. Accordingly, there is a need for an improved threshold cryptography systems and methods that overcomes at least some of the disadvantages of existing systems and methods.Summary

[0010] Systems and methods for multiparty cryptography that is resilient and gives end-users custodianship of their own cryptographic keys is described. The systems and methods described herein provide for key rotation for additional security and key recovery in case one or more parties lose their keys or if the key is compromised. The systems and methods herein can be utilized for digital identity, digital authentication, digital authorization and consent, digital signatures, and digital protection of data at rest, among other applications.

[0011] According to an embodiment, there is a system for multiparty crytopgraphic operations comprising a trusted party device, one or more user devices and at least one recovery device. The system implements a method for multiparty cryptographic comprising: splitting a secret into a first plurality of secret shares; dividing the first plurality of secret shares between the devices, each device receiving one secret share; sending a secret share from each user device to the trusted party device; combining the secret shares received from the one or more user devices with a secret share retained by the trusted party device to recover the secret; performing a cryptographic operation using the secret; and discarding, the secret and all secret shares received from the one or more user devices.

[0012] If a secret share is lost or corrupted, the method further comprises sending a secret share from each user device still having a secret share, to the trusted party device; sending a secret share from at least one recovery device to the trusted party device; combining the secret share from the at least one recovery device with the secret share received from each user device still having a secret share and the secret share retained by the trusted party device, to recover the secret; regenerating the at least one secret share lost by the at least one user device; and sending at least one regenerated secret share to at least one user device.

[0013] The method may further provide for key rotation comprising the steps of: sending the secret share from each user device to the trusted party device; combining the secret shares received from the user devices with the secret share retained by the trusted party device, to recover the secret; using the secret to generate a second plurality of secret shares; dividing the second plurality of secret shares between the trusted party device, the one or more user devices and the at least one recovery device, each device receiving one secret share from the second plurality of secret shares; discarding, the secret share from the first plurality of secret shares; and discarding, by the trusted party device, the secret and all secret shares received from the one or more user devices.

[0014] According to another embodiment, there is a system for multiparty cryptographic operations using single use public and private keys comprising at least two user devices and at least one recovery device. The system implements a method for multiparty encryption operations comprising generating a public key and a private key by each of at least two user devices and at least one recovery device; sending the public key and an indication of expected devices for decryption from each of the devices to a software; and performing a cryptographic operation to encrypt data by the software.

[0015] For decryption operations, the method further comprises: regenerating the public key and the private key by each of the user devices; sending a proof of the private key from each of the user devices to the software; and performing a cryptographic operation to decrypt the data by the software when the proof of the private key is received from the expected devices for decryption.

[0016] If a secret share is lost or corrupted, the method further comprises regenerating the public key and the private key used in a previous encryption operation by each of the user devices apart from the first user device; regenerating the public key and the private key used in a previous encryption operation by a recovery device; sending the proof of the private key by the recovery device and each of the user devices apart from the first user device to the software; and performing the cryptographic operation to decrypt the data by the software when the proof of the private key is received from the expected devices for decryption.

[0017] According to another embodiment, there is a system for multiparty cryptographic operations using a cryptographic solution comprising at least two user devices and at least one recovery device. The system implements a method for multiparty encryption operations comprising: generating and splitting, a first random partial secret into a number of partial secret shares equal to the number of user devices and recovery devices in the system. A device performing a cryptographic operation adds partial secret shares received from every device in the system to form a final secret share and performs an encryption operation on a dummy value to ensure an expected result. The device generates a first value that is a function of the final secret share and sends the first value to every device in the system. The device receives a second value from each user device in the system, the second values being a function of a final secret share of each user device. The first value and the second values are input to a distributed pseudo-random function (DPRF) to derive a first DPRF value and the first DPRF value is used to perform an encryption operation on data.

[0018] If a partial secret share is lost or corrupted a non-commutative or a commutative method for recovery is performed. The non-commutative recovery method comprises receiving a third value being a function of a final secret share of at least one recovery device, inputting the first value, the second values and the third value to a DPRF to derive a recovery value and using the recovery value to perform a recovery operation.

[0019] Other aspects and features will become apparent, to those ordinarily skilled in the art, upon review of the following description of some exemplary embodiments.Brief Description of the Drawings

[0020] The drawings included herewith are for illustrating various examples of systems, methods, and apparatuses of the present specification. In the drawings:

[0021] FIGS. 1 A is a flow chart of a trusted party cryptographic method, according to an embodiment;

[0022] FIG. IB is a flow chart of a key recovery operation;

[0023] FIG. 1C is a flow chart of a key rotation operation;

[0024] FIG. ID is a diagram of a system for implementing the method of FIG. 1A, shown during a setup phase, according to an embodiment;

[0025] FIG. IE is a diagram of the system of FIG. ID, shown during a cryptographic operation;

[0026] FIG. IF is a diagram of the system of FIG. ID, shown during a key recovery operation;

[0027] FIG. 1G is a diagram of the system of FIG. ID, shown during a key rotation operation;

[0028] FIGS. 2 A is a flow chart of a single-use key cryptographic method, according to an embodiment;

[0029] FIG. 2B is a flow chart of a key recovery operation;

[0030] FIG. 2C is a diagram of a system for implementing the method of FIG. 2A, shown during an encryption operation, according to an embodiment;

[0031] FIG. 2D is a diagram of the system of FIG. 2C shown during a decryption operation;

[0032] FIG. 2E is a diagram of the system of FIG. 2C shown during a key recovery operation;

[0033] FIG. 3A is a flow chart of a cryptographic solution method, according to an embodiment;

[0034] FIG. 3B is a flow chart of a non-commutative key recovery operation;

[0035] FIG. 3C is a flow chart of a commutative key recovery operation;

[0036] FIG. 3D is a diagram of a system for implementing the method of FIG. 3A, shown during a setup phase, according to an embodiment;

[0037] FIG. 3E is a diagram of the system of FIG. 3D, shown during a cryptographic operation;

[0038] FIG. 3F is a diagram of the system of FIG. 3D, shown during a non- commutative key recovery operation; and

[0039] FIG. 3G is a diagram of the system of FIG. 3D, shown during a commutative key recovery operation.Detailed Description

[0040] Various systems or processes will be described below to provide an example of each claimed embodiment. No embodiment described below limits any claimed embodiment and any claimed embodiment may cover processes or systems that differ from those described below. The claimed embodiments are not limited to systems or processes having all of the features of any one system or process described below or to features common to multiple or all of the systems described below.

[0041] One or more systems described herein may be implemented in computer programs executing on programmable computers, each comprising at least one processor, a data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. For example, and without limitation, the programmable computer may be a programmable logic unit, a mainframe computer, server, and personal computer, cloud-based program or system, laptop, personal data assistance, cellular telephone, smartphone, or tablet device.

[0042] Each program is preferably implemented in a high-level procedural or object- oriented programming and / or scripting language to communicate with a computer system.However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each such computer program is preferably stored on a storage media or a device readable by a general or special purpose programmable computer for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein.

[0043] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

[0044] Further, although process steps, method steps, algorithms or the like may be described (in the disclosure and / or in the claims) in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order that is practical. Further, some steps may be performed simultaneously.

[0045] When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article may be used in place of the more than one device or article.

[0046] Reference herein to “party,” “parties” or “participant(s)” means an individual / device / system that holds cryptographic information and can mathematically contribute to an encryption or decryption operation. Such a device or system is a computer (e.g., a server, laptop, tablet, smartphone) or hardware (e.g., ROE, HSM or TPM) configured specifically for performing cryptographic operations.

[0047] In the systems and methods described herein, an end-user enters a partnership with one or more parties, and secret cryptographic keys are split between all parties involved. Those partial keys are referred to herein as “normal” key shares and the parties holding them are termed “normal” parties. The total number of normal parties is referred to herein as the “threshold.” In the drawings, normal parties are labelled “N.” When a normal key operation is required, all normal parties holding a normal key share collaborate to reconstruct the secret key, which can then be used to perform the operation.

[0048] One or more of the parties are designated as the holders of dedicated “recovery” key shares and the parties holding them are termed “recovery” parties. In the drawings, recovery parties are labelled “R.” Recovery keys are not involved in normal operations, but act as backups in case of loss of a normal key. In the event that a party loses their normal key share, the recovery key shares are used instead of some of the normal key shares to perform an operation of recovery. The recovery operation allows the construction of a new set of normal key shares and recovery key shares without interruption of operations or loss of data.

[0049] The system provides for the delegation of a given key share (normal or recovery) among a new group of parties, a threshold of whom will be required to recover the key share. Similarly, the systems and methods herein provide for key rotation that enables all parties to maintain operations while modifying their key shares. Such a key modifying operation provides protection in case a party has been compromised unknowingly.

[0050] Additional hardware-based cryptography components (e.g., ROE, HSM and TPM) can be used in combination with the systems and methods described herein to further augment the overall security of the system.

[0051] Features of three exemplary cryptographic methods 100, 200, 300, according to various embodiments, are summarized in Table 1. In a trusted party method 100, a single party that is trusted by all gathers all secret shares, and performs the cryptographic operations for the group; in a single-use key method 200, no party is trusted by all, and keys are only ever used once; and in a cryptographic solution method 300, no party is trusted by all, and keys are reused, which calls for advanced cryptographic mechanisms to ensure the safety of the operations.

[0052] Table 1. Features of Exemplary Embodiments.

[0053] Each method 100, 200, 300 can be divided into phases, each phase involving a specific number of parties: 1. setup; 2. normal cryptographic operation; 3. recovery; 4. key rotation; and 5. Delegation.

[0054] During the setup phase an end user enters an agreement with one or more parties, jointly referred to as normal parties. Together, the normal parties identify one or more recovery parties to act as custodians of recovery key shares. Recovery parties can either be independent third parties (i.e., not a normal party), normal parties, or be an independent system managed by one of the normal parties.

[0055] During the normal cryptographic operation phase one of the normal parties contacts all other normal parties and asks them to collaborate to perform a cryptographic operation. The cryptographic operation is one of a range of cryptographic functions, including, but not limited to, encryption, signature, key derivation, establishment of identity, authorization, and authentication. All parties will confirm that the request is legitimate according to their own decision-making process, and if they agree to help, they will contribute to the operation. As described below, the way this operation is performed depends on the chosen method - in methods 100 and 300 only normal parties are involved in cryptographic operations; in method 200 all parties (normal and recovery) are involved in cryptographic operations.

[0056] Over the course of time, there is a risk that one or more normal parties will lose their secret share. When this situation occurs, the recovery phase is implemented. For all normal parties that lost their secret share, a recovery party must act as a replacement. Normally, recovery is triggered as soon as a single normal party loses their secret share, and as such, thereis no need for more than a single recovery party, though the possibility to allow for additional recovery parties, if required, is contemplated.

[0057] If the amount of lost key shares (be they recovery key shares or normal key shares) ever exceeds the amount of recovery parties, the keying material is lost, the operations must be interrupted, and the data protected by cryptographic operations is lost.

[0058] A recovery is initiated when a party signals the loss of its secret share. When this happens, all other normal parties that still have their secret share, along with as many recovery parties as required to attain the threshold (which is equal to the total number of normal parties), validate that the operation is legitimate, and then collaborate to perform the recovery operation.

[0059] The key rotation phase is generally similar to the key recovery phase - differences are described below.

[0060] During the delegation phase, a given party can share its own cryptographic material among another group of parties, which may or may not involve any of the original parties. The process of delegation is no different from any other cryptographic operation. As such, it can use the same processes of setup, normal cryptographic operation, recovery, and key rotation as described above. Indeed, the delegation phase provides the opportunity to change between cryptographic methods 100, 200, 300.

[0061] FIGS. 1 A-1C, show a flow chart of the trusted party cryptographic method 100, according to an embodiment. The method 100 includes at least a setup phase 102 and a cryptographic operation phase 104 (FIG. 1A) and may further include a key recovery phase 120 (FIG. IB) and / or a key rotation phase 130 (FIG. 1C).

[0062] A preferred embodiment of a system 10 for implementing the method 100 is shown in FIGS. 1D-1G, showing the setup phase (FIG. ID), the cryptographic operation phase (FIG. IE), the key recovery phase (FIG. IF) and the key rotation phase (FIG. 1G). The system 10 includes three (3) normal parties 11, 12, 13 and one (1) recovery party 14. Consider a service provider company that provides an encryption service to numerous end users. The service provider has a partnership with a system provider responsible for system 10 infrastructure. In the system 10, the system provider is responsible for two independent parties: a normal party 13, and the recovery party 14. To protect against a breach, both systems (i.e., the system acting as the normal party 13 and the system acting as the recovery party 14) are upkeptindependently, using separate hardware, on isolated networks. The other two normal parties are the service provider 11 and an end user 12.

[0063] In the system 10, the system provider 13 is identified as the trusted party that is responsible for the distribution of secret shares, and the collection of secret shares when a cryptographic operation is initiated. When the cryptographic operation is concluded, the trusted party 13 will forget all secret shares except for its own.

[0064] The act, by either the end user 12 or the service provider 11, of providing its secret share can be interpreted as a system of consent: by providing their secret share, the party consents to the cryptographic operation. The trusted party 13 acts as a facilitator for those operations.

[0065] In the following description of the method 100, the elements from FIGS. 1D- 1G are indicated in parenthesis for reference. As a preliminary step prior to commencing the method 100, all normal parties (11, 12, 13) and recovery parties (14) are first identified.

[0066] At 106, a designated trusted party (13) splits a secret into as many secret shares as there are parties (11, 12, 13, 14). This is done internally and requires no communication with other parties. The trusted party will first generate a random secret value, which will be the secret, then share this secret among all normal and recovery parties using the technique described in Shamir’s paper (Shamir, A., Communications of the ACM, 1979, vol. 22, is. 11, pp. 612-613), giving exactly one share to each party, including itself. The secret value acts as the root of a secret key used for cryptographic operations.

[0067] At 108, the trusted party (13) communicates a secret share to all parties (11, 12, 14), and keeps a secret share for itself.

[0068] At 109, the trusted party (13) forgets the secret, and all secret shares apart from its own.

[0069] At 110, all normal parties (11, 12) other than the trusted party (13) communicate their secret share to the trusted party (13).

[0070] At 112, the trusted party (13) uses all secret shares, including its own, to recover the secret.

[0071] At 114, using the secret, the trusted party (13) enables an operation or encrypts / decrypts data in the name of the group.

[0072] At 116, the trusted party (13) forgets the secret, as well as all secret shares apart from its own.

[0073] If a normal party (11, 12, 13) subsequently loses their secret share, or if the secret share is corrupted, the method 100 proceeds to the recovery phase 120.

[0074] At 121, all normal parties (11) who still have their secret share will communicate their secret share to the trusted party (13).

[0075] At 122, a number of recovery parties (14) equal to the number of parties (12) that lost their share, will communicate their secret share to the trusted party (13). As shown in FIG. IF, the normal party 11 still has its secret share, while the normal party 12 has lost their secret share. The trusted party 13 will ask a threshold number of parties, formed of normal parties with secret shares (11), and recovery parties (14), to send them their secret share, from which the trusted party will recover the secret. Given that one (1) normal party 12 lost their share, one (1) recovery party 14 is needed to recover the lost share; if two normal parties lose a share, it will require two recovery parties to reach the threshold and recover the two lost shares, etc.

[0076] It should be noted that steps 121 and 122 are performed at substantially the same time.

[0077] At 123, the trusted party (13) uses the secret shares received from the parties (11, 14) and its own secret share to recover the secret and regenerate the lost secret share. It should be noted that the underlying secret remains the same.

[0078] At 124, the trusted party (13) sends the lost secret share to the party (12) that lost it.

[0079] At 125, the trusted party (13) forgets the secret and all secret shares apart from its own.

[0080] According to some embodiments, following 116, the method 100 proceeds to the key rotation phase 130. Key rotation occurs on a fixed schedule, depending on the security needs. Key rotation may happen once per month, or once per year. Such rotation is done as part of a security policy, with the intention of replacing keys that may have been compromised by new, non-compromised set of keys.

[0081] The key rotation phase 130 is similar to the key recovery phase 120, with the difference being that recovery parties (14) are not involved directly in the process of key rotation, although they do receive a new secret share.

[0082] At 131, all normal parties (11, 12) send their secret share (16) to the trusted party (13).

[0083] At 132, to the trusted party (13) uses all secret shares, including its own, to recover the secret.

[0084] At 133, using the secret the trusted party (13) generates new secret shares.

[0085] At 134, the trusted party (13) communicates anew secret share (17) to all parties(11, 12, 14) including itself.

[0086] At 135, all normal parties (11, 12, 13) discard their old secret share (16).

[0087] At 136, the trusted party (13) forgets the secret and all secret shares except for its own secret share.

[0088] Referring to FIGS. 2A-2B, shown therein is a flow chart of the single-use key cryptographic method 200, according to an embodiment. The method 200 includes at least a cryptographic operation phase including encryption 201 and decryption 207 (FIG. 2 A) and may further include a key recovery phase 220 (FIG. 2B). In the method 200, cryptographic operations are modular. For example, a set of keys can be used for the signature of a single document, or the encryption and decryption of a single piece of data. Unlike the method 100, the method 200 does not include a setup phase beyond identifying the normal parties and recovery parties. The method 200 also does not include a key rotation phase, given that key “rotations” are performed after each cryptographic operation, thus there is no need to have a formal key rotation process.

[0089] A preferred embodiment of a system 20 for implementing the method 200 is shown in FIGS. 2C-2E, showing cryptographic operation phases including encryption (FIG. 2C) and decryption (FIGS. 2D) and a key recovery operation (FIG. 2E). The system 20 includes three (3) normal parties 21, 22, 23 and one (1) recovery party 24. Consider a service provider company that provides an encryption service to numerous end users. The service provider has a partnership with a system provider responsible for system 20 infrastructure. In the system 20, the system provider is responsible for two independent parties: a normal party 23, and the recovery party 24. Both systems (i.e., the system acting as the normal party 23 and the systemacting as the recovery party 24) are upkept independently, using separate hardware, on isolated networks. The other two normal parties are the service provider 21 and an end user 22.

[0090] In the system 20, there is no trusted party. All parties 21, 22, 23, 24, including the recovery party 24, generate single-use keys that are used for the duration of a given operation, and are discarded afterwards. Every party 21, 22, 23, 24 is responsible for its own set of keys. When a cryptographic operation is requested, each party 21, 22, 23, 24 will first generate its own cryptographic material. Often, this is done by hashing a specific value that acts as an identifier, together with a constant secret seed to obtain a value that is unique for each cryptographic operation and can be easily recomputed from the identifier. This hashing operation can be done repeatedly to have increasing levels of specification. For example, such a technique is being used in bitcoin’s BIP 44 (https: / / en.bitcoin.it / wiki / BIP_0044).

[0091] Once the proper cryptographic material has been generated, the party will provide it to the requester in accordance with the protocol. At this point, a software 25 will ensure that the threshold number of parties contributed before validating the operation. The software 25 may be a web-based platform created and upkept by the system provider to facilitate cryptographic operations in a manner similar to Bitcoin software, although the software 25 is not distributed and upkept in a peer-to-peer fashion.

[0092] The recovery parties 24 are involved in ongoing operations, where they will provide their public cryptographic material, since it has not been provided during setup. For example, during an operation of encryption, the recovery part 24 provides an asymmetric public key to the software 25 as a potential party responsible for the decryption of the same data.

[0093] To facilitate communication and coordination between parties, it is preferred that the same identifier be used to derive cryptographic material for a given operation by all parties. This allows the larger parties (the service provider 21 or the system provider 23) to be responsible for the maintenance and the organization of identifiers, thus freeing the smaller parties (the end user 22) from this task. Since the end user 22 is often much more limited in terms of resources, such a delegation of operations is a natural way to facilitate their operations while maintaining their efficiency and security.

[0094] In the following description of the method 200, the elements from FIGS. 2C-2E are indicated in parenthesis for reference. As a preliminary step prior to commencing the method 200, all normal parties (21, 22, 23) and recovery parties (24) are first identified.

[0095] At 202, all parties (21, 22, 23, 24), including recovery parties, will generate a pair of public / private cryptographic keys.

[0096] At 204, all parties (21, 22, 23, 24), including recovery parties, will send the public key to a software (25) that will gather those keys together, along with an indication of the required number of parties that must be present to decrypt the data.

[0097] At 206, the software (25) will perform a cryptographic operation to encrypt a piece of data (26).

[0098] At 208, all normal parties (21, 22, 23) will regenerate the public / private cryptographic keys they used during the previous operation of encryption 201.

[0099] At 210, all normal parties (21, 22, 23) will send a proof of knowledge of the private key (e.g., a digital signature or similar process) to the software (25) that will gather those proofs and accumulate them.

[0100] At 212, once the expected number of proofs have been received, the software will perform a cryptographic operation to decrypt the piece of data (26).

[0101] If after the encryption 201 phase, anormal party (21, 22, 23) subsequently loses their keys, or if the keys become corrupted, the method 200 proceeds to the recovery phase 220. It should be noted that “recovery” only has a meaning in the context of the ongoing cryptographic operation, since when a new operation takes place, all parties generate new sets of keys. That is, every ongoing cryptographic operation involves recovery parties (24). Should a normal party (21, 22, 23) involved in an operation of encryption lose their key, a recovery party (24) involved in the same operation of encryption will be called upon to provide a replacement key the operation of decryption.

[0102] At 222, all normal parties (21, 23) who can still regenerate the public / private cryptographic keys they used during the previous cryptographic operation do so.

[0103] At 224, a number of recovery parties (24) equal to the number of normal parties (22) who can’t do so will also regenerate the public / private cryptographic keys they used during the previous operation of encryption. As shown in FIG. 2E, the normal parties 21, 23 still have their respective keys, while the normal party 22 has lost their key. Given that one (1) normal party 22 lost their share, a threshold of one (1) recovery party 24 is needed to recover the lost key; if two normal parties lose a key, it will require a threshold of two recovery parties to recover the two lost keys, etc.

[0104] It should be noted that steps 222 and 224 are performed at substantially the same time.

[0105] At 226, the involved parties (21, 23, 24) will send a proof of knowledge of the private key (e.g., a digital signature or similar process) to the software (25) that will gather those proofs and accumulate them.

[0106] At 228, once the expected number of proofs have been received, the software (25) will perform the cryptographic operation. The software (25) is responsible for validating that the right number of parties are involved, and is agnostic to the nature of those parties; only the number of parties matters.

[0107] FIGS. 3A-3C, show a flow chart of the cryptographic solution method 300, according to an embodiment. The method 300 includes at least a setup phase 301 and a cryptographic operation phase 302 (FIG. 3 A) and may further include a non-commutative key recovery phase 320 (FIG. 3B) or a commutative key recovery phase 330 (FIG. 3C). The method 300 is preferred for long-term data protection, though it can be used in different contexts as well. This is because the keys persist for a long amount of time, and can be reused without risk.

[0108] A preferred embodiment of a system 30 for implementing the method 300 is shown in FIGS. 3D-3G, showing the setup phase (FIG. 3D), the cryptographic operation phase (FIG. 3E), initial steps of the non-commutative key recovery phase (FIG. 3F) and the commutative key recovery phase (FIG. 3G). The system 30 includes three (3) normal parties31, 32, 33 and one (1) recovery party 34. Consider a service provider company that provides an encryption service to numerous end users. The service provider has a partnership with a system provider responsible for system 30 infrastructure. In the system 30, the system provider is responsible for two independent parties: a normal party 33, and the recovery party 34. Both systems (i.e., the system acting as the normal party 23 and the system acting as the recovery party 24) are upkept independently, using separate hardware, on isolated networks. The other two normal parties are the service provider 31 and an end user 32.

[0109] All parties 31, 32, 33, 34 work together to generate a secret whose value will be unknown to any individual participants. More precisely, a threshold number of participants 31,32, 33, 34 will have to collaborate to identify the value of the secret. In the event of a key recovery or a key rotation, the party responsible for the assembly of all required values to perform the operation will be the end user 32, or more specifically, a piece of software actingin their name, since it is the only party that would be allowed to have access to the underlying data and perform the underlying operations.

[0110] In the following description of the method 300, the elements from FIGS. 3D- 3G are indicated in parenthesis for reference. As a preliminary step prior to commencing the method 300, all normal parties (31, 32, 33) and recovery parties (34) are first identified.

[0111] At 304, each party (31, 32, 33, 34) chooses a random value, called a partial secret, and will split the partial secret into as many partial secret shares as there are parties. Given there are 4 parties (31, 32, 33 34) in the system (30), each party will split the partial secret into 4 partial secret shares. Each party (31, 32, 33 34) employs the technique described by Shamir (Shamir, A., Communications of the ACM, 1979, vol. 22, is. 11, pp. 612-613) to split the partial secret.

[0112] At 306, each party (31, 32, 33, 34) distributes their partial secret shares among all parties, so that every party receives a single partial secret share from all parties including itself.

[0113] At 308, each party (31, 32, 33, 34) adds up their partial secret shares to form a final secret share. This operation is done using modular arithmetic in an agreed-upon context.

[0114] At 310, all parties (31, 32, 33, 34) perform a cryptographic operation of encryption on a dummy value (e.g., a hash of all public values (all generators, primes, available commitments, identifiers, threshold and total number of participants) that are available) to ensure the reliability of the values they are manipulating and verify the result is as expected in the normal cryptographic operation phase 302. Specifically, each party verifies: 1) the result of an encryption with fewer than the threshold number of parties differs from the result of an encryption with exactly the threshold number of parties; and 2) the result of an encryption with more than the threshold number of parties does not differ from the result of an encryption with exactly the threshold number of parties.

[0115] At 312, all normal parties (31, 32, 33) generate a value that is a function of their final secret share. To avoid leaking their secret share, all parties (31, 32, 33, 34) will agree upon a scheme that allows them to share a function of their secret share instead. Such a function is preferably a cryptographic one-way function included in the cryptographic software installed on each party’s device and executed in the device of the party performing a cryptographic operation that allows the provided values to be combined in a meaningful way. Such functions are called Distributed Pseudo-Random Functions (DPRF), introduced in 1999 by Naor, Pinkas,and Reingold (Naor, M., Pinkas, B., & Reingold, O. (1999, April). “Distributed pseudo-random functions and KDCs,” In International conference on the theory and applications of cryptographic techniques (pp. 327-346). Berlin, Heidelberg: Springer Berlin Heidelberg). It should be noted that the particular DPRF that is used may be any classical, post-quantum or other DPRF and is not limited to those DPRFs described by Naor et al.

[0116] At 314, the party that wants to perform the cryptographic operation (this could be any normal party (31, 32, 33) or a recovery party (34), or an altogether different party, depending on the scheme and the nature of the operation, so long as that party is identified during the setup phase 301) will receive the value generated by all normal parties (31, 32, 33). Depending on the properties required by the schemes, commitments may be used to enforce proper behavior.

[0117] At 315, if commitments are used as part of the method 300, they are verified at this step by the party performing the cryptographic operation.

[0118] At 316, the values generated by the normal parties (31, 32, 33) will be gathered in a DPRF (35), from which a DPRF value is derived. It should be noted that while the DPRF is shown as a separate element in the drawings, it is actually a mathematical function that is executed in the device of the party performing the cryptographic operation.

[0119] At 318, the DPRF value is used to perform a cryptographic operation, either directly or in an indirect way, for example, by deriving further values from the first DPRF value.

[0120] If after the encryption 302 phase, a normal party (31, 32, 33) subsequently loses their secret share, or if the secret share becomes corrupted, the method 300 proceeds to the non- commutative recovery phase 320 or the commutative recovery phase 330. The commutative recovery phase 330 is preferred as it provides additional privacy, security and flexibility as described below.

[0121] In the non-commutative recovery phase 320 a party that is allowed to conclude a given cryptographic operation will contact a threshold number of parties, both normal parties and recovery parties, to conclude all ongoing operations (for example, the decryption of a given datum). FIG. 3F shows the system 30 performing the initial steps 321, 322, 323, 324, 325 of the non-commutative recovery phase 320. Then, the setup operation (as shown in FIG. 3D) is performed by all parties involved, and the new cryptographic material is used to resumeoperations (as shown in FIG. 3E) without loss of data (for example, by re-encrypting decrypted data).

[0122] If the non-commutative recovery phase 320 is initiated, the method 300 proceeds as follows.

[0123] At 321, all normal parties (31, 32, 33) who still remember their secret share will generate a value (41, 43) that is a function of their secret share.

[0124] At 322, a number of recovery parties (34) equal to the amount of parties that lost their share will generate a value (44) that is a function of their secret share. As shown in FIG. 3F, the normal parties 31, 33 still have their respective secret shares, while the normal party 32 has lost their Secret share. Given that one (1) normal party 32 lost their secret share, a threshold of one (1) recovery party 34 is needed to recover the lost key; if two normal parties lose their secret shares, it will require a threshold of two recovery parties to recover the two lost secret shares, etc.

[0125] It should be noted that steps 321 and 322 are performed at substantially the same time.

[0126] At 323, the party that wants to perform the cryptographic recovery operation (this could be any normal party (31, 32, 33) or a recovery party (34), or an altogether different party, depending on the scheme and the nature of the operation) will receive the values (41, 43, 44) generated by all parties identified at steps 321, 322.

[0127] At 328, if commitments are used as part of the recovery phase 320, they are verified at this step by the party performing the cryptographic operation.

[0128] At 324, all values (41, 43, 44) will be input to a DPRF (35), from which a recovery value (45) is derived. The recovery value (45) may be identical to the DPRF value generated at step 316. It should be noted that while the DPRF (35) is shown as a separate element in the drawings, it is actually a mathematical function that is executed in the device of the party performing the cryptographic operation.

[0129] At 325, the recovery value is used to complete all ongoing cryptographic operations and recover all data (36). Depending on the implementation, the recovery phase 320 may repeat steps 321 through 325 until all data is recovered.

[0130] At 326, once all data is recovered and all operations are completed, the setup phase 301 (as shown in FIG. 3D) is performed by all parties (31, 32, 33, 34).

[0131] At 327, the party responsible for cryptographic operations (any one of 31, 32, 33, 34) will resume activities by re-encrypting data or restarting operations (as shown in FIG. 3E), using the new cryptographic material generated at step 326.

[0132] If the commutative recovery phase 330 is initiated upon loss of a party’s secret share, the method 300 proceeds as follows.

[0133] At 332, all parties (31, 32, 33, 34) perform the setup phase 301 (as shown in FIG. 3D).

[0134] At 334, all normal parties (31, 32, 33) generate a value (51, 52, 53) that is a function of their newly generated secret shares.

[0135] At 336, all normal parties (31, 33) who still remember their secret share generate a value (61, 63) that is a function of their old secret share.

[0136] At 338, a number of recovery parties (34) equal to the number of parties (32) that lost their share generate a value (64) that is a function of their old secret share. As shown in FIG. 3G, given that one (1) normal party 32 lost their share, a threshold of one (1) recovery party 34 is needed to recover the lost share; if two normal parties lose a share, it will require a threshold of two recovery parties to recover the two lost shares, etc.

[0137] It should be noted that steps 336 and 338 are performed at substantially the same time.

[0138] At 340, the party that wants to perform the cryptographic recovery operation (this could be any normal party (31, 32, 33) or a recovery party (34), or an altogether different party, depending on the scheme and the nature of the operation) will receive the values (51, 52, 53) from step 334 generated by all normal parties (31, 32, 33). If commitments are used as part of this scheme, they are verified at this step.

[0139] At 342, the party that wants to perform the cryptographic recovery operation (this could be any normal party (31, 32, 33) or a recovery party (34), or an altogether different party, depending on the scheme and the nature of the operation) will receive the values (61, 63, 64) from steps 336 and 338 generated by the normal parties (31, 33) and recovery parties (34), respectively. If commitments are used as part of this scheme, they are verified at this step (for all received values, both calculated from old and new shares) by the party performing the cryptographic operation. It should be noted that step 342 can be performed before or after step 340.

[0140] At 343, if commitments are used as part of the recovery phase 330, they are verified at this step by the party performing the cryptographic operation.

[0141] At 344, the values gathered at 340 are input to a DPRF (35) to derive a second DPRF value (55). It should be noted that while the DPRF (35) is shown as a separate element in the drawings, it is actually a mathematical function that is executed in the device of the party performing the cryptographic operation.

[0142] At 346, the second DPRF value (55) is used to perform a cryptographic operation on the (already encrypted) data (36).

[0143] At 348, the values (61, 63, 64) gathered at 342 are input to the DPRF (35) to derive a second recovery value (65).

[0144] At 350, the second recovery value (65) is used to remove all connection between the cryptographic operation or data (36) and the old secret, leaving the operations or data (36) protected by the new secret only.

[0145] It should be noted that the recovery phase 330 does not require data to be decrypted, re-encrypted, nor does it require that operations be interrupted. This is possible because commutative operations are used. For example, in a commutative operation, a key that protects a piece of data can be masked with the function of the shared secret (i.e. the DPRF output) using the Boolean XOR operation. It is then possible to first add a second mask created using the new cryptographic material, before removing the first mask. Such operations must still be performed only by a party allowed to conclude a given cryptographic operation.

[0146] Key rotation is also possible in the method 300. Generally, key rotation in the method 300 is identical to the key recovery phases 320, 330 with the only difference being recovery parties (34) are not called upon.

[0147] The systems 10, 20, 30 and methods 100, 200, 300 can be bolstered by the additional usage of Restricted Operating Environments (ROEs), including hardware enclaves such as HSM and TPM (among others), logical (virtual) enclaves, and Secure Elements such as those found on mobile devices. Any or all parties may store their respective cryptographic material in such an enclave, and benefit from all the advantages provided by hardware protection in addition to the advantages already obtained by the paradigms we provide. In preferred embodiments of the systems 10, 20, 30 and methods 100, 200, 300 all parties use a form of physical protection. It is preferred that end users 12, 22, 32 use a security cardcomplemented with biometric verification (e.g., the Multi-Pass™ by Kelvin Zero), while other parties secure their cryptographic material using a HSM.

[0148] The systems 10, 20, 30 and methods 100, 200, 300 are preferred embodiments representing a 3-out-of-4 solution with three (3) normal parties and one (1) recovery party. However, other embodiments having more or fewer parties are possible. Some of these embodiments are described below.

[0149] In an embodiment having the fewest possible number of parties, one of the normal parties is eliminated, leaving only two normal parties and one recovery party to form a 2-out-of-3 solution. Such an embodiment could represent the partnership between an end user and a single service / system provider that acts as provider for all underlying infrastructure; or a single party that wants to leverage the benefits of threshold security on its own, distributing the various shares among multiple parts of its own infrastructure; or a situation where the end user acts as both normal parties, and relies on a service provider to act as the recovery party.

[0150] According to another embodiment, should up to four parties want to collaborate to increase security and obtain additional protection for their data, a 4-out-of-5 solution is also possible. In this case, all four normal parties must collaborate to complete a given cryptographic operation. The 4-out-of-5 embodiment, may be advantageous in environments where the risk of corruption of some of the parties is more likely, for example, when the parties do not benefit from the additional protection provided by hardware enclaves.

[0151] According to yet another embodiment, an additional recovery party (thus forming a 3-out-of-5 solution) is included when there is a risk that more than one party lose their cryptographic material in a short amount of time, such as in environments with unreliable network connection, or when more than one party represent end users. If this embodiment is chosen, the role of various recovery parties must be clarified in the setup phase, since two recovery parties could collaborate with a single normal party to accomplish a normal cryptographic operation. The 3-out-of-5 embodiment may be advantageous in settings where the trust is high between parties, especially towards the recovery parties.

[0152] It should be noted that there is no upper limit to the number of parties collaborating to implement the cryptographic methods described herein. 4-out-of-6, 5-out-of- 6, 5-out-of-7, 6-out-of-8, 6-out-of-9 and further combinations are possible and contemplated within the scope of the invention.

[0153] As a counter-example to the systems and methods described herein, consider a 3-out-of-3 solution. In this setting, the loss, by a single normal party of their cryptographic material immediately leads to loss of data and the end of cryptographic operation. Furthermore, this setting does not allow for key rotation without either data decryption or loss of operations.

[0154] As a further counter-example, consider a solution in the form of 1-out-of-n, where n is 2 or higher. In such a setting, the compromission of a single party by a nefarious actor would result in the possibility, for that nefarious actor, to perform normal cryptographic operations against the will of other involved parties.

[0155] Using the systems and methods described herein to separate cryptographic material among different parties provides several benefits. First, the security is enhanced by the fact that an adversary would have to corrupt up to the threshold number of parties (normal or recovery) to be able to harm to the system, with the exception of the trusted party method 100, where the corruption of the trusted party results in the failure of the model. As such, an adversary must corrupt more targets, to be able to gain less: each group of parties holds different cryptographic material, and as such, large-scale breaches become impossible. Only targeted attacks remain possible, and even those are significantly harder than they would be in non-threshold settings.

[0156] Furthermore, systems and methods described herein allows for key rotation and key recovery in case of corruption or loss. In a non-cryptographic setting, the loss of a cryptographic key often results in the loss of data or the interruption of operations. In the systems and methods described herein, no data is loss and operations can continue seamlessly.

[0157] While the above description provides examples of one or more apparatus, methods, or systems, it will be appreciated that other apparatus, methods, or systems may be within the scope of the claims as interpreted by one of skill in the art.

Claims

Claims:

1. A method for multiparty cryptographic operations comprising: splitting a secret into a first plurality of secret shares by a trusted party device; dividing the first plurality of secret shares between the trusted party device, one or more user devices and at least one recovery device, each device receiving one secret share; sending a secret share from each user device to the trusted party device; combining the secret shares received from the one or more user devices with a secret share retained by the trusted party device to recover the secret; performing a cryptographic operation by the trusted party device using the secret; and discarding, by the trusted party device, the secret and all secret shares received from the one or more user devices.

2. The method of claim 1, further comprising: losing a secret share by at least one user device; sending a secret share from each user device still having a secret share, to the trusted party device; sending a secret share from the at least one recovery device to the trusted party device; combining the secret share from the at least one recovery device with the secret share received from each user device still having a secret share and the secret share retained by the trusted party device, to recover the secret; regenerating the at least one secret share lost by the at least one user device; and sending at least one regenerated secret share to at least one user device.

3. A method of claim 1, further comprising: sending the secret share from each user device to the trusted party device; combining the secret shares received from the user devices with the secret share retained by the trusted party device, to recover the secret; using the secret to generate a second plurality of secret shares;dividing the second plurality of secret shares between the trusted party device, the one or more user devices and the at least one recovery device, each device receiving one secret share from the second plurality of secret shares; discarding, by each user device, a secret share from the first plurality of secret shares; and discarding, by the trusted party device, the secret and all secret shares received from the one or more user devices.

4. A system for multiparty cryptographic operations comprising: a trusted party device, one or more user devices and at least one recovery device; the trusted party device configured to: split a secret into a first plurality of secret shares; divide the first plurality of secret shares between the trusted party device, the one or more user device and the at least one recovery device, each device receiving one secret share; receive a secret share from each user device; combine the secret shares received from the one or more user devices with a secret share retained by the trusted party device to recover the secret; perform a cryptographic operation using the secret; and discard the secret and all secret shares received from the one or more user devices.

5. The system of claim 4, wherein one or more devices is a hardware security module or a trusted platform module.

6. The system of claim 4, wherein at least one user device loses at least one secret share and the trusted party device is further configured to: receive a secret share from each user device still having a secret share; receive at least one secret share from the at least one recovery device;combine the at least one secret share from the at least one recovery device with the secret share received from each user device still having a secret share and the secret share retained by the trusted party device, to recover the secret; regenerate the at least one secret share lost by the at least one user device; and send at least one regenerated secret share to at least one user device.

7. The system of claim 4 wherein the trusted party device is further configured to: use the secret to generate a second plurality of secret shares; divide the second plurality of secret shares between the trusted party device, the one or more user devices and the at least one recovery device, each device receiving one secret share from the second plurality of secret shares; and discard the secret and all secret shares received from the one or more user devices.

8. The system of claim 7, wherein each user device is configured to: receive a secret share from the first plurality of secret shares sent by the trusted party device; send the secret share from the first plurality of secret shares to the trusted party device; receive a secret share from the second plurality of secret shares sent by the trusted party device; and discard the secret share from the first plurality of secret shares.

9. The system of claim 7, wherein each recovery device is configured to: receive a secret share from the first plurality of secret shares sent by the trusted party device; send the secret share from the first plurality of secret shares to the trusted party device; receive a secret share from the second plurality of secret shares sent by the trusted party device; discard the secret share from the first plurality of secret shares.

10. A method for multiparty cryptographic operations comprising:generating a public key and a private key by each of at least two user devices and at least one recovery device; sending the public key and an indication of expected devices for decryption from each of the devices to a software; and performing a cryptographic operation to encrypt data by the software.

11. The method of claim 10, further comprising: regenerating the public key and the private key by each of the user devices; sending a proof of the private key from each of the user devices to the software; and performing a cryptographic operation to decrypt the data by the software when the proof of the private key is received from the expected devices for decryption.

12. The method of claim 10, further comprising: losing at least one of the private key and the public key by a first user device; regenerating the public key and the private key used in a previous encryption operation by each of the user devices apart from the first user device; regenerating the public key and the private key used in a previous encryption operation by a recovery device; sending the proof of the private key by the recovery device and each of the user devices apart from the first user device to the software; and performing the cryptographic operation to decrypt the data by the software when the proof of the private key is received from the expected devices for decryption.

13. A system for multiparty cryptographic operations comprising: at least two user devices and at least one recovery device, each device configured to: generate a public key and a private key; send the public key and an indication of expected devices for decryption from each of the devices to a software; send a proof of the private key to the software; the software configured to:receive the public key and an indication of expected devices for decryption from each of the devices; perform a cryptographic operation to encrypt data; receive the proof of the private key from each of the devices; and perform a cryptographic operation to decrypt the data when the proof of the private key is received from the expected devices for decryption.

14. The system of claim 13, wherein each device is further configured to regenerate a previous public key and a previous private key used in a previous encryption operation.

15. A system for multiparty cryptographic operations comprising: at least two user devices and at least one recovery device, each device configured to: generate and split a first random partial secret into a number of partial secret shares equal to a number of devices in the system; send a partial secret share to each device in the system and retain one partial secret share; add up partial secret shares received from the devices in the system to form a final secret share; perform an encryption operation on a dummy value to ensure an expected result; generate a first value that is a function of the final secret share; send the first value to all devices in the system; receive a second value from each user device, the second values being a function of a final secret share of each user device; input the first value and the second values to a distributed pseudo-random function (DPRF) to derive a first DPRF value; and use the first DPRF value to perform an encryption operation on data.

16. A system of claim 15, wherein each user device is further configured to:receive a third value being a function of a final secret share of the at least one recovery device; input the first value, the second values and the third value to a DPRF to derive a recovery value; and use the recovery value to perform a recovery operation.

17. The system of claim 15, wherein each user device is further configured to: generate and split a second random partial secret into a number of second partial secret shares equal to the number of devices in the system; send a second partial secret share to each device in the system and retain one second partial secret share; add up second partial secret shares received from the devices in the system to form a second final secret share; perform an encryption operation on a second dummy value to ensure a second expected result; generate a fourth value that is a function of the second final secret share; send the fourth value to all devices in the system; receive a fifth value from each user device, the fifth values being a function of a second final secret share of each user device; receive a third value being a function of a final secret share of the at least one recovery device; input the fourth value and the fifth values to the DPRF to derive a second DPRF value; use the second DPRF value to perform a cryptographic operation on the data; input the second values and the third value to the DPRF to derive a second recovery value; and use the second recovery value to remove all connection between the encryption operation and the final secret shares.

18. A method for multiparty cryptographic operations comprising:generating and splitting, a first random partial secret into a number of partial secret shares equal to a number of user devices and recovery devices in a system; retaining one partial secret share and sending a partial secret share to every device in the system; adding partial secret shares received from every device in the system to form a final secret share; performing an encryption operation on a dummy value to ensure an expected result; generating a first value that is a function of the final secret share; sending the first value to every device in the system; receiving a second value from each user device in the system, the second values being a function of a final secret share of each user device; inputting the first value and the second values to a distributed pseudo-random function (DPRF) to derive a first DPRF value; and using the first DPRF value to perform an encryption operation on data.

19. A method of claim 18, further comprising: receiving a third value being a function of a final secret share of the at least one recovery device; inputting the first value, the second values and the third value to a DPRF to derive a recovery value; and using the recovery value to perform a recovery operation.

20. A method of claim 18, further comprising: generating and splitting a second random partial secret into a number of second partial secret shares equal to the number of devices in the system; retaining one second partial secret share and sending a second partial secret share to each device in the system; adding up second partial secret shares received from the devices in the system to form a second final secret share;performing an encryption operation on a second dummy value to ensure a second expected result; generating a fourth value that is a function of the second final secret share; sending the fourth value to all devices in the system; receiving a fifth value from each user device, the fifth values being a function of a second final secret share of each user device; receiving a third value being a function of a final secret share of the at least one recovery device; inputting the fourth value and the fifth values to the DPRF to derive a second DPRF value; using the second DPRF value to perform a cryptographic operation on the data; inputting the second values and the third value to the DPRF to derive a second recovery value; and using the second recovery value to remove all connection between the encryption operation and the final secret shares.

Images