戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

基本情報技術者 2017年 秋期 午後 問01


SSHによる通信に関する次の記述を読んで、設問1~4に答えよ。

 SSHは遠隔ログインのための通信プロトコル及びソフトウェアであり、通信データの盗聴対策や、通信相手のなりすましを防ぐ仕組みを備えている。SSHでは、サーバにログインしてデータをやり取りする通信(以下、ログインセッションという)に先立って、安全な通信経路の確立と利用者認証を行う必要がある。安全な通信経路の確立、利用者認証及びログインセッションを合わせてSSHセッションと呼ぶ。その流れを、図1に示す。
基本情報技術者試験(平成29年 午後 問1 図1)   〔安全な通信経路の確立の概要〕  安全な通信経路の確立は、次のようにして行う。
(1) クライアントがサーバにアクセスする。 (2) サーバとクライアントが、SSHセッションで使用する暗号アルゴリズムについて合意する。 (3) サーバとクライアントが、通信データの暗号化に使用するセッション鍵と、他のSSHセッションと区別するためのセッション識別子について合意する。 (4) ①クライアントがサーバ認証を行う。サーバ認証では、クライアントがあらかじめ入手して正当性を確認しておいたaを用い、サーバによるセッション識別子へのディジタル署名が正しいかどうかを検証する。 (5) 合意した暗号アルゴリズムとセッション鍵を用いて、②共通鍵暗号方式による通信データの暗号化を開始する。これ以降の通信は、全て暗号化される。   〔利用者認証の概要〕  クライアントからサーバへのログインでは、サーバは利用者認証を行う。SSHの利用者認証の方式には、ディジタル署名を用いる“公開鍵認証”とパスワードを用いる“パスワード認証”がある。  “公開鍵認証”では、クライアントの公開鍵を事前にサーバに登録しておき、この登録されている公開鍵に対応する秘密鍵をクライアントがもっていることをサーバが確認する。この確認では、クライアントがセッション識別子などに対するディジタル署名をサーバに送信し、サーバがbを用いてディジタル署名を検証する。  “パスワード認証”では、クライアントが利用者IDとパスワードを送信し、サーバは受け取ったパスワードが当該利用者のパスワードと一致していることを検証する。  なお、③“パスワード認証”は、“公開鍵認証”に比べて、安全性が低いと考えられている。

設問1:

問題文を見る
 本文中のに入れる適切な答えを、解答群の中から選べ。   a, bに関する解答群  ア:安全な通信経路の確立時に合意したセッション鍵  イ:クライアントの公開鍵  ウ:クライアントの秘密鍵  エ:サーバの公開鍵  オ:サーバの秘密鍵

模範解答

a:エ、b:イ

解説

解答の導き方

この問題では、サーバを確かめるときと、ログインする利用者を確かめるときに、それぞれどの鍵を使うかを区別します。
SSH(Secure Shell:遠隔ログインなどに使う通信の仕組み)では、公開鍵と秘密鍵の組合せを使った認証があります。公開鍵は相手に渡してよい鍵で、秘密鍵は本人だけが保管する鍵です。ディジタル署名(データが本人によって作られ、途中で改ざんされていないことを確かめるための情報)は、秘密鍵で作り、対応する公開鍵で検証します。
  1. aは、サーバが正しいかを確かめるための鍵です。
    本文では、クライアントが「サーバによるセッション識別子へのディジタル署名」を検証するとあります。セッション識別子は、SSHセッションを他のセッションと区別するための値です。
    サーバが自分の秘密鍵で作った署名を、クライアントが検証するには、対応するサーバの公開鍵を使います。また、その公開鍵をクライアントが事前に入手して正当性を確認しておくことで、偽のサーバの鍵を使わされることを防ぎます。したがって、aは「サーバの公開鍵」(エ)です。
  2. bは、ログインしようとしているクライアントを確かめるための鍵です。
    本文では、クライアントの公開鍵をあらかじめサーバに登録し、対応する秘密鍵をクライアントが持っていることを確認するとあります。
    クライアントは自分の秘密鍵で署名を作ります。サーバは、その署名を登録済みのクライアントの公開鍵で検証します。したがって、bは「クライアントの公開鍵」(イ)です。
サーバ認証ではサーバの公開鍵をクライアントが使い、利用者認証ではクライアントの公開鍵をサーバが使います。誰が誰を確かめているのかを整理すると、2つの空欄を区別できます。
なお、本文の「共通鍵暗号方式」は、通信する双方が同じ鍵を使ってデータを暗号化・復号する方式です。SSHでは安全な通信経路を確立した後、合意したセッション鍵を使って通信データを暗号化します。

誤りやすいポイント

  • 署名を作る鍵と、署名を検証する鍵を逆にすること
    署名は秘密鍵で作り、対応する公開鍵で検証します。秘密鍵を相手に渡して検証してもらうわけではありません。
  • サーバ認証と利用者認証で、同じ公開鍵を使うと思い込むこと
    aではサーバの署名をクライアントが確かめるため、サーバの公開鍵を使います。bではクライアントの署名をサーバが確かめるため、クライアントの公開鍵を使います。
  • 「公開鍵認証」では公開鍵を秘密にすると思うこと
    公開鍵は相手に登録・配布できます。本人だけが持つ秘密鍵を使って署名を作れることを、公開鍵で確認します。
  • パスワード認証では通信が暗号化されないと思うこと
    SSHでは、利用者認証の前に安全な通信経路を確立します。そのため、パスワード認証でも通信データは暗号化されます。ただし、パスワードは推測されたり、使い回しによって漏えいの影響を受けたりする可能性があります。

FAQ

Q: 公開鍵だけで署名を作れますか?
A: いいえ。署名を作るのは秘密鍵です。公開鍵は、その署名が対応する秘密鍵で作られたものかを検証するために使います。
Q: サーバ認証でサーバの秘密鍵をクライアントに渡さないのはなぜですか?
A: 秘密鍵はサーバ本人だけが持つ必要があるためです。クライアントには公開鍵を渡しておけば、サーバの秘密鍵を明かさずに署名を検証できます。
Q: パスワード認証の通信も暗号化されますか?
A: はい。SSHでは安全な通信経路を確立した後に利用者認証を行うため、パスワードも暗号化された通信の中で送られます。

関連キーワード: SSH、公開鍵認証、ディジタル署名、共通鍵暗号方式、セッション識別子

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

 本文中の下線①によって防ぐことができる攻撃として適切な答えを、解答群の中から選べ。   解答群  ア:DoS攻撃  イ:SQLインジェクション  ウ:クロスサイトスクリプティング  エ:総当たり攻撃  オ:中間者攻撃

模範解答

オ

解説

解答の導き方

設問は、下線①の「クライアントがサーバ認証を行う」ことで防げる攻撃を問うています。
SSH(Secure Shell:遠隔ログインなどの通信を安全に行う仕組み)では、安全な通信経路を作る段階で、クライアントが接続先のサーバが本物かどうかを確かめます。
本文には、クライアントが「正当性を確認しておいた」サーバの公開鍵を使い、サーバがセッション識別子に付けたディジタル署名を検証するとあります。ディジタル署名は、送信者が本人であることや、データが改ざんされていないことを確かめるための仕組みです。サーバが秘密鍵で署名し、クライアントが対応する公開鍵で検証します。
ここで重要なのは、通信を暗号化するだけでは、接続相手が本物だとは限らないことです。攻撃者がクライアントと本物のサーバの間に入り、サーバになりすまして通信を中継することがあります。これが中間者攻撃です。クライアントがサーバの署名を検証すれば、攻撃者が本物のサーバの秘密鍵を持っていない限り、正しい署名を作れないため、なりすましに気付けます。
したがって、下線①によって防ぐことができる攻撃は、中間者攻撃です。
ほかの選択肢は、攻撃の目的や方法が異なります。DoS攻撃はサービスを利用できなくする攻撃、SQLインジェクションはデータベースへの不正な命令の実行を狙う攻撃、クロスサイトスクリプティングはWebページに悪意のあるスクリプトを実行させる攻撃、総当たり攻撃はパスワードなどを次々に試す攻撃です。サーバ認証で接続相手を確かめることとは、直接対応しません。

誤りやすいポイント

  • 通信が暗号化されているだけで、接続相手も本物だと思い込まないようにしましょう。相手が攻撃者でも、その相手との通信が暗号化される場合があります。
  • 下線①は「サーバ認証」です。クライアントが本物のサーバかどうかを確かめます。利用者をサーバが確かめる「利用者認証」とは向きが逆です。
  • 公開鍵認証やパスワード認証は、本文ではログインする利用者の認証方式として説明されています。下線①のサーバ認証とは区別して考えましょう。

FAQ

Q: サーバ認証では、何を確認していますか?
A: 接続先が、クライアントが正当性を確認しておいたサーバであることを確認しています。サーバのディジタル署名を、対応する公開鍵で検証します。
Q: 通信を暗号化すれば、中間者攻撃は防げませんか?
A: 暗号化だけでは不十分です。攻撃者を相手にして暗号化通信を始めてしまう可能性があるため、通信相手が本物かどうかの確認も必要です。
Q: 総当たり攻撃とは、どのような攻撃ですか?
A: パスワードなどの候補を次々に試して、正しいものを見つけようとする攻撃です。接続相手のなりすましを見破るサーバ認証とは、対策の対象が異なります。

関連キーワード: SSH、サーバ認証、ディジタル署名、公開鍵暗号方式、中間者攻撃、セッション識別子

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

 本文中の下線②について、通信データの暗号化に公開鍵暗号方式ではなく共通鍵暗号方式を用いる理由として適切な答えを、解答群の中から選べ。   解答群  ア:共通鍵暗号方式は、公開鍵暗号方式よりも暗号処理が高速である。  イ:共通鍵暗号方式は、公開鍵暗号方式よりも解読に時間が掛かる。  ウ:共通鍵暗号方式は、公開鍵暗号方式よりも鍵の再利用が容易である。  エ:共通鍵暗号方式は、公開鍵暗号方式よりも鍵の配布が容易である。

模範解答

ア

解説

解答の導き方

この設問は、SSHでやり取りする通信データを、なぜ公開鍵暗号方式ではなく共通鍵暗号方式で暗号化するのかを問うています。
共通鍵暗号方式は、送信側と受信側が同じ鍵を使って暗号化・復号する方式です。一方、公開鍵暗号方式は、公開する鍵と秘密にする鍵の対になる鍵を使う方式です。
問題文では、安全な通信経路を確立した後、「合意した暗号アルゴリズムとセッション鍵を用いて」通信データの暗号化を始めるとあります。セッション鍵とは、そのSSHセッションで通信データを暗号化するための鍵です。
通信データは、ログイン後も続けて送受信されます。そのため、暗号化と復号を何度も行うことになります。一般に、共通鍵暗号方式は公開鍵暗号方式より暗号処理が高速です。大量の通信データを効率よく処理できるので、通信データの暗号化には共通鍵暗号方式が使われます。
これが、選択肢アが適切な理由です。SSHでは、公開鍵暗号方式を使う場面もあります。本文では、サーバの正当性の確認や利用者認証にディジタル署名を使うと説明されています。つまり、公開鍵暗号方式と共通鍵暗号方式は、どちらか一方だけを使うのではなく、役割に応じて使い分けます。
ほかの選択肢は、理由として適切ではありません。
  • イは、解読にかかる時間を方式だけで一律に比べることはできず、通信データの暗号化を共通鍵暗号方式で行う理由にはなりません。
  • ウは、鍵を再利用しやすいことが、通信データの暗号化に共通鍵暗号方式を使う理由ではありません。鍵の再利用は、安全性の面からも安易に行うべきではありません。
  • エは、鍵の配布についての説明です。公開鍵暗号方式では公開鍵を配布しやすい一方、共通鍵暗号方式では同じ鍵を安全に共有する必要があります。通信データの暗号化に共通鍵暗号方式を選ぶ主な理由とは異なります。

誤りやすいポイント

  • 「公開鍵暗号方式のほうが安全だから、通信データも公開鍵で暗号化する」と考えることです。方式の使い分けでは、安全性だけでなく処理速度も考慮します。
  • 共通鍵暗号方式と公開鍵暗号方式を、SSHではどちらか一方しか使わないと思うことです。SSHでは、認証などに公開鍵暗号方式を使い、通信データの暗号化には処理の速い共通鍵暗号方式を使います。
  • 選択肢エの「鍵の配布が容易」という特徴を、共通鍵暗号方式の特徴と取り違えることです。共通鍵は、通信する相手同士で同じ鍵を安全に共有する必要があります。

FAQ

Q: 共通鍵暗号方式の鍵は、通信のたびに変わるのですか?
A: この問題では、通信データの暗号化に使う鍵を「セッション鍵」と呼んでいます。問題文では、そのSSHセッションで使う鍵について合意すると説明されています。
Q: 公開鍵暗号方式は、SSHの中で何に使われますか?
A: 本文では、サーバの正当性を確認するためのディジタル署名や、公開鍵認証での署名の検証に関係しています。通信データを効率よく暗号化する役割とは分けて考えます。
Q: 共通鍵暗号方式のほうが、必ず安全性も高いのですか?
A: この設問で問われているのは処理速度です。安全性は、暗号方式や鍵の長さなどによって異なるため、「共通鍵暗号方式のほうが必ず安全」とは言えません。

関連キーワード: 共通鍵暗号方式、公開鍵暗号方式、セッション鍵、ディジタル署名、SSH

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

 本文中の下線③のように考えられている理由として適切な答えを、解答群の中から選べ。   解答群  ア:“パスワード認証”では、サーバが攻撃者に乗っ取られていた場合、送信したパスワードを攻撃者に取得されてしまう。  イ:“パスワード認証”では、正当なサーバとは異なるサーバに接続させられてしまっても利用者が気づけない。  ウ:“パスワード認証”では、パスワードだけを用いるが、“公開鍵認証”では、パスワードの他にディジタル署名も用いる。  エ:“パスワード認証”では、利用者のパスワードが平文でネットワーク上を流れるので、盗聴されるとパスワードを取得されてしまう。

模範解答

ア

解説

解答の導き方

この設問は、“パスワード認証”が“公開鍵認証”より安全性が低いと考えられる理由を問うています。SSH(Secure Shell:通信内容を暗号化して遠隔操作する仕組み)では、通信相手を確かめたうえで、通信データを暗号化します。
まず、パスワードがネットワーク上で盗み見られるかを考えます。本文では、利用者認証の前に安全な通信経路を確立し、その後の通信は「全て暗号化される」と説明されています。そのため、通信の途中でパスワードを盗み見られるというエの説明は当てはまりません。
次に、正当なサーバとは異なるサーバに接続させられる場合を考えます。本文では、クライアントが事前に正当性を確認したサーバの公開鍵(暗号化や署名の確認に使う鍵)を用いてサーバ認証を行います。したがって、接続先が正当なサーバかどうかを確認する仕組みはあり、イは適切ではありません。
では、サーバ自体が攻撃者に乗っ取られていたらどうでしょうか。“パスワード認証”では、利用者が送ったパスワードをサーバが受け取って確認します。通信中は暗号化されていても、サーバに届いた後はサーバ側でパスワードを扱うため、乗っ取った攻撃者に取得されるおそれがあります。
一方、“公開鍵認証”では、クライアントは秘密鍵(本人だけが持つ鍵)でディジタル署名(データが本人によって作られ、改ざんされていないことを確認するための情報)を作って送ります。秘密鍵そのものはサーバに送られません。サーバは登録済みの公開鍵を使って署名を検証するため、サーバが乗っ取られても、パスワード認証のように利用者のパスワードを取得される状況とは異なります。
この違いから、サーバが乗っ取られている場合に送信したパスワードを取得されるというアが、本文の説明に最も合います。ウは、“公開鍵認証”でパスワードも使うとしている点が誤りです。

誤りやすいポイント

  • 通信が暗号化されているから、パスワード認証も安全だと考えること
    暗号化は、通信の途中で内容を盗み見られるのを防ぎます。しかし、パスワードを受け取るサーバ自体が乗っ取られている場合、そのサーバ上でパスワードを取得される可能性は残ります。
  • “パスワード認証”ではパスワードが平文で流れると思い込むこと
    SSHでは利用者認証の前に安全な通信経路を確立します。本文の条件では、パスワードがネットワーク上を平文で流れるわけではありません。
  • “公開鍵認証”でもパスワードを併用すると考えること
    この問題で示されている“公開鍵認証”は、秘密鍵による署名を公開鍵で検証する方式です。パスワードを追加で使う方式ではありません。

FAQ

Q: サーバ認証があるのに、サーバが乗っ取られることは防げないのですか?
A: サーバ認証は、接続先が事前に確認したサーバに対応するかを確かめる仕組みです。正当なサーバが攻撃者に乗っ取られた場合、そのサーバ内部での不正な動作までは防げません。
Q: “公開鍵認証”では、クライアントは何をサーバに送るのですか?
A: 本文では、クライアントはセッション識別子などに対するディジタル署名を送ります。秘密鍵そのものを送るのではなく、サーバが登録済みの公開鍵で署名を検証します。
Q: SSHで通信が暗号化されていれば、サーバに届いたパスワードも攻撃者に見られませんか?
A: 通信経路上では暗号化されますが、パスワードを受け取るサーバでは認証のために扱われます。サーバが乗っ取られていれば、攻撃者がその情報を取得するおそれがあります。

関連キーワード: SSH、パスワード認証、公開鍵認証、共通鍵暗号方式、ディジタル署名

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

基本情報技術者を
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について