Author: salvatoshi
Source: https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607
For any non-single-signature wallet account, backup descriptors are extremely critical, because losing descriptors could have catastrophic consequences (loss of funds) - even if the seed words that are theoretically sufficient for wallet recovery have not been lost. This is true even for simple multisig wallets, as losing information in a single xpub could potentially make the wallet unrecoverable.
Due to the lack of standards, people have created various backup schemes, with some even etching them onto metal plates.
I believe this is not a good approach and should be avoided. Descriptors are not seed words, so they should be handled completely differently, both theoretically and operationally.
In this article, I will briefly introduce the background and outline the ideal structure of a wallet account backup standard that I believe can be adopted by software wallets.
Motivation: Confidentiality vs. Privacy
Seed words must be kept secret, as they protect the key material that can spend funds. If seed word access restrictions are breached, it means the attacker gains ownership of the funds (at least the specific control protected by the related keys). Therefore, touching seed words is extremely valuable for attackers, and they are willing to invest higher costs and more sophisticated attacks due to potentially high returns.
Therefore, for seed words:
- Electronic backups are high-risk: Hardware signers are specifically designed to store seed words in secure chips, isolated from devices running software wallets.
- Redundant backups of seed words are high-risk: Seed words must be protected by physical devices, and placing multiple copies in different locations makes comprehensive protection more difficult.
Descriptors (and their little brother xpub) only need privacy: Touching them would only allow an attacker to probe your funds. This is certainly bad, but not as valuable as directly stealing your funds. Attackers might use them to gather information about you and form further attacks, but they will lose interest if the attack becomes too expensive and complex.
For descriptors:
- Electronic backups are unavoidable: Every participant using this account will necessarily use an electronic backup in their own software wallet.
- The risk of additional redundant backups is negligible.
Therefore, generating multiple backups of descriptors, whether physical or electronic, stored on hard drives or cloud storage, is an effective way to reduce the risk of fund loss - unlike the redundant backups of seed words, which would increase your risk.
I recommend using time-locked recovery mechanisms like the liana wallet to substantially address the risk of fund loss due to seed word mismanagement.
So, how to correctly backup descriptors and wallet terms?
Physical backups are simple - you just need a printer. Paper backups are fine if you have redundant backups. In this article, I'm only focusing on electronic backups.
Desirable Properties of Electronic Backups
- Encryption: This way, backups can be stored in untrusted environments, such as cloud services or even public forums.
- Access Control: Decryption should be achievable by the target participants (usually a subset of co-signers).
- Easy to Implement: It should not require complex tools.
- Vendor Independent: Ideally, it should be implementable with any hardware signing device.
- Deterministic: The backup result is the same for the same payload. Not critical, but would be better.
A Simple Deterministic Encryption Backup Scheme (Draft)
We can simply encrypt the payload (in this case, the descriptor itself) using the xpub of each participant we want to be able to decrypt it.
Idea 1: We can do better by generating a random 32-byte symmetric key $s$, encrypting $s$ with each public key, and then using $s$ to encrypt the payload. This reduces the backup size from $O(n·|data|)$ to $O(n + |data|)$ (where $n$ is the number of public keys).
Translator's note: When the number of participants (public keys) is n, to ensure each participant can decrypt, directly encrypting the payload with each person's xpub would create n encrypted payload copies, thus $n·|data|$; but if encrypting the payload with a symmetric key, there would only be 1 encrypted payload, and additionally, n encrypted copies of the symmetric key $s$ (of fixed length), thus $n + |data|$.
Idea 2: For any participant who already knows the descriptor, there's nothing to hide. Therefore, confidentiality can be reduced to maintaining secrecy from those who don't have the descriptor. Each of our co-signers already has a public key (their xpub in the wallet account), so we can reuse this key as the encryption key. However, using asymmetric encryption would require a private key for decryption. This is undesirable because the private key might be in a secure chip where custom decryption logic is difficult to program. Conversely, we can reuse the entropy of the public key itself to generate a symmetric key and use it to "encrypt" the shared secret value $s$. So, for any participant $i$ using public key $p_i$, we derive its symmetric key as $s_i = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}" | p_i)$. This avoids asymmetric encryption and only requires accessing the public key from a secure chip - a function already available on all Bitcoin signing devices.
Idea 3: The only randomness in this process is the shared secret value $s$. To make it completely deterministic, we can use the combined entropy of the descriptor to derive a deterministic shared secret value that anyone who knows the descriptor can know. Assuming the different xpubs in the descriptor are $p_1, p_2, \dots, p_n$ (sorted in dictionary order), a simple choice would be: $s = \operatorname{sha256}(``\textrm{BACKUP_DECRYPTION_SECRET}" | p_1 | p_2 | \dots | p_n)$.
The next section will integrate all these ideas.
Scheme
In the following, the payload $data$ to be backed up is undefined, but it will (at least) include the descriptor or BIP388 wallet terms. The operator "⊕" represents bitwise XOR operation.
- Let $p_1, p_2, \dots, p_n$ be the public keys in the descriptor/wallet terms, sorted in dictionary ascending order.
- Let $s = \operatorname{sha256}(``\textrm{BACKUP_DECRYPTION_SECRET}" | p_1 | p_2 | \dots | p_n)$
- Let $s_i = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}" | p_i)$
- Let $c_i = s \oplus s_i$
- Use the AES-GCM algorithm to encrypt the payload $data$ with the symmetric key $s$
The final backup is a list of $c_i$ and the encrypted copy of $data$.
Decryption
To decrypt a backed-up payload, the owner of a specific public key $p$ calculates $s = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}" | p)$, then tries to compute the symmetric key $c_i \oplus s$ for each $c_i$, and uses the symmetric key to decrypt the payload.
Security Considerations
Deterministic encryption, by definition, cannot satisfy the "semantic security" property commonly used in cryptography; however, in our context, it can be safely assumed that the adversary cannot obtain the plaintext, and no other plaintext will be encrypted with the same secret value $s$.
Future Work
I hope this can inspire a more formal specification and have all software wallets adopt the same standard.
