A Study of WebRTC Security

WebRTCセキュリティレポート

あらまし

WebRTC(Web Real-Time Communication)は、Webアプリケーション技術の昨今のトレンドの一つだ。WebRTCを利用すると、プラグイン無しで、また他の条件も無しでリアルタイムコミュニケーションを実現できる。だが、そのオープンソースとして性質から、WebRTCを採用しようとする人がセキュリティ上の不安を覚えることもあるだろう。本レポートはWebRTCのセキュリティについて明らかにし、他の技術と比較してWebRTCのセキュリティが優れていることを解説する。

1. 導入

WebRTCはオープンソースのWebベースの技術であり、ユーザがリアルタイムメディア通信を、プラグイン無しで実現可能な技術だ。適切なブラウザを利用すれば、ウェブサイトをブラウズするだけで、他者に発信して通話することができる。

WebRTCの主なユースケースは以下の通りだ。

  • リアルタイムの音声/映像通信
  • ウェブ会議
  • P2Pでのデータ送受信

他のリアルタイムシステム(例えばSIP)と異なり、WebRTCの通信は、JavaScriptのAPIを通じて、Webサーバによって制御される。

プラグイン無しで、音声映像の通信を可能にするという点は非常に興味深い。 だが、その性質自体がセキュリティに関する不安を引き起こしている。 また、エンドユーザ・通信事業者・サードパーティの両方にとって 信頼できる通信を提供できるかどうかについても、不安がある。

本レポートではこれらのトピックについて述べ、さらにWebRTCが提供するセキュリティリスクについて防衛方法について述べる。ただし、このレポートではネイティブアプリケーションは扱わない。

2. WebRTCアーキテクチャの概要

WebRTCはP2Pのトポロジ形式で、ピア間のメディア通信を実現する。 WebRTCはユーザのブラウザに実装されており、追加のソフトウェアを必要としない。 ピア間の通信が始まる前には、「シグナリング」と呼ばれるメタ情報の交換が必要だ。 このシグナリングプロセスは、通信の開始時に利用され、ピア間の接続確立を実現する。

図1に示すように、シグナリングプロセスは中継サーバを経由して実現される。

図1. WebRTCのシンプルなトポロジ例

図1. WebRTCのシンプルなトポロジ例

シグナリングプロトコルはWebRTCで仕様規定されているわけではない。 これは開発者が自身の選択でプロトコルを選べるようにしているためだ。 開発者は、ユースケースやシナリオに適したアプリケーションを柔軟に作れる。

WebRTCの通信はどのように動作するのか？

WebRTCは3つのAPIから成っており、それぞれがリアルタイム通信を実現するために、ある機能を実現する。 これらのAPIを以降で簡単に解説する。それぞれのプロトコルの技術的な詳細、実装については、このレポートで扱わないが、関連するドキュメントはオンラインで簡単に見つけられる。

getUserMedia

WebRTC登場以前は、音声や映像の取得にはサードパーティのプラグイン（例えばFlashやSilverlight）が必要だった。だが、HTML5の時代になり、多くのデバイスについて直接アクセスする手段が出現し、今ではJavaScriptからそれらのデバイスを利用できるようにあった。

getUserMediaはそのようなAPIの一つで、ブラウザからカメラ・マイクへアクセスするためのAPIだ。WebRTCで多く利用されるAPIだが、このAPIはHTML5の一つとして提供されている。

RTCPeerConnection

RTCPeerConnectionは、WebRTC仕様として規定される3つのAPIのうちの1つだ。 RTCPeerConnectionインターフェースは、WebRTCの通信を示しており、 2つのピア間の効率的なデータ転送に利用される。

発信者が、ある着信先に通信を開始する場合、ブラウザはRTCPeerConnectionのインスタンスをまず作成する。その後、自身が作成するSDP(Session Description Protocol)を、通信相手と交換する。 受信側でも、SDPを作成し発信側に応答する。SDPはNAT越えのためのICEワークフロの一部として利用される。

コネクションが確立したら、RTCPeerConnectionはブラウザ間で音声・映像のデータをビットストリームとして送れるようになる。

究極的には、RTCPeerConnectionAPIがP2Pコネクションのライフサイクルの管理の責務を担い、 接続確立・状態管理を一つのインターフェースで管理できるようにしている。

RTCPeerConnectionは2つの特色がある：

  • 2つのブラウザ間のP2P接続を担う
  • UDP/IPの利用、すなわちTCP/IPの場合と異なりパケットの到達保証が無いが、オーバーヘッドはかなり小さい
    • (ある程度のデータのロスを許容することで、リアルタイム通信に集中できる)

参照: [1] [2]

RTCDataChannel

RTCDataChannelがWebRTC仕様として規定されるAPIのうちのもう1つであり、 ピア間の任意のアプリケーションデータの交換に利用されるコミュニケーションチャネルである。 言い換えれば、ピア間のデータ転送に利用される。

既にデータ転送するための仕組みは他にもあり、例えばWebSocketやServer Sent Eventsがある。 しかし、これらはピア間のデータ転送というよりも、サーバクライアント型向けに設計されている。 RTCDataChannelはWebSocketに似てているが、P2Pの形式で利用される。 また、RTCDataChannelは、トランスポートの特性をカスタマイズ可能といった特性がある。

2.1. WebRTCを支える技術群

前述の通り、開発者が利用するWebRTCのAPIは大きく3つあるが、配下にはそのAPIの支える多くの技術がある。

図2. WebRTC Protocol Stack

図2. WebRTC Protocol Stack

ICE、STUN、TURNはP2Pの接続を確立・維持に利用されている。 DTLSはピア間のデータ転送をセキュアにするために利用されており、 暗号化はWebRTCで必須となっている機能だ。 SRTPは音声・映像を暗号化して送受信されるのに利用される。 SCTPは以下の機能・特徴を持っている：

  • 異なるシステム間でアプリケーションプロトコルを多重化するのに利用される
  • 輻輳制御と流量制御を提供している
  • 信頼性のある転送
  • UDPの上に構築されている

SDP: Session Description Protocol (セッション記述プロトコル)

SDP(Session Description Protocol)は、セッション開始を宣言・維持するための標準的な方法で、 記述的なプロトコルだ。また、SDPはマルチメディアセッションの開始等のタスクも担う。 SDPは、ブラウザの能力とプリファレンスをテキストベースで表現しており、 以下の情報を含む：

  • メディア能力(音声、映像)、コーデック
  • IPアドレスとポート番号
  • P2Pデータ転送プロトコル(音声映像なら、WebRTCではSecure RTP)
  • 利用可能帯域
  • セッション属性(名前、識別子、開始終了時間)
    • ほとんどWebRTCでは利用されていないが…
  • その他のメタデータ

今日のSDPのユースケースの中で、SDPがもっとも利用されているのはSIP、RTP(Real-Time Transport Protocol)、RTSP（Real-Time Streaming Protocol）だ。

参照: [3]

ICE: Interactive Connectivity Establishment

シグナリングは、メタデータを交換する前に最初に中継サーバを必要とする。 メタデータ交換が完了すれば、WebRTCはP2Pの直接接続を試みる。 このプロセスは、ICEフレームワークを通じて実現される。

ICEは、インターネット上でピア間の接続を確立するのに使われるフレームワークのことだ。 WebRTCはP2Pによる直接通信をするが、実際には広く利用されている NAT(Network Address Translation)のせいで、 2つのピアが接続確立するのは難しい。

32ビットのIPv4アドレスは広く利用されているので、インターネットから 直接到達可能はユニークなIPv4アドレスをネットワーク機器が持つのは難しい。 NATは、プライベートIPをパブリックIPに、内側から外側へリクエストが出るときに変換する。 同様に反対の場合は、内側のネットワークで適切にルーティングされるように、 パブリックIPからプライベートIPへ変換する。 その結果、プライベートIPを通信相手のピアと交換しても、 ピア同士で接続するには十分な情報とはいえない。 ICEは、この難しさを克服するために、またピアに対する最適な経路を見つけるために利用される。

可能な限り並列に接続の可能性を試すことで、ICEは最も効率的なパスを選択できる。 ICEは最初に、OS（ネットワークインターフェース）から得られたホストアドレスを利用して、 接続確立を試みる。もし失敗したら（NATの背後にいるため）ICEは、STUNサーバを利用して NAT外部のアドレスを取得して接続確立を試みる。 それもまた失敗したら、最後のフォールバックとしてTURNサーバを利用する。

ICE候補はテキスト形式で表現され、ICE候補は優先度によってソートされている。 ICEは以下のいずれかを選択する。

  • 直接P2P接続
  • STUNを使って、NAT越えを実現したP2P接続
  • TURNを中継サーバとして利用した接続

これらの候補の中で、もっともオーバヘッドが少ないものが選択される。

参照: [4]

STUN: Session Traversal Utilities for NAT

P2P通信を実施するために、発信側・着信側はそれぞれ、 自身に割り当てられたIPアドレスとポート番号を知る必要がある。

STUNサーバは、パブリックIPを取得するために利用され、 またこれは、ICEフレームワークの接続処理の中でも参照される。

STUNサーバは一般的にはパブリックにアクセス可能な存在であり、 WebRTCのアプリケーションから自由に利用される。

TURN: Traversal Using Relays around NAT

P2Pによる接続確立が失敗すると、フォールバックとしてTURNサーバ経由の接続が利用される。 ピア間のトラフィックをTURNサーバが中継することで、WebRTCによる通信が担保される。 しかし、TURNサーバを介することで、メディアの品質の低下・レイテンシが増加する可能性もありうる。

ユーザの環境にかかわらず、TURNサーバはコール確立を高い可能性でできるように担保できる。 データは中継サーバを通じて送られるので、サーバ側での帯域も消費される。 もし、多くの通信が同時に発生すると、かなりの量の帯域が消費される。

TURNサーバは一般的には自由にアクセスされないようにする。 また、アプリケーション提供者によって提供されるべき（またはレンタルするべき）だ。

3. ブラウザベースのセキュリティ考察

一般に、リアルタイムアプリケーションにおけるセキュリティの脅威は、 ネットワーク側およびユーザ側のどちらにも存在している。 このようなセキュリティリスクは、データ通信・メディア通信の両方のデータ転送を利用する 全てのアプリケーションに当てはまる。

しかし、WebRTCは、他のリアルタイム通信アプリケーションと異なる。 それは、新規にWebRTCを利用する開発者にとって、セキュリティの危険を回避しつつ、 強固で信頼性のある基盤を利用することができるためだ。 本レポートでは、WebRTCがどのようにセキュリティリスクに対処しているか議論する。

参照: [5]

ブラウザ信頼モデル(Browser Trust Model)

WebRTCアーキテクチャは、セキュリティの観点から言えば、信頼性のある基盤の上に ネットワークリソースが存在することを想定している。 ユーザから見れば、ブラウザ（ユーザクライアント）が、全てのWebRTCセキュリティの基盤であり、 TCB(Trusted Computing Base、信頼性できる処理基盤)として振る舞う。

ブラウザの仕事はインターネットへのアクセスを可能にする一方で、 ユーザにとって十分なセキュリティ防御を提供する。 WebRTCのセキュリティ要件は、この上に構築されている。 つまり、ユーザがアクセスする全てのWebRTCアプリケーションおよびコンテンツは、 全てブラウザというポータルを通じてアクセスされる。

サーバから提供されるHTMLとJavaScriptはブラウザに様々な動作をさせる一方で、 ブラウザはそれらのスクリプトをサンドボックス上に隔離している。 サンドボックスはスクリプト同士を隔離し、 またユーザのコンピュータからも隔離する。 一般的に、スクリプトは同じドメインからのみしかリソースを扱えない。 もっと具体的に言えば、 同じ"origin"ということだ。

ブラウザはユーザが望むセキュリティポリシを全て強制し、 またサードパーティの検証をする最初のステップでもある。 検証された全てのエンティティは、ブラウザにチェックされたという証明を持つ。

もし、ユーザが信頼できるブラウザを選んだなら、 残りのプロセスとして、全てのWebRTCの通信は「安全」と考えられ、 WebRTCの技術で提供されるセキュリティアーキテクチャに従うことになる。 しかし、もしブラウザが「信頼できる」という点に疑いがあるなら、 （たとえば、信頼できない場所からダウンロードした場合等） WebRTCのアプリケーションは影響を受けている可能性があり、 安全でないかもしれない。

言い換えれば、ユーザに提供されるWebRTCのセキュリティのレベルは、 ブラウザの信頼に直接影響されるということだ。

同一オリジンポリシー (SOP: Same Origin Policy)

Webページがロードされる場合に、 全てのWebページのリソースはWebサーバから取得されるという点は、 DOMの基本的な観点の一つだ。 リソースの取得は、ブラウザがリロードされた場合や、 Webページが内包するスクリプトによって発行されるリクエストを通じて実施される。 そのようなスクリプトは、XMLHttpRequest APIを利用するが、 任意のサーバに対してリクエストを送れるわけではない。 リクエストはスクリプトを入手した「オリジン」と同一でなければならない。 「オリジン」は、URIスキーマ、ホスト名、ポート番号から構成される。 これら全ての制限が、「同一オリジンポリシ」（SOP、Same Origin Policy)と定義される。

SOPは、スクリプトの実行をオリジンごとのサンドボックスに隔離する。 そのため、SOPは異なるオリジン・iframeと情報を交換するのを禁じている。 同一オリジンから提供されるWebページとスクリプトは、 それぞれのJS変数から相互に影響される。 そのようなオリジンが、サンドボックスの単位の基本だ。

サンドボックスでの実行はオリジンを基本とするが、 エンドユーザはクレデンシャルの誤用からも守られている。 例えば、ソーシャルネットワークを利用する場合に、安全に使いたいと思うのは普通であり、 その際、広告パネルのスクリプト実行は避けたいし、ログイン情報を盗まれないようにしている。

同様に、Webページのサーバもユーザのブラウザからの攻撃から守ることができる。 もし、そのようなガードが無ければ、DoS攻撃によって、リソースを乱用できることになる。

参照: [6]

SOPをバイパスする

SOPは一般的に、ユーザとWebサーバの両方にとって非常には重要なセキュリティ機能だが、 一部のWebアプリにとって不利な点でもある。 サイト間の連携をする場合は、相互に同意が必要でありかつ方法は限られるが、 その方法は確かに存在している。

W3Cのクロスオリジンリソースシェアリング(CORS, Cross-Origin Resource Sharing)は、 この問題に対する回答の一つだ。 CORSにより、ブラウザはスクリプトが希望する任意のサーバに対して、 実際にアクセスをしてよいか判断するためにコンタクトする。 もし、クロスオリジンのリクエストが安全に許可されるなら、 特定のリクエストは許可して、それ以外のリクエストは拒否するように動作する。

Webソケットは同様の機能を提供するもう一つのオプションだが、 隔離されているHTTPのリクエストとは異なり、チャネルに対して透過性がある。 Webソケットのコネクションがひとたび確立してしまえば、 スクリプトから自由にトラフィックを転送できるし、リソースも扱える。 また、一連のHTTPリクエスト/レスポンスのようなフレームも扱える。

どちらのケースでも、最初の認証の段階によって、 異なるオリジンからの任意のデータ転送を阻止できる。

4. WebRTCのセキュリティ考察

参照: [7]

インストールと更新

デスクトップのソフトウェアでよくある課題は、そのアプリケーションが信頼できるかどうか、といったものだ。 新しいソフトウェアやプラグインのインストールは、潜在的にマルウェアや望ましくないソフトウェアを 入れてしまう危険性がある。 多くのユーザはソフトウェアがどこにインストールされているかわからないし、 誰からアプリケーションをダウンロードしているかもわからない。 実際に、悪意のあるサードパーティは既にかなり成功している。方法としては、 信頼のおけるソフトウェアにマルウェアを仕込んで、再パッケージ化して、 カスタムパッケージとして、フリーソフトウェアを配信するウェブサイトに載せる、といったものだ。

一方で、WebRTCはプラグインも必要ないし、インストールのプロセスも存在しない。 全てのWebRTCの技術は、WebRTC互換のブラウザ(例えば、ChromeやFirefox)をインストールすることで導入される。 もし、ユーザがこれらのブラウザをもっていれば、 WebRTCのアプリケーションを、他のセットアップや、準備無しに利用できる。 つまり、適切なWebRTCアプリケーションを利用するなら、マルウェアやウィルス混入の可能性はない。 だが、完全に安全なわけではなくて、例えばWebRTCのアプリケーションは、 Versignのような認証局によって書名され、 HTTPSでアクセスできるウェブサイトに配備されるべきだ。

もう一つの関連する考察は、ソフトウェアの脆弱性が見つかった場合の対応だ。 WebRTCは一般的なソフトウェアと同じで、将来的にバグや脆弱性が見つかる可能性は必ずある。 もし脆弱性が見つかった場合は、伝統的なデスクトップアプリ(例えば、VoIPアプリ等)であれば、 パッチ適用にかなりの時間がかかるのが普通だ。 これは、よくあるアプリケーション開発の問題で、セキュリティは機能の二の次（優先度が低い）に なっていることもある。 さらに深堀りして考えれば、ハードウェアベースの通信にも同種の問題があることが分かる。 VoIPの電話はどのぐらい頻繁にセキュリティアップデートを受けているのだろうか？ その定期的なアップデートは信頼できるものなのか？ そもそも誰かが責任をもって実施しているのだろうか？

これらに反して、WebRTCで多く用いるブラウザは、 ユーザがセキュリティの危険にさらされる機会も多いことから、 また非常に普及しているソフトウェアであることから開発が非常に早い。 WebRTCの要素はブラウザの一部として提供されることから、 ブラウザが更新される度に、WebRTCの要素も更新される。 もし、WebRTCの実装で脆弱性が見つかったら、修正版がすぐにユーザに届けられるだろう。 これは、特にChromeやFirefoxの開発サイクルでよく見られる。 実際に、現代のような自動アップデートの時代では、 ブラウザ・WebRTCの要素は、サーバ上に新しいバージョンが用意されるとすぐに、 更新されるようになっている。 モダンなブラウザは、深刻な脆弱性や脅威が見つかった場合には、24時間以内に 自動更新しているような良い記録もある。

補足： WebRTCはプラグインが必要とないと記述しているが、実際にはSafariやIEのような WebRTCをサポートしていないブラウザでもWebRTCを利用できるようにするため、 サードパーティからプラグインが提供されることがある。 そのような場合には、注意して利用すること。

4.2. メディア/ローカルリソースへのアクセス

ブラウザはローカルのリソース(カメラ、マイク、ファイル等)にアクセスできる。 これは、Webアプリケーションがマイクやカメラを利用できることを意味しており、 自然と心配の種の一つになる。 もし、Webアプリケーションがユーザのマイク・カメラを自由に使えたら、 悪意のあるアプリは、ユーザに知られることなく、盗聴や盗撮が可能になる。 バックグラウンドのタブに潜んで、ユーザの信頼を悪用していることだってある。 （ユーザは、あるウェブサイトが悪意のある通信アプリを内包しているなんて、気付きもしないこともある）

WebRTCは、上記のような危険に対して、カメラやマイクを利用する際には、 明示的な許可を必要とするようにしている。 ユーザに対しては、一度限り、または永久に許可するかどうかを問合せできる。 WebRTCのアプリケーションは、デバイスを許可無く自由に扱えるわけではないのだ。 さらに、マイクかカメラが利用中であるとき、クライアントのユーザインタフェースに、 利用中である旨が表示されるようになっている。 Chromeの場合は、以下の図のように、赤い点がタブに表示されるようになっている。

図3. Chrome UI Indicators

図3. Chrome UI Indicators

このセキュリティの考え方は、ユーザ自身が理解した上で、 発信・着信を許可するか決定すべき、といった考えに基づいている。 言い換えれば、ユーザは以下を理解していなければならない：

  • 誰が/何がメディアにアクセスを要求しているのか
  • どこにメディアが送られようとしているのか

将来的な展望ではあるが、WebRTCの仕様において、もしユーザインタフェースで 明示しているサインが、ウィンドウの重なりなどで隠れてしまった場合は、 カメラやマイクの動作を止めるべきだとも規定されている。 これは理想的な振舞いではあるが、必ずしも保証されるわけでもないので、 ユーザは注意して利用する必要がある。 だが幸運なことに、この追加の機能はユーザにとって期待される動作ではない。

WebRTCのその他の機能に、画面共有（スクリーンシェア）があり、 この機能はさらにセキュリティ上の考慮事項を引き起こす。 理由は、その画面共有の範囲が本質的に柔軟であるためだ。 つまり、ユーザは気づかないうちに、共有している範囲を広げてしまうかもしれない。 例えば、ユーザは単に特定のウィンドウを共有しているつもり（例えば誰かにプレゼンしている）だが、 実際にはスクリーンの全てを聴衆に表示してしまっているかもしれない。 このような事象は、最初にどの画面を共有するか選択する際に失敗しているかもしれないし、 単にユーザがその指定を忘れているだけかもしれない。

4.3. メディアの暗号化 と コミュニケーションセキュリティ

リアルタイムアプリケーションがセキュリティリスクにさらされる方法は多くある。 有名なものの1つは、暗号化されていない転送中のトラフィックの盗聴だ。 これは、ブラウザ~ブラウザ間およびブラウザ~サーバ間の通信において、 サードパーティが送受信されているデータを見られる場合に起こる。 しかし、暗号化を利用すれば、盗聴者が通信ストリームの中身を判別できないようにできる。 秘密鍵にアクセスできるもののみが、通信のストリームを解読できるのだ。

WebRTCで暗号化は必須の機能であり、全ての要素で利用をすることになっている （シグナリングも当てはまる）。結果として、WebRTCを利用して 送受信されるデータは、既に標準化されよく知られた暗号化プロトコルを利用して、 全て暗号化される。利用される暗号化プロトコルは、チャネルの型によって異なり、 データストリームはDTLS(Datagram Transport Layer Security)で暗号化され、 メディアストリームはSRTP(Secure Real-time Transport Protocol)で暗号化される。

4.3.1. DTLS: Datagram Transport Layer Security

WebRTCは特にdata channelにおいて、DTLSを暗号化に利用している。 RTCDataChannelはDTLSで暗号化されるということだ。

DTLSはWebRTCをサポートするブラウザに実装されている標準化されたプロトコルであり、 VoIPのプラットフォーム等で、情報を暗号化するのに利用されている。 これまでに述べたように、既にブラウザに組み込まれているので、 特に追加のセットアップは必要ない。 他の暗号系プロトコルと同様に、DTLSは盗聴と改ざんを防止するように設計されている。 DTLS自体は、ストリーム指向のTLSをベースにモデリングされている。 TLSは非対称暗号・データ認証・メッセージ正当性確認などの機能をもったプロトコルであり、 Webの暗号化の仕組みにおいては、HTTPSで利用されるようにデファクトだ。 TLSは信頼性のあるデータ転送を提供するTCPの上に動作するよう設計されているが、 VoIPアプリ(やゲーム等)は、信頼性のないUDPを利用している。

DTLSはSSLの派生なので、標準化されたSSLベースの接続と同じレベルでセキュアである。 実際、WebRTCのデータは標準化されているSSLベースのコネクションを利用してセキュアに守られる。 その際、WebRTCはエンドツーエンドの暗号化を、ほとんどサーバとの調整無しに実現する。

参照: [8]

4.3.1.1. DTLS over TURN

WebRTCの通信の初期化段階では、最初にシグナリングサーバと連携があるものの、 ブラウザ間の通信は直接P2Pでやりとりされる。 P2Pでの暗号化は比較的簡単で予期できるものだが、もしWebRTCの通信の セットアップに失敗すると、P2PからフォールバックしてTURNサーバ(可能な場合に限るが)を利用する。 TURNを利用して通信している間、メディアは品質低下やレイテンシの増加が起こるかもしれないが、 WebRTCのアプリケーションが、ネットワーク的に厳しい環境にあったとしても、動作させることができる。 本レポートでは、TURNを利用した場合の暗号化通信についても述べる。

通信の手段にかかわらず、送信されるデータはエンドポイントで暗号化される。 TURNサーバの目的は単にデータを中継するだけで、 単にルーティングのためだけにUDPレイヤの内容を利用する。 サーバはアプリケーションレイヤのデータをルーティングに利用しない。 そのため、TURNサーバはDTLSに触れることはないし、そもそも不可能だ。

結果として、TURN越しの通信であっても、エンドポイントで施された 暗号化は破られることはない。TURNサーバは エンドエンドで互いに送受信される情報を理解できないし、修正できない。

4.3.2. SRTP: Secure Real-Time Transport Protocol

基本的なRTPはセキュリティの仕組みを備えていない。 また、送受信されるデータを秘匿する機能を持っていない。 そのため、暗号化を提供するためには別の仕組みが必要になる。 実際、暗号化されていないRTPの利用は、WebRTCでは禁止されている。

WebRTCでは、メディアストリームの暗号化にDTLSではなくSRTPを利用している。 理由は、DTLSよりもSRTPの方が軽量だからだ。 WebRTCの仕様では、RTP/SAVPF(RTP/SAVPの上に構築されたプロファイル)を要求している [9]。 SRTPの鍵交換には、通信の開始時にDTLS-SRTPを利用して実施され、 Man-in-the-Middle攻撃を防いでいる。

4.3.3. 安全なリンク確立

WebRTCアプリケーションが、コールを確立する場合の処理をざっと見てみよう。 例えば、AliceとBobの2者が登場するとしよう。 コールの手順は、どちらか(Alice)が他者(Bob)に発信するところからはじまる。 そして、シグナリングの過程で、両者に関連するメタデータが交換される。

ひとたびICEのチェックが完了すれば（正確にはいくつか完了すれば） 2つのピアは1つかそれ以上のセキュアなチャネルを確立できる。 その後、最初にDTLSハンドシェイクがICEによって確立された全てのチャネルで実施される。 この状態で、暗号化するだけならDTLSで十分だが、メディアチャネルではステップがもう1つある。

DTLSハンドシェイクが完了したら、メディアチャネルでは、 SRTP用の鍵が作成されて利用される。 この段階で、AliceとBobは第三者に知られていない情報を持ち、 データやメディアを安全に互いに送受信できるようになる。

参照: [10]

4.3.4. DTLS-SRTP 対 SDES

メディアトラフィックのセキュリティパラメータを交換するために、 SRTPは何らかのキー管理のプロトコルを利用する必要がある。 SRTPにとっては、DTLS-SRTPが用いられる。(TODO)

なお、シグナリング(SIPやHTTP)とメディア(RTP)は個別に暗号化される点に注意すること。

SDES

SDESとは、SDP Security Description for Media Streams のことで、 WebRTCで以前、オプションの1つとして考えられていたものだ。

SDESの場合、セキュリティパラメータや鍵は、SDP属性の中に 平文で設定されて、通信相手と交換される。 SDPはシグナリングプレーン越しに通信されるので、 もしシグナリング自体が暗号化されていない場合は、 第三者に盗聴されて利用されるおそれがある。 言い換えれば、シグナリング自体は暗号化されるべきだ。 具体的にはTLSを使う方法がある。

しかし、シグナリングとメディアを個別に暗号化するということから、 メディアユーザとシグナリングユーザが異なるということもある（同じだとは保証されてないから）。 これに対する保証を提供するために、暗号化バインディングが必要だ。 DTLS−SRTPはそのメカニズムを提供しているが、SDESは提供していない。

今日のほとんどのVoIPのRTPトラフィックは暗号化されていない事実がある。 実際に、暗号化機能はほとんどの顧客が要望する機能だが、 予算の都合上、削られる機能でもある。 もしセキュリティ機能があったとしても、VoIPではSDESが利用されており、 結果的にシグナリングプレーンに頼るところが大きい。

DTLS-SRTP

一方でDTLS-SRTPは、鍵交換をシグナリングプレーンではなくメディアプレーンで実施する。 この違いにより、SDESと異なり暗号化キーをSDPで交換する必要がなくなる。

WebRTCの仕様では、DTLS-SRTPをサポートするのが必須になっている[9]。 さらに、DTLS-SRTPは推奨・デフォルトになる予定であり、他の鍵管理スキーマの利用はない。 言い換えれば、他のスキーマのサポート予定は全くないといううことだ。

もし、オファー(または発信)においてDTLS−SRTPとSDESの両方がサポートされているなら、 DTLS-SRTPが選択されなければならない。 (本条件は、シグナリングが安全かどうかにかかわらず依存しない)

議論

DTLS-SRTPが必須となり、WebRTCの暗号化の選択肢として一般的に受けいられている。 だが、疑問にあがるのが、他のスキーマ(すなわちSDES)が、 後方互換として残されるのかどうかだ。

互換性の観点から言えば、ChromeはSDESとDTLS-SRTPを両方サポートしている。 FirefoxはDTLS−SRTPのみをサポートしている。

参照: [11] [12]

4.3.5. SRTPの弱点

SRTPはRTPパケットのペイロード部分しか暗号化せず、 ヘッダの暗号化を提供していない。 ヘッダには様々な情報が存在しており、隠蔽されるのが望ましい。

例えば、RTPヘッダに存在する情報を1つ述べると、 オーディオ音量のデータがある。 本情報によりある一定の時間に話しているか・話していないのか、 SRTPのヘッダさえ見れば、判別することができる。 もちろん、メディアの内容自体は暗号化されていて盗聴しても分からないが、 それでも怖い側面がある。 例えば、ユーザが悪人と話しているかどうか、法務局が見つけて、判断できるかもしれない。

4.4. Webベースのピア認証 / 識別管理

発信者が接続先のピアの身元を確かめられると、ユーザは安心できる。 すなわち、発信者は、自身の話している相手が信頼に足る人なのか、詐欺師なのか、 確かめたいと自然に思っている。

シグナリングサーバがユーザの身元を証明することができるが、 シグナリングサーバそれ自体が信頼できないかもしれない。 そのため、シグナリングサーバと切り離して、ユーザの認証を提供する案がある。 これは、Identity Provider(IdP)によって実現される。

図4. A call with IdP-based identity

図4. A call with IdP-based identity

多くのウェブベースのIdPが現在のWebで利用可能だ。 例えば、Facebook Connect、BrowserID(Mozilla)、OAuth(Twitter)などがある。 これらのメカニズムの目的は、単に他のサービスに対して、 そのユーザが信頼たる存在であるかを伝えることを目的としている。 Facebook Connectの例でいえば、 Facebook IdPが、あるユーザをFacebook上で検証されたユーザかどうかを回答できる。 これにより、ユーザは自身の認証を他のサービス(主アカウントがあるサービス)と紐付けできる。 注意点としては、IdPが提供する信頼のレベルはエンドポイントのユーザやサービスに依存する点だ。 また、多くの場合、そのサービスはWeb全体の中における信頼についても関係する。

IdPの実装は、オープンソースの標準というよりも、それぞれの会社によって異なるが、 最低限の原理・機能は同じでなければならない。 IdPは、シグナリングサーバの認証を提供しない。 それよりも、ユーザの認証を提供する。（ブラウザによって処理される） WebRTCではどんなサービスが利用されるか定めた要件はないし、 アプリケーションの実装によって何が使われるべきか、といった要件はない。

Webアプリケーションそれ自体は認証に関係しないため、 ブラウザが認証の処理を安全に実施する必要があり、 Webアプリケーションに結果を安全に出力する。 このプロセスは、Webアプリケーションによって偽造されてはならない。

図5. The operation of an Identity Provider

図5. The operation of an Identity Provider

4.5. IPアドレスによる位置情報のプライバシ

ICEを利用した場合の悪影響は、ピアがだれかのIPアドレスを知ることができる、という点だ。 IPアドレスはグローバルの地域ごとに組織・機関によって分けられるので、 IPアドレスを入手できれば、おおまかな接続元の場所が分かる。 これはピアにとっては好ましくない可能性があり、ユーザは避けたい事項かもしれない。

WebRTCは、悪意のあるWebサイトがこの情報（IPアドレス）を入手しようとした場合に、 ユーザを守るように設計されていない。 典型的には、悪意のあるサイトはユーザのサーバリフレクシブアドレスを どんなHTTPリクエストからも入手できる。 サーバからIPアドレスを隠すのは、クライアントに何らかの仕組みが必要となるが、 それは本レポートの範囲外なので割愛する。

WebRTCでは、Webアプリケーションがユーザと協力して、他者から発信に 対応する際にIPアドレスを隠蔽する方法を提供している。 この方法を以下で述べる。

WebRTCの実装では、ユーザが発信に応答してからはじめて、 JavaScriptにICEのネゴシエーション(交渉)を開始するように求められている。 この仕組によって、もしユーザが応答しなかった場合には、 他方にユーザのIPアドレスを伝える必要がなくなる。 なおこの仕組みは、ピアに対しユーザがオンラインかどうか、という情報についても隠すという効果もある。

さらに、既存の通信にTURN以外の候補を追加するといった、 WebRTCアプリケーション自体に通信候補を修正させる方法もある。 さきほど説明した機能とあわせると、ユーザから発信の通知があった場合に ICEネゴシエーションをすぐに開始して、 遅延を減らすだけではなく、ユーザが応答するまでユーザのIPアドレスを隠すこともできる。

参照: [13]

4.6. シグナリング

WebRTCではシグナリングプロトコルが規定されていないので、 シグナリングの暗号のメカニズムは、開発者が選択したシグナリングプロトコルに依存する。 このレポートでは、もっとも普及しているシグナリングである、 SIP(Session Initiation Protocol)について述べる。

SIPはVoIPの接続・切断に利用されるプロトコルで、標準的にかつ広く普及しているプロトコルだ。 しかし、HTTPやSMTPの派生でもある。（これらのプロトコルは定期的に、不正に利用されたりする） SIPは平文で情報を交換するので、悪意のある者がネットワークを盗聴して SIPのメッセージをキャプチャできる。 もし、攻撃者が重要な情報を入手できれば、なりすましも可能だ。

SIPは平文でデータを送受信するので、攻撃者がSIPメッセージの中身を確認するのは簡単だ。 攻撃者が中身を確認した後にどう行動するかについては、攻撃者のみが知っているが、 メッセージのヘッダやボディが改ざんされると想像するのは簡単だ。 もし、攻撃者がSIPのINVITEを傍受できたなら、 例えばFROMヘッダを、攻撃者自身のIPへ変えることもできる。

参照: [10] [15]

4.6.1. SIPの脆弱性

SIPは音声や映像の通信のセッションを制御するためのシグナリングプロトコルだ。 SIPはVoIP技術の中でも広く適用されており、特に接続確立・切断で利用される。 WebRTCでもシグナリングに利用可能であり、1つの選択肢になる。 だが、SIPのメッセージは平文で送信されることが多い。 結果として、多くの攻撃の方法が存在する。以下では、はじめにSIPの処理フローを述べ、 続いてそれらの攻撃方法について述べる。

SIPの処理フロー

接続確立する過程で、ユーザのブラウザ(ユーザエージェント)は、 中央のサーバに(登録:Register)する。 この登録はVoIPにおいて必要不可欠な要素である。 なぜなら、通信相手の接続情報(IPアドレス等)を管理するためだ。

例えば、Bobが発信するとき、BobはまずINVITEメッセージを 中央のプロキシサーバに送る(このプロキシサーバは、シグナリングサーバとも呼ばれる)。 サーバはメッセージの中継し、着信相手を探す。 このときサーバは様々な手段(DNS確認など）を組合せて実施しても良い。

登録ハイジャック

最初のブラウザの登録は、ユーザのコンタクト先のアドレスを発信者に伝えるために利用される。 また、これによりユーザが着信を受けられることも示している。 だが、このプロセスは「登録ハイジャック」の危険性を内包している。

Registerメッセージの内部には「contact:」フィールドがあり、 ユーザのIPアドレスが設定される。 シグナリングサーバが発信を示すINVITEを受信した場合、 ユーザ名（または電話番号）が、Registerされているかどうか確認する。 そしてINVITEが登録されているユーザに転送される。 これらの登録は定期的に更新されて、最新に保たれる。

SIPメッセージは前述の通り平文で送信されるので、 攻撃者がRegisterメッセージの中身を確認するのは簡単だ。 確認した後には、SiVus Message generatorのようなツールを利用して、 類似したSIP情報を作成できる。このとき、 ユーザのIPアドレスが攻撃者のIPアドレスに書き換えられる。 攻撃者は本当のユーザを利用不可状態にしておいて、 この改ざんした情報をつかってRegisterを定期的にアップデートすることで、 本当のユーザ向けの着信を自身に向けることができる。

本当のユーザを利用不可に陥れるような方法は多くある：

  • ユーザデバイスに対するDoS攻撃
  • ユーザの登録を解除する(本レポートでは記載しないもう一つの攻撃)
  • 登録状態を競合状態にする。例えば、攻撃者が15秒ごとにREGISTERリクエストを送信して、本当のユーザのRegisterを上書きする。

これらは、WebRTCでも利用される可能性がある。

SIPの実装者はメッセージの真正性を確認しないので、 改ざんやリプレイ攻撃は発見不可能であり、 攻撃者が使いやすい方法の糸口になる。

もしSIPS(SIP over TLS)を実装して、 SIPリクエストとレスポンスを認証(真正性のチェック含む)していれば、これらの攻撃は回避できる。 実際、SIPSを利用すれば、盗聴やなりすましも防げる。

その他の攻撃

  • Man-in-the-Middle攻撃
    • 攻撃者は最初のSIPメッセージを横取りして、Man-in-the-Middle攻撃を実施する
  • リプレイ攻撃
    • キャプチャしたパケットを、攻撃者がサーバに対して再送する。これにより、サーバにキャプチャしたパケットを使って、再発信させることができる。（この際の発信は、さきほど発信したものを繰り返す内容になる）厄介なことに、攻撃者自身は発信者になる必要がない。自身のIPアドレスをシグナリングのパケットに含める必要がないからだ。
  • セッションハイジャック
    • Webサーバはステートレスであり、リクエストを個別のセッションとして捌く。（認証を継続するには別の仕組みが必要）クッキーがよく利用されるが、それ自体はセッションIDにすぎない。これらのクッキーは初回アクセス時に、サーバーからブラウザへ送信される。
    • もしクッキーが横取り・複製されたら、攻撃者が進行中のセッションの内容に完全にアクセスできることになる。この危険を軽減するために、多くのサイトではIPアドレスやタイムスタンプを利用したアルゴリズムでクッキーを生成している。

暗号化

シグナリングは悪意のある人が攻撃時に狙いやすい箇所ではあるが、常に攻撃しやすいわけではない。 WebRTCでは、メディアストリームに加えて、シグナリングレイヤも暗号化できる。 1つのオプションはOnSIPであり、SIP over WebSockets(wssを使う。WebSocket はTLSで暗号化される)アプローチがある。

本レポートのスコープ外ではあるが、他のシグナリングも同様にTLS、WebSocketを使って、 トラフィックを暗号化できる。 多くの暗号化と同様に、第三者は暗号化の鍵を知らないので、 暗号化された内容（平文）を解読することができない。これにより、攻撃のリスクを削減できる。 もちろん、アプリケーションの開発者は、 具体的に暗号化の方法を利用するように開発しなければならない。

参照: [16]

4.7. 追加のセキュリティトピック

通信事業者の観点

WebRTCのサポートにより、通信事業者がセキュリティリスクを高めるべきではない。 しかし、お客様の手元にあるデバイスやソフトは、悪意のある攻撃者から危険にさらわれる危険性はある。

この理由から、信頼できない送信元（例えばお客様・ユーザ）から送信された全てのデータは、 検証されなければならない。また、通信事業者はクライアントに送信されるデータは 悪意のある攻撃者に取得されうることを想定しなければならない。

これらの2原則を採用することで、通信事業者はお客様を攻撃から守ることができる。

クロスサイトスクリプティング(XSS)

クロスサイトスクリプティング(XSS)は、Webアプリケーションでよく利用される脆弱性の1つだ。 この攻撃により、攻撃者はクライアントサイドスクリプトをウェブページに埋め込める。 XSSの脆弱性は、同一オリジンポリシの回避等のために利用される。

XSSの影響は些細なものから、重大なセキュリティリスクまである。 リスクは、サイト所有者によって実装されたセキュリティ防衛の仕組みと、 サイトが利用するデータの重要性に依存する。

WebRTCにアクセスする主な手段は、HTML5をサポートするブラウザを利用する方法であり、 多くのセキュリティの懸念がある。例えば、 XSSやクロスドメインの攻撃、WebSocket、iframeのセキュリティ、他の課題から 重要な情報が危険にさらされるケースが考えられる。 クライアントはユーザにコントロールされており、ブラウザは安全な環境で動作するわけではないので、 WebRTCのクライアントも攻撃を受ける可能性がある。 クライアントに送信される全てのデータが、攻撃者から丸見えになることだってありえる。

参照: [17]

5. 競合技術との比較

本レポートは、WebRTC以外の競合のセキュリティの検討無しには完成しない。 このセクションでは、WebRTCの強み・弱みについて述べる。 また、他のリアルタイムコミュニケーションの機能についても触れる。

(本レポートは初版であり、比較対象は今後選択される)

候補としては、以下のような技術がある：

  • Flash
  • Sliverlight
  • Jabber
  • SIP

6. 安全な開発をするための設計指針(セキュアなWebRTCを開発するために)

WebRTCは安全に動作するよう設計されている。 しかし、単に技術を利用するだけでなく、常にセキュアな観点をもって設計するのは良い考えだ。 このセクションではプラクティスについて扱う。 このプラクティスにより、単にWebRTCのアプリケーションを開発するよりも、 より安全に開発できるようになる。 特に、機密情報を扱うようなサービス(銀行、医療などのサービス）に適用されるだろう。

セキュアなシグナリング

前述のように、WebRTCはシグナリングに制限は無く、 むしろWebRTCアプリケーションの開発者自身が好きな方法を選べるようにしている。 もちろん、アプリケーションに適した強力な柔軟性を提供する一方で、 シグナリングに関するセキュリティリスクもありえる。

そこで、シグナリングを提供する場合には、 暗号化機能などの追加のセキュリティ対策を実装するのが良い。 単に平文でシグナリングを提供すると、容易に盗聴されてしまう。 セキュリティを意識したアプリケーションのシグナリングには、 SIPS、OpenSIP、HTTPS(WSS) のような技術が併用されるべきだ。

認証とピア監視

単に発信応答するだけの基本的なWebRTCアプリケーションが必要とする情報は、 特に認証無しで利用されるユーザのIDのみだ。 本来は、発信する前に事前登録や事前認証が利用されるのが望ましい。 認証されていないユーザは、発信・応答不可であるべきだ。 また、信頼出来ない着信先へのアクセスも許可するべきではない。

メディアはP2Pで送受信されるので、メディアの内容(音声・映像)は ピア間で全二重形式で直接転送される。 シグナリングサーバは、ピアのセッションを管理しているので、 疑わしいピアが通信に参加しているかどうか、継続的に監視できる。 もし、セッションに参加しているピアが、 シグナリングサーバが認識している以上の数だったら、 悪意のあるだれかが隠れて参加しているかもしれないし、 その場合はそのユーザのアクセスを強制切断すべきだ。

リクエストに対する許可

ユーザが、リクエストに対する許可を、特にメッセージを読むことなく 実施してしまう行動はよくある。 この行動により、ユーザが本来意図していないような許可を Webアプリケーションに与えてしまうリスクがある。

この行動は簡単には対処できないが、考えられる解決策の1つとして、 Webアプリケーションのページ内に明確な詳細情報を記述しておく方法がある。 つまり、ユーザのプライバシ情報を真っ先に表示するという方法だ。

MiTM(Man-in-The-Middle)攻撃

攻撃者がMiTM攻撃に成功してしまった場合、 その発見・対抗策は簡単には見つけられない。 理由としては、攻撃に対する警告が存在しないから、また通常の接続のように見えるからだ。 もし、攻撃を排除しようとしても、気づかないまま通信が続くことになる。

しかし、メディア経路を定期的に確認して、 中継されていないことを確認することで、MiTM攻撃を多少なりとも軽減できる。 特に暗号化したシグナリングと併用するのが良い。

画面共有

画面共有機能を提供するWebRTCアプリケーションは、ユーザを守るために 警告表示を持つべきだ。前述したように、 ユーザが画面共有の範囲に気づいていないリスクがあるので、 アプリケーションは適切な情報を提供できるように設計されるべきだ。

例えば、画面共有を開始する前に、 ユーザに周知があり、機密情報を含む画面は閉じるように警告する、といった方法がある。

フォールバック

最後の手段として、接続確立中の通信が、認証されていない相手から危険にさらされるような ケースを考える。もし、そのような通信が確認されたら、 WebページをレンダリングしているWebアプリケーションのサーバが、接続を切断すべきだ。

参照: [18]

7. 結論

スマートフォン・モバイルデバイス全盛の時代に、 人々のコミュニケーションはこれまで以上に増えている。 そして、これまでに比べ、より私的な使い方になっている。 セキュリティは近年の大きなトピックであり、 大企業がクラックされる事件、政府の通信が盗聴される事件などは大きな問題になっている。 これらの問題が取り上げられた結果、強化されたセキュリティ対策の実装が必要となっている。 その中でも、エンドユーザが知りたいのは、自身のデータが安全な下にあるか、ということだ。

WebRTCはセキュリティといった観点からいえば、これまでのVoIPサービスに比べて、 大きな利点を持っている。今までのVoIPサービスでは、 セキュリティは付加機能といった位置付けであり、多くのVoIPユーザは、 セキュリティ機能無しでVoIPを利用してきた。 大企業はそんなユーザの1人であり、コスト削減や安易な実装を、 管理している情報やユーザよりも優先してきたのだ。 しかし、WebRTCは非暗号化のメディア通信を禁じており、 ユーザのデータは安全にかつプライベートに保たれる。

WebRTCはセキュリティを考慮して設計されており、 多くの主要エリアで、WebRTCはセキュリティを強要・推奨している。 それでも、WebRTCがセキュアだからとって、WebRTCアプリケーションの開発者は 単にアプリケーションを開発するのではなく、 セキュリティについて真剣に受け止めるべきだ。

通信の安全性に注力した結果、WebRTCは今日のVoIP技術の中で、 もっとも安全な技術として考えられている。 暗号化が標準で利用される性質により、通信は常に秘匿される状態にある。 セキュリティと暗号化はもはや付加機能ではないのだ。

最後になるが、WebRTCはだれでも自由につかえて、 開発者が次世代のアプリケーションを作成するのに、 非常に信頼性のある、そして魅力的なフレームワークだ。

もちろん近い将来、ユーザにとってさらにセキュリティが強化された 通信サービス・フレームワークが登場するかもしれない。 しかし、現時点では、数ある技術の中でWebRTCが先頭に立つ技術なのだ。

参照: [19]

8. 参考文献

1. RTCPeerConnection API Reference.
developer.mozilla.org. 2015年7月28日閲覧。

2. Brief Introduction to RTCPeerConnection API.
High Performance Browser Networking. 2015年7月28日閲覧。

3. SDP for the WebRTC.
tools.ietf.org. 2015年7月28日閲覧。

4. After signaling: using ICE to cope with NATs and firewalls.
html5rocks.com. 2015年7月28日閲覧。

5. Getting Started with WebRTC - Security.
html5rocks.com. 2015年7月28日閲覧。

6. WebRTC Security - Same Origin Policy.
tools.ietf.org. 2015年7月28日閲覧。

7. Security Considerations for WebRTC.
tools.ietf.org. 2015年7月28日閲覧。

8. Attack of the week: Datagram TLS.
blog.cryptographyengineering.com. 2015年7月28日閲覧。

9. Web Real-Time Communication (WebRTC): Media Transport and Use of RTP.
tools.ietf.org. 2015年7月28日閲覧。

10. The Foundation of WebRTC Security.
onsip.com. 2015年7月28日閲覧。

11. WebRTC MUST implement DTLS-SRTP but… MUST NOT implement SDES?.
webrtchacks.com. 2015年7月28日閲覧。

12. IETF-87 rtcweb agenda.
tools.ietf.org. 2015年7月28日閲覧。

13. Security Considerations for WebRTC.
www.ietf.org. 2015年7月28日閲覧。

14. WebRTC and Man in the Middle Attacks.
webrtchacks.com. 2015年7月28日閲覧。

15. Security in a SIP network: Identifying network attacks.
searchunifiedcommunications.techtarget.com. 2015年7月28日閲覧。

16. Two attacks against VoIP.
symantec.com. 2015年7月28日閲覧。

17. Security for WebRTC applications.
altanaitelecom.wordpress.com. 2015年7月28日閲覧。

18. WebRTC Security.
altanaitelecom.wordpress.com. 2015年7月28日閲覧。

19. Why WebRTC is the Most Secure VoIP Solution.
bloggeek.me. 2015年7月28日閲覧。

Fork me on GitHub