The Emergency Backup and Recovery Process

The Blockdaemon Builder Vault TSM Emergency Recovery Service (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.

A typical ERS setup will consist of:

• A TSM which 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:

1. 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).
2. Export: 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. 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.
3. Combine: 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 contains correct encryption of the private ECDSA key.
4. Validate: 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.
5. Recovery: Recovering the ECDSA key requires access to the encrypted recovery data and to the Decryption Service, which holds the private RSA key. The Decryption Service only performs several standard RSA decryptions.

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.