TLS とは
TLS とは、次のセキュリティの３要素 CIA を通信経路に提供するプロトコル（ルール）です [1]
・機密性 (Confidentiality): 送信されるデータを盗聴できない
・完全性・整合性 (Integrity): 送信されるデータの欠損や改ざんを検出可能
・認証 (Authentication): 通信相手が正しいことを確認可能
なお、TLS の古いバージョンを SSL と呼びます。SSL は脆弱性が存在しているため [2]、新しいバージョンである TLS を学べば OK です。
次に、CIA を実現するための暗号方式について説明します。
暗号方式とアルゴリズムの種類一覧
暗号方式は大きく分けて次の３つがあります。
| 暗号方式 | CIA | 利用用途 | 暗号化アルゴリズム |
|---|---|---|---|
| 一方向暗号 | 完全性 | ハッシュ関数 | ・MD5 ・SHA-1 ・SHA-2 ・SHA-3 ・AEAD |
| 共通鍵暗号 | 機密性 | 通信の暗号化 - 公開鍵暗号より高速なため | ・DES ・AES ・RC4 |
| 公開鍵暗号 | 機密性 | 共通鍵の交換 - 公開鍵は盗まれても問題無いため - 共通鍵は盗まれると大問題 | ・DH ・ECDH ・ECDSA ・ECDHE | 認証 | 電子署名 | ・RSA ・ECDSA ・EdDSA ・ECC |
一方向暗号（ハッシュ関数）とは
一方向暗号（ハッシュ関数）とは、「元のデータ」を「ハッシュ値」に変換する関数です。
「ハッシュ値」は次の２つの特徴を持ちます。
・「元のデータ」が同じ場合、「変換後のハッシュ値」は同じ文字列になる
・「変換後のハッシュ値」から「元のデータ」を推測できない
一方向暗号（ハッシュ関数）の特徴・用途は以下のとおりです。
| 特徴・用途 | 説明 |
|---|---|
| 利用用途 | ハッシュ関数 1. 送信前の元のデータに対してハッシュ関数でハッシュ値を求める 2. 送信後の元のデータに対してハッシュ関数でハッシュ値を求める 3. 手順1. 2 のハッシュ値が同じであれば、完全性を確認できます |
| CIA | 完全性（送受信したデータに欠損や改ざんが無いかを確認） |
| 暗号化アルゴリズム | ・MD5 ・SHA-1 ・SHA-2 ・SHA-3 |
一方向暗号（ハッシュ関数）のサンプルコマンド
■実際にハッシュ値を求めてみる
89c99d37500be2061f853db3a4da2fcce4c0fc0f2f2b71bc2238acca0967c3b7
上記のハッシュ値は、元のデータ（data.txt）が改ざんされない限り、何回実行しても同じ値になります。
■元のデータ（data.txt）を改ざん
172666081ff2e826232b1a3ed3bbfcaa9b3056b2a79f8854b562cf17a1b46d13
先程とハッシュ値が異なることがわかります。
共通鍵暗号方式とは
共通鍵暗号とは、自分と通信相手で共通の鍵を利用する方式です。
共通鍵で暗号化されたデータは共通鍵で復号化できます。
つまり、暗号化・復号化できるのは、共通鍵を持つ相手と自分だけです。
共通鍵暗号方式の特徴・用途は以下のとおりです。
共通鍵暗号のサンプルコマンド
■共通鍵を使ってデータを暗号化
U2FsdGVkX18w4ce8ZuMsgmqBsLtYeHuvipXOSqrNHes=
共通鍵（common_key.txt）を利用してデータ（data.txt）を暗号化できました。
■共通鍵を使ってデータを復号化
HelloWorld
暗号化したデータ（encrypt.txt）を復号化できたこと（decrypt.txt）が確認できます。
公開鍵暗号方式とは
公開鍵暗号方式とは、「全世界に公開する公開鍵」と「自分だけが持つ秘密鍵」を利用する方式です。
公開鍵暗号方式は次の３つの利用用途があります。
なお、「通信の暗号化」に対する「共通鍵暗号方式」と「公開鍵暗号方式」の使い分けは以下のとおりです。
| 用途 | 暗号方式 | 説明 |
|---|---|---|
| 共通鍵の交換 | 公開鍵暗号方式 | 暗号化してない通信で渡せる鍵は公開鍵だけ - 公開鍵は公開して良い - 共通鍵は公開してはいけない 受け取った公開鍵と自分の秘密鍵を利用して、共通鍵を生成します。 |
| 共通鍵を交換した後の通信 | 共通鍵暗号方式 | 共通鍵暗号方式の方が復号化の計算時間が短いため |
通信の暗号化
公開鍵で暗号化したデータは、秘密鍵でのみ復号化できます。
そのため、データを復号化できるのは秘密鍵を持つ自分だけです。
公開鍵暗号で暗号化するサンプルコマンド
■公開鍵でデータを暗号化
0000000 8a 61 e4 d4 5b fd 3f fd 74 bc 66 46 34 03 1e b9 0000010 76 11 a4 49 e0 64 37 37 bc 71 df 9f 80 d7 e7 e8 0000020 5d 74 a4 29 f5 48 1c 1f f2 f6 59 4c 14 9b ac 2d 0000030 bc 5c f4 76 23 c9 4e 03 bd b8 da 7c f9 6e 3e ff 0000040 c9 ba e7 69 01 96 11 0a 06 36 ae f4 d8 14 aa 22 0000050 46 a4 7f be 58 3f 59 bf 17 e1 ad 3b 94 a2 a3 b7 0000060 dd 25 69 38 d1 13 d4 12 d4 03 e9 f1 32 5b 09 04 0000070 ef b3 7e 69 f6 9e f3 1c 1b 83 f0 5d 9b f0 31 e8 0000080 3e 46 b0 0e 67 f3 1b ee c8 6e ec a9 07 99 f1 70 0000090 12 64 cb b6 66 3d 5d c9 a0 14 52 3f 19 5a 0b ad 00000a0 12 3e 58 75 a6 e0 73 84 75 f2 0c 0c 80 13 6c 9a 00000b0 4b 50 84 90 3e bb b8 96 9e 29 28 8e c5 53 85 13 00000c0 d6 25 56 0c a0 e6 2c 02 e7 64 1a ce c2 98 44 94 00000d0 0d a0 71 63 dd 23 16 b2 df 4f a4 1c e7 e2 81 a5 00000e0 94 f5 ed ff 81 5a 2c da d0 7c 5e f2 d4 63 a7 b5 00000f0 65 74 11 ca e7 6a 2a fa 8a d5 7e f6 64 09 99 3f 0000100
■秘密鍵でデータを復号化
HelloWorld■公開鍵と対になっていない秘密鍵で復号化した場合
RSA operation error-->ちゃんとエラーになる。
共通鍵の交換
共通鍵暗号方式では、共通鍵を持ってない相手と安全に共通鍵を交換できません。
- 共通鍵は誰にもバレてはいけないため、相手に渡す際には暗号化する必要があります
- 受信した共通鍵を復号化するためには、相手から共通鍵を貰う必要があります
- １に戻る
そこで、公開鍵暗号方式を利用して共通鍵を交換します。
■共通鍵の交換手順は以下のとおりです。（DH アルゴリズム）
- 各々が公開鍵を生成し交換します。（x, p は公開情報です。）
公開鍵は盗まれても大丈夫なので暗号化してない通信でも OK です。
2. 貰った公開鍵と持っている秘密鍵で共通鍵を生成します。
以下の計算式を用いると、「全く同じ共通鍵」が生成されることが数学的に証明されてます。
https://github.com/crypto-browserify/diffie-hellman/blob/master/lib/primes.json
詳しくは以下の記事が参考になります。
電子署名
秘密鍵で暗号化したデータは、公開鍵でのみ復号化可能です。
公開鍵で復号化可能なデータを生成できる人は、「秘密鍵を持ってる人」だけです。
そのため、「秘密鍵による暗号化」を「電子署名」として使うことができます。
公開鍵暗号で電子署名をするサンプルコマンド
■秘密鍵でデータの電子署名を作成
電子署名は以下の手順でハッシュ値を暗号化したものです。
- ハッシュ関数 SHA256 を利用して、data.txt のハッシュ値を求める
- 秘密鍵を利用して、１で生成したハッシュ値を暗号化する←これが電子署名
0000000 9b 1e 19 eb 53 80 d9 8d d7 bf d7 fb 4a ca 89 da 0000010 9a 20 8e 46 13 98 c9 9f 72 28 0b d6 06 24 27 88 0000020 a8 d2 49 b6 15 23 f7 4f ac 71 ca 82 cc 0d 89 b8 0000030 35 fc 86 8f d3 fa 9d 5d 8a 14 cb d7 4e 5b 7f 5c 0000040 a3 f8 74 b9 57 ec 68 17 1d 20 44 b2 fe 67 23 13 0000050 df 1b 65 46 b8 d7 ac 27 c3 5e e5 e1 4a 42 35 c5 0000060 73 31 54 99 92 db ff 02 c3 43 78 f5 21 73 66 ac 0000070 55 3f c5 6d 66 31 5d 23 51 4e d8 ca 67 ac 2b 74 0000080 a4 68 a2 34 60 ec a8 72 17 e2 cd 74 dd 76 5a 0b 0000090 3f 2f a8 8a d7 5a f1 4f 76 42 ef 1f 16 ad 73 9d 00000a0 ab 2c 6e 99 fa 04 bf 72 ce 34 d9 2d 5d 1e d3 50 00000b0 88 15 e8 6f 1c 73 5c 6a ba ba 44 9c fd 91 17 d6 00000c0 d1 b1 f5 fc 16 2c b9 0c 45 09 a8 7a ad b6 46 dd 00000d0 be d3 8e f8 74 3e 21 21 78 fe 44 a5 a6 3f e7 ee 00000e0 bc 86 ce 08 a6 dd b6 94 09 42 b9 5c 17 9b c6 91 00000f0 62 2f 79 1b 1b 15 1c 85 d0 26 b5 e9 36 e1 93 f3 0000100
■公開鍵でデータの電子署名を検証
Verified OK
以下の２つが一致すれば「Verified OK」となります。
- 公開鍵で、電子署名（sign.sig）を復号化した値を求める
- ハッシュ関数 SHA256で、元のデータ（data.txt）のハッシュ値を求める
Cipher Suite（暗号スイート）
Cipher Suite（暗号スイート）とは、サーバーとクライアント間で暗号通信を行う際に利用する以下の４つのアルゴリズムの組み合わせのことです。
・一方向暗号アルゴリズム（Mac - Message Authentication Code）
・共通鍵暗号アルゴリズム（Enc - Encryption）
・公開鍵暗号アルゴリズム
- 鍵交換アルゴリズム（Kx - Key Exchange）
- 認証アルゴリズム（Au - Authentication）
要するに、最初で示した以下の各暗号方式で利用する「暗号化アルゴリズム」を決めます。
| 暗号方式 | CIA | 利用用途 | 暗号化アルゴリズム |
|---|---|---|---|
| 一方向暗号（Mac） | 完全性 | ハッシュ関数 | ・MD5 ・SHA-1 ・SHA-2 ・SHA-3 ・AEAD |
| 共通鍵暗号（Enc） | 機密性 | 通信の暗号化 - 公開鍵暗号より高速なため | ・DES ・AES ・RC4 |
| 公開鍵暗号 | 機密性 | 共通鍵の交換（Kx） - 公開鍵は盗まれても問題無いため - 共通鍵は盗まれると大問題 | ・DH ・ECDH ・ECDSA ・ECDHE | 認証 | 電子署名（Au） | ・RSA ・ECDSA ・EdDSA ・ECC |
Cipher Suite（暗号スイート）の確認
利用可能な Cipher Suite を確認するには、以下のコマンドを利用します。
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 （中略）
例えば３行目の "ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384" は以下の意味を表します。
| 暗号方式 | 利用するアルゴリズム |
|---|---|
| 公開鍵暗号 の 共通鍵の交換（Kx） | ECDH |
| 公開鍵暗号 の 電子署名（Au） | RSA |
| 共通鍵暗号（Enc） | AES(256) |
| 一方向暗号（Mac） | AEAD |
TLS を実現する技術
２点間に安全な通信経路を提供するために、TLS は次の2つのプロトコルにより認証・機密性・完全性を実現します。
- TLS ハンドシェイクプロトコル（相手を認証して共通鍵を交換する）
- TLS レコードプロトコル（共通鍵で通信を暗号化する）
以降では初めて登場した用語「TLS 証明書」について説明をしていきます。
なお、TLS プロトコルは様々なアプリケーションプロトコルで利用できますが、今回は HTTPS プロトコルで TLS プロトコルを利用する例を見ていきます。
TLS 証明書の詳細
TLS 証明書は通信相手を認証するために使用します。証明書が本物であることは、信頼できる第三者が認証します。この信頼できる第三者を認証局（CA、Certificate Authority）と呼びます。
認証局が必要な理由
もし認証局がいない場合、証明書を送って来た Web ページは必ず以下のように「この証明書は本物なんですよ」と言います。
そのため、信頼できる第三者が証明書を本物であることを保証する必要があります。
TLS 証明書を使用して通信相手を認証する手順
通信相手を認証する手順は次のとおりです。
- 信頼できる認証局を設定する（/etc/pki/tls/certs/ca-bundle.crt）
- 通信相手の提供する証明書を受け取る
- 証明書の電子署名のハッシュを利用して完全性を確認する
- 証明書の電子署名の公開鍵暗号を利用して認証する（１で設定した信頼できる認証局が認証していることを確認）
信頼できる認証局を設定
主要な信頼可能な認証局は PC やスマホ出荷時に許可されてます。そのため、通常は特に必要ない操作です。
//信頼する認証局の証明書 $ less /etc/pki/tls/certs/ca-bundle.crt //追加で信頼する認証局の証明書を配置 $ sudo cp <追加で信頼する認証局の証明書> /usr/share/pki/ca-trust-source/anchors // "/etc/pki/tls/certs/ca-bundle.crt" の内容を更新する $ sudo update-ca-trust extract
通信相手（サーバー）が提供する証明書を確認
サーバーが提供する TLS 証明書の中身は openssl コマンドの -showcerts オプションにて確認できます。google.com を例に TLS サーバー証明書の中身を見ていきます。
$ openssl s_client -connect google.com:443 -showcerts 0> /dev/null depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com （中略）
証明書の各要素は以下の意味を表します。
| 要素 | 説明 |
|---|---|
| depth | 証明書チェインの深さ（後述します） |
| C | 国 |
| ST | 州（都道府県） |
| L | 都市（市区町村） |
| O | 組織名（企業名） |
| OU | 部門名 |
| CN | 一般名（ドメイン） |
例えば、一番最後の行は次の意味を表します。
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com C = US --> アメリカ ST = California --> カリフォルニア州 L = Mountain Vie --> マウンテンビュー O = Google LLC --> Google LLC という企業 CN = *.google.com --> *.google.com の証明書
証明書チェイン
*.google.com の証明書を認証する認証局の証明書Aが正しいかどうかを判断するにはどうすればよいでしょうか。答えは認証局Bが認証局Aの証明書を認証します。
このように認証が連鎖することを証明書チェインと呼びます。
証明書チェインの具体例
先程の *.google.com の証明書を例を見てみましょう。
$ openssl s_client -connect google.com:443 -showcerts 0> /dev/null
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
こちらは以下の意味を表します。
- Google LLC「CN = *.google.com は本物ですよ。CN = GTS CA 1O1 が証明してるからね」
- Google Trust Services「CN = GTS CA 1O1 は本物ですよ。GlobalSign が証明してるからね」
- GlobalSign「CN = GlobalSign は本物ですよ。俺が言うんだから間違いない」
最後に「俺が言うんだから間違い無い」と言う認証局はルート認証局と呼ばれます。
今回の証明書チェインのルート認証局である GlobalSign は GMO 系列の会社ですね。
なお、GlobalSign Root CA - R2 は以下のようにデフォルトで信頼されている認証局となります。
$ less /etc/pki/tls/certs/ca-bundle.crt GlobalSign Root CA - R2 -----BEGIN CERTIFICATE----- MIIDujC(中略) -----END CERTIFICATE-----
TLS 証明書の種類
TLS 証明書には、認証局が認証した方法により次の３種類に分かれます。
- ドメイン認証（DV）
- ドメイン（google.comなど）を所有しているかどうかを確認します
- 組織認証(OV)
- 組織の住所や会社名を確認します
- 実在認証(EV)
- 組織が本当に存在するのかきっちり確認する
- 帝国データバンクなどで組織の情報を確認
- 代表者に電話かける
- 組織が本当に存在するのかきっちり確認する
電子署名（認証・完全性）
ルート認証局（ここでは GlobalSign）が google.com の証明書を認証したことを確認するには電子署名を確認します。電子署名が無いと先程と同じように以下のとおりとなります。
- google「この証明書は GlobalSign に本物と証明されています」
- 悪意のあるWebページ「この証明書は GlobalSign に本物と証明されています」
電子署名の作成手順
電子署名は以下の手順で作成します。
- TLS サーバー証明書にハッシュ関数を使用してハッシュを作成する（完全性の保証）
- ハッシュに対して、秘密鍵を用いて暗号化する
openssl コマンドを利用して電子署名を作成する方法は以下のとおりです。
//RSAアルゴリズムで秘密鍵を作成します $ openssl genrsa > private.key //SHA256 ハッシュ関数、秘密鍵を使用して document.txtの電子署名を作成します。 $ openssl dgst -sha256 -sign private.key document.txt > sign.sig
電子署名の実体
$ hexdump sign.sig 0000000 f663 4396 ea2f 6ab1 e870 8424 897a cacf 0000010 d7a3 3cf0 8855 86e7 a5d4 2045 10e7 ab60 0000020 676e 147c e16e ff48 0679 9774 1405 0132 0000030 881f d88e 4345 be47 a19d 29ba 18aa c9c5 0000040 1022 8858 712b 0ea7 8875 ecf1 2c19 168b 0000050 6829 efca f152 9e0a e011 8872 a914 6d55 0000060 bae8 4cab 13ef 7fd8 237b b4cb b720 4b4a 0000070 6b41 59ee ac96 050a 9330 2446 bb1d c0d7 0000080 738f 9b41 12e7 3c8d 1b49 c5db d898 706f 0000090 819e 4470 c742 700e 7d14 0bc3 b697 9db4 00000a0 1cf1 0c68 72f8 0c1d 1bb8 4543 a44e 4d02 00000b0 e722 0c5c 7202 914d 0034 61bf 292f 48c9 00000c0 90bf 536a b481 1a87 a6a0 d535 2957 4a05 00000d0 f2bf 1c08 16af a535 2866 408f 6b62 2a92 00000e0 02f7 f1fd 3638 3b7a 7409 a32e 869f e843 00000f0 e7c2 008b b27f 3c47 3e62 5917 bcb8 0400 0000100
電子署名の検証手順
電子署名は以下の手順で正しいことを検証します。
- サーバーから受け取った TLS サーバー証明書にハッシュ関数を使用してハッシュを作成する
- 電子署名に対して公開鍵を用いて復号化する
- １と２が同じであれば本物（本物の秘密鍵以外で暗号化されている場合、復号化した結果が一致しない。）
秘密鍵を持っているのは、本物の認証局だけなので、電子署名によりルート認証局がたしかに認証した証明書であることが検証できます。
openssl コマンドを利用して電子署名を検証する方法は以下のとおりです。
//公開鍵の作成 $ openssl rsa -in private.key -pubout -out public.key //電子署名を検証する。以下の２つが一致することを確認 //公開鍵を使用して電子署名 sign.sig を復号化 //document.txt にハッシュ関数 sha256を使用してハッシュ値を求める $ openssl dgst -sha256 -verify public.key -signature sign.sig document.txt Verified OK
ルート認証局の公開鍵で復号できる暗号を作成を作成できるのは、本物の認証局が持つ秘密鍵だけです。なので通信相手は本物と認証できます。
証明書にハッシュ関数を適用して同じ値となるのは、同じ証明書の場合だけです。なので証明書の完全性を保証できます。
電子署名を具体例（google.com）で確認
下記のコマンドで TLS サーバー証明書の詳細を確認し、電子署名に関連する情報を確認します。
$ openssl s_client -connect google.com:443 -showcerts < /dev/null | openssl x509 -text depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com verify return:1 Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ba:b5:b9:2a:79:2b:52:74:6d:85:bc:b5:ff:ad: Signature Algorithm: sha256WithRSAEncryption c5:1b:7d:32:be:2c:1d:1f:7e:15:d0:9a:19:29:f2:f4:2e:8e:
上記のコマンドにより、 TLS 証明書には電子署名、および検証に必要な項目が全て含まれていることがわかります。
- Signature （電子署名）
- Algorithm: sha256WithRSAEncryption（電子署名で使用するハッシュ関数と公開鍵暗号）
- depth（証明チェイン）
- Public Key（公開鍵）
証明チェインに従って順番に検証を行い、ルート認証局まで検証が完了すれば認証完了です。なお、ルート認証局である 「GlobalSign Root CA - R2」は /etc/pki/tls/certs/ca-bundle.crt で信頼している必要があります。
参考ページ
[1] The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the secure channel should provide the following properties:
https://tools.ietf.org/html/rfc8446
[2] 更新：SSL 3.0 の脆弱性対策について(CVE-2014-3566)
https://www.ipa.go.jp/security/announce/20141017-ssl.html
[3] - Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).
https://tools.ietf.org/html/rfc8446
