1. 実行の振舞いを鍵情報とする不正プログラムの動的検出方式実行の振舞いを鍵情報とする不正プログラムの動的検出方式 福岡大学 岩佐崇史 九州大学/科学技術振興機構さきがけ　 井上弘士

2. 安全で安定した情報化社会システムの実現に向けて安全で安定した情報化社会システムの実現に向けて • 安全性の向上（特にウィルス問題） • 毎月８００の新種ウィルスが誕生（＊） • 気づかないうちに侵入して突然暴走 • 個人の財産に対する直接的な脅威 • 低消費エネルギー化 • バッテリ寿命の延長 • 利用者数の爆発 • 地球規模でのエネルギー問題 (*)板倉正俊「インターネット・セキュリティとは何か」日経BP社

3. 正規 プログラム アタック コード スラック予測 シグナル・ゲーティング ＩＬＰ ＴＬＰ ＤＶＳ 分岐予測 命令パイプライン パイプライン統合 リサイジング スーパスカラ 選択的活性化 値予測 アドレス予測 CTV BPRF プリフェッチ ＯＯＯ実行 クロック・ゲーティング キャッシュ マイクロプロセッサの発展 Security ・・・・・ High Performance Low Power/Energy

4. やっぱり かけてた！ 鍵かけたっけ？ 鍵かけたっけ？ ? ? ? ? ? ? ? ? まあ、いいや！ 安全性と消費エネルギー こんなご経験はありませんか？ P

5. Architectural Support for 研究目的 Security スタック・スマッシング検出（SWoPP’04） 不正プログラム実行検出（SWoPP’05） スラック予測 シグナル・ゲーティング ＩＬＰ ＴＬＰ ＤＶＳ 分岐予測 命令パイプライン パイプライン統合 リサイジング スーパスカラ 選択的活性化 値予測 High Performance Low Power/Energy アドレス予測 CTV BPRF プリフェッチ ＯＯＯ実行 クロック・ゲーティング キャッシュ

6. 発表手順 • はじめに • 不正プログラム検出とその問題点 • 実行の振舞いを利用したプログラム認証 • 安全性に関する考察 • 性能/コストに関する定量的評価 • おわりに

7. 不正プログラム検出型 →既知の不正プログラムを検出して駆除 認証済みプログラム実行型 →認められたプログラムのみを実行 静的認証 静的検出 動的認証 動的検出 証明書 ウィルス・スキャン （パタン・マッチング） ウィルス・スキャン （ルール・マッチング） • 問題点 • データベースが必要（ウィルス定義リストやルール定義リスト） • 新種ウィルスに対応できない • 問題点 • 鍵照合プログラムが改ざんされた場合は機能しない • 実行中に突然ウィルスが暴走した場合は対応できない 現在の主な不正プログラム対策と問題点(１/２)

8. 認証済みプログラム実行型（動的認証） →実行プログラムが振舞いモデルと一致するか検査 Program object code compile Behavior Model static analysis CPU Simulation 現在の主な不正プログラム対策と問題点(2/2) 問題点 • プログラム・コードから特徴抽出するため、抽出可能な実行振舞いの種類は限られる • 正規プログラムに似た振舞いをする不正プログラムは検出できない可能性が高い • ソフトウェアによる振舞い検出のため性能オーバヘッドが極めて大きい

9. 発表手順 • はじめに • 不正プログラム検出とその問題点 • 実行の振舞いを利用したプログラム認証 • 安全性に関する考察 • 性能/コストに関する定量的評価 • おわりに

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

11. 「実行の振舞い」を鍵情報とする動的プログラム認証方式「実行の振舞い」を鍵情報とする動的プログラム認証方式 • 鍵情報を意図的にプログラム・コードへ挿入 • 様々な「鍵情報としての実行振舞い」を実現可能（安全性の向上） • コンパイル時に安全性と消費エネルギーのトレード・オフ・ポイントを決定 • 実行途中に鍵情報を変更 • より安全なプログラムの実行を実現 • プログラムの各部分に対し個別に安全性の度合いを決定可能 • 鍵検出を書換え可能ハードウェアで実現 • 鍵検出に伴う性能オーバヘッドを削除 • 鍵情報を変更可能（鍵が破られた場合でも対応可能）

12. 「ある実行命令数毎に必ずアドレスAにアクセスする」「ある実行命令数毎に必ずアドレスAにアクセスする」 アタック コード プロファイラ 正規 プログラム N命令 プロファイラ 鍵となる実行の振舞い（例）～メモリアクセス・パタン～ 実行終了 実行制御の 乗っ取り！ • どのようにして実行振舞いを静的に制御するか？ • 制御フロー（分岐命令の存在） • 投機実行（分岐予測など） • アウト・オブ・オーダ実行

13. 基本 ブロック 実行振舞い制御と検出 鍵となる メモリアクセス命令 • 分岐命令への対応 • 基本ブロック・サイズの統一 • 投機実行への対応（分岐予測） • 鍵検出ハードウェアで対応 • ロールバックに伴う無効化命令数を考慮 • アウト・オブ・オーダ実行への対応 • ・・・

14. 発表手順 • はじめに • 不正プログラム検出とその問題点 • 実行の振舞いを利用したプログラム認証 • 安全性に関する考察 • 性能/コストに関する定量的評価 • おわりに

15. 安全性に関する考察 • 不正プログラム実行可能性 • 秘密鍵情報の漏洩→安全な秘密鍵管理 • 不正プログラム実行命令数＜鍵命令実行間隔→短い間隔 • 鍵情報の推測容易性 • 外部からの実行振舞い観測→プロファイラのオンチップ化 • 不正プログラム伝播容易性 • 同一秘密鍵→ユーザ/プログラム毎で異なる実行の振舞いを実現可能

16. 発表手順 • はじめに • 不正プログラム検出とその問題点 • 実行の振舞いを利用したプログラム認証 • 安全性に関する考察 • 性能/コストに関する定量的評価 • おわりに

17. 性能/コスト・オーバヘッドに関する定量的評価性能/コスト・オーバヘッドに関する定量的評価 • 評価項目 • プログラム・コード・サイズ増加率 • プログラム実行時間増加率 • 実験環境 • ARMSimplescalar（動的認証方式の実装） • StrongARMモデル（イン・オーダー実行） • ベンチマーク・プログラム • SPECint95（129.compress） • 統一サイズ：３０、２５、２０、１５、１０、５ • １個の基本ブロックへの鍵命令挿入数：１

18. Load for Key Nop Original 性能/コスト・オーバヘッド • StrongARM Model • In-Order execution • Branch Pred. (nottaken) • コードサイズ • 最大で6倍以上，最小でも約2倍 • 実行時間 • 最大で60%，最小で10%の性能低下

19. 発表手順 • はじめに • 不正プログラム検出とその問題点 • 実行の振舞いを利用したプログラム認証 • 安全性に関する定性的評価 • 性能/コストに関する定量的評価 • おわりに

20. おわりに • まとめ • 実行の振舞いを活用した動的プログラム認証方式 • 安全性に関する考察 • 性能/コードサイズの定量的評価 • コードサイズは約2倍（統一BBサイズ=5） • 性能オーバヘッドは約10%（統一BBサイズ=5） • 今後の課題 • 安全性に関するより詳細な考察 • 消費エネルギーと安全性のトレードオフ解析

21. Back-Up Slides …

22. 本当の今度の課題（!?） • 誰が「安全である」と保障してくれるのか？ • 現状はプログラム発行者（と前提） • 全てのプログラムのライセンス化は非現実的！ • 「安全性の判定能力」を持たせるには？ • ウィルス感染をどのようにしてユーザに伝えるか？ • CMP（又はマルチ・コア）でこれまでの議論が通用するのか？ • 殆どの研究では「オンチップはセキュア」という前提 • 安全性向上のための性能オーバヘッドを隠蔽できない？

23. 自己脆弱性の回避 スタック・スマッシング検出 SW: LibSafe/Verify[USENIX00] HW: SRAS[SPC03] HW: SCache[WASSA04] プログラム認証 暗号化 SCache: Dynamic+HW • キャッシュ・レベルでの実装 • プロセッサとの分離 • ランダムアクセス可能 • 大容量領域 • コスト削減 消費エネルギーの解析 関連研究（動的アプローチ）

24. 夜のお楽しみセッション「今後の日本のコンピュータ・サイエンス研究をどう盛り上げるか？」夜のお楽しみセッション「今後の日本のコンピュータ・サイエンス研究をどう盛り上げるか？」 SWoPP2005@武雄 今夜 １９：３０スタート！