どうもどうも、えもんだ社長です (*ﾟ▽ﾟ)ﾉ
今回は、前回の記事に続いて、PKIで使われるデジタル証明書とデジタル証明書と認証局（CA）、さらには実際のSSL/TLS通信について解説します。
【当シリーズ】
PKIの学習につまづく典型的なパターンに、
全体像を把握していない状態で、次々と新しい用語・モノ・機能を覚えようとする。
があると思います。
簡単なことから順番に覚えていけば、そこまで難しい道のりではありません。
各章を順番に読んで理解して行きましょう。
目次
暗号化で対応できない問題
まずは前回用いたこちらの図をご覧ください。
この共通鍵と公開鍵・秘密鍵を用いることで通信は暗号化され、第三者に盗み見されても内容が理解できない状態に出来ます。
しかし、暗号化では防げない問題があります。それは、
- 文書が改ざんされていないか否か
- 通信している相手は本当に希望する相手か否か
です。
それらを解決するのが今回解説する
- デジタル署名
- デジタル証明書
- 認証局（Certification Authority, CA）
です。
文章改ざんを防ぐ（デジタル署名）
文書の改ざんを防ぐ仕組みは、デジタル署名です。
デジタル署名を説明するために、まずはハッシュ値の説明をします。
ハッシュ値
ハッシュ値とは、
ハッシュ関数にデータを入力して出力されるある固定長（一定の長さ）のデータ
を指します。
図にするとこんな感じです。
特徴は、
- データがどんなに大きさでもハッシュ値の大きさは一定。（256ビットなど）
- 計算方法は決まっているので、同じデータを投入すると必ず同じハッシュ値が出力される。
- 元のデータを少しでも改ざんすると、全く違うハッシュ値が出力される。
です。
このハッシュ値は十分な数（※）がありますので、重複することはまずありえません。なので、このハッシュ値がそのデータ固有の署名になるわけです。
※現在、ハッシュ値の主流は256ビット固定長です（後述）。これは10進数では77桁の数字です（ちなみに1億は9桁で、1兆は13桁です）。あるデータのハッシュ値は77桁の中から1つの値を取るので、重複することはまずありません。
ハッシュ関数には、
- MD5
- SHA-1
- SHA-2
などがあります。
MD5とSHA-１は、同じハッシュ値を持つ別データを意図的に生み出すことに成功しているので、データの改ざんができる可能性があります。よって、現在ではSHA-2が主流です。
MD5のハッシュ値は128ビットで、SHA-1のハッシュ値は160ビットです。
SHA-2のハッシュ値は、224ビット、256ビット、384ビット、512ビットから選ぶことができます。256ビットが主に使用されており、「SHA-256」と記載されます。
これは「SHA-2で256ビットのハッシュ値を出力」という意味です。（ややこしい・・・）
デジタル署名
デジタル署名とは、
送信データのハッシュ値を秘密鍵で暗号化したもの
です。
送信するデータからハッシュ値を生成し、そのハッシュ値を公開鍵暗号方式でやり取りすることにより、データが改ざんされていないことを保証します。
- 送信者が公開鍵と秘密鍵を作成。
- 送信者が受信者に公開鍵を送付。
- 送信者が送信データからハッシュ値を作成。
- 送信者が「3.」で作成したハッシュ値を「1.」で作成した秘密鍵で暗号化（デジタル署名作成）
- 送信者が送信データとデジタル署名を受信者に送付。
- 受信者が受領したデジタル署名を「2.」で受領した公開鍵で復号。
- 受信者が受領したデータからハッシュ値を作成し、受領したデジタル署名を復号したハッシュ値と比較。一致すれば文章が改ざんされていないことを確認できる。
送信者が送ったデータから作成したハッシュ値と、（送信者しか暗号化できない）デジタル署名を復号したハッシュ値を突き合わせることにより、データが通信の途中で改ざんされていないことが確認できます。
SSL/TLSでは、（共通鍵を）公開鍵で暗号化し秘密鍵で復号しています。
いずれにしろ、数字の処理で非対称に暗号化・復号ができるという原則は変わりません。考え方で混乱してしまったら、今一度前回の記事を参照してください。
通信相手を確認する（デジタル証明書、認証局）
デジタル署名により、データが改ざんされていないことは確認できました。
しかし、そもそもの通信相手が誰かに成りすました悪者であれば、（データが改ざんされていなくても）ガセネタを掴まされることになります。
その通信相手を確認する仕組みが、デジタル証明書と認証局（CA）です。
デジタル証明書
デジタル証明書とは、
公開鍵と公開鍵作成者の情報などが記載された電子データ
であり、（通常は）公開鍵作成者とは異なる信頼できる第三者が発行します。
デジタル証明書の書式（格納されている情報）は、ITU-Tという国際機関のX.509という規格で定められており、
- 公開鍵
- 公開鍵の主体者（※1）の情報
- 証明書の発行者の情報
- 証明書の有効期限
- デジタル署名（※2）
などで構成されています。
（※1）X.509では、公開鍵を作成した組織（対になる秘密鍵を持っている、証明される組織）を「主体者」と呼びます。
（※2）このデジタル証明書からハッシュ値を作成し、「発行者の」秘密鍵で暗号化したものです。
認証局（Certificate Authority, CA）
デジタル証明書により、公開鍵作成者の身元は保証されました。
しかし、「誰による保証か？」という点によって、保証の信頼度が変わってきます。
人にお金を貸すときに、詐欺師によって「信頼できる人」と保証されているか、ちゃんとした金融機関や日本政府などによって「信頼できる人」と保証されているかで、借用書の価値は大きく異なります。
同様に、PKIで使うデジタル証明書も、ちゃんとした組織に保証してもらわないと、善良な通信相手と通信しているかの確信が持てません。
そのため、デジタル証明書は厳正な審査のうえで適正な機関に発行してもらう必要があります。その適正な組織が認証局（CA）です。
※前項で解説したデジタル証明書に記載されいている情報の中の「証明書の発行者の情報」の『発行者』が認証局です。
自身を「正規な通信先」であると保証してもらいたい人（HTTPSで通信を受けるWebサーバを運営する企業や官公庁など）は、この認証局に必要な情報を提供し、（通常はお金を払って）デジタル証明書を発行してもらいます。
認証局とWebサーバ運営者とのやり取りは以下の通りです。
- Webサーバ運営者は認証局にデジタル証明書の発行を申請。申請内容には、証明してほしい公開鍵の他、法人名や住所なども含まれ得る。
- 認証局は申請内容を審査
- 審査に合格したら、認証局はデジタル証明書を発行する。デジタル証明書には、その発行したデジタル証明書のハッシュ値を「認証局の秘密鍵で」暗号化したデジタル署名を付ける。
- Webサーバ運営者は、発行されたデジタル証明書をサーバに格納し、ユーザからのSSL/TLS通信などで利用する。
実際の証明書発行の手順は、Cybertrust社の証明書申し込みページをご覧いただくといいかと思います。
当然ですが、架空の住所や事業実態のない会社の情報を入力した場合には、審査が通らずに証明書は発行されません。
この審査により、証明書の安全性と通信相手の正当性が担保されます。
認証局のデジタル証明書
前項の説明で「認証局の秘密鍵」「認証局のデジタル署名」というキーワードが出てきました。
ということは、当然「認証局の公開鍵」で復号するわけですが、認証局の公開鍵をインターネット上でやり取りすると、再びなりすまし問題への対処が必要になります。
実はこれにも対策がしてあります。
認証局のデジタル証明書（公開鍵が格納されている）は、通常はブラウザにインストールされています。
ここでもちゃんとした審査がなされないと、PKIの安全性は担保できません。それぞれのブラウザを開発している企業は、認証局のデジタル証明書が信頼できるかどうかを確認したうえで、ブラウザにインストールしています。
ルート認証局であるGMO社のホームページには
GMOグローバルサインでは信頼されるルート認証局であり続けるために、WebTrust for CAという厳正な監査基準に基づく審査を受けています。WebTrust for CAとはインターネット事業者が国際的な電子商取引保証規準に基づいた電子商取引を行なっているかを審査するサービスです。
審査に合格したインターネット事業者には審査報告書とWebTrustシールが付与され、消費者はWebTrustシールをクリックすることで審査報告書を確認することができます。
という記述があります。このような監査を受けた認証局が発行したデジタル証明書なので、信頼でき、ブラウザにプリインストールできるのです。
SSL/TLS通信の流れ
それでは、以上を踏まえて（PKIのインターネット上の実装である）SSL/TLS通信がどのように行われるかを見てみましょう。
- 端末がWebサーバに、HTTPSアクセス。
- Webサーバが端末に、（認証局に発行された）自サーバのデジタル証明書を送付。
- 端末が受領したデジタル証明書に格納されているデジタル署名を、プリインストールされた[認証局の]公開鍵で復号。（※）
自身で作成したデジタル証明書のハッシュ値と比較し、一致した場合はデジタル証明書が正規のモノであると判断する。 - 端末がこのHTTPSセッションで利用する共通鍵を生成。
- 端末が（「3.」で検証済みの）デジタル証明書に格納されている[Webサーバの]公開鍵で、生成した共通鍵を暗号化。
- 端末が暗号化した共通鍵をWebサーバに送付。
- Webサーバが受信した暗号文を[Webサーバの]秘密鍵で復号し共通鍵を取得。
- 以降は双方が共通鍵で暗号化したデータを送受信。
（※）認証局のデジタル証明書がプリインストールされていない場合には、新規にインターネット上からダウンロードしインストールすることになります。通常、そういった場合にはブラウザに「このデジタル証明書を信用しますか？」という注意が表示されます。
まとめと感想
なんとなくで手を出した公開鍵暗号方式ですが、あれよあれよという間に結構な分量になってしまいました (´・ω・｀)
結構いろいろなサイトを見たんですが、正直どのサイトでもスッキリわかる説明はされていませんでした。
中途半端だったりマニアックすぎたり、大事なところが明確に描かれていなかったり、1997年の記事（！）にヒットしたこともありました。「SSLを利用しているドメインは現在1000くらい」なんて記述におったまげました ((( ；ﾟДﾟ)))
暗号については、（現場でもしばしば感じていたのですが）なんだかんだでみんながなんとなくしかわかっていない知識だと感じましたｗ
・・・何を隠そう、わたくし自身も ・・・(/ω＼)
しかし、こういう機会を経てこそ自信が成長するものです。
この記事を書けて良かったです (#^^#)
このブログで、少しでもIT業界で困っている人の助けになれればと思っています。
それでは (*ﾟ▽ﾟ)ﾉ
=-=-=-=-=-=-=-=-=-=
お読みのあなたが現役エンジニアなら、是非とも下のサムネをクリックしてアンケートにご協力をお願いします m(_ _)m
=-=-=-=-=-=-=-=-=-=