戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

応用情報技術者 2009年 秋期 午後 問09

公開鍵基盤を用いた社員認証システムに関する次の記述を読んで、設問1～4に答えよ。

　 　販売業を営むX社は、社内業務で利用している電子メールで顧客情報などの個人情報や機密性の高い販売業務に関する情報を安全に取り扱うために、公開鍵基盤を用いた社員認証システム（以下、本システムという）を導入している。本システムを含む社内業務システムの概要を図に示す。
〔本システムの概要〕 　(1) 本システムは、ディレクトリサーバ、認証局サーバ、社員ごとのPC及びIC社員証カード（以下、ICカードという）から構成される。 　(2) ディレクトリサーバでは、社員の公開鍵証明書や電子メールアドレスなどの属性情報の登録及び検索が行われる。 　(3) 本システムでは、プライベート認証局を使用している。 　(4) ICカードには、社員個人の秘密鍵、公開鍵証明書及びPIN（Personal Identification Number）が格納されている。社員が本システムを利用する際には、自分のICカードをPCのICカードリーダに挿入し、ICカードのパスワードであるPINを入力する。 　(5) PCには、本システムにおける認証機能や暗号化機能及び電子メールのクライアント機能を提供するソフトウェア（以下、PCサブシステムという）が導入されている。
応用情報技術者試験（平成21年度 秋期 午後 問09 図01）
〔新規発行〕 　システム管理者が、社員AにICカードを新規に発行する場合の処理の流れは、次のとおりである。 　(1) システム管理者は、認証局サーバで、aとbの対を生成する。 　(2) 認証局サーバは、bと社員名や有効期間などを結び付けた情報に cで署名し、dを生成する。 　(3) 認証局サーバは、dをディレクトリサーバに登録する。 　(4) 認証局サーバは、新規のICカードに、生成したaとd、及び事前申請されたPINを記録する。 　(5) システム管理者は、社員AにICカードを配付する。 　 〔電子メールのメッセージの送受信〕 　社員Aが社員Bあてに、業務情報を暗号化して電子署名を付与したメッセージを送信し、社員Bが受信する際の処理の流れは、次のとおりである。 　 《送信側》 　(1) 社員Aは、自分のICカードをPCのICカードリーダに挿入し、PINを入力することで、PCサブシステムにログインする。 　(2) 社員Aは、社員Bに送信したい電子メールのメッセージを作成した後、PCサブシステムに対し処理を依頼する。 　(3) PCサブシステムは、作成したメッセージのハッシュ値を求め、そのハッシュ値を社員Aの秘密鍵で暗号化して、電子署名を生成する。 　(4) PCサブシステムは、ディレクトリサーバから社員Bの公開鍵証明書を取得し、有効であることを確認する。 　(5) PCサブシステムは、社員Bの公開鍵証明書に結び付けられた社員Bの公開鍵を用いて、作成したメッセージと電子署名を暗号化し、社員Bに送信する。 　 《受信側》 　(1) 社員Bは、自分のICカードをPCのICカードリーダに挿入し、PINを入力することで、PCサブシステムにログインする。 　(2) e 　(3) f 　(4) g

設問1：

ICカードを新規に発行する処理に関して、本文中のa〜dに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群 　ア：システム管理者の公開鍵 　イ：システム管理者の公開鍵証明 　ウ：システム管理者の秘密鍵 　エ：社員Aとシステム管理者の共通鍵 　オ：社員Aの公開鍵 　カ：社員Aの公開鍵証明 　キ：社員Aの秘密鍵 　ク：認証局とシステム管理者の共通鍵 　ケ：認証局と社員Aの共通鍵 　コ：認証局の公開鍵 　サ：認証局の公開鍵証明香 　シ：認証局の秘密鍵

模範解答

a：キ b：オ c：シ d：カ

解説

解答の論理構成

  1. 「システム管理者は、認証局サーバで、aとbの対を生成する。」
    • 公開鍵基盤では本人用の鍵ペアを生成します。本人は「社員A」なので、生成されるのは「社員Aの秘密鍵」と「社員Aの公開鍵」です。
      よって
      a＝「キ：社員Aの秘密鍵」
      b＝「オ：社員Aの公開鍵」
  2. 「認証局サーバは、bと社員名や有効期間などを結び付けた情報に cで署名し、dを生成する。」
    • 公開鍵証明書を発行する際、認証局は自らの秘密鍵で電子署名を行います。
      c＝「シ：認証局の秘密鍵」
    • 署名済みデータは公開鍵証明書そのものです。
      d＝「カ：社員Aの公開鍵証明」
  3. 「認証局サーバは、dをディレクトリサーバに登録する。」
    • ここで登録されるのが 2. で作成した公開鍵証明書であることも確認できます。
以上より
a：キ b：オ c：シ d：カ が導かれます。

誤りやすいポイント

  • 「認証局サーバ」が鍵ペアを生成するので、つい「認証局の鍵ペア」と誤解しやすいが、文中に「社員AにICカードを新規に発行」と明記されており、生成対象は「社員A」の鍵ペアである。
  • 電子署名に使う鍵は「認証局の公開鍵」ではなく「認証局の秘密鍵」。公開鍵は検証用であり、署名行為には使わない。
  • 「公開鍵証明書」と「公開鍵」の混同。証明書は公開鍵に属性情報と署名が付いたものであり、単なる鍵そのものではない。

FAQ

Q: 認証局サーバが社員本人に鍵ペアを生成させず、代わりに生成するのはなぜですか？
A: 本文のような IC カード配付方式では、カードへの鍵格納と証明書発行を一括で管理でき、鍵のバックアップや初期 PIN 設定も統制下で行えるためです。
Q: 「ディレクトリサーバ」には公開鍵以外に何を登録しますか？
A: 本文にあるとおり「電子メールアドレスなどの属性情報」や証明書の失効状態を保持する場合があります。
Q: 受信側で最初に行う処理は何ですか？
A: 受信メッセージを自分の秘密鍵で復号し、平文と送信者の電子署名を取り出すことです（本文中のeに該当）。
関連キーワード: 公開鍵暗号、秘密鍵、電子署名、公開鍵証明書、ディレクトリサーバ

設問2：

受信後の処理の流れに関して、本文中のe〜gに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群 　ア：PCサブシステムは、社員Aの公開鍵証明書をディレクトリサーバから取得し、有効であることを確認する。 　イ：PCサブシステムは、社員Bの公開鍵で暗号化されたメッセージと子署名を受信し、社員Bの秘密鍵で復号する。 　ウ：PCサブシステムは、復号されたメッセージのハッシュ値を計算し、社員Aの公開鍵証明書に結び付けられた社員Aの公開鍵で電子署名から復号されたハッシュ値と比較し、改ざんの有無を確認する。

模範解答

e：イ f：ア g：ウ

解説

解答の論理構成

  1. 受信処理の最初の動作は、社員Bが自分の秘密鍵でメッセージを読める状態に戻すことです。本文には《受信側》(1)として
    　「社員Bは、自分のICカードをPCのICカードリーダに挿入し、PINを入力することで、PCサブシステムにログインする。」
    　とあります。続く(2)では、暗号化されて届いたものを復号する場面が入るはずです。解答群「イ」には、 　「PCサブシステムは、社員Bの公開鍵で暗号化されたメッセージと子署名を受信し、社員Bの秘密鍵で復号する。」
    　と記されており、社員B側での復号処理を正しく示しています。よって e＝イ となります。
  2. 復号が終わったら、次は送信者（社員A）の公開鍵証明書を取り寄せる必要があります。本文《送信側》では、送信前に
    　「PCサブシステムは、ディレクトリサーバから社員Bの公開鍵証明書を取得し、有効であることを確認する。」
    　とありました。受信側でも同じ流れで社員Aの証明書を確認しなければ、電子署名の真偽判定ができません。解答群「ア」は
    　「PCサブシステムは、社員Aの公開鍵証明書をディレクトリサーバから取得し、有効であることを確認する。」
    　と記述しており、目的に合致します。したがって f＝ア です。
  3. 最後にメッセージが改ざんされていないかを調べます。本文《送信側》(3)に
    　「PCサブシステムは、作成したメッセージのハッシュ値を求め、そのハッシュ値を社員Aの秘密鍵で暗号化して、電子署名を生成する。」
    　とあるので、受信側ではこの逆操作を行う必要があります。解答群「ウ」は、 　「PCサブシステムは、復号されたメッセージのハッシュ値を計算し、社員Aの公開鍵証明書に結び付けられた社員Aの公開鍵で電子署名から復号されたハッシュ値と比較し、改ざんの有無を確認する。」
    　と記されており、電子署名検証の手順そのものです。よって g＝ウ が成立します。
以上より
e＝イ
f＝ア
g＝ウ
が論理的に導かれます。

誤りやすいポイント

  • 復号と電子署名検証の順番を逆に考えてしまい、先に署名チェックを挿入してしまう。秘密鍵で復号しないとメッセージ本体を取り出せないため順序が変わることはありません。
  • 送信側と受信側で「誰の公開鍵証明書を取得するか」を取り違える。送信時は宛先、受信時は送信者の証明書が必要です。
  • 「公開鍵で暗号化・秘密鍵で復号」「秘密鍵で署名・公開鍵で検証」という基本動作を混同してしまう。設問では両方の流れが連続して登場するため注意が必要です。

FAQ

Q: 受信側で証明書を取得せず、送信されたメッセージに添付された証明書だけで検証してはいけないのですか？
A: ディレクトリサーバに問い合わせて「有効であることを確認する」手順が必要です。失効リストや期間切れのチェックを行わないと、無効な証明書によるなりすましを防げません。
Q: 解答群「イ」にある「社員Bの公開鍵で暗号化されたメッセージ」とは具体的にどの暗号方式ですか？
A: 一般的には共通鍵を社員Bの公開鍵で包むハイブリッド暗号方式が用いられます。設問では方式名まで示していませんが、公開鍵で暗号化し秘密鍵で復号する流れを押さえておけば十分です。
Q: 電子署名検証でハッシュ値を比較するとき、同じハッシュ関数を使う必要がありますか？
A: はい。送信側と受信側で同一のハッシュ関数を使用しなければ、計算結果が一致せず正しい検証ができません。
関連キーワード: 公開鍵基盤、電子署名、ディレクトリサービス、ハイブリッド暗号、ハッシュ関数

設問3：

本システムの機能では防止できない事象が発生する可能性がある。該当する事象を解答群の中からすべて選び、記号で答えよ。
解答群 　ア：社員Aが自分のICカードとPINを利用して、社員Bになりすますこと 　イ：社員Aが自分のICカードを紛失してしまうこと 　ウ：社員Aが社員Bあてに送信した暗号化メッセージを、社員Cが解読すること 　エ：社員Aが社員Bあてに送信した電子署名付きメッセージを、社員Aが否認すること 　オ：社員Aが社員Bあてに送信した電子署名付きメッセージを、社員Bが改ざんしてその内容を変更すること 　カ：社員Aが社員Bの電子署名を偽造すること

模範解答

イ、オ

解説

解答の論理構成

  1. 本システムが提供できる安全機能
    • 機密性：送信側手順(5)で「社員Bの公開鍵…を用いて、作成したメッセージと電子署名を暗号化」しているので、途中で盗聴しても復号は不可能です。
    • 完全性・認証・否認防止：送信側手順(3)で「メッセージのハッシュ値を…秘密鍵で暗号化して、電子署名を生成」しているので、受信側で改ざん検出と送信者の特定ができます。
    • 利用者認証：概要(4)「ICカードには、社員個人の秘密鍵…及びPIN」が格納され、ログイン時にPIN入力が必須です。
  2. 各選択肢の検討
    | 記号 | 事象 | 本システムで防止できるか | 判断根拠（原文引用） | |---|---|---|---| | ア | 社員Aが自分のICカードとPINを利用して、社員Bになりすます | 防止可 | ICカード内の秘密鍵は社員本人のもの（概要(4)）。Aのカードで作成される電子署名はAの証明書としか結び付きません。 | | イ | 社員Aが自分のICカードを紛失してしまうこと | 防止不可 | 物理的なカード紛失は技術的対策では阻止できません。PIN保護はあっても紛失自体は防げない。 | | ウ | 暗号化メッセージを社員Cが解読 | 防止可 | 送信側手順(5)で「社員Bの公開鍵…で暗号化」されているため、社員Cは秘密鍵を持たず復号不能。 | | エ | 電子署名付きメッセージを社員Aが否認 | 防止可 | 電子署名とCA 証明書により否認防止が成立（送信側手順(3)）。 | | オ | 受信した電子署名付きメッセージを社員Bが改ざん | 防止不可 | 受信後に復号された平文は社員BのPC上に存在するため、Bは自由に内容を変更できます。電子署名は削除すれば改ざん自体は防げない（システムは“改ざんされても送信者が再署名しない限り正しい署名を付与できない”だけで、改ざん行為そのものの抑止は不可能）。 | | カ | 社員Aが社員Bの電子署名を偽造 | 防止可 | B の秘密鍵は ICカード内に保護。A は鍵を取得できず偽造不可。 |
  3. 結論
    防止できない事象は「イ」「オ」であり、模範解答と一致します。

誤りやすいポイント

  • 「電子署名＝改ざんそのものを阻止」と誤解し、オを除外してしまう。署名は“検出”機能であり“抑止”機能ではない点に注意。
  • 物理的なカード紛失を技術システムでカバーできると考えてしまう。ICカードのアクセス制御と紛失防止は別問題です。
  • 公開鍵暗号を用いているので内部の誰も復号できないと早合点し、受信者自身の改ざん可能性を見逃す。

FAQ

Q: 電子署名が付いていても受信者が削除して改ざんしたら、送信者の責任は？
A: 改ざん後に署名が失われれば否認防止の根拠もなくなります。真正性を主張するには“改ざんされていない署名付きデータ”を提示する必要があります。
Q: ICカードを紛失した場合の典型的な追加対策は？
A: 失効手続き（CRL や OCSP）と速やかな再発行が一般的です。本システム概要には失効処理の記述がないため、運用規程で補う必要があります。
Q: なりすまし防止で最も重要なのは秘密鍵の管理ですか？
A: はい。概要(4)で示される「秘密鍵をICカードに格納しPINで保護」が基本ですが、多要素認証やICカードの持ち出し制限など運用面の補完が望まれます。
関連キーワード: 公開鍵暗号、電子署名、ディレクトリサービス、秘密鍵管理、否認防止

設問4：

電子メールは、社内業務システムから社外にも送信することができる。その場合、例えば次に記述した処理の流れで、社員Aが作成したメッセージを,X社の社員ではない相手Dに送信すると、相手Dは、受信したメッセージが社員Aから送信されたものであることを検証できない。その理由を25字以内で述べよ。 　 〔電子メールのメッセージの送受信〕 《送信側》 　(1) 社員Aは、自分のICカードをPCのICカードリーダに挿入し、PINを入力することで、PCサブシステムにログインする。 　(2) 社員Aは、X社の社員ではない相手Dに送信したい電子メールのメッセージを作成した後、PCサブシステムに対し処理を依頼する。 　(3) PCサブシステムは、作成したメッセージのハッシュ値を求め、そのハッシュ値を社員Aの秘密鍵で暗号化して、電子署名を生成する。 　(4) PCサブシステムは、作成したメッセージと電子署名を相手Dに送信する。

模範解答

社外では公開鍵証明書の取得と検証ができないから

解説

解答の論理構成

  1. 本システムでは、公開鍵証明書は社内の「ディレクトリサーバ」に登録されています。問題文では「ディレクトリサーバでは、社員の公開鍵証明書や電子メールアドレスなどの属性情報の登録及び検索が行われる」とあります。
  2. さらに「本システムでは、プライベート認証局を使用している」と明記されており、証明書の発行主体は社内限定です。
  3. 社外の相手Ｄに送信する手順では、送信側の④で「PCサブシステムは、作成したメッセージと電子署名を相手Dに送信する」とあるだけで、相手Ｄが社員Ａの公開鍵証明書を取得する手段は示されていません。
  4. 相手Ｄが電子署名を検証するには、(ア)公開鍵証明書の取得、(イ)証明書の真正性確認（署名検証）が必須ですが、プライベート認証局の証明書ストアやディレクトリサーバは社外には公開されていません。
  5. よって「社外では公開鍵証明書の取得と検証ができないから」という結論になります。

誤りやすいポイント

  • 「公開鍵そのものを添付すれば検証できる」と誤解しやすいですが、公開鍵だけでは“真正性”が保証できず、証明書とその検証環境が不可欠です。
  • 「公開鍵証明書はメールと一緒に自動送付される」と思い込み、社外でも問題ないと判断してしまうケース。
  • ルート証明書を“ブラウザに入れればよい”と考え、設問が示す前提（社外に配布していない）を読み落とすミス。

FAQ

Q: ディレクトリサーバの外部公開を行えば、相手Ｄでも検証できますか？
A: 可能ですが、その場合は社内限定の「プライベート認証局」のルート証明書を社外にも安全に配布し、失効情報も公開する追加設計が必要です。
Q: 公開鍵証明書をメールに添付すれば検証できるのでは？
A: 添付だけではプライベート認証局のルート証明書が相手Ｄに存在しないため、署名の真正性を確立できません。ルート証明書と失効情報の信頼経路が不可欠です。
Q: 社内向けと社外向けで異なる証明書を用意する方法はありますか？
A: はい。社外向けには公的認証機関の証明書を取得し、社内向けにはプライベート認証局を使う“デュアル証明書方式”を採用する企業もあります。
関連キーワード: 公開鍵証明書、プライベート認証局、ディレクトリサーバ、電子署名、失効情報
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者を
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について