Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TLS & LURK @ IETF 95

2,042 views

Published on

IETF報告会(5/10資料)

Published in: Internet
  • /.DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... /.DOWNLOAD PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • A really good presentation from Kazuho, as usual, a must read!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

TLS & LURK @ IETF 95

  1. 1. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. TLS & LURK @ IETF 95 DeNA Co., Ltd. Kazuho Oku 1
  2. 2. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. はじめに  話者は暗号の専門家ではありません  プロトコル実装はちょっとできる ⁃ H2O (HTTP/2)  TLS「実装」のハックは多少したことがある ⁃ TLS 1.3は自分で実装するつもり ツッコミお願いします m(__)m 2TLS & LURK @ IETF 95
  3. 3. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. TLS 1.3 3TLS & LURK @ IETF 95
  4. 4. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. TLS 1.3とは  TLSの次期メジャーバージョン ⁃ 2016/5 WGLC (予定)  主な変更: ⁃ Forward Secrecy (前方秘匿性) ⁃ より多くのデータを暗号化 (e.g. セッションID) ⁃ より高速なハンドシェイク (0-RTT / 1-RTT) ⁃ 脆弱性を産みにくい設計 • AEAD必須, 圧縮なし, リネゴシエーションなし, etc. ⁃ クライアント認証は、ハンドシェイク後に証明書の保 有証明として実現 4TLS & LURK @ IETF 95
  5. 5. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 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以前と同様 5TLS & LURK @ IETF 95
  6. 6. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 0-RTT  ハンドシェイク要求と同時にアプリデータ送信  懸念点: アプリデータはリプレイ可能 ⁃ 対策: アプリが気をつけて使う 6TLS & LURK @ IETF 95
  7. 7. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 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 7TLS & LURK @ IETF 95
  8. 8. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. ダウングレード攻撃の検知  要件 ⁃ クライアントは、自分が送信したTLSバージョンがを 話すサーバに正しく伝わったか検証したい ⁃ TLS 1.2以前でのハンドシェイク完了時にも、検出で きる必要がある  手法 ⁃ バージョンを、ServerRandomのprefixとして送信 • “DOWNGRD01” ⁃ TLS 1.3サーバがTLS 1.2以前のクライアントとハンド シェイクする場合 8TLS & LURK @ IETF 95
  9. 9. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 0-RTTハンドシェイクの整理  撤回されたもの ⁃ クライアント認証 (0-RTT) ⁃ (EC)DHE  残るもの ⁃ PSK ⁃ PSK-(EC)DHE  要は ⁃ 共通鍵を交換済の場合だけ0-RTT可能にする 9TLS & LURK @ IETF 95
  10. 10. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. (EC)DHE 0-RTT撤回の影響とは?  PSKが使えないケースが影響をうける ⁃ 今後もPSKなら0-RTTできるわけで…  例: out-of-bandでの(EC)DHE鍵の配布 ⁃ サーバのDNSレコードに(EC)DHE鍵を入れておく • 初回接続から0-RTT  撤回理由(のひとつ): ⁃ out-of-bandで鍵を配布&revokeする現実的な手法の 欠如 10TLS & LURK @ IETF 95
  11. 11. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 0-RTTハンドシェイクに失敗した場合の挙動整理  決まった手順 1. サーバがHelloRetryRequest送信 2. クライアントはearly-dataの末尾をalertでマーク 3. early-dataは全てなかったことにしてフルハンドシェ イクを続行 11TLS & LURK @ IETF 95
  12. 12. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 0.5-RTT vs. リプレイ攻撃  0.5-RTTとは ⁃ サーバがハンドシェイクとともに送るearly-data  0.5 RTTを使いたいユースケース: ⁃ HTTP/2, SMTP, ...  リプレイ攻撃が発生するケース: ⁃ PSK + client auth  結論: ⁃ 0-RTT early-data同様、アプリが注意して使う 12TLS & LURK @ IETF 95
  13. 13. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 鍵の使い分け  TLS 1.3ではハンドシェイクとアプリデータで異なる鍵を 使う ⁃ メリット: 権限分離可能  問題: post-handshake messageをどう暗号化するか ⁃ post-handshake messageとは? • NewSessionTicket, client-auth, KeyUpdate ⁃ 解決案: • とりあえず復号して整合性確認 • 2重暗号化 ← 採用 • content-typeを書き戻す ⁃ 使う鍵は? → 専用の鍵を作ろう 13TLS & LURK @ IETF 95
  14. 14. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 鍵について整理しておくと…  2つのSecret  SSとESから導出される鍵でメッセージを暗号化 ⁃ handshake key, application key, post-handshake key ⁃ Resumption Master Secretも同様に導出  SSは0-RTTの暗号化に使用 14TLS & LURK @ IETF 95 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
  15. 15. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 他にあった議論  対応する(EC)DHEのパラメータをサーバが告知したい ⁃ 「次からはこのパラメータを使ってほしいな」 ⁃ supported_groups extensionを送ることが可能に  TLS通信の改ざん不可能なモニタがほしい ⁃ KeyUpdateに受信通知をつければいい ⁃ 暗号鍵を更新後に古い鍵をモニタ装置に通知 → モニ タは保存しておいた暗号文を解読 ⁃ https://github.com/tlswg/tls13-spec/pull/426/ ⁃ Status: parked 15TLS & LURK @ IETF 95
  16. 16. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. LURK (Limited Use Remote Keys) 16TLS & LURK @ IETF 95
  17. 17. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. そもそものユースケース  CDN (Content Delivery Network) の秘密鍵運用  CDNは、世界各国に拠点を配置 ⁃ そこから高速かつ安価にコンテンツの配信を代行 ⁃ そのためにHTTPSを終端する ⁃ だが、秘密鍵の供託が必要な国もある • 盗聴リスク????  解決策: ⁃ 秘密鍵が必要な処理は、安全な拠点のサーバで行う ⁃ 安全じゃない拠点〜秘密鍵サーバは専用プロトコル • これを標準化するのがLURK 17TLS & LURK @ IETF 95
  18. 18. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 他のユースケース  コード署名の権利を委譲したい… 18TLS & LURK @ IETF 95
  19. 19. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 議論の焦点  なんでも署名(暗号化)してしまう秘密鍵運用サーバの 存在意義って何? ⁃ 秘密鍵を供託してるのとリスクは大差ないのでは?  そこを防ごうとすると、TLSプロトコル専用に、ハンドシ ェイク部分を委譲する仕組みとならざるをえないのでは? ⁃ → WGのゴールって何なのさ? 19TLS & LURK @ IETF 95
  20. 20. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. おしまい 20TLS & LURK @ IETF 95

×