午前I問題

デジタル署名の生成と検証に関する記述として、適切なものはどれか。

ア）送信者は、送信データを送信者の公開鍵で暗号化したものを署名として付加する。　イ）署名の検証では、受信者は送信者の秘密鍵を使って署名を復号し、データのハッシュ値と比較する。　ウ）送信者はデータのハッシュ値を生成し、そのハッシュ値を自分の秘密鍵で暗号化したものを署名として付加する。　エ）デジタル署名は送信データの暗号化を主目的としており、データの改ざん検知には利用できない。

午前I の解答・解説を見る

正解： ウ

解説： デジタル署名の生成は「①送信者がデータのハッシュ値を計算→②送信者の秘密鍵でハッシュ値を暗号化（署名）→③署名を元データに付加して送信」という手順で行われます。検証では受信者が送信者の公開鍵で署名を復号してハッシュ値を取り出し、受信データから算出したハッシュ値と一致するか照合します。ア）誤り。署名に使うのは「公開鍵」ではなく「秘密鍵」です。公開鍵は誰でも使えるため、公開鍵で暗号化しても送信者本人が作成した証明になりません。イ）誤り。受信者が復号に使うのは送信者の「公開鍵」です。秘密鍵は送信者だけが保持しており、受信者は入手できません。エ）誤り。デジタル署名の主目的は「否認防止」と「改ざん検知（完全性保証）」です。送信データ自体の機密性保護はハイブリッド暗号方式などで別途行います。

午前II問題

RFC 3161 に基づくタイムスタンプに関する記述として、適切なものはどれか。

ア）タイムスタンプ要求では、電子文書の全データをTSA（タイムスタンプ局）に送信し、TSAがその全データに対して署名してトークンを返す。　イ）タイムスタンプは、電子文書が特定の時刻に存在したことを証明するが、その時刻以降に文書が改ざんされていないことの確認には使用できない。　ウ）RFC 3161 のタイムスタンプトークン（TST）には、電子文書のハッシュ値・TSAが認定した時刻情報・TSAの電子署名が含まれる。　エ）TSA証明書が失効または期限切れになった場合、それ以前に発行されたタイムスタンプトークンはすべて無効となり、文書の存在時刻を証明できなくなる。

午前II の解答・解説を見る

正解： ウ

解説： RFC 3161 の TST（Timestamp Token）は「①電子文書のハッシュ値（文書本体は送らない）」「②TSAが認定した正確な時刻（MessageImprint + genTime）」「③TSAの電子署名（TSA証明書で検証可能）」の3要素で構成されます。ア）誤り。電子文書の全データはTSAに送信しません。ハッシュ値のみを送ることでプライバシー保護と通信量削減を両立しています。イ）誤り。タイムスタンプはその時刻以降の改ざん検知も可能です。文書が改ざんされるとハッシュ値が変化するため、タイムスタンプ内のハッシュ値との不一致で改ざんを検出できます。エ）誤り。TSA証明書が失効・期限切れになっても、失効前に発行されたタイムスタンプの証明力は長期署名形式（CAdES-LT/XAdES-LT）によって維持されます。これが長期署名を採用する主な理由の一つです。

午後問題

B社は従業員2,000名規模の製造業企業であり、現在は取引先との契約書をすべて紙で締結・保管している。デジタルトランスフォーメーション推進の一環として電子契約システムの導入を検討しており、法務部のF氏とシステム担当のG氏が協議を重ねた結果、以下の3つの方針が固まった。

（方針1）電子署名法第3条の「本人性」および「同一性」の要件を満たす当事者型電子署名を基本とする。 （方針2）税法・会社法上の文書保存要件（最長10年）を満たすため、長期署名形式（CAdES-LT）を採用する。 （方針3）電子署名環境を持たない取引先向けの代替として、クラウド型電子契約サービスによる立会人型署名も併用する。

G氏は上記方針を実装するにあたり、社内CAの構築ではなくパブリックCAから発行された電子証明書を利用する設計とした。また、将来的な暗号アルゴリズムの危殆化に備えた移行計画の策定も経営層から求められている。

設問1

方針1について、電子署名法第3条が規定する「本人性」と「同一性」の要件を、デジタル署名の技術的仕組み（秘密鍵・ハッシュ値）と対応させて説明せよ。また、方針3の立会人型署名が「本人性」の要件を満たすとされる根拠を30字以内で述べよ。

設問1の解答・解説を見る

正解例（要件の説明）：

  • 本人性： 電子署名は署名者本人だけが保持する秘密鍵で生成されるため、第三者が同じ署名を偽造することが計算上不可能であり、署名が存在することは署名者本人が意思をもって作成したことを示す。
  • 同一性： 署名生成時に計算したハッシュ値と、検証時に受信データから算出したハッシュ値を照合することで、署名後に文書が改ざんされていないことを確認できる。

正解例（立会人型署名の根拠・30字以内）：
サービス事業者がメール認証等で本人確認を行い、署名に本人の同意を記録するため。

解説： 電子署名法第3条は「電磁的記録に電子署名が行われているときは、真正に成立したものと推定する」と規定し、その前提として①当該電子署名を行える者が本人に限られること（本人性）と②文書の内容が署名後に変更されていないこと（同一性）の2要件が必要です。立会人型署名はGMOサインやクラウドサインなどのサービスが代表例で、本人確認をサービス事業者が行い、その記録（アクセスログ・メール認証等）が否認防止の証跡となります。電子署名法の「本人」性要件を完全に満たすかは法的議論がありますが、実務上は事業者の記録を根拠として有効性が認められています。

採点基準（12点）：

  • 本人性：「秘密鍵は署名者本人のみ保持」＋「第三者による偽造が不可能」（4点）
  • 同一性：「ハッシュ値の照合」＋「改ざん検知」（4点）
  • 立会人型の根拠：「サービス事業者による本人確認・同意記録」の主旨を30字以内で記述（4点）

設問2

方針2について、CAdES-LT（長期署名）を導入する理由を「証明書失効」と「タイムスタンプ」の両語を用いて説明せよ（3文以内）。また、10年間の保存期間中に署名アルゴリズム（RSA-2048 / SHA-256）が危殆化した場合に備えた技術的対策を1つ具体的に挙げよ。

設問2の解答・解説を見る

正解例（CAdES-LT導入の理由）：
通常の電子署名は、署名に用いた証明書が失効・期限切れになると検証が困難になる。CAdES-LTは署名時点の証明書チェーン・CRL/OCSPレスポンスをタイムスタンプとともに署名データに埋め込むことで、署名後に証明書が失効しても有効性を長期間維持できる。これにより10年以上の文書保存要件を技術的に担保する。

正解例（危殆化対策）：
署名データ全体（元の署名＋証明書チェーン＋タイムスタンプ）に、より強固なアルゴリズム（例：SHA-3やポスト量子暗号PQC対応アルゴリズム）で新しいアーカイブタイムスタンプを付与し直す「タイムスタンプの更新（Archive Timestamp）」を定期的に実施する。

解説： CAdES（CMS Advanced Electronic Signature）のレベル体系はB→T→LT→LTAの順に強化されます。LTレベルでは証明書失効情報（CRL/OCSPレスポンス）と証明書チェーンを署名に埋め込み、LTAレベルではさらにアーカイブタイムスタンプを付与することでアルゴリズム危殆化にも対応します。SHA-256は現時点で安全とされていますが、NIST SP 800-131Aは使用期限ガイドラインを定期改訂しており、10年の保存期間中に強度が低下するリスクがあります。ポスト量子暗号（PQC）への移行も2030年代以降に向けて準備が必要です。

採点基準（13点）：

  • 理由：「証明書失効後も検証可能にする」意図（3点）＋「タイムスタンプで時刻と証明書を埋め込む」仕組み（4点）＋「10年保存要件への対応」（2点）
  • 危殆化対策：「アーカイブタイムスタンプの更新」または「より強固なアルゴリズムへの付け替え」を具体的に記述（4点）

重要キーワード

用語説明
ハッシュ関数任意長のデータを固定長のダイジェスト値に変換する一方向性関数。SHA-256等が標準。改ざん検知の基盤
RSA素因数分解の計算困難性に基づく公開鍵暗号。デジタル署名の生成・検証に広く利用される
PKI（公開鍵基盤）CA・RA・証明書・CRLで構成されるデジタル証明書の発行・管理基盤。デジタル署名の信頼基盤
TSA（タイムスタンプ局）RFC 3161に基づきタイムスタンプトークン（TST）を発行する認定機関。電子文書の存在証明を担う
CAdES-LT（長期署名）証明書チェーン・失効情報・タイムスタンプを署名データに埋め込み、証明書失効後も長期検証を可能にする署名形式
否認防止送信者が「署名していない」と主張することを技術的に防ぐデジタル署名の性質。秘密鍵の唯一性が根拠

まとめ

  • 午前I視点： デジタル署名は「秘密鍵でハッシュ値を暗号化」「公開鍵で復号して照合」の流れが基本。主目的は否認防止と改ざん検知であり、機密性保護ではないことを押さえる
  • 午前II視点： RFC 3161 タイムスタンプはハッシュ値のみをTSAに送り、TSTに「ハッシュ値＋時刻＋TSA署名」が格納される。タイムスタンプは存在証明と改ざん検知の両方を担い、証明書失効後も長期署名で有効性が維持される
  • 午後視点： 電子署名法第3条の本人性・同一性をデジタル署名の技術と対応づけて説明できるよう準備する。CAdES-LTは「証明書失効後の検証継続」が核心で、危殆化対策としてのアーカイブタイムスタンプ更新もセットで理解する