ハードニング導出

BIP-32のツリーのすべてのノードは4,294,967,296個の子ノードを生成でき、その範囲の上半分は異なる動作をします。2,147,483,648以降のインデックスはハードニングされており、アポストロフィまたは文字hを付けて表記し、どの公開鍵もそれらを導出できません。この制約は欠点ではなく、利点です。

仕組み

ハードニングされた導出と通常の導出は、同じハッシュへの1つの入力だけが異なります。どちらも親のチェーンコードと子インデックスをHMAC-SHA512に入力します。通常の導出では親の公開鍵を加えますが、これは拡張公開鍵を保有する者なら誰でもすでに持っています。ハードニングされた導出では代わりに親の秘密鍵を加え、その先頭にゼロバイトを付けます。そのため、秘密を知らなければこの計算を行うことはできません。

その理由は、BIP-32がセキュリティに関する注記で明記している特定の弱点にあります。親の拡張公開鍵と、そこから派生したハードニングされていない秘密鍵のいずれかを知ることは、親の拡張秘密鍵、ひいてはその地点より下のすべての鍵を知ることと同じです。その背後にある計算は単純です。通常の子秘密鍵は親の鍵に公開情報から計算した値を加えたものに等しいため、その値を差し引けば親の鍵を復元できます。

ハードニングされたインデックスはこの経路を塞ぎます。それらに対する公開導出関数は存在しないため、拡張公開鍵はその境界で完全に止まります。ある口座のxpubが漏えいしても、その口座の履歴が露出するだけで、それより上や横のものは露出しません。

どこで目にするか

ハードニングは導出パスの中のアポストロフィとして現れ、それがどこに付くかは意図的な設計上の判断です。

標準的なネイティブSegWitのパスはm/84'/0'/0'/0/0です。最初の3つの階層、目的、コインタイプ、口座はハードニングされています。最後の2つ、チェーンとアドレスインデックスはハードニングされていません。この分割こそがウォッチオンリーウォレットを実用的にするものです。口座の拡張公開鍵はその下にあるすべての受取アドレスとお釣りアドレスを生成できる一方、同じxpubを入手した攻撃者はマスター鍵へさかのぼることも、m/84'/0'/1'へ横に移ることもできません。

表記は変わっても内容は変わりません。BIP-32は0'と表記し、多くのツールは0hを受け付け、Bitcoin Coreはエクスポートする記述子でhと表記します。JSONの中ではアポストロフィをエスケープする必要があるためです。SparrowからCoreへコピーしたパスはhの形式に書き換えられて戻ってきます。これは初めて見ると驚かされますが、見た目だけの問題です。

実務上のルールは短いものです。口座までのすべての階層をハードニングし、その下の2つの階層はウォッチオンリーのツールが機能し続けるようハードニングせずに残し、ハードニングされていない子秘密鍵を1つエクスポートさせようとするソフトウェアは便利な機能ではなく危険とみなしてください。そのエクスポートとあなたのxpubを組み合わせれば、その枝全体が手に入るからです。

ハードニングされた導出vsパスフレーズ

ハードニングされた導出は自動です。BIP-39のパスフレーズは自分で選ぶ秘密です。両者はウォレットを強化する方法としてまとめて語られますが、無関係な問題に対処するものです。ハードニングは漏えいした拡張公開鍵からツリーを守るもので、標準的なウォレットはすでにあなたに尋ねることなく適用しています。パスフレーズはツリーを構築する前にシードへ混ぜ込む追加の入力で、同じ12語または24語からまったく別のウォレットを生成します。パスフレーズを忘れると、どこにも記録されていないため、コインには到達できません。ハードニングのことを忘れても何も起こりません。それを決めていたのはあなたではなかったからです。