クライアントに新しい資格情報を登録するように要求するときに、WebAuthnがチャレンジを要求するのはなぜですか？
WebAuthnの一部として 新しい資格情報を登録する の場合、クライアントに challenge を送信する必要があるのはなぜですか？
おそらくこれはリプレイ攻撃を防ぐためですが、リプレイ攻撃はすでにTLSによって防止されていないのではないでしょうか？
私はこれについて多くのことを尋ねましたが、決定的な答えを見つけることができませんでした。ただし、次の理由により、課題が必要だと思います。
リプレイ攻撃は主にTLSで防ぐ必要がありますが、前述のように here および here TLSを使用しても、ユーザーまたはユーザーのブラウザーをだまして、リプレイ攻撃を実行することは可能です。要求を再試行してください。したがって、この課題は、TLSのリプレイ防止メカニズムのギャップをカバーするのに役立ちます。
たとえば、攻撃者がチャレンジが必要ない場合、次のシナリオでユーザーのIDを侵害する可能性があります。
- ユーザーが新しい資格情報を登録しようとしました。
- その要求は真ん中の人によって保持され、TCP=リセットがユーザーのブラウザに送信されます。
- ユーザーのブラウザーは要求を再試行し、新しい資格情報を正常に登録します。
- 短期間のうちに、ユーザーは資格情報の登録を取り消すことにしました。
この場合も、短期間のうちに、途中の男が元の要求をサーバーに解放するため、ユーザーの知らないうちに資格情報が再登録されます。
しばらくして、真ん中の男がユーザーのFIDO2オーセンティケーターを盗みます。
- 真ん中の男がユーザーのポーズをとることができます。
更新
ネットワーク内のノードが侵害された結果としてリプレイ攻撃が発生する必要はなく、オペレーティングシステムまたはブラウザーが侵害された結果としても発生する可能性があることを認識した後、私は次の例を考えなければなりません。登録時の課題：
- 攻撃者はユーザーのブラウザを制御します。
- ユーザーが新しい資格情報を登録すると、侵害されたブラウザーがPublicKeyCredentialをインターセプトしてから、サーバーに送信します。
- 攻撃者はユーザーのFIDO2オーセンティケーターを盗みます。
- ユーザーは資格を登録解除します。
- ユーザーが新しい認証情報を登録しようとすると、侵害されたブラウザは新しい認証情報ではなく古いPublicKeyCredentialを送信します。
- 攻撃者はユーザーを装うことができます。
ユーザーのオペレーティングシステムが危険にさらされ、登録時にチャレンジが使用されなかった場合にも、非常に類似したシナリオが発生する可能性があります。
また、これらのシナリオは、依存パーティが、攻撃者が簡単に解読できない特定のデバイスで登録/認証を実行する必要がある場合にのみ関連します。
この側面は本質的に1つの形式の challenge-response authentication になります。
先に述べたように、依存パーティ（RP）は（うまくいけば）ランダムな値に基づいてチャレンジを選択するため、リプレイ攻撃を防ぎます。
これは認証の方法でもあります：予測できないランダムな値に署名することにより、認証者は、信頼できるパーティ（RP）に対して暗号化された安全な方法で証明します。実際には、提示されている公開鍵に属する秘密鍵を制御しています。