H31春  午後1問2  設問2(3)
IPA回答とは別となりますが、ある参考書や、複数のサイトより
「攻撃者はオーセンティケータの秘密鍵Kを入手できず、署名Mを再生成できないから」
という回答がございました。

こちらについて疑問があります。
署名Mを再生成しなくても、Webブラウザと認証サーバXの間でMITBにより取得した署名Mをそのまま使うことで、認証がPassすると思うのですが、なぜ中間者が「署名Mを再生成」する必要があるのでしょうか。

ちなみにIPAでは「オリジンの一致を確認している」ことが回答となっていますが、仮に攻撃者が、本物のWebサーバのオリジンと同じオリジンを用意していた場合を想定しております。

まず、オリジンbは、ブラウザはHTTPで接続していますから、
HTTP://～
であり、オリジンsは、認証サーバXのWebサイトですから、
HTTPS://～
であり、オリジンb≒オリジンsです。(「～」の部分は同じ)

攻撃者は、認証をパスするためには、オリジンbをオリジンsに書き換える必要がありますが、署名Mは、オリジンbを基に秘密鍵Kで生成していますから、秘密鍵Kをもたない攻撃者は、オリジンsを基にした署名M'を生成することができません。

IPAの「オリジンの一致を確認している」よりも、「攻撃者はオーセンティケータの秘密鍵Kを入手できず、署名Mを再生成できないから」の方がしっくりきます。

なお、この仕組みは、MITB攻撃に対して、トークンでトランザクション署名を作成する対策と類似しています。

助け人さん、早急なご回答ありがとうございます。

> まず、オリジンbは、ブラウザはHTTPで接続していますから、
> HTTP://～
> であり、オリジンsは、認証サーバXのWebサイトですから、
> HTTPS://～
> であり、オリジンb≒オリジンsです。(「～」の部分は同じ)
上記については、下記質問及び回答の説明にて理解いたしました。
https://www.sc-siken.com/bbs/0386.html


> IPAの「オリジンの一致を確認している」よりも、「攻撃者はオーセンティケータの秘密鍵Kを入手できず、署名Mを再生成できないから」の方がしっくりきます。
そうですね、私もこちらのほうがWebAuthnのディジタル署名を利用するという部分で、回答としてはスマートだと感じております。

> なお、この仕組みは、MITB攻撃に対して、トークンでトランザクション署名を作成する対策と類似しています。
ありがとうございます、トランザクション署名の仕組みについて調べさせていただきました。
こちらの用途は特に銀行系で使用されていることが多く、署名内に口座情報等を入れることで、改ざんの有無を確認しているのですね。
確かに今回の認証方法とフローは一緒になりますね、勉強になりました。


> 攻撃者は、認証をパスするためには、オリジンbをオリジンsに書き換える必要がありますが、署名Mは、オリジンbを基に秘密鍵Kで生成していますから、秘密鍵Kをもたない攻撃者は、オリジンsを基にした署名M'を生成することができません。
なるほど、こちらの場合でも結局署名Mがオリジンbを基に作成してしまってるため、正規のオリジンsを使った署名を再生成しないといけないということですね。

追加で本問題の前提を変えて1点確認させていただいてもよろしいでしょうか。
仮に攻撃者が全く同じオリジン、つまりhttpsサイトを用意した場合を想定したとします。
その場合、攻撃者はWebブラウザから送られてきた署名Mを盗聴すれば、その署名Mをそのまま利用でき、認証をPassすることができると思いますが、こちらの認識は合っておりますでしょうか。

ただその場合、利用者にブラウザの警告画面が表示されるかと思いますが、こちらは利用者が無視して、URLにアクセスしてしまったケースという前提とさせてください。

利用者がブラウザの警告を無視したら、署名Mを盗聴して認証をパスできるという認識で合っています。

攻撃者がDNSキャッシュポイズニングなどにより偽サイトに誘導したり、攻撃者がブラウザと正規サイトの間に介在して中間者攻撃を行ったりする際の対策として、ディジタル証明書が有効ですが、あくまでも、「不正なディジタル証明書に対するブラウザの警告が出たら利用者は接続しない」と、利用者次第です。

ご説明いただきありがとうございます。
挙動について理解することができました、大変助かりました！