暗号資産ユーザー向けのセキュリティ助言の多くは、目に見える面に焦点を当てます。シードフレーズ、タップするリンク、サインインするサイトです。それらは重要です。しかし、その下にはより静かなリスクが横たわっています——ソフトウェアそのものと、それが何から作られたかです。ウォレットは完璧に書かれていても、なおバックドアを出荷しうるのです。現代のアプリは数百もの第三者製の部品と、ソースコードを、あなたがインストールするバイナリへと変えるビルドパイプラインから組み立てられるからです。その連鎖のどの環を侵害しても、下流のすべてのユーザーを侵害してしまいます。
これがソフトウェアのサプライチェーンであり、攻撃者はそれが暗号資産における最もレバレッジの高い標的の一つだと学びました。本記事は、サプライチェーン攻撃とは実際に何か、なぜウォレットがこれほど魅力的な標的なのか、実践で持ちこたえる防御、そして決定論的ビルドが何をもたらすか——SSP がこれらをどう適用しているかを含めて——を解説します。
サプライチェーン攻撃とは
サプライチェーン攻撃は、アプリケーションに直接侵入しません。代わりに、アプリが信頼している何か——取り込む依存関係、メンテナのアカウント、あるいは最終成果物を組み立てるビルドパイプライン——を侵害します。悪意あるコードは正規のアップデートに紛れて入り込み、署名され通常の経路で配布されるため、まさにあなたがインストールしようとしたソフトウェアそのものに見えます。
その間接性こそが要点です。広く使われる一つのライブラリ——あるいは一台のビルドサーバー——を攻撃するだけで、下流の数千のプロジェクトと数百万のユーザーに一度に届きます。暗号資産ウォレットにとって見返りは直接的です。ウォレット内で動くコードは、すでに肝心の瞬間——取引が署名され、アドレスが表示される瞬間——にアクセスできます。改ざんされた一つの依存関係は、フィッシングや脆弱なシードフレーズの衛生であなたに触れることなく、宛先アドレスをすり替えたり鍵素材を外部へ送り出したりできます。だからこそ、この種の攻撃はあなたの思考モデルに一席を占めるに値するのです。
身近に迫る二つの事例
二つの実例が、これがどう展開するかを示します——一つは暗号資産を真正面から狙ったもの、もう一つはインターネット全体をあやうく直撃しかけたものです。
event-stream と Copay ウォレット
2018 年、event-stream という人気の npm パッケージが、手伝いを申し出た新しいボランティアのメンテナへ引き継がれました。それは、オープンソースで絶えず起きている類の、型どおりで善意に見える引き継ぎでした。その後、新メンテナは難読化された悪意あるコードを含む新しい依存関係 flatmap-stream を追加しました。
ペイロードは異例なほど標的を絞っていました。全員に対して発火するのではなく、特定の下流プロジェクト——Copay ビットコインウォレット——の内部でのみ起動しました。そこでは、そのアプリのユーザーのシード素材と資金を盗むよう仕立てられていました。event-stream を取り込んだ開発者の大半は一度も影響を受けませんでした——コードは自分が探す被害者を正確に知っていたのです。
これは「小さなライブラリを一つ入れただけ」が決して話の全部ではない、という典型的な戒めです。あなたはそのライブラリが信頼するすべても一緒に入れたのです。
XZ Utils のバックドア
2024 年の XZ Utils 事件（CVE-2024-3094）は、さらに忍耐強いものでした。XZ Utils は、ほとんどの Linux システムに静かに存在する圧縮ライブラリです。数年がかりで、攻撃者は親切な貢献者として信頼を積み上げ、少しずつメンテナの責務を得て、やがて OpenSSH——世界中のサーバーへのリモートログインを守るソフトウェア——を妨害するよう設計されたバックドアを忍び込ませました。
それはほとんど偶然に、コンマ数秒の遅延に気づいた一人のエンジニアによって捕捉されました。広く配布されていれば、無数のマシンへのリモートアクセスを明け渡しかねませんでした。
暗号資産にとっての教訓は厳しいものです。この攻撃は巧妙なバグを突いたのではなく、オープンソースの信頼モデルそのものを突き、数年に及ぶソーシャルエンジニアリングを演じて、誰もが頼る人物になりすましたのです。
実際に効く防御
単一の対策でサプライチェーン攻撃を止められるものはありません。効くのはそれらを積み重ねた層で、各層が攻撃者の選択肢を狭めます。
- 固定された依存関係とロックファイル。 正確なバージョンを固定し、ロックファイルをバージョン管理に入れることは、ビルドが新しい改ざん済みリリースを黙って引き込めない、という意味です。アップデートは自動ではなく、意図的で精査可能な出来事になります。
- 最小限の依存関係。 追加するパッケージはどれも、あなたが信頼する相手です。依存が少ないほど攻撃面は小さくなり、侵害されうるメンテナも減ります。
- 依存関係のサンドボックス化。 LavaMoat のようなツールは、各パッケージが実行時に何をできるかを制限し、侵害された依存関係がネットワークや機微な API へ自由に到達できないようにします。
- コード署名。 署名されたリリースにより、ユーザーはバイナリが本物の発行者から来たもので、転送中に改変されていないことを検証できます。
- 第三者監査。 独立したセキュリティ企業が敵対者の目でコードと依存関係を精査し、内部チームが当たり前と見なすものを捉えます。
- 再現可能な、決定論的ビルド。 最も強力な構造的防御であり、詳しく理解する価値のあるものです。
決定論的ビルドの解説
通常、同じソースから二度ビルドすると、わずかに異なる二つのバイナリが生まれることがあります——タイムスタンプ、ファイルの並び順、ビルドマシンの細部が紛れ込むのです。この揺らぎは問題です。無害な差異と悪意ある差異を見分けられない、という意味だからです。
決定論的（または再現可能な）ビルドは、その揺らぎを取り除きます。同じソースコードであれば、誰でも、どこでも、どのマシンでも、バイト単位で同一の成果物を生み出します。その含意は強力です���独立した人々が公開ソースからウォレットを再ビルドし、あなたがダウンロードしたバイナリがソースの生み出すものとビット単位で一致することを確認できるのです。攻撃者がビルドパイプラインを改ざんしたり、後から何かを忍ばせたりしていれば、ハッシュは一致せず、改ざんはただちに可視化されます。
これは信頼モデルを反転させます。もはや発行者の言葉を鵜呑みにする必要はありません。検証は、コミュニティ全体が実施し相互に突き合わせられるものになります。Reproducible Builds プロジェクトはこの実践をエコシステム全体にわたって文書化しており、SLSA のようなフレームワークは、あなたがプロジェクトに求めうるビルド完全性の保証レベルを定義しています。
SSP はこれをどう適用しているか
SSP はビルドパイプラインを、後付けではなく脅威モデルの一部として扱います。ウォレットは Dockerfile 優先の決定論的ビルドで配布されます。Docker で定義された同じ環境が毎回同じ成果物を生み出すため、公開されたリリースは公開ソースから再ビルドし、あなたがダウンロードしたものとビット単位で照合できます。SSP はさらに Halborn による独立したセキュリティレビューを受けており、その監査はコードと、それが依拠する依存関係の両方を精査します。
SSP の作られ方に固有の、ここで効いてくる層がもう一つあります。SSP は 2-of-2 のマルチシグウォレットです。あらゆる取引には、別個のデバイス上にある第二の鍵、SSP Key からの独立した承認が必要です。それが何をして何をしないかは、正確に捉えてください。決定論的ビルドと監査は、改ざんされたビルドがそもそも配布される確率を下げます——それらは最前線です。しかし最悪の場合でも——何らかの形ですり抜けたビルドでも——第二の鍵は別個の承認面として、依然としてあらゆる取引に署名しなければなりません。
それは魔法の盾ではなく、侵害されたビルドを許容できるものにするわけでもありません。ただ、一台のデバイス上の改ざんされた単一の構成要素が、それ単独であなたの資金を動かすことはない、という意味です。多層防御こそが要点です。
あなた自身で確認できること
これらすべての恩恵を受けるのに、セキュリティエンジニアである必要はありません。いくつかの習慣が大きな差を生みます。
- 公式の入手元からのみダウンロードする。 ウォレットは公式サイトやストアの掲載から入手し、メッセージ内のリンクや検索広告からは決して入手しないこと。これはブラウザ拡張機能の衛生で扱うのと同じ規律です。
- 決定論的ビルドと監査を公開するプロジェクトを優先する。 リリースをコミュニティに検証させ、独立したレビューに費用を払うプロジェクトは、その考え方について何かを物語っています。
- 署名とハッシュが提供されたら検証する。 リリースに署名やチェックサムが付いているなら、一分かけて照合しましょう。再現可能なビルドは、誰かが実際に突き合わせて初めてあなたを守ります。
- 全体の opsec を引き締めておく。 サプライチェーンの防御はより大きな絵の中にあります。どの一層もすべての重みを背負わずに済むよう、opsec チェックリストを定期的に通しましょう。
これらのいずれも、単一の相手を信頼することを求めません。それこそ、自己保管ソフトウェアにあなたが求める性質です。
さらに先へ
ウォレットは、それを作り上げた連鎖の分だけしか信頼できません。良い知らせは、これがきれいで構造的な答えを持つ数少ないセキュリティ問題の一つだということです。決定論的ビルドに独立した監査を加えれば、「私たちを信じて」は「自分で検証して」に変わります。
フィッシングへの意識、シードフレーズのベストプラクティス、ブラウザ拡張機能の衛生、そして定期的な opsec チェックリストで、防御を築き続けてください。それぞれが一つの扉を閉じ、合わさってはじめて、自己保管のセキュリティが本当はどう見えるかを形づくります。
