下のこれ分かりますでしょうか。
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
qiitaのSSLで利用していた暗号スイートです。
SSLサイト評価してる方は、一度は、見たことあるんじゃないでしょうか。
ええ、なんとも長ったらしいですね。
この長ったらしく暗号にさえ見える羅列の意味がわからなかったのですが、DH(Diffie-Hellman)について興味を持ったところ、この長ったらしい意味が分かってきました。(とても奥深いです。)
※暗号スイートを分解してみるもので、最適な暗号スイートは何かとか、暗号の証明や安全性については書いていません。よってアリスとボブは出てきません。
暗号スイートの確認
firefox ならgoogle.comを開いて URL欄の左の鍵マーク→接続→詳細 をクリックすると出ます。
chromeなら右クリック検証からsecurityのconnectionを見るとそれらしいのが出てきます。(googleだとQUICKが使われるかも)
bashなら以下で見ることができます。
openssl ciphers -v
おもむろに分解
分解できるので、それぞれの意味を追っていきます。
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256を分解してみると、以下のようになります。
1.TLS
2.ECDHE
- 2.1 EC
- 2.2 DH
- 2.3 E
3.ECDSA
4.AES_128_GCM
- 4.1 AES128
- 4.2 GCM
5.SHA256
- SHA256
2.のECDHEとかはさらに分解できて、ECとDHとEに分解できます。
根本は、DH(Diffie-Hellman)ですが、まずはさくっと1.のTLSから見てみます。
1. TLS
セキュリティ通信のためのプロトコルの指定です。
バージョンまでは含まれないようで、おそらく1.2を使うことになると思います。
Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。 主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。 Wikipediaより
2.1 EC
ECとは何でしょうか。
これは、楕円曲線(Elliptic Curve)暗号から頭文字を取ったものでECの暗号を使いますって意味です。
楕円曲線暗号（だえんきょくせんあんごう、Elliptic Curve Cryptography: ECC）とは、楕円曲線上の離散対数問題 (EC-DLP) の困難性を安全性の根拠とする暗号。1985年頃に ビクタ・ミラー (Victor Miller) とニール・コブリッツ (Neal Koblitz) が各々発明した。 Wikipediaより
じゃあ、何にEC暗号を使うのでしょうか。次の2.2を見てみます。
2.2 DH(Diffie-Hellman key exchange)
でました DH。ざっくり言うと、秘密の通信したいときには、秘密の共通キーがあればいいよね。でもそのキーを共有するにはどうする？それにはDHを使うといいよ。です。どちらからも共通の秘密キーを送ることなく、共通の秘密キーを作ることができる仕組みです。すごいです。
ディフィー・ヘルマン鍵共有（ディフィー・ヘルマンかぎきょうゆう、Diffie-Hellman key exchange、DH）、あるいはディフィー・ヘルマン鍵交換（かぎこうかん）とは、事前の秘密の共有無しに、盗聴の可能性のある通信路を使って、暗号鍵の共有を可能にする暗号プロトコルである。この鍵は、共通鍵暗号方式の鍵として使用可能である。 Wikipeidaより
2.3 E(Ephemeral)
Eは、Ephemeralで、はかないとか、一時的なという意味です。
なんでこれが追加されたかというと、前方秘匿性(forward secrecy, perfect forward secrecy)と言って、交換した後に、そのキーが漏れたときに、過去のものまで影響が出ないようにするためです。
鍵交換したキーで通信するときに生成の元にランダムな数字を使います。そして、次の通信を行うときはそのキーを捨てて新たに生成したキーを使って通信を行います。
3.ECDSA
証明書に含まれる公開鍵。これで認証を行います。ECDSAの場合は、証明書の検証を行った後に証明書のDHパラメータを取り出して、共通かぎを作成するという順番になります。
4.1 AES_128
アプリケーション層の暗号化に使われる暗号化アルゴリズムです。作った共通鍵で暗号化を行います。
でも、ネットなどの通信の平文は長いですよね。その場合はブロック単位で区切って暗号化する必要があります。
その方法は4.2で指定します。
4.2 GCM
認証付き暗号。暗号化する際にどのサイクルで暗号化するかの方法を指定しています。
GCM では暗号化と同時に完全性や認証性も実現するための暗号方式となっています。
5. SHA256
最後に、暗号化したものをSHA256でハッシュ化して改竄されていないかを検証します。
終わりに
少しは長くなる意味が分かった気がしました。
TLS1.3になると楕円曲線暗号がメインになって、バリエーションは少なるなるでしょう。
実際に通信してみて検証できたら良かったのですが、まだそこまで行ってません。
参照
興味本位で探索していったので順不動です。
https://tools.ietf.org/html/rfc5246
https://ja.wikipedia.org/wiki/Transport_Layer_Security
https://tkengo.github.io/blog/2015/12/01/https-details/
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89
https://www.serotoninpower.club/archives/360
https://zoom-blc.com/what-is-ecdsa
https://rms.ne.jp/what-is-ssl-certificate/handshake.html
https://rms.ne.jp/howto/basis/forwardsecrecy.html
https://jovi0608.hatenablog.com/entry/20160524/1464054882
https://qiita.com/Brutus/items/1015cc01d2e1eb82a526
https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-2.0.pdf
http://kimh.github.io/blog/jp/security/understanding-pfs-jp/