電子署名と電子証明書の基礎

電子署名と電子証明書の話がごっちゃになってることが多いので、まとめておきます。

電子署名（デジタル署名）(digital signature)

「電子署名」とは、送信するデータに付加されるもので、そのデータの作成者やデータが改ざんされていないことをを確認するためのものです。 別の言い方をすると、受け取ったデータが第三者によって作られた 偽物でないことを確認するための印 です。

以下のような手順で、データが偽物でないかを確認します。

• データ送信側の「電子署名の作成」手順
  1. 送信するデータのメッセージダイジェスト（ハッシュ値）を求める。
  2. メッセージダイジェストを非公開鍵 (private key) で暗号化し、「電子署名」とする。
  3. データ送信時には、データと「電子署名」を一緒に送る。
• データ受信側の「電子署名の確認」手順
  1. 受信したデータのメッセージダイジェスト（ハッシュ値）を求める。
  2. 受信した「電子署名」を「送信者の公開鍵」で復号化し、メッセージダイジェストに戻す。
  3. 1 と 2 のメッセージダイジェストが等しければ、本人が作成したデータだと分かる。

上記の手順からも分かるように、一般的に「電子署名」の仕組みには、公開鍵暗号方式 が用いられます。 問題は、「送信者の公開鍵」の交換方法が定義されていないことです。 偽物の公開鍵が使われると、なりすましができてしまいます。 データの受信者は、何らかの方法で「本物の送信者の公開鍵」を取得しなければいけません。

もちろん、公開鍵を手渡しで渡せれば安全ですが、不特定多数のサーバーとの通信のたびにそんなことはやっていられません。 そこで、公開鍵が本物であるかを証明するための、「電子証明書」が必要になってきます。 電子証明書の仕組みを使うと、通信相手の Web サーバーから、直接そのサーバーの公開鍵を取得できるようになります。

電子証明書（デジタル証明書) (digital certificate)

電子証明書とは？

公開鍵が偽物であると、公開鍵暗号方式は意味をなさなくなるため、公開鍵の正当性を証明することが重要になってきます。 電子証明書は、ある公開鍵が本物であることを証明する ためのものです。 大まかに書いてしまうと、公開鍵を次のようにパッケージングしたものです。

電子証明書の発行（公開鍵への署名）

電子証明書は、公開鍵が本物であることを示すためのものですが、その電子証明書自体が本物であることを示すために、末尾に電子署名 が付加されます。 その署名は、公開鍵を作成したユーザが行うこともあるし（オレオレ証明書）、信頼のおける第三者が行うこともあります。 通常は、信頼のおける第三者機関である 認証局 (CA: Certificate Authority) が電子証明書への署名を行い、電子証明書の発行を行います。

サーバーの証明書 <---(その証明書の署名は本物だよ)--- ルート CA 証明書

サーバーの証明書
    ↑ （本物だよ）
    └─ 中間 CA 証明書
         ↑ （本物だよ）
         └─ 中間 CA 証明書
             ↑ （本物だよ）
             └─ ルート CA 証明書

電子証明書 (X.509) の構成

電子証明書は、一般的には、ITU-T X.509 の標準フォーマット（拡張子 .cer）で作成されます。 X.509 で作成された電子証明書ファイル (.cer) には、公開鍵そのものに加え、公開鍵の作成者（証明書の申請者）の情報、有効期限などが含まれています。

1. Web サーバーの公開鍵
2. 作成者情報
3. 有効期限など
4. 上記が本物だと示す CA の署名

前半に Web サーバーの公開鍵や申請者の情報、末尾に CA の電子署名が格納されています。

認証局による電子証明書の発行の流れ

1. サーバーの管理者（公開鍵の作成者）が、身元情報と公開鍵を CA（認証局）へ提出します。
   • このとき使われる証明書署名要求ファイルのことを CSR (Certificate Signing Request) と呼びます。CSR には、サーバー情報（ドメイン名など）など、いろいろな情報が含まれています。
2. CA は CSR の情報を厳密に審査し、電子証明書（X.509 形式）を発行します。
   • このとき、電子証明書は、CA の非公開鍵で電子署名されます。ここでは、認証局が電子証明書（X.509 の .cer ファイル）だけを発行する例を示していますが、秘密鍵と電子証明書の両方を認証局が作成、発行することもあります。

TSL/SSL 通信を行うときに相手の Web サーバーの公開鍵を取得するまでの流れ

TSL/SSL 通信を行うには、通信相手の Web サーバーの公開鍵を取得する必要があります。 Web サーバーの公開鍵は、CA から発行された電子証明書の形で Web サーバー自身が保持しているので、クライアントは通信相手となる Web サーバーから直接公開鍵を取得します。

1. クライアントは、Web サーバーに TSL/SSL 通信の開始要求を送ります（TSL ハンドシェイクの開始）
2. Web サーバーは、自身の電子証明書を返します。
3. クライアントは、その電子証明書を見て発行元の CA（認証局）を調べ、CA 自身の公開鍵を要求します。
4. CA は、クライアントに自身の公開鍵（電子証明書）を返します。
5. クライアントは、CA の公開鍵を使って Web サーバーの電子証明書が本物かどうかを調べ、中に入っている Web サーバーの公開鍵を取り出します。Web サーバーの公開鍵があれば、Web サーバーと暗号化通信を行えます。

上記の流れでは、3、4 で CA に公開鍵を取得しに行っていますが、有名な CA の公開鍵は、あらかじめブラウザに「信頼されたルート証明機関(CA)の公開鍵」としてインストールされているので、CA へのアクセスは省略されます。

上記のようにして、クライアントが、Web サーバーの公開鍵を取得できたら、クライアント側で共通鍵を作成し、それを Web サーバーに暗号化して送ることで、その後のデータ通信が共通鍵暗号化方式で暗号化して行えるようになります。

関連記事

• 暗号技術まとめ
• CPU のアーキテクチャ名と CPU 名の対応表
• IETF によるプロトコル標準化の流れ
• HMAC-SHA256 コードを生成する