4章_ウォレット
概要
クッキートークンはセキュアになってきているが、ユーザーの利便性はむしろ悪化している。
ウォレットというモバイルアプリを作ってクッキートークンを利用するためのタスクを肩代わりさせよう。
また秘密鍵のバックアップも行う方法を紹介する(多層的決定性ウォレット)。
4.1 ウォレットの最初のバージョン
ウォレットにさせるタスク
新アドレス作成
秘密鍵の管理
受領者から送金者への支払い詳細の送信
支払いの実行
残高の管理
秘密鍵のバックアップ
ウォレットでの支払い例
カフェが支払い用のアドレスと支払額を含むQRコードを生成する
ジョン(購入者)はウォレットアプリでQRコードを読み込み、支払いを承認する
ウォレットが支払い情報を持ったメールをリサ(管理者)に送信する
リサが前章までに記載した購入処理を行う
ウォレットはスプレッドシートを常に監視し、処理が正常に行われていることを確認してアプリに反映させる。
4.2 秘密鍵のバックアップ
ウォレットには複数の秘密鍵が含まれる。これらのバックアップを行いたい。どうするべきか？
秘密鍵をすべて書いたテキストファイルを自分のメールアドレスに送信する
メールサーバーに預けることで漏洩のリスクを持つ
秘密鍵を作るたびにバックアップをしなければならず、面倒
改善案
あらかじめ大量の秘密鍵を作っておき、まとめてバックアップしておくことで面倒を防ぐ
バックアップファイルを暗号化する
管理するものが増えてしまう(バックアップファイル、パスワード)
パスワード忘れの可能性がある
技術の発展によりパスワードが破られるリスク
ランダムなパスワードを作ることは難しく、覚えるのも困難
4.3 階層的決定性ウォレット
親となる秘密鍵(マスター拡張秘密鍵)を作り、その秘密鍵を使って階層的に秘密鍵を作れる
マスター拡張秘密鍵(を作る128ビットのランダムシード)のみバックアップしておけばすべての鍵を復元できる
細かい仕組みは画像が多いので省略 (長安)
4.4 バックアップの話にカムバック
ランダムシードを保管しておけば問題ないが、ランダム文字列はタイプミスなどの可能性もある
人間工学的にもっと適しているシンプルな方法に変更する。
4.4.1 ニーモニック文
シードを2048種類の自然言語による単語群に変換する。
4.4.2 シードのニーモニック文への符号化
シード 128bit+ チェックサム4bitを12個の11bitに変換
11bit = 2048種類の一般的な語句に、対応表に基づいて変換
12個の単語リストができる
バックアップ時はこれを保存しておけば良い。
ニーモニック文からの復元は逆変換すれば良い。
4.5 拡張公開鍵
拡張秘密鍵を複製して保持すると、漏洩した場合にその秘密鍵に紐づくすべての秘密鍵が漏洩してしまう。
秘密鍵がなくても公開鍵(とチェーンコード)で鍵の木構造は作れる = 拡張公開鍵。
こちらも細かい仕組みは画像が多いので省略 (長安)
4.6 ハードニングされた秘密鍵の生成
親の公開鍵と、その下位の秘密鍵が漏洩することで、それ以降の秘密鍵を計算できてしまう。
下位の鍵の生成に公開鍵ではなく秘密鍵をハッシングする( = ハードニング)ことで計算されてしまうことを防ぐ。
細かい仕組みは(略) (長安)
4.7 公開鍵の数学的操作