目的・概要
昨今、我々がInternet上のサービスを利用するにあたり、SSL/TLSは無くてはならない存在となっています。
なんとなく、おぼろげに理解しているSSL/TLSについて、仕組みをきちんと理解するに足る内容を整理し、
ポイントを押さえた説明を行うことを目的とします。
以下のような読者、具体的にはITエンジニア新人～2,3年目の方を対象としています。
何となくアプリ開発・インフラ開発は出来るようになったけれども、各要素技術の詳細について理解が曖昧という人を想定しています。
- SSL/TLSを何となく理解しているが、これを利用する通信・その他技術について、順を追って説明することが出来ない。
- OpenSSLのコマンドを打って何となくオレオレ証明書が作れたが、仕組みをよく理解していない。
- 生成・削除・編集が容易な電子データなのに、何故、偽造が出来ない／改ざんが出来ないのか、ちゃんと説明することが出来ない。
この投稿は何ではないか
この投稿は以下を目的としていません。
- 技術的に重要な要素を曖昧に、たとえ話で説明し、何となく分かった気にさせる
- OpenSSLのコマンドを紹介して、手っ取り早くCSR作成・秘密鍵作成する、SSLサーバ証明書を購入する手順を記載する
- オレオレ証明書を作り、Webサーバ（Apache/nginx）にインストールする
- SSL/TLSのプロトコル自体を詳解する
構成
情報量が多いので、前後編に分割します。
前編（この記事）は、SSL/TLSを実現する基礎的な仕組み・概念・技術要素を説明します。
後編は、SSL/TLSの具体的な内容について説明します。
以前、社内の勉強会で利用したスライドをベースに作成したので、お見苦しいところがあります。
用語の定義
| No | 用語 | 説明・内容 |
|---|---|---|
| 1 | SSL/TLS | Internet上でセキュアな通信を行うためのプロトコルの一つ。本記事で説明するもの。歴史的な経緯から、SSL/TLSには複数のバージョンがあるが、ここではそれらを総称して呼称する。 |
| 2 | SSLサーバ証明書 | Internet上で運営するWebサーバの正統性を証明するもの。本記事では「サーバ証明書」とも記述することがある。 |
| 3 | 平文 | 暗号化されていない文字列・情報。 |
| 4 | 暗号文 | 平文を、事前に既定した暗号方式で暗号化したもの。第三者に見られても、内容を読み取れない。 |
| 5 | 暗号化 | 平文を、既定の暗号方式に従って暗号文に変換すること。 |
| 6 | 復号化 | 暗号文を、既定の暗号方式に従って平文に変換すること。単に「復号」とも。 |
| 7 | 検証 | 電子署名を元に、対象となる電子データが改ざんされていない正当なものであることを、既定の手順に従って確認すること。 |
なぜ暗号が必要なのか
セキュリティの三要素
- 通信相手以外が通信内容を見ても、内容を判別できないようにしたい（Confidentiality）
- 通信内容が途中で改ざんされないようにしたい／改ざんされたらそれが分かるようにしたい（Integrity）
- 通信内容は予め許可した人にだけ参照可能なようにしたい（Availability）
暗号はConfidentialityを担保する。
共通鍵暗号と公開鍵暗号
共通鍵暗号方式
- 文字列の暗号化・復号化に同じ鍵を用いる方式
- 鍵を安全に渡すことが難しい
- 仕組みがシンプル
公開鍵暗号方式の仕組み
- 暗号化・復号化に別の鍵を用いる方式
- 2つの鍵を「鍵ペア」と呼び、それぞれ「秘密鍵」 「公開鍵」と呼ぶ
- 下記例では、「秘密鍵A」と「公開鍵A」が「鍵ペア」となる
- 秘密鍵で暗号化した文字列は、対になる公開鍵でのみ復号できる
-
公開鍵で暗号化した文字列は、対になる秘密鍵でのみ復号できる
なぜこのような芸当が実現できるのか、公開鍵そのものの仕組み・特性については、下記サイトが参考になります。
http://www.maitou.gr.jp/rsa/
http://www.maitou.gr.jp/rsa/rsa07.php
- 下記2組の鍵ペアを利用した通信の例
- 公開鍵W ・秘密鍵W（白ヤギさんが保持）
- 公開鍵B・秘密鍵B （黒ヤギさんが保持）
- 通信の流れ
- 通信相手の公開鍵を利用し、送りたい平文を暗号化する。
- 暗号文を受け取った側は、自分の秘密鍵で暗号文を復号する。
-
通信に先立ち、相手の公開鍵を入手しておく必要がある。
公開鍵暗号方式の難問
-
手に入れた公開鍵が、通信を望む相手のものなのか証明できない。
-
下図は、問題なく公開鍵の受け渡しができた場合。
-
手に入れた公開鍵が、通信を望む相手のものなのか証明できない。
-
下図は、中間に悪意の第三者が介在し、盗聴している場合。
-
白ヤギさんは、受け取った公開鍵が黒ヤギさんのものなのかどうか、判別できない。
-
この後白ヤギさんが、公開鍵Xで暗号化したデータを送った場合、悪意の第三者に解読されてしまう。
-
何が必要か
- 通信相手の公開鍵が本当に当人のものなのか、証明する必要がある。
-
どうやるか
- 公開鍵とその所有者の情報を組み合わせ、その内容に改ざんが無いことを証明する。
-
→電子署名
電子署名
電子署名とは
- 電子署名（でんししょめい）とは、電磁的記録（電子文書）に付与する、電子的な徴証であり、紙文書における印やサイン（署名）に相当する役割をはたすものである。主に本人確認、偽造・改竄(かいざん)の防止のために用いられる。
- （Wikipediaより引用。強調は引用者。）
- https://ja.wikipedia.org/wiki/電子署名
- SSL/TLSにおいて利用される。
電子署名の構成要素
- 公開鍵暗号方式（※説明済み）
- ハッシュ関数（一方向関数）
- 信頼できる第三者（CA局）
- 電子署名／電子証明書
ハッシュ関数（一方向関数）
- 入力文字列に複雑な計算を行い、固定長の数字を出力する関数
- 入力が1文字でも違えば出力は全く違うものになるため、改竄の検出に利用できる
- 出力文字列のサイズは、概ね128bit/256bit/512bitなどが利用される
- 主なハッシュ関数に以下のようなものがある
- SHA-2
- SHA-1
- MD5（脆弱性があるため、近年では利用されないようになっている）
信頼できる第三者（CA局）
- ある電子データ（署名文書）の改竄が無いことを担保するための重要な主体
- Certificate Authorityの略
- 日本語では「認証局」とも呼ばれる。
- CA局は厳重に管理された鍵ペアを運用する
- CA局の公開鍵は事前に広く配布される
- 鍵ペアを厳重に管理し、秘密鍵の漏洩は無いとされる
- 電子署名≒CA局が保持する秘密鍵で暗号化されたデータ
電子署名／電子証明書
- 通信主体の素性（署名文書）など、改ざんが無いことを保証したいデータに対し、CA局で電子署名を付与したもの
- 電子署名は、扱いを容易にするため、署名文書をハッシュ化した文字列に対して暗号化が行われる
電子証明書の作成
黒ヤギさんの署名文書から、電子証明書を作成する手順を考える。
- 黒ヤギさんが署名文書を作成し、CA局に署名を依頼する。この文書の中に、黒ヤギさんの公開鍵「公開鍵B」を入れておく
- CA局は、署名文書をハッシュ化する。
- ハッシュ化して得られた文字列を、CA局の秘密鍵で暗号化する。これが電子署名となる。（これはCA局の公開鍵でのみ、復号できる）
- 1.の署名文書に、3.で得られた文字列を付加したものが「電子証明書」となる。これを黒ヤギさんに返す。
電子証明書の検証
白ヤギさんが、黒ヤギさんの電子証明書を検証する手順を考える。
- 白ヤギさん黒ヤギさんから電子証明書を受け取る
- 白ヤギさんは、電子証明書の署名文書部分をハッシュ化する。
- 白ヤギさんは、電子署名部分をCA局の公開鍵「公開鍵CA」で復号化する（これは事前に入手している）
- 2.と3.で得られた文字を比較し、両者に差が無ければ、署名文書に改竄が無いと判断できる。結果、公開鍵Bが正統なものであることを確認できる。
電子署名の難問
- CA局の公開鍵はどうすれば信用できるのか？
- 更に上位のCA局が、下位のCA局の公開鍵・情報を証明すれば良いのか？
- →どこまでもさかのぼって際限が無い。どこかで割り切りが必要
電子署名が成り立つためのポイント
- 信頼できる第三者がCA局として存在する
- CA局の公開鍵を、信用できる手段で予め入手しておく
→上記が成り立たなければ、電子署名が成り立たない
SSL/TLSの場合、どう実現しているか？
- Symantec社やThawte社など、信頼のおける会社がCA局を運営している
- Webブラウザ出荷時に、予めCA局の公開鍵を**「ルート証明書」**として組み込んでおく。Internet Explorerの場合は、「信頼されたルート証明機関」として管理されている。
※後編に続く