SLIP39のバックアップ復元：必要な枚数がそろっても分からないこと

資金について：CypherpunkGuideは、リンク先の購入ガイドを通じて紹介報酬を得る場合がある。この記事に直接の購入用紹介リンクはない。今回の実験について、ウォレット事業者からスポンサー料は受けていない。

SLIP39は、復元に使う秘密情報を、所定数を集めて復元できる単語列へ分ける規格である。3枚に分けたバックアップのうち、2枚が手元に残っている。3枚中2枚を必要とする「2-of-3」なら、枚数は足りる。だが、その2枚は同じ組み合わせとして使えるのか。別のグループも必要なのか。目的のウォレットを開くためのパスフレーズは合っているのか。枚数だけでは答えられない。

2026年10月6日、公開された実験用データだけを使い、入力と期待される結果が決まっている公式の試験45件と、独自の確認32件を実行した。計77件すべてが、事前に定めた結果と一致した。想定どおりに処理を拒否した例も、パスフレーズの間違いを知らせず別の値を返した2例も含む。ウォレットの復元に77回成功した、という意味ではない。

実験に使ったのはSLIP39の参照実装、つまり規格の動作を示すプログラムである。ハードウェアウォレットの試験、Bitcoinの残高探索、取引への署名は行っていない。受領・署名・復旧の違いは、自己管理の確認手順で扱っている。

枚数に加えて、条件を満たしたグループを数える

#

SLIP39では、グループ内で必要な枚数と、復元に必要なグループ数を別々に定められる。分割したバックアップの一つを**シェア（share）と呼ぶ。通常は単語列として記録する。それぞれの段階で必要となる数がしきい値（threshold）**である。

この二段階の仕組みは、SLIP39の仕様で定められている。今回のグループ分けした試験では、3グループのうち2グループを必要とした。最初の2グループは、それぞれ3枚中2枚で条件を満たす。最後のグループは1枚だけで条件を満たす構成だ。最初のグループのカードを2枚集めても、満たせるのは1グループ分であり、バックアップ全体の復元条件には足りない。

この構成で、必要最小限の枚数からなる有効な組み合わせ15通りを試した。すべて元の値と一致した。一方、グループの条件が不足する2例は拒否された。別に用意した単純な2-of-3の試験でも、選べる2枚の組み合わせ3通りすべてが一致した。同じシェアを2回渡しても、別のシェアが1枚増えたことにはならなかった。

シェアから再現するのは、一つの秘密情報である。通常のBitcoinマルチシグで使う、独立した複数の署名鍵とは違う。マルチシグの復元実験では、その別の問題を検証している。どちらの方式も、すべての保有者にとって自動的に最善になるわけではない。

シェアが正しくても、パスフレーズの正しさは分からない

#

SLIP39は、入力したパスフレーズが意図したものかどうかを検証しない。パスフレーズとは、シェアとは別に使う追加の秘密文字列である。今回、わざとパスフレーズを違えた2例では、シェアからの復元と復号の処理が完了した。しかし、得られたデータは、元の公開された値とは異なっていた。

プログラムはまず、シェアが表す暗号化済みの値を復元する。これを**暗号化マスターシークレット（EMS）**と呼ぶ。その後、パスフレーズを使って暗号化前の値を導く。Trezorのファームウェア文書も、シェアからの復元と、パスフレーズに依存する導出を分けて説明している。

処理が完了した、という表示だけで安心してよいのか。今回の実験では、元の値をあらかじめ知っていたから、不一致を見つけられた。完了したことだけでは判定できない。

ただし、今回はアドレスを作って照合したわけでも、ウォレットの残高を調べたわけでもない。実際の復元で残高が空なら、原因をさらに調べる必要がある。この実験だけで、その原因がパスフレーズにあるとは判断できない。

添付のプログラムは、パスフレーズを探すための道具ではない。パスワード復旧の記事は、別の種類の問題を扱っている。

追加で作っても、以前のバックアップは使えることがある

#

同じ秘密情報のバックアップを追加で作っても、以前の復元情報が使えるまま残ることがある。今回の試験では、先に作った1枚式、先に作った2-of-3、後から作った2-of-3のいずれからも、同じ元の値を復元できた。

ここで「先に作った」とは、実験内の作成順を指す。3セットともextendable形式（extendable=True）で、識別値も同じ42にそろえた。旧世代のSLIP39形式や、端末上の更新手順を試した結果ではない。

これとは別に、Trezorのバックアップ更新ガイドも、対応する既存ウォレットでバックアップを追加しても、元のバックアップは無効にならないと説明している。画面操作や、追加に対応する条件は製品ごとに決まる。今回の数学的な例で、それらの条件を検証したわけではない。

資金へのアクセスとプライバシーを管理するなら、最新のセットだけでなく、以前のバックアップも点検対象に含める必要がある。シェアを追加で作ることを、すでに漏れた復元情報の失効と取り違えてはいけない。この記事は、バックアップの廃棄、端末の初期化、資金の移動を指示するものではない。

77件の確認で分かった範囲

#

実験結果は、元の値との一致、元の値とは異なる結果、処理の拒否を区別している。ケースごとの結果には、77件すべての観測を残した。

最後の2行には、特に注意が要る。同じ先頭語になる例は、付随する識別情報を意図的に使い回し、独立した分割セットを作った人工的なものだ。その1例では、混在が復元時の整合性検査で拒否された。あらゆる混在の動作や、失敗する割合を確かめたわけではない。先頭語の一致は、目的のウォレットであることの証明にはならない。

3枚全部を渡したときの拒否は、この実装の復元関数が定める入力条件による。必要枚数ちょうどを選んで渡すことが求められる。3枚とも手元にあると復元できない、という意味ではない。その中から2枚を選んだ組み合わせは、すでに3通りとも成功している。

実験の再現用一式には、版を固定した公式実装、入力、結果をまとめた。使っているのは、再現できるよう乱数を固定した試験処理と公開値だけである。このシェアを実資金の保管に使ってはいけない。実際の復元用の単語を入力できるように、プログラムを改変してもいけない。 公式実装の説明書も、機密性の高い秘密情報を扱うための保護を備えていないと明記している。オフラインで実行しても、実用の復元ツールとして安全になるわけではない。

公式の試験用入力では、復元したマスターシークレットのデータを期待値と照合した。付属するBIP32拡張秘密鍵の導出は試験していない。端末の互換性、アドレスの探索、署名、人が実際に行う復元手順も、今回の検証範囲に含まれない。

秘密情報を集めずに、復元計画を点検する

#

復元の点検表には、どの条件を確認したかを記録すればよい。復元用の単語そのものを集める必要はない。未記入の点検表も、確認状況を書く形式にした。シェア、パスフレーズ、人名、保管先の住所を書く欄は設けていない。

確認するのは、バックアップ形式と文書で示された復元先の対応状況、必要なシェアとグループ、別途パスフレーズが必要か、以前のバックアップがまだ使えるかである。一度の事故で複数の保管先を同時に失う可能性も考える。点検表だけでも保管体制が分かる場合があるため、その内容に応じて非公開で管理すること。

実際の確認には、利用する製品の提供元が文書化した手順を使う。点検表を埋めるために、使えている復元情報を消してはいけない。ファイルの復元テストで分かるのは、保存したファイルを読み出せるかどうかである。それだけで、特定のウォレットの復元条件を満たすとは証明できない。

押さえておきたいこと

#

実験結果についての疑問

#

先頭の単語が同じなら、そのカードを組み合わせてよいですか？

#

先頭語の一致で確認できるのは、付随する識別情報の一部までです。シェア全体の検証、復元の成功、目的のウォレットに必要な条件の確認に代わるものではありません。今回、先頭語が同じになるよう作った混在例は、単語列の読み取りを通過した後、復元時の整合性検査で拒否されました。

3枚を渡すと拒否されるなら、1枚は捨てるべきですか？

#

捨ててはいけません。今回使ったプログラムの復元関数が求める入力条件の話です。2枚を選ぶ3通りの組み合わせは、すべて成功しました。復元情報を廃棄する理由にも、実際の端末画面が同じ動作をすると考える根拠にもなりません。

この実験で、相続の準備もできたことになりますか？

#

なりません。公開テストデータを、一つの実装で確認した実験です。必要な材料を誰が見つけて使えるか、法的な権限があるか、保有者の死亡後も運用を続けられるかは確認していません。

出典と保存版

#

実装リポジトリの保存版は、機密情報を扱う際の警告を裏付けるものである。今回の実験で固定した版そのものの保存版ではない。実験に使った版と各ファイルの照合値は、再現用一式に含めた。