仮想通貨を始めようとしている方、すでに始めている方、全員に読んでもらいたい記事です。
元々は「ハードウェアウォレットを使ってるからって100%安全じゃないよ」を伝える記事だったのですが、仮想通貨取引/DeFiのリスク全般の記事になりました。
現在のDeFi界隈は非常に危険です。毎日のようにラグプル（資産が全て抜き取られる）が横行しています。これはれっきとした事実です。
この記事では
- ハッカーの手口、ハッキング手法
- そもそもハードウェアウォレットは効果あるのか？
- 資金を失う前に行うべき対策
について解説します。
筆者はブロックチェーンセキュリティの専門家ではありませんが、この数週間「DeFi界隈で発生したサイバー攻撃の事例」や「実際にイーサリアムチェーンを構築し、コントラクトアドレス・スマートコントラクトを実行し、dAppsを構築して脆弱ポイントの調査」をしていました。
その結果を共有します。できるだけ仮想通貨の被害を減らすために。
結論から言います。ハードウェアウォレットも万能ではありません。ハードウェアウォレットを利用していても、被害に合うケースは沢山あります。
むしろハードウェアウォレットの採用よりも重要なセキュリティ対策の方が多いと思います。その辺の個人的な考えも取り上げていきます。
この記事の「保護対象」（何を守るか？）
まずは、この記事で述べるトピックの「保護対象」を明確にしますね。
この記事では「個人ウォレットに保有している仮想通貨」にフォーカスを当てています。
ただし、以下のような市場変動などによる間接的な損失については対象外です。
- FX取引などによる資産目減りリスク
- ステーキングなどによる資産目減りリスク
- ファーミングなどによるインパーマネントロス
これらは個人アセットのサイバー攻撃（以下、平易に表現するためハッキングとします）とは関係なく、併記すると範囲が非常に広がってしまうため、この記事では対象としません。
従って、記事の対象としている主なアセットは以下となります。
- 個人ウォレットに保有している仮想通貨
- DeFiにファーミング/ステーキング（以降、ファーミングに統一）している仮想通貨
DeFiでファーミングしているアセットも本質的には個人のウォレットに紐付けられているため対象とします。DEXのアグリゲータも同様です。
ここまで長くなりましたが（すいません）、つまり「DeFiに興味がある人は特に読んでもらいたい記事」ということです。
仮想通貨取引の処理について、おさらい
この後に「ハッカーの攻撃手法」を解説するのですが、その前に
そもそも仮想通貨で取引を行う際の一連の流れ
を再考し、どの処理（プロセス）にどんな攻撃をされがちかについて考えてみます。
個人が関連する仮想通貨の取引は、ざっくり分けると以下の3点に分類されます。
- 仮想通貨の受け取り
- 仮想通貨の送金
- コントラクト実行
「3.コントラクト実行」は後述するので、この時点で理解されていなくても問題ありません。殆どの方は「受け取り」と「送金」だけを理解されていると思います。
なので、まずは「1.仮想通貨の受け取り」と「2.仮想通貨の送金」の内部動作を解説します。
仮想通貨の送受信処理を理解する上でわかっていないといけない要素は
- 送金先アドレス（公開鍵）
- 秘密鍵
最も重要な要素はこれだけです。（厳密には送金先アドレスと公開鍵は違うのですが、同じ結果を果たすので同じものと扱います）
仮想通貨を受け取る場合は、送信者に対して自身の送金先アドレスを伝えて、そのアドレスに対して送金してもらいます。
内部的には、送金する際に送金データ（以下、トランザクション）に送金者の秘密鍵を用いた署名を行ってブロックチェーンにトランザクションデータを送信します。
セキュリティを考察する上で、この一連の処理の理解は非常に非常に重要なので、シナリオを交えて処理を列挙してみます。わかってると思ってる人も、読んでほしいです。
（AがBに対して送金する場合）
- Bが事前に「Bの送金先アドレス」をAに伝える
- Aが「Bの送金先アドレス」に仮想通貨を送金するトランザクションを作成
- Aが「2」で作成したトランザクションを「Aの秘密鍵」を利用して署名し、ブロックチェーンに送信
- ブロックチェーンにトランザクションが保存される（送金完了）
「1.」について主要なポイントを解説します。
Bは自身の送金先アドレスを送信者に伝えます。伝え方はメールでも何でも構いません。ネットに公開して「これが私の送金先アドレスです」と伝えても構いません。
「2.」について主要なポイントを解説します。
Aは「Bの送金先アドレス」に対して仮想通貨を送金するトランザクション、これは送金する命令のようなものです、を作成します。これがAのウォレットアプリで内部的に行われている処理です。
「3.」について主要なポイントを解説します。非常に重要なポイントです。
Aは「2.」で作成したトランザクションに対して「自身の秘密鍵」を利用して署名を行います。
この署名は何を意味するのでしょうか？
「私（A）は、私の持っている仮想通貨をBに譲渡する事を了承します」と宣言しているのです。
トランザクションは電子データなので、誰でも簡単に作れます。でも、Aの仮想通貨（Aのウォレット内の資産）はAだけのもの。それを他の人が勝手にトランザクションを作って無断でBに譲渡できたら問題です。自分の資産が気づいたらハッカーのウォレットに送金されていたら嫌ですもんね。
じゃあ「Aはどうやってトランザクション（送金許可）を自分が作ったか？」を証明するかですが、A自身の秘密鍵で署名します。これを真正性の確保と言います。
秘密鍵で署名する技術的なプロセスは言及しませんが、とにかく秘密鍵を使うと、Aは自分のウォレットから他人に送金できるということです。A以外は秘密鍵を持っていないので、Aのウォレットから他人に送金できない（他人に送金するトランザクションを作れない）のです。
逆に言うと、Aが自分のことを証明するツールは秘密鍵だけです。
最後に、「4.」について主要なポイントを解説します。
トランザクションがブロックチェーンに保存された時点で、送金は完了となります。
（厳密にはその後に複数のブロックチェーンが生成された時点でコミットとするケースが多いのですが、今回のセキュリティ観点ではそれ程重要ではないので割愛します）
以上がざっくりとした送金プロセスの流れとなります。Bの観点から（受信する側）は送金アドレスを公開するだけなのが、おわかりになるかと思います。ハッキングリスクは少ないです。
一方、Aはリスクを負っています。ここまでの解説で「どの辺が攻撃されやすいか」について、おぼろげながら理解できてきたかと思います。
では、次に「どの処理プロセスがハッカーに攻撃されがちか」について解説していきます。
仮想通貨取引のプロセスにおいての、主な攻撃ターゲット
ここまでで一般的な送金処理のフローを解説しました。ここから、いよいよ本題に入っていきます。
まずは、この送金処理をハッカーの観点で考えてみます。彼らは、どの処理に対して攻撃を試みるでしょうか？
もう一度シナリオを再掲します。
- Bが事前に「Bの送金先アドレス」をAに伝える
- Aが「Bの送金先アドレス」に仮想通貨を送金するトランザクションを作成
- Aが「2」で作成したトランザクションを「Aの秘密鍵」を利用して署名し、ブロックチェーンに送信
- ブロックチェーンにトランザクションが保存される（送金完了）
結論から述べると「2.」と「3.」の処理が、最もハッカーに攻撃されやすい、リスクに晒されている処理となります。
「1.」は送金先アドレスが公開されているだけなので、それほどリスクはありません。そもそも送金アドレスはブロックチェーンの仕様上、全世界に公開されています。ブロックチェーンは誰でも見れるので、どの送金アドレスがどんなトランザクションに含まれているかについて誰でも参照することが可能です（パブリックチェーン前提）。公開アドレスを知っていても、その公開アドレスに紐付けられている資金を取り出すことはできません。
「2.」の先に「3.」を考察してみます。繰り返しますが、この処理群が仮想通貨取引の中で最もリスクが高いプロセスであり、殆どのセキュリティ記事でフォーカスされている部分です。
前述の通り、トランザクションは誰にでも作れてしまいます。そのトランザクションが「真にAが作ったトランザクションである」と証明できるメカニズムがないと大問題です。このトランザクションは「Aの資金を減らす」処理なので、A以外が作れてしまうとAの資金が盗まれることと同義だからです。そのために、Aしか持っていない秘密鍵を利用して署名して、誠にAが作ったトランザクションであることを確実にするのです。
逆に言うと、Aが秘密鍵を盗まれると、盗んだ相手がAの資金を勝手に取り出すことができます。例えばCがAの秘密鍵を盗むことに成功した場合、Cは「Aが全ての資金をCに送金する」というトランザクションを作ることが可能です。
故に「秘密鍵はウォレットそのものと同義」とも言えますし「秘密鍵を盗まれること=資金を盗まれることと同義」です。
だからネットではどこもかしこも「絶対に秘密鍵は公開してはいけない」・「サポートセンターと名乗る人にも秘密鍵は伝えてはいけない」・「シードフレーズは画面キャプチャしてはいけない、絶対に紙に書いて物理的に盗まれない場所に保管すること」と言われているのです。
で、ここまでは恐らくこの記事を読みに来た人のほとんどがご存知なことだと思います。はい、わかっています。
じゃあ、秘密鍵さえ安全に（どこまでが安全かは主観がありますが、ここでは「電子機器には一切残さずに、紙媒体に書き写して厳重保管」とします）保管していたら、資金は安全なのでしょうか？これが昨今の界隈で生き抜くために重要な観点となります。
とりあえず話を勧めます。攻撃されがちな処理の話でしたね。
「2.」について考えます。つまり「AがBにXX量だけ資金を送金する」というトランザクションの生成です。
これも実は「3.」と同レベルのリスクです。本来であればウォレットアプリが生成するものですが、もし何らかの手法で
「AがBにXX量だけ資金を送金する」
を
「AがCにXX量だけ資金を送金する」
に変えられたとしたら？
次の「3.」でトランザクションを署名するプロセスがありますが、送金先アドレスを1文字1句確認して署名しますか？しないですよね？
なので、このリスクも「秘密鍵を盗まれた場合」と同じレベルで、記事で取り上げる必要がありそうです。
「4.」について考えてみます。トランザクションがブロックチェーンに送信されて保存されるタイミングのリスクです。
この段階は、個人ウォレットからブロックチェーン側（厳密にはインターネット上のブロックチェーンのウォレットのMEMPOOL）に送信されて保存するので、ネットワークやストレージを含む様々な観点での考察が必要です。
まずは、通信経路（ネットワーク）のリスクを考えてみます。トランザクションを送信する場合、一般的にはインターネットが使用されます。トランザクションデータは「ウォレットクライアントがある端末」から「インターネット」を経由して「ブロックチェーンのノード」に届きます。経路間にハッカーがいてトランザクションを盗聴して、トランザクションを改ざんすることは可能でしょうか（中間者攻撃）。結論から言うと、リスクは低いでしょう。トランザクションは秘密鍵を利用した署名がないとブロックチェーンに登録する際に拒否されるため、盗聴されてもリスクは低いと言えるでしょう。
ブロックチェーンに保存されるタイミングのリスク（ストレージに書き込むタイミング）を考えてみます。ブロックチェーンに保存される前に、実はMEMPOOLと言われるトランザクションプールに保存されます。このMEMPOOLのデータを改ざんしようとしても、上記の中間者攻撃と同様のロジックなので、リスクは低いと言えます。ブロックチェーンに保存された後のトランザクションは改ざんが困難です。これがブロックチェーンの最大のメリットと言えるので、ここでは割愛します。
つまり、「4.」についてはリスクが低いと言えるでしょう。
まとめると、最もリスクが高い処理は「2.トランザクションの生成」と「3.秘密鍵を使用したトランザクションの署名」となります。
まとめると、以下となります。
（以降は説明のしやすさを考慮し、順番を便宜上いれかえます。）
- 秘密鍵に対する攻撃
- トランザクションに対する攻撃
- その他の攻撃
「3.その他の攻撃」については後述します。
（主にDEXへの攻撃ですが、まずは秘密鍵とトランザクションの解説をしないとわかりづらくなるので）
代表的な攻撃手法
ここまで、仮想通貨取引を行う上でのリスク、保護すべき要素（主にトランザクション・秘密鍵）について解説しました。
次に、それぞれの保護対象に対して、ハッカーが「どのように攻撃を試みるか（盗もうとするか）」について解説します。（あくまでも主要なものを紹介します）
合わせて、その攻撃に対してハードウェアウォレットの実装が有効かについても考察してみます。
秘密鍵に対する攻撃
ソーシャルエンジニアリング（絶対読め！）
頻度：非常に多い
リスク：超大
被害：超大
概要：攻撃対象に対して秘密鍵を送信するように誘導する手口
個人が秘密鍵を盗まれるケースとして最も多い攻撃だと思います。厳密には「盗まれる」じゃなくて「提供してしまう」パターンです。
例えば、こんなシナリオです。
シナリオA:
- ツイッターで、AirDrop実施中！ 参加するにはRTとLikeボタンのクリックと「リンク先のフォーム」入力が条件
- リンク先のフォームにシードフレーズの入力が求められる
- フォームを申請した瞬間に資金が全て抜き取られる（不審なアドレスに全ての資金が送金されてしまう）
シナリオB:
- ツイッターで、仮想通貨関係の公式サイト（を名乗るアカウント）から直接連絡
- 「お得な情報」や「サポート」を受けるための「リンク先のフォーム」が提示される
- リンク先のフォームにシードフレーズの入力が求められる
- フォームを申請した瞬間に資金が全て抜き取られる（不審なアドレスに全ての資金が送金されてしまう）
シナリオC:
- 購入したトークンの公式Discordで質問を投げたら、管理者から連絡がありサポート対応をしてもらう
- サポートしてもらっている中で「細かく調査するためにシードフレーズが必要」と言われ、提供してしまう
- 提供した瞬間に資金が全て抜き取られる（不審なアドレスに全ての資金が送金されてしまう）
試しにTwitterでPancakeswapなどの主要DEXやMetamaskなどの主要ウォレットのアカウントのツイートを参照してみてください。必ずと行っていいほど「私はXXのサポート担当ですが、困っているようなのでXXフォームを入力してください」などのコメントが書き込まれています。他に「私も困っていましたがXXがサポートしてくれて解決しました」などの書き込み（おとり）。これらは全てソーシャルエンジニアリング攻撃です。
（絶対にリンクをクリックしないでくださいね！）
「こんなアホな手口に引っかかるわけないだろ！」と思うかもしれませんが、当然ながら攻撃者も安直に「シードフレーズくれ！」とは言いません。巧妙に聞き出してきます。
秘密鍵（シードフレーズ）を盗む攻撃の中で、この攻撃が最も有効であり、被害数が多い攻撃だと考えられます。YouTubeで「Metamask Hacked」などのキーワードで検索してみてください。実際に被害にあってしまった方が沢山いることがわかります。
なぜ、この攻撃が最も有効で被害者数が多いか？
この攻撃は、ターゲットに侵入したり、マルウェアを仕込む必要がありません。従って、高度なハッキングスキルが不要です。「数撃ちゃ当たる戦法」で、一人でも引っかかったら成功なのです。攻撃者としては「わざわざ工数をかけてターゲットに侵入する」よりも「費用対効果が高い」。
対策：絶対に、いかなる状況でも他人に秘密鍵（シードフレーズ）を提供してはいけません。
2022/12/30追記：
では、この攻撃に対してハードウェアウォレットは効果的でしょうか？
残念ながら、ハードウェアウォレットを活用しても、この攻撃は防げません。
ハードウェアウォレットを利用しても、秘密鍵を利用している事実は変わらないからです。このシナリオではターゲットが自らシードフレーズ（秘密鍵）を提供してしまうので。
この攻撃に対しては「ソフトウェアウォレットであろうが、ハードウェアウォレットだろうが、リスクは変わらない」と言えるでしょう。
ターゲットのソフトウェアに侵入
頻度：それなりに多い
リスク：超大
被害：超大
概要：ターゲットのソフトに侵入して秘密鍵を制御する（利用や盗難）
例えば、以下のシナリオです。
シナリオA:
- （仮想通貨関係なく）たまたま踏んだリンク先のページが悪意あるサイトで、パソコンがマルウェアに感染
- パソコンがハッカーに制御されて秘密鍵漏洩、資金流出
シナリオB:
- NFT製作者（デザイナー）が依頼者（ハッカー）から「NFTを作ってほしい」と依頼があり、具体的なデザインをイメージした画像を添付したファイルが送られてくる
- NFT製作者（以下被害者）がファイルを解凍し、参照
- ファイルがマルウェアで、パソコンがマルウェアに感染
- パソコンがハッカーに制御されて秘密鍵漏洩、資金流出
つまり、パソコン（クライアント）自体が突破（他人が制御）されてしまうケースです。
通常、秘密鍵はウォレットアプリの中に保存されています。で、その秘密鍵データは暗号化されて盗難されても複合できないメカニズムになっている（ことを期待する）。
でも、仮にパソコンに侵入されてしまって、ウォレットアプリにアクセスされると、シードフレーズのバックアップ画面の表示も可能です。仮にシードフレーズの画面キャプチャやメモ帳保存などをしていたら、これもアウトです。
このような手口は映画の中だけだと思うかもしれませんが、実際に被害にあっている方は沢山いらっしゃいます。
では、この攻撃に対してハードウェアウォレットは効果的でしょうか？
答えとしては「かなり効果的」でしょう。
ハードウェアウォレットの場合はパソコンなどのローカルに秘密鍵を保持していないので、仮にパソコンに侵入されてしまっても安全のはずです。
しかし、ハードウェアウォレットでも、以下のようなシナリオには注意しなければいけません。
- ハードウェアウォレットのクライアントアプリをネットからダウンロード
- 実は、そのクライアントアプリは公式ではない悪意あるプログラムだった
- ハードウェアウォレットとの接続の際に「初期設定にシードフレーズが必要」などのメッセージが表示され、公式アプリなので安心してシードフレーズを入力してしまった
ハードウェアウォレットであっても、パソコンにクライアントソフトをインストールします。スマホであればスマホのアプリをインストールします。そのアプリが「真に公式が発行した安全なアプリである」ことをどうやって確認するのでしょうか。
ちなみに、AndroidはiPhoneと比べてもアプリをオンラインストアに登録するする敷居が低いため、リスクは増えているように見受けられます。
ターゲットのハードウェアに攻撃
頻度：非常に多い
リスク：中
被害：超大
概要：物理的に盗難
前項ではターゲットのソフトウェア（ウォレットアプリやOSそのもの）への侵入について解説しました。
もっと原始的な方法として、物理的な攻撃が考えられます。
例えば
- ターゲットの自宅に侵入して、秘密鍵の紙を盗み取る
- ターゲットのスマホ・ハードウェアウォレットを盗み取って秘密鍵を取得する
などです。
個人的には「これを考え始めたらキリがない」と思います。確かにリスクではあるのですが、仮に自宅に侵入するのであれば、秘密鍵の紙を探すよりも現金を盗むでしょうし、ハードウェアウォレットを盗み出すなら、もっと効率的なソーシャルエンジニアリング攻撃のほうがコストが低い。
では、ハードウェアの攻撃に対してハードウェアウォレットは効果があるのでしょうか？
これは様々な考え方があると思いますが、個人的には「効果が極めて低い」と思っています。理由を解説します。
そもそもハードウェアウォレットを利用するメリットとして「秘密鍵がハードウェアウォレットの中にしか存在しない、殆どのハードウェアウォレットは無理やり秘密鍵を取り出そうとすると自己破壊する」などと言われていますが、それをどうやって証明するのでしょうか。
結局は、製造元を信用するしかありません。
この辺の議論を深めてしまうと、例えば「じゃあ、ハードウェアウォレットを購入した際に、発送の段階で悪意あるコードが入った製品にすり替えられてないか？」など、無限にリスクシナリオが考えられます。
物理的な製品が絡んでいる以上、サプライチェーンを信頼するしかありません。製品発送時の内部犯行が存在しないことを祈るしかありません。
「ソフトウェアウォレットの場合は、必ず平文の秘密鍵が署名時に展開されるので、ハードウェアウォレットより危険」と言われますが、上記のハードウェアウォレットのジレンマとそう変わらないのではないでしょうか。
秘密鍵を保存したストレージに対する攻撃（絶対に読め！）
頻度：非常に多い
リスク：超大
被害：超大
概要：秘密鍵を保存したストレージがハックされるケース
注意喚起がなされていても、半分程度の利用者はやっちゃってるんじゃないでしょうか。
ウォレットを作成時に出力されたシードフレーズ（秘密鍵）を紙媒体以外に記述しているケースです。
やってませんか？
- スマホのカメラで画像として保存
- シードフレーズを画面キャプチャ
- iPhoneのメモ帳に保存
- Dropbox/Google Driveなどのオンラインストレージに保存
いずれも「非常にリスクが大きい」です。特にオンラインストレージ（iCloud含む）がハッキングされた時に真っ先に狙われるのは仮想通貨ウォレットのシードフレーズとも言われています。
少し話がそれますが、重要な話なので補足します。パスワードの話です。
それなりのサイトでは、認証に使用するパスワードの保存はしていません。サイトが持っているのはパスワードのハッシュ値だけです。で、実際に利用者がパスワードを入力した際に、そのハッシュ値と比較して本人確認を行っています。
なので、例えばGmailのパスワードをハッカーが解析するのは難しいのです。でも、実は別の経路からGmailのパスワードを見つけられる可能性があります。
それは「昨今のサービスではe-mailをユーザアカウントとして利用することが多い」ことを逆手に取られる手法です。
例えばとあるユーザがセキュリティ強度が弱いサイトにユーザ登録したとします。ユーザ名はメールアドレスです。パスワードを設定します。サイトはそのパスワードを平文で保存していました。そのパスワードリストをハッカーが盗みました。
そのパスワードは、本来だったら、そのサイト専用のパスワードです。しかし、ハッカーはそう考えるでしょうか？
「同じアカウント名（e-mailアドレスのアカウント）の別のサイトでも同じパスワードを利用している可能性がある」と考えます。つまり、複数サイトでの同一パスワードの再利用です。
これが「同一パスワードの再利用は避けてください」と言われる所以です。セキュリティ強度の低いサイトが突破されると、なし崩し的にセキュリティ強度の高いサイトも（間接的に）突破されるからです。
いくらDropboxがパスワード管理を徹底したとしても、ユーザがパスワードを再利用していたら防げません。なので、最近はMFAが主流になっているのです。
例えば貴方がDropboxに秘密鍵を保管しているとして（自動でアップロードされるのも同じです）、Dropboxと同じパスワードを別のサイトでも利用していたら、、もう秘密鍵は盗まれているかもしれません。
本当に危険です。
では、この攻撃に対してハードウェアウォレットは効果的でしょうか？
当然「全く効果がない」が答えとなります。攻撃されているのは秘密鍵を保存しちゃったストレージなので、ウォレットの種類は関係ありません。
トランザクションに対する攻撃
ここまで秘密鍵に対する攻撃について考察してみました。こんな感じで攻撃手法をリストアップしてみると、ハードウェアウォレットが万能ではない事が改めて認識できたかと思います。
では、次にトランザクションに対する攻撃を考えてみます。
トランザクションの署名に対する攻撃
頻度：それほど多くない
リスク：超大
被害：超大
概要：トランザクションを改ざんして署名
まずは、トランザクションの中に入っている情報を再度考えてみます。システム的な情報（ナンスなど）は割愛します。
- 送信元アドレス
- 送信先（振込先）アドレス
- 金額
この3つの情報を1つのトランザクションにまとめて、秘密鍵で署名します。
この署名するタイミングの攻撃で考えられるのは
- マルウェアなどで送信先アドレスを変更（ハッカーのアドレス）
- 金額を変更
- 正規の秘密鍵で署名
が考えられますね。署名する前であれば署名による検証（ハッシュのバリデーション）が行われていないので、操作ができたらやりたい放題です。
この攻撃に対してハードウェアウォレットは有効なのでしょうか？
私は「効果は絶大」だと考えています。
というのも、殆どのハードウェアウォレットは、トランザクション自体の生成をハードウェアウォレット内で行います。正確には「トランザクション生成」と「トランザクションの署名」の2つのプロセスをハードウェアウォレット内で完結させます。
故に、ハッカーがそのプロセスに介入するためには、ハードウェアウォレットのプログラムへのアクセスが必要となり、それは物理的に不可能なケースがほとんどです。
トランザクション「入力」時の攻撃
頻度：それほど多くない
リスク：超大
被害：超大
概要：トランザクション生成前の情報入力時に改ざん
トランザクション署名に対する攻撃にハードウェアウォレットは効果的です。
しかし、本当に穴はないのでしょうか。
トランザクションの生成＆署名は確かにハードウェアウォレットの中で実行されます。
しかし、肝心の「情報の入力」はどうでしょうか。例えば
- 送信先（振込先）アドレスの「入力」
- 振り込み金額の「入力」
これはどこでやるのでしょう？殆どの場合はハードウェアウォレットを接続する端末のソフトウェアで行うはずです。私が知らないだけで送信先アドレスの入力自体をハードウェアウォレットで完結できる製品があるのかもしれませんが、あの長いアドレスを一文字一句間違えずに入力する術は？って事になります。
この入力時の攻撃とは、具体的には以下のような例です。実際に被害が発生している事例です。
- 何らかの手法でパソコンにマルウェアが組み込まれる
- マルウェアがクリップボードを監視しており、仮想通貨のアドレスがクリップボードに格納されたら「ハッカーのアドレス」にスワップされる
- 利用者はそれに気づかず、送金時にクリップボードのアドレスをペーストし、結果的にハッカーに送金してしまう
殆どの人は宛先アドレスをキーボードで手入力はしないでしょう。恐らく、公開されているアドレスをコピー＆ペーストで宛先フィールドに貼り付けると思います。
このマルウェアは感染した場合、ターゲットのローカルにハッカーのアドレスリストを保存します。一般的に数千の組み合わせのアドレスを保存します（全てハッカーが保有しているウォレットのアドレス）。そして、仮想通貨のアドレスと見られる文字列がクリップボードに格納されるタイミングを伺います。仮に仮想通貨のアドレスと見られる文字列がクリップボードに格納された場合、その文字列に近い（例えば前方4文字一致、後方4文字一致）のハッカーアドレスをリストから抽出し、クリップボードの正規のアドレスとスワップします。後は運良く（悪く？）送金アドレスフィールドに貼り付けられたらハッカーに送金される仕組みです。普通は送金先アドレスを全て目視確認しないと思います（せいぜい前方数文字と後方数文字ですよね）。
この攻撃に対してハードウェアウォレットは有効でしょうか？
個人的には「効果は薄い」と考えています。どんな製品であろうと情報の入力は発生します。その過程が攻撃されるのは防ぐのが困難。その後工程（トランザクション生成＆署名）が守られていても、大前提の情報が書き換えられていると意味がありません。
その他の攻撃
秘密鍵に対する攻撃とトランザクションに対する攻撃について解説しました。
では、最後に「その他」の攻撃について紹介してみます。
この項は送金者（ウォレットを使用する利用者）ではなく、「DEXフロントエンド」や「コントラクト」など、DeFiを利用する際のネット上のエンティティに対する攻撃です。
DEXフロントエンドに対する攻撃
頻度：多い
リスク：ケースバイケース
被害：ケースバイケース
概要：DEXフロントページの操作不能
DEXは非中央分散型のアーキテクチャです。
でもそれはブロックチェーン＆構成ノードが非集中であることを意味してるだけです。
例えばBinance Smart Chainで最も有名なDEXである「PancakeSwap」を例に上げてみます。PancakeSwapでファーミングした情報はBSCのブロックチェーン上に記録されます。この情報は分散型アーキテクチャで担保されており、1つのノードが不正をおこなったり喪失しても影響はありません。
しかし、ファーミングを行う際に参照するページはどうでしょう？
このページはDecentralizedではありません。運営担当者が存在するCentralizedな存在です。ちなみにこの手のページはユーザーがDeFiを使用しやすいように存在している「フロントエンド」と呼ばれます。
「フロントエンド」が存在しなくてもDEXは利用できます。フロントエンドの処理は裏ではブロックチェーン内に保存されている「コントラクト」と呼ばれるプログラム（細かくは違うのだが割愛）を実行しているに過ぎません。なので、フロントエンドを利用せずともブロックチェーンのコントラクトアドレスのコントラクト関数を呼び出すことでファーミングすることも可能です。
でも、そんなこと一般ユーザはしません、というか出来ません。なので、（間接的に）DEXを利用する時はフロントエンド（上記例ではPancakeswapのサイト）に依存することになります。
仮にPancakeswapの運営が悪意ある組織で、ユーザの資金を奪うケースを考えてみます。犯行直前にフロントエンドを停止しますよね。
フロントエンドが止められると一般ユーザはDEXページを利用できないので、ファーミングしている資金を引き出せなくなります。知識さえあればブロックチェーンに直接コントラクト関数を呼び出すことにより引き出せる可能性があるのですが、それを学習している間に資金を抜かれるでしょう。
実際の資金を抜かれる攻撃は後述します。その意味ではこの攻撃（フロントエンドを使用不能にする）は本攻撃の前段階とも言えますね。
では、この攻撃に対してハードウェアウォレットは有効なのでしょうか？
言うまでもなく「効果はない」です。そもそも攻撃を受けているのは（運営の内部犯か外部犯かは関係なく）DEX側です。クライアントがソフトウェアウォレットを使っているかハードウェアウォレットを使っているかなんて関係ありません。
コントラクトの脆弱に対する攻撃
頻度：それなりに多い
リスク：超大
被害：超大
概要：DEXのプログラムの抜け穴を攻撃
この記事の冒頭に「ウォレットに関する操作は、ざっくりと3つありますよ」と述べました。こちらです。
- 仮想通貨の受け取り
- 仮想通貨の送金
- コントラクト実行
例えばDEXでイールドファーミングをしたりステーキングしたり通貨のスワップをしたりしますよね。これは「1.仮想通貨の受け取り」ではなく「2.仮想通貨の送金」でもありません。
「3.コントラクト実行」によって実現しています。
ややこしいワードに聞こえますが、難しく考える必要はありません。ファーミングなどの命令（例：私のウォレットのX通貨をステーキングして）は、実はブロックチェーン内のコードを実行しているに過ぎません。具体的にはざっくり以下のような内容です。
運用側がやる事前準備：
- DEX運営がステーキングのプログラムを作る
- DEX運営がプログラムをブロックチェーンにアップロードする
アップロードしたプログラムは「プログラムが保存されているアドレス」と「プログラム名」を指定することにより実行可能となります。「プログラムが保存されているアドレス」は通常の利用者の受信アドレスと同じような文字列です。これをフロントエンドが裏でやってくれているので、我々一般ユーザは意識せずにイールドファーミングができるのです。
つまり何が言いたいかというと、ステーキングなどのFinance処理を実行する際も、結局は「プログラムを呼び出して実行しているにすぎない」ということです。
このプログラムを悪用して資金を抜き取る攻撃が、この項の議論の対象です。
DeFiが実利用されはじめてまだ数年しか経っていませんが、既に何度も事件が発生しています。以下に実際の例を紹介します。
（内部犯）利用者の資金を持ち逃げ
本番ローンチして、大量の利用者がトークンを購入した後に、運営者が資金を引き出して持ち逃げしたパターンです。
利用者が資金を引き出せないようにプログラム上でロックが掛かっており、かなり用意周到だったことが伺えます。
この手の事件は何度も何度も発生しています。
内部犯かは不明だが、とにかく利用者の資金を持ち逃げ
かなりの被害が大きかった事件です。
超ざっくり言うと「プログラムのバグにより、特殊な組み合わせのロジックを実行することにより想定以上のトークンを取得できた」ことを悪用したパターンです。
プログラムが複雑になればなるほど、脆弱が顕在化しやすい。このケースはそんな穴が悪用されました。
ちなみに「開発が甘くてできてしまった脆弱」なのか「開発者がもともと悪意ある操作を意識し上で作っていた脆弱」なのかは不明です。また、運営チームが「外部からハックされた、脆弱を利用された」とアナウンスしてもその真偽は不明です。でもとにかく甚大な被害が出たのは事実です。
実は、この記事を書いている数時間前にも、このカテゴリのハッキングが発生しています。
そして、記事を校正している間にさらに発生しました。Azura DAOのラグプル。
では、この攻撃に対してハードウェアウォレットは有効なのでしょうか？
こちらも「一切効果はない」です。攻撃対象がウォレットではないので、仮にハードウェアウォレットを利用していても資金は抜き取られます。
コントラクト自体が悪意あるコードだった
頻度：多い
リスク：超大
被害：超大
概要：DEX内の命令がはじめから悪意コードとして作られた
これも恐ろしい。
コントラクトのコードの脆弱とか関係なく、そもそも悪意あるハッカーがコントラクトを開発したケースです。
例えばこんなケースです。
- ハッカーが「実行したユーザのアドレスから全ての資金をハッカーのアドレスに送信」するプログラムを作成
- ブロックチェーンに登録
- 偽物のDEXフロントエンドを開発
- 世界に公開
既存の大手サイトに似せるケースもありますし、高APRを謳って立ち上げるサイトもあります。とにかく注目を浴びてユーザーがアクセスするサイトです。
この攻撃に対してハードウェアウォレットは有効なのでしょうか？
「一切効果はない」です。攻撃対象がウォレットに見えますが、ウォレットはその先のコントラクト関数がどのような挙動をしているかについてコントロールしていません。コントラクトの実行という観点では完全に正当なので、署名してトランザクション処理をします。
ハッカーによるハッカーに対する攻撃（ハニーポット）
これは一般ユーザが被害者ではなく「ハッカーが被害者」になるハッカーによる攻撃です。なので一般ユーザが知る必要はないかもしれませんが、面白い攻撃なので休憩がてら読んでください。
仮想通貨界隈で最も重要な情報は「秘密鍵」であることは既に説明しました。この攻撃では、悪意ある攻撃者が「わざと」自分の秘密鍵を公開します。
事前準備はこんな感じ。
- 真の攻撃者が、自分のウォレット（以降、罠ウォレット）にETHチェーンのトークン（以降、餌トークン）を格納する（普通にDEXでスワップ）
- 罠ウォレットの中のETHを全て別の財布に転送する
- この時点で罠ウォレットの中身は「ETH:0 餌トークン:スワップしただけ」
- このウォレットの秘密鍵を公開する
この秘密鍵情報をたまたま見つけたハッカー（以降、被害者ハッカー）は何をするでしょうか？
罠ウォレットの中のトークンを奪おうと、急いで自分のウォレットに秘密鍵をインポートしてトークンを転送しようとしますよね。
しかし、トークンを転送するためにはGASフィーが必要です。一般的にはそのチェーンの通貨が必要です。罠ウォレットの中に通貨がないのでトークンを転送できません（そのように準備しているので）。
となると、被害者ハッカーはどうするでしょう？少額のETHを罠ウォレットに送金しますよね？
これが真の攻撃者の狙いです。罠ウォレットのETH残高を確認するBotを仕込んでおいて、少しでもETHが入ったら転送する仕組みを作っておけば、永遠に世界中の愚かなハッカーから資金を吸い出せるでしょう。（実際はBotの仕組みをスマートコントラクトに仕込んでおくことが現実的でしょう）
DeFi版のハニーポットです。
これ、NervosのGodwokenだと少し高度なテクニックが利用できそうです。
- L2に50CKB程度入れておく
- L1は0CKB
こんな感じのウォレットの秘密鍵を公開しておきます。Godwokenの仕様上、出金するためには400CKBが必要です。なので秘密鍵を取得したハッカーは残りの350CKBを送金するかもしれません。それをBotで奪う。
（期待値が少ないので引っかかるハッカーは少ないかもしれませんが）
ここまでのサマリ
かなり長々と書いてしまったので、サマリします
| 攻撃種別 | ハードウェアウォレットが有効か？ |
| ソーシャルエンジニアリング | ✗ |
| ソフトウェアへの攻撃 | △ |
| ハードウェアへの攻撃 | △ |
| 秘密鍵を保管しているストレージへの攻撃 | ✗ |
| トランザクション生成＆署名への攻撃 | ○ |
| トランザクション入力時の攻撃 | ✗ |
| DEXフロントエンドへの攻撃 | ✗ |
| コントラクトの脆弱への攻撃 | ✗ |
| コントラクト自体が悪意あるコード | ✗ |
こんな結果となりました。
これだけ見るとハードウェアウォレットの優位性がほとんどないように感じてしまいます。でも、それは攻撃の手法がどんどん増えてきた背景があるのでは？と考えています。昔は秘密鍵が最大の脆弱であったため、秘密鍵をいかに守るかが最大の焦点だった。しかし、DeFiが普及するにつれて、秘密鍵以外のセキュリティホールも露呈し、結果的に秘密鍵を守る=資産を守るではなくなってしまった。
つまり「資産をハードウェアウォレットで守ってるから大丈夫！」と盲信するのは危険すぎる世の中になったということです。
ハッキングに対する対策
ここまでの考察で、ハードウェアウォレットの利用だけでは不十分、ほんの一部の攻撃しか防げない、ことが理解いただけたかと思います。
では、ハッキングに対する対策は全体的な観点で何が考えられるでしょうか？
個人的に徹底している内容を紹介します。
セキュリティ対策のレベルが向上するまで利用しない
これが一番だと思います。不安なら利用しないほうが良い。
「ブロックチェーンはセキュリティもしっかりしている」
というのは、ウソか誤解です。
ブロックチェーンのセキュリティは主に「チェーンの改ざんが困難である」ことを指していて、利用者の資産が保護されていることではない。
別の記事でも書きましたが、現在のDeFiは一般ユーザが利用するセキュリティレベルに達しているとは到底思えません。一つの誤操作・ハッカーからの攻撃で資産を全て抜かれます。
でも、対策が「使わない」だけだと記事を書いた意味がないので、、、私が実践している対策を紹介します。
余裕資金（なくなっても苦しまない）レベルで行う
基本中の基本です。
どれだけ注意深く行動しても、現在のDeFiではハックされる危険性があります。ここまでさんざん解説したからわかるはず。
例えば、どれだけユーザ側で注意しても、DEX側がやられたらアウトです。
有名所でも100%安全ではありません。どんなDeFiサービスでも20%くらいは危険が残ると考えたほうが良い（数字は肌感覚）。
仮に被害にあった場合、戻ってくる可能性は限りなくゼロです。銀行のように保証はありません。
私自身も、いつ被害にあうかわかりません。
なので、それを十分に理解した上で、なくなっても精神的ダメージが少ないレベルの余裕資産で楽しむくらいが丁度いいのです。
資産を増やすことは意識しないほうが良いです。ゲーム感覚で最新テクノロジーを学ぶお金だと考えたらラクです。
秘密鍵は紙に書いて厳重に保管する
- ローカルのパソコンにシードフレーズを保存している
- スマホに画面ショットを保存している
- iCloudやDropboxなどのオンラインストレージに転送されている
こんなことをしている方、今すぐ新しいウォレットを作成して、シードフレーズを紙だけに残しましょう。そして、旧ウォレットから資金を全て転送しましょう。
もう、既に、他の人が秘密鍵を盗み終わった後かもしれません。数カ月後に急に資金がゼロになるかもしれません。そのくらい危険なことをしています。
物理的に盗難に合う可能性のほうがずっと低いです。心配だったら家の複数箇所に保管したら良い。
とにかく、ソフトウェア上での秘密鍵の保管はやめましょう。
パソコンでの操作は行わない
DeFiの作業について、私はパソコンは一切利用していません。
全ての処理はスマホ（iPhone）で完結させています。
WindowsだろうとMacだろうとLinuxだろうと、リモートログインの入り口が無数にあります。
それぞれのアプリが連携する手法が無数にあります。可能性が多いほど脆弱も多いことを意味しています。
アプリ内連携も同様です。ChromeのMetamaskウォレットは非常に人気があるウォレットアプリですが、Chromeのタブに悪意あるサイトが存在している場合、それだけでリスクとなります。
自分のPCがリモートログインされていない、されない確証を私は100%持つことができません。そのなかのアプリならなおさらです。自分が想定していなくとも、悪意あるサイトに誘導されないという確証がないのです。
たった1回の操作で全てを失う可能性があるのです。秘密鍵のシードフレーズを自分から入力するのは愚の骨頂ですが、それ以外でも上記で説明したように全てを失います。
実際に世界中で起っている事実です。私は大丈夫、と思ってはいけません。
なので、私はiPhoneのウォレットアプリを利用しています。ウォレットアプリの製品名を書くと広告に思われるかもしれないので、ここでは記載しません。iPhoneのウォレットアプリ以外は絶対に使いません。
iPhoneもインターネットに繋がっている限りは「100%安全」ではありません。しかし、リモートログインの可能性は汎用OSと比べると圧倒的に少ない。
仮に何らかの手法でiOSにログインされたとしても、ウォレットアプリの起動にパスワード&指紋認証（MFA）が必要です。汎用OSのMetamaskにたどり着くよりも何倍もセキュリティ強度が高いはずです。
何度も言いますが、そのウォレットのシードフレーズをWindowsのChromeのMetamaskに登録した瞬間にセキュリティ強度がゼロに等しくなります。なので、絶対にやりません。
Androidも使用しません。AndroidのマーケットプレイスはiPhoneストアよりも公開の敷居が低いように感じているからです。こればかりは定性的なデータがないのですが、以下を参照してください。
本物のウォレットアプリに似せた、偽物のウォレットアプリが多数公開されている事実です。
仮にiPhoneのアプリだったとしても、100% 正規のアプリかは分かりません。毎回アプリダウンロードの際に、ハッシュ値の照らし合わせをしますか？結局はどれだけ信頼があると評価するかです。ハードウェアウォレットでも、ウォレットのアップデートの際に不正なロジックがアップデートされる可能性があるわけで、どこで線を引くかの話です。
上記はBSC上で最も有名なDEX「PancakeSwap」の偽アプリです。このように、iPhoneアプリやMacアプリであっても100%信用することはできません。
ウォレット内でのDAppしか利用しない
Googleで検索したリンクからDAppを利用するのは非常に危険です。
仮に検索結果ページの最初に表示されているリンクであっても危険です。
むしろ、最初のリンクは注意する必要があります。ハッカーが広告料金を支払って不正なサイトに誘導している可能性があるので。
通常のブラウザからリンクをクリックしてDAppにアクセスするのは非常に危険です。
従って、以下の2点のどちらかの利用を徹底するべきです。
ブラウザにURLを直打ち
リンクに頼らずに、自分でブラウザにサイトのURLを直打ちします。例えばPancakeSwapの場合は「https://pancakeswap.finance」と直打ちします。
しかし、これも完璧ではありません。自分が「絶対に100%、正しく文字列を入力したか」をどうやって評価するのでしょうか。ハッカーは「わざと類似した文字列のドメインを保有しておき、全く同じ見た目のサイトで待ち構えている」可能性もあります。実際に1文字間違ってアクセスしてくるターゲットを狙う手口です。
なので、この手法は、検索結果のリンクをクリックするより少し安全程度に考えておくべきでしょう。
信頼できるウォレットアプリ内のDApp用ページからアクセスする
私はこれ以外の手法は絶対に利用しません。
スマホのウォレットアプリの殆どは、内蔵ブラウザを保有しており、予め有名所のDAppのリンク（アイコン）が入っています。これを利用します。
当然制約があります。限られたDEXしか登録されていないし、新しいDEXもありません。でも、その範囲内でしか利用しません。そもそも新しいDEXは脆弱の耐性ができていないと考えています。そんなDEXに貴重な資産を預けるのは無謀です。
「そのウォレットアプリのリンクが正規か、信用できるのか？」と疑問に思われるかもしれません。その疑問は正当です。リンクが正規か、内部のブラウザロジックで不正サイトにリダイレクトされないか？誰にもわかりません。しかし、仮に不正なリンクが埋め込まれていたて被害が発生した場合、そのウォレットアプリは多大な信用を失います。それこそ、そのリンクを埋め込んで得た利益以上の被害を受けるはずです。
結局は「何が信用に値するか、どの信用に頼ることにするか？」の話になるのです。
複数ウォレットを運用する
一つのウォレットに全ての資産をいれない。
ウォレットを作るのは簡単です。なので、複数ウォレットを作って資産を分散させるのです。運用は若干煩雑になりますが、かなりの効果が期待できます。
個人的にはハードウェアウォレット1つよりも効果があると思っています。
サードーパーティのセキュリティ評価サイトを活用する
初めてのDAppを利用する前、コントラクトを実行する前に、サードパーティのDeFiセキュリティ評価サイトをチェックします。
最低でも以下のサイトでチェックしてください。
ここでアクセス予定のDeFiサイトを検索し、スコアを確認します。例えば上記で紹介した「Grim Finance」を検索してみると「High Risk」となっています。
基本的に「Medium Risk」以上は利用しない。アクセスさえもしない。これを徹底します。
監査済マークを信用しない
DEXサイトには「監査サイトをPassしました」とのメッセージがあったり、その証明としてロゴが入っていたりします。
だから安全、と考えてはいけません。殆どの監査は「コードの中に不審なロジックが入っていないか」が中心となっており、運営者の所在やIdentityまで細かく調べているわけではありません。
アグリゲータは利用しない
一般的なイールドファーミングのコードは過去のハッカーからの攻撃を踏まえて改善されつつあります。
一方、アグリゲーターは存在そのものが新しく、内部のロジックも複雑になりがちです。故にハッカーのターゲットになりやすい（上記のGrim Financeもアグリゲーターの脆弱を攻撃されたよう）。
また、アグリゲーターは運営が資金を一旦引き取るので、資金をロックされると直接コントラクト関数を実行して資金を引き上げることも困難です。
APRが魅力的であっても資金を抜き取られたら元も子もありません。
ファーミング/ステーキングのApproveは定期的にRevokeする
「コントラクト自体が悪意あるコードだった」で解説した内容と関連があります。
信用レベルが低いDAppsでファーミング/ステーキングのApproveを行った場合、速やかにRevokeするべきです。Revokeすることによって、Approveの際に許可した通貨のコントロールを停止することが出来ます。
前述の通り、ハードウェアウォレットであっても残存するリスクのため、定期的にRevokeするべきです。
RevokeはUnrektというサイトが有名です。信用できるウォレットアプリからのアクセスを推奨します。
終わりに
・・・書いていくと想像以上に長いコンテンツになってしまいました。
繰り返しますが、一般ユーザは現在のDeFiを使用することはオススメできません。単純にセキュリティ施策が脅威の増加に追いついていないのです。
これから更にハッキング手口の巧妙化・増加が続くでしょう。初のハッキング手口（ゼロデイアタック）も増えていくでしょう。ゼロデイアタックの前では、殆どの対策は無力です。そんな世界に資産を放り込むのは無謀です。
「ハードウェアウォレットを利用しているから大丈夫」とか「私はこれまでハッキングされたことがないから大丈夫」とか、根拠のない自信は持たないでください。そんな人ほど既にハッキングされているものです（気づいていないだけ）。
全ては自己責任です。（この記事の対策全てを行ってもハッキングされるときはされます。私は一切の責任を負えません）
コメント