時間認証

送信元機器で認証情報を組み込む通信路非依存型
セキュア・ライブ通信に関する研究
システム情報科学府情報工学専攻岡村研究室
修士2年中川和久
2006/5/23
発表内容
• 背景
– 通信路依存型ライブ通信
• 準備
– セキュアなライブ・ストリーミング
• 研究の目的
– 送信側及び受信側双方が信頼し得るライブ・ストリーミングの実現
• 発表者の研究
• 課題
– 送受信される映像及び音声に送信元機器が認証情報を組み込む機
構の実現
• 今後の予定
• まとめ
1
背景 (1/5)
• 大容量インターネット
– ネットワークインフラの急速な発展
– 常時接続型ネットワークの普及
広帯域を使用する通信が普及しつつある．
– 端末の性能向上
– Giga-bit Ethernetの普及
インターネットを介して端末同士が広帯域を使用す
るコンテンツの送受信が可能になる．
2
背景 (2/5)
• 動画通信
– テレビ会議システム・ライブ映像配信
• ライブ・ストリーミング
– 送信側に接続された送信元機器からキャプチャされた映
像及び音声を遠隔に存在する受信側に送信し，受信側で
遅延無くそれらを再生する．
送信元機器
送信端末
受信端末
受信側機器
インターネット
3
背景 (3/5)
• 通信の堅牢性
– 外部から端末への侵入を防ぐ技術
• 侵入検知システム(IDS)・ファイヤーウォール
– 端末間に悪意のある第三者が介入して，意図的に送受信
されるデータを盗聴し，改竄する事態が想定される．
• 通信路の暗号化
悪意ある第三者
×
悪意ある第三者がデータの盗聴
を行っていても，暗号化が施され
ているので解読が不可能である．
通信路の暗号化
通信路依存型なセキュア・ライブ通信の実現
4
背景 (4/5)
• 送信されるデータのすりかえ
– 通信路の信頼性を確保しても解決できない問題がある．
• 通信路を介して送受信されるデータそのものに依存する問題
• 動画通信において，悪意のある送信側が暗号化した通信路に送
信する映像及び音声を，送信中にすりかえる事態を想定する．
本来の送信元機器
あらかじめ用意されてい
る別の送信元機器
もしくはあらかじめ保存さ
れていたストリーミング
送信元機器から送信される映像及び音声に信頼性があることが
望まれる．
5
背景 (5/5)
• ライブ通信におけるすりかえ
悪意のある送信側にとって都
合の悪い映像及び音声が受
信側に送信されようとする．
送信元機器から逐次キャプチャ
送信側に悪意がある場合
受信側はあたかも現時点での映
された映像及び音声を送信端末
像が送信されているかのように，
が受け付けなくなる．
再生し続けることになる
×
すりかえの発生
送信側への信頼を前提として
動画通信が行われているのが
現状である
都合の良い映像，もしくは別の送
信元機器があらかじめ用意され
ている．
6
準備 (1/5)
• セキュアなライブ・ストリーミング
– 広帯域
• DV (Digital Video) で撮影した映像をネットワークを介して送信す
る場合，使用帯域は片方向で30Mbpsが必要である.
– 分散システム
• 送信元機器からキャプチャされた映像及び音声データを，トランス
ポート層以下のプロトコルを利用して送信を行う.
• 受信側は映像及び音声データを受け取り，あらかじめ指定された
形式で再生を行う.
– 通信路の暗号化
• 悪意のある第三者によるデータ改竄の防止
• 特定の相手と自由に通信
7
準備 (2/5)
• 分散システム
– 実時間の特性を持ったデータの転送プロトコルを規定する．
• トランスポートプロトコル上にタイミングの回復と欠落検出の機能を
提供する．
• RFC3550 RTP (Real-time Transport Protocol)
– タイムスタンプやセッションのメンバ識別子を格納する.
• RFC3551 RTCP (RTP Control Protocol)
– QoSを監視し，進行中であるセッションにおける参加者の情報を伝達
するプロトコルを規定する．
データ
RTP/RCTP
UDP
分散システムが準備する機構
トランスポート層 --- データ送信先の識別によるプロセス間通信
IP
ネットワーク層
--- ホストの識別及びルーティング
インターネットヘッダ
データリンク層
--- データ転送単位のフレーム化
8
準備 (3/5)
• 通信路の暗号化
– SSL (Secure Sockets Layer)
• 公開鍵暗号や秘密鍵暗号，デジタル証明書，ハッシュ関数などの
セキュリティ技術を組み合わせた暗号化プロトコル
• OSI参照モデルでの第4層のトランスポート層と，その上位層との
間で機能するように実装される．
ペイロードデータ
分割 (必要ならば圧縮)
データ
MAC (メッセージ認証コード) 付加
データ
暗号化してSSLヘッダ付加
データ
データ
暗号化
9
準備 (4/5)
• RTPパケットでの機密性保持
– SRTP (Secure Real-time Transport Protocol)
• RTPデータパケットのペイロードセッションのみを暗号化するという
方法で，パケットの機密性を保持する．
RTPヘッダ
ペイロードデータ
DES共有鍵暗号方式で暗号化
RTPヘッダ
暗号化されたペイロードデータ
ハッシュ関数を用いて認証タグを作成．
付加する．
RTPヘッダ
暗号化されたペイロードデータ
認証タグ
認証される部分
10
準備 (5/5)
• VPN (Virtual Private Network)
– ネットワーク上に仮想的な専用回線を作る技術
• 通信プロトコルレベルで暗号化を行う.
– IPsec (IP Security Protocol)
• アプリケーションで実装するのではなく，OS (オペレーションシステ
ム) のネットワークスタックの一部として，またはゲートウェイの内
部に実装する.
• 第3層のネットワーク層での認証および暗号化を行うためのセキュ
リティ・プロトコルである．
IPヘッダ
セキュリティヘッダ
UDPヘッダ
ペイロードデータ
セキュリティトレーラ
２台の端末間をIPsecで接続するトランスポートモード
IPヘッダ
セキュリティヘッダ
IPヘッダ
UDPヘッダ
ペイロードデータ
セキュリティトレーラ
IPヘッダもIPsecの処理対象であり，セグメント間に存在するセキュリティゲートウェイをIPsecで接続するトンネルモード
より上位層に親和的な，機密性の高い通信路を実現している．
11
目的 (1/2)
• すりかえの検出
– ペイロードデータそのものに対する信頼性
• SSLやSRTPでのペイロードデータの暗号化，IPsecでのIPパケッ
トの暗号化が行われている．
– 認証情報を組み込む機構の実現
• 送信元機器がすりかえの検出に必要な認証情報を組み込む機構
を提案する．
• ペイロードデータとは独立した認証情報を準備する．
ライブ・ストリーミングにおいて送信側及び受信側双方が信頼し得る動
画通信を実現する
12
目的 (2/2)
• 汎用性のある認証機構
– 既存の分散システムに依存しない設計でソフトウェア上で
実現することを目的とする．
• ある分散システムに特化した機構を作成することは容易ではある
が，それぞれの分散システムに適した機構を準備する必要がある．
• 送信側で認証情報を組み込むミドルウェア，及び受信側でそれら
を検証するミドルウェアを作成する手法について検討する．
既存の分散システムの機能をそのままに，汎用性のある認証機構とし
てソフトウェア上で実現することを目的とする．
13
発表者の研究 (1/9)
• 関連研究
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.
– Audio and Video Watermarking
• コンテンツの著作権情報といった特定の情報を埋め込む技術
• 提案するモデルは，電子透かしを分散システムにおける圧縮時及
び解凍時に適応するものである．
インターネット
圧縮
多重パケット化
再結合
データ一重化
解凍
再生
映像・音声
ストリーミング
電子透かし
検証
電子透かし
組み込み
送信側
受信側
検証結果
14
発表者の研究 (2/9)
• 電子透かし
– ストリーミングに対する電子透かしは，スケーラブルな動画
圧縮を適応した場合は2つの点で影響しうる．
① ペイロードデータを処理して電子透かしが作成される場合は処理時間
が発生する．
コンテンツ配信には適しているが，ライブ・ストリーミングには不適である．
② 動画通信において，Ethernetフレームの欠落及び入れ替えが常に起
こる．
受信側が順序通りにストリーミングを受信できない場合は，受信側の検出には工夫
が必要である．
15
発表者の研究 (3/9)
• 本研究との関連性
– 認証情報
• コンテンツの著作権情報を埋め込むのではない．
• ライブ通信に対応する為，処理時間による遅延を抑える．
– 遅延を抑えた認証機構
• 受信側があらかじめ指定した規則に従って，送信側が認証情報を
逐次ペイロードデータ単位で組み込む方式を提案する．
• 受信側において，分散システムが映像及び音声を再生するプロセ
スとは別に，認証情報の検証を行うプロセスを起動する．
受信側
認証情報の検証
解凍
圧縮されたペイロードデータ
data
data
data
分散システムが取り扱う
ペイロードデータ
data
遅延無く再生
16
発表者の研究 (4/9)
• ライブ・ストリーミングを実現する分散システム
– DVTS (Digital Video Transport System)
• WIDEプロジェクトが製作したDV転送システム
• http://www.sfc.wide.ad.jp/DVTS/
17
発表者の研究 (5/9)
• 分散システムとしての機能
– RTPを用いた動画通信
• IEEE1394を通じて民生用DV(Digital Video)カメラからキャプチャ
された映像及び音声をRTP/UDP/IPパケット化して，遠隔に存在す
る受信側に送信している．
– 非圧縮
• キャプチャされた映像及び音声データは加工されずにIPデータグ
ラム化される．
DV over IP技術
18
発表者の研究 (6/9)
• DV over IP技術でのペイロードデータ
– DVフレーム
• DIF(Digital Interface)シーケンスに分割される．
• 1つのDIFシーケンスは150個のDIFブロックで構成される．
← 1byte (8bit) →
Type
← 1byte (8bit) →
1＊＊＊ DIF Seq M 111
～
～
← 1byte (8bit) →
← 1byte (8bit) →
DIF Block
～
～
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ブロックに認証情報を組み込むのは，大きな遅延が生じるので適切ではない．
19
発表者の研究 (7/9)
• フレーム・レート
– 30fpsで映像及び音声のキャプチャを実現
• 民生用DVカメラは0.033秒毎に1回で10シーケンス分(DIFブロッ
ク1500個分)キャプチャを行う．
• 30fpsでのIPデータグラム化
– 89フレームごとにRTPヘッダのタイムスタンプが更新
１７個のDIFブロック
14 bytes 20 bytes 8 bytes
EthernetⅡ IPv4
Header
Header
12 bytes
UDP
Header
RTP
Header
14 bytes 20 bytes 8 bytes
12 bytes
EthernetⅡ IPv4
Header
Header
UDP
Header
RTP
Header
DIF
DIF
DIF
・・・
DIF
DIF
DIF
DIF
DIF
DIF
× 88フレーム
× 1フレーム
RTPでのタイムスタンプ情報は0.00001111ずつインクリメントされる．
クロック・レート90Hzがあらかじめ指定されており，フレームレートには依存していない．
20
発表者の研究 (8/9)
• 認証機構の実現
– 認証情報
• 端末間における送信元機器の特定及び時間認証に基づいた動画
通信の実現
– 送信側
• ペイロードデータ単位で認証情報を組み込む方式をフレーム・レー
トに則った設計を行う．
• この手法により，既存の分散システムは，認証情報が既に組み込
まれた映像及び音声を送受信するようになる．
– 受信側
• 実際に映像及び音声をキャプチャした機器及び時間を特定する機
構を提供する．
21
発表者の研究 (9/9)
• 送信元機器で認証情報を組み込む
– 送信元機器が認証情報を組み込むライブ・ストリーミング
の実現
送信元機器が認証情報を組み込む機
構を，送信端末のミドルウェアとして実
現する．
受信端末は，
①どの送信元機器から ②何時の映像が
受信されているのか検出が可能になる．
認証情報
data
data
data
分散システムが取り扱う
ペイロードデータ￥
送信側が指定した方式
で認証情報を組み込む
data
data
data
data
再生
認証情報の検証
認証情報が指定した通りに組み込まれ
ているか検証した上で情報を取り出す
22
課題 (1/3)
• 認証情報そのものに依存する問題
– 送信元機器の特定
• 端末間であらかじめ共通の識別子を設定する．
受信側が送信元機器をあらかじめ認識する必要性がある．
• それぞれの機器の固有情報を対応づける．
USB機器
VenderID(vid) ：製造者を一意に識別
ProductID(pid)：商品を一意に識別
同一種類の機器は全て同じIDとなってしまう．
接続端子に関する情報も必要である．
送信側のどの接続端子から，どのような機器が接続されているか
を明らかにする情報を，送信元機器の特定に利用する．
23
課題 (2/3)
• 時間認証
– 送信側及び受信側が正確な時間情報を共有
• 送信元機器が組み込んだ時間情報
• 受信側が参照する時間情報
送受信で必然的に発生する以上の遅延が検出される
受信側で遅延が検出されたことが出力される．
– 遅延の検出
• 映像及び音声のすりかえが発生
無遅延ですりかえが行われた事態においての検出は困難である．
• 通信路が不安定
分散システムの再送機能に起因し，別の検出機構を用いることで明らかになる．
• 送信元機器のトラブル
未然に防ぐことは不可能である．
実現する機構は，ライブ・ストリーミングがキャプチャされた時間と
受信側に到達した時間を明らかにするものである．
24
課題 (3/3)
• ソフトウェア上での実現に関する問題点
– 送信側でミドルウェアを改竄
• 送信元機器の設定において，送信側が受信側に正しく識別子を提
供するのかという問題点が浮上する．
無遅延ですりかえが行われた事態においての検出は困難である．
• 時間情報をあらかじめ改竄して組み込む危険性もある．
受信側が認証情報を指定する段階で対策を講じる必要がある．
初めからすりかえられたライブ・ストリーミングには対応出来ない
• 送信元機器で認証情報を組み込む機構は，悪意のある送信側に
よって改竄される事がないようにする必要がある．
ソフトウェアそのものの難読化
25
今後の予定 (1/1)
• 認証機構の決定
– セキュアであるということが前提である．
• ミドルウェアの実装
– 遅延を抑えてのセキュア・ライブ通信が可能であるか検証
する．
• システムの評価
– 送信元機器の接続形態によって，多少のチューニングが
必要になる．
26
まとめ (1/1)
• 通信路依存型セキュア・ライブ動画
– ライブ通信におけるすりかえ
• 認証情報を組み込む通信路非依存型セキュア・ライブ通信
– 送信元機器が認証情報を，受信側の意図通りに組み込む機構
– 受信側は，それらが正しく反映されているか検証する機構
• 分散システム
– DVTSを例に挙げ検証
• 今後の予定
– セキュアであるという事を踏まえた上での実装
27

Download Report