情報セキュリティマネジメント 2026年 科目A 問04
問題文
チャレンジレスポンス認証方式に該当するものはどれか。
選択肢
ア:固定パスワードを、TLSによる暗号通信を使い、クライアントからサーバに送信して、サーバで検証する。
イ:端末のシリアル番号を、クライアントで秘匿鍵を使って暗号化し、サーバに送信して、サーバで検証する。
ウ:トークンという機器が自動的に表示する、認証のたびに異なる数字列をパスワードとしてサーバに送信して、サーバで検証する。
エ:利用者が入力したパスワードと、サーバから受け取ったランダムなデータとをクライアントで演算し、その結果をサーバに送信して、サーバで検証する。(正解)
🔒 解説は解答すると表示されます
チャレンジレスポンス方式【情報セキュリティマネジメント解説】
正解の理由
チャレンジレスポンス方式とは、サーバ側が送る「ランダムな問い(チャレンジ:nonce)」を受けて、クライアント側が利用者の秘密情報(パスワードや鍵)とそのチャレンジを使って計算した「応答(レスポンス)」を返し、サーバ側で照合する認証方式です。これにより、パスワードそのものを通信路で繰り返し送らず、同じ応答が二度と使えないためリプレイ攻撃(過去の通信を使った不正再利用)を防げます。
設問の選択肢のうち、クライアントが「利用者が入力したパスワード」と「サーバから受け取ったランダムなデータ」をクライアント側で演算してその結果を送る記述が該当します。したがって、エが正解です。
(用語補足)チャレンジ(challenge):使い捨てのランダム値。nonce(ナンス)とも呼ばれます。TLS(Transport Layer Security:通信路を暗号化する仕組み)やHMAC(Hash-based Message Authentication Code:鍵付きハッシュ)については補足で触れます。
解法ステップ
- 「サーバ側からランダムなデータを送っているか」を探す。これがチャレンジの有無を見る第一歩です。
- 次に「クライアント側でそのランダムデータを使って計算しているか」を確認する。チャレンジを使うのがチャレンジレスポンス方式の本質です。
- 「計算結果をサーバが検証する」形式になっているかを確認する。サーバ側が同じチャレンジと利用者の秘密で検証可能である必要があります。
- 上の条件を満たす選択肢を選ぶ。設問ではこれに当てはまるのがエだけです。
選択肢別の誤答解説
-
ア: 固定パスワードをTLSで送る
TLS(Transport Layer Security:通信を暗号化する仕組み)で保護された通信は盗聴を防ぎますが、毎回同じパスワードを送信する点でチャレンジレスポンスではありません。通信が解読されない前提に依存するため、パスワードが漏れた場合や中間者攻撃で復号されるリスクがあります。さらに「同一のパスワード送信によるリプレイ」を技術的に区別する仕組みがありません。 -
イ: 端末のシリアル番号をクライアントで秘匿鍵で暗号化して送る
秘匿鍵(プライベートキー)で暗号化=署名のような使い方ならクライアント認証に近いですが、問題文では「端末のシリアル番号」をそのまま暗号化して送るだけで、サーバからのチャレンジ(ランダム値)を使っていません。送る値が毎回同じであればリプレイされやすく、チャレンジレスポンスの定義に合致しません。 -
ウ: トークンが毎回異なる数字列を表示して送る(ワンタイムパスワード)
トークンが自分でワンタイムの値を生成し、その値をパスワードとして送る方式は「ワンタイムパスワード(OTP)」です。OTPは確かにリプレイ対策になりますが、チャレンジ(サーバからのランダム値)を用いる方式とは異なります。OTPはトークン側とサーバ側で時刻やカウンタを同期して照合する仕組みが多く、チャレンジが都度サーバから送られる「チャレンジレスポンス」とは分類が別です。 -
エ: 利用者のパスワードとサーバからのランダムデータをクライアントで演算して送る
サーバが毎回生成するランダムなチャレンジを使い、クライアントが秘密(パスワード等)とチャレンジを組み合わせて計算した結果を返す流れが、チャレンジレスポンスの定義そのものです。よってエが該当します。
よくある誤解
-
チャレンジレスポンスとワンタイムパスワード(OTP)を混同する
どちらも「一度限りの値で認証する」点は似ていますが、チャレンジレスポンスは「サーバが出すチャレンジに対する応答」を使い、OTPはトークンやアプリが独自に生成した一回限りの値をユーザが入力して送る方式です。仕組みと導入・運用の要件が異なります。 -
TLS(HTTPS)でパスワードを送ればチャレンジレスポンスと同等だと思う
TLSは通信の暗号化を提供しますが、パスワード自体をそのまま送る点は変わりません。サーバ側が毎回変化する疑似値で検証しない限り、チャレンジレスポンスの利点(リプレイ耐性やパスワード非送信)は得られません。 -
「クライアント側で暗号化して送る=チャレンジレスポンス」と考える
クライアントで何らかの暗号化やハッシュをしても、サーバ側からのチャレンジが関係しなければ、同一の暗号化値が繰り返される可能性があり、リプレイ攻撃の保護になりません。チャレンジの有無が重要です。
補足コラム
よく使われるチャレンジレスポンスの例
- CHAP(Challenge-Handshake Authentication Protocol):PPP接続などで使われる。サーバがチャレンジを送り、クライアントがパスワードとチャレンジでハッシュを作って返す方式です。
- NTLM(Windowsの古い認証方式)や、一部のスマートカード認証/トークン連携でもチャレンジレスポンスが使われます。
- SRP(Secure Remote Password):パスワードをサーバに直接保存せず相互に証明する、安全性の高いチャレンジレスポンス系プロトコルです。
職場での運用イメージ:VPNや社内システムでチャレンジレスポンスを使う場合、サーバは毎回異なるチャレンジ値を発行します。クライアント(ソフトやトークン)はこれを受け取り、ユーザが入力したパスワードやデバイス内の秘密情報と組み合わせて計算し、サーバは同様の計算または検証アルゴリズムで合致を確認します。このため、パスワードをそのまま通信上に流さず、盗聴や再送信のリスクが下がります。
簡単な動作例(HMACを使った擬似コード):
# クライアント側
import hmac, hashlib
secret = b"user_password_or_key" # 利用者の秘密(実運用では平文ではなく派生値)
challenge = b"server_random_nonce" # サーバが送ったランダム値
response = hmac.new(secret, challenge, hashlib.sha256).hexdigest()
# この response をサーバに送る
# サーバ側は同じ secret と challenge で計算し、一致すれば認証成功
FAQ
Q. チャレンジはどれくらいランダムでなければいけませんか?
A. 「予測できない」ことが重要です。短くて繰り返し使われる値は安全性を損ないます。一般に十分な長さ(数バイト〜数十バイト)でランダムに生成します。
A. 「予測できない」ことが重要です。短くて繰り返し使われる値は安全性を損ないます。一般に十分な長さ(数バイト〜数十バイト)でランダムに生成します。
Q. チャレンジレスポンスはスマホアプリの二段階認証と同じですか?
A. 一部似ていますが、スマホアプリのOTP(時刻同期型など)はサーバのチャレンジを使わないことが多いです。チャレンジレスポンスはサーバ発行のチャレンジを使う点が異なります。
A. 一部似ていますが、スマホアプリのOTP(時刻同期型など)はサーバのチャレンジを使わないことが多いです。チャレンジレスポンスはサーバ発行のチャレンジを使う点が異なります。
Q. クライアント側で秘密が漏れたらどうなりますか?
A. クライアント側の秘密(パスワードや鍵)が漏れるとそのアカウントは危険です。従って秘密の保護、鍵管理、定期的な更新が不可欠です。
A. クライアント側の秘密(パスワードや鍵)が漏れるとそのアカウントは危険です。従って秘密の保護、鍵管理、定期的な更新が不可欠です。
関連キーワード: チャレンジレスポンス, ノンス(nonce), リプレイ攻撃, ワンタイムパスワード, CHAP, HMAC, TLS

\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

