デジタル署名とは？電子署名との違い・仕組み・活用場面をわかりやすく解説

「デジタル署名と電子署名、何が違うの？」

「コード署名やS/MIMEを設定しろと言われても、仕組みがよくわからない」

こうした疑問を持つエンジニアは少なくありません。デジタル署名は現代のセキュリティ基盤を支える技術でありながら、「なんとなく知っている」で済ませてしまいがちな概念です。

実際の現場では、ソフトウェアの改ざん検知・メールの真正性確認・契約書の電子化など、あらゆる場面でデジタル署名が使われています。仕組みを正しく理解していないと、設定ミスや誤った信頼判断につながり、セキュリティインシデントの原因になりかねません。

この記事では、デジタル署名の仕組みと電子署名との違いを基礎から解説し、現場エンジニアが「明日から業務で使える」レベルの知識として整理します。コード署名・メール署名・電子契約の3つの活用場面も具体的に取り上げます。

デジタル署名とは？3つの保証を理解する

デジタル署名（digital signature）とは、公開鍵暗号とハッシュ関数を組み合わせ、デジタルデータの「送信者が本物であること」と「内容が改ざんされていないこと」を数学的に証明する技術です。

デジタル署名が保証するのは、次の3つです。

・真正性（Authenticity）: そのデータを作成・送信したのが本人であることを確認できる
・完全性（Integrity）: 署名後にデータが1バイトも改ざんされていないことを検証できる
・否認防止（Non-repudiation）: 署名者が後から「送っていない」「作っていない」と言い張ることを防ぐ

なぜこの技術が重要なのでしょうか。たとえば、システム管理者がソフトウェアのアップデートをダウンロードするとします。そのファイルが公式ベンダーから配布されたものか、攻撃者がすり替えたマルウェアなのか、見た目だけでは判断できません。デジタル署名があれば、ファイルが本物のベンダーによって署名されたかどうかを数秒で検証できます。

この「数学的に証明できる」という点が、デジタル署名を単なる慣習的なハンコと根本的に異なる点です。証明に使う秘密鍵を持っている人だけが署名を生成できるため、なりすましや改ざんを技術的に排除できます。

電子署名との違い―日本の法律を踏まえて整理する

「電子署名」と「デジタル署名」は、似ているようで指し示す範囲が異なります。混同すると法的な効力の判断を誤る可能性があるため、正確に理解しておきましょう。

日本には「電子署名及び認証業務に関する法律」（電子署名法）があり、この法律が想定する「電子署名」は実質的に公開鍵暗号を用いたデジタル署名を指しています。法的効力が求められる契約書類には、電子署名法の要件を満たす方式を採用する必要があります。

セキュリティエンジニアとして押さえておきたいのは、「電子署名という言葉が使われていても、それが公開鍵暗号ベースのデジタル署名かどうかは確認が必要」という点です。単なる「同意ボタン」を押す行為を「電子署名した」と表現しているサービスもあり、安全性のレベルは方式によって大きく異なります。

デジタル署名の仕組み―ハッシュと公開鍵暗号の組み合わせ

デジタル署名は、ハッシュ関数と公開鍵暗号（非対称暗号）の2つの技術を組み合わせて実現します。難しそうに聞こえますが、順を追うと構造はシンプルです。

1. 署名の生成（送信側の操作）

まず、署名したいデータ（ファイルやメッセージ）をハッシュ関数に通して「ハッシュ値（フィンガープリント）」を生成します。SHA-256を使う場合、どんな大きさのデータでも256ビットの固定長に変換されます。

# ファイルのSHA-256ハッシュ値を確認する（Linux）
sha256sum contract.pdf
# 出力例: a3f8e1c2d4b7...  contract.pdf

# OpenSSLでファイルに署名する（秘密鍵が必要）
openssl dgst -sha256 -sign private_key.pem -out contract.pdf.sig contract.pdf

次に、このハッシュ値を署名者の秘密鍵（private key）で暗号化します。この暗号化されたデータが「デジタル署名」です。元のデータ（contract.pdf）とデジタル署名（contract.pdf.sig）をセットで受信者に送ります。

2. 署名の検証（受信側の操作）

受信者は署名者の公開鍵（public key）を使って、送られてきたデジタル署名を復号します。これにより「ハッシュ値A」が得られます。さらに、受け取った元データを自分でハッシュ関数に通して「ハッシュ値B」を計算します。

# 受信側での署名検証
openssl dgst -sha256 -verify public_key.pem -signature contract.pdf.sig contract.pdf
# ハッシュ値A（署名から復号）とハッシュ値B（ファイルから計算）が一致 → Verified OK
# 不一致の場合 → Verification Failure（改ざんまたは別人の署名）

・ハッシュ値A = ハッシュ値B のとき → 署名者本人が送った正真正銘のデータ
・ハッシュ値A ≠ ハッシュ値B のとき → データが改ざんされているか、署名が偽造されている

秘密鍵を持っている人だけが正しいデジタル署名を作れます。公開鍵は署名の復号（検証）にしか使えません。つまり「この公開鍵で検証できた＝対応する秘密鍵の持ち主が署名した」という証明になります。

重要な点をひとつ補足します。デジタル署名はデータを暗号化しません。署名されたデータは誰でも中身を読めます。「誰が作ったか・改ざんされていないか」を証明するのが目的であり、機密性（内容を秘匿する）とは別の話です。機密性が必要な場合は署名に加えて暗号化を適用します。

デジタル署名の実際の活用場面

デジタル署名は、現場のエンジニアが日常的に触れる様々な技術の基盤になっています。

1. コード署名（ソフトウェアの真正性確認）

macOSでアプリをインストールしようとして「開発元が未確認です」というダイアログを見たことがあるはずです。これはAppleのコード署名（Gatekeeper）が機能しているサインです。

正規の開発者はAppleやMicrosoftの認証局（CA）から発行された証明書でコードに署名します。OSはインストール・実行時にこの署名を検証し、署名なし・署名不一致のファイルを弾きます。サプライチェーン攻撃でソフトウェアが改ざんされても、コード署名が正しく機能していれば検知できます。

Linuxでも、パッケージ管理システム（apt / dnf）がリポジトリから取得するパッケージをGPG署名で検証しています。

# GPG署名の確認（RPMパッケージの例）
rpm --checksig some-package.rpm
# some-package.rpm: digests signatures OK

# aptリポジトリのGPGキー確認
apt-key list

# GPGでファイルに署名する（秘密鍵が必要）
gpg --armor --detach-sign document.pdf
# document.pdf.asc が生成される

# 署名の検証
gpg --verify document.pdf.asc document.pdf

2. メールのデジタル署名（S/MIME・DKIM）

「このメールは本当にあの取引先から来たのか？」という疑問に答えるのがメールのデジタル署名です。方式が異なる2つを整理します。

・S/MIME: メールクライアント（Outlook・Thunderbird等）に個人証明書を設定し、メール単位で署名する。受信者は送信者の公開証明書で署名を検証できる。フィッシングメールのなりすましを検知できる
・DKIM（DomainKeys Identified Mail）: メールサーバーレベルで送信ドメインの正当性を署名する。送信者が意識しなくてもサーバーが自動で署名し、受信側サーバーが検証する

DKIMはドメイン全体に適用できるため、設定の費用対効果が高い方式です。SPF・DMARCと組み合わせることで、なりすましメール対策としてより強固になります。

なお、姉妹サイトLinuxMaster.JPでは、PostfixへのDKIM設定（opendkim）など、メールサーバーの実践的な設定方法を解説しています。

3. 文書への電子署名（PDF・クラウドサービス）

契約書や発注書のペーパーレス化で急速に普及しているのが、PDF文書へのデジタル署名とクラウド電子署名サービスです。

・PDF署名（Adobe Acrobat / Preview等）: 証明書ベースの署名をPDFに埋め込む。Adobe ReaderやPreviewで署名の有効性を視覚的に確認できる
・クラウドサービス（クラウドサイン・DocuSign・GMOサイン等）: ブラウザ上で完結する電子署名。電子署名法に準拠したサービスが多く、法的効力を持つ

クラウド電子署名サービスは、認証局との連携やPKIの管理をサービス側が肩代わりするため、企業側の技術的な負担が少ないのが利点です。ただし、プラットフォームへの依存が生まれる点と、利用しているサービスの証明書方式が電子署名法の要件を満たすかどうかは事前に確認しましょう。

中小企業でも今日からできること

デジタル署名というと「大企業のもの」と思われがちですが、小規模な組織でも段階的に導入できます。

・DKIMの設定（コスト: 無料）: 自社ドメインのメールサーバーにDKIM署名を設定する。なりすましメールを防ぎ、自社メールの到達率も改善できる。設定は1回で済み、以降は自動で動作する
・GPGでのファイル署名（コスト: 無料）: 重要ファイルの配布時にGPG署名を付ける。受け取った側が改ざんを検証でき、シェルスクリプトや設定ファイルの配布にも応用できる
・クラウド電子署名（コスト: 月額数千円～）: 取引先との契約書の電子化に対応できる。各サービスに無料プランがあり、まず試しやすい
・コード署名証明書（コスト: 年額数万円）: 社内ツールや配布ソフトへの署名でWindowsのSmartScreen警告を回避し、ユーザーの信頼度を上げる

最初の一歩として最も着手しやすいのはDKIMの設定です。メールサーバーに1回設定すれば、以降は自動で動作します。フィッシング対策と到達率改善を同時に実現できるため、コスト対効果が非常に高い施策です。

次のステップとしてGPGを活用すると、社内で重要ファイルを配布する際に改ざん検知の仕組みを持てます。「以前と同じファイルか」をハッシュ値で確認する習慣をチームに広めるだけでも、セキュリティ意識の底上げになります。

よくある誤解と注意点

【誤解1】「デジタル署名されたファイルは暗号化されている」

デジタル署名はデータの真正性と完全性を保証しますが、内容は暗号化しません。署名されたファイルでも、中身は誰でも読めます。機密情報を保護したい場合は、署名とは別に暗号化（PGPなら`–encrypt`オプション等）を適用する必要があります。この2つを混同すると、機密データを意図せず公開してしまうリスクがあります。

【誤解2】「電子署名 = デジタル署名」

電子署名は広義の概念であり、デジタル署名はその一形態です。クリック一つの同意、スキャンした手書きサインなども電子署名に含まれますが、これらは公開鍵暗号を使っていないため、デジタル署名ではありません。法的効力や技術的な安全性のレベルは方式によって大きく異なります。重要な契約には方式の確認が必要です。

【誤解3】「デジタル署名があれば送信者を完全に信頼できる」

デジタル署名の信頼性は、証明書を発行した認証局（CA）の信頼性と秘密鍵が安全に管理されているかに依存します。信頼できないCAが発行した証明書、または秘密鍵が盗まれた場合は、デジタル署名は意味をなしません。

過去には、正規の認証局が侵害されて偽の証明書が発行された事例も発生しています。証明書の失効確認（CRL・OCSP）も運用上の重要な要素です。秘密鍵はHSM（ハードウェアセキュリティモジュール）や専用キーストアで厳重に管理し、必要最低限の人員だけがアクセスできるよう設計しましょう。

本記事のまとめ

デジタル署名の要点を整理します。

デジタル署名は「なんとなく使われているもの」ではなく、現代のインターネットセキュリティを支える根幹技術です。コード署名・メール署名・電子契約のいずれかで必ず関わる技術なので、仕組みを頭に入れておくことで現場での判断がぐっと速くなります。

PKIの仕組みや証明書の詳細については、当サイトの「PKI（公開鍵基盤）とは？」もあわせてご覧ください。