TLS & LURK @ IETF 95

Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS & LURK @ IETF 95
DeNA Co., Ltd.
Kazuho Oku
1

はじめに
 話者は暗号の専門家ではありません
 プロトコル実装はちょっとできる
⁃ H2O (HTTP/2)
 TLS「実装」のハックは多少したことがある
⁃ TLS 1.3は自分で実装するつもり
ツッコミお願いします m(__)m
2TLS & LURK @ IETF 95

TLS 1.3

TLS 1.3とは
 TLSの次期メジャーバージョン
⁃ 2016/5 WGLC (予定)
 主な変更:
⁃ Forward Secrecy (前方秘匿性)
⁃ より多くのデータを暗号化 (e.g. セッションID)
⁃ より高速なハンドシェイク (0-RTT / 1-RTT)
⁃ 脆弱性を産みにくい設計
• AEAD必須, 圧縮なし, リネゴシエーションなし, etc.
⁃ クライアント認証は、ハンドシェイク後に証明書の保
有証明として実現

Forward-secrecyとリザンプション
 TLS 1.2以前:
⁃ フルハンドシェイク (2-RTT)
⁃ リザンプション (1-RTT)
• 暗号鍵を使いまわし（正確にはTCP接続毎にFSでない）
 TLS 1.3:
⁃ フルハンドシェイク (1-RTT)
• 認証と暗号鍵の分離を強制 ((EC)DHE)
⁃ Pre-Shared Key (リザンプションに相当, 0-RTT)
• PSK+(EC)DHE: TCP接続毎の前方秘匿性(FS)を確保
• PSK-only: TLS 1.2以前と同様

0-RTT
 ハンドシェイク要求と同時にアプリデータ送信
 懸念点: アプリデータはリプレイ可能
⁃ 対策: アプリが気をつけて使う

TLS 1.3 @ IETF 95
 WGLCにむけた作業
⁃ (未成熟な) 部分を削る
⁃ 細かな改善
 資料
⁃ https://www.ietf.org/proceedings/95/slides/slide
s-95-tls-2.pdf
⁃ https://www.ietf.org/proceedings/95/minutes/mi
nutes-95-tls

ダウングレード攻撃の検知
 要件
⁃ クライアントは、自分が送信したTLSバージョンがを
話すサーバに正しく伝わったか検証したい
⁃ TLS 1.2以前でのハンドシェイク完了時にも、検出で
きる必要がある
 手法
⁃ バージョンを、ServerRandomのprefixとして送信
• “DOWNGRD01”
⁃ TLS 1.3サーバがTLS 1.2以前のクライアントとハンド
シェイクする場合

0-RTTハンドシェイクの整理
 撤回されたもの
⁃ クライアント認証 (0-RTT)
⁃ (EC)DHE
 残るもの
⁃ PSK
⁃ PSK-(EC)DHE
 要は
⁃ 共通鍵を交換済の場合だけ0-RTT可能にする

(EC)DHE 0-RTT撤回の影響とは?
 PSKが使えないケースが影響をうける
⁃ 今後もPSKなら0-RTTできるわけで…
 例: out-of-bandでの(EC)DHE鍵の配布
⁃ サーバのDNSレコードに(EC)DHE鍵を入れておく
• 初回接続から0-RTT
 撤回理由（のひとつ）:
⁃ out-of-bandで鍵を配布&revokeする現実的な手法の
欠如

0-RTTハンドシェイクに失敗した場合の挙動整理
 決まった手順
1. サーバがHelloRetryRequest送信
2. クライアントはearly-dataの末尾をalertでマーク
3. early-dataは全てなかったことにしてフルハンドシェ
イクを続行

0.5-RTT vs. リプレイ攻撃
 0.5-RTTとは
⁃ サーバがハンドシェイクとともに送るearly-data
 0.5 RTTを使いたいユースケース:
⁃ HTTP/2, SMTP, ...
 リプレイ攻撃が発生するケース:
⁃ PSK + client auth
 結論:
⁃ 0-RTT early-data同様、アプリが注意して使う

鍵の使い分け
 TLS 1.3ではハンドシェイクとアプリデータで異なる鍵を
使う
⁃ メリット: 権限分離可能
 問題: post-handshake messageをどう暗号化するか
⁃ post-handshake messageとは?
• NewSessionTicket, client-auth, KeyUpdate
⁃ 解決案:
• とりあえず復号して整合性確認
• ２重暗号化 ← 採用
• content-typeを書き戻す
⁃ 使う鍵は? → 専用の鍵を作ろう

鍵について整理しておくと…
 ２つのSecret
 SSとESから導出される鍵でメッセージを暗号化
⁃ handshake key, application key, post-handshake
key
⁃ Resumption Master Secretも同様に導出
 SSは0-RTTの暗号化に使用
Key Exchange Static Secret (SS) Ephemeral Secret (ES)
(EC)DHE (1-RTT) client & server ephemeral client & server ephemeral
PSK (0-RTT) pre-shared key pre-shared key
PSK+(EC)DHE (0-RTT) pre-shared key client & server ephemeral

他にあった議論
 対応する(EC)DHEのパラメータをサーバが告知したい
⁃ 「次からはこのパラメータを使ってほしいな」
⁃ supported_groups extensionを送ることが可能に
 TLS通信の改ざん不可能なモニタがほしい
⁃ KeyUpdateに受信通知をつければいい
⁃ 暗号鍵を更新後に古い鍵をモニタ装置に通知 → モニ
タは保存しておいた暗号文を解読
⁃ https://github.com/tlswg/tls13-spec/pull/426/
⁃ Status: parked

LURK
(Limited Use Remote Keys)

そもそものユースケース
 CDN (Content Delivery Network) の秘密鍵運用
 CDNは、世界各国に拠点を配置
⁃ そこから高速かつ安価にコンテンツの配信を代行
⁃ そのためにHTTPSを終端する
⁃ だが、秘密鍵の供託が必要な国もある
• 盗聴リスク????
 解決策:
⁃ 秘密鍵が必要な処理は、安全な拠点のサーバで行う
⁃ 安全じゃない拠点〜秘密鍵サーバは専用プロトコル
• これを標準化するのがLURK

他のユースケース
 コード署名の権利を委譲したい…

議論の焦点
 なんでも署名（暗号化）してしまう秘密鍵運用サーバの
存在意義って何？
⁃ 秘密鍵を供託してるのとリスクは大差ないのでは?
 そこを防ごうとすると、TLSプロトコル専用に、ハンドシ
ェイク部分を委譲する仕組みとならざるをえないのでは?
⁃ → WGのゴールって何なのさ？

おしまい

TLS & LURK @ IETF 95

More Related Content

What's hot

Viewers also liked

Similar to TLS & LURK @ IETF 95

More from Kazuho Oku

TLS & LURK @ IETF 95