【情報セキュリティマネジメント】デジタル署名とタイムスタンプの違い、分かるのは「誰の鍵か」と「いつまでに」|署名鍵・検証鍵・時刻認証・否認防止

デジタル署名とタイムスタンプは、どちらも電子データの信頼性を高める技術です。

しかし、確認する対象は異なります。

  • デジタル署名:対応する署名鍵で署名が生成されたことと、署名後の完全性を確認する
  • タイムスタンプ:対象データが特定時点までに存在し、その時点以後に変更されていないことを確認する
  • 暗号化:内容を第三者へ読ませない
  • MAC:共有秘密鍵を持つ主体による生成と完全性を確認する

学習上は、次のように整理すると見分けやすくなります。

「誰が」に関係するのがデジタル署名、「いつ」に関係するのがタイムスタンプ、「隠す」のが暗号化です。

ただし、「デジタル署名があれば、現実の本人が自ら内容へ同意したと必ず証明できる」「タイムスタンプが示す時刻が文書の作成時刻である」と断定してはいけません。

署名鍵の管理、検証鍵と本人との結び付き、証明書の有効性、業務上の権限、タイムスタンプの発行主体なども確認する必要があります。

この記事では、ハッシュ関数・メッセージダイジェストを土台に、デジタル署名の生成・検証、タイムスタンプの仕組み、両者が示すこと・示さないことを整理します。

読み終えるころには、事例に出てくる仕組みが「誰が」「いつ」「隠す」のどれを扱っているかを見分け、技術的な検証で済む範囲と、業務手続で確認すべき範囲の境目を自分で判断できるようになります。

先に結論:何を確認でき、何を確認できないか

仕組み 主に確認できること 単独では確認できないこと
デジタル署名 対応する署名鍵による署名生成、署名後の完全性 機密性、信頼できる第三者時刻、内容の真実性
タイムスタンプ 特定時点までの存在、その時点以後の完全性 作成者の本人性、意思・権限、内容の真実性
MAC 共有秘密鍵の保有者のいずれかによる生成、完全性 共有者のうち誰が生成したか、第三者への否認防止
暗号化 内容の機密性 署名者、存在時刻、内容の妥当性

デジタル署名とタイムスタンプを組み合わせると、「誰の署名鍵に対応する署名か」「何が署名されたか」「いつまでに存在したか」を相互に補えます。

ただし、技術的な検証結果と、現実の本人の意思、契約権限、法的効果は同一ではありません。

1.デジタル署名の目的

デジタル署名は、公開鍵暗号技術を基盤とする認証技術で、電子データについて次を確認するために利用します。

  • 対応する署名鍵を用いて署名値が生成されたこと
  • 署名後に対象データが変更されていないこと
  • 第三者に対して署名者を示す証拠となり、否認防止を支えること

ただし、署名検証が成功しただけで、現実の本人が必ず自ら端末を操作し、内容を確認して同意したと断定できるわけではありません。

署名を想定する本人へ結び付けて判断するには、署名鍵の適切な管理と、検証鍵がその本人に対応することの確認が必要です。さらに、業務上の同意や権限まで判断する場合は、本人確認や承認手続も別途確認します。

デジタル署名は真正性・完全性・否認防止を支える技術ですが、暗号学的な検証結果だけで本人の意思や権限まで証明するものではありません。

2.署名鍵と検証鍵

デジタル署名では、数学的に対応する二つの鍵を使用します。

管理・公開 用途
署名鍵 署名者が秘密に管理する 署名値を生成する
検証鍵 検証者へ公開する 署名値を検証する

SGシラバスでは、デジタル署名の用語例として「署名鍵」「検証鍵」が明示されています。

暗号化との違い

機密性を確保する公開鍵暗号では、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号します。

一方、デジタル署名では、署名者の署名鍵で署名を生成し、署名者に対応する検証鍵で検証します。

目的 処理
受信者だけに読ませる 受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する
署名者と完全性を確認する 署名者の署名鍵で署名を生成し、署名者の検証鍵で検証する

「秘密鍵で暗号化し、公開鍵で復号する」とだけ覚えると、機密性を守る暗号化とデジタル署名を混同します。

本教材では、次のように表現を分けます。

  • 暗号化:暗号化・復号
  • デジタル署名:署名生成・署名検証

3.メッセージダイジェストを利用する理由

一般的なデジタル署名では、対象文書へハッシュ関数を適用してメッセージダイジェストを生成し、その値を利用して署名を生成・検証します。

メッセージダイジェストは、ハッシュ関数の出力、すなわちハッシュ値です。

署名生成の基本的な流れ

  1. 署名対象の文書からメッセージダイジェストを計算する
  2. 署名者の署名鍵を用いて署名値を生成する
  3. 文書、署名値、必要な証明書などを相手へ渡す

長い文書も固定長のダイジェストへまとめられるため、効率的に署名処理を行えます。

ただし、「ダイジェストそのものがデジタル署名である」という説明は誤りです。

  • メッセージダイジェスト:文書から計算したハッシュ値
  • デジタル署名:署名鍵を用いて生成した署名値

両者は関連しますが、同じものではありません。

4.デジタル署名の検証手順

A社の署名者から電子契約書とデジタル署名を受信した場合を考えます。

暗号学的な署名値を確認する

  1. 受信した文書から、署名時と同じハッシュ関数でダイジェストを計算する
  2. A社署名者に対応する検証鍵で署名を検証する
  3. 署名が示す値と、受信文書から求めた値の対応を確認する

署名後に文書が変更されていれば、受信文書から求めるダイジェストが変化し、通常は署名検証に失敗します。

検証鍵の信頼性も確認する

暗号学的な署名値が正しくても、使用した検証鍵が本当に想定する署名者のものかを確認できなければ、署名者の識別にはつながりません。

デジタル証明書などにより検証鍵と署名者の識別情報との結び付きを確認し、その証明書を信頼してよいかも確認します。証明書チェーン、有効期間、失効状態などの詳細は「PKIとデジタル証明書」の記事で扱います。

なお、「証明書チェーン」という用語名自体は、SGシラバスVer.4.1の用語例には明示されていません。本記事では、検証鍵を信頼できるか判断するための関連知識として扱います。

署名の確認では、「署名値の暗号学的な検証」と「検証鍵を信頼してよいかの確認」を分けて考えます。

5.署名検証でよくある誤り

誤った手順 問題点
受信者の秘密鍵で署名を検証する 署名者に対応する検証鍵を使用する
署名者の署名鍵を受け取り、同じ署名を再生成する 署名鍵は署名者が秘密に管理する前提である
受信文書を受信者の公開鍵で暗号化して比較する 暗号化は機密性の処理であり、署名検証ではない
署名値の検証だけで本人確認も完了したと考える 証明書、失効、鍵管理なども確認する
証明書が存在すれば必ず有効と考える 有効期間、失効状態、証明書チェーンを確認する

署名鍵を共有してはいけない理由

署名鍵を他者へ渡すと、他者もその署名者として検証に通る署名を生成できる可能性があります。

その場合、次の前提が崩れます。

  • 署名鍵を署名者だけが管理しているという前提
  • その署名者以外は有効な署名を生成できないという前提
  • 署名者が後から容易に否定できないという前提

したがって、署名鍵は受信者へ渡さず、署名者側で厳格に管理します。

6.署名検証に成功しても自動的には分からないこと

適切な前提の下で署名検証に成功すると、対応する署名鍵によって署名が生成され、署名後に対象データが変更されていないことを確認できます。

しかし、次はデジタル署名だけでは自動的に保証されません。

  • 文書に書かれた内容が事実である
  • 契約条件が適法・妥当である
  • 署名者が契約締結権限を持っている
  • 署名者が内容を十分に理解した
  • 署名者本人が実際に端末を操作した
  • 署名鍵が不正利用されていない
  • 文書が第三者から読めない
  • 信頼できる正確な署名時刻
  • 契約が法的に有効である

技術的な検証結果は重要ですが、業務手続・本人確認・権限確認・法令要件を置き換えるものではありません。

7.デジタル署名は内容を暗号化しない

デジタル署名を付与しても、文書本文は通常、そのまま読むことができます。

署名の目的は、機密性ではなく、対応する署名鍵による署名生成とデータの完全性を検証することです。

処理 主な目的
署名だけ 署名者に対応する鍵と完全性を確認する
暗号化だけ 内容を読める者を限定する
署名と暗号化 真正性・完全性と機密性を組み合わせる

「署名鍵が秘密鍵なので、署名を付ければ文書も秘密になる」という説明は誤りです。

検証鍵は公開され、多数の検証者が署名を確認できることがデジタル署名の特徴です。

8.MACとの違い

MAC(Message Authentication Code:メッセージ認証符号)とデジタル署名は、どちらも完全性と生成元の確認に利用できますが、鍵の共有関係が異なります。

比較項目 MAC デジタル署名
送受信者などが共有秘密鍵を使用する 署名者の署名鍵と公開の検証鍵
生成者 共有秘密鍵を持つ者なら生成できる 原則として署名鍵の保有者
検証者 共有秘密鍵を持つ者 検証鍵を取得した者
第三者への証明 共有者のうち誰が生成したか区別しにくい 証明書・鍵管理を前提に署名者を確認できる
否認防止 向かない 支える
機密性 提供しない 提供しない

A社とB社が同じMAC鍵を共有している場合、A社だけでなくB社も正しいMACを生成できます。

そのため、第三者へ「A社だけが生成した」と証明する用途には向きません。

デジタル署名では、署名鍵を署名者だけが管理することを前提として、第三者による検証と否認防止を支えます。

9.タイムスタンプ:特定時点までの存在を示す

タイムスタンプは、対象データのハッシュ値と信頼できる時刻情報を結び付ける仕組みです。

時刻認証局・時刻認証サービスなどが発行するタイムスタンプを検証することで、一般に次を確認します。

  • 対象データが、その時刻までに存在していたこと
  • その時刻以後、対象データが変更されていないこと

「作成時刻」ではなく「遅くともその時刻までに存在」

タイムスタンプが示すのは、対象データが遅くともその時刻までに存在していたことです。

その文書が実際に作成された瞬間を必ず示すわけではありません。

例えば、前日に作成した文書へ翌日にタイムスタンプを付けた場合、タイムスタンプによって確認できるのは、翌日の発行時刻までに文書が存在していたことです。

10.タイムスタンプの基本的な流れ

  1. 利用者が対象文書からハッシュ値を生成する
  2. ハッシュ値を時刻認証サービスへ送信する
  3. サービスが信頼できる時刻情報などを結び付ける
  4. サービスがタイムスタンプトークンを発行する
  5. 後日、対象文書から再計算したハッシュ値とトークンを検証する
  6. 時刻認証サービスの署名・証明書なども確認する

一般的な時刻認証では、文書本体ではなくハッシュ値を送信します。

そのため、時刻認証サービスへ文書内容そのものを渡さずに処理できる構成が可能です。

ただし、ハッシュ関数が安全であること、タイムスタンプトークンを適切に検証すること、発行者と証明書を信頼できることが必要です。

11.タイムスタンプと似た時刻情報の違い

仕組み 主な役割 タイムスタンプの代わりにならない理由
PC・サーバの作成日時 ファイル属性として時刻を記録する 利用者やプログラムが変更できる
NTP(Network Time Protocol)による時刻同期 機器の時計を基準時刻へ合わせる 対象データと時刻を暗号学的に結び付けない
アクセスログ 操作・アクセスの時刻を記録する ログの管理主体や改ざん耐性を別途確認する必要がある
署名内の自己申告時刻 署名ソフトなどがローカル時刻を記録する 信頼できる第三者時刻とは限らない
信頼できるタイムスタンプ データのハッシュ値と信頼できる時刻を結び付ける 発行者の署名・証明書を含めて検証する

「時計が正しいこと」と、「その時刻までに特定のデータが存在したことを第三者が検証できること」は別です。

なお、NTPという用語名自体は、SGシラバスVer.4.1の用語例には明示されていません。本記事では、タイムスタンプとの違いを理解するための関連知識として扱います。

12.タイムスタンプが単独では保証しないこと

タイムスタンプが確認する中心は、存在時刻と、その時点以後の完全性です。

次は単独では保証しません。

  • 誰が文書を作成したか
  • 誰が文書へ同意したか
  • 作成者が権限を持っていたか
  • 文書内容が事実であるか
  • 契約条件が妥当であるか
  • 文書が第三者から読めないか
  • 文書がタイムスタンプ発行時刻に作成されたか
  • 契約が法的に有効か

標準的な時刻認証の仕組みでは、時刻認証局は要求者の識別情報をタイムスタンプトークンへ含めません。そのため、トークンだけから「誰が要求したか」は分かりません。

作成者・署名者の確認には、デジタル署名、証明書、本人確認、業務上の承認手続などを組み合わせます。

13.デジタル署名とタイムスタンプを組み合わせる

電子文書について「誰が」「何を」「いつ」を確認したい場合は、複数の仕組みを組み合わせます。

  • デジタル署名:どの署名鍵に対応する署名か、署名後に変更されていないか
  • デジタル証明書:検証鍵と署名者の識別情報を結び付ける
  • タイムスタンプ:特定時点までに存在し、その後変更されていないか
  • 暗号化:文書を読める者を限定する
  • 業務手続:本人の意思・権限・承認を確認する

長期保存では後から検証できる情報を残す

署名やタイムスタンプを長期間にわたって検証するには、署名時点の証明書や失効情報など、後から当時の有効性を確認できる情報を保存し、必要に応じてタイムスタンプを更新します。

長期署名や証明書管理の詳細は「PKIとデジタル証明書」の記事以降で扱います。

なお、「長期署名」という用語名自体は、SGシラバスVer.4.1の用語例には明示されていません。本記事では、長期保存時の検証を理解するための関連知識として扱います。

14.電子署名とデジタル署名を区別する

SGシラバスの認証技術として明示される用語は「デジタル署名」です。

「電子署名」は、法律や電子契約を含む文脈でより広く使われることがあり、JIPDECもデジタル署名を公開鍵暗号方式を利用する電子署名の一種として整理しています。

したがって、電子的な署名・同意の方法が、常に暗号学的なデジタル署名と同じ仕組みとは限りません。

本記事は技術としてのデジタル署名を扱います。電子署名法上の要件、真正成立の推定、認定認証業務などの法的論点は「通信・電子取引に関する法律」の記事で扱います。

15.科目Bでの使われ方

科目Bでは、署名やタイムスタンプの数学的な仕組みではなく、その場面で技術的な検証だけを根拠に判断していないかを問う形で使われます。

事例文に次の言葉が出てきたら、この記事の内容が判断材料になります。

事例文の合図 確認すること
電子契約書に署名があるので本人が同意したものとして処理した 鍵管理・証明書・権限の確認まで済んでいるか
取引先から「その文書は送っていない」と言われた 使っているのは署名かMACか、第三者へ示せるか
ファイルの更新日時を存在時刻の証拠にしようとしている 信頼できるタイムスタンプか、端末の自己申告時刻か
署名を付けたので内容が外部に漏れる心配はない 機密性には別途暗号化が必要ではないか
数年前の署名文書をこれから検証したい 当時の証明書・失効情報が残っているか

担当者としては、確認したいのが「誰が」「何を」「いつ」「隠す」のどれかを切り分け、いま使っている仕組みで足りるかを判断します。技術的な検証結果だけで本人の意思や権限まで判断せず、本人確認や承認手続と組み合わせます。判断に迷う場合や、取引先との取決めに関わる場合は、上位者へ報告し、契約担当者と協力して対応します。

16.署名と時刻を見分ける手順

  1. 内容を秘密にしたいのか、署名者と完全性を確認したいのか

秘匿なら暗号化、署名者・完全性ならデジタル署名です。

  1. 誰の鍵で署名を生成したか

署名者の署名鍵を使用します。

  1. 誰の鍵で検証するか

署名者に対応する検証鍵を使用します。

  1. 検証鍵を信頼してよいか

証明書、証明書チェーン、有効期間、失効状態を確認します。

  1. メッセージダイジェストを署名そのものと混同していないか

ダイジェストはハッシュ値で、署名生成・検証に利用されます。

  1. 特定時点までの存在を確認したいか

その場合は信頼できるタイムスタンプを利用します。

  1. タイムスタンプを本人確認として扱っていないか

タイムスタンプ単独では作成者・同意者を確認しません。

  1. 「その時刻に作成された」と言い過ぎていないか

確認できるのは、遅くともその時刻までに存在したことです。

  1. 機密性まで自動的に得られると考えていないか

署名もタイムスタンプも、文書内容を隠しません。

よくある取り違え

誤った理解 正しい整理
デジタル署名は受信者の秘密鍵で検証する 署名者に対応する検証鍵で検証する
署名者の署名鍵を受信者へ渡して再計算する 署名鍵は署名者が秘密に管理する
秘密鍵を使うので文書も暗号化される デジタル署名は機密性を提供しない
署名検証に成功すれば、本人が必ず自ら同意した 鍵管理、証明書、本人確認、権限・承認も確認する
検証鍵があれば本人の鍵だと自動的に分かる 証明書などで検証鍵と本人の結び付きを確認する
メッセージダイジェストがデジタル署名そのものである ダイジェストを利用して署名値を生成する
MACがあれば特定の送信者を第三者へ証明できる 共有者双方が生成でき、否認防止には向かない
タイムスタンプは文書の正確な作成時刻を示す 特定時点までに存在していたことを示す
タイムスタンプがあれば作成者も確定する 単独では本人・作成者を確認しない
NTPで時刻同期すればタイムスタンプと同じである NTPは時計を合わせる仕組みで、データと時刻を証明しない
アクセスログの時刻だけで存在時刻を暗号学的に証明できる ログ管理主体・改ざん耐性などを別途確認する必要がある
署名内の端末時刻は信頼できる第三者時刻である 自己申告時刻と信頼できるタイムスタンプは異なる
タイムスタンプがあれば文書内容も秘密になる 機密性には別途暗号化が必要
デジタル署名と電子署名は常に完全な同義語である 技術用語と制度・法律上の用語を区別する

まとめ

  • デジタル署名は、署名者の署名鍵で生成し、対応する検証鍵で検証する
  • 一般的には、文書から生成したメッセージダイジェストを署名処理に利用する
  • 署名検証には、署名値の暗号学的検証と、検証鍵を信頼できるかの確認がある
  • 検証鍵と署名者の結び付きは、デジタル証明書などで確認する
  • 証明書の有効期間、失効状態、証明書チェーンも確認する
  • 適切な鍵管理と本人への結び付きを前提に、デジタル署名は真正性・完全性・否認防止を支える
  • 署名検証だけで、本人の実操作、意思、権限、内容の真実性を無条件に断定しない
  • デジタル署名は文書を暗号化せず、機密性には別の暗号化が必要
  • MACは共有者双方が生成できるため、特定人物による生成を第三者へ証明する否認防止には向かない
  • タイムスタンプは、対象データのハッシュ値と信頼できる時刻情報を結び付ける
  • タイムスタンプで確認するのは、特定時点までの存在と、その時点以後の完全性
  • タイムスタンプの発行時刻は、文書の正確な作成時刻とは限らない
  • タイムスタンプ単独では、作成者、同意者、権限、内容の真実性を確認しない
  • NTP、ファイル日時、アクセスログ、自己申告の署名時刻は、信頼できるタイムスタンプと同じではない
  • 電子文書の信頼性を高めるには、署名、証明書、タイムスタンプ、暗号化、業務手続を目的に応じて組み合わせる
  • 長期保存では、証明書・失効情報・タイムスタンプなど、後から検証するための情報も管理する
  • SGの技術問題ではデジタル署名を扱い、電子署名法上の効果は法律の記事へ分ける
  • 科目Bでは、「誰が」「何を」「いつ」「隠す」のどれを確認したいかを切り分ける

関連記事

  • C2-T01:暗号方式の基本(鍵管理・危殆化を含む)
  • C2-T03:ハッシュ関数とメッセージ認証
  • C2-T05:PKIとデジタル証明書
  • C5-T09:ログ管理と監視
  • C5-T11:セキュアプロトコルと実装技術
  • C8-T06:通信・電子取引に関する法律

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

  • IPA「情報セキュリティマネジメント試験(レベル2)シラバス Ver.4.1」
  • IPA「電子署名について」
  • NIST FIPS 186-5「Digital Signature Standard」
  • RFC 3161「Internet X.509 Public Key Infrastructure Time-Stamp Protocol」
  • JIPDEC「電子署名についてのFAQ」
  • JIPDEC「電子証明書を利用したアプリケーションについてのFAQ」

関連する問題


コメント

タイトルとURLをコピーしました