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

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

Transcript

1. WebRTC is secure,
 or not secure?
 -WebRTC セキュリティ概説-
 WebRTC Meetup Tokyo #6
 @iwashi86
 1
2. •Attribute
 　・Name -> Yoshimasa IWASE 
 　・Twitter -> @iwashi86
 　・Web -> iwashi.co
 
 •Work @ NTT Communications
 　・SkyWay(WebRTC)の裏側の開発
 　・HTML5 Experts.jpというWebメディアの編集
 
 •Recently
 　・SkyWayでTURNトライアルを開始しました！
 2
3. 今日のお話
 WebRTCのセキュリティ
 3
4. WebRTCって安全！ 4
5. WebRTCって安全！ ホント？ 考えたことありますか？ 5
6. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 6
7. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 7 Secureって書いてある Secureって書いてある
8. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 8 Secureって書いてある Secureって書いてある どこ暗号化？
9. ざっくり通信フローで
 ちょっと考えてみよう
 9
10. Webサーバ STUNサーバ TURNサーバ HTML/JS/CSS をDL Signalingサーバ WebRTCアプリをWebサーバから落とす
 10
11. Webサーバ STUNサーバ TURNサーバ 己のグローバル IP/Portを知る Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから STUNに問合せ。STUNとTURNは同じサーバでもOK。 発信前にSTUNへ問合せ
 11
12. Webサーバ STUNサーバ TURNサーバ 直接接続できない場合に使う TURNサーバのアドレスを取得 Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 12
13. Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 Signalingサーバ シグナリングで必要な情報交換
 13
14. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 音声・映像を接続開始 注：接続開始前には ICEで頑張ってホールパンチングする P2Pでメディア(音声・映像)接続する
 14
15. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注：接続開始前には ICEで頑張ってホールパンチングする またはTURN経由でメディア接続する
 15
16. DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data SRTP × DTLS は どこを暗号化？
 16
17. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 暗号化対象 暗号化されるのはメディアのみ
 17
18. 暗号化対象 Webサーバ STUNサーバ TURNサーバ Signalingサーバ その他の経路はWebRTCアプリ側で面倒をみる
 (∵WebRTCにおいて、シグナリングは未規定なので当たり前？)
 18 補足：STUNは、用途によってはセキュリティをあまり考慮しないこともあ
19. 暗号化対象 Webサーバ STUNサーバ TURNサーバ Signalingサーバ その他の経路はWebRTCアプリ側で面倒をみる
 (∵WebRTCにおいて、シグナリングは未規定なので当たり前？)
 19 補足：STUNは、用途によってはセキュリティをあまり考慮しないこともあ しかもセキュリティって 色々な要素がありますよね？
20. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 20 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性
21. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 21 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える
22. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 22 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと
23. ※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 23 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと 安全にサービス提供するには 色々考えないとイカン！
24. そこで、本セッションでは、
 WebRTCアプリに対する
 攻撃とその対策について紹介
 
 (特にWebRTCアプリの開発者向けに)
 24
25. 25 本題の前に基礎知識
 SSL/TLS について
 
 (今日よく出てくるので)

26. SSL/TLSとは
 26 TCPレイヤの上で動作し、以下の機能を提供する： • 認証 • 相手が本物か確かめられる • 暗号化 • 盗聴しても分からなくなる • 改ざん検出 • 経路途中で書き換えられていないか検出できる
27. 27 http://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 では本題

29. 今日のスコープ ⇒ 主に音声/映像
 29 DTL Securi ty IP UDP 　DTLS Secure RTP SCTP Audio/Video Data
30. お話の流れ
 シンプルな通信フローに
 ツッコミを入れていこう
 30
31. Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 31
32. Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 32 本当に信じていいWebサーバ？
33. Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 33 本当に信じていいWebサーバ？ SSL/TLS で証明しよう！
34. Webサーバ STUNサーバ TURNサーバ セキュアさは比較的重要視されないのでスルー (単にグローバルIP/Portを調べる動作なので) ただし、STUNのRFC5389で規定される以下 の技術要素は知っておくべき： ・long term credential ・short term credential (こっちはほぼ不要) Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから STUNに問合せ。STUNとTURNは同じサーバでもOK。 お次はSTUN
 34
35. RFC5389より
 35
36. RFC5389より
 36 同じCredentialを「長期間」使う仕組み
37. RFC5389より
 同じCredentialを「長期間」使う仕組み 「一時的」なCredentialを使う仕組み 37
38. RFC5389より
 同じCredentialを「長期間」使う仕組み (WebRTCは、こっち) 「一時的」なCredentialを使う仕組み 38
39. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 39
40. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 そのTURN、本物？
 40 例：TURN over TLS でチェック
41. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 それよりも重要なこと
 41 その仕組み上 CPU等のリソース、NWリソースを大量消費する
42. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注：厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 42 その仕組み上 CPU等のリソース、NWリソースを大量消費する ⇒　勝手に利用されると超マズイ しかもTURNのデフォルトの認証は WebRTC的にはイケてない・・・
43. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ デフォルトでのTURNの使うサンプルコード
 43
44. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 何故イケてないかというと・・・
 44 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する
45. http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 45 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する 普通にJSに書いておくと、秘匿すべき情報を 誰でも知ること出来てしまう。（⇒タダ乗り） 何故イケてないかというと・・・

46. http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 対策は色々考えられますが、その1つ 46
47. 問題をもうちょっとkwsk http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 47
48. Webサーバ ※ Hashed Message Authentication Code。秘密鍵(SS)をつけてハッシュを計算したもの。 ざっくり言うと、Shared Secretを共有して
 HMAC※で共有値を作る仕組み
 48 GET /?service=turn password: <HMAC("1375043487:abcd1234", SharedSecret)> TURNサーバ
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. ちなみにRFCはExpire.. 50
51. が・・・実装されてる！ ただし、TURNだけ。 対となるHTTPサーバ側は自分で実装してね 51
52. 元に戻って、次はSignaling
 52
53. Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 （その通信のセッション を特定できる情報等、 超重要な情報を含む） Signalingサーバ シグナリングで必要な情報交換
 53
54. Webサーバ STUNサーバ TURNサーバ Signalingサーバ Signalingサーバは本物？通信経路はダダ漏れ？
 54 本物？ 平文？
55. Webサーバ STUNサーバ TURNサーバ Signalingサーバ XX(任意のシグナリング) over WSS で対応
 55 平文？ 本物？ Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS
56. Signalingは まだ続く
 56
57. Webサーバ STUNサーバ TURNサーバ Signalingサーバ 通信するPeerは本物？　きみ誰？
 57 Bobに発信しているつもり Alice Bob Carol 実は違う人(Carol)だった
58. WebRTCではDTLSがあるじゃない？
 58 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html ＜DTLS HandShake＞
59. WebRTCではDTLSがあるじゃない？
 59 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 （＝オレオレ証明書） ＜DTLS HandShake＞
60. WebRTCではDTLSがあるじゃない？
 60 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 （＝オレオレ証明書） しかもOriginベースで使い回し （＝通信相手ごとに作るようなコント ロールをJSで出来ない） ＜DTLS HandShake＞
61. 先に証明書生成の話
 61 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 （＝オレオレ証明書） しかもOriginベースで使い回し （＝通信相手ごとに作るようなコント ロールをJSで出来ない） ＜DTLS HandShake＞
62. http://www.slideshare.net/yusukenaka52/webrtcortc　より引用 62
63. http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf サンプルコードのイメージはこんな感じ
 63 注：ブラウザに実装されてない。あくまでサンプルです。
64. もう1つ
 64
65. http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 （＝オレオレ証明書） しかもOriginベースで使い回し （＝通信相手ごとに作るようなコント ロールをJSで出来ない） ユーザの真正性の話
 ＜DTLS HandShake＞ 65
66. http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 （＝オレオレ証明書） しかもOriginベースで使い回し （＝通信相手ごとに作るようなコント ロールをJSで出来ない） ユーザの真正性の話
 ＜DTLS HandShake＞ どうやって証明書を証明する？
 66
67. よくあるWebの仕組み
 この証明書はVerisign社に よって証明されている 67
68. よくあるWebの仕組み
 この証明書はVerisign社に よって証明されている WebRTCだとちょっとヘビー？ 68
69. 69 かなり前から議論が進んでいる http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf
70. 70 提案されているTopologyの全体像
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf
71. 71 提案されているTopologyの全体像
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ・IdP (Identity Provider)が 　本人であること証明してくれる。 ・IdPは信頼できるところならなんでもいい。 　例えば、GoogleやFacebookとか。
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 続 Call Flow
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ◆ポイント 　・Bobが応答するときは、BobもIdPに問合わせて証明してもらう 　・Bobは証明情報をつけて、Aliceへ応答する 　・Aliceはそれを受け取ったら、BobのIdPに確認する
74. Signalingは まだまだ続く
 74
75. Signalingサーバ Man In The Middle してみる
 途中で暗号を解かない場合
 75 悪いサーバ 暗号化 1. 発信する(情報は暗号化)
76. Signalingサーバ Man In The Middle してみる
 途中で暗号を解かない場合
 76 悪いサーバ 暗号化 1. 発信する(情報は暗号化) 2. 暗号化された情報をそのまま送る(Replay) 何が起きるかはSignaling Protocol依存 (対策としてはシーケンス番号を付与、等)
77. Signalingサーバ Man In The Middle してみる
 途中で暗号を解いてみる場合
 77 悪いサーバ 暗号 化 暗号化 なりすまして 盗聴する or 改ざんする
78. Signalingサーバ 78 悪いサーバ 暗号 化 暗号化 なりすまして 盗聴する or 改ざんする WebRTCデフォルトのDTLSオレオレ証明書を使っていると、 MITMには無防備なことに注意 （前述したよう通信相手が本物だと確かめる必要有り） Man In The Middle してみる
 途中で暗号を解いてみる場合

79. Signaling 最後
 79
80. 80 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました

81. 81 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました
 Signaling サーバ 電話網とか Gateway ＜WebRTCから電話できる有償サービスの場合＞ お客様
82. 82 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました
 Signaling サーバ 電話網とか Gateway ＜WebRTCから電話できる有償サービスの場合＞ 長時間通信しても、「そんなに使ってないよ」 とお客様が言い出したら、正しい料金を請求できない ⇒　通信の開始・終了を記録しておけばOK 特にオレオレSignalingプロトコルのときは要注意 お客様
83. Signalingが終わったら
 次はメディア確立
 83
84. ICE Negotiation メディア確立時には裏でICEが動いてる
 84 ICEを三行で： • 相手と使えそうなIPアドレス/Port候補を集める • ひたすら通信確立にトライ(ホールパンチング含む) • 定期的に空けた穴が閉じないようにキープアライブ
85. ICE Negotiation メディア確立時にはICEが動く
 85 さっきSignalingでIPアドレスとか 交換したけど、本物？ Signaling時のSDP抜粋
86. ICE Negotiation ICE自体にも認証の仕組みがついている
 86 Signaling時のSDP抜粋 さっきSignalingでIPアドレスとか交換 したけど、そのICEの情報は本物？ セッション単位で変わる ufrag(username)とpwd(password) でICEが正しいと証明
87. ここまでで
 簡単な通信フローは
 おしまい
 87
88. その他
 WebRTC特有の課題
 88
89. 89 Privacy
 ・音声/映像を取得していることを示すことが大事 　ブラウザはデフォルトで対応するが、ネイティブアプリを作るときは要注意 ・スクリーンシェアする場合は、している旨を通知すること http://www.slideshare.net/Quobis/webinar-webrtc-security-concerns-a-real-problem
90. その他 一般的なこと
 90
91. Webサーバ STUNサーバ TURNサーバ Signalingサーバ Internetで公開するWebRTCアプリの場合
 以下のサーバ群は全て公開サーバとなる
 91
92. 92 昨日の出来事(Facebook is down)
93. Webサーバ STUNサーバ TURNサーバ Signalingサーバ Internetで公開するWebRTCアプリの場合
 以下のサーバ群は全て公開サーバとなる
 93 そのため、通信確立時のフローだけではなく、 その他セキュリティ対策も必要（特に可用性対策） 例： • DDoS攻撃 • SynFlood攻撃 • ICMP/UDP Flood攻撃　　　などなど
94. まとめ
 94
95. 95 • WebRTCはセキュリティ機能を提供している
 – ただし、メディアの通信経路のみ
 – しかも、オレオレ証明で対応
 • メディア以外のセキュリティ機能については、各自で 対応する
 – WebRTC(/VoIP)系の攻撃
 • Signaling
 • STUN/TURN
 • 本人確認
 – それ以外の攻撃
 • Syn/UDP/ICMP Flood
 
 WebRTCのセキュリティまとめ

96. 96 • WebRTCはセキュリティ機能を提供している
 – ただし、メディアの通信経路のみ
 – しかも、オレオレ証明で対応
 • メディア以外のセキュリティ機能については、各自で 対応する
 – WebRTC(/VoIP)系の攻撃
 • Signaling
 • STUN/TURN
 • 本人確認
 – それ以外の攻撃
 • Syn/UDP/ICMP Flood
 
 WebRTCのセキュリティまとめ
 おしまい! 
 Any questions?