セキュリティ / 技術全般

こんにちは、いからしです。

最近はアレですね。テレビをつけてもネットを見ても、暗号スイートの話で持ちきりですね。

同僚とのランチも友人との飲み会も、隙さえあれば暗号スイートの話になります。兎にも角にも暗号スイート、一家に一台暗号スイート。

もはや暗号スイートなしでは生活が成り立たない有様です。大変な時代になりました。

 

 

 

…はい、すみません嘘です。

最近ちょっとHTTPS通信の仕組みを掘り下げる機会がありまして、そのときに今までフワっとしてた暗号スイートの知識を整理したのでブログに書いてみたくなったのです。

ということで今日は暗号スイートについて書きます。

内容は

  • 暗号スイートとは何か
  • 暗号スイートはどのように利用されるのか
  • SSL/TLSプロトコルはどのようにデータを暗号化するのか

あたりです。

 

暗号スイートってなーに？

そもそも皆さん暗号スイートって知ってます？

「スイート」は「sweet」じゃなくて「suite」です。「一揃い」とか「ひと組み」という意味ですね。

なので暗号スイートってのは複数の暗号化アルゴリズムの組み合わせのことです。

 

え？暗号化アルゴリズムっていくつもあるのかって？

お前ちょっと新人研修からやり直s そうなんです、暗号化アルゴリズムってのはいくつも種類があるんです。

一例を挙げると

共通鍵方式のもの

  • DES
  • 3DES
  • MD5
  • AES
  • AEAD

公開鍵方式のもの

  • DH
  • ECDSA
  • ECDH
  • RSA

とかとか。

 

暗号とはそのアルゴリズムがどんなにイケていても、暗号化したいデータそのものだけで暗号化すると、どのアルゴリズムで暗号化したかがバレた瞬間に複合化されてしまいます。

その暗号化アルゴリズムの逆を行えばいいだけですからね。

 

そのためほぼ全ての暗号化アルゴリズムでは、暗号化時に鍵と呼ばれるセキュアな文字列を暗号化したいデータに含め、その鍵を知っている者にしか複合化できないようにしています。

メジャーな暗号化アルゴリズムには、暗号化側と複合化側で同じ鍵を利用する共通鍵方式と、別々の鍵を利用する公開鍵方式の2つがあります。

以降の話は共通鍵方式と公開鍵方式がわかっていないと理解が難しいので、そこに自信がないという人は首を洗って出直しt 下記のサイトあたりを参考に知識を補強してから戻ってきてください。

https://www.infraexpert.com/study/security4.html

 

さて、話を続けます。

複数の暗号化アルゴリズムをどのように一揃えとして定義するのかというと、こんな感じです。

何のこっちゃって感じですね。1つずつ見ていきましょうか。

 

暗号スイートの定義はスペースで区切られた6つの要素がそれぞれ別の意味を持っています。

左から順に概要を説明します。

  1. (ECDHE-RSA-AES256-GCM-SHA384) 暗号スイートの名前。
  2. (TLSv1.2) 暗号スイートが利用されるSSL/TLSプロトコルのバージョン。
  3. (Kx=ECDH) SSLハンドシェイク時、通信内容の暗号化に利用する共通鍵自体を暗号化します。そのときに利用する暗号化方式です。KxはKey Exchange(鍵交換)の略。
  4. (Au=RSA) クライアントがサーバ認証を行う際、サーバ証明書に付随するデジタル署名を複合化します。そのときに利用する複合化方式です。AuはAuthentication(認証)の略。当然、認証局が署名(暗号化)した際のアルゴリズムと一致している必要があります。
  5. (Enc=AESGCM(256)) 暗号化したい通信データ自体の暗号化方式です。ここで指定した暗号化方式 + 鍵交換した共通鍵でデータの暗号化と複合化を行います。EncはEncryption(暗号化)の略。
  6. (Mac=AEAD) 暗号化した通信データの改ざん検証に使われるハッシュ方式です。MacはMessage Authentication Code(メッセージ認証コード)の略です。

はい、ワラワラ概要を書きましたがコレだけだとなんだかよくわかりませんね。

 

とりあえず今の段階では上記の暗号スイートを見たときに「ECDHE-RSA-AES256-GCM-SHA384って名前の暗号スイートはTLSv1.2プロトコルで利用できて、鍵交換のときにECDH、サーバー認証のときにRSA、データの暗号化にAESGCM(256)という暗号化アルゴリズムを使って、データの改ざんチェックにAEADというハッシュアルゴリズムを使うんだな」というのが読み取れればOK。

これが何を意味しているのかを理解するために、ここからはSSL/TLSハンドシェイクの流れに沿って暗号スイートの使われ方を説明していきます。

 

SSL / TLSハンドシェイク

SSL/TLSはデータを暗号化してセキュアに通信するためのプロトコル。このプロトコルでは暗号化したいデータを共通鍵で暗号化・複合化します。

共通鍵はクライアント側で生成するんですが、当然何も考えないとコレをサーバー側へ共有する際に盗まれてしまう可能性がありますね。

そこでSSL/TLSでは共通鍵自体を公開鍵方式で暗号化して、共通鍵をセキュアに共有します。そのフローをSSL/TLSハンドシェイク、サーバーとクライアントで共通鍵を共有することを鍵交換と呼びます。

 

フローの概要は下記の図の通りです。

この絵の下から3つ目、サーバー側からの(Finished)までがハンドシェイクのフローです。

ここまででセキュアな共通鍵共有が完了し、以降(Application Data)はその鍵を使った暗号通信ができるようになります。

どんなにアレなサイトを閲覧しようが画像をダウンロードしようが、第三者にその内容は漏れません。素敵ですね。(ネットワーク管理者に接続先のIPはバレますけど)

 

鍵交換時とサーバー認証時には公開鍵・秘密鍵を利用するので、暗号化アルゴリズムは公開鍵方式です。つまりKxとAuは常に公開鍵方式の暗号化アルゴリズムになります。

また通信したいデータ自体は鍵交換した共通鍵を使って行われます。なのでEncは常に共通鍵方式の暗号化アルゴリズムになります。

 

ちなみにあまり話をややこしくしたくないのですが、誤解を生みたくもないのでいくつか補足があります。

  • このフローはTLS1.2までのもので1.3はこれとは少し異なるフローになっています。ただ暗号スイートを利用することに変わりはありません。
  • Kxが今回の様にRSAである場合、サーバーが事前に鍵ペアを作成して公開鍵をサーバ証明書に付与します。クライアント側はその公開鍵を利用して共通鍵を暗号化するため、上絵の上から4つ目、ServerKeyExchangeでは特にすることがありません。しかしKxがECDHEなどの一時鍵を利用するものである場合、ここで一時的に作成した公開鍵を送信することになります。が、やはり話がややこしくなるため今回は省略します。
  • 今回のフローではクライアント証明書を利用していません。これを利用するのはサーバー側が特定のクライアントとしか通信を行いたくない場合です。事前にサーバー側でクライアント証明書を生成し、それを対象のクライアントに共有しておきます。ハンドシェイク時にサーバーからクライアント証明書を要求、それに対してクライアントはクライアント証明書を送信、という形で通信を許可されたクライアントであることを確認します。

 

終わりに

さて、これを熟読した皆さんはもう暗号スイートマスターです。心置きなく暗号スイートと戯れてください。暗号スイートの心の声を聞いてください。

しかしさらに一歩先、実際に使われる暗号化アルゴリズムにも興味が湧いてきませんか？湧いてきますよね、わかります。

ということで、本当はその辺りのことも書きたかったんですが、PSYCHO-PASS 3期が待ち遠しすぎて思ったように時間が取れないのでまたの機会に。

 

一応書こうと思ったことだけをまとめておきます。そうすると他のoliva社員が書いてくれるかもしれない。きっとそうに違いない。

  • ブロック暗号とストリーム暗号
  • ブロック暗号の暗号モード
  • ストリーム暗号の議事乱数列生成機
  • 暗号アルゴリズムの歴史

 

ではこの辺で。