まくろぐ
更新:
作成:

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

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

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

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

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

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

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

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

電子証明書とは?

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

電子証明書 = 公開鍵 + 本物の公開鍵であることを示す署名

電子証明書の発行(公開鍵への署名)

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

☝️ CA の署名は本物か

電子証明書は、そこに含まれている公開鍵が正しいものかどうかを、CA 署名で確認できるようにしたものですが、その CA 署名自体が本物なのかという問題があります。 CA 署名の真正性も電子証明書によって確かめます。 Windows や macOS などの OS には、有名どころの CA の電子証明書(ルート CA 証明書)があらかじめインストールされており、サーバー証明書内の CA 署名が本物であるかを調べられるようになっています(参考: macOS で利用できるルート証明書の一覧)。

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

多くの場合、Web サーバーの証明書はルート CA 以外の中間 CA から発行されたものであり、証明書内の署名のチェックは、下の図のように数珠繋ぎに実行されることになります。 最終的に、ルート CA による署名が本物であると判断されれば、Web サーバーの証明書も本物であるとみなされます。

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

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

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

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

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

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

sequenceDiagram actor admin as サーバー管理者 participant ca as CA(認証局) admin ->> ca: CSR(証明書署名要求) ca -->> admin: 署名された電子証明書 (.cer)
  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 サーバーから直接公開鍵を取得します。

sequenceDiagram # エイリアス participant client as クライアント participant server as サーバー participant ca as CA(認証局) # TSL ハンドシェイク client ->> server: 1. TSL/SSL 通信要求 server -->> client: 2. 電子証明書を返す alt CA の公開鍵がインストールされていない場合 client ->> ca: 3. CA の公開鍵を要求 ca -->> client: 4. CA の公開鍵 end client ->> client: 5. CA の公開鍵で電子証明書を検証し、
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 サーバーに暗号化して送ることで、その後のデータ通信が共通鍵暗号化方式で暗号化して行えるようになります。

関連記事

まくろぐ
サイトマップまくへのメッセージ