The Blockdaemon Builder Vault TSM Emergency Recovery System (ERS) allows you to securely export private ECDSA and EdDSA keys from the TSM. The exported key will be encrypted under an external public RSA key, and can be safely stored somewhere else as a backup. The private ECDSA or EdDSA key can later be recovered using only the exported encrypted backup and the external private RSA key. Recovery does not require access to the TSM.

Key features:

The backup is encrypted under a public RSA key.
The backup can be validated in zero-knowledge at any time and by anyone holding the public RSA key.
The backup can be recovered offline using the private RSA key.
The private RSA key can be stored in a hardware security module (HSM); recovering only requires a number of standard decryptions using the private RSA key.
You can use a fixed RSA key for backup of many keys or a separate RSA key for each backup.

The Emergency Backup and Recovery Process

A typical ERS setup will consist of:

A TSM stores the private ECDSA or EdDSA key that should be exported.
An application is 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 contain a private ECDSA key. This means the ECDSA key is split into shares distributed among the MPC nodes. We will assume that its own organisation owns each of the MPC nodes, and each organisation uses its 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 partial recovery data (Step 1 in the diagram above). The partial recovery data is essentially encrypted under the RSA key of the MPC node's private ECDSA key share and a zero-knowledge proof.
Combine [Step 2] The partial recovery data is then collected and combined into a single piece of recovery data. The combined method uses the public RSA key and the zero-knowledge proofs contained in the recovery data to verify that the combined recovery data contains correct encryption of the private ECDSA key. It does not require the private RSA key; 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. The combined method is also available for convenience 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. However, usually, partial recovery data is collected from all MPC nodes.

Validate [Step 3] The combined recovery data is stored somewhere safe, for example, in some offline storage devices. The recovery data is not sensitive as long as the private RSA key remains unavailable. Anyone holding the public RSA and ECDSA keys 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-knowledge proofs, which ensures that the private ECDSA key can be recovered from the recovery data if one has access to the private RSA key.

The recovery data may be validated regularly to ensure the backup has not been corrupted or otherwise tampered with. If transferring the recovery data from one person to another, the receiver may want to re-validate the recovery data.

Recovery [Steps 4 and 5] 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 several 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.

The ERS Label

When creating an ERS backup, a label can be attached to the encryptions. The decryption service needs this label 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 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 publicly announce that fact, and the decryption service will refuse to decrypt with labels that have not been told they want their key recovered.