送信元機器で認証情報を組み込む通信路非依存型セキュア・ライブ通信に関する研究

1. 送信元機器で認証情報を組み込む通信路非依存型セキュア・ライブ通信に関する研究送信元機器で認証情報を組み込む通信路非依存型セキュア・ライブ通信に関する研究 システム情報科学府 情報工学専攻 岡村研究室 修士2年 中川 和久

2. 発表内容 • 背景 • 通信路依存型ライブ通信 • 準備 • セキュアなライブ・ストリーミング • 研究の目的 • 送信側及び受信側双方が信頼し得るライブ・ストリーミングの実現 • 発表者の研究 • 課題 • 送受信される映像及び音声に送信元機器が認証情報を組み込む機構の実現 • 今後の予定 • まとめ

3. 背景 (1/5) • 大容量インターネット • ネットワークインフラの急速な発展 • 常時接続型ネットワークの普及 • 端末の性能向上 • Giga-bit Ethernetの普及 広帯域を使用する通信が普及しつつある． インターネットを介して端末同士が広帯域を使用するコンテンツの送受信が可能になる．

4. 背景 (2/5) • 動画通信 • テレビ会議システム・ライブ映像配信 • ライブ・ストリーミング • 送信側に接続された送信元機器からキャプチャされた映像及び音声を遠隔に存在する受信側に送信し，受信側で遅延無くそれらを再生する． 送信元機器 送信端末 受信端末 受信側機器 インターネット

5. 背景 (3/5) • 通信の堅牢性 • 外部から端末への侵入を防ぐ技術 • 侵入検知システム(IDS)・ファイヤーウォール • 端末間に悪意のある第三者が介入して，意図的に送受信されるデータを盗聴し，改竄する事態が想定される． • 通信路の暗号化 悪意ある第三者 悪意ある第三者がデータの盗聴を行っていても，暗号化が施されているので解読が不可能である． × 通信路の暗号化 通信路依存型なセキュア・ライブ通信の実現

6. 背景 (4/5) • 送信されるデータのすりかえ • 通信路の信頼性を確保しても解決できない問題がある． • 通信路を介して送受信されるデータそのものに依存する問題 • 動画通信において，悪意のある送信側が暗号化した通信路に送信する映像及び音声を，送信中にすりかえる事態を想定する． 本来の送信元機器 あらかじめ用意されている別の送信元機器 もしくはあらかじめ保存されていたストリーミング 送信元機器から送信される映像及び音声に信頼性があることが望まれる．

7. 背景 (5/5) • ライブ通信におけるすりかえ 悪意のある送信側にとって都合の悪い映像及び音声が受信側に送信されようとする． 送信元機器から逐次キャプチャされた映像及び音声を送信端末が受け付けなくなる． 受信側はあたかも現時点での映像が送信されているかのように，再生し続けることになる 送信側に悪意がある場合 × すりかえの発生 送信側への信頼を前提として動画通信が行われているのが現状である 都合の良い映像，もしくは別の送信元機器があらかじめ用意されている．

8. 準備 (1/5) • セキュアなライブ・ストリーミング • 広帯域 • DV (Digital Video) で撮影した映像をネットワークを介して送信する場合，使用帯域は片方向で30Mbpsが必要である. • 分散システム • 送信元機器からキャプチャされた映像及び音声データを，トランスポート層以下のプロトコルを利用して送信を行う. • 受信側は映像及び音声データを受け取り，あらかじめ指定された形式で再生を行う. • 通信路の暗号化 • 悪意のある第三者によるデータ改竄の防止 • 特定の相手と自由に通信

9. 準備 (2/5) • 分散システム • 実時間の特性を持ったデータの転送プロトコルを規定する． • トランスポートプロトコル上にタイミングの回復と欠落検出の機能を提供する． • RFC3550RTP (Real-time Transport Protocol) • タイムスタンプやセッションのメンバ識別子を格納する. • RFC3551RTCP (RTP Control Protocol) • QoSを監視し，進行中であるセッションにおける参加者の情報を伝達するプロトコルを規定する． データ 分散システムが準備する機構 RTP/RCTP トランスポート層 UDP --- データ送信先の識別によるプロセス間通信 IP ネットワーク層 --- ホストの識別及びルーティング インターネットヘッダ データリンク層 --- データ転送単位のフレーム化

10. 準備 (3/5) • 通信路の暗号化 • SSL (Secure Sockets Layer) • 公開鍵暗号や秘密鍵暗号，デジタル証明書，ハッシュ関数などのセキュリティ技術を組み合わせた暗号化プロトコル • OSI参照モデルでの第4層のトランスポート層と，その上位層との間で機能するように実装される． ペイロードデータ データ データ データ 分割 (必要ならば圧縮) データ MAC (メッセージ認証コード) 付加 暗号化 暗号化してSSLヘッダ付加

11. 準備 (4/5) • RTPパケットでの機密性保持 • SRTP (Secure Real-time Transport Protocol) • RTPデータパケットのペイロードセッションのみを暗号化するという方法で，パケットの機密性を保持する． RTPヘッダ ペイロードデータ DES共有鍵暗号方式で暗号化 RTPヘッダ 暗号化されたペイロードデータ ハッシュ関数を用いて認証タグを作成． 付加する． RTPヘッダ 暗号化されたペイロードデータ 認証タグ 認証される部分

12. 準備 (5/5) • VPN (Virtual Private Network) • ネットワーク上に仮想的な専用回線を作る技術 • 通信プロトコルレベルで暗号化を行う. • IPsec (IP Security Protocol) • アプリケーションで実装するのではなく，OS (オペレーションシステム) のネットワークスタックの一部として，またはゲートウェイの内部に実装する. • 第3層のネットワーク層での認証および暗号化を行うためのセキュリティ・プロトコルである． IPヘッダ セキュリティヘッダ ペイロードデータ セキュリティトレーラ UDPヘッダ ２台の端末間をIPsecで接続するトランスポートモード IPヘッダ セキュリティヘッダ IPヘッダ UDPヘッダ ペイロードデータ セキュリティトレーラ IPヘッダもIPsecの処理対象であり，セグメント間に存在するセキュリティゲートウェイをIPsecで接続するトンネルモード より上位層に親和的な，機密性の高い通信路を実現している．

13. 目的 (1/2) • すりかえの検出 • ペイロードデータそのものに対する信頼性 • SSLやSRTPでのペイロードデータの暗号化，IPsecでのIPパケットの暗号化が行われている． • 認証情報を組み込む機構の実現 • 送信元機器がすりかえの検出に必要な認証情報を組み込む機構を提案する． • ペイロードデータとは独立した認証情報を準備する． ライブ・ストリーミングにおいて送信側及び受信側双方が信頼し得る動画通信を実現する

14. 目的 (2/2) • 汎用性のある認証機構 • 既存の分散システムに依存しない設計でソフトウェア上で実現することを目的とする． • ある分散システムに特化した機構を作成することは容易ではあるが，それぞれの分散システムに適した機構を準備する必要がある． • 送信側で認証情報を組み込むミドルウェア，及び受信側でそれらを検証するミドルウェアを作成する手法について検討する． 既存の分散システムの機能をそのままに，汎用性のある認証機構としてソフトウェア上で実現することを目的とする．

15. 発表者の研究 (1/9) • 関連研究 • Audio and Video Watermarking • コンテンツの著作権情報といった特定の情報を埋め込む技術 • 提案するモデルは，電子透かしを分散システムにおける圧縮時及び解凍時に適応するものである． Eugene T. Lin et al. “Streaming video and rate scalable compression: what are the challenges for watermarking?” Journal of Electronic Imaging, vol. 13, Jan. 2004. インターネット 解凍 圧縮 多重パケット化 再結合 データ一重化 再生 映像・音声　ストリーミング 電子透かし 検証 電子透かし 組み込み 検証結果 送信側 受信側

16. 発表者の研究 (2/9) • 電子透かし • ストリーミングに対する電子透かしは，スケーラブルな動画圧縮を適応した場合は2つの点で影響しうる． ① ペイロードデータを処理して電子透かしが作成される場合は処理時間が発生する． コンテンツ配信には適しているが，ライブ・ストリーミングには不適である． ② 動画通信において，Ethernetフレームの欠落及び入れ替えが常に起こる． 受信側が順序通りにストリーミングを受信できない場合は，受信側の検出には工夫が必要である．

17. 発表者の研究 (3/9) • 本研究との関連性 • 認証情報 • コンテンツの著作権情報を埋め込むのではない． • ライブ通信に対応する為，処理時間による遅延を抑える． • 遅延を抑えた認証機構 • 受信側があらかじめ指定した規則に従って，送信側が認証情報を逐次ペイロードデータ単位で組み込む方式を提案する． • 受信側において，分散システムが映像及び音声を再生するプロセスとは別に，認証情報の検証を行うプロセスを起動する． 受信側 認証情報の検証 解凍 圧縮されたペイロードデータ data data data data 分散システムが取り扱うペイロードデータ 遅延無く再生

18. 発表者の研究 (4/9) • ライブ・ストリーミングを実現する分散システム • DVTS (Digital Video Transport System) • WIDEプロジェクトが製作したDV転送システム • http://www.sfc.wide.ad.jp/DVTS/

19. 発表者の研究 (5/9) • 分散システムとしての機能 • RTPを用いた動画通信 • IEEE1394を通じて民生用DV(Digital Video)カメラからキャプチャされた映像及び音声をRTP/UDP/IPパケット化して，遠隔に存在する受信側に送信している． • 非圧縮 • キャプチャされた映像及び音声データは加工されずにIPデータグラム化される． DV over IP技術

20. ～ ～ ～ ～ 発表者の研究 (6/9) • DV over IP技術でのペイロードデータ • DVフレーム • DIF(Digital Interface)シーケンスに分割される． • 1つのDIFシーケンスは150個のDIFブロックで構成される． ← 1byte (8bit) → ← 1byte (8bit) → ← 1byte (8bit) → ← 1byte (8bit) → Type DIF Block 1＊＊＊ DIF Seq M 111 DV data (77 bytes) Type：4bits DIF Seq：4bits 1 (0001) ヘッダ（Header） 3 (0011) 付属情報（Subcode） 5 (0101) 映像外部情報（VAUX） 7 (0111) 音声情報（Audio） 9 (1001) 映像情報（Video） DIFのシーケンス番号 M：1bit 25Mbps(SD)であれば0，50Mbps(HD)であれば1となる DIF Block :8bits 0～134(16進数で86)のDIFブロック番号が格納 全てのDIFブロックに認証情報を組み込むのは，大きな遅延が生じるので適切ではない．

21. 発表者の研究 (7/9) • フレーム・レート • 30fpsで映像及び音声のキャプチャを実現 • 民生用DVカメラは0.033秒毎に1回で10シーケンス分(DIFブロック1500個分)キャプチャを行う． • 30fpsでのIPデータグラム化 • 89フレームごとにRTPヘッダのタイムスタンプが更新 １７個のDIFブロック 20 bytes 8 bytes 12 bytes 14 bytes UDP Header EthernetⅡ Header IPv4 Header RTP Header DIF DIF DIF DIF DIF ・・・ × 88フレーム 20 bytes 8 bytes 12 bytes 14 bytes UDP Header IPv4 Header RTP Header DIF DIF DIF DIF EthernetⅡ Header × 1フレーム RTPでのタイムスタンプ情報は0.00001111ずつインクリメントされる． クロック・レート90Hzがあらかじめ指定されており，フレームレートには依存していない．

22. 発表者の研究 (8/9) • 認証機構の実現 • 認証情報 • 端末間における送信元機器の特定及び時間認証に基づいた動画通信の実現 • 送信側 • ペイロードデータ単位で認証情報を組み込む方式をフレーム・レートに則った設計を行う． • この手法により，既存の分散システムは，認証情報が既に組み込まれた映像及び音声を送受信するようになる． • 受信側 • 実際に映像及び音声をキャプチャした機器及び時間を特定する機構を提供する．

23. 発表者の研究 (9/9) • 送信元機器で認証情報を組み込む • 送信元機器が認証情報を組み込むライブ・ストリーミングの実現 送信元機器が認証情報を組み込む機構を，送信端末のミドルウェアとして実現する． 受信端末は， ①どの送信元機器から ②何時の映像が 受信されているのか検出が可能になる． 認証情報 data data data data data data data 再生 分散システムが取り扱うペイロードデータ￥ 認証情報の検証 送信側が指定した方式で認証情報を組み込む 認証情報が指定した通りに組み込まれているか検証した上で情報を取り出す

24. 課題 (1/3) • 認証情報そのものに依存する問題 • 送信元機器の特定 • 端末間であらかじめ共通の識別子を設定する． • それぞれの機器の固有情報を対応づける． 受信側が送信元機器をあらかじめ認識する必要性がある． VenderID(vid) ： 製造者を一意に識別 ProductID(pid)： 商品を一意に識別 USB機器 同一種類の機器は全て同じIDとなってしまう． 接続端子に関する情報も必要である． 送信側のどの接続端子から，どのような機器が接続されているかを明らかにする情報を，送信元機器の特定に利用する．

25. 課題 (2/3) • 時間認証 • 送信側及び受信側が正確な時間情報を共有 • 遅延の検出 • 映像及び音声のすりかえが発生 • 通信路が不安定 • 送信元機器のトラブル • 送信元機器が組み込んだ時間情報 • 受信側が参照する時間情報 送受信で必然的に発生する以上の遅延が検出される 受信側で遅延が検出されたことが出力される． 無遅延ですりかえが行われた事態においての検出は困難である． 分散システムの再送機能に起因し，別の検出機構を用いることで明らかになる． 未然に防ぐことは不可能である． 実現する機構は，ライブ・ストリーミングがキャプチャされた時間と受信側に到達した時間を明らかにするものである．

26. 課題 (3/3) • ソフトウェア上での実現に関する問題点 • 送信側でミドルウェアを改竄 • 送信元機器の設定において，送信側が受信側に正しく識別子を提供するのかという問題点が浮上する． • 時間情報をあらかじめ改竄して組み込む危険性もある． • 送信元機器で認証情報を組み込む機構は，悪意のある送信側によって改竄される事がないようにする必要がある． 無遅延ですりかえが行われた事態においての検出は困難である． 受信側が認証情報を指定する段階で対策を講じる必要がある． 初めからすりかえられたライブ・ストリーミングには対応出来ない ソフトウェアそのものの難読化

27. 今後の予定 (1/1) • 認証機構の決定 • セキュアであるということが前提である． • ミドルウェアの実装 • 遅延を抑えてのセキュア・ライブ通信が可能であるか検証する． • システムの評価 • 送信元機器の接続形態によって，多少のチューニングが必要になる．

28. まとめ (1/1) • 通信路依存型セキュア・ライブ動画 • ライブ通信におけるすりかえ • 認証情報を組み込む通信路非依存型セキュア・ライブ通信 • 送信元機器が認証情報を，受信側の意図通りに組み込む機構 • 受信側は，それらが正しく反映されているか検証する機構 • 分散システム • DVTSを例に挙げ検証 • 今後の予定 • セキュアであるという事を踏まえた上での実装