Backup/Restore of Key Shares

Background

In most cases the backup of key shares are done by backing up configuration files and the database. On mobile phones, however it may be difficult to do a database backup, and in this case an alternative way of creating backups is needed.

Configuration

To enable backup of key shares the following entry need to be added to the relevant protocol section of the configuration:

[SEPH18S/DKLS18/DKLS19/SEPD19S]
  EnableShareBackup=true

EnableShareBackup will enable endpoints so backup and restore can be called.

Use of Backup and Restore

As this is intended for mobile phones and it returns the key share unencrypted, the BackupShare and RestoreShare methods in the SDK will refuse to run if more than one node is configured in the SDK client.

Backup will return the database state required to restore the key share at a later point. The exported state is not protected and must use some protection to prevent the key share from being leaked.

Because it is the database state that is backed up, there are a lot of meta data backed up along with the key share.
There are numerous ways to handle this database, a couple of them (by no means a complete list) are:

Create a QR code containing the backup data to be saved securely outside the phone. Restoring is just a matter of scanning the QR code. This will require access to printers from the phone to get the QR code printed, and the printout should not be left in the printer unattended as it contains the key share.
Creating a symmetric AES key (16-32 bytes) and encrypting the backed up data. The AES key can then be stored or memorized by the user, e.g. using BIP-39, or just writing down the HEX/Base 64 encoding. The encryption of the backed up data can then be stored in some central server, as the only one who is able to decrypt it will be the user that knows the AES key.

This is just a couple of examples of how the backup can be handled safely for inspiration, but many other solutions will solve the problem just as well.

Code examples

The following examples are made using the ECDSA client, but the call sequence is identical if using the EDDSA client instead. To back up a key share, a client with a single node (possibly an embedded client) must be created. Then the following code can be used:

// Error checking have been omitted for simplicity
// Input:
//   client: a client containing a single node, e.g. an embedded client
//   keyID: the id of the key to back up

ecdsaClient := tsm.NewECDSAClient(client)

backup, err := ecdsaClient.BackupShare(keyID)
// handle the backup securely

This returns a byte array with the backed up database state. This must be stored securely as it contains the key share unprotected.

To restore the backup at a later point, the following code can be used:

// Error checking have been omitted for simplicity
// Input:
//   client: a client containing a single node, e.g. an embedded client
//   backup: the backup returned from the BackupShare call

ecdsaClient := tsm.NewECDSAClient(client)

restoredKeyID, err := ecdsaClient.RestoreShare(backup)

This returns the keyID of the key, which is always the same as the keyID given to the BackupShare method.