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.

WebRTC is secure, or not secure? - WebRTC セキュリティ概説 -

8,807 views

Published on

WebRTC Meetup Tokyo #6にて発表したスライドで、
WebRTCのセキュリティについて、
実際のコールフローに沿っての概説。

Published in: Technology
  • Be the first to comment

WebRTC is secure, or not secure? - WebRTC セキュリティ概説 -

  1. 1. WebRTC is secure, or not secure? -WebRTC セキュリティ概説- WebRTC Meetup Tokyo #6 @iwashi86 1
  2. 2. ●Attribute ・Name -> Yoshimasa IWASE ・Twitter -> @iwashi86 ・Web -> iwashi.co ●Work @ NTT Communications ・SkyWay(WebRTC)の裏側の開発 ・HTML5 Experts.jpというWebメディアの編集 ●Recently ・SkyWayでTURNトライアルを開始しました! 2
  3. 3. 今日のお話 WebRTCのセキュリティ 3
  4. 4. WebRTCって安全! 4
  5. 5. WebRTCって安全! ホント? 考えたことありますか? 5
  6. 6. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと 6
  7. 7. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと 7 Secureって書いてあるSecureって書いてある
  8. 8. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと 8 Secureって書いてあるSecureって書いてある どこ暗号化?
  9. 9. ざっくり通信フローで ちょっと考えてみよう 9
  10. 10. Webサーバ STUNサーバ TURNサーバ HTML/JS/CSS をDL Signalingサーバ WebRTCアプリをWebサーバから落とす 10
  11. 11. Webサーバ STUNサーバ TURNサーバ 己のグローバル IP/Portを知る Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからSTUNに問合せ。STUNとTURNは同じサーバでもOK。 発信前にSTUNへ問合せ 11
  12. 12. Webサーバ STUNサーバ TURNサーバ 直接接続できない場合に使う TURNサーバのアドレスを取得 Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからTURNに問合せ 発信前にTURNにも問合せ 12
  13. 13. Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 Signalingサーバ シグナリングで必要な情報交換 13
  14. 14. Webサーバ STUNサーバ TURNサーバSignalingサーバ 音声・映像を接続開始 注:接続開始前にはICEで頑張ってホールパンチングする P2Pでメディア(音声・映像)接続する 14
  15. 15. Webサーバ STUNサーバ TURNサーバSignalingサーバ 注:接続開始前にはICEで頑張ってホールパンチングする またはTURN経由でメディア接続する 15
  16. 16. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data SRTP × DTLS は どこを暗号化? 16
  17. 17. Webサーバ STUNサーバ TURNサーバSignalingサーバ 暗号化対象 暗号化されるのはメディアのみ 17
  18. 18. 暗号化対象 Webサーバ STUNサーバ TURNサーバSignalingサーバ その他の経路はWebRTCアプリ側で面倒をみる (∵WebRTCにおいて、シグナリングは未規定なので当たり前?) 18補足:STUNは、用途によってはセキュリティをあまり考慮しないこともある
  19. 19. 暗号化対象 Webサーバ STUNサーバ TURNサーバSignalingサーバ その他の経路はWebRTCアプリ側で面倒をみる (∵WebRTCにおいて、シグナリングは未規定なので当たり前?) 19補足:STUNは、用途によってはセキュリティをあまり考慮しないこともある しかもセキュリティって 色々な要素がありますよね?
  20. 20. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると 20 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性
  21. 21. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると 21 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える
  22. 22. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると 22 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと
  23. 23. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると 23 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと 安全にサービス提供するには 色々考えないとイカン!
  24. 24. そこで、本セッションでは、 WebRTCアプリに対する 攻撃とその対策について紹介 (特にWebRTCアプリの開発者向けに) 24
  25. 25. 25 本題の前に基礎知識 SSL/TLS について (今日よく出てくるので)
  26. 26. SSL/TLSとは 26 TCPレイヤの上で動作し、以下の機能を提供する: • 認証 • 相手が本物か確かめられる • 暗号化 • 盗聴しても分からなくなる • 改ざん検出 • 経路途中で書き換えられていないか検出できる
  27. 27. 27http://upload.wikimedia.org/wikipedia/ja/6/64/SSL%E3%81%AB%E3%82%88%E3%82%8B%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%81%AA%E9%80%9A%E4%BF%A1.jpg SSL/TLSのフロー
  28. 28. 28 では本題
  29. 29. 今日のスコープ ⇒ 主に音声/映像 29 DTL Securi ty IP UDP DTLS Secure RTP SCTP Audio/Video Data
  30. 30. お話の流れ シンプルな通信フローに ツッコミを入れていこう 30
  31. 31. Webサーバ STUNサーバ TURNサーバSignalingサーバ まず最初のダウンロード 31
  32. 32. Webサーバ STUNサーバ TURNサーバSignalingサーバ まず最初のダウンロード 32 本当に信じていいWebサーバ?
  33. 33. Webサーバ STUNサーバ TURNサーバSignalingサーバ まず最初のダウンロード 33 本当に信じていいWebサーバ? SSL/TLS で証明しよう!
  34. 34. Webサーバ STUNサーバ TURNサーバ セキュアさは比較的重要視されないのでスルー (単にグローバルIP/Portを調べる動作なので) ただし、STUNのRFC5389で規定される以下 の技術要素は知っておくべき: ・long term credential ・short term credential (こっちはほぼ不要) Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからSTUNに問合せ。STUNとTURNは同じサーバでもOK。 お次はSTUN 34
  35. 35. RFC5389より 35
  36. 36. RFC5389より 36 同じCredentialを「長期間」使う仕組み
  37. 37. RFC5389より 同じCredentialを「長期間」使う仕組み 「一時的」なCredentialを使う仕組み 37
  38. 38. RFC5389より 同じCredentialを「長期間」使う仕組み (WebRTCは、こっち) 「一時的」なCredentialを使う仕組み 38
  39. 39. Webサーバ STUNサーバ TURNサーバSignalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからTURNに問合せ 発信前にTURNにも問合せ 39
  40. 40. Webサーバ STUNサーバ TURNサーバSignalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからTURNに問合せ そのTURN、本物? 40 例:TURN over TLS でチェック
  41. 41. Webサーバ STUNサーバ TURNサーバSignalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからTURNに問合せ それよりも重要なこと 41 その仕組み上 CPU等のリソース、NWリソースを大量消費する
  42. 42. Webサーバ STUNサーバ TURNサーバSignalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてからTURNに問合せ 発信前にTURNにも問合せ 42 その仕組み上 CPU等のリソース、NWリソースを大量消費する ⇒ 勝手に利用されると超マズイ しかもTURNのデフォルトの認証は WebRTC的にはイケてない・・・
  43. 43. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ デフォルトでのTURNの使うサンプルコード 43
  44. 44. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 何故イケてないかというと・・・ 44 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する
  45. 45. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 45 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する 普通にJSに書いておくと、秘匿すべき情報を 誰でも知ること出来てしまう。(⇒タダ乗り) 何故イケてないかというと・・・
  46. 46. http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 対策は色々考えられますが、その1つ 46
  47. 47. 問題をもうちょっとkwsk http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 47
  48. 48. Webサーバ ※ Hashed Message Authentication Code。秘密鍵(SS)をつけてハッシュを計算したもの。 ざっくり言うと、Shared Secretを共有して HMAC※で共有値を作る仕組み 48 GET /?service=turn password: <HMAC("1375043487:abcd1234", SharedSecret)> TURNサーバ
  49. 49. Webサーバ TURNサーバ ざっくり言うと、Shared Secretを共有して HMAC※で共有値を作る仕組み 49 GET /?service=turn password: <HMAC("1375043487:abcd1234", SharedSecret)> TURNリクエストにて credential: <HMAC("1375043487:abcd1234", SharedSecret)> OkだったらリソースをAllocateして返す ※ Hashed Message Authentication Code。秘密鍵(SS)をつけてハッシュを計算したもの。
  50. 50. ちなみにRFCはExpire.. 50
  51. 51. が・・・実装されてる! ただし、TURNだけ。 対となるHTTPサーバ側は自分で実装してね 51
  52. 52. 元に戻って、次はSignaling 52
  53. 53. Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 (その通信のセッション を特定できる情報等、 超重要な情報を含む) Signalingサーバ シグナリングで必要な情報交換 53
  54. 54. Webサーバ STUNサーバ TURNサーバSignalingサーバ Signalingサーバは本物?通信経路はダダ漏れ? 54 本物? 平文?
  55. 55. Webサーバ STUNサーバ TURNサーバSignalingサーバ XX(任意のシグナリング) over WSS で対応 55 平文? 本物? Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS
  56. 56. Signalingは まだ続く 56
  57. 57. Webサーバ STUNサーバ TURNサーバSignalingサーバ 通信するPeerは本物? きみ誰? 57 Bobに発信しているつもり Alice Bob Carol 実は違う人(Carol)だった
  58. 58. WebRTCではDTLSがあるじゃない? 58http://chimera.labs.oreilly.com/books/1230000000545/ch18.html <DTLS HandShake>
  59. 59. WebRTCではDTLSがあるじゃない? 59http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) <DTLS HandShake>
  60. 60. WebRTCではDTLSがあるじゃない? 60http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) <DTLS HandShake>
  61. 61. 先に証明書生成の話 61http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) <DTLS HandShake>
  62. 62. http://www.slideshare.net/yusukenaka52/webrtcortc より引用 62
  63. 63. http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf サンプルコードのイメージはこんな感じ 63 注:ブラウザに実装されてない。あくまでサンプルです。
  64. 64. もう1つ 64
  65. 65. http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) ユーザの真正性の話 <DTLS HandShake> 65
  66. 66. http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) ユーザの真正性の話 <DTLS HandShake> どうやって証明書を証明する? 66
  67. 67. よくあるWebの仕組み この証明書はVerisign社に よって証明されている 67
  68. 68. よくあるWebの仕組み この証明書はVerisign社に よって証明されている WebRTCだとちょっとヘビー? 68
  69. 69. 69 かなり前から議論が進んでいる http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf
  70. 70. 70 提案されているTopologyの全体像 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf
  71. 71. 71 提案されているTopologyの全体像 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ・IdP (Identity Provider)が 本人であること証明してくれる。 ・IdPは信頼できるところならなんでもいい。 例えば、GoogleやFacebookとか。
  72. 72. 72 Call Flow http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ◆ポイント ・AliceはBobに発信するときに、IdPに問合せて証明してもらう ・その証明情報をつけて、SDPのOfferをBobに送る ・Bobはそれを受け取ったら、AliceのIdPに本物か確認する
  73. 73. 73 続 Call Flow http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ◆ポイント ・Bobが応答するときは、BobもIdPに問合わせて証明してもらう ・Bobは証明情報をつけて、Aliceへ応答する ・Aliceはそれを受け取ったら、BobのIdPに確認する
  74. 74. Signalingは まだまだ続く 74
  75. 75. Signalingサーバ Man In The Middle してみる 途中で暗号を解かない場合 75 悪いサーバ 暗号化 1. 発信する(情報は暗号化)
  76. 76. Signalingサーバ Man In The Middle してみる 途中で暗号を解かない場合 76 悪いサーバ 暗号化 1. 発信する(情報は暗号化) 2. 暗号化された情報をそのまま送る(Replay) 何が起きるかはSignaling Protocol依存 (対策としてはシーケンス番号を付与、等)
  77. 77. Signalingサーバ Man In The Middle してみる 途中で暗号を解いてみる場合 77 悪いサーバ 暗号化 暗号化 なりすまして 盗聴する or 改ざんする
  78. 78. Signalingサーバ 78 悪いサーバ 暗号化 暗号化 なりすまして 盗聴する or 改ざんする WebRTCデフォルトのDTLSオレオレ証明書を使っていると、 MITMには無防備なことに注意 (前述したよう通信相手が本物だと確かめる必要有り) Man In The Middle してみる 途中で暗号を解いてみる場合
  79. 79. Signaling 最後 79
  80. 80. 80 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました
  81. 81. 81 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました Signaling サーバ 電話網とかGateway <WebRTCから電話できる有償サービスの場合> お客様
  82. 82. 82 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました Signaling サーバ 電話網とかGateway <WebRTCから電話できる有償サービスの場合> 長時間通信しても、「そんなに使ってないよ」 とお客様が言い出したら、正しい料金を請求できない ⇒ 通信の開始・終了を記録しておけばOK 特にオレオレSignalingプロトコルのときは要注意 お客様
  83. 83. Signalingが終わったら 次はメディア確立 83
  84. 84. ICE Negotiation メディア確立時には裏でICEが動いてる 84 ICEを三行で: • 相手と使えそうなIPアドレス/Port候補を集める • ひたすら通信確立にトライ(ホールパンチング含む) • 定期的に空けた穴が閉じないようにキープアライブ
  85. 85. ICE Negotiation メディア確立時にはICEが動く 85 さっきSignalingでIPアドレスとか 交換したけど、本物? Signaling時のSDP抜粋
  86. 86. ICE Negotiation ICE自体にも認証の仕組みがついている 86 Signaling時のSDP抜粋 さっきSignalingでIPアドレスとか交換 したけど、そのICEの情報は本物? セッション単位で変わる ufrag(username)とpwd(password) でICEが正しいと証明
  87. 87. ここまでで 簡単な通信フローは おしまい 87
  88. 88. その他 WebRTC特有の課題 88
  89. 89. 89 Privacy ・音声/映像を取得していることを示すことが大事 ブラウザはデフォルトで対応するが、ネイティブアプリを作るときは要注意 ・スクリーンシェアする場合は、している旨を通知すること http://www.slideshare.net/Quobis/webinar-webrtc-security-concerns-a-real-problem
  90. 90. その他 一般的なこと 90
  91. 91. Webサーバ STUNサーバ TURNサーバSignalingサーバ Internetで公開するWebRTCアプリの場合 以下のサーバ群は全て公開サーバとなる 91
  92. 92. 92 昨日の出来事(Facebook is down)
  93. 93. Webサーバ STUNサーバ TURNサーバSignalingサーバ Internetで公開するWebRTCアプリの場合 以下のサーバ群は全て公開サーバとなる 93 そのため、通信確立時のフローだけではなく、 その他セキュリティ対策も必要(特に可用性対策) 例: • DDoS攻撃 • SynFlood攻撃 • ICMP/UDP Flood攻撃 などなど
  94. 94. まとめ 94
  95. 95. 95 • WebRTCはセキュリティ機能を提供している – ただし、メディアの通信経路のみ – しかも、オレオレ証明で対応 • メディア以外のセキュリティ機能については、 各自で対応する – WebRTC(/VoIP)系の攻撃 • Signaling • STUN/TURN • 本人確認 – それ以外の攻撃 • Syn/UDP/ICMP Flood WebRTCのセキュリティまとめ
  96. 96. 96 • WebRTCはセキュリティ機能を提供している – ただし、メディアの通信経路のみ – しかも、オレオレ証明で対応 • メディア以外のセキュリティ機能については、 各自で対応する – WebRTC(/VoIP)系の攻撃 • Signaling • STUN/TURN • 本人確認 – それ以外の攻撃 • Syn/UDP/ICMP Flood WebRTCのセキュリティまとめ おしまい! Any questions?

×