安全な通信を考える(電子証明書/PKI)

「安全な通信を考える(ハッシュ関数/電子署名)」の続きです。電子署名を使えば送信者の検証ができますが、それには相手の「本物の公開鍵」が自分の手元にあることが前提でした。

相手の公開鍵が本物かどうか?

これを解決するには、信頼できる第三者に証明してもらうことになります。その仕組みを書いてみます。

■電子証明書

まず、信頼できる第三者とは「公的な機関や組織」です。認証局(CA)と呼ばれます。認証局になるためには高い信頼性を確保するための運用や管理方法など厳しい審査をクリアする必要があります(※どのような審査があるのかは僕もわかりません)。この認証局(CA)が「この公開鍵はあなたのものです」と証明してくれるのですから、みんなもそれを信頼してくれることになります。

[広告]

前回の例で、BさんがAさんに公開鍵を渡す場合、まずBさんはCAに「公開鍵が自分のものである」と証明してもらう申請を行います。CAではBさんの申請の審査を行い、問題ないようであれば電子証明書の発行を行います(図1)。

図1

この電子証明書ですが、その中身が重要です。電子証明書には以下のものが含まれています。

・公開鍵の証明書
・申請した公開鍵
・CAの電子署名

この中の「公開鍵の証明書」には、発行した認証局の名称、電子証明書の有効期間、証明書のシリアル番号(識別番号)と言った情報が記載されています。電子証明書はフォーマットが決まっていて、そのフォーマットにあわせた情報が記載されます(「X.509」といったフォーマットがあります)。

Bさんは、この電子証明書をAさんに送ることにより「この公開鍵はCAが認めた私のものです」とAさんに納得してもらうことができます。

とはいえ、、、Aさんは「この電子証明書は本当にCAが認めたものなのか?」という検証を行う必要があります。この検証を行う方法ですが、電子証明書に含まれる「CAの電子署名」を検証することでCAが発行したものなのかどうかを確認することができます。それにはCAの公開鍵が必要です(図2)。
※電子署名の検証については前回の「安全な通信を考える(ハッシュ関数/電子署名)」を参照してください。

図2

CAの公開鍵ですが、実は、AさんはすでにCAの公開鍵を持っています。信頼できる第三者であることから、OSやWEBブラウザーにあらかじめインストールされているのです。

改めて、AさんとBさんの通信を考えます。Bさんには、「本文」と「Bさんの電子署名」と「電子証明書」をあわせて送ってもらいます(図3)。

図3

Bさん(送信者)が行う作業、および、Aさん(受信者)が行う作業をそれぞれ記載してみます。

【Bさんの作業】

  1. 送りたい情報(本文)を作成する。※この本文はダミーで漏洩してもよいもの。
  2. 本文をハッシュ関数でハッシュ値にする(ダイジェストの作成)。
  3. 作成したダイジェストを秘密鍵で暗号化する。※この暗号化されたダイジェストが電子署名と呼ばれるものです。
  4. 「本文」と「Bさんの電子署名」、それに「電子証明書」を添付してAさんに送信する。

【Aさんの作業】

  1. Bさんから送られた情報を受け取る。
  2. 電子証明書からCAの電子署名を取り出し、インストールされているCAの公開鍵で復号する。
  3. 電子証明書から公開鍵の証明書を取り出し、ハッシュ化する。
  4. 2と3のハッシュ値を比較し、一致すれば電子証明書に含まれる公開鍵はBさんのものであるということが言える。
  5. 次に、そのBさんの公開鍵で「Bさんの電子署名」を復号する。
  6. 「本文」をハッシュ化する。
  7. 5と6のハッシュ値を比較し、一致すれば送られてきた情報は本当のBさんからのものであり、送信者が間違いないと言える。
  8. 受領したBさんの公開鍵で、本当に送りたい情報を暗号化してAさんからBさんに送る。

これでやっと、本当に安全な通信ができるようになったと言えます。

■公開鍵基盤(PKI)

この一連の仕組みは公開鍵基盤(Public Key Infrastructure)と呼ばれるもので、いまのインターネットが当たり前になっている現状では必要不可欠なものとなっています。信頼できる第三者を立てることで成り立っており、そこが「基盤」と言われるところなのでしょう。

IPAが実施する情報処理安全確保支援士やネットワークスペシャリスト試験でもセキュリティ分野に関わる問題がよく出ていて、電子証明書の理解ができていないと問題が解けないので、このブログの記載が理解の手助けとなれば幸いです。

安全な通信を考える(ハッシュ関数/電子署名)

「安全な通信を考える(共通鍵暗号/公開鍵暗号)」の続きです。公開鍵方式では相手(送信者)の検証ができませんでした。「なりすまし」をされたらわかりません。

でもちゃんと送信者を検証できる仕組みがあります。それにはまず「ハッシュ関数」を知る必要があります。

■ハッシュ関数

関数というと理系でない人は引いてしまいそうですが、そんなに難しくはありません(僕も特徴しか押さえていません)。ハッシュ関数は以下の特徴があります。

  • 任意の長さのデータから、固定長のデータ(ビット列)を生成する。※この固定長のデータのことをバッシュ値、もしくは、メッセージダイジェストと呼びます。
  • 生成されたハッシュ値からもとのデータの復元はできない(もとに戻せない)。
  • もとのデータがわずか1ビットでも異なれば、生成されるハッシュ値も異なる。
  • 同じハッシュ値をもつ異なるデータを作成することは、ほぼ不可能。

ハッシュ関数にはMD5や、SHA-1、SHA-2といったものがあります。

[広告]

話をもとに戻します。このハッシュ関数と公開鍵暗号を組み合わせることで「なりすまし」を防ぐことができるようになります。

前回は、こうでした。

  1. Aさんが自分の公開鍵をBさんに渡し、BさんがAさんの公開鍵で暗号化してAさんに送る。

これを、変えます。

  1. まず、Bさんには自分の秘密鍵/公開鍵のペアを作成してもらい、AさんがBさんの公開鍵を受け取る。
  2. Bさんには、Bさんの秘密鍵で暗号化をしてもらいそれをAさんに送ってもらう。
  3. Aさんは、Bさんから送られた情報をBさんの公開鍵で復号する。

絵にすると以下の図1です。

図1

ん?
図1の上のほうは相手がBさんかわからないけれども、Aさんの公開鍵で暗号化しているため通信内容は秘匿化されていました。でも下のほうはBさんの秘密鍵で暗号化してるのでBさんの公開鍵をもっている人(いっぱいいるだろ?)なら誰でも復号できてしまうけど、いいの?

図1の下の場合、通信内容は誰にでも知られてしまうのですが、ここにはBさんでしかできないことが隠されています。

AさんはBさんから送られた来た情報をBさんの公開鍵で復号しますが「復号できたということは、相手は秘密鍵を持っているBさんしかありえない」ということです。公開鍵はいろんな人がもっていて構いませんが、秘密鍵を持っているのは鍵を生成したBさんだけだからです

■電子署名

この仕組みを利用したものが電子署名(デジタル署名)です。電子署名は以下のようなやりとりになります。Aさんが情報の受信者、Bさんが送信者となります。

【Bさんの作業】

  1. 送りたい情報(本文)を作成する。
  2. 本文をハッシュ関数でハッシュ値にする(ダイジェストの作成)。
  3. 作成したダイジェストを秘密鍵で暗号化する。※この暗号化されたダイジェストが電子署名と呼ばれるものです。
  4. Aさんに本文と電子署名を送信する。

【Aさんの作業】

  1. Bさんから本文と電子署名を受け取る。
  2. 受け取った本文をハッシュ関数でハッシュ値にする(ダイジェストの作成)。
  3. 受け取った電子署名をBさんの公開鍵で復号する。※復号すると、Bさんが作成したダイジェストになる。
  4. 2と3のダイジェストを比較する。

【Aさんの作業】の「4」において、ダイジェストが一致すれば送信者はBさんに間違いないことになります。また、本文が改ざんされていない証拠にもなります。電子署名の持つ機能として、送信者の検証と改ざんの検知ができるのです。

これを絵にしたものが図2になります。

図2

ここで注意したのは、本文はあくまでも電子署名を検証するために必要なもので隠したい情報ではないということです。安全に通信したい内容は送信者がBさんだと検証できた上で、Aさんの公開鍵を渡してはじめることになります。

電子署名を使うことで相手がBさんであることの確認も取れ、安全な通信ができるようになりました・・ん?

そもそも、、Bさんを装った誰かが自分の秘密鍵/公開鍵を作成し、自分をBさんと語って自分の公開鍵をAさんに渡していたら・・。話がもとに戻ったような気がしてしまうのだけれど、今までの話は大事な前提があったのです。

【前提】
Bさん(つまりは通信相手)の「本物の公開鍵」が自分の手元にあること。

これが成り立たないと、電子署名だけではまったく意味がありません。
この問題については、「安全な通信を考える(電子証明書/PKI)」に続く