ガイドSG

暗号技術と公開鍵基盤(PKI)の仕組み|共通鍵・公開鍵・電子署名・証明書を基本解説

公開: 2026-10-03更新: 2026-10-05
情報セキュリティマネジメント(SG)の暗号と電子署名の違いを学習。暗号化の鍵と署名の鍵を、誰の鍵かで区別します。比較表とオリジナルの事例問題で、用語の違いや対策を選ぶ根拠を確認します。

暗号と電子署名の違いでは、暗号化の鍵と署名の鍵を、誰の鍵かで区別します。用語を覚えるだけでなく、事例の条件に合う対策を選べるように整理しましょう。

科目Aで基本的な意味を確認し、科目Bでは「守る情報・起きた事象・組織のルール・担当者の権限」を読み取ります。本文の確認問題は、考え方を練習するためのオリジナル問題です。

1. 共通鍵暗号と公開鍵暗号の決定的な相違

暗号化方式には大きく分けて「共通鍵暗号方式」と「公開鍵暗号方式」の2つが存在します。両者の長所と短所を理解することが、すべての暗号問題の出発点です。

方式

使う鍵

特徴・注意

共通鍵暗号

暗号化・復号で同じ鍵

大量のデータに適する。相手と鍵を安全に共有する必要がある

公開鍵暗号

公開鍵と秘密鍵の組

暗号化・署名・鍵確立などに利用する。公開鍵が正しい相手のものか確認が必要

ハイブリッド暗号方式の実務設計

Web通信(TLS/HTTPS)やセキュアメール(S/MIME)では、両者のメリットを組み合わせた「ハイブリッド暗号方式」が標準的に採用されています。

  1. 送信者は、高速な「共通鍵(セッション鍵)」をランダムに生成し、通信データ本文を共通鍵で暗号化する。

  2. 送信者は、受信者の「公開鍵」を使って、セッション鍵だけを暗号化する。

  3. 暗号化されたデータ本文と、暗号化されたセッション鍵を受信者へ送信する。

  4. 受信者は、自分だけの「秘密鍵」で暗号化セッション鍵を復号し、取り出したセッション鍵でデータ本文を復号する。

この仕組みにより、「鍵の配送問題の解決(公開鍵暗号の利点)」と「大量データの高速暗号化(共通鍵暗号の利点)」を同時に実現しています。

2. ハッシュ関数とディジタル署名が担保するもの

暗号化が「機密性(盗聴防止)」を守るのに対し、データの「完全性(改ざん防止)」と「真正性(なりすまし防止・送信者の否認防止)」を担保するのが「ディジタル署名」です。

一方向ハッシュ関数の3大特性

ハッシュ関数(SHA-256等)は、任意の長さのデータから固定長のハッシュ値(メッセージダイジェスト)を生成する関数であり、以下の特性を持ちます。

  • 一方向性(不可逆性):ハッシュ値から元のデータを復元することは現実的な計算で求めることが困難である。

  • 弱衝突困難性:あるデータ M に対し、ハッシュ値が一致する別のデータ M' を見つけることが極めて困難である。

  • 強衝突困難性:ハッシュ値が一致する任意の異なる2つのデータペアを見つけることが極めて困難である。

ディジタル署名の生成と検証の流れ

ディジタル署名は、公開鍵暗号の鍵ペアを暗号化とは「逆向き」に使用します。

処理

使う鍵

確認すること

署名生成

署名者の秘密鍵

本文に対する署名を、署名方式に従って作る

署名検証

署名者の公開鍵

本文と署名の対応を検証する。鍵と本人の対応も証明書等で確認する

【試験の鉄則】暗号化は「受信者の公開鍵」でかけ、「受信者の秘密鍵」で解く。ディジタル署名は「送信者の秘密鍵」でかけ、「送信者の公開鍵」で検証する。

3. 公開鍵基盤(PKI)とディジタル証明書の実務

ディジタル署名において致命的な脆弱性となるのが、「送信者の公開鍵そのものが偽物(なりすまし者の公開鍵)にすり替えられていたらどうするか?」という点です。この問題を解決するのが「公開鍵基盤(PKI)」と「ディジタル証明書(X.509)」です。

  • 認証局(CA:Certification Authority):申請者の身元を審査し、公開鍵に対してCA自身のディジタル署名を付与した「ディジタル証明書」を発行する第三者機関。

  • ルートCAと中間CA:階層構造(信頼の連鎖:Chain of Trust)を形成し、最上位のルート証明書はOSやブラウザに事前インストールされている。

  • 証明書の失効確認:秘密鍵が漏えいした場合や退職時に証明書を失効させるため、CRL(証明書失効リスト)のダウンロードや、リアルタイムに失効照会を行う OCSP(Online Certificate Status Protocol)が運用される。

4. 科目B形式実戦シナリオ演習

演習1:電子契約システムにおける真正性と完全性の検証

〔背景〕製造業A社では、取引先B社との間で業務委託契約を電子化するため、クラウド型電子契約サービスを導入することになった。A社の法務担当者は情報セキュリティリーダーのC氏に、電子署名の仕組みと法的有効性の根拠について確認を求めた。

〔課題と運用設計〕C氏は、電子署名法に準拠した契約フローを策定した。契約書PDFを作成したA社は、自社が信頼する認証局から発行された電子証明書に基づき、契約書に電子署名を付与してB社へ送信する。

〔設問〕次の記述のうち、B社がA社からの電子署名付き契約書を受信した際に行う検証処理として、最も適切なものはどれか。

  • ア:B社は自社の秘密鍵で契約書を復号すれば、A社の署名を確認したことになる。

  • イ:B社は信頼できる手順で確認したA社の公開鍵を使い、契約書本文とディジタル署名を検証する。

  • ウ:B社は認証局の秘密鍵を入手して証明書を復号する。

  • エ:B社はA社の秘密鍵で署名を検証する。

【解答と解説】

正解:イ

イが正解です。署名方式に従ってA社の公開鍵で検証します。「署名はハッシュ値を秘密鍵で暗号化し、公開鍵で復号する」という説明は、全ての署名方式に共通する手順ではありません。検証成功の意味は、信頼できる鍵の確認と秘密鍵の適切な管理を前提に判断します。

  • ア:誤り。B社自身の秘密鍵で復号するのは「B社宛てに暗号化された文書」を読むときの手順です。

  • ウ:誤り。認証局の電子署名は「認証局の公開鍵(ルート証明書等)」で検証します。秘密鍵は認証局自身が厳重に保管しており、第三者は所持していません。

  • エ:誤り。A社の秘密鍵はA社自身しか持っておらず、B社がA社の秘密鍵を使用することはあり得ません。

演習2:証明書失効とWebサイトなりすましリスクへの初動

〔背景〕ECサイトを運営するD社では、WebサーバにSSL/TLSサーバ証明書を導入している。ある日、インフラ担当者が社内検証用サーバのディスクを外部業者へ廃棄依頼した際、本番Webサーバの秘密鍵(Private Key)ファイルが誤って検証用ディスク内に残存していた可能性が判明した。

〔設問〕このインシデントにおいて、秘密鍵の漏えいによる第三者のなりすまし被害を即座に防ぐため、D社が最優先で認証局(CA)に対して実施すべき手続きはどれか。

  • ア:認証局に対して証明書の更新(Renewal)を申請し、有効期限を延長する。

  • イ:認証局に対して証明書の失効(Revocation)を申請し、CRLやOCSPに反映させる。

  • ウ:認証局に対して公開鍵の再暗号化を依頼し、利用者に新パスワードを配布する。

  • エ:WebサーバのDNS設定を変更し、認証局のIPアドレスを自社に向ける。

【解答と解説】

正解:イ

イが正解です。漏えいした秘密鍵に対応する証明書を失効し、新しい鍵と証明書へ切り替えます。失効情報を確認する方式やブラウザの動作は異なり、必ず警告が表示されて全被害が防げるとは限りません。証明書の秘密鍵漏えいで過去の全通信が必ず復号できるという意味でもありません。

5. まとめと試験直前チェックリスト

  • 暗号化:受信者の公開鍵で暗号化 → 受信者の秘密鍵で復号(機密性の担保)

  • 署名:送信者の秘密鍵で署名生成 → 送信者の公開鍵で署名検証(完全性+真正性の担保)

  • ハイブリッド暗号:本文は高速な共通鍵で暗号化し、共通鍵を公開鍵で暗号化して届ける

  • CA(認証局):公開鍵が本人のものであることを証明書と自らの署名で保証する第三者機関

  • 秘密鍵漏えい時:認証局への速やかな失効申請(CRL/OCSP反映)が最優先初動

共通鍵を公開鍵で暗号化して送る流れは、ハイブリッド暗号の一つの例です。TLS 1.3などは一時的な鍵交換等で鍵を確立し、同じ手順をそのまま使うわけではありません。

出典と仕様を確認する

IPA:情報セキュリティマネジメント試験 シラバス Ver.4.1

RFC 8446:TLS 1.3

次におすすめの学習

編集・検証について

編集・検証:IT資格ラボ編集部

IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。

編集方針・情報源・訂正方針を見る
この記事を共有する