応用情報 科目A 19：共通鍵・公開鍵・ハッシュ・デジタル署名・PKI

2026年試験基準 · 改訂／出典確認 2026-10-21

学習インデックス

1. 公式範囲 2. セキュリティ目標 3. 鍵の選択表 4. ハッシュ・MAC・署名 5. ハイブリッド暗号 6. PKI検証 7. エンベロープ手順 8. 試験の罠 9. クイックシートと復習 10. 問題

1. 公式範囲と用語

本回はIPA Ver.7.2の大分類3／中分類11 セキュリティに正確に対応する。1. 情報セキュリティ > (1) 情報セキュリティの目的と考え方 は PDF 53／冊子49頁、1 > (8) 情報セキュリティに関する技術 > ① 暗号技術 は PDF 54／冊子50頁から PDF 55／冊子51頁までである。② 認証技術 と ⑤ 公開鍵基盤 は PDF 55／冊子51頁にある。利用者認証、MFA・生体認証、認可、アクセス制御の詳細はAP20に譲る。

KO	JA	EN
기밀성	機密性	confidentiality
무결성	完全性	integrity
진정성	真正性	authenticity
대칭키(공통키) 암호	共通鍵暗号	symmetric-key cryptography
공개 키 / 개인 키	公開鍵／秘密鍵	public key / private key
해시 / 메시지 인증 코드	ハッシュ／メッセージ認証コード	hash / MAC
전자서명(디지털 서명)	デジタル署名	digital signature
인증 기관 / 신뢰 앵커	認証局／トラストアンカー	CA / trust anchor

2. セキュリティ目標

• 機密性は無許可の閲覧を防ぎ、完全性は無許可の変更を検出し、真正性はデータ又は主体の出所・身元の主張を裏付ける。
• 可用性は必要なときに利用できることである。広いセキュリティ目標には含まれるが、暗号だけでは提供できない。
• 暗号化だけで完全性や真正性が必ず得られるわけではない。認証付き暗号は、共有鍵の前提の下で機密性と完全性・データ出所認証を提供できる。

3. 正しい鍵を選ぶ

全て合成した人物名である。

目的	送信者／生成者	受信者／検証者	要点
Alice→Bobの共通鍵による機密性	共有秘密 K で暗号化	同じ秘密 K で復号	両者が一つの秘密を共有
Alice→Bobの公開鍵による機密性	Bobの公開鍵でBob宛てに暗号化／鍵ラップ	Bobの秘密鍵で復号／アンラップ	受信者の鍵ペア
Aliceのデジタル署名	Aliceの秘密／署名鍵で署名	Aliceの公開／検証鍵で検証	署名者の鍵ペア
CAによる証明書署名	CA秘密鍵でCAが署名	依拠当事者が発行CA公開鍵で検証	発行者の鍵ペア

後二行を「秘密鍵による暗号化」と一般化してはならない。現代の署名方式は、必要な符号化・乱数化規則を伴う署名生成・検証アルゴリズムであり、多くはダイジェストを対象にする。署名はメッセージを暗号化しない。

4. ハッシュ，MAC，デジタル署名

方式	鍵	支援する性質	重要な限界
暗号学的ハッシュ	なし	固定長ダイジェスト。信頼済みダイジェストがあれば変更検出	誰でも再計算でき、ハッシュだけでは出所を認証できない
MAC／HMAC	共有秘密	完全性と共有鍵によるデータ出所認証	全鍵保有者が生成でき、誰が生成したかを区別できず、否認防止を提供しない
デジタル署名	秘密署名鍵・公開検証鍵	完全性と真正性	否認防止には身元、排他的な鍵管理、時刻、方針の証拠も必要。署名自体は暗号化でない

範囲となるハッシュの性質には一方向性／原像計算困難性、第二原像計算困難性、衝突発見困難性がある。SHA-256／SHA-3はハッシュの例で、HMACは暗号学的ハッシュと秘密鍵を組み合わせる。AESは共通鍵ブロック暗号であり、ハッシュ又は署名アルゴリズムではない。

5. ハイブリッド暗号

大容量ファイルでは、Aliceがランダムな共通のコンテンツ暗号鍵 CEK を生成し、適切な認証付き暗号でバルクデータを効率よく保護する。単純な鍵配送方式なら CEK をBobの公開鍵でラップする。BobはBobの秘密鍵で CEK を回復し、データを復号・認証する。公開鍵処理は小さな鍵を、共通鍵暗号はバルクデータを扱う。

これは試験レベルの鍵配送例であり、全プロトコルがセッション鍵を文字どおり暗号化するという意味ではない。実プロトコルは認証された鍵合意によって共有秘密を導出する場合もある。

6. 証明書とPKI検証

証明書は、発行者の主張と方針の下で主体／名前を公開鍵に結び付ける公開オブジェクトである。秘密でもペイロード暗号でもない。

service.example では、提示された リーフ／サーバ証明書 → 中間CA証明書（群）→ 設定済みの信頼するルート／トラストアンカーをたどる。依拠当事者は、該当する次の事項を確認する。

1. 候補証明パスを構築し、各発行者署名を検証する。
2. 要求した名前／身元（例：service.example）との一致を確認する。
3. 検証時点における各証明書の有効期間を確認する。
4. 基本制約とパス長制約を適用する。
5. 用途に合う鍵用途と拡張鍵用途を適用する。
6. 方針に従いCRL及び／又はOCSPで失効状態を扱う。

トラストアンカーはローカル設定又は方針によって信頼される。ルート証明書が自己署名だから信頼されるのではなく、パス検証でアンカーを自己署名だけで証明される通常の証明書として扱わない。失効情報を取得できないことは良好状態の証拠ではない。soft-fail、hard-failなどの扱いは方針が決める。

7. エンベロープ暗号とPKIの手順

AliceがBobへ署名済みの機密パッケージを送る。

1. Aliceは文書 M をハッシュし、Aliceの署名秘密鍵で署名生成アルゴリズムを実行して S を作り、M と S をまとめる。
2. ランダムな CEK を生成し、そのパッケージを認証付き暗号化して暗号文と認証データを作る。
3. この単純な鍵配送例では、AliceはBobの公開鍵で CEK をラップし、ラップ済み鍵と保護済みパッケージを送る。
4. BobはBobの秘密鍵で CEK をアンラップし、パッケージを認証付き復号する。認証検査が失敗すれば拒否する。
5. Aliceの証明書を得て、ローカルのトラストアンカーまでチェーンを検証する。署名、Aliceの主張された身元、時刻、制約、用途、方針上必要なCRL／OCSP状態を確認する。
6. 検証済みAlice公開鍵で M に対する S を検証する。これは署名の完全性・真正性を確認する。否認防止の結論には鍵管理、身元、時刻、方針の証拠も要る。

鍵の用途は分離される。Bobの鍵ペアは受信者の機密性、Aliceの鍵ペアは署名、CA鍵は公開鍵の結び付けの認証に使う。

8. 試験の罠

• 機密性には受信者の公開鍵、署名には署名者の秘密鍵を使う。
• ハッシュだけでは出所認証にならず、暗号化が自動的に完全性を与えるわけでもない。
• MACは公開検証方式ではなく、共有鍵保有者のうち一人を特定できない。
• 署名は署名対象データを認証するが隠さず、一般的な「秘密鍵暗号化」ではない。
• 証明書は身元／名前と公開鍵を結び付けるが、アプリのペイロードを暗号化しない。
• 自己署名だけでは信頼は生じない。失効照会の失敗は「良好」ではない。

9. クイックシート・自己確認・1/3/7日復習

• クイックシート：共通鍵: K/K、機密性: Bob公開→Bob秘密、署名: Alice秘密→Alice公開、証明書: CA秘密→CA公開、ハッシュ=鍵なし、MAC=共有鍵、署名=秘密／公開鍵。
• 自己確認：四行の鍵表、暗号化と完全性の違い、ハッシュ／MAC／署名の比較、ハイブリッド暗号、全パス検証項目を説明できるか。
• 1日目：鍵マトリクスとエンベロープを描き直す。3日目：PKIチェーンと六検査を見ずに再現する。7日目：全問を解き直し、全誤答の理由を説明する。

10. オリジナル四択5問

Q1

Aliceが公開鍵暗号によってBobだけが回復できる機密データを送りたい。正しい鍵方向はどれか。 ア Alice公開→Alice秘密。 イ Bob公開→Bob秘密。 ウ Alice秘密→Bob公開。 エ CA秘密→ルート公開。

正解：イ(2)。 アはBobでなくAliceを対象にする。イは受信者Bobの公開鍵で暗号化しBobの秘密鍵で回復する。ウは署名と無関係な鍵を混同する。エはペイロード機密性でもBobの鍵ペアでもない。

Q2

正しい比較はどれか。 ア ハッシュだけで生成者を認証する。 イ HMACによって複数の共有鍵保有者の誰が生成したかを検証者が証明できる。 ウ 署名は秘密署名鍵と公開検証鍵、HMACは共有秘密を使い、ハッシュ自体は鍵なしである。 エ デジタル署名は秘密性のためメッセージを暗号化する。

正解：ウ(3)。 アは誰でもハッシュ可能な点を無視する。イは全共有鍵保有者がMACを生成可能な点を無視する。ウは三者を正しく分ける。エは真正性・完全性と機密性を混同する。

Q3

正しいハイブリッド暗号の説明はどれか。 ア ランダムな共通コンテンツ鍵でバルクデータを処理し、単純な鍵配送方式では受信者公開鍵でその鍵を保護する。 イ コンテンツのハッシュだけで秘密になる。 ウ 全バルクデータをCA秘密鍵で暗号化する。 エ 全実プロトコルは必ずセッション鍵を文字どおり暗号化する。

正解：ア(1)。 アは効率的なハイブリッドパターンである。イに機密性はない。ウはCA署名とコンテンツ暗号化を混同する。エは秘密を導出する認証済み鍵合意方式を無視する。

Q4

service.example の妥当な検証手順はどれか。 ア リーフが期限内なら信頼する。 イ ルートが自己署名なので信頼する。 ウ OCSPに到達不能なら良好が証明されたと扱う。 エ リーフ→中間CA（群）→設定済みトラストアンカーを構築し、発行者署名、名前、時刻、制約、用途、方針上の失効状態を確認する。

正解：エ(4)。 アは身元、チェーン、制約、用途、失効方針を欠く。イは自己署名と設定済みの信頼を混同する。ウは不明を良好に変える。エは必要な検証手順である。

Q5

署名と否認防止を最も正確に述べるものはどれか。 ア 鍵盗難や方針に関係なく有効な署名は常に本人の行為を証明する。 イ 署名は完全性・真正性を支援するが、否認防止には身元、鍵管理、時刻、方針の証拠も必要である。 ウ 署名は必ずメッセージを隠す。 エ 共有鍵MACはどの鍵保有者が生成したかを一意に証明する。

正解：イ(2)。 アは鍵使用が証明する範囲を誇張する。イは条件付きの証拠要件を正しく述べる。ウは署名と暗号化を混同する。エは全共有鍵保有者がMACを生成できる点を無視する。

解答：[2, 3, 1, 4, 2] = [イ, ウ, ア, エ, イ]

公式出典と告知

一次資料、2026-10-21確認：IPA syllabus Ver.7.2、NIST FIPS 197 AES、FIPS 180-4 SHS、FIPS 198-1 HMAC、FIPS 186-5 DSS、SP 800-57 Part 1 Rev.5、SP 800-56B Rev.2、RFC 5280、RFC 6960、RFC 9525、NIST SP 800-38D。

この独自執筆の学習資料はIPA、NIST、IETFと提携していない。過去問題又は第三者解説を使用せず、合格を保証しない。