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

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?