背景

• HTTPSについて調べていたときのメモを発見したのでこっちにコピーする

基本

共通鍵暗号方式 (DES, AES)

一番ベーシックな暗号方式は共通鍵暗号方式。 シーザー暗号もこの一種。

1. 予め共通鍵を共有する
2. 送信者は送るテキストを共通鍵で暗号化
3. 受信者に送信
4. 受信者は暗号化された文を共通鍵で復号

DESとAESとは？

第二次世界大戦で利用されたエニグマなど1976年以前の暗号は共通鍵暗号に分類される。 この暗号方式は1977年にアメリカ政府が策定した56ビットの鍵を用いるDES(Data Encryption Standard)として広く用いられてきた。 しかし、現在では総当たり攻撃で解読可能なほど安全性が低くなっており、2001年にNISTが公募し規格化したAES(Advanced Encryption Standard)が標準として利用されている。

公開鍵暗号方式とは？

共通鍵暗号方式では、ひとつの鍵（共通鍵）を使用するが、公開鍵暗号方式では対になっている 2つの暗号鍵を用いる。

この 2つの鍵は、それぞれ「公開鍵 (Public Key)」と 「プライベート鍵(Private Key)もしくは秘密鍵」と呼び、対となる 2つの鍵の組み合わせを「鍵ペア」と呼ぶ。

メッセージの送信フロー

1. 受信者は予め公開鍵を送信者に送る
2. 送信者はメッセージを公開鍵で暗号化して送信する
3. 受信者は秘密鍵で暗号文を復号する

なぜ公開鍵で暗号化して、秘密鍵で復号化するのか？

基本的には公開鍵で暗号化して、秘密鍵で複合する。 なぜ逆はないかというと、秘密鍵で暗号化すると、みんな読めてしまう状態になるから。

ハイブリッド暗号 (公開鍵暗号方式と共通鍵暗号方式を組み合わせ)

実際のメッセージの中身の暗号化では、公開鍵暗号方式と共通鍵暗号化方式を組み合わせる。

なぜ公開鍵暗号方式と共通暗号方式を組み合わせるのか？

公開鍵暗号方式では実は処理が重いから。 公開鍵暗号方式は複雑な演算処理を行うため、共通鍵暗号方式の数百倍もの計算が必要になる。 そこで実際には、高速な処理を可能にするため、公開鍵暗号方式と共通鍵暗号方式を組み合わせて使用する。

公開鍵暗号方式と共通暗号方式を組み合わせによるメッセージの暗号化

1. 共通鍵 (S) を生成する。（A さん）
2. 生成した共通鍵 (S) を用いて、平文 (T) を暗号化する。（A さん）
3. 各送信相手の公開鍵 (B, C, D) を用いて、共通鍵を暗号化 (SB, SC, SD) する。（A さん）
4. 暗号文 (TS) と暗号化した共通鍵 (SB, SC, SD) を送信する。（A さん）
5. 自分の公開鍵(B)で暗号化された共通鍵 (SB) を選択し、自分のプライベート鍵(B’)を用いて復号(S)する。（B さん、C さん、D さん）
6. 復号した共通鍵 (S) で暗号文 (TS) を復号 (T) する。（B さん、C さん、D さん）

公開鍵暗号方式と共通暗号方式の組み合わせのポイント

共通鍵でメッセージを暗号化するが、共通鍵は公開鍵で暗号化して、秘密鍵で共通鍵を復号化してその復号化した共通鍵でメッセージを復号化するところ。 つまり、共通鍵方式で問題だった、共通鍵の安全なやり取りの問題を公開鍵方式で解決しているところ。 共通鍵方式では一旦共通鍵がバレルと暗号文は全部ダダ漏れだから。

非公開鍵による変換（デジタル署名）

デジタル署名とは？

メッセージに対するダイジェストを秘密鍵で暗号化することで、メッセージの改ざんを検出することができる。これをデジタル署名 (Digital Signature) と呼ぶ。

公開鍵は誰でも取得できるため、プライベート鍵で暗号化しても 守秘性の確保にはならないが、 プライベート鍵が特定の個人のみ所有しているので、電子文書の真正性と完全性の保証を実現することができる。

これがデジタル署名 (Digital Signature) と呼ばれる技術。

デジタル署名では、署名と検証の2つのことを行う。

デジタル署名の検証の目的

1. メッセージが改ざんされていないこと
2. メッセージは、検証に使用した公開鍵と対になる秘密鍵(鍵ペア)によって署名されたこと

なぜ非公開鍵で暗号化するのか？

• 基本的に公開鍵方式では、公開鍵で暗号化して、非公開鍵で復号化する。
• (なぜなら、その逆だと、公開されている公開鍵でだれても暗号文を解読できてしまうから)
• ただし、RSA暗号方式の場合、これとは逆に、プライベート鍵で暗号化(署名)して公開鍵で復号(検証)することもできる。
• この仕組みによって、署名を検証することで、改ざんされていないことや鍵ペアが正しいことを検証する。
• NOTE: メッセージの中身自体は暗号化されていないので注意。

用途による鍵ペアの名称

メッセージの中身自体を暗号化したい場合は、公開鍵を使って暗号化して、秘密鍵で復号化する。 他方、署名(デジタル署名)をしたい場合は、非公開鍵で暗号化して、秘密鍵で検証する。

用途による意味の違い

意味的には、暗号鍵と復号鍵と検証鍵がある。

RSA暗号について

基本、公開鍵暗号方式では、公開鍵は公開されているので、暗号化用で、非公開鍵は復号化ように使われる。 ただし、RSAはちょっと違う。双方向で暗号と復号が可能。その構造上、デジタル署名のアルゴリズムとして使われている。 順を追って説明する。

RSA暗号の仕組み

RSAでは公開鍵と秘密鍵の２つの鍵を 素数の掛け算と素因数分解の計算コストの差を利用して実現する。

A: 素数 B: 素数 C = A x B

その計算には次の特徴がある。

• 掛け算は簡単
  • AとBが数百桁あったとしても、かなり短時間で計算できる。
  • 23451532523 x 53523532532235 = ??? みたいな
  • 単に計算すればOK = ローコスト
• 素因数分解は難しい
  • ??? x ??? = 5057230593780528023
  • これは5057230593780528023を素因数分解する必要がある。
  • ただし、因数は素数なので大きな素数の掛け算になる。
  • 虱潰しに計算しないといけない = ハイコスト

RSA暗号の具体的な例

• RSAの公開鍵 (素因数分解)
  • この鍵で暗号化したものを平文化するためには、秘密鍵が必要
  • A × B = C のうちの C だけが書かれている
  • 計算によって、Cから AとB を特定するのは困難(=公開鍵から秘密鍵は作れない)
  • 公開鍵から秘密鍵を作ることができないため、「閉めることしかできない鍵」となる
• RSAの秘密鍵 (掛け算)
  • 公開鍵で暗号化したものを平文化することができる鍵
  • A × B = C のうちの AとB が書かれている
  • 計算によって、AとB から Cを求めるのは簡単(=秘密鍵から公開鍵を作れる)
  • 秘密鍵から公開鍵を作ることができるので、間接的には閉めることもできる

重要なのは、RSAでは、秘密鍵だけ大事に保管しておけば、 無くしてしまった公開鍵をあとから生成しなおすことができる

RSAの公開鍵と非公開鍵はどちらでも暗号化と復号化が可能

実は RSAの公開鍵と秘密鍵は同じ構造をしているので、どちらの鍵をつかっても暗号化することができる

つまり、双方向でできてしまう。 ただし、秘密鍵から公開鍵は作成できないので、公開鍵を渡すようにする。

また、公開鍵で暗号化してもあまり意味がない。 なぜなら、公開鍵は公開されているので、誰でも暗号化できるため。 Githubみたいに(https://github.com/mgoldchild.keys)、公開鍵として公開されている。

非公開鍵で暗号化できるメリット

それは暗号文を自分で暗号化したことを証明できる。

明日送金します。by Mike

というメッセージが平文で(暗号化されずに)送られてきた時に、 そのままではこのメッセージを書いたのが本当にMikeなのか、 それとも第三者が捏造したものなのかを区別することができない。

それを区別できるようにするのが電子署名。

RSAの電子署名は、 秘密鍵による暗号文を作り出すことで実現する。 上記文章をMikeの秘密鍵で暗号化すると、受け取った人はMikeの公開鍵を使って平文化できる。

Mikeさんの公開鍵は公開されているので誰でも読めるが 公開鍵で平文化できる暗号文を作れたということは、 Aさんの秘密鍵を持っているということ、

つまり 本人が書いた文章だということがわかる。これが電子署名。

つまり、メッセージを暗号化する共通鍵方式や普通の公開鍵暗号方式とは違い、 RSA暗号ではメッセージではなく、送信者を保証することを目的とする。

コマンドの具体例

コマンドでは一旦メッセージを計算コストの低くなるdigitにsha1などで変換してから、非公開鍵で暗号化する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

echo -n "明日送金します。by Mike" | openssl dgst -sha1 -sign private-key.pem | hexdump
0000000 c2 1f 73 6d 4f b5 fa 5a 9d 9d 02 e0 a3 fe 70 0c
0000010 93 ef f5 f1 3c 34 ec 5f e0 8d 21 58 6a 27 3a e1
0000020 b0 49 81 a8 15 d2 92 39 cc fe ce 2d 3f 9f 91 3d
0000030 68 cf 99 ce 91 04 2e 72 e7 e5 c5 71 55 29 87 7d
0000040 f5 e9 f0 c3 f5 6b af f4 be 8f f9 c4 34 bb 52 1c
0000050 51 8d cf c7 64 e0 84 d2 33 ed bb 80 4f 9a 3f 42
0000060 84 2e ef 41 e4 fc b4 04 51 5e 55 11 86 63 31 fc
0000070 a1 b7 6b 93 f7 e0 67 31 04 69 e4 2e 97 e6 5f a2
0000080

まとめ

インターネットで身元を確認して挨拶するのは大変という話。

Mike> Hi John. John> Good morning Mike.

顔が見えないインターネットでは次のような疑問が浮かぶ。

• 人
  • 本当にMikeなのか？
  • 本当にJohnなのか？
• メッセージ
  • 途中で誰かにメッセージを盗聴されていないか？
  • 途中で誰かにメッセージを改ざんされていないか

そういう背景があって暗号化が必要になる。

比較

公開鍵暗号方式の種類

DH鍵共有

DH 離散対数問題とフェルマーの小定理

素数と離散対数問題 (Discrete Logarithm Problem)

2^x mod n = xを次の表で示す。 例えば、2の2(x)乗=4を3(n)でmodすると、答えは1。つまり、あまりは1。 すると、nが素数のとき (7, 17, 23, 31 を除いて)、計算結果に 1 から n-1 までの全ての整数が登場する。

例えば n=37 のとき、1 から 36 が 1 回ずつ登場する。

また、そのようにならなかった n=7, 17, 31 についても、3^x mod n を計算すると同様に 1 から n-1 までの全ての整数が登場する。

このように、n が素数で、基数 g (前述の 2 とか 3 の部分) を適切な値に選ぶと、g^x mod n (1 ≦ x ≦ n-1) は 1 から n-1 までの整数が 1 回ずつ登場する。

このようなとき、g^x mod n = K の計算で、K 以外の 3 つのパラメータが与えられていて K を計算するのは比較的簡単であるのに対し、x 以外の 3 つのパラメータが与えられて x を計算するのは難しい、という性質がある。

この x を求める難しい問題のことをDiscrete Logarithm Problem (DLP: 離散対数問題) と呼ぶ。

以降、mod n の n (法の n) が素数のとき、mod p と記述する。素数を英語で prime と呼ぶからである。

DH 鍵共有アルゴリズムでは、g (基数) と n 改め p (適切な大きな素数) を公開パラメータ、x (1 ≦ x ≦ p-1) を各個人の秘密鍵、K (g^x mod p) を各個人の公開鍵として使う。

フェルマーの小定理

先程の表で、n が素数のとき、n-1 の計算結果が必ず 1 になっていることに着目する。これはフェルマーの小定理と呼ばれるものである。

DH法の問題点は中間者攻撃

中間者攻撃とは、通信を行う２者の間に第三者が介入し、２者に気づかれないように情報を盗み見る方法。

下地図のように中間攻撃者がいると、共通鍵がバレてしまうので、メッセージの内容を復号化して中身を読めてしまう。

DH鍵共有とは

共通鍵暗号方式のために使われる共通暗号を共有する仕組み。 具体的には、$a$, $b$を非公開鍵、$g$, $p$をパラメータとし、$g^a \mod p$や$g^b \mod p$を公開鍵とし、認識を合わせた上で、共有鍵を作る方式。

DH鍵共有の具体的な計算

DH鍵共有を使うプロトコル

IP ネットワーク通信において、暗号化による機密性と認証による通信相手の正当性を担保する技術として「IPsec」や「SSL/TLS」、「SSH」等がある。 この 3 つのプロトコルは用途によって使い分けられるが、いずれも共通鍵暗号方式での通信暗号化のための「共通鍵の共有」を、【Diffie-Hellman 鍵共有 (DH 鍵共有)】というアルゴリズムによって実現している。

dh鍵交換の簡単な計算例

50 / 7 = 4あまり1を次のように表現する。

$$ \begin{align} 50 \mod 7 = 1 \\ 324 \mod 7 = 2 \end{align} $$

この剰余演算は普通の計算と同じような、以下の性質がある。

$$ \begin{align} (a \mod n) + (b \mod n) = (a+b) \mod n \\ (a \mod n) - (b \mod n) = (a-b) \mod n \\ (a \mod n) × (b \mod n) = ab \mod n \\ (a \mod n)^b = a^b \mod n \\ \end{align} $$

割り算も条件付きで定義可能だが、ここでは省略する。

$$ \begin{align} (50 \mod 7) + (324 \mod 7) = 374 \mod 7 = 3 \\ (50 \mod 7) - (324 \mod 7) = -274 \mod 7 = 6 \\ (50 \mod 7) × (324 \mod 7) = 16200 \mod 7 = 2 \\ \end{align} $$

SSL証明書

SSL証明書とは

HTTP通信を暗号化するには次のファイルが必要となる。

• サーバーの公開鍵(CSR)と秘密鍵(Key)
• 認証局(CA)が電子署名したSSL証明書(CRT)と中間CA証明書 SSL証明書はサーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が署名されているファイルである。

サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用し、署名は「なりすまし」を防ぐために使う。

署名は、証明書を発行するCAと呼ばれる第三者機関が、CSRの情報を元に行う。

中間CA証明書は、SSL証明書を発行する認証局またはその配下にある別の認証局によって署名されたファイルである。必須ではありませんが、セキュリティレベルの向上を理由に、中間CAを1つい上用いる階層構造とる認証が現在は主流となっている。

SSLの用語と設定の違い

事前に用意するモノ

• KEY:
  • SSLの為のサーバー用の秘密鍵のこと。
• CSR (Certificate Signing Request):
  • SSLの為のサーバー用の公開鍵のこと。
  • CSR には「公開鍵」とその所有者情報、及び申請者が対応する秘密鍵を持っていることを示すために申請者の署名が記載されている
  • サーバの公開鍵はクライアントとの通信を「暗号化」する際に使用するリクエスト用

CSRの例

CA(認証局)によって発行されるSSL証明書

• CRT:
  • サーバー証明書
• INCRT
  • 中間CA証明書
• ROOTCRT
  • ルート証明書

CRTの例

SSL証明書の中身

• SSL証明書 or SSLサーバー証明書 or サーバー証明書
  • CRTとINCRTとROOTCRTの中身
  • サーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報が電子署名されているファイル
  • 階層構造になっている
  • トラストチェーンでサーバー証明書を証明する中間CA証明書を証明するルート証明書という感じになっている
  • ルート証明書はPCに直接保存されている

1
2
3

Example CA Root X1
 └Example CA intermediate G2
   └example.jp

SSL証明書発行と設定の流れ

SSL証明書の発行には、次のような手順が踏む。

1. 自分のサーバーでCSRとKEYを作成
2. CSRをCAへ送信して証明書の発行を申請
3. CAから電子署名されたCRTと中間CA証明書を受け取る
4. 受け取った証明書類をWebサーバーへ設置する

ディスティングイッシュネームとは？

• ディスティングイッシュネームとは、CSRを作成する際に登録をする、ウェブサイトの所有者情報のことである。

電子証明書

CSR (証明書発行要求) とは

CSR とは証明書発行要求 (Certificate Signing Request) と呼ばれるもので、これを生成する際に、秘密鍵と公開鍵も作られる。

CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がる。

• CSR = 公開鍵を含む情報
• 電子証明 = 認証局の秘密鍵で生成
• デジタル証明書 = 電子証明 + CSR

デジタル署名とは？

電子文章をハッシュ化して非公開鍵を使って電子署名を作成。 それに対して、公開鍵で検証する仕組み。

RSA署名の作成

RSA署名の検証

電子証明書が正しいかどうかは、認証局の公開鍵を用いて署名検証鍵（署名の対象となる電子文章）を復号化して、それをハッシュ関数に渡してハッシュ値が一致するかを確認する。

大前提として、非公開鍵で暗号化された文章は複合が可能。

電子証明書は印鑑登録書と同じ仕組み

SSL（電子証明書）の仕組みは、単純に言えば、印鑑登録証(印鑑証明)と同じ仕組み。

デジタル証明書を発行する中間認証局が、その中間認証局の秘密鍵でデジタル証明書にデジタル署名する。これにより、デジタル証明書に書かれたホスト名の機器は、中間認証局がお墨付きをくれた状態になる。(印鑑証明で言う地方役所)

じゃあ中間認証局の身元は誰が保証するの？というと、更に上位の認証局。

このプロセスを最上位であるルート認証局まで繰り返すが、ルート認証局の身元は誰が保証するの？というと、自分自身でサインする。これは自己署名証明書と呼ばれる (俗に言うオレオレ証明書)。(印鑑証明で言う日本国)

=> なのでルート証明書は必ず自己署名証明書 (オレオレ証明書) になる。

その他

実際のフロー

Webサーバーの事前準備

1. Webサーバーは予めCSRと秘密鍵を発行する
2. そのCSRを認証局に送る
3. 認証局はCSRを認証局が持つ秘密鍵で暗号化する=デジタル証明書の作成
4. 認証局はその暗号化したCSR(デジタル証明書)をWebサーバーに返す
5. Webサーバーはデジタル証明書と秘密鍵を設置する

Userからのアクセス

1. Userはデジタル証明書をWebサーバーに要求する
2. Userはデジタル証明書を認証局の公開鍵を使って検証
   • 相手が認証局に証明されているデジタル証明書を使っているかを確認
   • この時点で認証局に証明されたWebサーバーの公開鍵が入っているがまだ使わない
3. WebサーバーはDH公開鍵(SV)を作成
4. Webサーバーは秘密鍵でDH公開鍵(SV)を署名する = デジタル証明書(2)
5. Webサーバーはその新たなデジタル証明書(2)をUserに送る
6. Userはデジタル証明書の公開鍵でデジタル証明書(2)を検証
   • 送られたデジタル証明書(2)は間違いなく認証局に認証されたWebサーバーから署名されたモノ
   • つまり、中間攻撃者がいないことを認証局を使って確認した
7. Userは自分のDH公開鍵(CL)を送る
8. DH公開鍵(CL/SV)により、UserとWebサーバーは共通鍵を生成
9. それを利用してメッセージを暗号化する

NOTE:

• CL = Client
• SV = Server

TSL SNIとは？

つのサーバーで1つしか使えなかったSSLサーバー証明書が、ドメイン名（URL）単位で利用できるようになる技術。

仕組みとしてはSSL通信時にドメイン名を通知することで、サーバー側がどのSSLサーバー証明書を利用すべきか判別する。

これによって、1台のサーバーでもドメイン名の数だけSSLサーバー証明書の利用が可能になり、URLが途中で変わってしまう心配や、SSLサーバー証明書ごとに別々のサーバーを用意するといった手間やコストの負担が軽減された。

暗号スイートとは

SSLは4種類の機能を組み合わせたハイブリット暗号技術。 英語で Cipher Suites と言い、TLSの暗号通信のためのプロトコルで複数の暗号化アルゴリズムの組み合わせのことを指す。

例

opensslで使われる暗号化スイートの一覧。

1
2
3
4
5
6
7

$ openssl ciphers -v 
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD

一番上を抜粋すると、

1
2

1                           2       3           4       5               6
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

番号で読み解くと次の意味

1
2
3
4
5
6
7
8

1.暗号化スイートの名前
  - ECDHE-RSA-AES256-GCM-SHA384 の箇所
1. SSLのバージョン
3. ECDHE : 鍵交換方式(Kx)を意味する
4. RSA : 鍵認証方式(Au)を意味する
5. AES256 : メッセージ暗号方式(Enc)を意味する
5. GCM : ブロック処理を意味する
5.6. SHA384 : メッセージ署名方式(Mac)を意味する

参考文献

• https://keita-blog.com/programming/security-common-open
• https://www.ipa.go.jp/security/pki/022.html
• https://www.ipa.go.jp/security/pki/022.html
• https://qiita.com/kunichiko/items/ef5efdb41611d6cf7775
• https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14234965664
• https://qiita.com/angel_p_57/items/30a12a0d45457b5f76d5
• https://www.ipa.go.jp/security/pki/022.html
• https://milestone-of-se.nesuke.com/nw-basic/tls/diffie-hellman-summary/
• https://it-trend.jp/encryption/article/64-0055
• https://milestone-of-se.nesuke.com/nw-basic/tls/diffie-hellman-summary/
• https://avinton.com/academy/creating-ssl-certificate-by-certbot/
• https://ssl.sakura.ad.jp/column/difference-in-ssl/
• https://www.securecore.co.jp/support/manual/csr_distinguish.php
• https://milestone-of-se.nesuke.com/sv-advanced/digicert/digital-certification-summary/
• https://milestone-of-se.nesuke.com/sv-advanced/digicert/digital-certification-summary/