読者です 読者をやめる 読者になる 読者になる

i remember nothing

文章の練習も兼ねています

プロフェッショナルSSL/TLS 2.3-2.12 章

2.3.1 RSA 鍵交換

  • クライアントが48byteの乱数を生成し,それをサーバの公開鍵で暗号化して* * ClientKeyExchange * に入れて送信する。 このメッセージを複合することでサーバはプリマスターシークレットを手に入れられる。 TLSで利用されるRSAの暗号化スキームは RSAE5-PKCS1-v1_5 という。これは RFC 3447 で規定されている。

  • RSA 鍵交換の簡潔さは欠点にもなりうる。将来的に盗聴されるとそれでセッションを乗っ取られてしまう。永続化されたマスターシークレットを使っているからだ。

    • いったん鍵が漏れると過去の通信も全て復号されてしまう。

2.3.2 Diffie-Hellman 鍵交換

  • 安全でない通信路を介して二者間で秘密を共有するためのアルゴリズム。以降、DH鍵交換と省略。

  • これに対してDHE, * Ephemeral Diffie Hellman * という鍵交換方式が使われる。この方式の場合前回のDH鍵交換で用いたパラメータは再利用されない。

サーバ側は以下のパラメータを送る。

struct {
  opaque dh_p;
  opaque dh_g;
  opaque dh_Ys;
} ServerDHParams;

対してクライアント側は自身のパラメータのうち公開するものを返却する。

struct {
  select (PublishValueEncoding) {
  case implicit:
  case explicit:
  } dh_public;
} ClientDiffieHellmanPublic;

現在の DH 鍵交換の方式には以下のような問題がある。

  • DH パラメータのセキュリティ
  • DH パラメータのネゴシエーション
  • 不十分な鍵強度
    • 弱い鍵強度を用いているサーバも珍しくない
    • 2015年にはLogjam攻撃により512bitのDHパラメータはリアルタイムで破られることがわかった。

2.3.3 楕円曲線 Diffie-Hellman 鍵交換

  • ECDHE (ephemeral elliptic curve Diffie-Hellman)
  • ある特別な楕円曲線を用いる。この曲線がDHのドメインパラメータ的な役割を担う。

  • TLS サーバは自身が選んだ楕円曲線とECポイントというパラメータを渡す。

    • TLS でサーバが指定するのは named curve (名前付き曲線)
  • これを受けてクライアントは自身の公開パラメータを渡し,プリマスターシークレットを計算する。
  • クライアントが対応する曲線を送信するにはTLS拡張のelliptic_curvesを用いる。 利用できる名前付き曲線については後ほど出てくるらしい。

2.4 認証

  • TLS ではコストのかかる暗号処理を何度もしなくていいように認証と鍵交換が一体になっている。TLSの認証は公開鍵暗号方式が基本。
  • 一回証明書が検証されればクライアントの利用できる公開鍵を入手できたことになる。
    • RSA による鍵交換ではクライアントのみ鍵交換に関与する。クライアントが動的に生成したプリマスタシークレットをサーバの公開鍵で暗号化してサーバに送信する。
    • DHE, ECDHE による鍵交換ではサーバも鍵交換に関与する。サーバの秘密鍵で署名したパラメータを用い,クライアントはこの秘密鍵に対応する公開鍵を検証した証明書から入手する。

2.5 暗号化

2.5.1 ストリーム暗号化方式

  • 暗号化を2段階で行う。
  • sequence 番号, Record ヘッダ,平文データを結合したものの MAC を計算する。
 +----------------+---------+----------------+
 | シーケンス番号   |  ヘッダ   |    ===平文 ===   |
 +----------------+---------+-----------------+

  --認証-->

 +----------+---- ------+
 | ==平文 ==| == MAC == |
 +----------+----------+


  --暗号化-->

 +--------+------------------+
 |  ヘッダ   | ==== 暗号文 === |
 +--------+------------------+

2.5.2 ブロック暗号化方式

  1. シーケンス番号, Record ヘッダ, 平文データの MAC を計算する
  2. 暗号化する前のデータの長さがブロックの長さの整数倍になるようにパディングする
  3. 暗号化ブロックと同じ長さで Initialization Vector を生成する。コレにより同じ平文でも異なる暗号文になる。
  4. 平文, Mac, padding を CBC モードで暗号化する
  5. IV と暗号文を一緒に送信する

  6. no-padding で MAC を計算しており,そのためパディングオラクル攻撃の余地あり。

    • この攻撃に対して現在の実装に明らかな脆弱性は判明していないが不安な部分である。

2.5.3 AEAD

  • 認証付き暗号

    • ストリーム暗号化方式とブロック暗号化方式の折衷案
  • nonce という値を用いる。

  • 64 bit の nonce を作る

  • 平文データをAEADのアルゴリズムで暗号化する。同時にシーケンス番号とRecordヘッダも渡す。
  • nonce と暗号文を合わせて送信する

  • AEAD は MAC-then-Encrypt の問題を回避できるので現在TLSで利用できる最良の暗号化利用モードである。

    • TLS の認証方式の選択肢として現在 GCM, CCM モードが規定されているが,実際に対応しているのは GCM のみである。
    • 新しい暗号スイートとして,ChaCha20ストリーム暗号化方式に基づくものが標準化されつつある段階。

2.6 再ネゴシエーション

TLS接続ではやりとりの終了後再ネゴシエーションが要求された場合,新しい接続のセキュリティパラメータについて合意するために,改めてハンドシェイクを行う。

  • クライアント証明書
  • 情報の隠蔽
  • 暗号化の強度の変更
  • SGC(Server-Gated Crypto)
    • 選択的に強い暗号技術を利用するための機能
    • 特殊な証明書がある場合のみ強い暗号方式に格を上げることが出来る。
    • 暗号技術の輸出規制が緩和された影響でSGCは廃れた
  • TLS Record Counter の Overflow
    • TLS ではデータをレコードとして細切れにする。
    • やり取りを続けるうちにこのシーケンス番号は増えていく
    • シーケンス番号が溢れそうになったら再ネゴシエーションすれば良い
      • 現実的には,カウンタは非常に大きい数なので,オーバーフローすることはまず無い

2.7 Application Data プロトコル

名前の通り,アプリケーションのデータを運ぶ。

TLSでは単なるデータのBufferとして機能する。

Recordプロトコルのレイヤで細分化や暗号化が行われる。

2.8 Alert プロトコル

  • 通信中の相手に例外的な状況を伝える簡潔な通知の仕組み
  • Error メッセージや close_notify など
struct {
  AlertLevel level;
  AlertDescription description;
} Alert;
  • AlertLevel は warning, fatal など
  • AlertDescription は単純にコード番号がはいる
    • 俗に言うエラーメッセージのように任意の情報を入れる機能は存在しない!!

2.9 接続を閉じる

  • Alert で close_notify を送信する。
    • このアラートを受け取ったら,書き込み中の内容を破棄して自身のclose_notifyを送信する。このあと届いたメッセージはすべて無視する。
  • 強制切断攻撃を防ぐためのもの

2.10 暗号処理

PRF という擬似暗号生成器が使われる

2.10.1 擬似乱数生成器

  • PRF : 擬似乱数生成器
  • TLS1.2 ではHMACとSHA256によるPRFを用いる
  • TLS1.2では,P_hashというデータ拡張に基づいたPRFが規定されている
P_hash(sec, seed) = sum{n = 1..k}(HMAC_hash(sec, A(k) + seed)}

A(0) = HMAC_hash(sec, seed)
A(i) = HMAC_hash(sec, A(i-1)) :: i > 0

2.10.2 マスタシークレット

master_secret = PRF(pre_master_secret, "master_secret", client_random + server_random)

2.10.3 鍵生成

key = PRF(master_secret, "key_expansion", server_random + client_random)

2.11 暗号スイート

暗号スイートは以下のような説明的な名前になっている

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • 鍵交換方式 e.g. ECDHE, DHE, RSA
  • 認証 e.g. RSA, ECDSA
  • アルゴリズム e.g. AES, 3DES
  • 長さ e.g. 128
  • MACまたはPRF e.g. SHA256

2.12 拡張

様々な拡張タイプについて,IANA が定義している:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Extention extentions;

struct {
  ExtentionType extension_type;
  opaque extension_data;
} Extention;