EIP-3074 の批判と単純な置き換え

以太坊爱好者

特邀专栏作者

2021-06-29 09:00 (UTC+8)

この記事は約2726文字で、全文を読むには約4分かかります

AUTH コミットに署名する方が、脆弱な/悪意のある契約に関連するトランザクションに署名するよりもリスクが高いのはなぜですか?

AI要約

AUTH コミットに署名する方が、脆弱な/悪意のある契約に関連するトランザクションに署名するよりもリスクが高いのはなぜですか?

開発者にとって、AUTH/AUTHCALL メカニズムは非常に魅力的です。これにより、呼び出し元を作成して、さまざまなバッチ戦略 (並列処理を向上させるための複数のノンスをサポートするなど)、ガス抽象化モデル、複雑なアカウント抽象化メソッドなどを実装できます。

この柔軟性は、このメカニズムが開発者に大きな自由を与えることに由来しています。 AUTH/AUTHCALL メカニズムでは、開発者が特定のパターンに従う必要はありませんが、ユーザーはコミットハッシュ値に署名する必要があり (コミットの内容は呼び出し元によって解析されます)、開発者はコミットに基づいて独自の制限を設定できます。

ただし、この柔軟性にはセキュリティが犠牲になります。この記事では、より簡単な代替手段を紹介したいと思います。このソリューションには AUTH/AUTHCALL メカニズムの利点のほとんどが備わっていますが、リスクは後者よりもはるかに低くなります。

AUTH コミットに署名する方が、脆弱な/悪意のある契約に関連するトランザクションに署名するよりもリスクが高いのはなぜですか?

ユーザーが契約関連の取引に署名するとき、ユーザーが負うリスク、つまり契約の管理下にある資産が失われる可能性があることがわかっています。ユーザーが、悪意のある DEX コントラクトを承認する ERC 20 コントラクトへの承認トランザクションに署名したとします。この悪意のある DEX 契約は、ERC 20 契約のユーザーの残高全体を引き出すことができます。ただし、ユーザーの承認がない限り、ユーザーの他の ERC 20 契約からトークンを引き出すことはできません。また、これも排他的なユーザーの承認が必要なため、ユーザーに代わって他のアクションを実行することはできません。

対照的に、EIP 3074 では、ユーザーに「白紙小切手」への署名を要求するだけでなく、発信者が正直で脆弱性がないことも前提としています。悪意のある/脆弱な呼び出し元は、ユーザーに代わってあらゆるアクションを実行できます。ユーザーが保有する資産へのアクセス、ユーザーに代わって投票、ユーザーが所有する契約の制御などです。

さらに悪いことに、nonce 実装は呼び出し元の制御下にあるため、呼び出し元がいつでも悪さを行う可能性があります。 nonce ロジックの脆弱性または悪意のある実装により、ユーザーの過去のトランザクションがリプレイされる可能性があります。コミット検証の他の部分のロジックにも脆弱性がある場合、呼び出し元はこの nonce ロジック実装を使用して、ユーザーに代わって任意の操作を実行できます。脆弱性が発見されても、ユーザーは白紙小切手を撤回することはできません。この外部アカウント (EOA) は永久に侵害されています。

正しい呼び出し元プログラムを書くのは難しく、EIP 3074 の最後にある呼び出し元が注意すべきチェック/脆弱性/状況の完全ではないリストで証明されているように、呼び出し元が時折バグアウトすることはほぼ確実です。リストは今後さらに長くなるのは必至で、おそらく苦痛を伴う発見プロセスが必要となるだろう。

さらに、悪意のある攻撃者は、一見無害な呼び出し元プログラムを作成する可能性がありますが、多数の外部アカウントが呼び出し元を認証するまで攻撃者によって悪用されない微妙な脆弱性を意図的に残す可能性があります。

副題

ガバナンスハイジャックの例

悪意のある分散型取引所 EveSwap は、ユーザーのために呼び出し側プログラムを作成しました。この呼び出し元プログラムは、EVE トークンをエアドロップすることでユーザーにガス資金を提供し、ユーザーの承認と転送トランザクションをバッチ処理します。
EveSwap の呼び出し元プログラムは一見無害で、ユーザーのトークンを盗むことはありません。それは、すぐに公開されてしまうからです。
ユーザーは満足しています。取引はすべて成功し、取引手数料も安かった。何事もなく過ごした数ヶ月でした。
ただし、誰かが EveSwap を使用して、AliceSwap のガバナンストークン ALI を取引するたびに、ユーザーの AliceSwap 投票権は自動的に EveSwap に委任されます。
認可された数が特定のしきい値に達すると、EveSwap はガバナンス提案を通じて AliceSwap をハイジャックします。
副題

クロスチェーンリプレイの例

EIP 3074 は、コミットにチェーン ID を含めるべきであることを合理的に示唆しています。ただし、これはプロトコルではなく呼び出し元によって強制されます。別のチェーン上の同じアドレスを持つ発信者は、このチェックをスキップできます (またはその点についてはチェックします)。

EveSwap は、EIP 3074 をサポートする EVM 互換の BobSpongeChain 上で実行されます。 EveSwap は、BobSpongeChain に正直な呼び出し元をデプロイします。
ユーザーはこの呼び出し元を使用して BobSpongeChain で取引し、ブリッジを使用して資産をイーサリアムに転送します。
EveSwap は、同じデプロイメントキーを使用して、イーサリアム上に同じアドレスを持つ別の呼び出し元をデプロイします。 Ethereum 上のこの呼び出し元はコミットをチェックせず、ownerOnly のみをチェックし、その所有者の汎用 AUTH/AUTHCALL プロキシとして機能します。
このようにして、EveSwap はイーサリアム上のユーザーの外部アカウントをハイジャックし、その資産を奪うことができます。
ユーザーはイーサリアムで取引したことがなく、BobSpongeChain で実行されている呼び出し側プログラムは厳格なセキュリティ審査を受けています。それにもかかわらず、ユーザーは資産全体を失いました。
副題

他に何ができるでしょうか？

私の提案は、プロトコルレベルでコミットの意味を強制する、より明示的なメカニズムを実装することです。コミット構造は (EIP 712 で説明されているように) 型付けされ、ウォレットはユーザーが読み取り可能な形式でコミットを表示します。ユーザーは、呼び出し側プログラムの開発者の性格や能力に依存することなく、トランザクションがどのようなものかを正確に知ることができ、このトランザクションがどのチェーンでもリプレイされないことを確信できます。

可能な実装:

AUTH は、コミットハッシュを、承認された呼び出しのリストを含む型指定された構造体に置き換えます。各呼び出しでは、{nonce,to,gas,calldata,value,chainid} を指定します。署名が検証され、承認された呼び出しのリスト全体が、承認されたアドレス変数ではなく、authorized_transactions として保存されます。

AUTHCALL は、最後の AUTH によって作成されたリスト内のアドレスを指す新しいパラメーターインデックスを取得します。

ユーザーアドレスのノンスはAUTHCALLでインクリメントされます。 nonce は呼び出し元によって保存されるのではなく、実際のアカウント nonce です。

利益：

ユーザーは状況を明確に理解できます。
セキュリティはプロトコルによって保証されます。
バッチおよびアカウントの抽象化は引き続きサポートされています。
短所:
nonce 実装は並列処理をサポートしていません。
複雑な呼び出し側プログラムのトランザクションは、ユーザーが呼び出しのリスト全体を確認して受け入れる必要があるため、煩雑になる場合があります。
実装が異なれば、サポートされる nonce スキームも異なる場合があります。ただし、使用するメカニズムが何であれ、そのメカニズムは呼び出し元ではなくプロトコルによって実装される必要があります。
副題