実行の振舞いを鍵情報とする 不正プログラムの動的検出方式

Post on 22-Jan-2016

38 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

実行の振舞いを鍵情報とする 不正プログラムの動的検出方式. 福岡大学 岩佐崇史 九州大学 / 科学技術振興機構さきがけ  井上弘士. 安全で安定した情報化社会システムの実現に向けて. 安全性の向上(特にウィルス問題) 毎月800の新種ウィルスが誕生 (*) 気づかないうちに侵入して突然暴走 個人の財産に対する直接的な脅威 低消費エネルギー化 バッテリ寿命の延長 利用者数の爆発 地球規模でのエネルギー問題. (*) 板倉正俊「インターネット・セキュリティとは何か」日経 BP 社. 正規 プログラム. アタック コード. スラック予測. - PowerPoint PPT Presentation

TRANSCRIPT

実行の振舞いを鍵情報とする不正プログラムの動的検出方

福岡大学岩佐崇史

九州大学 /科学技術振興機構さきがけ 井上弘士

安全で安定した情報化社会システムの実現に向けて

安全性の向上(特にウィルス問題) 毎月800の新種ウィルスが誕生(*) 気づかないうちに侵入して突然暴走 個人の財産に対する直接的な脅威

低消費エネルギー化 バッテリ寿命の延長 利用者数の爆発 地球規模でのエネルギー問題

(*)板倉正俊「インターネット・セキュリティとは何か」日経 BP社

RFIDタグ

センサ

情報サービス会社ホームサーバ

次世代携帯端末

RFIDタグ

センサ

情報サービス会社ホームサーバ

次世代携帯端末

正規プログラム

マイクロプロセッサの発展

OOO実行

命令パイプラインスーパスカラ

分岐予測

アドレス予測値予測

クロック・ゲーティング

シグナル・ゲーティング

リサイジング 選択的活性化

アタックコード

・・・・・

キャッシュ

プリフェッチ

ILP TLP

スラック予測

パイプライン統合

DVS

CTV BPRF

こんなご経験はありませんか?

安全性と消費エネルギーやっぱりかけてた!PP 鍵かけたっけ?

??

??

鍵かけたっけ??

??

?

まあ、いいや!

Architectural Support for

研究目的

OOO実行

命令パイプラインスーパスカ

ILP TLP分岐予測

アドレス予測

値予測

キャッシュ

プリフェッチ

パイプライン統合

DVS

クロック・ゲーティング

シグナル・ゲーティング

リサイジング 選択的活性化

スラック予測

CTV BPRF

スタック・スマッシング検出( SWoPP’04)不正プログラム実行検出( SWoPP’05)

発表手順 はじめに 不正プログラム検出とその問題点 実行の振舞いを利用したプログラム認

証 安全性に関する考察 性能 / コストに関する定量的評価 おわりに

不正プログラム検出型→既知の不正プログラムを検出して駆除

認証済みプログラム実行型→認められたプログラムのみを実行

ウィルス・スキャン(パタン・マッチング)

ウィルス・スキャン(ルール・マッチング)

静的検出 動的検出証明書静的認証 動的認証

問題点データベースが必要(ウィルス定義リストやルール定義リスト)

新種ウィルスに対応できない

問題点鍵照合プログラムが改ざんされた場合は機能しない

実行中に突然ウィルスが暴走した場合は対応できない

現在の主な不正プログラム対策と問題点 (1 /2 )

現在の主な不正プログラム対策と問題点 (2/2)

認証済みプログラム実行型(動的認証)→実行プログラムが振舞いモデルと一致するか検査

問題点プログラム・コードから特徴抽出するため、抽出可能な実行振舞いの種類は限られる

正規プログラムに似た振舞いをする不正プログラムは検出できない可能性が高い

ソフトウェアによる振舞い検出のため性能オーバヘッドが極めて大きい

Program

static analysisBehavior

Model

compile object code

CPU

Simulation

発表手順 はじめに 不正プログラム検出とその問題点 実行の振舞いを利用したプログラム認証

安全性に関する考察 性能 /コストに関する定量的評価 おわりに

「実行の振舞い」を鍵情報とする動的プログラム認証方式(提案)

利用者側 発行者側

アプリケーションプログラム

共通秘密鍵

セキュア・プロファイラ(再構成可能ハードウェア)

マイクロプロセッサ

セキュア・プロファイラ合成

鍵挿入済みプログラム・コード

セキュア・コンパイラ

ダウンロード

共通秘密鍵 アプリケーションプログラム

共通秘密鍵

セキュア・プロファイラ(再構成可能ハードウェア)

マイクロプロセッサ

セキュア・プロファイラ合成

鍵挿入済みプログラム・コード

セキュア・コンパイラ

ダウンロード

共通秘密鍵

問題点→ CPUは何のためらいも無くウィルスを実行 解決策→ CPUによる実行レベルでの動的プログラム認証 手段→「実行振舞い」を意図的に変更し鍵情報として利用

実行の振舞い実行の振舞い

「実行の振舞い」を鍵情報とする動的プログラム認証方式

鍵情報を意図的にプログラム・コードへ挿入 様々な「鍵情報としての実行振舞い」を実現可能(安全性の向上)

コンパイル時に安全性と消費エネルギーのトレード・オフ・ポイントを決定

実行途中に鍵情報を変更 より安全なプログラムの実行を実現 プログラムの各部分に対し個別に安全性の度合いを決定可能

鍵検出を書換え可能ハードウェアで実現 鍵検出に伴う性能オーバヘッドを削除 鍵情報を変更可能(鍵が破られた場合でも対応可能)

鍵となる実行の振舞い(例)~メモリアクセス・パタン~

正規プログラム 実行終了

アタックコード

実行制御の乗っ取り!

プロファイラ

どのようにして実行振舞いを静的に制御するか?

制御フロー(分岐命令の存在) 投機実行(分岐予測など) アウト・オブ・オーダ実行

「ある実行命令数毎に必ずアドレス Aにアクセスする」

N命令

プロファイラ

実行振舞い制御と検出

分岐命令への対応 基本ブロック・サイズの統一

投機実行への対応(分岐予測) 鍵検出ハードウェアで対応 ロールバックに伴う無効化命令数を考慮

アウト・オブ・オーダ実行への対応

・・・

基本ブロック

鍵となるメモリアクセス命令

発表手順 はじめに 不正プログラム検出とその問題点 実行の振舞いを利用したプログラム認証

安全性に関する考察 性能 /コストに関する定量的評価 おわりに

安全性に関する考察 不正プログラム実行可能性

秘密鍵情報の漏洩→安全な秘密鍵管理 不正プログラム実行命令数<鍵命令実行間隔→短い間隔

鍵情報の推測容易性 外部からの実行振舞い観測→プロファイラのオンチップ化

不正プログラム伝播容易性 同一秘密鍵→ユーザ /プログラム毎で異なる実行の振舞いを実現可能

発表手順 はじめに 不正プログラム検出とその問題点 実行の振舞いを利用したプログラム認証

安全性に関する考察 性能 /コストに関する定量的評価 おわりに

性能 /コスト・オーバヘッドに関する定量的評価

評価項目 プログラム・コード・サイズ増加率 プログラム実行時間増加率

実験環境 ARMSimplescalar (動的認証方式の実装)

StrongARM モデル(イン・オーダー実行) ベンチマーク・プログラム

SPECint95 ( 129.compress ) 統一サイズ:30、25、20、15、10、5 1個の基本ブロックへの鍵命令挿入数:1

性能 /コスト・オーバヘッド

コードサイズ 最大で 6倍以上,最小でも約 2倍

実行時間 最大で 60%,最小で 10%の性能低下

0

1

2

3

4

5

6

7

No

rmal

ized

Co

de

size

30 25 20 15 10 5Basic-Block Size

0

0.5

1

1.5

2

2.5

3

No

rm.

Exe

cuti

on

Tim

e

25 20 15 10 5

Basic-Block Size

StrongARM Model •In-Order execution•Branch Pred. (nottaken)

Load for KeyNopOriginal

発表手順 はじめに 不正プログラム検出とその問題点 実行の振舞いを利用したプログラム認証

安全性に関する定性的評価 性能 /コストに関する定量的評価 おわりに

おわりに まとめ

実行の振舞いを活用した動的プログラム認証方式 安全性に関する考察 性能 /コードサイズの定量的評価

コードサイズは約 2倍(統一 BBサイズ=5) 性能オーバヘッドは約 10%(統一 BBサイズ=5)

今後の課題 安全性に関するより詳細な考察 消費エネルギーと安全性のトレードオフ解析

Back-Up Slides …

本当の今度の課題( !?) 誰が「安全である」と保障してくれるのか?

現状はプログラム発行者(と前提) 全てのプログラムのライセンス化は非現実的! 「安全性の判定能力」を持たせるには?

ウィルス感染をどのようにしてユーザに伝えるか?

CMP(又はマルチ・コア)でこれまでの議論が通用するのか? 殆どの研究では「オンチップはセキュア」という前提 安全性向上のための性能オーバヘッドを隠蔽できない?

関連研究(動的アプローチ)自己脆弱性の回避

スタック・スマッシング検出 SW: LibSafe/Verify[USENIX00] HW: SRAS[SPC03] HW: SCache[WASSA04]

プログラム認証暗号化

SCache: Dynamic+HW

キャッシュ・レベルでの実装プロセッサとの分離ランダムアクセス可能大容量領域コスト削減消費エネルギーの解析

夜のお楽しみセッション

「今後の日本のコンピュータ・サイエンス研究をどう盛り上げ

るか?」

SWoPP2005@武雄今夜

19:30スタート!

top related