情報処理安全確保支援士 2017年 秋期 午後1 問03

解答の論理構成

1. サーバ証明書の作成と検証
   引用: 「サーバ証明書の作成とその検証には公開鍵暗号方式を利用したa技術を利用します。」
   公開鍵暗号方式で真正性を保証する技術は「ディジタル署名」です。したがって
   a＝コ「ディジタル署名」。
2. データの暗号化と復号
   引用: 「データの送受信時は、暗号化と複号のためにbを利用します。」
   転送データの暗号化には高速な「共通鍵暗号」を用いるのが SSL/TLS の一般的な仕組みです。
   b＝カ「共通鍵暗号」。
3. 鍵共有の方法
   引用: 「データの送信者と受信者がbで使用する鍵を共有するために、公開鍵暗号方式を用いてcを行います。」
   公開鍵暗号方式を用いてセッション鍵を安全に共有する操作は「鍵交換」です。
   c＝オ「鍵交換」。
4. サーバ証明書の種類
   引用: 「現在、世の中で発行されているサーバ証明書には複数の種類があり、代表的なものはドメイン認証証明書とdです。」
   ドメイン認証証明書と並ぶ代表格は「EV証明書（Extended Validation）」です。
   d＝イ「EV証明書」。

誤りやすいポイント

• a を「エンティティ認証」と誤認するケース
  → 証明書作成・検証の核心は署名の真正性確認であり、通信時の相手認証とは文脈が異なります。
• b と c を逆にするケース
  → 「暗号化・複号に使う」＝アルゴリズム、「共有する」＝手続きと切り分けると混同しません。
• EV証明書と CA証明書の混同
  → CA証明書は認証局自身を証明する証明書、EV証明書はサーバ向けの拡張審査付き証明書です。

FAQ

解答の論理構成

1. 【問題文引用】
   H 氏は「御社のECサイトを複製して偽のECサイトを立ち上げ、①DNSキャッシュポイズニング攻撃と組み合わせて、不正を行うかもしれません。」と述べています。
2. DNSキャッシュポイズニング攻撃とは
   • 参照する DNS キャッシュに偽の対応情報（FQDN ⇔ 攻撃者サーバの IP）を注入し、正規ドメイン名の問い合わせ結果を改ざんする攻撃です。
3. 偽サイトと組み合わせる目的
   • ユーザは「正規の EC サイトの FQDN」をブラウザに入力またはリンククリック → DNS から取得した IP が改ざん済み → 攻撃者が運営する偽サイトへ到達。
4. したがって DNS キャッシュポイズニング攻撃の役割は、正しい URL を入力した利用者を偽サイトへ転送し、通信を盗聴・詐取させることです。

誤りやすいポイント

• 「キャッシュの書き換え＝通信傍受」と短絡してしまい、“改ざんされた DNS 応答がどこに送られるのか”という導線を答え忘れる。
• 「フィッシング攻撃だ」とだけ書いてしまい、DNS キャッシュポイズニング攻撃自体が担う“誘導”の工程に触れない。
• SSL/TLS の脆弱性と混同し、「暗号通信を復号する」など DNS レイヤとは無関係の役割を記述してしまう。

FAQ

解答の論理構成

1. 問題文では、H 氏が B さんに対し
   「②鍵ペアの生成に用いる擬似乱数生成器 に必要な条件を、Zソフトは、満たさないことが分かっています。」
   と述べています。
2. 鍵ペアを生成する際に用いる擬似乱数が推測できると、生成される素数や秘密鍵そのものが再現できてしまい、サーバ証明書に対応する秘密鍵が攻撃者に知られるリスクが生じます。
3. このリスクを防ぐためには、擬似乱数列が外部から「規則性を判別できない」「次の値を予測できない」こと、すなわち“予測不可能”であることが必須です。
4. したがって、解答群の中で適切なのは
   エ：予測不可能である
   となります。

誤りやすいポイント

• 「一様分布」を満たすだけでは十分ではありません。一様であっても生成アルゴリズムが知られていれば次の値を計算できる場合があります。
• 周期が長いことは望ましいものの、周期が長い＝安全とは限りません。周期途中でも規則性を突ければ予測可能です。
• 「規則性がある」ことは安全要件ではなく、むしろ欠点です。「規則性がある」は誤答を誘う文言なので注意してください。

FAQ

解答の論理構成

1. 事故発覚直後に講ずべき対応を H 氏は次のように助言しています。
   引用: 「・当該鍵に関わるサーバ証明書のア停止
       ・当該鍵に関わるサーバ証明書のイ申請」
   秘密鍵が漏えいした証明書は、引き続き使えば盗聴やなりすましを許すため、
   ①“使うこと”そのものを止める必要があります。したがって ア には「利用」が入って「利用停止」という語が完成します。
2. 併せて、その証明書を公的に無効化し、ブラウザや OS が不信証明書として扱うよう、認証局へ“無効にしてほしい”手続きを取ります。これが一般に「失効申請」です。よって イ には「失効」が入ります。
3. 以上より
   ・ア = 利用
   ・イ = 失効

誤りやすいポイント

• 「使用停止」と迷う
  「停止」は文中に既に存在し、空欄は“何を停止するのか”を示す語を入れる構造です。
• 「取消申請」「再発行申請」と書く
  取消は結果であって手続名ではなく、再発行は“新証明書”を得る手続きで別物です。
• CA への失効申請と CRL/OCSP 反映の関係を混同
  失効申請はあくまで CA への手続き、CRL や OCSP はその結果として公開される仕組みです。

FAQ

解答の論理構成

1. 【問題文】図1には、鍵が漏えいした際の実施事項として
   “(6) ③当該鍵を使用していたサーバの利用者が、自身の被害の可能性を判断できるようにするための情報の公表”
   と明記されています。
2. 利用者が被害可能性を判断するには、 (a) 自分がアクセスしたサーバを特定できること
   (b) その期間内にアクセスしたかどうかを確認できること
   の2点が不可欠です。
3. (a) を満たす最小かつ一意の情報は “FQDN” です。H氏の説明でも
   “サーバ証明書には、サーバのFQDNと公開鍵が記載されます。”
   と引用され、FQDNがサーバ識別子であることが示されています。
4. (b) を満たすには “鍵が危たい化したと思われる日時” を示すことで、 利用者はアクセス時刻と突き合わせて影響有無を判断できます。
5. 以上により、公開すべき2項目は
   “鍵が危たい化した Web サイトの FQDN”
   “鍵が危たい化したと思われる日時”
   となります。

誤りやすいポイント

• URL全体やIPアドレスを挙げ、FQDNを書かない
  →複数バーチャルホスト運用時に一意性を欠きます。
• “公開鍵” や “証明書シリアル番号” を公表項目にする
  →被害判断に直接結び付きにくく、利用者が確認困難です。
• “推定原因” や “対策手順” を優先してしまう
  →重要だが、③の目的は利用者の被害判定であり優先度が異なります。

FAQ

解答の論理構成

1. 図1の“システムを復旧させる際の遵守事項”には、 ・“(1) 危ない化した鍵に関わる証明書署名要求（CSR）の再利用禁止”
   ・“(2) e の生成と、その利用”
   と並列に記載されています。
2. “(1)”では危ない化した鍵に関係する既存 “CSR” を使い回さないことを指示しています。CSR には公開鍵が含まれるため、同じ CSR を再利用すると同じ公開鍵（＝危ない化した秘密鍵と対になる鍵）を使い続けることになります。
3. したがって “(2)” では再利用禁止を受けて “新しい鍵そのものを作り直す” ことを示している必要があります。
4. 本問題全体では、「鍵ペア」を “Z ソフトを利用して生成” したため秘密鍵が推定されたことが原因であり（図2「2. 秘密鍵が他者に知られてしまった原因」）、安全な運用のためには “安全な乱数で再生成した鍵ペアに入れ替える” ことが自然な対策です。
5. 以上より、e には“鍵と鍵が対になったもの”すなわち「鍵ペア」を当てはめると整合します。

誤りやすいポイント

• 「CSR の再利用禁止＝新しい CSR を作る」と短絡し、“CSR” や “新規 CSR” と書いてしまう。
• “公開鍵”だけを作り直せば良いと誤解して「公開鍵」と記入する。秘密鍵と対にならない公開鍵は存在しないため不適切です。
• “証明書”そのものを指すと誤認し「サーバ証明書」と回答する。図1は証明書を得る前提として“鍵の再生成”を求めています。

FAQ

解答の論理構成

1. 問題設定
   図2にあるとおり、ECサイトのサーバは「利用可能なプロトコルのバージョン：SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2」と設定されています。
2. 脆弱性の原因
   図4の説明に「SSL 3.0 プロトコルのパディングチェックの脆弱性を利用して攻撃する」とあります。POODLE攻撃はSSL 3.0固有の設計上の問題を突くため、SSL 3.0を許可しているだけで攻撃対象になります。
3. 対策方針
   H氏は「問題1　POODLE 攻撃に対して脆弱であること」と指摘し、④各サーバに施すべき措置を提案しました。設問はその措置を問うています。
4. 論理的帰結
   ・攻撃の根本原因＝SSL 3.0の利用可否
   ・最も確実な封じ込め策＝SSL 3.0をサーバ側で無効化（クライアントにも提供しない）
   以上から解答は「SSL3.0 を利用しない設定にする」と導けます。

誤りやすいポイント

• CBC方式の暗号スイートを削除すれば十分と誤解し、SSL 3.0自体を無効化しない。
• TLS 1.0以降にも実装依存で類似攻撃があり得ると読んで、TLSをすべて停止する極端な判断をする。
• クライアント側設定（ブラウザ）だけで対応できると考え、サーバ設定変更を怠る。

FAQ

解答の論理構成

1. 【問題文】には「⑤PFSの性質をもつ鍵交換方式」と明記されています。
2. PFS（Perfect Forward Secrecy）とは、サーバの長期秘密鍵が漏えいしても、過去の通信セッション暗号が解読されない性質です。
3. PFS を実現する代表的な仕組みは「エフェメラル Diffie-Hellman」系列です。通信ごとに一時的（ephemeral）な鍵ペアを生成し、長期鍵とは独立した鍵交換を行うため、過去セッションが保護されます。
4. 解答群を確認します。
   • ア：「AES」は共通鍵暗号方式であり、鍵交換ではありません。
   • イ：「CFB」はブロック暗号の動作モードです。
   • ウ：「DHE」は Diffie-Hellman Ephemeral で PFS を提供します。
   • エ：「DSA」はデジタル署名方式で鍵交換ではありません。
   • オ：「ECDHE」は Elliptic Curve Diffie-Hellman Ephemeral で PFS を提供します。
   • カ：「ECDSA」は楕円曲線ディジタル署名方式です。
   • キ：「PKCS」は暗号API仕様群の総称であり方式名ではありません。
   • ク：「RSA」は公開鍵暗号方式ですが、サーバ証明書に含まれる長期公開鍵でセッション鍵を暗号化する方式では PFS が成立しません。
5. よって PFS の性質をもつ鍵交換方式は「ウ：DHE」と「オ：ECDHE」です。

誤りやすいポイント

• 「RSA」も公開鍵暗号なので PFS と誤解しやすいですが、長期鍵に依存するため前方秘匿性は確保できません。
• 「ECDSA／DSA」は署名方式であって鍵交換ではない点を見落としがちです。
• 「AES」「CFB」は暗号アルゴリズムやモードであり、鍵交換の文脈に当てはまりません。

FAQ

解答の論理構成

1. 問題文は、C 社がハンドシェイクで「⑥セッション鍵を共有するための秘密情報をクライアントがサーバ証明書に記載されたRSAの公開鍵を用いて暗号化して送信する方式」を採用していると明示しています。
2. この方式では、クライアントが生成したプレマスターシークレットを サーバ証明書に含まれる RSA 公開鍵で暗号化し、サーバは 対応する秘密鍵で復号してセッション鍵を導出します。
3. 従って、ハンドシェイクで必要なのは 常に同一の秘密鍵であり、PFS（Perfect Forward Secrecy）のように“使い捨ての鍵”は生成されません。
4. したがって、攻撃者が後に「秘密鍵」を入手すると、 ・ハンドシェイク中の暗号化プレマスターシークレットを復号
   ・セッション鍵を計算
   ・そのセッション鍵で暗号化されたアプリケーションデータをすべて復号
   という流れで、過去・現在・未来の取得済み通信をすべて解読できます。
5. これを裏付けるように、本文でも「秘密鍵を知った者は、御社のECサイトと利用者との通信パケットを入手できれば、それを復号して内容をのぞき見できる可能性があります」と説明しています。
6. 以上より、リスクを最も端的に表す選択肢は「取得された通信データの全てを復元されるおそれがある。」であり、解答は【エ】となります。

誤りやすいポイント

• 「危たい化“後”だけ危険」という認識
  → RSA 方式はハンドシェイクに使う鍵が固定なので、過去のキャプチャにも影響します。
• PFS と混同して「鍵が漏れても過去の通信は安全」と思い込む
  → PFS を利用していない場合は成り立ちません。
• TLS 1.2 を使っているから安全だと早合点
  → プロトコルバージョンよりも“鍵交換方式”が本質である点を見落としがちです。

FAQ

解答の論理構成

• 本文では「H 氏は、⑦EC サイトが新たに立ち上げたサイトであることを考慮すると、ドメイン認証証明書の選択は妥当でないと指摘」とある。
• ドメイン認証証明書が提供する保証は“そのドメイン名を制御できる主体がいる”という最低限の事実のみで、組織の実在性や正当性までは検証しない。
• 一方、利用者は「新たに立ち上がった EC サイト」が本当に「衣料品製造会社である C 社」のサイトかを知りたい。そこで必要なのは、運営組織の存在を認証局が審査する「d」（組織認証証明書や EV 証明書）である。
• したがって、運営主体を証明できない“ドメイン認証証明書”では利用者に十分な安心を与えられないため、妥当でないと評価される。

誤りやすいポイント

• 「ドメイン名が正しい＝運営者も正しい」と早合点する。ドメイン認証証明書は運営組織の確認を行わない点を見落としやすいです。
• 問題文に出てくる「d」を拡張認証証明書と即断し、根拠を曖昧に書いてしまう。
• 「既に社名が知られているからドメイン認証で十分」と考えるが、新規サイトゆえに利用者視点では信用情報が不足していることを忘れがちです。

FAQ