常時SSLが叫ばれ、ついにhttpsじゃないサイトにアクセスするとブラウザに脅される時代になった。

そもそもhttpsとは何なのか、SSLとはなんなのか、TLSとの関係は？
ふんわりした知識をまとめてみた。

ただ暗号化しているだけじゃないあらゆるものを総動員している。

ブラウザからアクセスして表示されるまでに、こんなことをやっていたのか！改めてコンピュータとは凄いと思うだろう。

https、SSL、TLSの用語を改めて説明

httpsとは、セキュリティ機能がついたhttpだ。
httpだと誰かに見られるかもしれない。
盗み見るのは犯罪者とは限らない、学校や職場の監視システムやプロバイダ、国家の検閲とかもあるかもしれない。

それを防ぐのがhttps

SSLはセキュリティを求められる通信のために考えられたプロトコル（規格）で、TLSはSSLの次のバージョン。
昔はSSLと言っていて、今はTLSと言っているという、名前が変わっただけと思っても構わない。
昔からずっとSSLと言っている人もいれば、TLSと言い直す人もいる。
紛らわしいので、SSL/TLSと2つ付けてしまうパターンもある。

httpsはこのSSL/TLSの仕組みをhttp通信に組み込んでセキュア通信を実現している。

SSL/TLSとは？

簡単に言えばこのような、他人に見られないという通信だ。
だが、それだけの知識では不十分だ！！
なにが安全なのか？なんで安全なのか？どうやったら安全じゃなくなるのかを知らないと総TLS時代についていけないのだ！

まず主にTLSで何から守られるものはというと…

• 盗聴
• 改竄
• なりすまし

盗聴つまり盗み見だけ守っていると思っている人も多かったのではないか？
クレジットカードやパスワードを守る意図で導入するものだと思っている人もいるかもしれない。

でもそれだけではない。
途中で通信を書き換えることもできない。

URLを不正な手段で書き換えてニセサイトに送る手口でも、TLSであれば証明書を不正に使用することはできないので、なりすましは気付けるのだ。
※ただしhttpで通信していたり、似たURLで騙されたりするので、人がこういう知識を付けないと危ういところは当然ある。

基礎知識。暗号化のための鍵

鍵とはデータを暗号化するときのためのデータのこと。

コンピュータがやり取りをするデータは、文字だったり画像だったり映像だったりするけれども、コンピュータ内部では数値として扱われている。
だから数学的に計算が可能になっている。

それを類推が困難な計算方法で別の数値にするのが暗号化。
逆にその数値から元に戻すのが復号という。

鍵はその計算方法のための別の数値で、
超簡単な例えで言えば、
テストの点数を隠したいけれども友達同士とは話したいという人がいた場合、
54点が元のデータということになる。
友達同士の合意で31を掛けた数字で話し合うという約束をした。
1674が暗号化されたデータ。
31が鍵
1674÷31で54が求められるが、これが復号という処理になる。

鍵の種類 共通鍵

さっきの例の31とはまさにこの共通鍵で、暗号化と復号で同じ鍵を使う物が共通鍵と言われる物になる。

実際に通信をする際には、この鍵を交換する時が問題になる。

データは暗号化されても、鍵が漏れてしまえば誰だって簡単に暗号を解いてしまうことができてしまうのだ。

鍵の種類 公開鍵

公開鍵とは共通鍵の鍵交換の難しさを克服した方式

公開鍵と秘密鍵というそれぞれ対になる鍵が用意されている。

データは公開鍵で暗号化し、
暗号データを秘密鍵で復号することができる。

公開鍵 : 暗号鍵
秘密鍵 : 復号鍵

簡単に言い換えれば公開鍵は暗号用、秘密鍵は復号用に主に使われる。

公開鍵を使って、復号することはできない。
できるはできるが、処理時間が現実的な時間で終わらない様になっている。

というのも、コンピュータでも素数かどうかを判定するのは総当りでしかできなくて、その性質を利用して巨大な素数同士をかけ合わせたものを使用している。
これをコンピューターで計算しても現実的な時間で終わらない。
だが、コンピュータの進歩でいつかは解読できてしまうかもしれない。これについてはまた別の機会に話すとして、

現実的には復号が難しいので、公開鍵をバンバン人に見せても大丈夫なのだ。

だからそれを盗み見承知でバンバン送って、それを使って暗号化してもらうという方式が公開鍵だ。

TLSでは何方式？

公開鍵のほうが安全じゃん？と思われるかもしれないが、
共通鍵にも利点はある。
処理速度が早いということと、鍵が漏洩しなければ非常に強固な暗号なのだ。
現在共通鍵の主流のAESというプロトコルは、公開鍵方式のRSAより強固になっている。

なので、このように2つの方式を使うことにしている。

公開鍵で共通鍵の鍵を交換して、
通信データは共通鍵を使って暗号化してやり取りをするという方式だ。

公開鍵受け渡しの問題点

公開鍵は、見られても安全なので広く公開することができるが、なりすましには無力。

間に第三者が介入。公開鍵を渡す間はまだセキュアな通信じゃないので、上の絵のように偽物の鍵に差し替えられても全然わからない。

成り済ましから守るにはさらに別の仕組みが必要になってくる

データを要約するハッシュ

成り済ましを防止する具体的な手段を講じる前に、暗号とは別の仕組みが必要になる。

それがハッシュだ。メッセージダイジェストとも言う。

ハッシュとは、データを決まった長さの数値(ハッシュ値)に置き換える仕組みのことで、同じデータからは必ず同じハッシュ値になるようになっている。

逆にハッシュ値から元のデータに戻すことは不可能に近い。

ちょっとでも、1ビットでも違うデータでも、全然違うハッシュ値になるので、法則を探ることもできない。

ハッシュ値は同じ長さの値になるが、入れられる数値は無限の組み合わせがある。なので別のデータと同じハッシュ値になることもあるが、膨大な数の中のいずれかになるので、同じ値になることは確率的にほぼ無視できるほどのも。

データの中身を送らなくても符号として使える

たとえばファイルをお互い持っているけれども、同じものかどうかを調べるために、ファイルを送らなくても同じものかどうかを調べることができる。

一方が、ファイルからハッシュ値を作る。
もう一方が、受け取ったハッシュ値と自分が持っているファイルのハッシュ値を比較して、同じ値ならば同じファイルであるということが言える。

公開鍵のもう一つのワザ。秘密鍵で暗号化

成り済ましを防ぐためにはもう一つワザが必要だ。

公開鍵方式の暗号で別の使い方をする。

公開鍵 : 暗号鍵
秘密鍵 : 復号鍵
先程の説明ではこのように公開鍵が暗号化用の鍵であると言ったが、実は逆もできる。

秘密鍵で暗号化することができる。
するとそれを復号するには、ペアになる公開鍵でしかできない。

どっちも暗号化できるならば、どっちか好きな方を暗号鍵や公開鍵にすればいいと思われるかもしれないが、そうはいかない。
秘密鍵が分かれば公開鍵を作ることができる。
公開鍵からは秘密鍵は作れない。

この違いがあるから鍵のペアはそれぞれ役割が決まっている。

だが逆向きに秘密鍵で暗号化することで、公開鍵の持ち主が暗号化したものであるという証明ができる。

正しい鍵かどうか証明する証明書

さて、公開鍵を受け取ったときに本当に相手が送ってきたものかどうかを最終的に解決するにはどうするか。

それは認証局という権威を用意する。

認証局とは名前からして公的機関っぽいけれども、主に一般企業が多い。
場合によっては政府が行うものもあるらしい。
大手はデジサート、ちょっと前まではシマンテックがやっていたけれど色々あってデジサートに買収された。

そういう証明書を発行する企業が沢山ある。

仕組みは以下の図の通り。分かりづらいね。

1. サーバー管理者は、秘密鍵を生成する
2. CSRという証明書署名要求というファイルを作る。サーバーのドメインなどを入れる。CSRには公開鍵も含まれている。
3. CSRを認証局に送る
4. 認証局は送られた証明書要求の情報を正しいかどうかを確認する。
   企業の登記を確認するしっかりレベルのものもあれば、証明書要求に書かれたドメインの連絡先に連絡すれば申請者につながるかどうかという簡単なレベルの確認もある。
5. 認証局は、申請した情報で証明書を作るが、証明書の情報のハッシュ値を証明書に入れて置く。
6. その証明書を申請者に送る。

これで申請者が証明書を取得することができる。
これをhttpサーバーなどに導入して使う。

ちなみに、証明書は中間証明書というのも一緒に渡されてくる。
自分の証明書とルート証明書(認証局の証明書)を結ぶ途中の証明書で、
自分の証明書を中間証明書が署名して、中間証明書はルート証明書を署名しているという繋がりになっている。

こんどはそれをブラウザからアクセスした場合どうなるかを説明する

1. 認証局の証明書は元々ブラウザやOSなどにインストールされている。もしくは、自分がここが発行したところなら大丈夫だと思うルート証明書（認証局の証明書）をインストールしておく。
2. 利用者がブラウザにアクセスすると、サーバー証明書と中間証明書が送りつけられてくる。
   証明書には公開鍵が含まれている。
3. サーバー証明書の署名を中間証明書の公開鍵で復号する。
4. 復号したらハッシュ値が出るので、サーバー証明書の情報のハッシュ値を取って比較をする。
5. 同じハッシュ値ならばサーバー証明書は中間証明書に署名されていると証明できる。
6. 中間証明書も同じ手順で、ブラウザに元々あるルート証明書で署名を検証する。
7. すべて検証できたら、サーバー証明書はブラウザに元々ある権威ある企業団体がちゃんと審査をして発行した証明書だということが証明される。
8. 証明書に書かれているドメインと、アクセスしようとしているドメインが一致しているならば正しい公開鍵を持っている証明書だと証明される。

このような手順を踏んで、サーバーの公開鍵が正しいと言える。

これで公開鍵が偽物ではないと信じることができるので、
安心して共通鍵を交換することができる。

まだまだ深い世界へ

今回は、暗号化するための鍵をどのように交換するか、
そのために相手が正しい通信相手かどの様に証明するかということを中心に説明した。

これで通信は安全に暗号化できたと思われるかもしれないが、
今は最新のセキュリティでもいつかは廃れてしまう。

未来永劫安全なのか？

たとえば、鍵交換には危険が潜んでいる。

公開鍵で暗号化されたデータを不正に解読するには、非常に長い計算をしなければならないと言うことが安全性の根拠になっている。

だがそれはいつまで続くのだろうか。

通信データを暗号化されたまま盗聴して、何年も保存しておいて、いつか凄いマシンのおかげで復号できたらどうする？

すると、共通鍵が解読できてしまう。

共通鍵が解読できればあとは通信は丸見えだ。

解読されたデータが賞味期限切れの古いデータだったら問題はない。
有効期限の切れたカード番号とかかもしれない、
でもそうじゃないかもしれない。
マイナンバーかもしれない。
未来永劫知られたくない個人情報かもしれない。

未来においても安全に保たなければならない情報のために
今の鍵交換方式はもっと複雑にしている。

楕円曲線ディフィーヘルマン鍵共有というかっこいい名前の方式だ。

これは後日まとめるつもりだ。

TLSだからといって完全に安全ではない。
古い方式をそのまま使ったりすると危険なのだ。