はじめに: ETH2 におけるタイムサーバー攻撃と緩和策
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)ここ、著者: dankrad、翻訳: A Jian、Odaily の許可を得て転載。
要約: Eth2 におけるタイムサーバー攻撃についても以前に議論されました。しかし、これまでのところ、この種の攻撃はバリデーターを一時的にオフラインにするだけで、ノードオペレーターが正しい時刻同期手段を再確立するのを待つだけで、ノードはオンラインに戻ることができる、というのが主流の意見です。ただし、ノードがだまされて遠い将来のエポックの証明書に署名できる場合、危険は単に一時的にオフラインになるだけではありません。コンセンサス アルゴリズムのラップアラウンド 投票スラッシュ ルールにより、これらのノードはそのエポックに到達できなくなります。ネットワーク全体が実際に到達するまで、誤って送信された認証メッセージのターゲット エポックが経過するまで、これ以上認証メッセージに署名することはできません (そうでない場合はスラッシュがトリガーされます)。
ここ
）。コンセンサスルールの運用下では、この種のタイムサーバー攻撃は、攻撃された検証者をほぼ永久にオフラインにし、関連する利害関係者も非活動漏洩による大きな代償を支払うことになります。
攻撃対象領域
次のようにタイム サーバー攻撃をでっち上げることができます。最初のステップは、タイム サーバーの時刻を操作して将来の特定の時刻にジャンプすることです。これにより、攻撃される検証者の時刻も未来にジャンプします (たとえば、15 時)。 20 日まで)、この時間は、怠惰ペナルティによってバリデーターの残高がゼロになる時間より短くなければなりません。そうでない場合、バリデーターは構成証明メッセージに再度署名しません。
結果
次に、関連するノードをだまして、実際にチェーンと同期していると思わせ、証明書に署名する必要があります。これは、攻撃者が複数のピアを制御している場合、将来、ピアツーピア ネットワーク チャネルでいくつかの証明書とブロックを送信するだけで常に可能です。複数のノードの制御も簡単に実現できるため、これは攻撃者の非現実的な想定ではありません。
ターゲットのバリデーターが将来のエポックを対象とした構成証明メッセージに署名すると、攻撃者はメッセージを保存し、ネットワーク全体が実際にその将来のエポックに到達するまで、バリデーターがそれ以上の構成証明に署名できないようにすることができます (そうでない場合、攻撃者はこのメッセージを送信する可能性があります)メッセージが表示され、スラッシュが発生します)。現在 Eth2 に実装されているすべてのバリデーター クライアントには、バリデーターが矛盾する証明書に署名することを防ぐ手段があり、そのためバリデーターは事実上オフラインになります。
結果
攻撃者は、タイム サーバー (または、roughtime などの同様の機能) を使用して、TA が影響を与える可能性のあるすべてのバリデーターを排除する可能性があります。このような攻撃は、同じインターフェースを使用して以前に考えられた攻撃 [2] よりも悪くなるでしょう。なぜなら、その効果は一時的なものではなく、はるかに永続的なものだからです。このような攻撃を数分以内に検出でき、すべてのプロフェッショナル ノードが数時間以内に通常の時間に回復できる可能性はありますが、ダメージがすでに発生しているため役に立ちません。また、バリデーターにつながる可能性があります。怠惰のペナルティが指数関数的に増加するため、多くのバリデーターがネットワークから撤退する可能性があります。
緩和
バリデータクライアントの非スラッシュルールを追加
検証クライアントに非スラッシュ ルールを追加できます。すべてのメッセージに署名する前に現在の時刻を評価することを要求し、将来のメッセージに事前署名しないように要求します。この方法は実際には、バリデータ クライアントとビーコン チェーン ノードが同じマシン上に展開されておらず、攻撃の影響を受けない場合にのみ役立ちます。ただし、このルールにより、リーダーはバリデーターのアクションをブロックする可能性のある将来の認証メッセージを提案することができないため、これはキー分割バリデーターにとっては明らかな改善です。
時刻同期対策のための保護をさらに追加する
