ハードウェアウォレットは長年、暗号資産を守るためのゴールドスタンダードと見なされてきました。秘密鍵をインターネットに接続された機器から切り離すことで、マルウェアやフィッシングをはじめとする多くの脅威を遮断できるためです。しかし最近の攻撃によって、このモデルに穴があることが明らかになりました。鍵がいかに厳重に守られていても、利用者が自分の署名する内容を把握できなければ、ほとんど防御になりません。
ProtectDevices
2025年2月のBybitのハッキング事件は、この問題をはっきりと示しました。北朝鮮のLazarus Groupは、BybitがEthereumのコールドウォレット管理に使っていたマルチシグ基盤Safe{Wallet}の開発者のマシンを侵害し、署名インターフェースに悪意あるコードを仕込みました。
Bybitの署名者の画面には、通常の送金と見える内容が表示されていました。ところが実際にハードウェアウォレットが署名したのは、ウォレットの基盤ロジックを変更し、制御権を攻撃者に渡す操作でした。盗まれたETHは約15億ドルに上り、当時の暗号資産窃取として過去最大となりました。
鍵そのものは抜き取られていません。デバイスは設計どおりに動作しました。ここから、業界にとって不都合な疑問が浮かびます。利用者が承認内容を独自に確認できないのであれば、コールドストレージはどこまで保護になるのでしょうか。
スマートコントラクトウォレットやマルチシグアカウント、複雑なオンチェーン操作が当たり前になるにつれ、答えは次の3つがそろって機能するかどうかにかかっています。透明性のあるソフトウェア、検証可能なハードウェア、そしてデバイス上で行うトランザクションの検証です。
コールドストレージだけでは不十分な理由
ハードウェアウォレットの役割は単純です。インターネットに接続するパソコンやスマートフォンから離れた専用デバイスで、秘密鍵を生成して保管します。トランザクションに署名が必要になると、接続されたアプリがデータをデバイスに送り、デバイスは内部で署名して、鍵を一切外に出さずに署名だけを返します。
この設計により、遠隔の攻撃者が鍵を盗むことは非常に困難になります。しかし、利用者が悪意あるトランザクションを承認してしまうことは防げません。ハードウェアウォレットは鍵を完全に隔離していても、資金を流出させる取引や、アカウントの権限を変更する取引、悪意あるコントラクトに資産へのアクセスを許可する取引に署名してしまう可能性があります。
ブラインドサイニングとは、ハードウェアウォレットが読み取れる形で表示できないトランザクションの承認を利用者に求める状態を指します。取引が何を実行するのかを明確に示す代わりに、生のコントラクトデータや不完全な情報が表示されます。Bybitの事例のように、接続されたパソコンの画面まで侵害されていれば、署名者は信頼できる形でトランザクションの内容を確認する手段をどこにも持てません。
Bybitは例外ではありません。2024年10月には、攻撃者が同様の手口でレンディングプロトコルのRadiant Capitalから約5,000万ドルを流出させました。3人の開発者のデバイスに入り込んだマルウェアが、Safeのインターフェース上に正当に見えるトランザクションを表示する一方で、ハードウェアウォレットはコントラクトの所有権を移転する取引に署名していました。署名者はそれぞれ、通常の操作だと信じて承認していたのです。
ProtectDevices
これは、ハードウェアウォレットが無効だという意味ではありません。オフラインでの鍵保管は、必要な対策の半分にすぎないということです。多額の資産やマルチシグアカウント、DAOの資金を管理する人にとって、もう半分である意図の検証も同じくらい重要です。
オープンソースが重要な理由
デバイスの内部で何が動いているのかという問題もあります。ほとんどの利用者は、ハードウェアウォレットがどう動作しているのかを知る手段を持ちません。安全なファームウェアの作成、適切な鍵の生成、物理部品が説明どおりに動くことの保証は、すべてメーカーを信頼するしかありません。
オープンソース開発は、その信頼の一部を「検証」に置き換えます。ファームウェアが公開されていれば、独立した研究者がコードを調べ、脆弱性を見つけ、修正案を提示できます。オープンソースハードウェアは同じ考え方を回路基板の設計や部品配置にまで広げており、技術力のある利用者が自分でデバイスを組み立てられる場合もあります。
ただし、透明性は安全性と同義ではありません。公開されたコードにもバグは含まれ得ますし、ハードウェア設計を公開しても、改ざんされた部品がサプライチェーンに紛れ込むことは防げません。独立した監査、安全な製造、継続的な保守は引き続き不可欠です。
コードを公開するだけでは、デバイスを検証可能にしたことにもなりません。再現可能なビルドは、この溝の一部を埋めます。誰でもソースからファームウェアをビルドし、その結果がメーカー出荷のバイナリと一致するかを確認できるからです。目指すのは、利用者に信じてもらうしかない安全性ではなく、調べて試せる安全性です。
信頼できるハードウェアウォレットの条件
単一の機能で決まるわけではありません。信頼できるデバイスは、複数の層を組み合わせています。
安全な鍵の生成と保管。鍵は保護された環境で作成され、その外に出てはなりません。セキュアエレメントは物理的な抽出攻撃への耐性をハードウェアレベルで高めますが、それだけでは保証できる範囲は限られます。実装のしかたや、周囲のハードウェア・ファームウェアとの連携も同じくらい重要です。
ファームウェアの透明性。ファームウェアは、デバイスが鍵をどう扱い、トランザクションをどう処理し、他の機器とどう通信するかを左右します。内容を検証できなければ、利用者はメーカーを信じるほかありません。公開されたソースコードは、ビルドと検証の手順が文書化されているときに最も効果を発揮します。
トランザクションの検証。最も見落とされがちな要件です。デバイスはトランザクションを受信したと確認するだけでなく、送金、トークンの承認、コントラクト呼び出し、アカウント権限の変更など、その取引が何を実行するのかを表示すべきです。
サプライチェーンの完全性。設計が優れたデバイスでも、部品のすり替えや製造時の改ざんによって、利用者に届く前に侵害される可能性があります。検証可能なハードウェアと製造管理は、ファームウェアのセキュリティと同じ土俵で議論されるべきです。
クリアサイニングとは
単純な送金なら、受取人と金額を表示するだけで済みます。しかしスマートコントラクトとのやり取りはそう簡単ではありません。1回のトランザクションに、トークンの承認、送金、コントラクト呼び出し、所有権の変更がまとめて含まれることがあり、マルチシグウォレットでは複数の操作を一括で処理することも日常的です。生のcalldataはほとんどの利用者にとって意味をなさず、経験豊富な開発者でも文脈なしには読み解くのに苦労します。
その代替策がクリアサイニングです。ハードウェアウォレットがトランザクションをデコードし、実際に何が行われるのかを自らの画面にわかりやすい言葉で表示します。重要なのは、この変換をどこで行うかです。パソコンやブラウザが侵害されていれば、そこに表示されるものは何も信頼できません。ハードウェアウォレットが独自にトランザクションを解釈し、何が起きるのかを自ら提示する必要があります。
業界ではこの標準化が始まっています。ERC-7730はLedgerが最初に提案した形式で、現在はEthereum Foundationが管理しています。開発者はコントラクトの関数をどう表示するかを記述でき、対応するウォレットなら生データの代わりに同じ読みやすい要約を表示できます。共通の形式を採用するウォレットやアプリが増えるほど、クリアサイニングは特定ベンダーへの依存から離れていきます。
デバイス上でのデコードがあらゆる攻撃を止めるわけではありません。見慣れないコントラクトや、悪意あるアプリケーションロジックが絡む攻撃は特にそうです。それでも署名者に、承認前に不審な点に気づく現実的な機会を与えます。Bybitの署名者に欠けていたのは、まさにそれでした。
Ambire Ice:実践例のひとつ
こうした考え方は、すでに新しいハードウェアの形になりつつあります。セルフカストディ型ウォレット開発元のAmbireは10月30日、AmbireとSafeのスマートアカウント向けに作られたオープンソースのハードウェアウォレット「Ambire Ice」を発表しました。TrezorやKeystoneなど、外部の人間がファームウェアを検証できるオープンソースの署名デバイスは数こそ少ないものの増えつつあり、Iceもその仲間に加わります。
Ambireは、Iceをオフライン鍵保管のデバイスとして前面に打ち出すのではなく、トランザクションの検証を中心に設計しました。デバイス自身がSafeのトランザクションを再構築して各アクションを画面に表示するため、署名者は承認前に送金、トークンの承認、一括処理の内容を確認できます。Safeの所有者、署名のしきい値、モジュールを変更する取引についても警告します。Ambireによると、未知のコントラクトへのDELEGATECALLは、許可リストに載っていない限りブロックされます。Bybitの攻撃で使われた種類の呼び出しを狙った対策です。
ハードウェア面では、NXPとInfineonのセキュアエレメントを組み合わせ、異なる種類の物理攻撃に備えています。物理スイッチを操作するとUSBデータが切断され、Bluetoothへの給電も止まります。これにより、アニメーションQRコードを使った完全オフラインでの署名が可能になります。USBやBluetoothも、使いたい人のために引き続き利用できます。ファームウェアはTrezorのオープンソースコードベースをフォークしたものです。Ambireによると、ハードウェア設計と基板ファイルは公開されており、透明な筐体により内部の部品を自分の目で確認できます。
こうした設計は、より広い流れを映しています。隔離された鍵保管に、トランザクション単位の検証と、外部の人間が確認できるハードウェア・ソフトウェアの構成を組み合わせるという流れです。これらの機能があっても攻撃に対する耐性が保証されるわけではなく、Ambireの主張にも独立した検証が必要です。価値があるのは、研究者や利用者が調べて確かめられる材料が増える点にあります。
セルフカストディは秘密鍵だけの問題ではない
暗号資産業界は長年、シードフレーズを守り、鍵をオフラインに保つよう利用者に呼びかけてきました。この助言は今も有効です。しかし、現在のオンチェーン活動の複雑さによって、新たな溝が生まれています。鍵を守れても、利用者が何を承認しようとしているのかを明確に伝えられないハードウェアウォレットでは、最も重大な場面である署名の判断が、信頼に委ねられたままになります。
オープンソースのファームウェア、検証可能なハードウェア、適切な鍵の生成、デバイス上でのトランザクションのデコード。それぞれがこの溝の一部に対処しますが、単独では十分ではありません。組み合わせることで、デバイスのセキュリティ上の前提を検証し、疑問を投げかけやすくなります。
もはや目標は、秘密鍵をオフラインに保つことだけではありません。利用者が「署名」を押したときに起きることを信頼できるだけの確かな根拠を、利用者に提供することです。
(Photo by Mariia Berezovsky on Unsplash)
翻訳元: https://hackread.com/hardware-wallets-need-open-source-clear-signing/
