Webで実行したSSSが危険な理由｜安全な秘密分散の実装2選

シードフレーズを3枚に分割した。1枚だけでは何も分からない。2枚揃わないと復元できない。これで完璧だと思った。

問題は、その実行にWebサイトを使ったことだ。

シャミアの秘密分散法は数学的に完璧だ

1979年、暗号学者アディ・シャミアが発表したシャミアの秘密分散法（Shamir’s Secret Sharing、SSS）は、数学的に証明された安全性を持つ。「k枚のシェアが揃わない限り、秘密情報は1ビットも漏れない」という保証だ。

たとえば3枚に分割して「2枚で復元」と設定した場合、1枚しか持たない攻撃者には秘密の内容がゼロ情報になる。これは確率論的な話ではなく、多項式補間を使った数学的証明に裏打ちされた保証である。

だからこそ多くのビットコイン保有者がSSSに安心感を覚える。しかしその安心感が正当かどうかは、数学の強さではなく実行環境の安全性によって決まる。

Web検索でツールを探すとき、何が起きているか

「shamir secret sharing tool」でWeb検索すると、UIが整ったサービスが複数表示される。使い方は簡単だ。シードフレーズを入力し、シェア数と閾値を選んで「分割」ボタンを押す。3枚のシェアが画面に現れる。

この操作を完了した時点で、シードがサーバーに届いていた可能性がある。

ブラウザを経由したデータがどこへ行くかは、ソースコードを精査しない限り確認できない。「このサイトはクライアントサイドのみで動作します」という表示は、信頼のための宣言であって技術的な保証ではない。難読化されたJavaScriptが実際に何をしているか、一般ユーザーが検証することは現実的でない。

シードを入力した時点で、SSSの数学的安全性は既に消えている。あの数学が守るのは「シェアが揃わない状態」であり、シード原文がどこかに渡った後の話ではないからだ。

数学の強さと実装の弱さは別問題だ

セキュリティの世界に「アルゴリズムの強さは実装の弱さを補わない」という原則がある。256ビットの暗号強度を持つシステムも、秘密鍵をプレーンテキストでログに書き出せばその強度はゼロになる。

Webサイトでのシード入力は、この構造の失敗だ。SSSが保証するのは「シェアk枚未満からは情報が漏れない」という数学的条件であり、入力時点でのデータ保護は前提にない。

取引所にシードを預けているのと本質的に何が違うか。どちらも「他者のシステムへの信頼」を前提にしている。秘密鍵の管理権を自分の手に取り戻すというセルフカストディの目的と、根本的に矛盾している。

安全なSSS実装は2つしかない

現時点で実用的な安全なSSS実装は、以下の2つに絞られる。

Trezor Model TのSLIP-39実装は、シード分割の全工程をハードウォレット内部で処理する。シードフレーズがデバイス外のデジタル環境に出ることなく、シェアを生成して書き出す設計だ。ネットワーク接触という問題が構造的に発生しない。

エアギャップ環境上のCodex32は、完全にオフラインで計算を行う仕様だ。Codex32の計算は紙とペンでも実施できる設計になっており、電子機器を一切介在させないことでネットワーク経由の流出を原理的に排除する。

どちらにも共通するのは「シードが暗号化されていない状態でネットワークに触れない」という原則だ。Webサイトという選択肢は、この原則の入り口で既に脱落する。

「オフライン動作」という主張を検証する方法

Web検索で見つかるSSSツールの中には「完全オフライン動作」「クライアントサイドのみ」を標榜するものがある。この主張を技術的に検証できるかと問われると、多くの人は「できない」と答えるだろう。

コードのハッシュ値を確認してソースコードの改ざんがないか検証できるか。難読化されていないJavaScriptを実際に読んで動作を追えるか。その答えが「分からない」であれば、そのツールでシードを処理すべきではない。

ビットコインのセルフカストディにおいて「信頼する」という行為は脆弱性だ。「このサイトは安全だと思う」という感覚的な判断の上に、回復不可能な資産を置いてはいけない。シードを分割する前に確認すべきことは一つだ。その実行環境が、技術的にネットワーク接触を排除しているかどうか。分割作業を始める前に、まずその問いに答えてほしい。

※本記事は一般的な情報提供を目的としており、投資助言ではありません。