Document

実行の振舞いを鍵情報とする
不正プログラムの動的検出方式
福岡大学
岩佐崇史
九州大学/科学技術振興機構さきがけ
井上弘士
安全で安定した情報化社会シス
テムの実現に向けて

安全性の向上（特にウィルス問題）




ホームサーバ
毎月８００の新種ウィルスが誕生（＊）
気づかないうちに侵入して突然暴走
個人の財産に対する直接的な脅威
次世代
携帯端末
低消費エネルギー化



バッテリ寿命の延長
利用者数の爆発
地球規模でのエネルギー問題
情報サービス会社
センサ
RFIDタグ
(*)板倉正俊「インターネット・セキュリティとは何か」日経BP社
マイクロプロセッサの発展
正規
プログラム
アタック
コード
・・・・・
ＩＬＰ
ＴＬＰ
分岐予測
スラック予測
命令パイプライン
スーパスカラ
アドレス予測
ＯＯＯ実行
シグナル・ゲーティング
ＤＶＳ
パイプライン統合
リサイジング
選択的活性化
値予測
プリフェッチ
キャッシュ
CTV
BPRF
クロック・ゲーティング
安全性と消費エネルギー
P
こんなご経験はありませんか？
やっぱり
かけてた！鍵かけたっけ？
鍵かけたっけ？
まあ、いいや！
研究目的
Architectural Support for
スタック・スマッシング検出（SWoPP’04）
不正プログラム実行検出（SWoPP’05）
ＩＬＰ
ＴＬＰ
分岐予測
スラック予測
命令パイプライン
シグナル・ゲーティング
ＤＶＳ
パイプライン統合
リサイジング
選択的活性化
スーパスカラ
アドレス予測
ＯＯＯ実行
値予測
プリフェッチ
キャッシュ
CTV
BPRF
クロック・ゲーティング
発表手順






はじめに
不正プログラム検出とその問題点
実行の振舞いを利用したプログラム認証
安全性に関する考察
性能/コストに関する定量的評価
おわりに
現在の主な不正プログラム対策
と問題点(１/２)

不正プログラム検出型
→既知の不正プログラム
を検出して駆除
静的検出
動的検出
ウィルス・スキャン
（パタン・マッチング）
ウィルス・スキャン
（ルール・マッチング）

認証済みプログラム実行型
→認められたプログラムのみ
を実行
静的認証
動的認証
証明書
問題点
問題点
 データベースが必要（ウィルス定義
リストやルール定義リスト）
 新種ウィルスに対応できない
 鍵照合プログラムが改ざんされた
場合は機能しない
 実行中に突然ウィルスが暴走した
場合は対応できない
現在の主な不正プログラム対策
と問題点(2/2)

認証済みプログラム実行型
（動的認証）
→実行プログラムが振舞い
モデルと一致するか検査
Program
compile
static analysis
問題点
プログラム・コードから特徴抽出する
ため、抽出可能な実行振舞いの種類
は限られる
正規プログラムに似た振舞いをする不
正プログラムは検出できない可能性
が高い
ソフトウェアによる振舞い検出のため
性能オーバヘッドが極めて大きい
object
code
Behavior
Model
CPU
Simulation
発表手順






はじめに
不正プログラム検出とその問題点
実行の振舞いを利用したプログラム認証
安全性に関する考察
性能/コストに関する定量的評価
おわりに
「実行の振舞い」を鍵情報とする
動的プログラム認証方式（提案）
問題点→CPUは何のためらいも無くウィルスを実行
解決策→CPUによる実行レベルでの動的プログラム認証
手段→「実行振舞い」を意図的に変更し鍵情報として利用
共通秘密鍵
共通秘密鍵
利用者側
セキュア・プロファイラ合成
アプリケーション
プログラム
セキュア・コンパイラ
発行者側
実行の振舞い
セキュア・プロファイラ
鍵挿入済み
（再構成可能ハードウェア）ダウンロードプログラム・コード
マイクロプロセッサ
実行の振舞い
「実行の振舞い」を鍵情報とする
動的プログラム認証方式

鍵情報を意図的にプログラム・コードへ挿入



実行途中に鍵情報を変更



様々な「鍵情報としての実行振舞い」を実現可能（安全
性の向上）
コンパイル時に安全性と消費エネルギーのトレード・オ
フ・ポイントを決定
より安全なプログラムの実行を実現
プログラムの各部分に対し個別に安全性の度合いを決
定可能
鍵検出を書換え可能ハードウェアで実現


鍵検出に伴う性能オーバヘッドを削除
鍵情報を変更可能（鍵が破られた場合でも対応可能）
鍵となる実行の振舞い（例）
～メモリアクセス・パタン～
「ある実行命令数毎に必ずアドレスAにアクセスする」
正規
プログラム
N命令

どのようにして実行振舞いを静的に制
御するか？
 制御フロー（分岐命令の存在）
 投機実行（分岐予測など）
 アウト・オブ・オーダ実行
プロファイラ
実行終了
実行制御の
乗っ取り！
アタック
コード
プロファイラ
実行振舞い制御と検出
基本
ブロック

分岐命令への対応


投機実行への対応（分岐予測）



基本ブロック・サイズの統一
鍵検出ハードウェアで対応
ロールバックに伴う無効化命令数を考慮
アウト・オブ・オーダ実行への対応

・・・
鍵となる
メモリアクセス命令
発表手順






はじめに
不正プログラム検出とその問題点
実行の振舞いを利用したプログラム認証
安全性に関する考察
性能/コストに関する定量的評価
おわりに
安全性に関する考察

不正プログラム実行可能性



鍵情報の推測容易性


秘密鍵情報の漏洩→安全な秘密鍵管理
不正プログラム実行命令数＜鍵命令実行間隔→短い間隔
外部からの実行振舞い観測→プロファイラのオンチップ化
不正プログラム伝播容易性

同一秘密鍵→ユーザ/プログラム毎で異なる実行の振舞い
を実現可能
発表手順






はじめに
不正プログラム検出とその問題点
実行の振舞いを利用したプログラム認証
安全性に関する考察
性能/コストに関する定量的評価
おわりに
性能/コスト・オーバヘッドに関する
定量的評価

評価項目



プログラム・コード・サイズ増加率
プログラム実行時間増加率
実験環境

ARMSimplescalar（動的認証方式の実装）


StrongARMモデル（イン・オーダー実行）
ベンチマーク・プログラム



SPECint95（129.compress）
統一サイズ：３０、２５、２０、１５、１０、５
１個の基本ブロックへの鍵命令挿入数：１
性能/コスト・オーバヘッド
Load for Key
Nop
Original
6
5
4
3
2
1
0

30
20
15
10
Basic-Block Size
5
2.5
2
1.5
1
0.5
0
コードサイズ


25
最大で6倍以上，最小でも約2倍
実行時間

StrongARM Model
•In-Order execution
•Branch Pred. (nottaken)
3
Norm. Execution Time
Normalized Code size
7
最大で60%，最小で10%の性能低下
25
20
15
10
Basic-Block Size
5
発表手順






はじめに
不正プログラム検出とその問題点
実行の振舞いを利用したプログラム認証
安全性に関する定性的評価
性能/コストに関する定量的評価
おわりに
おわりに

まとめ



実行の振舞いを活用した動的プログラム認証方式
安全性に関する考察
性能/コードサイズの定量的評価



コードサイズは約2倍（統一BBサイズ=5）
性能オーバヘッドは約10%（統一BBサイズ=5）
今後の課題


安全性に関するより詳細な考察
消費エネルギーと安全性のトレードオフ解析
Back-Up Slides …
本当の今度の課題（!?）

誰が「安全である」と保障してくれるのか？





現状はプログラム発行者（と前提）
全てのプログラムのライセンス化は非現実的！
「安全性の判定能力」を持たせるには？
ウィルス感染をどのようにしてユーザに伝えるか？
CMP（又はマルチ・コア）でこれまでの議論が通用す
るのか？


殆どの研究では「オンチップはセキュア」という前提
安全性向上のための性能オーバヘッドを隠蔽できない？
関連研究（動的アプローチ）

自己脆弱性の回避
 スタック・スマッシング検出




SW: LibSafe/Verify[USENIX00]
HW: SRAS[SPC03]
HW: SCache[WASSA04]
プログラム認証

暗号化
SCache: Dynamic+HW
キャッシュ・レベルでの実装
プロセッサとの分離
ランダムアクセス可能
大容量領域
コスト削減
消費エネルギーの解析
夜のお楽しみセッション
「今後の日本のコンピュータ・サイ
エンス研究をどう盛り上げるか？」
SWoPP2005@武雄
今夜
１９：３０スタート！

Download Report