送信元機器を特定したリアルタイム
映像通信の実現に関する調査
システム情報科学府 情報工学専攻 岡村研究室
修士1年 中川 和久
2015/10/1
目次
•
•
•
•
•
•
背景
準備
論文紹介1
問題提起
論文紹介２
本研究との関連性
2015/10/1
1
背景 (1/3)
• 大容量インターネット
– 広帯域を利用するコンテンツの送受信が可能になる．
– リアルタイム動画通信が注目されている．
• ビデオ会議システム，ライブ映像配信
– Giga-bit Ethernetの普及が想定される．
• 大容量マルチメディアの通信が可能
2015/10/1
2
背景 (2/3)
• 信頼性のある通信路
– 端末間に悪意のある第三者が介入して，意図的にデータ
を盗聴し，改竄する事態が想定される．
– 通信路の暗号化が推奨されている．
• SSL
• IPSec
2015/10/1
3
背景 (3/3)
• 送信元機器を特定した動画通信
– リアルタイムの動画通信において，あらかじめ改竄した動
画を，暗号化した通信路に送信する事態を想定する．
• 通信路以外での悪意ある第三者，もしくは悪意ある送信者が改
竄した動画を受信側の端末に送信する．
端末間の通信路に暗号化を施しても，送信元への信頼を
前提として動画通信が行われているのが現状である
2015/10/1
4
準備 (1/4)
• マルチメディア通信
– ハイパーテキストや文字・画像・音声などを混在させ，統
合的に扱うことができる通信システムの総称を指す．
• テレビ会議，ライブ映像配信等もマルチメディア通信と呼ぶ．
• リアルタイム性
– いつまでに処理や通信を完了するかを保証する性質であ
る．
• 分散制御やマルチメディア処理において非常に重要な概念
• 動的スケジューリング
2015/10/1
5
準備 (2/4)
• 通信路の暗号化
– SSL (Secure Sockets Layer)
• 公開鍵暗号や秘密鍵暗号，デジタル証明書，ハッシュ関数など
のセキュリティ技術を組み合わせた暗号化プロトコルでOSI参照
モデルでの第5層のセッション層で機能するように実装される．
– IPSec
• 第3層のネットワーク層での認証および暗号化を行うためのセ
キュリティ・プロトコルであり，より上位層に親和的な，機密性の高
い通信路を実現している．
2015/10/1
6
準備 (3/4)
SSL
第5層
データ
第4層
データ
TCP
ヘッダ
データ
TCP
ヘッダ
第3層
データ
TCP
IP
ヘッダ ヘッダ
データ
TCP
IP
ヘッダ ヘッダ
第2層
データ
TCP
IP インターネット
ヘッダ ヘッダ
ヘッダ
データ
TCP
IP インターネット
ヘッダ ヘッダ
ヘッダ
データ
IPsec
第1層
2015/10/1
回線に信号送出
回線より信号取り出し
7
準備 (4/4)
• 送信元機器を特定する通信
– パケットを送信した端末を特定することは可能である．
• TCPパケットの送信元アドレス，送信元ポート番号
本研究では，動画通信を映像・音声フレームがそれぞれど
の端末のインターフェイスから送信されたかを表す情報をフ
レームに付加させることについて考察する．
フレームに電子透かしとして送信元機器の情報を付加させる．
ビデオ・ストリーミングに電子透かしを導入する研究に関して調査する．
2015/10/1
8
論文紹介1
Streaming video and rate scalable compression:
what are the challenges for watermarking?[1]
• 概要
– 本論文では，動画通信の概要，ビデオを圧縮及び解凍す
る技術について述べ，電子透かしの技術について報告し，
リアルタイムな動画に対する電子透かしの実現方法に関
する筆者の見解を紹介する．
2015/10/1
9
背景
• 動画通信システム
– 送信側は映像・音声のソースをデータとして符号化し，
データを送受信するネットワークにビデオ・ストリームとし
て転送する．受信側はそのビデオ・ストリームを受け取り，
復号化してビデオを利用者にリアルタイムで表示する．
符号化
復号化
Internet
IEEE1394
2015/10/1
10
動画通信 (1/3)
• ネットワーク
– リアルタイムで動画通信を行うネットワークの性能に関し
て，quality-of-service(QoS)に関する3つの問題がある．
1: 帯域
– 時間によってネットワークの帯域は変化する．
2: 遅延，ジッタ(タイミング・エラー)，待ち時間
– リアルタイムでデータの符号化・復号化が行われているた
め，遅延の制限が生じてしまう．
3: エラー発生
– 様々な理由によりデータが損失してしまう．ネットワークの
変化によるデータ損失もあり得る．
2015/10/1
11
動画通信 (2/3)
• IP (Internet Protocol)を用いたネットワーク転送
– パケット交換網を想定した動画配信が主流である．
• video over IPの実現
• RTP(Realtime-Transfer-Protocol)
• スケーラブルな画像圧縮
– 様々な帯域を持ったネットワークに対して，受信側が動画
配信を適切に受信するため，送信側は映像のソースに対
して圧縮を行う必要性がある．
• MPEG-4
• H.263+
2015/10/1
12
動画通信 (3/3)
• 動画通信システムの概要
圧縮
解凍
映像・音声フレームは圧縮されバイナリのストリームになり，必要なら
ば同期や制御に関する情報を付加させ，パケット化する．このときフ
レームの情報や時間情報と共に，FEC(Forward Error Correction)を
加えることも可能である．
2015/10/1
13
動画に対する電子透かし (1/5)
• 動画に対する電子透かし
– 画像の電子透かしと同じ要領で，それぞれのフレームに
電子透かしを独立的に施す考えが一般的である．
動画の特性を踏まえた電子透かしが必要である．
デジタルビデオは単に一定の時間間隔で，表示されたイメージの
系列ではないと考える．
• 連続したフレーム間に対する，空間的な相関関係を把握
する必要があり，全てのフレームが独立的ではなく，類似
性を持っていなくてはならない．
• すべてのフレームに同じ電子透かしを行うのは，攻撃者
に対して電子透かしの構造を教えかねない事となる．
2015/10/1
14
動画に対する電子透かし (2/5)
• ライブ・コンテンツの電子透かしやコピー・コントロール情報
を組み込む場合には，送信側のアプリケーションには，リア
ルタイムでの電子透かしが組み込まれることが必要とされ
る．
• コピー保護情報を検出する場合や，受信側のアプリケー
ションには，リアルタイムでの電子透かしの検出を行うこと
が必要とされる．
• 電子透かしによって，データ量を増やさないようにする．
① 動画圧縮でのブロック・モーション圧縮に適した電子透かしを考える．
画像ブロックと呼ばれる8×8画素単位で離散コサイン変換(DCT)を行
い，符号化をする．
② 動画圧縮に依存しない電子透かしを考える．
2015/10/1
15
動画に対する電子透かし (3/5)
• watermark into the intracoded picture of video
sequence
– 画像ブロックをグループ化し，グループに電子透かしを導
入する．
• DCTを行う画像圧縮に対して親和的な電子透かしである．
• グループ化する規模をDCT係数によって決める．
• GOP管理(独自に画像ブロックのグループ化を行う処理)を用い
た画像圧縮には適さない．
video frame
watermarking
8 pixel
2015/10/1
8 pixel
16
動画に対する電子透かし (4/5)
• spread-spectrum watermarking
– 擬似雑音を用いた電子透かしを，特定の(高周波成分・低
周波成分を多く含む)映像フレームに対して行う．
• 電子透かし検出の際に，模擬雑音を同期させる必要
がある．
2015/10/1
17
動画に対する電子透かし (5/5)
• watermark based on a temporal wavelet
transform
– 動画圧縮に依存せず，動画フレームをシーンに分割し，
それぞれのシーンにウエーブレット変換を行う．
• 電子透かしはウエーブレット変換に依存したものであるため，受
信側も同じように動画フレームを変換することで，電子透かしの
検出が可能である．
2015/10/1
18
リアルタイム動画に対する電子透かし (1/5)
• リアルタイム性を保持した電子透かし
– 動画圧縮に電子透かしに導入した方法で，ネットワークを
介した場合を考える．
• 提案するモデルは，リアルタイム性を保持した電子透かしを，既
存のネットワークにおける圧縮された動画通信システムに適応す
るものである．
video
streaming
compression
Watermark
Embedding
2015/10/1
Multiplexing
packetization
Network
Reassembly
Demultiplexing
Decompress
Watermark
detecting
video
streaming
answer
19
リアルタイム動画に対する電子透かし (2/5)
• ビデオ・ストリーミングに対する電子透かし
– リアルタイムでの，スケーラブルな動画圧縮を適応した場
合の電子透かしは2つの点で影響しうる．
① 受信側がビデオ・ストリーミングの復号化を違ったレートで行わなければな
らない場合がある．
受信側が正しくストリーミングを受信できない場合は，電子透かしが有効ではなくなる．
② 電子透かしが行われているビデオ・ストリームと行われていないビデ
オ・ストリームそれぞれを受け取った受信側での混同を無くすべきであ
る．
マルチキャストでの動画通信を考慮する必要がある．
実際にリアルタイム動画に対する電子透かしは，動画に対する電
子透かしとは違う問題点が生じる．
2015/10/1
20
リアルタイム動画に対する電子透かし (3/5)
• ネットワークと電子透かしの堅牢性
– 電子透かしはネットワーク内の転送時に消失してはなら
ない．
• ネットワーク障害にも十分強い電子透かしを作成できるか？
• ビデオ・ストリームの中のエラー制御や回復機能が電子透かしを
組み込む場合に効率的に機能するのか？
• 電子透かしを組み込む段階
– 映像・音声がソースの段階，ネットワークへ転送される段
階，受信側がパケットを受け取った段階，それぞれの段
階で電子透かしを組み込むことが可能である．
2015/10/1
21
リアルタイム動画に対する電子透かし (4/5)
• ビデオ・ストリームのコンテンツに対する検出
– ビデオ・ストリームに対する電子透かしは脆く，フレーム落
ちやフレーム混入，フレーム入れ替えが常に起こる．
• どのように受信側は検出を行うべきか？
• エラー隠蔽を参考した攻撃への対処方法
– エラー制御や回復機能は，電子透かしやビデオ・ストリー
ムを保護するために有益なものと捉えられているが，攻
撃者はエラー隠蔽の挙動を参考にして，電子透かしを無
効にする方法を画策する．
2015/10/1
22
リアルタイム動画に対する電子透かし (5/5)
• 電子透かしに対する評価
– 電子透かしに関しての客観的な安全の指標というものが
存在していない．
• 暗号化に関しては，素数判定や対数問題など数学的な比較が可
能である．
2015/10/1
23
結論
• 本論文は，動画通信の概念をまとめ，リアルタイム
動画通信に電子透かしを導入するための，克服す
べき課題を紹介している．
2015/10/1
24
問題提起
• 送信元の機器を特定するためのフレーム加工
– 電子透かしと同じ要領で，映像・音声フレームに何らかの
加工をリアルタイムで行う送信側と，リアルタイムでそれら
加工を認証する受信側を想定する．
通信路の暗号化を実現できるように，上位層での実装
を考える．
• 電子透かしの実装について触れられていない．
– リアルタイム性を保持した電子透かしに関して，実装及び
報告がなされていない．
実際に音声データに電子透かしを導入した研究を紹介する．
本発表では音声透かしと総称する．
2015/10/1
25
論文紹介2
Audio Watermarking Algorithm for Real-time Speech
Integrity and Authentication[2]
• 概要
– 端末間でのリアルタイムでの音声通話を，より信頼性の高
いものにするために，音声透かし(Audio Watermarking)
に着目し，公開鍵暗号方式を効率的に用いるためのアル
ゴリズムを示している．本論文の最後にGMS 610 (RPELTP:補完パルス増幅-長時間予測) coderに実装し，通常
の通信と音声透かしを行った通信との音声の質を比較し
ている．
2015/10/1
26
音声透かし (1/4)
• 背景
– IP通話に代表される音声通話には，大容量のマルチメ
ディア・データとリアルタイム通信それぞれに起因する特
性がある．
– ある程度のパケットロスは必ず生じるため，エンドユーザ
はそのようなパケットロスを感知することは出来ず，映像・
音声の質を左右するものではないということである．
信頼性の高い通信とマルチメディアデータの取り扱い
にはトレード・オフが必ず生じるということを示している．
2015/10/1
27
音声透かし (2/4)
• SRTP (Secure Real-time Transport Protocol)
– IETFで推奨された，音声や動画などのリアルタイム通信
を暗号化するプロトコルである．
• 暗号化ではRTPバケットをDES共有鍵暗号方式で計算し，その
結果を認証タグとして付加させる．ハッシュ関数にはHMAC-SHA
を用いている．
2015/10/1
28
音声透かし (3/4)
• SRTPの欠点
– MAC(メッセージ認証コード)を用いたハッシュ関数に欠点
があると考えられる．
• MACはデータの歪みに敏感である．通信時に歪んだデータを認
証時に破棄される可能性がある．
• MACは一般的にメッセージのチェックサムで，攻撃者はマルチメ
ディアのデータそのものを盗聴することが可能である．
• SRTP一連の技術が遅延を増加させるものである．
そこで，電子透かしを音声通信に導入することを考える．
2015/10/1
29
音声透かし (4/4)
• 音声透かしのアルゴリズム
– 時間内にメモリ領域を操作して人間の聴力に適うようなマ
スキング・モデルを開発する．
– 0.5秒毎の音声データに対して，音声透かしを実施する．
• 400バイト未満のデータとして，0.5秒間ずつのスピーチを圧縮し，
音声透かしを付加する方式が主流である．
• RTPを用いたパケット通信
– リアルタイム性を失わない通信を実現する．
2015/10/1
30
リアルタイム通信での音声透かし (1/3)
• 電子透かしを用いたセキュアなシステム
– 正しく送信されるマルチメディア・データの量は想定できな
いし，生じうるパケットロスの量も想定できない．
送信側・受信側共に1つの検出用電子透かしの技術を
共有する．それを用いて受信側はデータの整合性を確
認する
雑音の多い通信
路を想定する
2015/10/1
31
リアルタイム通信での音声透かし (2/3)
• Voice over IPに対するリアルタイム認証
– 公開鍵暗号法での信頼できる第三者(transServe)から共
有する音声透かし技術を受け取る．
• 端末が音声透かしに関する情報を受け取り通信が始まる．
• それぞれの出力される音声ストリームに電子透かしを組み込む．
同時にそれぞれが受け取る音声ストリームに共有技術を用いて
認証を行う．
(1) Request
user1
transServe
(3) transCerts
(1) Notification
(3) transCerts
user2
(2) Request
2015/10/1
32
リアルタイム通信での音声透かし (3/3)
• 本論文で提案された音声透かしシステム
– 信頼できる第三者からのkeyの情報を用いて，音声透か
しを行う．
• keyの情報には音声透かしを埋め込む位置が記述されている．
Key
speech
GSM
Vocoder
Network
Selector
Watermark
Embedding
comm_watermark
2015/10/1
Key
Selector
Watermark
Extraction
speech
Comparison
answer
comm_watermark
33
音声フレームのフォーマット
• RPE-LTP vocoderの出力
– GSM 610 coderは3ビットずつ52個のRPE(Regular
pulse excitation)パルスを0.2秒毎に生成される音声フ
レームに記録している．
LARs
LTP tag
実装時には0.2秒毎の音声フレームに
対する音声透かしの組み込み及び検
出を行う．
52 RPE
pulses
～
～ ・・・
・・・
～
・・・ ～
3bit
2015/10/1
34
導入されたアルゴリズム
• 音声透かしのモデル
– key:整数のペア{(p1,p2)|0<p1,p2<50}
• このkeyの値で指定するRPEパルスを選択し，それらの差の絶対値があらかじめ
共有している値になるように．ＲＰＥパルスを変化させる．
• 受信側での検出は，再びkeyの指定するRPEパルスの差の絶対値を取るもので
ある．
LARs
LTP tag
Embedding
ｘ’
ｘ
0
1
|ｘ= ｘ’|1
0
|ｘ= ｘ’|0
0
0
52 RPE
pulses
Extraction
～
～ ・・・
2015/10/1
・・・
～
・・・ ～
ｘ’
ｘ
0
0
35
実験
• Test1
user1からuser2への片方向の通信を行う．
speech
user2
user1
Pentium3
800MHz
356MB RAM
100Mb/s Ethernet LAN
Celeron 2GHz
256MB RAM
• Test2
帯域を低くして，混線状態のWLANで実験する．
speech
Pentium3
800MHz
356MB RAM
2015/10/1
user2
user1
11Mb/s busy WLAN
Celeron 2GHz
256MB RAM
36
実験結果 (1/2)
フレームの符号化・
復号化にかかる時間
フレームの音声透か
しに用いられる時間
音声透かしの時間／
符号化の時間
287.63μs
2.79μs
1%
GSM 610 coderでの音声透かしに関するオーバーヘッドについての結果で
ある．早い時間に音声透かしの組み込み及び検証が終わったことが分かる．
通信の成功率
パケット総
数
パケットロス，もし
くは遅延が生じた
パケット数
音声透かしの
エラーが生じた
パケット数
100Mb/s Ethernet
LAN (Test1)
16390
6
6
99.96%
11Mb/s busy
WLAN (Test2)
15952
48
32
99.89%
それぞれの実験において，通信の成功率もほぼ100%近い結果である．
2015/10/1
37
実験結果 (2/2)
上が音声透かしを施したスピーチで，下がオリジナルのスピーチであ
る．ほぼ遜色が無いことが分かる．
音声透かしを施したスピーチ
オリジナルのスピーチ
2015/10/1
38
結論
• 本論文は，端末間に信頼できる第三者をおいて，そ
こから受け取る鍵と共通の参照用電子透かしを用
いて音声透かし及び認証を行うシステムを作成した．
• 音声透かしの際のオーバーヘッド及び認証ミスも目
立たなく，音声透かしを行ったスピーチはオリジナル
のスピーチにほぼ等しいものであった．
2015/10/1
39
発表者の研究との関連
• 論文[1]
– リアルタイム動画通信に関して，電子透かしを導入するた
めの課題を提案した．今回発表者は送信元機器を特定
するため，リアルタイムでの電子透かしの組み込み及び
検出を実現する際に生じうる課題をまとめた．
• 論文[2]
– 実際に音声透かしを実現したシステムに関して，このシス
テムは広帯域を利用しない音声のみのマルチメディア通
信であったため，映像での実現に関して，より高速な認証
機構が必要である．
2015/10/1
40
© Copyright 2024 ExpyDoc
