Cryptoセキュリティ、まだ見落とされている「信頼の盲点」とは？

執筆：imToken

純正チップを搭載し、ファームウェアも正規品で、公式の正規品認証（Genuine Check）さえ問題なく通過するハードウェアウォレットなのに、その中の資産がハッカーに盗まれる可能性がある？

最近のLedgerセキュリティインシデントは、まさにこの一見ありえないリスクを露呈させた。

Ledgerセキュリティチームが後に開示した調査結果によると、攻撃者は該当デバイスの内部に悪意ある回路を追加で植え込み、それが画面に表示されるリカバリーフレーズを傍受し、モバイル通信ネットワークを通じて攻撃者に送信できるようにしていた。

言い換えれば、純正セキュリティチップは突破されておらず、リカバリーフレーズが初めて画面に表示された時点で、すでにハッカーの手に渡っている可能性があるのだ。

しかも、これは最近注目すべき唯一のセキュリティインシデントではない。

9月以来、Bitgetが第三者セキュリティ製品の脆弱性を悪用された事例から、TrezorのメールサービスプロバイダーであるBrevoが侵入された事例、さらにはMetaMaskの一部インフラでセキュリティ問題が発生した事例まで、一連の出来事は私たちにこう警告している。Crypto製品がますます複雑になるにつれて、セキュリティはもはや秘密鍵を守り、スマートコントラクトの脆弱性を避けるだけでは済まなくなっている。

デバイスの流通、第三者サービス、内部権限、ユーザー通信の中に潜むリスクもまた、攻撃者が突破口を探す対象になり得るのだ。

1. Ledgerが鳴らした「サプライチェーンセキュリティ」の新たな警鐘

まずはLedgerの今回の事例を分解してみよう。

普段ハードウェアウォレットを買う際に警戒するのは、突き詰めれば二つのことだ。偽物を買ってしまうこと、あるいは事前に初期化されたデバイスを受け取ってしまうこと。

かつて最もよく見られた手口は、悪意ある仲介業者がリカバリーフレーズを先に生成し、スクラッチカードに印刷してパッケージに戻し、ルールを知らない初心者ユーザーがそのまま入金してしまうことに賭けるというものだった。

こうした詐欺は危険ではあるものの、防御の論理は非常に明確だ。正規のチャネルで購入し、デバイスの状態を確認し、デバイス自身が新しいリカバリーフレーズを生成するのを見届け、箱に入っている既成のリカバリーフレーズは絶対に使わない。

しかし今回のLedgerに対する攻撃は、明らかに一段階上の手段だった。ハッカーは筐体内部にマイクロコントローラー、eSIM、セルラー通信機能を備えた電子モジュールを追加で仕込み、ユーザーが初めてウォレットを初期化する際には必ず画面からリカバリーフレーズを読み取って書き写す必要がある。

言い換えれば、植え込まれた悪意ある回路はリカバリーフレーズの生成過程には一切干渉せず、ただリカバリーフレーズを監視して直接送信しているだけだ。これが「秘密鍵がセキュリティチップから直接抽出されなかった」ことが、ユーザーのウォレット復元情報が依然として安全であることを意味しない理由である。

さらに厄介なのは、デバイスが公式のGenuine Check正規品認証を通過したとしても、この追加搭載されたハードウェアを識別できるとは限らないことだ。正規品認証は主にセキュリティチップの身元とファームウェアの信頼性を確認するものだからである。

したがって今回の事件は、日常的に見落とされがちな重大な「サプライチェーンリスク」を確かに露呈させた。ハードウェアウォレットのセキュリティは、チップとファームウェアだけでなく、工場出荷からユーザーの手元に届くまでの納品プロセス全体にも依存する。

そもそも一台のデバイスは、地域販売代理店、第三者倉庫、物流、小売業者など複数の段階を経る必要があり、実際にデバイスに触れる機会を持つあらゆる関係者が、追加で評価すべきリスクポイントになり得るのだ。

2. TrezorからBitgetまで：攻撃者はどうやって中核のセキュリティ防衛線を迂回するのか？

Ledgerの問題を理解した上で、最近BitgetやTrezorが相次いで遭遇したセキュリティインシデントを見ると、その根底にある論理が驚くほど似ていることに気づく。攻撃者は同じように最も堅固な正面の防衛線を避け、外縁の「第三者サービス」から切り込んできたのだ。

まずTrezorを見てみよう。

9月初旬、一部のTrezorユーザーに「Critical Security Alert: STM32 Entropy Vulnerability」という件名のメールが届き、ハードウェアウォレットに重大なセキュリティ脆弱性が発生したとして、直ちに対処する必要があると主張した。

こうしたメールはユーザーを容易に緊張させる。何しろハードウェアウォレットとセキュリティ脆弱性に関わる話であり、自分の資産がそれによって損失を受けることを望む人はいない。

これはまさに、攻撃者がTrezorの利用する第三者メールマーケティングプラットフォームBrevoを悪用し、悪意あるコンテンツを正常なメール送信インフラを通じてユーザーのメールボックスに届けたものだった。

Brevoの後の事故報告によると、攻撃者はそのシングルサインオンシステムの権限境界の欠陥を利用して、他の顧客アカウントへの未承認アクセス権を取得し、最終的に138の顧客アカウントが関与、その一部がフィッシングメールの送信や連絡先データのエクスポートに使用された。

Trezorはその後、347,149件のマーケティングメール連絡先アドレスが事件でエクスポートされたことを確認し、攻撃メールはユーザーに悪意あるアプリをダウンロードさせ、ウォレットのバックアップ情報を入力させようと企図していた。

注意すべきは、この事件でTrezorのハードウェアウォレットや秘密鍵保護システムが突破されたことを示す証拠はなく、攻撃者がまず獲得したのはユーザー情報と公式通信チャネルの濫用能力だったという点である。

しかしメールを受け取った一般ユーザーにとっては、リスクの識別がかえって難しくなる。なぜならメールは見慣れた公式ドメインから送信されている可能性があり、正常なメール認証チェックも通過できるのに、内容はすでに攻撃者によってフィッシング情報に差し替えられているからだ。

もしユーザーがこれによって自らリカバリーフレーズを入力してしまえば、本来は第三者メールサービスの問題に過ぎなかったものが、さらに実際の資産損失へと発展する可能性がある。

次にBitgetを見てみよう。

9月24日、Bitgetの一部ホットウォレットとウォームウォレットで未承認の資産流出が発生し、最終的に約3億8,800万ドル相当が関与していたことが確認された。

Bitget公式が公表した調査結果によると、攻撃者は第三者セキュリティ製品の脆弱性を利用して取引所内部の高権限認証情報を取得し、その後ウォレット関連のバックエンドシステムに侵入、出金指示を偽造して既存のリスク管理チェックを迂回し、異常な送金を正常な実行フローに乗せた。

Bitgetは今回の事件で秘密鍵の漏洩は確認されておらず、コールドウォレットも影響を受けていないと述べているが、これは一見矛盾しているように聞こえる。秘密鍵が盗まれていないのに、なぜ資金が移動できてしまうのか？

実は理解は難しくない。

取引所のようなカストディアル型プラットフォームでは、ユーザーが出金を開始した後、毎回必ずしも人間が秘密鍵を持って一件ずつ署名するわけではなく、アカウント検証、リスク管理審査、取引生成、ウォレット署名といった一連の内部フローを経る必要がある。

これは銀行の金庫のようなものだ。たとえ金庫の鍵が非常に厳重に保管されていても、誰かが内部の高権限身元を詐称でき、承認を通過した送金指示を偽造できれば、金庫内の資金は依然として誤って送金される可能性がある。

Bitgetが今回露呈したのは、まさに上流の権限と指示検証が失守した後、リスクがいかにして資産実行システムへとさらに伝播するかということであり、したがって「秘密鍵が漏洩していない」ことと「資金が不正に送金されない」ことは、実は別問題なのである。

9月末にMetaMaskが開示したインフラセキュリティインシデントは、また別の次元の運用リスクを呈している。

当時MetaMaskは予防措置として、影響を受けた一部のステーキングバリデータから自主的に退出した。公式の10月1日の調査アップデートによると、MetaMaskウォレットや顧客資金が影響を受けた兆候はまだ確認されておらず、関連するステーキング業務も顧客の代わりに引き出し鍵を管理することはない。

ただし、これはインフラに問題が生じても他の影響が出ないという意味ではない。ノンカストディアルが主に解決するのは資産のコントロール権の問題であり、外部インフラの運用リスクを自動的に消し去ることはできない。

これらの出来事を合わせて見ると、脉络は実に非常に明確だ：

• Ledgerが露呈したのはハードウェア流通段階における物理的改ざんリスクであり、最終的にリカバリーフレーズが窃取される可能性がある；
• Trezor / Brevoが露呈したのはユーザー情報の漏洩と公式通信チャネルの濫用リスクであり、ウォレット自体が突破されたこととは異なる；
• Bitgetが露呈したのは第三者製品の脆弱性が内部高権限システムへ伝播するリスクであり、資金執行に直接影響を与え得る；
• MetaMaskは、資産のコントロール権とサービス運用リスクは同じ概念ではないことを私たちに思い起こさせる。

総じて、今日のCrypto製品はもはや孤立した島ではない。

ウォレットは外部のRPCノードに依存してオンチェーンデータを読み取り、集約インターフェースに依存して相場を取得する。取引所は外部のセキュリティ監視、KYC認証、リスク管理コンポーネントを欠かせない。さらに外へ延びれば、ノード運営者、クラウドプロバイダー、カスタマーサポートのチケット、そしてBrevoのようなメールシステムもある。

これらの外部サービスは製品をより効率的に稼働させ、ユーザー体験も改善するが、同時に新たな外部依存を導入するたびに、製品は管理すべき信頼関係を一層増やすことになる：

第三者は何にアクセスでき、どれほどの権限を持ち、それが一旦失守した場合、リスクが他の核心システムへさらに伝播するかどうか？

3. 製品とユーザーはどう防ぐべきか？

ますます複雑化する第三者依存リスク、そして連鎖する依存関係に直面して、製品チームが「いかなる外部サービスも利用しない」原始状態に戻ることを期待するのは明らかに非現実的であり、市場の法則にも合わない。

真にセキュリティアーキテクチャの力量が試されるのは、あらゆる可能なリスクエクスポージャーを可能な限り縮小することだ。

例えば、マーケティングメールの送信だけを担当するSaaSサービスプロバイダーが、なぜ長期間にわたって全ユーザーの連絡先データを保持するのか？第三者セキュリティ監視ツールが、なぜ独立した多重承認なしに核心的な本番環境にアクセスできるのか？特に資金移動に関わる敏感な操作では、内部システム間で「デフォルト信頼」を決して行ってはならず、厳格な権限分離と独立したクロス検証を必須とすべきだ。

これがセキュリティアーキテクチャでよく言われる「最小権限」と「職務分離」でもある。メール送信プラットフォームはメール送信に必要な権限だけを持つべきであり、セキュリティ監視ツールは勝手に資金移動を実行すべきではなく、大口出金も単にどこかの内部システムから送られた指示だけでそのまま通してはならない。

そしてLedgerの事件は、ハードウェアウォレットメーカーに対し、安全管理が製品の物理的流通段階にまで延びる必要があることをさらに思い起こさせる。

工場出荷、倉庫保管、物流から販売代理店の納品に至るまで、追跡可能な管理プロセスをどう構築するか、デバイスの異常な分解・組立や交換をどう発見するか、そして問題発生後に影響を受けたロットとユーザーをどう特定するかは、いずれも単なるチャネル管理業務として扱うべきではない。

なぜなら、秘密鍵を保護するハードウェアデバイスにとって、納品プロセスそのものがセキュリティ体系の一部だからである。

もちろん、一般ユーザーとしては、ウォレットのソフトウェアサプライチェーンを監査することもできなければ、ハードウェアウォレットの倉庫保管や物流の各段階を逐一調査することもできない。

しかし、それはただ受動的にリスクを負うしかないという意味ではない。少なくともいくつかのことは、日常使用の中で習慣化する価値がある。

まず、ハードウェアウォレット購入過程における不必要な中継をできるだけ減らすこと。

条件が許せば、ブランド公式サイトでの注文、工場または公式倉庫からの直接発送を優先すれば、通常はデバイスが工場の管理を離れた後に第三者に接触、分解・組立、すり替えられる機会を減らすことができる。

リスク管理の観点から見れば、デバイスに触れる独立した主体が多ければ多いほど、追加で信頼しなければならない段階も増える。また、デバイス到着後も、梱包や外観の異常を確認し、公式ソフトウェアで検証を完了し、初期化フローを厳守すべきだ。

次に、「公式メッセージ」が信頼できるかどうかを改めて理解する必要がある。

Trezorの事件はすでに、メールが確かに公式が利用するサービスプラットフォームを通じて送信され