研究。鍵の導出
BIP32の非ハードニング型親キーのエスカレーション
BIP32にはあまり知られていない特性があり、xpubと単一の非ハードened子プライベートキーを組み合わせることで、親キーが特定されてしまう可能性があります。これは真のリスクであると同時に、所有者にとっては復旧手段ともなります。
BIP32階層型決定論的ウォレットは、1つのシードから鍵のツリー全体を生成します。多くの人は、このツリーが親から子へと下方向に流れることを知っています。しかし、特定の条件下では上方向に遡ることができることを知っている人はあまりいません。このページでは、非ハードニングされたエスカレーション特性について、その定義、セキュリティ上の重要性、およびウォレットの復旧にどのように役立つかを解説します。
HDの導出の仕組み
BIP32ウォレットでは、各鍵は、親鍵とチェーンコード、およびインデックスを組み合わせた一方向関数を介して子鍵を導出します。これには2つの方式があります。1つは、親の秘密鍵を必要とする「ハードened導出」（インデックスが2³¹を超えるもの）であり、もう1つは、親の公開鍵から実行できる「非ハードened導出」です。 非ハードened導出こそがxpubの有用性を支える要素であり、ウォッチオンリーサーバーは、秘密鍵を一切保持することなく、新しい受信アドレスを生成することができます。
エスカレーションプロパティ
ここが重要なポイントです。非ハードニング化された導出の場合、親の公開鍵（xpub）もわかっていれば、子プライベートキーとその親との間の関係は逆算可能です。具体的には、xpubと任意の1つの非ハードニング化された子プライベートキーが与えられれば、親のプライベートキーを計算することができ、そこからサブツリー全体を導き出すことができます。1つの子キーが漏洩し、かつxpubが公開されてしまえば、そのブランチは完全に侵害されたことになります。
なぜセキュリティ上のリスクとなるのか
これにより、一見安全に見える2つの要素が、危険な組み合わせとなってしまいます。会計処理や閲覧専用としてxpubを共有することは無害に思えますし、1つの子プライベートキーが漏洩しても、影響は1つのアドレスに限定された損失に過ぎないと感じられます。 しかし、これらが組み合わさると話は別です。xpubを保持する攻撃者が、強化されていない子鍵をたった1つ入手しただけで、親鍵へと遡り、そのアカウント内のすべてのアドレスから資金を抜き取ることが可能になります。これは、個々に見れば軽微な情報漏洩が組み合わさって完全な侵害につながるclassic であり、アカウント境界において「強化された導出」が存在する理由でもあります。
鍵の回収にどのように役立つか
自分が所有者であり、自身の資金を取り戻そうとしている場合、この特性はまさに「贈り物」となります。アカウントのxpubと、たとえ1つでも「ハードニング」されていない子プライベートキー（エクスポートされたキー1つ、あるいはまだ手元にある1つのアドレスのキーなど）を保有していれば、親キーとブランチ全体を再構築することができます。 一見無用に見える部分的かつ断片的な鍵データであっても、エスカレーションを通じてウォレット全体を再構築することが可能です。これにより、「古い秘密鍵が1つとxpubしか持っていない」という状況が、行き詰まりから完全な復旧へと変わるのです。
適用される場合
条件は明確です。導出は「非ハードened」でなければなりません（ハードenedされた子ノードでは親ノードに関する情報が一切明らかになりません）。また、親ノードの正しいxpubと、その直下にある真正な子の秘密鍵が必要です。多くのウォレットは、まさにこれを阻止するためにアカウントレベルでハードenedされた導出を採用しているため、この手法がどこでも適用できるわけではありません。しかし、ウォレットが非ハードenedされた導出を採用している場合、これは強力でありながら見過ごされがちな手法となります。
症例の評価
エスカレーションが適用されるかどうかを判断するには、ウォレットの導出スキーム（どのソフトウェアで作成されたか、また問題のブランチが強化されていたかどうか）を特定し、そのxpubが、自分が保有する子キーの親キーに確実に一致していることを確認する必要があります。数学的な処理は厳密であるため、これらの事実が一致すれば、再構築は決定論的になります。つまり、親キーが正しく導き出されるか、あるいは入力が一致しないかのいずれかとなり、その間に推測の余地は一切ありません。
身を守るために
セキュリティ上の教訓は単純です。xpubは「公開情報」ではなく「機密情報」として扱い、対応するxpubが誰かに知られている間は、個々の子秘密鍵を決して公開してはいけません。監視目的のみでxpubを共有せざるを得ない場合でも、その下位にある単一の、セキュリティ対策が施されていない子鍵が1つでも漏洩すれば、アカウント全体が危険にさらされることを理解してください。可能な限り、アカウント境界でセキュリティ対策が施されているウォレットを利用し、たとえxpubと子鍵が漏洩しても、それらが組み合わされて権限の昇格につながらないようにしてください。
具体的な例
ある会計士が、入金状況を追跡するために「閲覧専用」のxpubを受け取り、さらに数年前に少額の残高を引き出すために、別のアドレスの秘密鍵を個別にエクスポートしたと想像してみてください。個別にみれば、どちらも大した問題ではないように思えます――xpubからは鍵は明らかになりませんし、1つのアドレスの鍵は、そのアドレス1つだけのリスクに過ぎないからです。しかし、もしそのアドレスが共有xpubの「非ハード化」された子アドレスだった場合、この2つを組み合わせることで親鍵と、その下にあるすべてのアドレスが再構築されてしまいます。 攻撃者がこの組み合わせを悪用できるのと同じ計算原理により、メインのウォレットを失った後も両方の情報を保持している正当な所有者は、再びアクセス権を取り戻し、そのブランチ内のすべてを回復することができるのです。この特性が、なぜ危険であると同時に命綱でもあるのかを示す、最も明確な実例です。
当社のドキュメント
KeychainXは、実際の復旧作業において、非強化型の権限昇格手法を用いて断片的な鍵素材からウォレットを再構築してきました。この手法は、リスクとしてだけでなく、復旧ツールとしてもその重要性が十分に認識されていないため、ここでその詳細を記録しています。これは、Trezorの鍵導出に関するフォレンジック分析など、当社が取り組むより広範な鍵導出関連の研究の一環です。もしxpubと孤立した秘密鍵をお持ちの場合、それらが役に立たないと決めつけないでください。
よくある質問
どのような主要な資料が必要ですか？
理想的には、アカウントのxpubと、その直下に位置する少なくとも1つの非ハード化された子プライベートキーが必要です。これら2つがあれば、導出が非ハード化されている場合、親キーおよびそのブランチ全体を再構築することができます。
BIP32の非ハードニング・エスカレーションとは何ですか？
親の拡張公開鍵（xpub）と、任意の1つの非ハード化子公開鍵が与えられた場合、親の秘密鍵、ひいてはブランチ全体を計算できるという性質。
自分のXPUBを共有しても安全ですか？
必ずしもそうとは限りません。xpub自体は閲覧専用ですが、漏洩した非強化型の子秘密鍵と組み合わせると、親鍵およびそのアカウント内のすべてのアドレスが露見してしまいます。xpubは機密情報として扱ってください。
これは、私のウォレットの復旧にどのように役立つのでしょうか？
xpubと、非ハード化された子秘密鍵を1つでも所有していれば、親鍵とブランチ全体を再構築することができ、断片的な鍵素材から完全な復元が可能になります。
これは常に当てはまるのでしょうか？
いいえ。これには、ハードニングされていない派生アドレスと、それに対応するxpubが必要です。アカウントレベルでハードニングを行うウォレットではこれがブロックされるため、特定の設定でのみ適用されます。
回復にはどれくらいの費用がかかりますか？
成功報酬型：ウォレットの回収に成功した場合にのみ、回収額の一定割合を報酬としてお支払いいただき、前払いは一切不要です。
xpubと、どこからともなく現れた秘密鍵を保持しているのですか？
それらの断片から、エスカレーションによってウォレット全体を復元できる可能性があります。お手持ちの鍵情報を教えてください。24時間以内に正直な評価をお知らせします。