ディジタル署名の作成と検証で使う鍵の向きを、暗号化との対比で整理。確保できる特性（完全性・真正性・否認防止）と確保できない機密性、ハッシュ値に署名する理由、コード署名やタイムスタンプまで解説します。
ディジタル署名は、「この文書は確かにこの人が作り、その後変わっていない」ことを示す仕組みです。紙の印鑑と違うのは、文書の中身と結び付いている点です。中身が一文字でも変われば検証は失敗します。情報処理安全確保支援士試験では、暗号化との鍵の向きの違いが繰り返し問われます。
署名は送信者の秘密鍵で作り、送信者の公開鍵で検証します。秘密鍵を持っているのは本人だけなので、その鍵でしか作れないものが付いていれば、本人が作ったと言えます。一方、暗号化は受信者の公開鍵で行い、受信者の秘密鍵で復号します。「誰の」「どちらの」鍵かで四通りあり、ここを混同すると設問で落とします。
| 目的 | 処理する側 | 使う鍵 | 確かめる側 | 使う鍵 |
|---|---|---|---|---|
| 機密性（読ませない） | 送信者 | 受信者の公開鍵 | 受信者 | 受信者の秘密鍵 |
| 真正性（誰が作ったか） | 送信者 | 送信者の秘密鍵 | 受信者（誰でも） | 送信者の公開鍵 |
署名で確保できるのは、完全性（変わっていないこと）と真正性（誰が作ったか）です。真正性が確かめられることで、後から「自分は送っていない」と言えなくなる——否認防止にも繋がります。一方で、機密性は確保できません。署名を付けても中身はそのまま読めます。読まれたくないなら、暗号化と併用します。この線引きを問う設問はよく出ます。
公開鍵暗号の処理は重いため、長い文書をそのまま扱うと現実的な時間で終わりません。そこで、文書を短い固定長のハッシュ値に変えてから署名します。検証する側は、届いた文書から同じようにハッシュ値を計算し、署名から取り出した値と比べます。処理量が文書の長さに左右されなくなるのが利点です。
この仕組みの前提は、同じハッシュ値になる別の文書を作れないことです。もし衝突を作れてしまえば、正規の署名がそのまま別の文書に通ってしまいます。SHA-1 での署名が使われなくなったのは、この衝突が現実的に作れるようになったためです。ハッシュ関数の強度が、そのまま署名の強度になります。
ハッシュ値の照合だけでは足りない場面があります。配布物のハッシュ値が公開値と一致すれば「配布時から変わっていない」ことは分かりますが、その公開値自体が本物かは別問題です。配布元の真正性まで確かめるには署名が要ります。ハッシュで何が言えて、何が言えないか——この違いが設問になります。
署名だけでは「いつ作られたか」は保証されません。署名した本人が時刻を自由に書けるからです。第三者の時刻認証局が、その時刻にその文書が存在したことを証明するのがタイムスタンプです。署名に使った証明書が後で失効しても、失効前に署名されたことを示せるため、長期の保存が必要な文書で併用されます。
署名が数学的に正しく検証できたとしても、それだけでは十分ではありません。検証に使った公開鍵が、本当に名乗っているとおりの相手のものかを確かめる必要があります。ここで効いてくるのが電子証明書で、信頼する認証局が発行したものか、有効期限内か、失効していないかまで確かめて、初めて「この相手が作った」と言えます。検証処理を自前で実装するときに、この確認を省いてしまう不備が実際に見つかっています。
鍵の管理も同じ重みを持ちます。署名用の秘密鍵が漏えいすれば、その鍵で作られた署名はすべて疑わしくなります。だから、署名用の鍵は暗号化用の鍵と分け、耐タンパ性のある装置に保管し、取り出せないようにするのが基本です。持ち出せない場所に置いておけば、鍵そのものが漏れるという事態を構造的に避けられます。
午前Ⅱでは、署名の作成・検証に使う鍵と、確保できる特性が定番です。「機密性も確保できる」という選択肢は誤りなので、そこで切れます。午後では、配布物の検証手順や、更新プログラムの適用手順の中で、署名の検証をどこに入れるかを書かせる形が出ます。書くときは「送信者の秘密鍵で署名し、受信者が送信者の公開鍵で検証する」と、誰のどちらの鍵かまで明示すると観点を落としにくくなります。
IPA 公式：過去問題（情報処理安全確保支援士試験） ↗各年度の問題冊子・解答例・採点講評の PDF を、公式サイトで確認できます。