HOME»情報処理安全確保支援士掲示板»平成31年春午後I問2図3〜図6
投稿する
図3の下に「ドメイン:IDaaS-Xのドメイン名」と明記さてれいます。
一般的にTOTPアプリや、オーセンティケータは複数のシステムの認証に対応する
ことができます。
システムを識別するために、システムが利用している認証システムのドメインが
利用されます。
そのため、ドメイン別に秘密鍵・公開鍵を生成する必要があります。
本文中に明記されていませんが、その認識でよいかと思います。
オリジンs(図5参照)のドメイン部分と、IDaaS-Xのドメイン名は一致していると
考えられます。
しかし、本設問のフローは以前から難解な部分があるため、一致しているというのも
多分そうであると考えてください。
また、オリジンbとオリジンsを比較する理由ですが、この点についても現在でも
明確な解答は出ていません。
解答の候補として、偽の認証サーバXにアクセスした場合、偽の認証サーバXの
スキームは(h)ttp://で、本物の認証サーバXのスキームは(h)ttps://になるため
オリジンを比較するとその違いが検出できるというものです。
本問の前半でHSTSでスキームが異なるサーバへの接続をテーマにしていました。
この設問でも、攻撃者は中間者攻撃として偽の認証サーバを用意する攻撃を
想定し、その際のスキームは異なったものが使われると考えております。
平成31年春午後I問2図3〜図6 [1440]
きなこさん(No.1)
図3〜図6のフローについて理解したく、まず質問になるのですが、このフローでやり取りされている「ドメイン」というのは、ここではメールサービスPのドメインのことでしょうか。
またここでドメインをやりとりする必要性について、図3.図4ではドメインごとに
共通鍵を生成・登録して利用するため、図5.6では、利用者IDにあわせてドメイン別にも秘密鍵、公開鍵を生成する必要があるようなイメージであいますでしようか。(要は利用者IDだけでなく、ドメインごとにも認証準備・検証が必要というイメージかなと)
変な質問でしたらすみません、よろしくお願いいたします。
またここでドメインをやりとりする必要性について、図3.図4ではドメインごとに
共通鍵を生成・登録して利用するため、図5.6では、利用者IDにあわせてドメイン別にも秘密鍵、公開鍵を生成する必要があるようなイメージであいますでしようか。(要は利用者IDだけでなく、ドメインごとにも認証準備・検証が必要というイメージかなと)
変な質問でしたらすみません、よろしくお願いいたします。
2024.03.24 16:14
pixさん(No.2)
★SC ダイヤモンドマイスター
>図3〜図6のフローについて理解したく、まず質問になるのですが、このフローで
>やり取りされている「ドメイン」というのは、ここではメールサービスPの
>ドメインのことでしょうか
図3の下に「ドメイン:IDaaS-Xのドメイン名」と明記さてれいます。
一般的にTOTPアプリや、オーセンティケータは複数のシステムの認証に対応する
ことができます。
システムを識別するために、システムが利用している認証システムのドメインが
利用されます。
そのため、ドメイン別に秘密鍵・公開鍵を生成する必要があります。
2024.03.24 17:29
きなこさん(No.3)
いつもご回答ありがとうございます。
図3の下に明記されてましたね、ごめんなさい。
ちょっと変な質問になるかもしれませんが、ということは認識サーバxのwebサイトのオリジンs(図5参照)のドメイン部分と、IDaaS-Xのドメイン名は一致しているということでしょうか。(もし誤ってましたらご指摘いただけますと幸いです。)
→なるほど、複数の認証システムに利用されるから、認証にドメインが利用され、ドメイン別に秘密鍵・公開鍵を生成する必要があるのですね、ありがとうございます。
図3の下に明記されてましたね、ごめんなさい。
ちょっと変な質問になるかもしれませんが、ということは認識サーバxのwebサイトのオリジンs(図5参照)のドメイン部分と、IDaaS-Xのドメイン名は一致しているということでしょうか。(もし誤ってましたらご指摘いただけますと幸いです。)
> 一般的にTOTPアプリや、オーセンティケータは複数のシステムの認証に対応することができます。システムを識別するために、システムが利用している認証システムのドメインが利用されます。そのため、ドメイン別に秘密鍵・公開鍵を生成する必要があります。
→なるほど、複数の認証システムに利用されるから、認証にドメインが利用され、ドメイン別に秘密鍵・公開鍵を生成する必要があるのですね、ありがとうございます。
2024.03.24 19:00
pixさん(No.4)
★SC ダイヤモンドマイスター
>ちょっと変な質問になるかもしれませんが、ということは認識サーバxのwebサイトの
>オリジンs(図5参照)のドメイン部分と、IDaaS-Xのドメイン名は一致していると
>いうことでしょうか。(もし誤ってましたらご指摘いただけますと幸いです。)
本文中に明記されていませんが、その認識でよいかと思います。
オリジンs(図5参照)のドメイン部分と、IDaaS-Xのドメイン名は一致していると
考えられます。
しかし、本設問のフローは以前から難解な部分があるため、一致しているというのも
多分そうであると考えてください。
また、オリジンbとオリジンsを比較する理由ですが、この点についても現在でも
明確な解答は出ていません。
解答の候補として、偽の認証サーバXにアクセスした場合、偽の認証サーバXの
スキームは(h)ttp://で、本物の認証サーバXのスキームは(h)ttps://になるため
オリジンを比較するとその違いが検出できるというものです。
2024.03.24 19:18
きなこさん(No.5)
ご回答ありがとうございます。難解な部分も多いんですね。多分、一致である旨承知しました。
→私はてっきり、偽の認識サーバXはドメインが違うのかなと思いましたが、図5の認証フロー、鍵の生成でドメインを利用しているとなると、確かにドメインが異なることは考えづらいですね。それで、消去法として、スキームがhttpで異なる、という認識でしょうか。
> また、オリジンbとオリジンsを比較する理由ですが、この点についても現在でも明確な解答は出ていません。
→私はてっきり、偽の認識サーバXはドメインが違うのかなと思いましたが、図5の認証フロー、鍵の生成でドメインを利用しているとなると、確かにドメインが異なることは考えづらいですね。それで、消去法として、スキームがhttpで異なる、という認識でしょうか。
2024.03.24 23:09
pixさん(No.6)
★SC ダイヤモンドマイスター
>→私はてっきり、偽の認識サーバXはドメインが違うのかなと思いましたが、
>図5の認証フロー、鍵の生成でドメインを利用しているとなると、確かに
>ドメインが異なることは考えづらいですね。それで、消去法として、
>スキームがhttpで異なる、という認識でしょうか。
本問の前半でHSTSでスキームが異なるサーバへの接続をテーマにしていました。
この設問でも、攻撃者は中間者攻撃として偽の認証サーバを用意する攻撃を
想定し、その際のスキームは異なったものが使われると考えております。
2024.03.25 07:37
きなこさん(No.7)
ご回答ありがとうございます。なるほど、確かにテーマ的にもそうですね。
色々とありがとうございました。
色々とありがとうございました。
2024.03.25 08:16