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