情報処理安全確保支援士 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

解答の導き方

1. 目標とするセキュリティ強度を特定する。問題文中の表2は「最も効率が良い攻撃手法で暗号を解読するときに必要な計算量を指標とし、同程度の耐性をもつものを同じ“セキュリティ強度”としている」と説明しています。表2の「素因数分解問題に基づくアルゴリズム」の行で、3,072が128ビット安全性 に対応しているため、今回の目標は128ビット安全性 です。
2. ハッシュ関数で128ビット安全性 を満たす条件を確認する。表2の「ハッシュ関数」の行で256が128ビット安全性 に対応しています。一般的にハッシュ関数の衝突探索に必要な計算量は出力長 $n$ に対して概ね $2^{n/2}$ であり、出力長が256ビットであれば衝突耐性は約 $2^{128}$、すなわち128ビット相当の安全性が得られます。したがって、出力長が256ビット以上のハッシュ関数が要件を満たします。
3. 選択肢を照合する。選択肢の中でハッシュ関数に該当し、かつ出力長が256ビット以上なのは次のものです。
   • カ：SHA-256（出力256ビット）
   • キ：SHA-512（出力512ビット）
   他の選択肢が不適格な理由は以下の通りです。
   • ウ（MD5）：出力128ビットだが、衝突探索は約 $2^{64}$ で済むため衝突耐性は約64ビット相当であり128ビット安全性を満たさない。
   • オ（SHA-1）：出力160ビットで衝突探索は約 $2^{80}$、表2では80ビット安全性 に対応しており不足する。
   • ア（Camellia）、エ（RC4）、ク（TripleDES）：いずれもハッシュ関数ではなく共通鍵暗号（ブロック/ストリーム暗号）でありカテゴリが異なる。
   • イ（ECDSA）：楕円曲線署名アルゴリズムでありハッシュ関数ではない。

誤りやすいポイント

• ハッシュ関数の「出力長 = そのままのビット安全性」と誤解すること。衝突耐性は出力長 $n$ に対して約 $2^{n/2}$ の計算量となり、実効的な安全性は出力長の半分に相当します。
• MD5を出力長128ビットだから「128ビット安全性」と扱ってしまう誤り。実際の衝突探索は約 $2^{64}$ である点を押さえておくこと。
• 問題が「ハッシュ関数」を求めているのに、共通鍵暗号や署名アルゴリズムを混同して選んでしまうミス。設問の対象カテゴリに注意すること。
• 表2が「最も効率の良い攻撃手法」を基準に示している点を見落とし、理想的な（非現実的な）攻撃モデルで判断してしまうこと。

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又は図2中の字句を用いて」埋める形式です。CSR（証明書署名要求）など実務用語を思いついても、図中の表現と合致しないと部分点を失う恐れがあります。

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