Slide 1

Slide 1 text

WebRTC is secure,
 or not secure?
 -WebRTC セキュリティ概説-
 WebRTC Meetup Tokyo #6
 @iwashi86
 1

Slide 2

Slide 2 text

●Attribute
  ・Name -> Yoshimasa IWASE 
  ・Twitter -> @iwashi86
  ・Web -> iwashi.co
 
 ●Work @ NTT Communications
  ・SkyWay(WebRTC)の裏側の開発
  ・HTML5 Experts.jpというWebメディアの編集
 
 ●Recently
  ・SkyWayでTURNトライアルを開始しました!
 2

Slide 3

Slide 3 text

今日のお話
 WebRTCのセキュリティ
 3

Slide 4

Slide 4 text

WebRTCって安全! 4

Slide 5

Slide 5 text

WebRTCって安全! ホント? 考えたことありますか? 5

Slide 6

Slide 6 text

DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 6

Slide 7

Slide 7 text

DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 7 Secureって書いてある Secureって書いてある

Slide 8

Slide 8 text

DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data Meetup #3 でお話したこと
 8 Secureって書いてある Secureって書いてある どこ暗号化?

Slide 9

Slide 9 text

ざっくり通信フローで
 ちょっと考えてみよう
 9

Slide 10

Slide 10 text

Webサーバ STUNサーバ TURNサーバ HTML/JS/CSS をDL Signalingサーバ WebRTCアプリをWebサーバから落とす
 10

Slide 11

Slide 11 text

Webサーバ STUNサーバ TURNサーバ 己のグローバル IP/Portを知る Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから STUNに問合せ。STUNとTURNは同じサーバでもOK。 発信前にSTUNへ問合せ
 11

Slide 12

Slide 12 text

Webサーバ STUNサーバ TURNサーバ 直接接続できない場合に使う TURNサーバのアドレスを取得 Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 12

Slide 13

Slide 13 text

Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 Signalingサーバ シグナリングで必要な情報交換
 13

Slide 14

Slide 14 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 音声・映像を接続開始 注:接続開始前には ICEで頑張ってホールパンチングする P2Pでメディア(音声・映像)接続する
 14

Slide 15

Slide 15 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注:接続開始前には ICEで頑張ってホールパンチングする またはTURN経由でメディア接続する
 15

Slide 16

Slide 16 text

DTL Securi ty IP UDP DTL Security Secure RTP SCTP Audio/Video Data SRTP × DTLS は どこを暗号化?
 16

Slide 17

Slide 17 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 暗号化対象 暗号化されるのはメディアのみ
 17

Slide 18

Slide 18 text

暗号化対象 Webサーバ STUNサーバ TURNサーバ Signalingサーバ その他の経路はWebRTCアプリ側で面倒をみる
 (∵WebRTCにおいて、シグナリングは未規定なので当たり前?)
 18 補足:STUNは、用途によってはセキュリティをあまり考慮しないこともあ

Slide 19

Slide 19 text

暗号化対象 Webサーバ STUNサーバ TURNサーバ Signalingサーバ その他の経路はWebRTCアプリ側で面倒をみる
 (∵WebRTCにおいて、シグナリングは未規定なので当たり前?)
 19 補足:STUNは、用途によってはセキュリティをあまり考慮しないこともあ しかもセキュリティって 色々な要素がありますよね?

Slide 20

Slide 20 text

※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 20 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性

Slide 21

Slide 21 text

※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 21 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える

Slide 22

Slide 22 text

※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 22 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと

Slide 23

Slide 23 text

※ http://www.ipa.go.jp/files/000015290.pdf P.4 IPAの資料※を抜粋すると
 23 その他、以下も定義されることも ◆真正性 ◆責任追跡性 ◆否認防止性 要は・・・ ・中身をばれずに ・かつ改ざんされずに ・許可された人が使いたくなったら使える 要は・・・ ・本人確認できて ・やらかした人を特定できて ・言い逃れさせないこと 安全にサービス提供するには 色々考えないとイカン!

Slide 24

Slide 24 text

そこで、本セッションでは、
 WebRTCアプリに対する
 攻撃とその対策について紹介
 
 (特にWebRTCアプリの開発者向けに)
 24

Slide 25

Slide 25 text

25 本題の前に基礎知識
 SSL/TLS について
 
 (今日よく出てくるので)


Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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のフロー


Slide 28

Slide 28 text

28 では本題


Slide 29

Slide 29 text

今日のスコープ ⇒ 主に音声/映像
 29 DTL Securi ty IP UDP  DTLS Secure RTP SCTP Audio/Video Data

Slide 30

Slide 30 text

お話の流れ
 シンプルな通信フローに
 ツッコミを入れていこう
 30

Slide 31

Slide 31 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 31

Slide 32

Slide 32 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 32 本当に信じていいWebサーバ?

Slide 33

Slide 33 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ まず最初のダウンロード
 33 本当に信じていいWebサーバ? SSL/TLS で証明しよう!

Slide 34

Slide 34 text

Webサーバ STUNサーバ TURNサーバ セキュアさは比較的重要視されないのでスルー (単にグローバルIP/Portを調べる動作なので) ただし、STUNのRFC5389で規定される以下 の技術要素は知っておくべき: ・long term credential ・short term credential (こっちはほぼ不要) Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから STUNに問合せ。STUNとTURNは同じサーバでもOK。 お次はSTUN
 34

Slide 35

Slide 35 text

RFC5389より
 35

Slide 36

Slide 36 text

RFC5389より
 36 同じCredentialを「長期間」使う仕組み

Slide 37

Slide 37 text

RFC5389より
 同じCredentialを「長期間」使う仕組み 「一時的」なCredentialを使う仕組み 37

Slide 38

Slide 38 text

RFC5389より
 同じCredentialを「長期間」使う仕組み (WebRTCは、こっち) 「一時的」なCredentialを使う仕組み 38

Slide 39

Slide 39 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 39

Slide 40

Slide 40 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 そのTURN、本物?
 40 例:TURN over TLS でチェック

Slide 41

Slide 41 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 それよりも重要なこと
 41 その仕組み上 CPU等のリソース、NWリソースを大量消費する

Slide 42

Slide 42 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 注:厳密にはCallee(受信側)は、相手の発信を受けてから TURNに問合 発信前にTURNにも問合せ
 42 その仕組み上 CPU等のリソース、NWリソースを大量消費する ⇒ 勝手に利用されると超マズイ しかもTURNのデフォルトの認証は WebRTC的にはイケてない・・・

Slide 43

Slide 43 text

http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ デフォルトでのTURNの使うサンプルコード
 43

Slide 44

Slide 44 text

http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 何故イケてないかというと・・・
 44 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する

Slide 45

Slide 45 text

http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ 45 Turnを利用する際に Username と Credential(≒パスワード) をWebRTCアプリ側で設定する 普通にJSに書いておくと、秘匿すべき情報を 誰でも知ること出来てしまう。(⇒タダ乗り) 何故イケてないかというと・・・


Slide 46

Slide 46 text

http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 対策は色々考えられますが、その1つ 46

Slide 47

Slide 47 text

問題をもうちょっとkwsk http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf 47

Slide 48

Slide 48 text

Webサーバ ※ Hashed Message Authentication Code。秘密鍵(SS)をつけてハッシュを計算したもの。 ざっくり言うと、Shared Secretを共有して
 HMAC※で共有値を作る仕組み
 48 GET /?service=turn password: TURNサーバ

Slide 49

Slide 49 text

Webサーバ TURNサーバ ざっくり言うと、Shared Secretを共有して
 HMAC※で共有値を作る仕組み
 49 GET /?service=turn password: TURNリクエストにて credential: OkだったらリソースをAllocateして返す ※ Hashed Message Authentication Code。秘密鍵(SS)をつけてハッシュを計算したもの。

Slide 50

Slide 50 text

ちなみにRFCはExpire.. 50

Slide 51

Slide 51 text

が・・・実装されてる! ただし、TURNだけ。 対となるHTTPサーバ側は自分で実装してね 51

Slide 52

Slide 52 text

元に戻って、次はSignaling
 52

Slide 53

Slide 53 text

Webサーバ STUNサーバ TURNサーバ 互いのIP等を交換 (その通信のセッション を特定できる情報等、 超重要な情報を含む) Signalingサーバ シグナリングで必要な情報交換
 53

Slide 54

Slide 54 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ Signalingサーバは本物?通信経路はダダ漏れ?
 54 本物? 平文?

Slide 55

Slide 55 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ XX(任意のシグナリング) over WSS で対応
 55 平文? 本物? Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS Signalingは未規定なので 一例だが、 XX over WSS

Slide 56

Slide 56 text

Signalingは まだ続く
 56

Slide 57

Slide 57 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ 通信するPeerは本物? きみ誰?
 57 Bobに発信しているつもり Alice Bob Carol 実は違う人(Carol)だった

Slide 58

Slide 58 text

WebRTCではDTLSがあるじゃない?
 58 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html <DTLS HandShake>

Slide 59

Slide 59 text

WebRTCではDTLSがあるじゃない?
 59 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) <DTLS HandShake>

Slide 60

Slide 60 text

WebRTCではDTLSがあるじゃない?
 60 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) <DTLS HandShake>

Slide 61

Slide 61 text

先に証明書生成の話
 61 http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) <DTLS HandShake>

Slide 62

Slide 62 text

http://www.slideshare.net/yusukenaka52/webrtcortc より引用 62

Slide 63

Slide 63 text

http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf サンプルコードのイメージはこんな感じ
 63 注:ブラウザに実装されてない。あくまでサンプルです。

Slide 64

Slide 64 text

もう1つ
 64

Slide 65

Slide 65 text

http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) ユーザの真正性の話
 <DTLS HandShake> 65

Slide 66

Slide 66 text

http://chimera.labs.oreilly.com/books/1230000000545/ch18.html これを作るのは自分 (=オレオレ証明書) しかもOriginベースで使い回し (=通信相手ごとに作るようなコント ロールをJSで出来ない) ユーザの真正性の話
 <DTLS HandShake> どうやって証明書を証明する?
 66

Slide 67

Slide 67 text

よくあるWebの仕組み
 この証明書はVerisign社に よって証明されている 67

Slide 68

Slide 68 text

よくあるWebの仕組み
 この証明書はVerisign社に よって証明されている WebRTCだとちょっとヘビー? 68

Slide 69

Slide 69 text

69 かなり前から議論が進んでいる http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

Slide 70

Slide 70 text

70 提案されているTopologyの全体像
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

Slide 71

Slide 71 text

71 提案されているTopologyの全体像
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ・IdP (Identity Provider)が  本人であること証明してくれる。 ・IdPは信頼できるところならなんでもいい。  例えば、GoogleやFacebookとか。

Slide 72

Slide 72 text

72 Call Flow
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ◆ポイント  ・AliceはBobに発信するときに、IdPに問合せて証明してもらう  ・その証明情報をつけて、SDPのOfferをBobに送る  ・Bobはそれを受け取ったら、AliceのIdPに本物か確認する

Slide 73

Slide 73 text

73 続 Call Flow
 http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf ◆ポイント  ・Bobが応答するときは、BobもIdPに問合わせて証明してもらう  ・Bobは証明情報をつけて、Aliceへ応答する  ・Aliceはそれを受け取ったら、BobのIdPに確認する

Slide 74

Slide 74 text

Signalingは まだまだ続く
 74

Slide 75

Slide 75 text

Signalingサーバ Man In The Middle してみる
 途中で暗号を解かない場合
 75 悪いサーバ 暗号化 1. 発信する(情報は暗号化)

Slide 76

Slide 76 text

Signalingサーバ Man In The Middle してみる
 途中で暗号を解かない場合
 76 悪いサーバ 暗号化 1. 発信する(情報は暗号化) 2. 暗号化された情報をそのまま送る(Replay) 何が起きるかはSignaling Protocol依存 (対策としてはシーケンス番号を付与、等)

Slide 77

Slide 77 text

Signalingサーバ Man In The Middle してみる
 途中で暗号を解いてみる場合
 77 悪いサーバ 暗号 化 暗号化 なりすまして 盗聴する or 改ざんする

Slide 78

Slide 78 text

Signalingサーバ 78 悪いサーバ 暗号 化 暗号化 なりすまして 盗聴する or 改ざんする WebRTCデフォルトのDTLSオレオレ証明書を使っていると、 MITMには無防備なことに注意 (前述したよう通信相手が本物だと確かめる必要有り) Man In The Middle してみる
 途中で暗号を解いてみる場合


Slide 79

Slide 79 text

Signaling 最後
 79

Slide 80

Slide 80 text

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


Slide 81

Slide 81 text

81 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました
 Signaling サーバ 電話網とか Gateway <WebRTCから電話できる有償サービスの場合> お客様

Slide 82

Slide 82 text

82 ◆責任追跡性 ◆否認防止性 ・やらかした人を特定できて ・言い逃れさせないこと セキュリティの要素にはこんなのもありました
 Signaling サーバ 電話網とか Gateway <WebRTCから電話できる有償サービスの場合> 長時間通信しても、「そんなに使ってないよ」 とお客様が言い出したら、正しい料金を請求できない ⇒ 通信の開始・終了を記録しておけばOK 特にオレオレSignalingプロトコルのときは要注意 お客様

Slide 83

Slide 83 text

Signalingが終わったら
 次はメディア確立
 83

Slide 84

Slide 84 text

ICE Negotiation メディア確立時には裏でICEが動いてる
 84 ICEを三行で: • 相手と使えそうなIPアドレス/Port候補を集める • ひたすら通信確立にトライ(ホールパンチング含む) • 定期的に空けた穴が閉じないようにキープアライブ

Slide 85

Slide 85 text

ICE Negotiation メディア確立時にはICEが動く
 85 さっきSignalingでIPアドレスとか 交換したけど、本物? Signaling時のSDP抜粋

Slide 86

Slide 86 text

ICE Negotiation ICE自体にも認証の仕組みがついている
 86 Signaling時のSDP抜粋 さっきSignalingでIPアドレスとか交換 したけど、そのICEの情報は本物? セッション単位で変わる ufrag(username)とpwd(password) でICEが正しいと証明

Slide 87

Slide 87 text

ここまでで
 簡単な通信フローは
 おしまい
 87

Slide 88

Slide 88 text

その他
 WebRTC特有の課題
 88

Slide 89

Slide 89 text

89 Privacy
 ・音声/映像を取得していることを示すことが大事  ブラウザはデフォルトで対応するが、ネイティブアプリを作るときは要注意 ・スクリーンシェアする場合は、している旨を通知すること http://www.slideshare.net/Quobis/webinar-webrtc-security-concerns-a-real-problem

Slide 90

Slide 90 text

その他 一般的なこと
 90

Slide 91

Slide 91 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ Internetで公開するWebRTCアプリの場合
 以下のサーバ群は全て公開サーバとなる
 91

Slide 92

Slide 92 text

92 昨日の出来事(Facebook is down)

Slide 93

Slide 93 text

Webサーバ STUNサーバ TURNサーバ Signalingサーバ Internetで公開するWebRTCアプリの場合
 以下のサーバ群は全て公開サーバとなる
 93 そのため、通信確立時のフローだけではなく、 その他セキュリティ対策も必要(特に可用性対策) 例: • DDoS攻撃 • SynFlood攻撃 • ICMP/UDP Flood攻撃   などなど

Slide 94

Slide 94 text

まとめ
 94

Slide 95

Slide 95 text

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


Slide 96

Slide 96 text

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