要約：
- リプレイアタックとは、とある送信者が送った認証データを取得し、そのデータを送信者のふりをして再送信するハッキング手法です。
- ブロックチェーンでもリプレイアタックが起こる可能性があります。ブロックチェーンでのリプレイアタックは、ハードフォークがないときの攻撃と、ハードフォーク後の攻撃に分けられます。
- ブロックチェーンでのリプレイアタックも、対策が講じられています。基本的にはユーザー側で対処する必要はありませんが、ハードフォーク後には対策がされているかを調べるほうが安心できます。
リプレイアタック（反射攻撃）とは
リプレイアタック（反射攻撃）とは、とある送信者が送った認証データを取得し、そのデータを送信者のふりをして再送信するハッキング手法です。
ハッカーは取得した認証データの送信を遅らせることにより、被害を引き起こすことも
例えば、Aliceがパスワードを入力してWebサイトにログインしたとします。パスワードが暗号化（ぐちゃぐちゃに加工）されてサーバに送信されていたとしても、暗号化された文字列を取得して、そのまま送信すればログインできてしまいます。
リプレイアタックは、毎回同じパスワードのみを要求してログインするようなケースで発生する可能性があります。
一般的な防止方法
ワンタイムパスワードを要求し、パスワードとワンタイムパスワードを合わせてハッシュする（暗号化の方法の1つ）などすれば、リプレイアタックは防止できます。
ハッシュを利用する場合、入力値が同じなら同じ出力値が生成されますが、入力値が違うなら違う出力地が生成されます。
ワンタイムパスワードが毎回違うため、認証時に提出が求められる出力値も毎回変わり、これにより傍受したデータをそのまま送付することでは、ログインできなくなるのです。
ブロックチェーンでのリプレイアタック
ブロックチェーンでもリプレイアタックが起こる可能性があります。例えば、1 ETHを送金してもらった人が、その送金を繰り返すために引き起こそうとする可能性があります。
より具体的に、以下の状況を考えてみましょう。
- AliceがBobに1 ETHを送金した
- Aliceの残高は2 ETHで、送金後1 ETHになった
- Bobは「AliceがBobに1 ETHを送る」という処理を再度実行させたい
リプレイアタックを企てたBobは、Aliceが送ったトランザクションを取得しました。ちなみにトランザクションとは、送金金額や送金先などの内容に署名が付与されたものです。
署名はAliceのウォレットの秘密鍵を知らないと作れませんが、Bobは一度作られた署名を取得してそのまま提出します。また送金に関する内容もそのまま送信します。
これで、「Aliceが1 ETHをBobに送金する」というトランザクションが送れました。Aliceの残高は十分であり、Alice自身の秘密鍵によって署名がされているので、トランザクションのチェック役のノードは気づけなさそうです。
ただ、実際には対策がされていて、上の手口は通用しません。
ハードフォーク後に起こることも
上記は、1つのブロックチェーンで起こるリプレイアタックの例でした。詳細は後述しますが、この手口には対策がされているので、主要なチェーンを使うならあまり心配しなくても良さそうです。
実は、ハードフォーク後を狙ったリプレイアタックも存在しており、被害に遭わないためには、こちらのほうに注意を払う必要があります。
ハードフォークとは、アップグレードを経て、ブロックチェーンが互換性のない二つのチェーンに分かれることです。ブロックチェーン参加者が「絶対にアップグレードしたい」という側と、「絶対にしたくない」という側に分かれると、ハードフォークが起こります。
なぜハードフォーク後には、別の手口でリプレイアタックを仕掛けられるのでしょうか。これを理解するためには、「ハードフォーク前に保有していた資産」がポイントになります。
ハードフォーク前に保有していた資産は、ハードフォークで分岐した両方のチェーンに残る仕様となっています。例えば、ハードフォーク前のイーサリアムで1 ETH持っていた人なら、ハードフォーク後は、1 ETHと1 ETHWを保有していることになります。
またハードフォーク後、秘密鍵は同じものが使われます。
そこで、Aliceが1 ETHをBobに送信した後にBobが、そのトランザクションを取得して、別のブロックチェーンで送ると、「Aliceが1 ETHWをBobに送信する」というトランザクションを理論上は実現させることが可能です。
リプレイアタックへの対策
リプレイアタックは、ハードフォークがないとき、ハードフォーク後で手口が異なります。それぞれの手口にはどのような対策がされているか見てみましょう。
ハードフォークがないとき
ビットコインの対策
ビットコインは、「UTXOモデル」という記録方法、送金方法を採用することでリプレイアタックを防止しています。
UTXOモデルを利用すると、送金内容は毎回異なります。「AliceがBobに1 BTCを送る」という内容であったとしても、1回目と2回目では違いが出ます。
そのため、Bobは過去のトランザクションを取得し、そのまま送信することではハッキングできません。
イーサリアムの対策
イーサリアムは、ナンス（Nonce）を送金内容に含めることでリプレイアタックを防止しています。
イーサリアムのナンスとは、とあるアドレスが送るトランザクションの整理番号のようなものです。例えば、「AliceがBobに1 BTCを送る」という内容を作ると、「ナンス0」などと番号も自動で送金内容に含められます。
ナンスがあるため、同じ宛先・金額の送金であったとしても、1回目の送金と2回目の送金では、送金内容が変わります。そのため、1回目の送金内容をそのままコピーするだけでは、トランザクションは成立しないのです。
ナンスという用語はマイニングの説明でも出てきますが、二つは全く別の概念です。
ハードフォークがあったとき
ハードフォーク直後は、別の対策が必要になります。ただし、ハードフォークするブロックチェーン側が対策用の規則を追加したり、ウォレットが対策を講じたりするので、基本的にはユーザー側での対策は不要となっています。
ただ、ハードフォーク後の対策がされているかについては、一応ユーザー側でも調べておくほうが無難かもしれません。
参照
コメント