中間発表用発表資料 送信元機器で認証情報を組み込む通信路非依存型 セキュア・ライブ通信に関する研究 システム情報科学府 情報工学専攻 岡村研究室 修士2年 中川 和久 2006/12/25 発表内容 • 背景 – ライブ通信における送信元機器のすりかえ • 目的及び方針 – 送信側及び受信側双方が信頼し得るライブ通信の実現 • 提案手法 – 送信元機器における認証情報の組み込み • ライブ通信に対応した認証機構の実現 – インターフェースにおけるデータ転送プロトコル – ソフトウェアインターフェース・認証基盤対応アプリケーション – 動画ストリーミングにおける認証機構 • まとめ – 今後の予定 2006/12/25 1 背景 (1/3) - 広帯域を利用した通信の普及 – インターネットを介したライブ通信 • 実時間性（リアルタイム性）が要求されるデータ通信 • ライブ配信における動画ストリーミング – 送信端末が送信元機器から転送された映像及び音声データを，遠 隔に存在する受信端末に送信し，受信端末でデータの受信及び再 生を並行して逐次行う方式 送信元機器 データ転送 data 送信端末 IPパケット化 IP/UDP data インターネット データストリーム伝送 IP/UDP data 受信端末 データ取り出し IP/UDP 出力機器 データ再生 data data 送信開始 受信開始 データを逐次再生 2006/12/25 2 背景 (2/3) - ライブ通信における脅威と通信路の暗号化 – インターネットにおける脅威 • 不正アクセスの傾向 – 今までは愉快犯が多かったが，近年は悪質なプロ化へ． 攻撃は誰にも気づかれないように，セキュリティ対策の弱いと思われるところを 狙い，情報盗聴及び改竄といった目的を実行する． 対象はアプリケーション・データベースレベルといったアプリケーション層を狙っ たものが主流になる． – 通信路依存型のセキュアなライブ通信 • IPsec・SSLといったセキュリティプロトコル – 悪意ある攻撃者によるデータの盗聴及び改竄を通信路において防止 する． 通信路の暗号化技術を用いて端末間での信頼性を確保 （セキュアな範囲） 2006/12/25 3 背景 (3/3) - 送信端末におけるデータのすりかえ – ライブ通信におけるデータのすりかえ • 端末間での信頼性を確保だけでは解決出来ない問題が浮上する． • ライブ通信中に，受信側が受信するデータストリームが，送信側で 悪意のある攻撃者によってすりかえられる事態を想定する． – 送信側が暗号化された通信路にすりかえたデータを送信する． 攻撃者が予め用意され すりかえの発生 ていた別のデータ，もしく は別の送信元機器から のデータへすりかえる． IP/UDP data? data × 通信路の暗号化 悪意を持った攻撃者が受信 端末にデータを送信している 送信端末に侵入してしまう． 2006/12/25 受信端末はあたかも送信端末 端末間において，IPsecを用いて通信路での から現時点でのデータを受信 改竄を防いだとしても，悪意のある攻撃者に しているかのように，処理し続 よって送信端末そのものに侵入され，データ けることになる． そのものが改竄される問題がある． 4 目的 - 送信側及び受信側双方が信頼し得るライブ通信の実現 たとえ端末間の通信路に暗号化を施していたとしても，送信端末への信 頼を前提としてライブ通信が行われている． 端末同士において改竄無くライブ通信が行われている事を検証する機構 の実現を目指す．（すりかえの検知を可能にする機構の実現） これまでは送信端末と受信端末との間で認証がなされていた． 受信端末が知り得る身分証明は送信端末のものであって，送信端末が送信する データそのものについては身分証明が出来なかった． （送信端末におけるすりかえという事態に対応が出来ない） – ライブ通信で送受信される大容量のデータストリームに対 する認証を実現 • ライブ通信において，送信端末でのデータのすり替えを，受信端 末でデータの受信及び処理と並行して検知可能にする． 2006/12/25 5 提案手法 (1/2) - 認証情報の組み込み – 送信元機器に認証情報を組み込むアイデア • ライブ通信において送信端末で送信するデータを生成する段階 までに遡って，その段階で認証情報を組み込む． • 受信端末において，データを生成する送信元機器そのものの身 分証明を可能にする． ※ データストリームへ認証情報を組み込む 認証情報を検証し，特定の送信元 送信元機器と受信端末との間での信 通信路を暗号化させることで，端末間 機器からのデータを受信している 頼性を認証情報を用いて確保する． での信頼性の確保が可能である． ことを確認する． セキュアな範囲を送信元機器と受信端末に拡張させる． セキュアな範囲は端末間である． data IP/UDP 認証情報の 組み込み 2006/12/25 data IP/UDP data IP/UDP data 検証 通信路をセキュアにするのではなく，認証情報をセキュアにすることで， データストリームを構成するデータそのものに対する認証を実現する． 6 提案手法 (2/2) - 本研究で取り組む内容 – ライブ通信に対応した認証機構の研究 • 送信元機器から転送されるデータを改造しない認証機構を実現 – 電子透かしのようなデータそのものの品質劣化は避ける． – 送信用アプリケーションがデータを処理する（IPカプセル化を行う） 以前に認証データを組み込む． 送信用アプリケーションがデータを処理する時点で，送信元機器から転 送されたデータはどのような状態でIPカプセル化されるか検証する． 悪意のある攻撃者はIPカプセル化される段階で情報をすりかえる． • 送信元機器及び送信端末間のデータ転送を研究する事で，大容 量データストリームに対応した認証機構を実現する． – 送信側で認証情報を組み込むインターフェース 2006/12/25 7 認証機構の実現 (1/4) - ハードウェアインターフェースにおけるプロトコル – 送信元機器と送信端末におけるデータ転送プロトコル • ハードウェアインターフェース – 送信元機器と送信端末実際にデータ転送を行う • アイソクロナス転送 (isochronous transfer) – USB及びIEEE1394でサポートするデータ転送方式 – 他のインターフェースがバスを使用している際，そのインターフェース に対するトラフィックが高くても，一定時間辺りの転送量が保証される． データの転送が途中で途切れないので，動画や音声などのストリーミング データの転送に向いている． 送信元機器が一定間隔で データを生成し，送信元機器 上のインターフェースが指定 するレジスタ空間へ格納する． 2006/12/25 IEEE1394 Interface IEEE1394 Interface インターフェースが，送信端末 との接続形態に応じたデータ 転送プロトコルで，送信端末が 指定するメモリ上へデータを転 送する． 8 認証機構の実現 (2/4) - データ転送プロトコルのトランザクションにおけるデータ量 – トランザクションにおけるデータ量 • USB2.0及びIEEE1394におけるアイソクロナス転送は，データ・パ ケット転送に関するトランザクションが125μsの周期で実行されて いる． 送信元機器からデータが125μsの間隔で格納されるメモリ領域 （送信端末が指定） （100μs＝0.1ms＝0.0001s） USB2.0でパケットに乗せるデータ（ペイロー ド）のサイズは，転送単位（エンドポイント）毎 に設定が可能である． IEEE1394 Interface data 最短125μs IEEE1394 Interface 最大1024byte IEEE1394でパケットに乗せるデータのサイズ は，バス上でのデータ転送時間が62μs未満 になるように定められている． data 転送レート100Mbpsのバスでは最大データ長は512byte 転送レート200Mbpsのバスでは最大データ長は1024byte data data data 2006/12/25 9 認証機構の実現 (3/4) - 送信元機器それぞれに則ったデータ生成 – 送信元機器におけるデータ生成に関する規格 • 送信元機器ではデータが生成された情報を，ハードウェアインター フェースが指定するレジスタ空間へ転送する為のメモリ領域が存 在する． 映像及び音声に関するデータが送信元機器のメモリ領域で更新される度 に認証情報を発行する事で，データそのものの身分証明を可能にするに は，送信元機器の性能に基づいた実現を要求する事になる． （例） DV NTSC （IEC61834-2） 映像：30fps，色情報：24(bit)，YUV=4:1:1で12bit，DVcodec：1/5 音声：非圧縮リニアPIM 16bit/48kHz,2ch 1秒間に720 * 480 * 24 / 2 * 29.97 / 5 / 8 + 16 * 48,000 * 2 / 8 = 3,299,289.6byteのデータが生成される． 125μs間隔で送信端末が指定するメモリ領域へ1024byteずつ 転送される事が想定される． カメラのメモリ量に依存して，どれだけのデータが生成される度 に認証情報が付けられるのかタイミングが決定する必要がある． 2006/12/25 10 認証機構の実現 (4/4) - 認証情報の組み込み – 送信元機器が認証情報を組み込むタイミング • 送信元機器において，一定間隔で転送されるデータに付随させ る技術を提案する． – アイソクロナス転送で転送されるデータ量に関する規定は存在しな いので，冗長性を持たせても問題は無い ※ 送信元機器におけるハードウェアインターフェースとしての実装 事前に認証情報を送信元機器内に記憶させ，認証情報を組み込んだデータが送 信端末に転送されるように，送信元機器内でハードウェア機構として実現させる． セキュアなライブ通信はハードウェアにおける認証情報に依存される． ※ 送信端末におけるソフトウェアインターフェースとしての実装 既に認証情報を用意されているメモリ領域をソフトウェアで実現し，送信元機器か ら転送されたデータがそれら領域上に格納されるようにする． 汎用性のある実現方法であり，認証情報の柔軟な対応が期待される． 2006/12/25 11 認証情報の実現 (1/2) - ハードウェアインターフェース – 送信元機器それぞれが対応した識別子を用意する． • ハードウェアインターフェースとして実現させる場合，製造された周 辺機器それぞれに独自のID識別子を割り振る． – 認証情報はその識別子を秘匿ID化させたものである． • 公開鍵暗号または共通鍵暗号を利用してID識別子を事前に暗号 化し，暗号化されたビット列を送信元機器に記憶させる． 認証情報の検証 AAA-xxx-012345 ID識別子（識別子として原則公開） 暗号化専用の アルゴリズム 復号鍵を受信端末は事前 に入手している． abcpqxyz 復号化専用の アルゴリズム abcpqxyz 認証情報（秘匿ID化・非公開） 送信元機器に認証情報をビット列 として記憶させる． 秘匿ID情報 （非公開） data ID 認証情報の組み込み 2006/12/25 AAA-xxx-012345 data ID 認証情報の検出 12 認証情報の実現 (2/2) - ソフトウェアインターフェース – 認証情報の指定 • 受信端末がデータストリームの中に認証情報として組み込む情報 を送信端末へ伝える． – 送信端末はソフトウェアインターフェースへ認証情報の指定を行う． – ソフトウェアインターフェースは – 送信端末は送信元機器が認証情報も組み込んでいるかのように解 釈する． 送信元機器からデータが転送されるメモリ領域 （ソフトウェアインターフェースが指定） ソフトウェアインターフェースを経由する時に は既に認証情報が組み込まれている． software Interface data 2006/12/25 abcpqxyz 受信側で指定した認証情報 data data data ID 13 提案手法の概要 (1/2) - 認証情報を組み込むインターフェースを用いた認証基盤 – ライブ通信中において攻撃者によるすり替えを防止する． 受信端末はID情報を元に共通 ライブ通信開始前に受信端末 ID data data abcpqxyz 送信端末はソフトウェアインター software 鍵で暗号化し秘匿ID情報を送 は送信端末へ認証情報の内 IP/UDP IP/UDP ID data ID data事前に送信端末は受信端末へ送 data フェースへ認証情報を組み込む Interface data 信端末に渡す， 容を伝える． 信元機器のID情報を告知する． よう設定を行う． 認証情報の 認証情報の 検証 abcpqxyz 送信端末は秘匿ID情報を送信元 AAA-xxx-012345 abcpqxyz 組み込み 組み込み 機器に記憶させる． ID data data abcpqxyz AAA-xxx-012345 暗号及び復号処理の負荷は受信端末が担う分，受信端末が認証情報の指定が可能 である為，認証情報がトラッキングされても，以後の認証情報の利用に支障はない． 2006/12/25 14 提案手法の概要 (2/2) - 認証情報が組み込まれたデータストリームの送信 – ライブ通信で想定されるアプリケーション • 実時間性を維持した通信を実現するため，可能な限り最大量， データをIPカプセル化を行う． ハードウェアインターフェースでのデータ転送プロトコルが実 際にデータ転送する間隔と，アプリケーションがメモリ上へ バッファさせる間隔のズレにより隙間が生じる IPカプセル化が行われるメモリ領域 （アプリケーションが指定） data data data data data data data data data data data data data data アプリケーションが送信端末上でのインターフェースの参照し，IPカプセル化を行うメ モリ上へバッファし，先頭から逐次IPカプセル化を行う． ① data ② data data data data data data data data data data data data data data ID data ID data ID data ID data ID data ID data ID ID ①では実際に転送するデータが極端に減ってしまうので，②のように間隔のズレ を埋めるような認証情報の組み込みを実現する． 2006/12/25 15 本研究で取り組む技術 - ソフトウェアインターフェース・認証基盤対応アプリケーション – ソフトウェアインターフェース • 送信側で認証情報を組み込むソフトウェアインターフェース – 送信元機器で認証情報を組み込む機構を，送信元機器が送信端 末へ転送された時に実現する． – 認証情報そのものを送信元機器を大量に組み込む． – 認証基盤対応アプリケーション • 認証情報が組み込まれたデータを送受信するアプリケーション – ライブ通信可能な限り最大量，データをIPカプセル化を行う． • 受信側で認証情報を検証するプロセス – 大量に組み込まれた認証情報に対して，絶えず検証を行う． 認証基盤対応アプリケーション software Interface 2006/12/25 16 動画ストリーミングにおける認証機構 (1/4) - 大容量の動画ストリーミングを行うアプリケーション – 動画配信アプリケーションに認証機構を実現 • 大容量データストリームが行われている． – アプリケーションは，送信端末上でのソフトウェアインターフェースが 指定するメモリ領域を参照し，IPカプセル化を行うメモリ上へ格納する． そして，先頭から逐次IPカプセル化し，受信側へ送信する． – 受信端末では，通信され再構成されたデータに組み込まれた認証情 報を検証する機構を，再生プロセスとは別に実現する． ※ 送信端末 ※ ※ 受信端末 ※ 2006/12/25.13:00.01 OK 2006/12/25.13:00.02 OK 2006/12/25.13:00.03 OK 2006/12/25.13:00.04 OK ・・・ software Interface data data 本来アプリケーションが取り 扱うデータ量を拡張 2006/12/25 data data 認証情報を検出し，本来アプリ ケーションが必要としているデー タへ再構築するプロセス 検証機構 17 動画ストリーミングにおける認証機構 (2/4) - 動画配信アプリケーションでの実現 – 送信端末におけるIPカプセル化 • 認証情報が組み込まれたデータストリームを動画配信アプリケー ションが転送するデータとして認識する必要がある． – 認証情報が組み込まれているフレームを単独に用意する． data data data data ID どのフレームに認証情報が格納されているのか悪意のある攻撃者に検知されないように考える． – データストリームの受信元機器への受け渡し • 認証情報が組み込まれているフレームを検出する機構を用意す る必要がある． data data data data ID 受信用アプリケーションが必要なデータのみを取り 出し，あらかじめ用意したメモリ上へバッファする． 2006/12/25 ID 実時間性を維持した検証結果の出力 を実現させる． 18 動画ストリーミングにおける認証機構 (3/4) - 送信端末 – 送信端末実装時における主要な機能 • 認証情報を組み込むソフトウェアインターフェース data data data ① アプリケーションは，送信元機器からデータが転送されているメモリ領域から，IPカプセル 化を行うメモリ領域の先頭から逐次データを格納する． data data data data data data data data data data data data data data ID ② ソフトウェアインターフェースは，アプリケーションによってIPカプセル化が行われる直前に なるとメモリバッファの末尾に認証情報が格納する． フレームを満たす認証情報の格納 data data data data data data data data data data data data data data ID ③ 認証情報が組み込まれたデータを，本来のデータストリーム同様，メモリバッファされた先 頭から逐次IPカプセル化させる 送信側におけるIPカプセル化を行うメモリ参照領域の拡張 UDPパケットが転送可能な最大量を搭載したイーサネットフレーム（複数存在） 残りのデータ及び認証情報を搭載し最大量搭載するイーサネットフレーム（1つ存在） 2006/12/25 19 動画ストリーミングにおける認証機構 (4/4) - 受信端末 – 受信端末実装時における主要な機能 • 送信端末から2種類のイーサネットフレームを受信する． ID data ① 受信端末は送信端末から2種類のイーサネットフレームを受信し，アプリケーションはそ れらデータを指定するメモリ領域に格納する． data data data data data data data data data data data data data data ID アプリケーションが参照するメモリ領域 ② アプリケーションは認証情報を参照させないメモリ参照を行う事で，認証情報が検出され た映像及び音声データを受信することになる．同時に認証情報をあらかじめ用意したメモ リ領域へ格納する． 認証情報を検証用のメモリ領域へ退避させ検証するプロセス ID ID ID ライブ通信開始時に指定した認証情報と同じかを検証する． ③ 認証情報を逐次検証し，ログとして検証結果をテキスト形式で出力させる． 認証情報の実時間性を維持した検証 2006/12/25 20 まとめ - 今後の予定 – すりかえ検知を可能にする認証機構 • 送信元機器及び送信端末間のデータ転送を研究する事で，大容量デー タストリームに対応した認証機構を実現する． – ライブ通信に対応した認証機構 • 送信側で認証情報を組み込むソフトウェアインターフェース • 既に認証情報が組み込まれたデータを送受信するアプリケーション • 受信側で認証情報を検証するプロセス – 今後の予定 • 動画配信アプリケーションの実装 – 民生用デジタルビデオカメラカメラ（DV NTSC）を実装の対象とする DVTS (Digital Video Transport System) WIDEプロジェクトが製作したDV転送システム http://www.sfc.wide.ad.jp/DVTS/ • 論文執筆 2006/12/25 21 2006/12/25 22 遅延の検証 (1/5) - 低遅延を保障した認証情報の組み込みについての解析 – ライブ・ストリーミングにおける実時間性という制約 • 30fpsでの動画キャプチャでは100ms(33msecの3倍)以下といっ た低遅延での認証情報の組み込み及び検出機構を目指す． • 特に復号化でどれだけ処理に時間が掛かるかをシミュレートする 事で，実際に認証情報を組み込む時間間隔を決定する事が可能 になる． 受信端末は動画配信アプリケーションを 起動するので，高性能な端末であると想 定する． AAA-xxx-012345 復号化専用の アルゴリズム abcpqxyz 解析に用いる端末は，DVTS※が利用可 能なシステムである事を前提とする． DVTS (Digital Video Transport System) WIDEプロジェクトが製作したDV転送システ ム 2006/12/25 http://www.sfc.wide.ad.jp/DVTS/ 秘匿ID情報 （非公開） ID data 23 遅延の検証 (2/5) - 復号化の処理時間を算出 – AiCrypto http://mars.elcom.nitech.ac.jp/security/aicrypto.html • 名古屋工業大学・岩田研で公開されているフリーの暗号ライブラリ • 暗号化及び復号化に関するモジュールが関数で実現されている – 計測方法 • プログラムのステップで暗号化及び復号化の関数に突入する際に タイマーをスタート． • プロセス時間を取得するtimes()，日付と時間を返すftim()を用いる． • 戻り値を得て関数から抜けた時にタイマーをストップ． 処理速度(kBps) ＝ 処理したデータ量 (関数に投入するデータ数 × 8 ×再起プロセス回数 ) 処理時間(s) × 1024 – 計測環境 • PentiumⅢ866MHz，768MB，Fedora Core4 (kernel-2.6.11-1) 2006/12/25 24 遅延の検証 (3/5) - DES (Data Encryption Standard) – 共通鍵暗号アルゴリズム • データを64bit長のブロックに分割し，各ブロックを56bit長の鍵で 暗号化する共通暗号鍵アルゴリズム． • Triple-DESは，DESを3重に繰り返すことで暗号強度を高めてい る． • ECB (Electronic Code Block) モード – 最終的に各ブロックをつなぎ合わせる． • CBC (Cipher Block Chaining) モード – すでに暗号化が済んでいるデータを利用して，次のブロック を暗号化することで強度を高められる． 2006/12/25 25 遅延の検証 (4/5) - 共通鍵暗号方式と公開鍵暗号方式 – 公開鍵暗号方式 • 不可逆性のアルゴリズム • RSA (Rivest Shamir Adleman) – オイラーの定理と2つの素数を使って公開鍵暗号の仕掛けを実現． » 公開鍵 (n,d) で暗号化，秘密鍵 (e) で復号化を行う． » 秘密鍵 (n,d) で暗号化，公開鍵 (e) で復号化を行う． ※ 公開鍵暗号化方式の暗号化方式 暗号化アルゴリズム 特徴 暗号化の強度 RSA暗号 公開鍵の長さは128bitから 256bitが主流 素因数分解の困難性 ElGamal暗号 生成されるキーは元の情報の 2倍 離散対数問題の困難性 楕円曲線暗号 (EC-ElGamal) 短い鍵で高い安全性が確保で き署名時の計算を高速 有限体の楕円曲線における 離散対数問題の困難性 http://www.ipa.go.jp/security/enc/CRYPTREC/index.html 2006/12/25 26 遅延の検証 (5/5) - 測定結果 共通鍵暗号方式 (DES) 秘匿化する ID情報 DES Encryption (ECB) DES Decryption (ECB) DES Encryption (CBC) DES Decryption (CBC) 3DES Encryption (ECB) 3DES Decryption (ECB) 3DES Encryption (CBC) 3DES Decryption (CBC) 64bit 0.010 s 0.010 s 0.020 s 0.010 s 0.080 s 0.080 s 0.080 s 0.080 s 128bit 0.020 S 0.015 s 0.020 s 0.015 s 0.160 s 0.160 s 0.160 s 0.160 s 公開鍵暗号方式 (RSA) 秘匿化する ID情報 RSA Encryption RSA Decryption 64bit 0.200 S 0.010 S 128bit 0.250 S 0.600 S 256bit 0.300 S 1.000 S 2006/12/25 RSAでID情報が128bitを超える時，復号化に100ms以上 時間が経過してしまう恐れがある． RSAで認証機構を実現するには，フレームレートに則った 認証情報の付加に対して，検出時にはある程度間引きを 行う必要があると考えられる． 27
© Copyright 2024 ExpyDoc
