TLSによる暗号化通信
エンジニアになりたての頃に書いた記事の転載で、TLSがどのように成り立っているのかについての概要記事となります。
インフラ構築の際に、ALBに証明書を持たせてHTTPS通信を行うようにするタイミングで、暗号化通信とは何か、どのように成り立っているのかについて疑問にもったことが書いたきっかけだったと思います。
SSL/TLSとは？
TLS(Transport Layer Security)とは、インターネット上で通信を暗号化して盗聴や改竄を防ぐプロトコルで、HTTP上に実装したHTTPSがよく知られています。
TLSによって暗号化を行わないと、平文のデータがネットワーク上を流れてしまい、盗聴や改竄等のリスクが生じます。
TLSはSSL(Secure Sockets Layer)の後継プロトコルであり、SSLの抱える脆弱性を改善したものです。SSLの名称が広く普及しているため、現在でもSSL/TLSという表記が使用されることもあります。
TLSを支える要素技術
TLSによる暗号化通信は共通鍵暗号方式と公開鍵暗号方式という2つの暗号方式によって実現しています。
これは、共通鍵暗号方式の処理速度を生かしつつ、抱える欠点を補うためです。
TLS暗号化通信の流れについて理解するために、まずはこれらの技術について見ていきます。
また、これらの鍵の考え方は様々なところで利用されているので、エンジニア初心者は覚えておくといいと思います。
共通鍵暗号方式(対称鍵暗号方式)
共通鍵暗号方式は、暗号化と復号化に同じ鍵(共通鍵)を使用する暗号化方式で、送信者と受信者が同じ共通鍵を利用して暗号化、復号化を行います。
共通鍵暗号方式では、暗号化と復号化に同じ鍵を使用するため、処理が(公開鍵暗号化方式に対して)高速ですが、事前に共有鍵を安全に共有する必要があります。(同じ鍵で復号化を行うので、鍵の漏洩によって復号される可能性がある)
そこで、TLSによる暗号化通信では共通鍵の共有に公開鍵暗号方式を利用します。
公開鍵暗号方式
公開鍵暗号方式とは、暗号化と復号化に異なる鍵を使用する方式です。
暗号化を公開鍵によって行い、復号化を秘密鍵によって行います。公開鍵で暗号化されたデータは対になる秘密鍵によってのみ復号できます。
公開鍵暗号方式では、公開鍵と秘密鍵のペアが生成されます。
公開鍵は一般に公開され、秘密鍵は自分だけが参照できるようにします。(秘密鍵が漏れてしまうと復号化が可能になり盗聴の危険なので、他人に絶対に漏れないようにしましょう！)
また、公開鍵から秘密鍵を類推することは非常に困難になっています。
ちなみに、TLSはTCP/IPにおけるアプリケーション層に位置付けられるプロトコルであり、TLSが暗号化するのはアプリケーション層のデータのみです。したがって、TLSより下位の層（トランスポート層、インターネット層、ネットワークインターフェイス層）のデータ自体はTLSでは暗号化されません。
TLSによる暗号化通信の流れ
上記の共通鍵暗号方式と公開鍵暗号方式を利用したTLS暗号化通信の流れは下記になります。(一派的にはロードバランサーに証明書を配置することが一般的ですが、ここでは簡単のためクライアント・サーバー間の通信を想定しています。)
- クライアントはTLS暗号化通信をリクエスト
- サーバーは、証明書(公開鍵を含む)を送付する
- クライアントは、証明書を検証し、公開鍵を取得する
- クライアントは共通鍵を生成し、サーバーの公開鍵で暗号化する
- サーバーの公開鍵によって暗号化された共通鍵をサーバーの秘密鍵で復号化する
- 共通鍵によって暗号化されたデータの通信を行う
HTTPSでは、クライアントをブラウザ(ChromeやSafari等)が担います。
このような通信の確立の流れをTLSハンドシェイクと呼びます。
こうして、公開鍵を利用することで、共通鍵(セッションキー)を安全に配送する問題を解決し、通信を暗号化することができます。
証明書
ここで証明書という言葉が出てきました。
証明書というと入学証明書といった特定の事実を証明する文書を思い浮かべると思いますが、ここでの証明書は、証明書の所有者(サーバー)がきちんとした第三者によってその信頼性が担保されていることを示すためものです。
この証明書を支える技術や仕組みとしては、デジタル署名やハッシュ、認証局といったものがあるので、そちらも解説したいと思います。
簡単にいうと、認証局という信頼できる第三者が証明書自体の信頼性を保証します。
デジタル署名とは？
公開鍵暗号方式を利用して、秘密鍵で署名し、公開鍵で署名の検証を行います。
これによって、「データの改ざん防止」「送信者のなりすまし防止」「事後否認」を実現することができます。
これは当初、公開鍵暗号方式の公開鍵で暗号化した電子文書を秘密鍵で復号化できるという性質を利用して、「本人だけが署名をできて(秘密鍵)誰でも署名を検証できる(公開鍵)仕組み」を作れないかという発想で考えられました。
デジタル署名には公開鍵暗号方式の考え方が利用されていますが、すべての公開鍵暗号方式が署名に適しているわけではありません。RSAのように暗号化と署名の両方に使える方式もあれば、署名専用に設計された方式もあります。
デジタル署名の流れ
- 送信データをハッシュ化
- ハッシュを「送信側の秘密鍵」で署名
- 証明されたハッシュ値をデータ本体と合わせて送信
- 受信側では、受信データを同じハッシュ関数でハッシュ化
- 「送信側の公開鍵」で署名されたハッシュ値を検証 -> なりすまし防止
- 4と5の値が一致 -> 改ざん検知
ハッシュ
ハッシュ関数によって任意のデータから固定長のハッシュ値を生成するプロセスのことをハッシュ化と呼びます。
ハッシュ関数は一方向関数であり、ハッシュ化されたデータから元のデータを計算することは困難です。
異なるデータから同じハッシュ値が生成される可能性(衝突可能性)は非常に小さくなっており、データの一部でも改ざんされていれば異なるハッシュ値が生成されます。そのため、ハッシュを使用することで、データの改ざんの有無を調べることができます。
また、一方向関数であるという性質から、パスワードの保存にも利用されます。(パスワードの検証は可能にしつつ、漏洩を防ぐことができる)
このように、デジタル署名では、「送られてきた公開鍵の持ち主がデータを送信してきたこと」「データが改竄されていないこと」は検証できますが、公開鍵の持ち主の正当性を検証することはできません。
認証局
公開鍵が特定の組織や個人に属していることを証明するために、証明書が使用されます。
このデジタル証明書は、認証局（Certificate Authority: CA）と呼ばれる信頼できる第三者機関によって発行されます。
認証局は、申請者の身元を確認した上で、公開鍵とその所有者情報にデジタル署名を行い、証明書として発行します。
これにより、他者は証明書を検証することで、公開鍵が正当なものであり、改ざんされていないことを確認できます。
認証局によるデジタル証明書の発行の流れ
- 申請者は、自身の公開鍵と**本人確認情報（氏名、ドメイン名など）**を、証明書発行の申請データとして認証局（CA）に提出する。
- 認証局は、提出された本人確認情報やドメインの所有権などを審査し、申請者の正当性を確認する。
- 認証局は、審査に合格した申請者の公開鍵と本人情報をひとつにまとめた証明書に対し、自身の秘密鍵でデジタル署名を行い、デジタル証明書を作成する。
- 認証局は、作成したデジタル証明書を申請者に発行・提供する。
認証局は階層構造になっており、最上位のルート認証局の下に中間認証局(複数になりえる)が存在しています。中間認証局の証明書は上位の認証局の署名を受けており、その上位の認証局の証明書はさらに上位の認証局の署名を受けており、証明書を辿っていくと最終的にはルート認証局へ行き着きます。このような証明書のチェーンのことを証明書チェーンと呼びます。
最終的には、ルート認証局の署名を検証する必要があるので、そのためには、ルート認証局の証明書（公開鍵）が必要になります。そのため、ルート証明書はWebブラウザ等に直接組み込まれています。
証明書の検証フロー
- サーバー証明書の署名を中間認証局の証明書(公開鍵)で検証する
- 中間認証局の署名をさらに上位の認証局の証明書(公開鍵)で検証する
- 最終的にルート認証局の署名をルート証明書で検証することで、サーバー証明書の正当性を検証する
ここでサーバーに認証局の証明書が設定されていない場合や、ルート認証局の認証局証明書がブラウザにインストールされていない場合、証明書チェーンの検証に失敗し、ブラウザのアドレスバーに赤や黄色の文字で警告が出ます。
Discussion