デジタル署名で改ざんを検知する仕組みとは｜PKI・電子署名との違いをSC試験対策で解説

「送ったはずのデータが途中で書き換えられていないか」「本当にこの相手が作ったものか」。この2つを同時に、しかも第三者に対して証明できる形で保証するのがデジタル署名です。そして、その署名検証に使う「公開鍵」が本物であることを社会的に担保するのがPKI（公開鍵基盤）です。

この記事では、まず多くの人がつまずく「デジタル署名がどうやって改ざんを検知するのか」の仕組みをハッシュ値の比較という一点に絞って解説し、続いて電子署名との違い、PKIと認証局（CA）の役割、そして情報処理安全確保支援士（SC）試験で狙われる出題パターンまでを一気に整理します。

私がCIOとして情報システムを統括していた頃、個人情報を格納したCD-Rを本人限定受取郵便でやり取りしていました。物理的な「実印と印鑑証明」でしか本人性を担保できなかった時代です。デジタル署名とPKIは、その「実印と印鑑証明」をネットワーク上で再現する技術だと理解すると、腹落ちが早くなります。ハッシュ関数やメッセージ認証コード（MAC）の基礎が曖昧な方は、先に暗号と認証の全体像を整理した記事で土台を固めておくと本記事の理解が深まります。

デジタル署名で改ざんを検知する仕組み（ハッシュ値の比較）

デジタル署名の中核は「2つのハッシュ値を比較して、一致するかどうかで改ざんの有無を判定する」という一点に尽きます。まずこの仕組みだけを正確に押さえれば、あとの応用はすべてここから派生します。

なぜハッシュ値を使うのか

ハッシュ関数は、任意の長さのデータから固定長の「要約値（ハッシュ値）」を計算する関数です。入力が1ビットでも変われば出力が大きく変わるため、ハッシュ値は元データの「指紋」として機能します。データ全体を秘密鍵で処理すると計算が重くなりますが、短いハッシュ値だけを署名対象にすれば、大きなファイルでも効率的に扱えます。

この「指紋」の性質があるからこそ、元データが1文字でも書き換えられれば、受信側で再計算したハッシュ値が署名から取り出したハッシュ値と食い違い、改ざんが検知できるのです。

署名作成と検証の流れ（改ざん検知のフロー）

送信者をAさん、受信者をBさんとして、署名の作成から検証までの流れを追います。

デジタル署名の作成と検証のフロー図。送信側はメッセージのハッシュ値を計算し秘密鍵で暗号化して署名を作り、受信側は送信者の公開鍵で署名を復号したハッシュ値と、受信メッセージから再計算したハッシュ値を比較して改ざんを検知する

【送信側（Aさん）：署名作成】

送りたいメッセージのハッシュ値（要約）を計算します
このハッシュ値を、Aさんの「秘密鍵」で暗号化します。これが「デジタル署名」です
「元のメッセージ」と「デジタル署名」をセットで相手に送ります

【受信側（Bさん）：署名検証】

受け取った「デジタル署名」を、Aさんの「公開鍵」で復号します → ハッシュ値（X）が出てきます
受け取った「元のメッセージ」から、自分でハッシュ値を計算します → ハッシュ値（Y）が出てきます
ハッシュ値XとYを比較します。完全に一致すれば「改ざんされておらず、Aさん本人が署名した」と証明されます

もし途中で誰かがメッセージを書き換えていれば、受信者が計算したハッシュ値（Y）は、署名から取り出したハッシュ値（X）と一致しません。この「XとYの不一致」こそが改ざん検知の正体です。逆に言えば、デジタル署名は「どこが」書き換えられたかを特定したり、元に戻したりはできません。あくまで「一致するか・しないか」で改ざんの有無を判定する技術である点を押さえてください。

改ざん検知はハッシュ値の比較であることを示す図。署名から公開鍵で取り出したハッシュ値Xと、受信データから再計算したハッシュ値Yを天秤で比較し、一致すれば改ざんなし、不一致なら改ざんありと判定する

また、悪意ある第三者が偽の署名を作ろうとしても、Aさんの秘密鍵を持っていないため、Aさんの公開鍵で正しく復号できる署名を作ることはできません。

公開鍵暗号の「逆利用」という発想

署名作成で「秘密鍵で暗号化」と書きました。これは公開鍵暗号方式の使い方を逆にしたものです。通常の暗号化通信では「公開鍵で暗号化し、秘密鍵で復号」しますが、デジタル署名では「秘密鍵で処理し、公開鍵で検証」します。

「秘密鍵」は世界で送信者本人しか持っていません。もしAさんの公開鍵で正しく復号できたなら、そのハッシュ値は「間違いなく秘密鍵を持つAさん本人が作成した」と言い切れます。現実世界で本人しか押せない実印と同じ発想です。

※厳密には、現代の主流な署名方式（楕円曲線DSAなど）では「暗号化・復号」とは異なる署名専用の計算を行いますが、本記事では仕組みを直感的に理解しやすい従来のRSA方式のモデルで解説しています。

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

電子署名とデジタル署名の違い

試験でも実務でも混同されやすいのが「電子署名」と「デジタル署名」です。結論から言うと、電子署名は広い概念、デジタル署名はその中の一手法という包含関係にあります。

電子署名は「意思表示」全般を指す広い概念

電子署名とは、電子文書に対して「誰がその内容に合意したか」を示すための仕組み全般を指す言葉です。実現方法は特定の技術に限定されません。メール末尾に名前を入力する、「同意します」のチェックボックスを押す、タッチ画面に手書きするといった簡易な方法も、広義には電子署名に含まれます。日本の電子署名法（電子署名及び認証業務に関する法律）でも、本人性と非改ざん性を満たす措置であれば手段は限定されていません。

デジタル署名は公開鍵暗号を用いた技術的措置

デジタル署名は、公開鍵暗号方式とハッシュ関数を用いて、改ざん検知と本人証明を暗号技術的に実現する具体的な手法です。認証局（CA）が発行する電子証明書と組み合わせることで、完全性・真正性・否認防止を強力に保証します。

つまり「電子署名」という大きな箱の中に、暗号技術で裏付けられた「デジタル署名」が入っている、という関係です。試験では「電子署名＝広い」「デジタル署名＝公開鍵暗号を用いた技術限定」の区別を押さえておけば十分です。なお、デジタル署名は「誰が」「何に」署名したかは証明できますが、「いつ」署名したかは保証しないため、実務では時刻を保証するタイムスタンプと併用されることが多い点も覚えておくと応用が利きます。

MACとデジタル署名の違い（否認防止ができるか）

前提として、メッセージ認証コード（MAC）もデジタル署名も「完全性」と「真正性」を保証します。しかし決定的に異なるのが否認防止（Non-repudiation）の有無です。ここはSC試験で繰り返し狙われる論点です。

デジタル署名が保証する3つのこと

完全性（Integrity）: データが改ざんされていないこと（内部でハッシュ関数を使います）
真正性（Authenticity）: 間違いなく本人が作成したこと
否認防止（Non-repudiation）: 本人が「やっていない」と否定できないこと

MACはなぜ否認防止できないのか

MACは送信者と受信者が同じ共通鍵を共有します。そのため受信者も同じMACを作成でき、「本当に送信者が作ったのか、受信者が偽造したのか」を第三者が判断できません。つまり送信者が「私は送っていない」と言い張れば、それを覆す手段がないのです。

一方、デジタル署名の秘密鍵は本人しか持っていないため、言い逃れができません。裁判などの法的な場面でも「この署名は本人が行った」という証拠として使えます。「共通鍵か、本人だけの秘密鍵か」が否認防止の分かれ目だと覚えてください。

なぜ「公開鍵」が本物だと信じられるのか（PKIの役割）

ここまでの署名検証には、送信者の「公開鍵」が必要でした。しかし、その公開鍵自体が偽物だったら、仕組みは根底から崩れます。この問題を解決するのがPKIです。

その「公開鍵」、偽物じゃないですか？（中間者攻撃）

悪意ある第三者（Cさん）が、AさんとBさんの通信の間に割り込み、Aさんの「本物の公開鍵」を「Cさん自身の公開鍵」にすり替えて渡したらどうなるでしょうか。Bさんは偽の公開鍵で検証してしまい、Cさんが送った偽データを「Aさんからの本物」と信じ込んでしまいます。

これは「中間者攻撃（Man-in-the-Middle Attack）」と呼ばれます。署名の計算がいくら完璧でも、公開鍵の出所が保証されなければ、仕組みごと無効化されてしまうのです。だからこそ「この公開鍵は間違いなくAさんのものだ」と証明する第三者が必要になります。

PKI（公開鍵基盤）とは

この問題を解決する社会的な仕組みが「PKI（Public Key Infrastructure：公開鍵基盤）」です。信頼できる第三者機関が公開鍵の持ち主を保証する仕組み全体を指し、技術だけでなく法律・組織・運用ルールを含む総合的な「基盤（インフラストラクチャ）」です。

現実世界で例えるなら印鑑登録制度です。役所で印鑑登録を行い印鑑証明書を発行してもらうことで、「この印影は間違いなく本人のものだ」と第三者に証明できます。PKIはこれをデジタルの世界で実現したものと考えると分かりやすいでしょう。

信頼の要「認証局（CA）」と「電子証明書」

PKIの中心となるのが「認証局（CA: Certificate Authority）」です。デジタルの世界における「役所」のような存在で、次の流れで電子証明書を発行します。

申請: Aさんは認証局（CA）に自分の「公開鍵」と身分証明書を提出し、「これは私の公開鍵です」と登録申請します
審査（身元確認）: CAは厳格に審査します。企業なら登記簿謄本、個人なら身分証明書などで申請者の身元を確認します
証明書発行: 審査に問題がなければ、CAは「電子証明書（デジタル証明書）」を発行します

電子証明書には次の情報が含まれます。

シリアル番号（証明書の識別番号）
署名アルゴリズム（使用しているハッシュ関数や暗号の方式）
証明書の所有者の名前（個人名や組織名）
所有者の公開鍵
証明書の有効期限
発行したCAの情報
CAのデジタル署名（これが最も重要）

つまり電子証明書とは、Aさんの「公開鍵」に、CAが「これは間違いなくAさんの鍵です」というお墨付き（CAのデジタル署名）を付けたデータです。現実世界の「印鑑登録証明書」と同じ役割を果たします。受信者（Bさん）はこの証明書をCAの公開鍵で検証することで、「Aさんの公開鍵は本物だ」と安心して使えるようになります。

信頼の連鎖：ルート証明書

「では、CAの公開鍵はどうやって信頼するの？」という疑問が湧きます。PKIはここで「信頼の連鎖（Chain of Trust）」という考え方を使います。

最上位には「ルートCA」があり、その証明書（ルート証明書）はOSやブラウザに最初から組み込まれています。私たちは「このルートCAは信頼できる」という前提から出発しているわけです。そしてルートCAが中間CAを認証し、中間CAが個々のWebサイトや個人を認証するという階層構造により、末端のエンドユーザーの証明書まで信頼が伝わります。

PKIの信頼の連鎖を示す階層図。OS・ブラウザに組み込まれたルートCAが中間CAを認証し、中間CAがWebサイトや個人などのエンドエンティティを認証することで、末端まで信頼が伝わる

学び始めの人がつまずきやすいのが、自己署名証明書（いわゆる「オレオレ証明書」）です。自分で自分を保証しているだけで、この信頼の連鎖につながっていないため、ブラウザは警告を出します。テスト環境で警告を消したいからと安易に警告を無視する癖をつけると、本番でも中間者攻撃を見逃す危険な習慣になります。

証明書の失効管理（CRLとOCSP）

秘密鍵の漏えいなどが起きた場合、有効期限前でも証明書を無効化する必要があります。その仕組みが失効管理です。SC試験でも頻出なので、2方式の違いを押さえましょう。

CRL（Certificate Revocation List：証明書失効リスト）: 失効した証明書のシリアル番号を一覧化したもの。クライアントがリストを取得して照合しますが、サイズが肥大化しやすく、失効が即時には反映されにくい課題があります
OCSP（Online Certificate Status Protocol：オンライン証明書状態プロトコル）: 証明書のシリアル番号をOCSPレスポンダに問い合わせ、「有効／失効／不明」の応答をリアルタイムに得る方式。RFC 6960で規定されています

CRLとOCSPは「一覧をまとめて取得するか、1件ずつ即時に問い合わせるか」の対比で覚えると混同しません。

身近な利用例（メール・電子契約・e-Tax）

デジタル署名とPKIは、日常生活の中で既に広く使われています。

電子メール（S/MIME）

重要な契約書や機密情報をメールで送る際、S/MIME（Secure/Multipurpose Internet Mail Extensions）を使うとメールにデジタル署名を付けられます。受信者は署名を検証することで「間違いなく取引先の担当者から送られた」「内容が途中で書き換えられていない」と確信できます。

クラウド電子契約サービス

紙の契約書の代わりに、PDFファイルなどにデジタル署名を行い法的効力を持たせる電子契約が普及しています。従来は印鑑を押して郵送していた契約書がオンラインで完結でき、締結スピードの向上とコスト削減につながります。

オンライン行政手続き（e-Tax・マイナンバーカード）

確定申告をオンラインで行うe-Taxでは、マイナンバーカードによる本人認証が行われます。カード内には秘密鍵と電子証明書が格納されており、カードリーダーに挿入してPINコードを入力すると、カード内の秘密鍵でデジタル署名が実行されます。これにより「間違いなく本人が申告した」と証明でき、税務署は申告を受理できます。

SC試験での出題パターンと対策

デジタル署名とPKIは、情報処理安全確保支援士試験の午前II・午後で繰り返し出題される最重要テーマです。過去問の傾向から、押さえるべき論点を整理します。

鍵の使い分け（最頻出のひっかけ）

最も狙われるのが「どの鍵を使うか」です。暗号化通信とデジタル署名では鍵の使い方が真逆になります。

暗号化通信（TLSのハンドシェイクなど）: 受信者の公開鍵で暗号化 → 受信者の秘密鍵で復号
デジタル署名: 送信者の秘密鍵で署名 → 送信者の公開鍵で検証

「暗号化は相手に読ませたいので相手の公開鍵」「署名は自分が書いた証明なので自分の秘密鍵」と、目的から逆算すると混同しません。TLSでの公開鍵の使われ方をあわせて確認したい方はIPsec VPNとSSL-VPNの違いを解説した記事も参考になります。

午前IIで問われる定番論点

デジタル署名の目的を問う設問は、SC試験の前身である情報セキュリティスペシャリスト試験の平成21年春期午前II 問5でも出題されており、正解は「送信者が署名鍵（秘密鍵）を使って署名を作成し、受信者が送信者を確認できるようにする」という趣旨の選択肢でした。ここでも問われているのは「秘密鍵で署名し、公開鍵で検証する」という向きです。デジタル署名がメッセージ本文を暗号化する技術ではない点、改ざん箇所の特定・訂正まではできない点が、そのまま誤答選択肢として繰り返し使われます。

証明書の失効確認については、応用情報技術者試験の平成26年秋期午前問38で「デジタル証明書が失効しているかどうかをオンラインでリアルタイムに確認するためのプロトコルはどれか」が出題され、正解はOCSPでした。同種の失効確認の論点はSCでも繰り返し問われるため、CRLとOCSPの違いは確実に得点源にしておきたいところです。

PKIの構成要素

各要素の役割も頻出です。

CA（認証局）: 電子証明書を発行する信頼できる第三者機関
RA（登録局）: 証明書発行の申請受付や身元確認を行う（CAの業務を補助）
CRL（証明書失効リスト）: 有効期限前に無効化された証明書のリスト
OCSP（オンライン証明書状態プロトコル）: 証明書の有効性をリアルタイムに確認するプロトコル

午前IIの暗号・認証分野を集中的に演習したい方は、午前II 過去問ノック（暗号・認証編）で本記事の知識を実戦形式で試してみてください。

【演習】デジタル署名とPKIの理解度チェック（全10問）

デジタル署名とPKIは、午前IIでは鍵の使い分け・保証する性質・失効確認プロトコルを問う4択、午後では証明書検証や中間者攻撃を含む事例読解として出題されます。定番のひっかけは「暗号化と署名で使う鍵の取り違え」と「MACとデジタル署名の否認防止の混同」です。以下の練習問題で本記事の理解度を確認してみましょう。

【練習問題】デジタル署名とPKIの基礎理解度チェック（全10問）

まとめ：改ざん検知と信頼の基盤を押さえる

今回は、デジタルの世界で「信頼」を確立する核心技術を、改ざん検知の仕組みから整理しました。

デジタル署名の本質は、送信者の秘密鍵で署名し公開鍵で検証すること、そして署名から取り出したハッシュ値と受信データから再計算したハッシュ値を比較して改ざんを検知することにあります。完全性・真正性に加え、MACでは実現できなかった否認防止までを備え、デジタルデータに「実印」相当の効力を持たせます。

PKI（公開鍵基盤）は、認証局（CA）が「公開鍵が本物であること」を保証する社会的な仕組みで、電子証明書はデジタルの「印鑑証明書」として機能します。中間者攻撃を防ぎ、信頼の連鎖と失効管理（CRL・OCSP）で運用を支えます。

私がCIOだった頃はCD-Rを本人限定受取郵便で送るしかありませんでしたが、いまはこの2つの技術で、遠隔でも「実印と印鑑証明」に匹敵する信頼をネットワーク上に築けます。電子契約・オンライン申請・セキュアな通信の多くが、この土台の上に成り立っています。鍵の向きとハッシュ値の比較という2点を軸に、繰り返し過去問で定着させていきましょう。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。