応用情報技術者 2022年 春期 午前2 問38

チャレンジレスポンス認証【午前2解説】

正解の理由

解法ステップ

1. 問題文の各選択肢で「サーバがランダムなデータ（チャレンジ）を送っているか」「クライアントがそれに応答して演算を行っているか」を探す。
2. チャレンジが存在し、クライアント側で秘密情報と組み合わせて演算し、その結果を返している記述があればチャレンジ・レスポンス方式である。
3. チャレンジが無く、クライアントが単に固定値やトークンで生成された値を送るものはワンタイムパスワード（OTP）や固定認証であり、チャレンジ・レスポンスではないと判定する。

選択肢別の誤答解説

• ア: 固定パスワードを TLS で送る方式。TLS が通信を守るが、認証プロトコル自体は固定パスワード送信であり、サーバからのチャレンジ・レスポンスを用いていないため該当しない。リプレイやサーバ側のパスワード保護の観点で弱点がある（平文送信しない点は救済になっているが方式分類としては違う）。
• イ: 端末のシリアル番号をクライアントの秘密鍵で暗号化して送る方式。これは「所有証明」や「署名」に近いが、サーバが事前にランダムチャレンジを出していないためチャレンジ・レスポンスとは呼べない。静的データの暗号化はリプレイ対策が不足する（対策としてはチャレンジやタイムスタンプの導入が必要）。
• ウ: トークンが自動表示する毎回異なる数字列（ワンタイムパスワード）を送る方式。これは TOTP/HOTP のようなチャレンジを必要としないワンタイムパスワード方式であり、サーバ側のチャレンジに応答する構造ではないためチャレンジ・レスポンス方式ではない。トークンがチャレンジを受け取って応答するタイプ（チャレンジ-レスポンストークン）とは区別される。
• エ: 利用者の入力したパスワードとサーバからのランダムデータをクライアントで演算し、その結果を返す記述は、まさにチャレンジの存在とその応答による検証を示しているため正解。チャレンジを用いることでリプレイ耐性やパスワード非送信性が確保される。

よくある誤解

• OTP（ワンタイムパスワード）は全てチャレンジ・レスポンスだと思い込む誤り。TOTP/HOTP はサーバとトークンが時間やカウントで同期して独立にコードを生成する「チャレンジ不要」の方式であり、チャレンジ・レスポンスとは別物です。一方で、サーバのチャレンジにトークンが応答する「チャレンジ-レスポンストークン」も存在します（種類を区別して理解すること）。
• Kerberos を単純にチャレンジ・レスポンスの代表例とする誤り。Kerberos はチケットやタイムスタンプを使う認証フレームワークで、用途や仕組みが異なるので「場合によっては異なる」と明確化して扱うべきです。
• 「秘密鍵で暗号化すれば常に安全」ではない点。静的な値をそのまま送るとリプレイ攻撃を受ける可能性があるため、チャレンジやタイムスタンプを組み合わせることが重要です。

補足コラム

• 代表的プロトコル例：CHAP（Challenge-Handshake Authentication Protocol）、SRP（Secure Remote Password）、S/Key（ワンタイムパスワード系だがチャレンジを用いる実装も存在）。これらはサーバ発行のチャレンジとクライアント側の秘密を組み合わせてレスポンスを生成します。
• 一般的なレスポンス生成例（概念式）： $R={\mathrm{HMAC}}_K(\mathrm{nonce})$ ここで K はクライアントの秘密、nonce はサーバが発行するランダム値、HMAC はハッシュベースの MAC。
• 実装上の注意点：チャレンジは十分に長くランダムで一意であること、サーバ側は期待されるレスポンスを同じ方法で計算して比較すること、及び中間者（MitM）攻撃やリプレイに対する追加対策（相互認証、TLS併用など）を設けることが重要です。

import hmac, hashlib

def make_response(secret_key: bytes, nonce: bytes) -> str:
    return hmac.new(secret_key, nonce, hashlib.sha256).hexdigest()

FAQ