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

解答の論理構成

1. 問題文の抜粋
   • 表2「暗号アルゴリズムの安全性」において、256ビット安全性の欄には
     ・共通鍵暗号：256
     ・素因数分解問題に基づくアルゴリズム（RSA など）：15,360
     ・ハッシュ関数：512
     が対応すると明示されています。
   • Cさんの発言

     「鍵長256ビットのAESアルゴリズムは、鍵長aビットのRSAアルゴリズムや、bビットのハッシュ関数などと同じセキュリティ強度」
     とあるため、表2の“256ビット安全性”の行を参照すれば a と b に入る値が分かります。

2. 数値の決定
   • RSA の欄（素因数分解問題に基づくアルゴリズム）の 256 ビット安全性は 15,360 ビット。
   • ハッシュ関数の 256 ビット安全性は 512 ビット。
3. よって
   • a ＝ 15,360
   • b ＝ 512

誤りやすいポイント

• 112ビット安全性や128ビット安全性の列と取り違えてしまう。設問では「鍵長256ビットのAES」を例示しているので、必ず“256ビット安全性”列を確認します。
• RSA と楕円曲線暗号の値を混同する。RSA（素因数分解問題）の256ビット安全性は 15,360、楕円曲線暗号の同列は 512 ではなく 512 はハッシュ関数です。
• 「ハッシュ関数 bit 長＝セキュリティ強度」と早合点し、256 と答えてしまうミス。表2ではハッシュ長512ビットが256ビット安全性に相当します。

FAQ

解答の論理構成

• 【問題文】の表2には、公開鍵暗号（素因数分解問題に基づくアルゴリズム）の欄に「3,072」が掲載されており、同じ列の見出しは「128ビット安全性」です。すなわち、 「鍵長3,072ビットのRSAアルゴリズム ＝ “128ビット安全性”」
  であると読み取れます。
• 同じ表のハッシュ関数の行を見ると、「128ビット安全性」の列に「256」と記載されています。よって、出力長が256ビット以上のハッシュ関数は「128ビット安全性」と同等、あるいはそれ以上の耐性を備えていることが分かります。
• 解答群のうちハッシュ関数は「ウ：MD5」「オ：SHA-1」「力：SHA-256」「キ：SHA-512」の4つです。
  • 「ウ：MD5」は128ビット出力で、表2の「80ビット安全性」に相当し不適格。
  • 「オ：SHA-1」は160ビット出力で、表2の「80ビット安全性」に相当し不適格。
  • 「力：SHA-256」は256ビット出力で、表2の「128ビット安全性」に該当し適格。
  • 「キ：SHA-512」は512ビット出力で、表2の「256ビット安全性」に該当し適格。
• 以上より、「鍵長3,072ビットのRSAアルゴリズムと同等又はそれ以上のセキュリティ強度をもつハッシュ関数」は
  「力：SHA-256」と「キ：SHA-512」です。

誤りやすいポイント

• 「出力長160ビットのSHA-1は128ビット安全性」と誤解しやすいですが、表2に従うとSHA-1の耐性は「80ビット安全性」です。
• ハッシュ関数以外（Camellia, RC4, TripleDES, ECDSA）は対象外と気付かず選択してしまうミス。
• 「ビット数が大きい＝必ず安全」と短絡し、MD5の脆弱性を見落とすケース。

FAQ

解答の論理構成

1. Qシステムの稼働期間を確認
   • 問題文より引用
     「2015年9月から10年間の稼働を想定している。」
     したがって運用終了は「2025年8月」になります。
2. NIST 文書を基にした表2の“利用終了時期の目安”を確認
   • 「利用終了時期の目安」行には
     80ビット安全性 … 「2013年」
     112ビット安全性 … 「2030年」
     と記載されています。
3. 必要なセキュリティ強度を決定
   • 2025年8月まで安全と判断できるのは「2030年」まで利用が推奨される「112ビット安全性」以上。
   • よって c には「112」を入れるのが最小かつ妥当です。
4. 要件の導出
   • セキュリティ強度を選ぶ根拠は「Qシステムのサービス提供期間」であり、これを短くまとめると
     「利用期間は2025年8月までである」。

誤りやすいポイント

• 「2031年以降」が複数記載されているため、128ビット安全性を選びたくなる。実際には稼働終了時点で十分な余裕がある112ビットで足りる点を見落としがちです。
• 稼働開始月「2015年9月」を起算日に含めない、または満10年間を「2026年9月」と誤算するケース。
• “表2”の「共通鍵暗号」の列を直接比較し、公開鍵やハッシュまで同じ長さを選択しようとする早合点。

FAQ

解答の論理構成

• 【問題文】では、代理店ガイドラインに「①Qシステムにアクセスしていた端末を交換及び廃棄する場合に代理店が実施すべき処理」を盛り込むよう求めています。
• Qシステムは「SSLクライアント認証」により「端末の限定」を実現しています。したがって、端末に格納された証明書が生きている限り、その端末（あるいは証明書を抜き出した別端末）からアクセスできてしまいます。
• 端末を交換・廃棄するときは、その証明書が無効化されていなければ「代理店の管轄下にない端末でQシステムにアクセスできる可能性」（R主任の指摘）を残します。
• そこで、端末とひも付いた証明書を使えなくする＝「利用停止を申請」する手続が必須となります。
• 以上より、代理店が行うべき具体的処理は「端末に発行された証明書の利用停止を申請する」となります。

誤りやすいポイント

• 「端末を初期化／物理破壊すれば十分」と勘違いし、証明書自体の失効を忘れる。証明書がバックアップされていると不完全対策になる。
• 「新端末で新証明書を発行する」ことだけを答え、旧証明書失効の手続を示していない。
• 「利用停止」の主体をL社と誤認し、代理店側のアクションを書かない。

FAQ

解答の論理構成

1. 図1の手順(4)
   引用：「端末で鍵ペアを生成し、生成した d を送信する。」
   生成して送信できるのは公開情報であるため、d＝「公開鍵」と判断します。
2. 図2‐1.利用停止手順(1)
   引用：「利用を停止する証明書の e 又は識別番号を入力する。」
   証明書に固有で代理店が容易に把握できる値は引用「証明書のシリアル番号」であるため、e＝「シリアル番号」です。
3. 図2‐3.検証項目
   引用：「証明書中の識別番号が f に登録されていないこと」
   利用停止手順(2)で引用「識別番号を受付拒否リストと呼ばれるリストに登録」とあるので、f＝「受付拒否リスト」となります。
4. 同じ検証項目の次行
   引用：「g が、証明書中の h と一致すること」
   直前の検証項目に引用「入力された利用者IDに対して…」があるため、g＝「入力された利用者ID」。
   一致を確認する相手は証明書に格納された利用者識別子であり、図1注記にも引用「利用者ID」があるので、h＝「利用者ID」です。

誤りやすいポイント

• 手順(4)で送信するのは秘密鍵と誤解しがちですが、秘密鍵は端末外へ出しません。
• シリアル番号と識別番号を混同しやすいので、それぞれの用途（証明書固有／L社管理用）を整理して区別すると安全です。
• 受付拒否リストをCRLやOCSPと同列に扱い、「失効リスト」と答えてしまうミスに注意しましょう。

FAQ

解答の論理構成

1. 設計方針の確認
   問題文では、情報漏えい防止設計方針として表1に
   “端末の限定―『代理店の管轄下にある端末からのアクセスだけを許可する。』”
   と明示されています。したがって、証明書が代理店管理外の端末に入れば方針違反になります。
2. リスクの指摘
   R主任は新規発行手順について
   “代理店の担当者が不適切な行為をした場合、…代理店の管轄下にない端末でQシステムにアクセスできる可能性”
   を問題視しました。つまり担当者レベルで証明書を外部端末に導入する恐れがあるという指摘です。
3. 対策の責任分担
   しかし下線②の方針で
   “Qシステムでは対策をとらず、代理店側で対策をとってもらう”
   と決定されたため、L社側で技術的制御を追加せず代理店の内部統制で補完します。
4. 誰が確認すべきか
   図1の説明からも、証明書発行申請の主導は代理店の「代表者」であり、代表者は信頼できる前提です。よって、端末が代理店の管理下にあることを確認・保証できる立場は代表者となります。
5. 結論
   以上を踏まえ、代理店で行う具体的な対策は
   “代理店の管轄下の端末に証明書がインストールされていることを代表者が確認する。”
   となります。

誤りやすいポイント

• 「Qシステム側で端末証明書インストールを制限する」と考えてしまう
  → 下線②で「Qシステムでは対策をとらず」と明言されています。
• 担当者自らの自己申告で十分だと誤認する
  → 担当者が不適切行為をする可能性があると指摘されているため、より上位の代表者が確認する必要があります。
• 表1の目的が“アクセス制御”ではなく“利用者認証”だと混同する
  → 本設問は端末の限定（場所・所有者の制限）に関する対策です。

FAQ

解答の論理構成

1. 【問題文】表3には「役割と権限を見直し、i。」と記載されています。
2. 同じ行の長所には「担当者が不在の場合にも、証明書の利用停止が可能である。」とあります。これは“担当者以外”でも停止手続を行えるようにする狙いを示しています。
3. 一方、短所として「代表者の役割が拡大し、権限が集中する。」と明記されており、“代表者”が追加の権限を持つことが前提です。
4. 以上より、(2)案で実現したい修正は「担当者の証明書の停止権限を、代理店の代表者にも持たせること」であると論理的に導けます。
5. よって i に入れる文は「担当者の証明書を停止する権限を代表者に付与する」となります。

誤りやすいポイント

• 「代表者の役割が拡大」という短所を読まずに、L社側やシステム管理者へ権限を渡すと勘違いしやすいです。
• “利用停止”と“失効（Revocation）”を混同し、証明書失効リストへ登録する手続きだと思い込むケースがあります。ここではあくまで“受付サーバでの利用停止”権限の追加です。
• 「担当者が不在の場合にも…」という長所から“自動停止”と誤解し、権限の移譲という発想に至らないことがあります。

FAQ

解答の論理構成

• 【問題文】では、証明書の更新手順で「(1) 担当者は登録サーバにアクセスし、更新前の証明書と、当該秘密鍵の保持を示す署名データを提示する。」とあり、基本的に“古い証明書が有効である”ことを前提に更新しています。
• しかし R主任は「利用停止された証明書の取扱いを担当者が誤った場合などに、③本来発行されるべきでない証明書が発行される可能性」を指摘しました。ここで言う“本来発行されるべきでない証明書”とは、すでに停止（失効）手続が済んだ証明書に基づく更新申請を指します。
• 停止済みかどうかは、図2「(2) 受付サーバは…当該証明書の識別番号を受付拒否リストと呼ばれるリストに登録する。」で管理されています。
• したがって、登録サーバ側でも更新要求を受け付ける際に「証明書中の識別番号が受付拒否リストにないこと」を照合すれば、“停止済み証明書の更新”という矛盾を排除できます。
• この対策は図2「3. …検証項目（順不同）・証明書中の識別番号が f に登録されていないこと」の検証をログイン時だけでなく“更新処理時”にも適用するだけなので、既存の仕組みを流用でき、運用負荷を増やさずに安全性を高められます。

誤りやすいポイント

• 「失効リスト（CRL）」と「受付拒否リスト」を同一視する
  → 本システム固有の“受付拒否リスト”で管理している点に注意が必要です。
• “停止済み証明書の破棄”と“更新拒否”を混同する
  → 停止済み証明書を破棄しても、その番号で再申請されたら意味がないため登録サーバ側のチェックが欠かせません。
• 検証を認証局サーバに追加すると考えてしまう
  → 登録サーバが受付窓口なので、ここで拒否するのが最小コストかつ確実です。

FAQ