TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS1.2での暗号スイートの一例ですが、なんでこんなにいくつもアルゴリズムを使う必要があるの？と思うわけです。しかも、ECDHEとECDSAとEdDSAなど用語が似ていたり、RSAは鍵交換と認証を両方やってしまったり、勉強している中でとても混乱してしまいそうです。

TLS1.2とTLS1.3の違いも含めて、自分なりにまとめて整理していきます。間違いがあればご指摘いただけると嬉しいです。

TLSで行われていること

以下の4つの視点でまとめていきます。仮にクライアントAがサーバBと安全ではない経路を使って安全に通信したいとします。

鍵交換
- Aは暗号化用の鍵を誰にも知られずBに伝えたい
認証（デジタル署名）
- AはBが本当にB本人であることを知りたい
暗号化
- Aは長いメッセージを誰にも知られずBに伝えたい
完全性の検証
- AはBから受け取った返信が改ざんされていないことを確認したい

TLS1.2の適当な暗号スイートを上記4つに当てはめると以下のようになります。

f:id:dorapon2000:20210404205740p:plain

なお、TLS1.3で暗号スイートと言うと「TLS_AES_128_CCM_SHA256」のように少し短くなっており、暗号化以降の部分が抜き出された形になります。TLS1.2では暗号スイートとして一緒くたになっていましたが、TLS1.3からそれぞれ別々に合意が取られます。

暗号化・完全性の検証

一番とっかかりやすいところは暗号化だと思います。共通鍵暗号で秘匿したいメッセージを暗号化するためのアルゴリズムです。

	種類	TLS1.2	TLS1.3*1
AES	ブロック暗号	o	o
3DES	ブロック暗号	o	x
RC4	ストリーム暗号	o	x
ChaCha20	ストリーム暗号	x	o

最も主流なのはAESで、TLS1.3でも引き続き採用されています。長いメッセージをブロックという単位で区切って暗号化するブロック暗号には、暗号利用モードというバリエーションがあります。ブロックを順々に暗号化する際、前のブロックをどう活用するかを決めます。

	完全制の検証	TLS1.2	TLS1.3*2
AES_XXX_CBC	x	o	x
AES_XXX_GCM (AEAD)	o	o	o
AES_XXX_CCM (AEAD)	o	o	o

CBCは秘匿用の暗号利用モードであり、完全制の保証には別途MAC (Message Authentication Code) の検証が必要でした。このMACの存在はBEAST攻撃など数多くの問題を引き起こすため、MACを使わないAEAD (Authenticated Encryption with Associated Data) のみがTLS1.3で許可されています。

鍵交換

次は、先のアルゴリズムでメッセージを暗号化/復号するための鍵を、安全に相手と共有する必要があります。もし、安全ではない経路中にそのまま鍵を流したりなんてしたら、攻撃者が鍵を盗み見る可能性があります。これを防止するのが鍵交換アルゴリズムです。

鍵交換アルゴリズムは小さいメッセージ（鍵）を暗号化して相手に送るので、要は暗号化アルゴリズムです。ただ、共通鍵暗号よりも安全だが計算コストが高い公開鍵暗号を利用します。

	TLS1.2	TLS1.3
RSA	o	x
DHE	o	o
ECDHE	o	o

RSAはこれまで長らく鍵交換アルゴリズムとして使われてきました。しかし、セキュリティを担保するために必要な鍵長が1024bit→2048bit (→3072bit) と増えており、計算コストも増加してしまいます。また、RSAは鍵を盗難されると過去のメッセージもすべて復号されてしまう欠点があります（PFSがない）。なので、TLS1.3ではDHEとECDHEだけをサポートします。

楕円曲線暗号

ECDHEはDiffie–Hellman鍵交換アルゴリズムを楕円曲線暗号で実現する鍵交換アルゴリズムです。RSAと比べて鍵長が短く、PFSがあります。

利用できる楕円はいくつか定義されており、その中から選びます

ECDHE	楕円曲線	TLS1.2	TLS1.3*3
secp256r1	P256	o	o
x25519	Curve25519	x	o
x448	Curve448	x	o

楕円曲円暗号の仕組みは以下の記事がシンプルでわかりやすかったです。

qiita.com

認証（デジタル署名）

鍵が安全に交換できて、暗号通信できるけど、本当に通信相手は正しいの？PKIをベースに署名アルゴリズムによって通信相手の認証を行います。

PKI (Public Key Infrastructure) は日本語で公開鍵基盤といい、一般に信頼された認証機関（CA）がサーバが本物であることを保証するという仕組みそのもの、暗号通信のインフラのことを指します。

大雑把な認証の流れは以下です。公開鍵を取得する手順にもなります。

サーバがCAから本物であることを証明する証明書を貰う（CAによる署名）
クライアントに証明書を送る
クライアントは証明書が本物か検証すると同時に、証明書からサーバの公開鍵を取得する

その署名アルゴリズムが以下です。

	TLS1.2	TLS1.3
DSA	oだが実質x	x
RSA	o	o
ECDSA	o	o
EdDSA	x	o

なぜ鍵交換に出てきたRSAがなぜ署名にもでてくるの！？という気持ちになりますが、 RSAが復号鍵でも暗号化できるという特殊な性質だからです。TLS1.3の署名でRSAが廃止されていない理由はわからないです。ハッシュをかませるからでしょうか。しかし、鍵長が長くなるにつれパフォーマンスが落ちる問題は依然としてあります*4。

ECDSAとEdDSAはどちらも楕円曲線を用いた署名アルゴリズムです。