ERS Backup and Recovery

A typical ERS setup will consist of:

A TSM storing the private ECDSA or EdDSA key that should be exported.
An application requesting the encrypted backup from the TSM.
A recovery application that will recover the private ECDSA or EdDSA key once it determines that all conditions for recovery are satisfied, and once it has received the encrypted backup.
A decryption service is used by the recovery application to decrypt parts of the backup.

The following figure shows how the ERS works.

Suppose we have a TSM with three MPC nodes that contains a private ECDSA key. This means that the ECDSA key is split into key shares that are distributed among the MPC nodes. We will assume that each of the MPC nodes is owned by its own organisation, and that each organisation uses its own instance of the SDK to access its MPC node.

The ERS backup and recovery process then works as follows:

Setup We will assume that the Decryption Service holds a private RSA key, and that each of the organisations holds a copy of the corresponding public RSA key. The Decryption Service could for example be a hardware security module (HSM).
Export [Step 1] To back up the ECDSA key, each organisation calls a method on its SDK where it provides the public RSA key and obtains what we call partial recovery data (Step 1 in the diagram above). The partial recovery data is essentially an encryption under the RSA key of the MPC node's private ECDSA key share along with a zero-knowledge proof.
Combine [Step 2] The partial recovery data is then collected and combined into a single piece of recovery data. The combine method uses the public RSA key and the zero-knowledge proofs contained in the recovery data to verify that the combined recovery data does indeed contain a correct encryption of the private ECDSA key. It does not require the private RSA key, and the key shares remain encrypted under the public RSA key. On request we provide an open-source reference Go code implementation that shows how to combine the recovery data. For convenience, the combine method is also available as a static method on the TSM SDK.

Technically it is enough to collect partial recovery data from t+1 MPC nodes, where t is the security threshold of the TSM. But usually partial recovery data is collected from all MPC nodes.

Validation [Step 3] The combined recovery data is then stored somewhere safe, for example in some offline storage device. The recovery data is not sensitive as long as the private RSA key remains unavailable. Anyone holding the public RSA key and the public ECDSA key can validate the recovery data. This can be done by the open-source Go library we provide, or by calling a static validate method on our SDK. Validation includes checking the zero-knowlege proofs which ensures that the private ECDSA key can indeed be recovered from the recovery data, if one has access to the private RSA key.

Validating the recovery data may be done regularly to ensure that the backup has not been corrupted or otherwise tampered with. And if transferring the recovery data from one person to another, the receiver may want to re-validate the recovery data.

Recovery [Step 4 and 5] Recovery of the ECDSA key requires the encrypted recovery data and access to the Decryption Service, which holds the private RSA key. Our open-source Go code, available on request, shows how to implement the recovery algorithm.

The Decryption Service only performs a number of standard RSA decryptions. This means that this service can be provided by almost any type of HSM. Also, the Decryption Service is never asked to decrypt enough information to learn the ECDSA key.

ERS Label

When creating an ERS backup it is possible to attach a label to the encryptions. The decryption service needs this label in order to be able to decrypt.

An example of how this feature could be used is to let the label contain a policy describing under which circumstances this key should be recovered. The decryption service can then verify that it is actually allowed to recover this key, and if the recovery application lied about the policy then decryption will fail.

Another example is to let the label contain the ID of the key owner. If a user wants to recover his key he will publically announce that fact, and the decryption service will refuse to decrypt with labels that have not announced that they want their key recovered.