ディジタル署名と暗号技術―安全な電子商取引のためのセキュリティシステムと法律基盤 フォード，ウォーウィック、 バウム，マイケル、 日本ベリサイン、 Ford，Warwick、 baum，Michael S.; 慎一郎，山田 価格：1,180円（税込、送料別) (2025/7/12時点) 楽天で購入

第1章: デジタル署名とは？～インターネット社会の「ハンコ」と「封蝋」～

まず、「デジタル署名」とは一体何なのでしょうか？

現実世界で私たちが契約書にサインしたり、印鑑を押したりするのはなぜでしょう？それは、「この書類は確かに私が作成・承認しましたよ」という意思表示と、「この書類は（署名・捺印後に）誰にも改ざんされていませんよ」という証明のためですよね。

デジタル署名も、これと非常によく似た役割をデジタル空間で果たします。具体的には、デジタル署名は主に以下の3つのことを保証します。

• 真正性 (Authentication): その情報が本当に主張された作成者（送信者）から来たものであることを証明します。「確かにAさんからのメッセージだ！」
• 完全性 (Integrity): その情報が途中で改ざんされていないことを証明します。「このファイルは送られてきた時のままだ！」
• 否認防止 (Non-repudiation): 作成者（送信者）が後になって「そんな情報は送っていない」と否認することを防ぎます。「Aさんが送ったことに間違いない、後で知らないとは言わせないぞ！」

つまり、デジタル署名は、「デジタルの世界における、信頼性の高い身元証明と内容保証の仕組み」と言うことができます。これがあるおかげで、私たちは安心してソフトウェアをダウンロードしたり、オンラインで重要な取引を行ったりできるのです。

第2章: デジタル署名の心臓部！支える2大コア技術

デジタル署名がどうやって前述の「真正性」「完全性」「否認防止」を実現しているのか、その秘密は2つの強力な暗号技術にあります。

2.1. ハッシュ関数：データの一意な「指紋」を作る魔法

まず一つ目のコア技術は「ハッシュ関数 (Hash Function)」です。

ハッシュ関数とは、どんなに長いデータ（メッセージやファイルなど）を入力しても、そこから固定長の短い、一見ランダムな文字列（ハッシュ値、またはメッセージダイジェストとも呼ばれます）を生成する関数のことです。まるで、データ全体の「指紋」を取るようなイメージです。

このハッシュ関数には、デジタル署名にとって非常に重要な、以下の3つの特性があります。

• 一方向性 (One-way): ハッシュ値から元のデータを復元することは、計算上ほぼ不可能です。シュレッダーにかけた紙片から元の文書を復元するのが難しいのと似ています。
• 衝突耐性 (Collision Resistance):
  • 弱衝突耐性: あるデータと同じハッシュ値を持つ別のデータを見つけることが非常に困難です。
  • 強衝突耐性: 同じハッシュ値を持つような2つの異なるデータを見つけることが非常に困難です。つまり、意図的に同じ「指紋」を持つ偽のデータを作ることは極めて難しいのです。
• 入力感度 (Avalanche Effect): 元のデータがほんの少しでも変わると、生成されるハッシュ値は全く異なるものになります。1文字違うだけでも、指紋は完全に変わってしまうイメージです。

これらの特性により、ハッシュ値はその元データの「ダイジェスト（要約）」として機能し、データのわずかな変更も検知することができます。代表的なハッシュ関数には、SHA-256（256ビットのハッシュ値を生成）やSHA-3などがあります。

2.2. 公開鍵暗号方式：魔法の鍵ペアが生み出す信頼

二つ目のコア技術は「公開鍵暗号方式 (Public-key Cryptography)」です。

これは、「公開鍵 (Public Key)」と「秘密鍵 (Private Key)」というペアの鍵を使う暗号技術です。この2つの鍵は数学的に密接に関連していますが、一方の鍵からもう一方の鍵を推測することは非常に困難です。

それぞれの鍵の役割は以下の通りです。

• 秘密鍵: 自分だけが厳重に保管し、他人には絶対に見せない鍵。まさに「秘密」の鍵です。銀行の金庫の鍵や、自分しか知らない印鑑のようなものです。
• 公開鍵: 広く一般に公開する鍵。誰でも入手可能です。秘密鍵で作られた署名が本物かどうかを確認するための「見本」のようなものです。

公開鍵暗号方式では、この鍵ペアを使って主に2つのことができます。

1. 暗号化と復号:
   • 公開鍵で暗号化したデータは、ペアになっている秘密鍵でしか復号できません。
   • 秘密鍵で暗号化したデータは、ペアになっている公開鍵でしか復号できません。
2. デジタル署名と検証:
   • 署名: 送信者は、自分の秘密鍵を使って署名を作成します。
   • 検証: 受信者は、送信者の公開鍵を使ってその署名が正しいか検証します。

デジタル署名では、このうち後者の「署名と検証」の仕組みを利用します。「秘密鍵で署名し、公開鍵で検証する」というのが鉄則です。これにより、「秘密鍵を持っている本人しかその署名を作れない」＝「真正性」と「否認防止」が実現できるのです。

代表的な公開鍵暗号アルゴリズムには、RSAやECDSA（楕円曲線DSA）などがあります。

第3章: 実践！デジタル署名の生成と検証プロセス ～信頼が生まれる瞬間～

さて、デジタル署名の心臓部であるハッシュ関数と公開鍵暗号方式を理解したところで、いよいよ実際にデジタル署名がどのように作られ（署名生成）、どのように確かめられるのか（署名検証）を、より詳しくステップごとに見ていきましょう。このプロセスこそが、デジタル情報に「信頼」を吹き込む瞬間です。

3.1. デジタル署名を作る側（署名生成プロセス）～想いを込めた「封印」の儀式～

あなたが「重要プロジェクト計画書.docx」というファイルを作成し、これにデジタル署名を付けて関係者に送るケースを想定してみましょう。

ステップ0: 準備はOK？～署名者の「鍵」と「証明書」～

まず大前提として、あなたは自分自身の「秘密鍵」とそれに対応する「公開鍵」のペアを持っていなければなりません。この鍵ペアは事前に生成しておくものです。そして、あなたの公開鍵が本当にあなたのものであることを第三者（認証局：CA）が証明する「デジタル証明書」も通常は用意しておきます。この証明書によって、受信者はあなたの公開鍵を安心して使うことができます（証明書の詳細は第6章で解説します）。

ステップ1: 対象の明確化～何に署名する？～

署名したい対象、つまり「重要プロジェクト計画書.docx」の元データ（メッセージ）を準備します。このデータの内容が、これから保証される対象となります。

ステップ2: 指紋採取の方法を選ぶ～どのハッシュ関数を使う？～

次に、この「重要プロジェクト計画書.docx」の「指紋」を取るためのハッシュ関数を選びます。一般的には、SHA-256やSHA-512といった、現在安全とされている標準的なハッシュアルゴリズムが利用されます。この選択は、使用する署名ツールやシステムによって自動的に行われることもあります。

ステップ3: 指紋の採取～メッセージダイジェストの生成～

選んだハッシュ関数（例: SHA-256）を使って、「重要プロジェクト計画書.docx」の内容全体からハッシュ値を計算します。このハッシュ値は、元データのユニークな要約であり、「メッセージダイジェスト」とも呼ばれます。
（例: 重要プロジェクト計画書.docx → SHA-256関数 → メッセージダイジェストA）
このメッセージダイジェストAは、もし元データが1ビットでも変われば、全く異なる値になります。

ステップ4: 封印の道具を選ぶ～どの署名アルゴリズムを使う？～

次に、メッセージダイジェストを暗号化（署名）するための公開鍵暗号アルゴリズムを選びます。これは、あなたの秘密鍵とペアになっているアルゴリズムです（例: RSA、ECDSA）。

ステップ5: 秘密のスタンプを押す～秘密鍵による署名処理～

ステップ3で生成したメッセージダイジェストAを、あなたの「秘密鍵」とステップ4で選んだ署名アルゴリズムを使って暗号化します。この「暗号化されたメッセージダイジェスト」こそが、「デジタル署名」そのものです。
（例: メッセージダイジェストA + あなたの秘密鍵 (RSAアルゴリズム使用) → デジタル署名X）
この作業は、あなたしか持っていない秘密鍵で行うため、「この署名はこの秘密鍵の持ち主（つまりあなた）が行った」という強力な証拠になります。

ステップ6: パッケージング～署名と元データをどうまとめる？～

作成された「デジタル署名X」は、元の「重要プロジェクト計画書.docx」と関連付けて送る必要があります。この関連付けの方法は様々です。

• 分離型署名 (Detached Signature): 元データファイル（例：「重要プロジェクト計画書.docx」）とは別に、署名データファイル（例：「署名.sig」や「署名.p7s」）を作成し、これらを一組として扱う方法です。この方式の利点は、元のデータファイルを変更することなく署名を付与・検証できる点にあります。
• 包含型署名 (Enveloped / Enveloping / Embedded Signature): 署名情報を元データ自体に含めてしまう方法です。
  • PDF署名 (PAdES): PDFファイル形式自体が署名情報を内部に格納する標準的な方法を定義しています。対応ソフトウェアはPDF文書内に署名を埋め込みます。
  • XML署名 (XAdESなど): XML署名では、署名情報（<ds:Signature>要素）を元のXML文書内に埋め込んだり（Enveloped）、署名要素が元XMLを包含したり（Enveloping）します。
  • S/MIMEメール署名 (CAdESなど): 元メッセージ、署名情報、証明書などを一つの暗号メッセージ構文（CMS）としてまとめ、例えば「smime.p7m」のような単一のファイルやメールの一部として扱います。

多くの場合、デジタル署名には、署名に使ったアルゴリズムの情報や、あなたの公開鍵を検証するためのデジタル証明書（またはその参照情報）も一緒にパッケージ化され、受信者が検証作業をスムーズに行えるようになっています。

ステップ7: いざ、発送！～信頼を届けるための最終準備～

最後に、元の「重要プロジェクト計画書.docx」と、それに対応する「デジタル署名X」（そして通常はあなたのデジタル証明書も含む関連情報）をセットにして、相手に送信します。
（送信物: 重要プロジェクト計画書.docx + デジタル署名Xと関連情報）

この「セットにする」具体的な方法は、ステップ6で触れたパッケージング方式によって異なります。

• 分離型署名の場合: 元ファイルと署名ファイルを、例えば一つの圧縮ファイル（ZIPなど）にまとめたり、メールに両方のファイルを添付したりして送ります。受信者は両方のファイルを使って検証を行います。
• PDF署名のようにデータと署名が一体化している場合: その署名済みPDFファイルをそのまま送ります。受信者はPDFビューアで署名を確認できます。
• S/MIMEによるメール署名の場合: メールクライアント（例: Outlook, Thunderbird）が、標準化された形式（multipart/signedなど）に従ってメールを構成し、署名情報を含めて送信します。受信側のメールクライアントがこれを解釈して署名を表示・検証します。

このように、送信者は、受信者が元データとそれに対応する署名、そして検証に必要な情報を確実に受け取り、検証プロセスを開始できるように、適切な方法でこれらを「セット」として提供するわけです。

これで、あなたの想い（と内容の保証）を込めた「封印」の儀式は完了です。

3.2. デジタル署名を確かめる側（署名検証プロセス）～封印を解き、真実を見抜く～

さて、あなたは関係者から「重要プロジェクト計画書.docx」と「デジタル署名Xと関連情報」を受け取りました。これが本当に差出人本人から送られ、途中で改ざんされていないかを確認する「検証」のステップに進みましょう。

ステップ0: 受信物の確認と「埋め込まれた署名」へのアクセス

まず、元データである「重要プロジェクト計画書.docx」と、それに対応する「デジタル署名X」（または署名が埋め込まれたファイル）、そして多くの場合、送信者の「デジタル証明書」が含まれる関連情報が揃っていることを確認します。

特に、署名が元データに埋め込まれている場合（包含型署名）、その確認方法はファイル形式や使用するアプリケーションによって異なります。

• PDF署名 (PAdES) の場合:
  • Adobe Acrobat ReaderやFoxit Readerなどの多くのPDFビューアには、署名パネルや署名検証機能が組み込まれています。
  • ファイルを開くと、通常、画面上部や特定のパネルに「署名済みであり、すべての署名は有効です」といったメッセージ 署名有効 や、署名者の名前、署名日時などが表示されます。
  • この署名情報をクリックすると、さらに詳しい情報（証明書の詳細、信頼の連鎖、署名のプロパティなど）が表示され、手動で再検証することも可能です。検証結果は「有効」「無効」「不明（例: ルートCAが信頼されていない）」など、視覚的に分かりやすく示されます。
• S/MIMEメール署名 (CAdESなど) の場合:
  • Microsoft OutlookやMozilla Thunderbirdといった主要なメールクライアントは、S/MIME署名されたメールを受信すると、それを自動的に認識します。
  • メールのヘッダー部分や特定の位置に、署名が有効であることを示すアイコン（リボンマーク 署名済、チェックマーク、鍵マークなど）が表示されます。
  • このアイコンをクリック（またはマウスオーバー）することで、署名者の情報、証明書の発行者、有効期間などを確認できます。メールクライアントがバックグラウンドで証明書の有効性や信頼性を検証し、その結果をユーザーに伝えます。
• XML署名 (XAdESなど) や JWS の場合:

  これらは主にシステム間でデータ連携に使われるため、エンドユーザーが直接署名を目にする機会は少ないかもしれません。通常、受信側のシステムやアプリケーションが、専用のライブラリやモジュールを使ってプログラム的に署名を検証します。開発者は、これらのライブラリを使用して、署名されたXML文書やJWSトークンを解析し、署名値の検証、証明書の検証を行います。

このように、署名がデータにどのように組み込まれているかによって、ユーザーが署名情報にアクセスし、検証プロセスを開始する方法は異なりますが、多くの場合、対応するアプリケーションがその手助けをしてくれます。

ステップ1: 差出人の身元確認～公開鍵と証明書の信頼性チェック～

これが検証プロセスの非常に重要な入口です。

1. 証明書の入手・特定: 送信者のデジタル証明書を入手します（分離型署名の場合は署名ファイルに含まれていたり、包含型の場合は署名情報からアクセスできたりします）。
2. 証明書の有効性検証:
   • 失効確認: その証明書が失効していないか、CRL（証明書失効リスト）やOCSP（オンライン証明書ステータスプロトコル）を使って確認します。秘密鍵が漏洩した場合などに証明書は失効されるため、この確認は不可欠です。このチェックを怠ると、既に危険にさらされた鍵による署名を信用してしまうリスクがあります。
   • 有効期限の確認: 証明書の有効期限が切れていないか確認します。期限切れの証明書は信頼できません。
   • 発行者の信頼性確認（信頼の連鎖）: その証明書を発行した認証局（CA）が信頼できるか、上位のCAを辿っていき、最終的にあなたのコンピュータやシステムが信頼するルートCA（OSやブラウザに事前に組み込まれている、信頼の起点となるCA）に行き着くか（証明書チェーンの検証）を確認します。なぜルートCAを無条件に信頼できるかというと、OSやブラウザの提供元（Microsoft, Apple, Google, Mozillaなど）が、世界的に認められた厳格な基準（例: CA/Browser ForumのBaseline Requirements）に基づいて審査し、信頼できると判断したCAのみを「信頼できるルート証明書ストア」に組み込んでいるためです。このストアに含まれていないCAや、チェーンが途中で途切れる場合は信頼できません。
3. 公開鍵の取り出し: 証明書が信頼できると判断できたら、証明書の中から送信者の「公開鍵」を取り出します。この公開鍵が、署名の検証に使われます。

もし、このステップで証明書に問題が見つかれば（例: 失効している、信頼できない発行者、有効期限切れ）、その時点で署名の検証は失敗とし、元データも信頼できないと判断すべきです。

ステップ2: 使われた道具の確認～署名アルゴリズムとハッシュアルゴリズムの特定～

受信したデジタル署名や証明書の情報から、送信者が署名生成時にどのハッシュ関数（例: SHA-256）とどの公開鍵暗号アルゴリズム（例: RSA）を使用したかを確認します。この情報は通常、署名データ自体（例えばJWSのヘッダーやXML署名のSignatureMethod要素、AlgorithmIdentifierフィールドなど）や、証明書内の署名アルゴリズム識別子、公開鍵アルゴリズム識別子といった特定のフィールドに記述されています。検証ソフトウェアはこれらの情報を読み取ります。

ステップ3: こちらでも指紋採取～受信データからメッセージダイジェストを再計算～

受信した「重要プロジェクト計画書.docx」（元データ）の内容全体から、ステップ2で特定したのと同じハッシュ関数（例: SHA-256）を使って、メッセージダイジェストを計算します。
（例: 受信した重要プロジェクト計画書.docx → SHA-256関数 → メッセージダイジェストB）
これは、送信者が行ったであろう指紋採取と同じ作業を、受信者側でも行うということです。この計算は、署名に含まれる元データではなく、受信者が現に保有している元データに対して行われる点が重要です。

ステップ4: 署名の開封準備～デジタル署名データの取り出しとデコード～

受信した署名情報（分離型ファイルや包含型データの一部）から、純粋なデジタル署名値（暗号化されたハッシュ値）を取り出します。この署名値は、しばしばBase64などの形式でエンコードされてテキストとして表現されていることがあるため、その場合はデコードして元のバイナリ形式のバイト列に戻す必要があります。

ステップ5: 秘密のスタンプの照合～公開鍵による署名解読とダイジェスト取り出し～

ステップ4で取り出したデジタル署名値を、ステップ1で入手・検証した送信者の「公開鍵」と、ステップ2で特定した署名アルゴリズム（例: RSA）を使って復号（または検証処理。例えばRSA署名の場合は公開鍵で復号に近い操作を行いますが、DSAやECDSAの場合は少し異なる数学的検証プロセスとなります）します。
この処理が成功すれば、送信者が署名時に暗号化したはずのメッセージダイジェスト（ここでは仮にメッセージダイジェストCとします）が取り出せます。
（例: デジタル署名X + 送信者の公開鍵 (RSAアルゴリズム使用) → メッセージダイジェストC）
このメッセージダイジェストCは、送信者が元データから計算し、秘密鍵で封印した「元の指紋」であるはずです。

ステップ6: 二つの指紋を比較！～ダイジェストの一致確認～

いよいよクライマックスです。

• ステップ3で、受信した元データからあなたが計算したメッセージダイジェストB
• ステップ5で、デジタル署名を解読して取り出したメッセージダイジェストC

この2つのメッセージダイジェストが、完全に一致するかどうかを比較します。バイトレベルで一ビットの違いもなく同一である必要があります。

ステップ7: 審判の時～検証結果の判断～

• もし、メッセージダイジェストB と メッセージダイジェストC が完全に一致すれば…

  おめでとうございます！デジタル署名の検証は成功です！
  これは以下のことを意味します。

  • 真正性: 送信者の公開鍵で正しく署名を検証できたので、その署名は対応する秘密鍵の持ち主（＝信頼できる証明書で確認された送信者本人）によって作られた可能性が極めて高いと言えます。
  • 完全性: あなたが受け取ったデータから計算したダイジェストと、署名に含まれていたダイジェストが一致したので、データは署名された時から改ざんされていないことが確認できます。
  • 否認防止: これだけの証拠があれば、送信者は署名した事実を後から否定することが困難になります。
• もし、メッセージダイジェストB と メッセージダイジェストC が一致しなかったら…

  警告！デジタル署名の検証は失敗です！
  これは、以下のいずれか（または複数）の可能性を示唆しています。

  • データが改ざんされた: 送信されてからあなたの手元に届くまでの間に、元データの内容が誰かによって変更された（例: 転送中のネットワークエラーによるビット化け、中間者による悪意のある改ざん、ディスクエラーなど）。
  • 署名が無効である:
    • 送信者になりすました悪意の第三者が、偽の秘密鍵（あるいは別の人の秘密鍵）で署名した。
    • 署名プロセス自体に誤りがあった（例: 送信者が署名対象のデータを取り違えた、署名ソフトウェアにバグがあった）。
  • 使用した公開鍵が間違っている: 何らかの理由で、検証に使用した公開鍵が、実際に署名に使われた秘密鍵と対応するものではなかった。

この場合、受信したデータは信頼できないものとして扱うべきです。ただし、注意点として、デジタル署名の検証成功が必ずしも「ファイルの内容が100%安全である（例: ウイルスやマルウェアを含まない、情報が全て正しい）」ことを保証するわけではないということを覚えておきましょう。デジタル署名はあくまで「誰が署名し、署名後に改ざんされていないか」を技術的に保証するものであり、署名された内容自体の正当性、正確性、安全性（例えば、署名されたプログラムが悪意のある動作をしないかなど）は、別途評価する必要があります。

以上が、デジタル署名の生成と検証の詳細なプロセスです。一つ一つのステップは論理的で、それぞれの技術が重要な役割を果たしていることがお分かりいただけたかと思います。この厳密なプロセスがあるからこそ、私たちはデジタルの世界で情報を信頼し、安全なやり取りを行うことができるのです。

第4章: デジタル署名にも色々ある！種類と特徴を徹底解剖

一口にデジタル署名と言っても、その用途や対象データ、満たすべき要件によって様々な種類が存在します。ここでは代表的なものをいくつか紹介しましょう。

4.1. 基本的なデジタル署名

前章で説明したハッシュ関数と公開鍵暗号方式を用いた汎用的なデジタル署名です。電子文書への署名、ソフトウェアの配布など、幅広い場面で基本となります。

4.2. 電子署名（広義）と法的効力

「電子署名」という言葉は、技術的なデジタル署名だけでなく、より広義に手書き署名や押印に代わる電子的な行為全般を指すこともあります。

特に法的な文脈では、国の法律（日本では「電子署名法」、EUでは「eIDAS規則」など）によって、特定の要件を満たした電子署名に法的効力が認められています。

例えば、EUのeIDAS規則では、電子署名を以下の3つのレベルに分類しています。

• 標準電子署名 (SES: Standard Electronic Signature): 最も基本的なレベル。
• 高度電子署名 (AdES: Advanced Electronic Signature): 署名者と一意に関連付けられ、署名者を特定でき、署名者が単独で管理でき、署名後のデータ変更を検知できるもの。
• 適格電子署名 (QES: Qualified Electronic Signature): 高度電子署名の要件に加え、適格電子署名作成デバイス（QSCD）で作成され、かつ適格トラストサービスプロバイダ（QTSP）が発行した適格証明書に基づくもの。最も信頼性が高く、手書き署名と同等の法的効力を持つとされています。

これらのレベルは、主に認証局（CA）による本人確認の厳格さや、使用されるデバイスのセキュリティレベルによって決まります。

4.3. XML署名 (XML Signature / xmldsig) – Webサービスの縁の下の力持ち

ひとことで言うと？ XML文書のための専用デジタル署名！

定義: XML (Extensible Markup Language) 文書の一部または全体に署名するためのW3C標準仕様です。

特徴:

• XML文書の特定の要素だけに署名したり、複数の署名を一つの文書に含めたりと、非常に柔軟な署名が可能です。
• 署名情報自体もXML形式で記述され、元のXML文書に埋め込むことができます（Enveloped, Enveloping, Detachedの3形式）。
• Canonical XML (C14N) というXML正規化処理により、意味的に同じだが表現が異なるXML文書でも同じ署名検証結果を得られるようにします。

用途:

• Webサービス間のメッセージ交換プロトコルであるSOAPメッセージのセキュリティ。
• SAML (Security Assertion Markup Language) による認証・認可情報への署名。
• 電子請求書 (例: Peppol BIS Billing) や公的機関への電子申請データ。

豆知識: XML署名は非常に高機能ですが、その仕様は複雑で、正しく実装するのが難しいことでも知られています。

<Order>
  <ItemID>XYZ123</ItemID>
  <Quantity>10</Quantity>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- 署名情報がここに埋め込まれる -->
  </ds:Signature>
</Order>

4.4. JSON Web Signature (JWS) – モダンWebの軽量な認証サイン

ひとことで言うと？ JSONデータのためのコンパクトなデジタル署名！

定義: JSON (JavaScript Object Notation) データ構造に署名するためのIETF標準仕様 (RFC 7515) です。JOSE (JSON Object Signing and Encryption) ファミリー仕様の一つです。

特徴:

• XML署名に比べて非常にコンパクトで、URLに含めやすい形式（JWS Compact Serialization）も定義されています。
• 署名アルゴリズムや鍵IDなどの情報は、JSON形式の「JOSEヘッダー」で指定します。
• 署名対象のデータ（ペイロード）はJSONである必要はなく、任意のバイト列が可能です。

用途:

• OAuth 2.0 や OpenID Connect におけるIDトークンやアクセストークン（これらを総称してJWT: JSON Web Token と呼ぶことが多い）。
• モバイルアプリやWebアプリケーション間のAPI認証。
• 自己完結型の認証情報（Statelessな認証）。

構成 (JWS Compact Serialization): BASE64URL(UTF8(JWS Protected Header)) + . + BASE64URL(JWS Payload) + . + BASE64URL(JWS Signature) の3つの部分をピリオドで連結した文字列となります。

[Header (Base64URL)].[Payload (Base64URL)].[Signature (Base64URL)]

4.5. コードサイニング (Code Signing) – ソフトウェアの安全を守る番人

ひとことで言うと？ ソフトウェア専用の身元保証＆改ざん検知！

定義: ソフトウェア、アプリケーション、ドライバ、スクリプトなどの実行可能なコードに対して行われるデジタル署名です。

目的:

• 配布元の保証: ソフトウェアが信頼できる開発元や発行元から提供されたものであることを証明します。
• 改ざん検知: ソフトウェアが配布されてからユーザーの手に渡るまでの間に改ざんされていないことを保証します。
• 警告の回避: OS（Windows、macOSなど）やブラウザが、署名のない、あるいは信頼できない署名のあるソフトウェアを実行しようとする際に表示する警告メッセージを回避できます。

仕組み: 開発者は、認証局から発行された「コードサイニング証明書」を用いて、自身の秘密鍵でソフトウェアに署名します。ユーザーがソフトウェアをダウンロードまたは実行する際、OSやブラウザは、その署名を開発者の公開鍵（証明書に含まれる）で検証し、同時に証明書の有効性や信頼性を確認します。

例:

• WindowsのAuthenticode（ドライバ署名、実行ファイルの署名）。
• AppleのDeveloper ID（macOSアプリやiOSアプリの署名）。
• JavaのJAR署名。

4.6. タイムスタンプ付き署名 (Timestamping) – 「いつ」を証明する確かな証

ひとことで言うと？ 「その瞬間に、確かに存在し、改ざんされてない」を証明！

定義: ある文書やデータが特定の時刻に存在し、かつその時刻以降改ざんされていないことを証明するために、デジタル署名に信頼できる時刻情報を組み合わせたものです。

仕組み:

1. 署名対象の文書のハッシュ値を取得します。
2. このハッシュ値を、信頼できる第三者機関である時刻認証局 (TSA: Time Stamping Authority) に送ります。
3. TSAは、受け取ったハッシュ値と正確な時刻情報を結合し、TSA自身の秘密鍵でデジタル署名を行います。このTSAによる署名が付与されたものが「タイムスタンプトークン」です。
4. このタイムスタンプトークンを元の文書と一緒に保管することで、後日、その文書がその時刻に存在し、改ざんされていないことを客観的に証明できます。

用途:

• 電子契約の締結日時の証明。
• 知的財産（論文、設計図など）の先使用権や存在証明。
• 電子帳簿保存法など、法令で求められる電子データの長期保存における非改ざん証明。
• デジタル署名に使用された証明書の有効期間が切れた後でも、署名時点での有効性を証明（長期署名）。

4.7. 【発展編】未来を彩るかもしれない特殊な署名技術

ここでは、より専門的で特定のニーズに応えるための、少し変わったデジタル署名技術をいくつか紹介します。これらは特定の分野で非常に重要な役割を果たしています。

• ブラインド署名 (Blind Signature):

  概要: 署名者が署名する内容（メッセージ）を完全に知ることなく署名を行うことができる技術です。まるで、カーボン紙の入った封筒の上から署名するようなイメージ。

  特徴: 署名されたメッセージの検証は可能ですが、署名者はどのメッセージに署名したかを後から特定できません。これにより、署名される情報のプライバシーを保護しつつ、署名の正当性を保証できます。

  用途例: 電子投票システム（誰が誰に投票したかを秘匿しつつ、投票の正当性を保証）、プライバシーを重視するデジタル通貨。

• リング署名 (Ring Signature):

  概要: グループのメンバーのうちの誰かが署名したことは分かるが、具体的にどのメンバーが署名したのかは特定できない匿名性を持つ署名方式です。

  特徴: 署名者はグループの他のメンバーの公開鍵を使って、自身がそのグループの一員であることを証明しつつ、自分の身元を隠して署名できます。検証者は、署名がグループの誰かによって行われたことは確認できますが、個人は特定できません。

  用途例: 内部告発（組織内の誰かが情報をリークしたが、個人は保護される）、一部のプライバシー志向の仮想通貨（Moneroなど）。

• グループ署名 (Group Signature):

  概要: リング署名と似ていますが、こちらはグループの正当なメンバーがグループを代表して匿名で署名できる一方で、信頼できるグループ管理者（オープナー）は、必要に応じて署名者の身元を特定（オープン）できるという特徴があります。

  特徴: 条件付き匿名性。「通常は匿名だが、不正があった場合には追跡可能」というバランスが取られています。

  用途例: 企業内での文書承認プロセス（誰が承認したかは通常秘匿するが、問題発生時には特定可能）、有料コンテンツへの匿名アクセス。

• マルチシグネチャ (Multi-signature / Multisig):

  概要: 一つのトランザクションや文書に対して、複数の異なる署名者による署名が揃って初めて有効となる署名方式です。「M-of-N署名」とも呼ばれ、N人の署名権限者のうち、M人以上の署名が必要、といった設定が可能です（例: 2-of-3 なら3人中2人の署名が必要）。

  特徴: 単独の秘密鍵漏洩による不正リスクを低減し、セキュリティを向上させます。権限を分散させ、共同管理を可能にします。

  用途例: 仮想通貨の共同管理ウォレット（企業や組織での資金管理）、重要な契約や意思決定における複数承認プロセス。

• 集約署名 (Aggregate Signature):

  概要: 多数の異なるユーザーがそれぞれ異なるメッセージに対して行った署名を、一つの短い署名に集約できる技術です。

  特徴: 署名全体のデータサイズを大幅に削減でき、検証も効率的に行える可能性があります。

  用途例: ブロックチェーンにおけるブロックヘッダのサイズ削減（例: BLS署名）、セキュアなルーティングプロトコル。

これらの特殊な署名は、それぞれが特定の課題を解決するために考案されており、デジタル世界の信頼性とプライバシー保護の新たな可能性を切り拓いています。

第5章: どこで使われているの？デジタル署名の活躍する舞台

デジタル署名は、目に見えないところで私たちのオンライン活動を支えています。具体的にどのような場面で活躍しているのか、代表的な例を見てみましょう。

• SSL/TLS通信 (HTTPS): Webサイトの安全な接続（URLがhttps://で始まるもの）を実現するSSL/TLSプロトコルでは、Webサーバーが自身の身元を証明するために「サーバー証明書」を使用します。この証明書には、認証局によるデジタル署名が付与されており、ブラウザはこれを検証することで、接続先のサーバーが本物であり、通信内容が途中で盗聴・改ざんされるのを防ぎます。ブラウザのアドレスバーに表示される鍵マークは、この安全の証です。
  図: SSL/TLSでの署名の役割

  ユーザーPC ↔ (暗号化通信) ↔ Webサーバー
  Webサーバーは自身の「サーバー証明書」を提示。
  証明書にはCAのデジタル署名があり、ブラウザがこれを検証してサーバーの信頼性を確認。

• セキュアな電子メール (S/MIME, PGP): S/MIME (Secure/Multipurpose Internet Mail Extensions) や PGP (Pretty Good Privacy) といった技術を使うと、電子メールにデジタル署名を付与できます。これにより、受信者はメールの送信者が本当に本人であること（なりすましでないこと）や、メールの内容が途中で改ざんされていないことを確認できます。重要なビジネスメールや機密情報のやり取りで活用されます。
• DNSSEC (DNS Security Extensions): インターネットの住所録であるDNS (Domain Name System) の応答にデジタル署名を付与し、その応答の完全性とオリジン認証（正当なDNSサーバーからの応答であること）を保証する技術です。これにより、DNSキャッシュポイズニングといった攻撃を防ぎ、ユーザーが意図しない偽サイトに誘導されるリスクを低減します。
• ソフトウェア・OSアップデート: OS（Windows, macOS, Linuxなど）やアプリケーションのアップデートファイルには、開発元によるコードサイニングが施されています。これにより、ユーザーは安全なアップデートファイルを入手でき、マルウェアに感染するリスクを減らせます。
• API通信のセキュリティ: Webサービスやクラウドプラットフォームが提供するAPI (Application Programming Interface) の多くは、リクエストやレスポンスの信頼性を確保するためにデジタル署名を利用しています。例えば、Amazon Web Services (AWS) では、APIリクエストに「Signature Version 4」という署名プロセスを用いて認証を行っています。
• 電子契約・電子申請システム: 紙の契約書への押印の代わりに、電子ファイルに電子署名を行うことで、契約の法的有効性を担保するシステムが普及しています。国や地方自治体への各種申請手続きも電子化が進んでおり、そこでもデジタル署名（多くはマイナンバーカードに格納された公的個人認証サービスの電子証明書を利用）が活用されています。
• ブロックチェーン技術（仮想通貨など）: ビットコインなどの仮想通貨の取引（トランザクション）では、送金者が自身の秘密鍵でトランザクションにデジタル署名を行います。これにより、その送金指示が正当な所有者によって行われたことが検証され、不正な送金を防ぎます。ブロックチェーンの各ブロックにも、マイナー（採掘者）による署名や、前述の集約署名などが活用されることがあります。
• JSON Web Tokens (JWT): WebアプリケーションやAPIの認証・認可で広く使われるJWTは、JWS (JSON Web Signature) を用いて、トークンに含まれる情報（クレーム）が改ざんされていないことを保証します。

このように、デジタル署名は非常に広範な分野で、デジタル社会の信頼と安全を支える基盤技術として機能しているのです。

第6章: デジタル署名と公開鍵基盤（PKI）～信頼の連鎖を築く仕組み～

さて、これまで「送信者の公開鍵で検証する」と何度も説明してきましたが、ここで一つの疑問が浮かびます。「その公開鍵が、本当に送信者本人のものだと、どうやって信じればいいの？」

確かに、もし悪意のある第三者が偽の公開鍵を「これがAさんの公開鍵だよ」と偽って配布したら、私たちはそれを信じてしまい、偽の署名を本物だと誤認してしまうかもしれません。

この「公開鍵の信頼性」を担保する仕組みが「公開鍵基盤 (PKI: Public Key Infrastructure)」です。

PKIの中心的な役割を担うのが「認証局 (CA: Certificate Authority)」です。CAは、公開鍵とその持ち主が誰であるかを証明する「デジタル証明書（単に証明書とも呼ばれます）」を発行します。

6.1. デジタル証明書とは？

デジタル証明書（多くはX.509という標準形式）には、主に以下の情報が含まれています。

• 公開鍵: 証明書の持ち主の公開鍵。
• 所有者情報: 個人名、組織名、ドメイン名など。
• 発行者 (CA) の情報: この証明書を発行したCAの名前。
• 有効期間: この証明書が有効な期間。
• CAのデジタル署名: CAが上記の情報全体に対して、自身の秘密鍵で署名したもの。

この「CAのデジタル署名」が非常に重要です。これにより、証明書の内容がCAによって保証され、改ざんされていないことが確認できます。

6.2. 信頼の連鎖 (Chain of Trust)

では、そのCA自体はどうやって信頼できるのでしょうか？ ここで「信頼の連鎖」という考え方が登場します。

1. ルートCA (Root CA): 最上位に位置する認証局。ルートCAの証明書（ルート証明書）は、OSやブラウザに最初から組み込まれており、これらは「自己署名証明書（自分自身で署名した証明書）」ですが、非常に厳格な審査と運用基準のもとに信頼されています。これが信頼の起点（トラストアンカー）となります。
2. 中間CA (Intermediate CA): ルートCAから証明書を発行してもらったCA。中間CAは、さらに他の中間CAやエンドユーザー（Webサーバー、個人など）に対して証明書を発行できます。
3. エンドエンティティ証明書 (End-entity Certificate): 最終的な利用者（Webサーバーや個人など）に発行される証明書。

私たちがWebサイトのサーバー証明書などを検証する際、その証明書を発行したCAの証明書を辿り、さらにそのCAの証明書を発行した上位のCAの証明書を辿り…最終的にOSやブラウザが信頼するルートCAの証明書に行き着けば、「この証明書は信頼できる」と判断します。この一連の証明書の繋がりが「信頼の連鎖（証明書チェーン、証明書パスとも呼ばれます）」です。

6.3. 証明書の失効

証明書は、有効期間内であっても、秘密鍵が漏洩した場合や情報が変更された場合などに失効されることがあります。失効した証明書を誤って信頼しないように、CAは証明書失効リスト (CRL: Certificate Revocation List) を定期的に発行したり、OCSP (Online Certificate Status Protocol) というプロトコルで証明書の有効性をリアルタイムに問い合わせられるようにしたりしています。

PKIという社会的なインフラがあって初めて、私たちは見ず知らずの相手の公開鍵でも、一定の信頼のもとにデジタル署名を検証することができるのです。

第7章: デジタル署名の課題と未来の展望

デジタル署名は非常に強力な技術ですが、いくつかの課題も抱えています。また、技術の進歩とともに新たな脅威も現れており、それに対応するための研究開発も進められています。

7.1. 鍵管理の複雑さとリスク

デジタル署名の安全性は、秘密鍵が厳重に管理されていることが大前提です。

• 秘密鍵の生成・保管: 安全な方法で生成し、他人に漏れないように厳重に保管する必要があります。ハードウェアセキュリティモジュール (HSM) などの専用デバイスが使われることもあります。
• 秘密鍵のバックアップと復元: 紛失や破損に備えたバックアップも重要ですが、バックアップ自体のセキュリティも確保しなければなりません。
• 秘密鍵の更新: 定期的な鍵の更新（キーローテーション）が推奨されます。
• 秘密鍵の失効: 秘密鍵が漏洩した疑いがある場合は、速やかに関連する証明書を失効させる手続きが必要です。

これらの鍵管理は、個人にとっても組織にとっても負担となる場合があり、管理を怠ると重大なセキュリティインシデントに繋がる可能性があります。

7.2. 量子コンピュータによる既存暗号への脅威

現在主流の公開鍵暗号方式（RSAやECDSAなど）は、特定の数学的問題（素因数分解や離散対数問題）の困難性に基づいて安全性が保たれています。しかし、大規模で実用的な量子コンピュータが実現すると、これらの問題が効率的に解かれてしまい、既存のデジタル署名が無力化される危険性が指摘されています（Shorのアルゴリズム）。

この脅威に対応するため、量子コンピュータでも解読が困難とされる新しい暗号技術「耐量子計算機暗号 (PQC: Post-Quantum Cryptography)」の研究開発が世界中で進められています。PQCには、格子ベース暗号、ハッシュベース署名、符号ベース暗号、多変数公開鍵暗号、同種写像ベース暗号など、様々なアプローチがあります。NIST（アメリカ国立標準技術研究所）などがPQCの標準化を進めており、将来的にはこれらの新しい署名方式への移行が必要になると考えられています。

専門家の間では、PQCへの移行は単にアルゴリズムを置き換えるだけでなく、鍵長の変化、処理性能への影響、既存システムとの互換性など、多くの課題を伴う大規模なプロジェクトとなると認識されており、早期からの準備と検証が不可欠であるとされています。

7.3. ユーザビリティの向上

デジタル署名やPKIの仕組みは複雑なため、一般のユーザーにとっては理解や操作が難しい場合があります。署名のプロセスがユーザーに意識されない、よりシームレスで使いやすいインターフェースや仕組みの開発が求められています。「使っていることを感じさせないセキュリティ」が理想です。

7.4. 標準化と相互運用性の継続的な確保

新しい署名技術や応用プロトコルが登場するたびに、それらが異なるシステムやベンダー間で問題なく動作する（相互運用性がある）ように、国際的な標準化活動が重要になります。IETFやW3C、ISOなどの標準化団体がその役割を担っています。

7.5. 法的・制度的整備

デジタル署名の法的効力や、国境を越えた利用における取り扱いなど、技術の進展に合わせて法制度や社会的なルールも整備していく必要があります。特に国際的な取引においては、各国の法制度の違いが課題となることもあります。

デジタル署名は、これらの課題を克服し、進化を続けることで、今後も私たちのデジタル社会の信頼を支える重要な役割を担っていくことでしょう。