こんにちは、CTOの森下です。

今回は、BCHのハードフォークによって懸念されているトランザクションリプレイとリプレイアタックについて書きたいと思います。

事の発端としては、リプレイアタックを受けてみたというTweetをみて、 「リプレイアタックは自分自身に対して行ってもアタックと言えるのか？」と気になったからです。

いつもの実装記事と違い、個人的な主観が入っているので「こういう考え方もあるのか」という程度で読んでいただけると幸いです。

トランザクションリプレイ

まずはトランザクションリプレイについて説明します。 トランザクションリプレイとは、あるブロックチェーンネットワークに対して送信したトランザクションがフォーク先のネットワークでも有効なトランザクションとされ、両方のチェーンで同様の送金が行われることです。 ただし、この説明はフォーク時の文脈に限ります。

今回のBCHとBSVのフォークは下図のようになっています。

+---------+   HF   +---------+  +--------+
|         |        |         |  | A -> B |  本来のTX
|   BCH   +---+----+   BCH   |  |  1BCH  |
|         |   |    |         |  +--------+
+---------+   |    +---------+
              |            AさんからBさんへ1BCH送る場合
              |    +---------+
              |    |         |  +--------+
              +----+   BSV   |  | A -> B | リプレイされたTX
                   |         |  |  1BSV  |
                   +---------+  +--------+

BCHとBSVは仕様の違いによりハードフォークが行われました。しかし、リプレイプロテクションがないため、トランザクションリプレイが起こります。 したがって、AさんがBさんへBCHとBSV両方のブロックチェーンに存在するUTXOをインプットとしてBCHを送ろうとした場合、BSVネットワークでも有効なトランザクションとして処理され、両方送金されてしまいます。

BTCとBCHのハードフォーク時にはBCH側にリプレイプロテクションが実装されたため[1][2]、これは起こりませんでした。

リプレイプロテクション

リプレイプロテクションとは、フォークの際にトランザクションリプレイが起きないようにすることです。 仕組みとしては、両チェーンで有効とされるトランザクションを一方のチェーンでは無効なトランザクションとなるように仕様を変更します。 トランザクションの構造や署名の方式を変えたりすることで、両方のネットワークへのトランザクションのブロードキャストを防ぎ、トランザクションリプレイが起こらないようにできるわけです。

リプレイアタック

上で説明したようにリプレイプロテクションが実装されていない場合には、トランザクションリプレイが起こってしまいます。 これを利用して、不正に通貨を得る手法がリプレイアタックです。 また、トランザクションリプレイのことをリプレイアタックと称している場合もあります。

私の解釈では、トランザクションリプレイは現象のことであり、リプレイアタックはそのトランザクションリプレイの現象を利用した攻撃手法だと考えています。 しかし、多くのメディアではリプレイアタックをトランザクションリプレイとしている記事が多く見受けられます。 リプレイアタックの定義の確固たるソースがないので何が正解というわけではないですが、なにか腑に落ちませんでした。

まず、アタック(攻撃)というからには、攻撃者とその対象者がいると考えられます。 この場合、どんなプレイヤーが攻撃者と対象者になりうるでしょうか？

+---------+        +---------+
|  攻撃者  +------> |  対象者  |
+---------+        +---------+

※ この説明におけるユーザーとは仮想通貨を使用する者とする。

悪意を持ったユーザー → 取引所

まずは、悪意を持ったユーザーが取引所に行う攻撃です。 これのやり方もBCHとBSVで説明します。

  ユーザーの      　　　取引所
  ウォレット      +--------------+
                |              |
+---------+     |  +--------+  |
|  1BCH   +------> |        |  |
|   ↓     |     |  |  1BCH  |  |   BCHの入出金を繰り返す
|  1BCH   | <------+        |  |
|         |     |  +--------+  |
|         |     |              |
|         |     |  +------+    |
|         | <------+ 1BSV |    |   BCHの引き出し毎に
|  0BSV   |     |  +------+    |   BSVを引き出せる
|   ↓     |     |  +------+    |
|  3BSV   | <------+ 1BSV |    |
|         |     |  +------+    |
|         |     |  +------+    |
|         | <------+ 1BSV |    |
+---------+     |  +------+    |
                |              |
                +--------------+

この2つの通貨には、現時点でリプレイプロテクションがないため、トランザクションリプレイが起こります。 まず、悪意を持ったユーザーは取引所にBCHだけを預けます。そして、取引所に着金確認がされ次第、それをすぐに引き出します。 このとき、フォークしたBSVも同様に引き出せてしまいます。もう一度BCHだけ預けて引き出すとフォークした通貨を更に引き出せます。 これを繰り返すことで取引所の残高がなくなるまでフォークした通貨を不正に引き出すことが可能となります。 これは、取引所は出金のアドレスを複数のユーザと共有していることが多く、大量の通貨を盗み出せる可能性のあるリプレイアタックです。

ただし、まともな取引所であればリプレイプロテクションがない場合には入出金の機能を止めるため、現実的には実行は難しいでしょう。

悪意を持ったユーザー → 一般ユーザー

ユーザー対ユーザーの場合では、秘密鍵をそれぞれが管理しているため、リプレイアタックが起きにくいと考えられます。 しかし、ハードフォークが行われ、BSVが付与されたことを知らないBCHホルダーに対して、 「利子つけて返すからいくらか送ってくれない？」などといって、BCHを送ってもらうことで、送信者は意図せずBSVを送金してしまい、受信者はBSVを盗むということもできるわけです。 この場合は、ユーザーのリテラシーが問題になってきます。

新たな観点

上に述べたことが、私が思うリプレイアタックです。 これは悪意を持ったプレイヤーが誰かに攻撃を仕掛け、利益を得るという認識からくるものです。 しかし、トランザクションリプレイ = リプレイアタックと解釈する場合、悪意を持っているかどうかは関係なくなります。

この「ユーザーが意図せずにトランザクションリプレイが起きてしまうということ」をリプレイアタックの定義とすると、 リテラシーが低いユーザーにとってはトランザクションリプレイはリプレイアタックとなります。

しかし、リプレイアタックと称するからには、攻撃者がいないことには成立しません。 上でリテラシーが低いユーザーにとってはリプレイアタックになると述べましたが、この観点から行くと、 ユーザーに対してプロテクションリプレイがないブロックチェーンを開発するコミュニティ、 またはそのサービスを提供する事業者が攻撃者になりうると気づきました。

この認識は非常に重要で、ユーザーからすると意図せずに不利益を被った場合には、攻撃された場合と結果は同じです。 いくらブロックチェーンのデータが堅牢であるとしてもブロックチェーンの仕様が原因のヒューマンエラーによって資産がなくなるといったことが起こりやすい場合は、 ブロックチェーンのセキュリティが甘いといっても良いと考えます。

最終的な定義

私の結論は、リプレイアタック ≠ トランザクションリプレイですが、解釈によってはほぼ同じになるというものです。 最終的には以下のように定義しました。

  • リプレイアタックとは、トランザクションリプレイが起こることによってユーザーの意図とは関係なくフォーク通貨が送金されること

まとめ

今回は、トランザクションリプレイとリプレイアタックの定義について書きました。 個人の思想が入った哲学的なものなので正しいかどうかわかりませんが、腹落ちできました。 大学・大学院時代は言語情報学をやっていたので、言葉の定義に関して非常に興味があり、たまに考えてみたくなるんですよね。 適当にインプットしていたものをしっかりと考え、最終的に自分なりの解釈まで落とし込むことで新たな観点を発見できる良い機会となりました。 機会をくれたさんのツイートはいつも参考にさせていただいています。 ありがとうございます。

ブロックチェーンのサービスはまだまだ改善の余地があり、一般のユーザーからすると非常に使いにくいのが現状です。 ブロックチェーンの仕様だけではなく、それを使うユーザーがどうなるのかまで加味して設計することが大切であり、意識し続けていきたいと思います。

Tip us!

エンジニアチームのブログを書くモチベーションが上がります 💪

address

0xd6d478dCe4585a394834690158cf83581223C08f

※ BCHだけを分離して送れる人だけお願いします。

参考文献