多言語音声翻訳システム(アプリ「VoiceTra」)と …多言語音声翻訳システム(アプリ「VoiceTra」)とは ・31言語間の翻訳 ・うち23言語は音声入力、
計算機言語 システム論 発表
description
Transcript of 計算機言語 システム論 発表
![Page 1: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/1.jpg)
計算機言語システム論発表修士 1年 電子情報学専攻田浦研究室弘中 健
![Page 2: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/2.jpg)
紹介する論文• Discoverer: Automatic Protocol Reverse
Engineering from Network Traces– Weidong Cui, Jayanthkumar Kannan, Helen J.
Wang– 16th USENIX Security Symposium
![Page 3: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/3.jpg)
背景 (1)
• Application-level Protocolの仕様を特定したい–分かり切っているもの: TCP, HTTP
• セキュリティ的にも大切–仕様を元に、 inputを生成して penetration test–ネットワークにどのようなパケットが流れているか断定したい• Firewall system, IDSなどで解析をする時に仕様が必要
![Page 4: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/4.jpg)
背景 (2)
• 分からないプロトコル仕様の特定?– TCP, HTTPなどは分かり切っている– Applicationごとに勝手にいろいろある• 公でないものがほとんど
• 例: SAMBA– Microsoftの SMBプロトコルを 12年かけて追跡
• 例: messenger clientソフト– Multiple-protocol対応にするためには。。。
![Page 5: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/5.jpg)
問題• プロトコルの仕様を突き止める上での問題
– アプリケーションのソースは手に入らない• ネットワークトレースの解析が必要
– バイト列だけでは特定できない• Contentが違えば、メッセージプロトコルが同じでも、 byte列は変わる
• 今までの手法:– マニュアル作業
• 自動的にネットワークトレースを解析する手法が必要– ヒントが少ない:バイト列の流れる方向程度– プロトコルは多種多様– メッセージの内容は文脈依存
![Page 6: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/6.jpg)
問題定義• 通信の「プロトコル」とは–通信両端の有限オートマトン• 例えば、 session idなしで sessionの管理
–通信を流れるメッセージの「フォーマット」• メッセージのフィールドの構文・意味• 同じ formatでも Byte列が変わる
– Contentsが違えば変わる
![Page 7: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/7.jpg)
本論文の貢献• ネットワークトレースを用いた汎用的なプロトコル reverse engineering• プロトコルの全メッセージのフォーマットを推論する
– バイト列をトークン列に識別し、クラスタリングを行う– 一つのクラスタが一つのメッセージフォーマットに対応– Type-based sequence alignment algorithmでover-clusteringを避ける
• 状態遷移マシンの推論は future work
• HTTP, RPC, SMBのネットワークトレースを用いて評価する– Correctness: ~90%
• 導かれたフォーマットは一つのフォーマットに対応するか– Conciseness: ~5
• 幾つの導かれたフォーマットが一つのフォーマットに対応しているか– Coverage:
• トレース内のメッセージのどれだけが導かれたフォーマット達で説明されるか
![Page 8: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/8.jpg)
概要• Tokenization/簡単なクラスタリング
– バイト列をメッセージに区切る– メッセージをトークン列にする
• 各トークンは Binary/textの二種類– メッセージのトークン列パターンを用いて簡単なクラスタリング
• 再帰的クラスタリング– クラスタでフォーマットを推論– 擬似的にメッセージをパースする
• Format Distinguisherというフォーマットを決定づけるようなトークンを基に再帰的にクラスタリングし、繰り返す• マージング
– 分かれすぎたクラスタを合わせる– Type-based sequence alignment algorithm
![Page 9: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/9.jpg)
概要図
![Page 10: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/10.jpg)
Tokenization• 1つのメッセージを複数の tokenに分割する
– 恐らく、「メッセージ」は一方向に一度に流れる byte列– Asynchronous protocolはまだ対応していない
• Text/binaryの” token class”に振り分けられる– Text class
• 各byteをASCII文字と照らし合わせる• ある閾値以上の長さ (binary tokenを text tokenと間違えない )• Spaceがあれば区切る
– Binary class• Text class tokenに挟まれたそれ以外の byte• 1 byte = 1 token (conservative decision)
• この時点での誤検出は大丈夫 (後述 )
B T T BT
ASCII文字
space 短すぎB B B
![Page 11: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/11.jpg)
• Token Pattern ::= (direction, tok_class0, tok_class1, …., tok_classN)– e.g.: (Cli_2_serv, B, B, T, T, B)
• 同じ token patternのものを一つの cluster– Byte-patternだと、可変フィールドなどで狂う–同じ patternでもまだ違うmsg. formatもある
Token Pattern
![Page 12: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/12.jpg)
Recursive clusteringするには• より細かく clusteringするには、より詳細な semanticsに関する情報が必要– 最終的: 1 cluster 1 msg. format⇒
• Msg. format– Token pattern をより詳細にしたもの
• Msg. format ::= (token specification)*– Token specification• Token semantics• Token properties
![Page 13: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/13.jpg)
Token Specification Inference• Token property
– Token Class ( B or T )• 既に出来ている
– Constant or variable• Cluster内で同じ tokenを比較する
• Token Semantics– Length field, offset field token
• 候補– At most 4 consecutive binary token (4 byte: integerに値する )– Text token in dec. or hex.
• msg間で値の差を取る、それがmsg長の差に該当すればOK• クラスタ内ですべてのmsgで成立すれば、採用
– Cookie fieldなど– なしの tokenが殆ど
100110
10
OK
![Page 14: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/14.jpg)
Msg. Format Comparison• この時点では
– クラスタごとに一つの token patternがある– クラスタ内で Specification inferenceで複数のmsg. formatが生まれる
• それぞれのmsg. formatにフィットするmsg. sub clusterがある• 次に、二つのmsg. formatが同じかを判定する• Format Comparison
– 二つの formatの token semanticsを順に比較– Semanticsがない tokenに関しては値を比較
• 定数 matches 変数– 定数の値が変数が取る領域に重なる場合
• 変数 matches 変数– 二つの変数が取る領域に重なりがある場合
![Page 15: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/15.jpg)
Format Distinguisher
• Applicationがmsg.を読む時、その token以後のformatを既定する token– どのようにパースすればいいかを教える– 例えば、明示的なmsg. type field
• E.g.: HTTP → ‘OK’ ‘GET’ ‘CONTINUE’
• Tokenが FDである要件– 取る値の種類が閾知以下– 出来る sub-cluster サイズに下限– Sub-cluster:
• Msg. format with same value for target FD• Sub-clusterが違っても、同じ clusterである
![Page 16: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/16.jpg)
Emulation
• 一般に、 msg. formatは複数の FDを持つ• 実際のアプリケーションのように、 msg.
formatの左から順に走査し、 FDを見つけていく– 判定にはクラスタ内msg.達を使う
• FDが見つかったら、クラスタ内で再帰的に clusteringをする
![Page 17: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/17.jpg)
FDを使った recursive clustering
2. Subcluster内で Format inference
SmallerMsg. set
sizeval: Bval: A
1. FDの値でsubclusterに分けるFDCLUSTER
CLUSTER CLUSTER
New format
3. Format comparisonで
merge
![Page 18: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/18.jpg)
Merging
• いままでを繰り返すと、 over-clusteringが起きてしまう– 何百、何千の clusterが一つの実 formatに対応– 何らかの方法で clusterをmergeする必要がある
• Type-based sequence alignmentを採用– ⇔ conventional sequence alignment–出来た clusterを全対全で比較する
![Page 19: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/19.jpg)
Sequence Alignment• 遺伝子配列のmatchingなどに使われる• 考慮すること:
– 完全なmatchingは必ずしもない ( 進化 )• Point mutation
– ABCD → AACD• Gaps( 挿入、削除 )
– ABCD → ABCAD, AB_D
• アルゴリズムに必要なこと– 1要素が空白へのマッチ– 1要素が複数要素にマッチ– 例:最小編集距離
• msgのクラスタリングには使えない– 1要素が変数だったり、可変長だったりする
![Page 20: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/20.jpg)
Type-based Sequence Alignment (1)
• Seq. Alignmentは複数 Formatのmatchingに– Tokenが空白にマッチ– Tokenが複数 tokenにマッチ
• マッチングには依然の Format Matchingを使う–ただし、 Binary-Binary, Text-Textしか許さない
![Page 21: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/21.jpg)
• Seq. Alignmentの特徴を受け継ぐ– Gap:
• Text tokenはGapにマッチしてもよい
– Point Mutation:• N 個連続した Binary Token(合計Nbyte)は長さN以上の Text Tokenにマッチしてよい
• 制約– Gapの数は最大2まで– 最大 1tokenのmismatchまで許す
Type-based Sequence Alignment (2)
B T T T
B T T T
T
B T T T T
B T T T
![Page 22: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/22.jpg)
例題• Etherealによる SMBプロトコルの” Tree Connect AndX
Request” msg.
![Page 23: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/23.jpg)
回答• Discovererによるこの msg. の inference
![Page 24: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/24.jpg)
評価での設定• Max. message Prefix: 2048– 初めの 2048しか読まない
• Min. length of text token: 3bytes– 2byteの ASCII文字列は binaryにされる
• Min. msg. cluster size: 20• Max. distinct values for FD: 10
![Page 25: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/25.jpg)
評価 (1)
• Several million messagesの trace 入力– Honeyfarmのサイト– “busy enterprise”– HTTP, CIFS/SMB, and RPC プロトコルのmsg.• CIFS/SMB, RPCの msg 境界検出には etherealを使った
![Page 26: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/26.jpg)
評価 (2)• Discovererの結果と、 etherealを使って得られた「実 msg. format」と比較
– Ethereal:すでに formatが分かっているmsg.達に対するnetwork protocol analyzer
• Correctness– クラスタ内には 1つしか実 formatがない
• Conciseness– 一つの実 formatをいくつのクラスタで表現しているか
• Coverage– Msg. coverage
• 導かれた formatで説明できるmsg.の割合– 実 format coverage
• 説明できるmsgが従う実 formatの割合
![Page 27: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/27.jpg)
HTTP
• HTTP ヘッダーでは複数の Paramter : Valueペアがある– “set semantics”:含まれている parameterの集合で 1つの format。順番は自由• まだ対応していない
• 一つの集合でも Parameter:value ペアの順番が違うごとに別の formatだと思うことにした– 実 format数が 2696にも膨れ上がった
![Page 28: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/28.jpg)
HTTP: msg. distribution
• Long Tail– Most msg. in few msg.
formats⇒Low format coverage
• Cause:Min-size limit for clustering (20 msgs), unable to identify formats beyond #1000
• Should improve for larger data set size
![Page 29: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/29.jpg)
HTTP:Cumulative Dist. Function• Most clusters represent 1
true format– Good correctness
• Error reason– Cannot detect difference
between “Connection” and “Proxy-Connection” because same values follow
– Ethereal does not recognize “Proxy-Connection” and get two True formats
![Page 30: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/30.jpg)
HTTP
• Merge phase– 4465 3926⇒ clusters– Covered true formats: 865– Conciseness ratio: ~ 5
• Coverage– Msg. coverage
• 99.8 %– Format coverage
• 865/2696• Due to long tail distribution of msg.
![Page 31: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/31.jpg)
RPC
• Inferred 33 formats for 18 true formats
• Merge Phase:– 83 33 formats⇒
• An example where merging does well– Gives no reason why
![Page 32: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/32.jpg)
CIFS/SMB: Cum. Dist. Function• Only 57% of inferred formats
correspond to single true format– Due to Ethereal parse error:
split 1 true format into 2⇒improved to 90%
The remaining 10%2 True formats in question: difference of last field
“Stub data (XX bytes)”– Different XX value, Discoverer
thinks it’s just a variable field
![Page 33: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/33.jpg)
Current Limitations(1)
• 根本的な制限: Traceを使用することから出る– Trace依存性• Traceにない formatは検出できない• Traceで 1つしか値を取らないものは定数と思う
– Semanticsは事前に定義• Traceから新しい semanticsを生み出すことは出来ない
![Page 34: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/34.jpg)
Current Limitations(2)• Design Decisionによる制約、まだ改善の予知があるもの
– Semanticsがまだ限られている• Set semantics
– “AとBを含むものは一つの format”– 今は順番が違えば formatも違う
• ある fieldが配列だった場合、– 配列内でのoffsetを定義する– 配列の長さ
– 非同期プロトコルへは非対応• Msg.の区切りが分からない
– 一連のmsg.のセッションへは非対応• Msg.を独立に見ている
– 状態遷移オートマトンの推論はやっていない• Future Work
– プログラムの解析を織り交ぜる
![Page 35: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/35.jpg)
関連研究• マニュアル作業
– SAMBA project, messenger clients• Protocol Informatics Project
– Byte区切りで sequence alignment– 同じbyte sequenceは検出出来るが formatは無理
• RolePlayer, ScriptGen– Byte sequence alignmentだが、ヒューリスティックを使ってアドレス、cookieなどを検出し、調整する– Application-level replayが目的
• プロトコルのmsg. formatを全部特定したいという目的ではない• Ma et al.
– Trace内で一連のmsg.がなす sessionをプロトコル別に振り分ける• Byte offsetの分布、マルコフモデルなどを駆使する
– プロトコルは識別出来ればいい、msg.の formatの特定はしない• Grammar Inference
– 言語のサンプルをもとに、文法を特定する– 理論的に解けない
• 正規表現でも無理
![Page 36: 計算機言語 システム論 発表](https://reader036.fdocuments.net/reader036/viewer/2022081418/56815b4b550346895dc92e19/html5/thumbnails/36.jpg)
まとめ• Network Traceを使った自動的なmsg. format
inference• 再帰的な clustering, type-based sequence alignmentを用いた• 3つのプロトコルに関して、精度の高い inferenceが出来た– CIFS/SMB, RPC, HTTP
• 今後– プロトコル状態遷移マシーンの inference– プログラム解析も行っていく