作者：salvatoshi
來源：https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607
對任何非單簽名的錢包賬戶來說，備份描述符都是極為關鍵的，因為弄丟描述符可能會有災難性的後果（損失資金） —— 即使理論上來說足以復原錢包的種子詞沒有丟失。哪怕對簡單的多簽名錢包來說也是如此，因為僅僅弄丟一個 xpub 中的信息就有可能使錢包無法復原。
因為缺乏標準，人們自創了各種備份方案，甚至有人把它刻在金屬板上。
我認為這不是個好辦法，應該避免。描述符不是種子詞，所以不管在理論上還是操作上，都應該有完全不同的處理辦法。
在本文中，我會簡要介紹背景，並簡述我認為可被軟件錢包採用的 錢包賬戶備份標準 的理想結構。
動機：機密性 vs. 隱私性
種子詞要秘密保存，它是用來保護能夠花費資金的密鑰材料的。種子詞訪問限制如果被突破，就意味著攻擊者獲得資金的所有權（至少是相關的密鑰所保護的具體控制權）。因此，能夠觸碰種子詞對攻擊者來說是非常有價值的，而且它們願意投入更高的成本、更精心的攻擊，因為可能有高昂回報。
因此，對種子詞來說：
- 電子備份是高風險的：硬件簽名器專門設計成在安全芯片中保存種子詞，跟運行軟件錢包的設備隔離。
- 種子詞的冗餘備份也是高風險的：種子詞必須要物理裝置保護，而在多個地點放置多個副本會讓周全的保護變得更難。
描述符（以及它的小兄弟 xpub）則只需要隱私：觸碰到它只會讓一個攻擊者可以打探你的資金。這當然也是壞事，但不像直接拿走你的資金那麼有價值。攻擊者可能會用它來獲得關於你的信息、形成進一步的攻擊，但 一旦發現攻擊太過昂貴和複雜就會失去攻擊興趣。
對描述符來說：
- 電子備份是無法避免的：每一個使用這個賬戶的參與者都 必然 會在自己自己的軟件錢包中使用一個電子備份。
- 額外的冗餘備份的風險算不上什麼。
因此，為描述符生成多個備份，無論是實體的、電子的，放在硬盤上還是放在雲存儲上，都是減少資金丟失風險的有效方法 —— 它不像種子詞的冗餘備份那樣會給你帶來更高的風險。
我建議使用像 liana 錢包這樣的時間鎖復原機制，以在實質上解決由種子詞管理不當帶來的資金丟失風險。
那麼，要如何 正確地 備份描述符和錢包條款？
實體備份很簡單 —— 你只需要打印機就性了。如果你有冗餘備份，紙備份也挺好。在本文中我只關心電子備份。
電子備份的可欲屬性
- 加密：這樣一來，備份就可以放在不受信任的環境中，比如雲服務商，甚至公開的論壇中。
- 具有訪問控制：解密應該是目標參與者可以做到的事（一般來說是聯合簽名人的一個子集）。
- 易於實現：不應要求使用複雜的工具。
- 廠商獨立：理想情況下，它應該能夠使用任意硬件簽名設備實現。
- 確定性：備份的結果對相同的載荷是一樣的。並不關鍵，但有會更好。
一種簡單的確定性加密備份方案（草稿）
我們可以單純用每一個我們希望能夠解密描述符的參與者 xpub 來加密載荷（在這裡就是描述符本身）。
想法 1：可以做得更好一些，我們生成一個隨機的 32 字節的對稱密鑰 $s$，用每一個公鑰加密 $s$，然後用 $s$ 來加密載荷。這將備份的體積從 $O(n·|data|)$ 降到了 $O(n + |data|)$（其中 $n$ 為公鑰的數量）。
譯者注：當參與者（公鑰）數量為 n，為保證每一個參與者都能解密，直接用每個人的 xpub 來分別加密要形成載荷的 n 個加密副本，因此是 $n·|data|$；但如果用一個對稱密鑰來加密載荷，就只會有 1 個載荷加密副本，另外，則是對稱密鑰 s 的 n 個（固定長度的）加密副本，因此是 $n + |data|$ 。
想法 2：對於任何已經知道描述符的參與者，就沒什麼好隱藏的。因此，機密性 可以降低到 對任何還沒有拿到描述符的人保持機密。我們的每個聯合簽名人已經有一個公鑰（就是他們在錢包賬戶中的 xpub），因此，我們可以複用這個密鑰作為加密密鑰。然而，使用非對稱加密，在解密的時候就需要私鑰。這是不合意的，因為私鑰可會能放在不容易編程出定制化解密邏輯的安全芯片中。反過來，我們可以複用公鑰自身的熵來生成一個對稱密鑰，並用它來 “加密” 共享的秘密值 $s$ 。那麼，對於任何使用公鑰 $p_i$ 的參與者 $i$，我們都這樣派生其對稱密鑰 $s_i = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}” | p_i)$ 。這就避免了非對稱加密，而且只需要能夠從安全芯片中訪問公鑰 —— 這是所有的比特幣簽名設備都已具備的功能。
想法 3：這個過程中唯一的隨機性是共享秘密值 $s$。為使之是完全確定性的，我們可以使用描述符的結合熵（combined entropy）來派生一個確定性的、每個知曉描述符的人都能知道的共享秘密值。假設該描述符中的不同 xpub 有 $p_1, p_2, \dots, p_n$（以字典順序排列），一個簡單的選擇是：$s = \operatorname{sha256}(``\textrm{BACKUP_DECRYPTION_SECRET}” | p_1 | p_2 | \dots | p_n)$。
下一節則會將上述想法都整合起來。
方案
在下文中，將被備份的載荷 $data$ 是未定義的，但它將（至少）包括描述符或者 BIP388 錢包條款。操作符 “⊕” 表示的是按位 XOR（異或）操作。
- 設 $p_1, p_2, \dots, p_n$ 為 描述符/錢包條款 中的公鑰，以字典升序排列。
- 令 $s = \operatorname{sha256}(``\textrm{BACKUP_DECRYPTION_SECRET}” | p_1 | p_2 | \dots | p_n)$
- 令 $s_i = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}” | p_i)$
- 令 $c_i = s \oplus s_i$
- 使用 AES-GCM 算法， 用對稱密鑰 $s$ 來加密載荷 $data$
最終的備份是 $c_i$ 的列表以及 $data$ 的加密副本。
解密
要解密一個備份的載荷時，特定公鑰 $p$ 的主人要計算 $s = \operatorname{sha256}(``\textrm{BACKUP_INDIVIDUAL_SECRET}” | p)$，然後嘗試用每一個 $c_i$ 計算出對稱密鑰 $c_i \oplus s$，並用對稱密鑰來解密載荷。
安全考慮
確定性加密，按照其定義，無法滿足密碼學中常用的“ 語義安全” 屬性；但是，在我們這個語境下，可以安全地假設敵手無法獲得明文，而且也沒有別的明文會用同樣的秘密值 $s$ 來加密。
未來的工作
我希望這能夠給更加正式的規範帶來啟發，讓軟件錢包都採用相同的標準。
