Transcript
Page 1: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

Stack and Queue Integrity on Hostile Platforms

Premkumar T. DevanbuStuart G. Stubblebine

AMO グループミーティング資料塩谷 沢生

Page 2: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

概要

• 信頼できないホスト H 上でスタックやキューを保持するプロトコルの提案

• O(1) のメモリと、 Push や Pop などの操作ごとに O(1) のデータを送信するだけでよい

Page 3: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

Introduction

• Trusted Hardware の普及– SmartCard など– ハードウェアとしては貧弱– 通常はホストマシンに装着して使用する

• Trusted Hardware 上から、ホストマシンのリソースを利用して計算を行えないか?

Page 4: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

論文の構成

• 目標と課題および関連研究• スタックの実現方法とその評価• キューの実現方法とその評価• RAM を扱った先行研究との比較• 応用• 将来の拡張• 結論

Page 5: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

関連研究

• 信用できないホスト上のメモリをチェックするフレームワーク– M.Blum, et al. 94– N.M.Amato, et al. 94 – 信用できないホスト P 上に n bit のメモリ

に対して デバイス、 V は log(n) のメモリがあれば妥当性をチェックできる

• Merkle Signature trees ( 後述 )

Page 6: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

User CheckerResource/Manager

WorkSpace

– 信用できないホスト上に、キューやスタックを保持させる

trusted untrusted

Page 7: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

攻撃者に関する仮定 (1)• ホスト H はこのプロトコルに従わなくてよい• 信用できるデバイス T と ホスト H との通信

チャネルは、認証されている• ホスト H はデバイス T に高次の命令を指示で

きる= Known Attack ・ Chosen Attack が可能– Known Attack: 攻撃者は各操作とデータを知ってい

る– Chosen Attack: 攻撃者は各操作とデータをコント

ロールできる

Page 8: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

攻撃者に関する仮定 (2)

• 攻撃者は computationary に制約されるものとする– データ構造に対して行う操作の制約– 蓄積できる情報量の制約– データの処理や蓄積に必要な操作の制約

• 攻撃者は他のインスタンスからのデータを再現してもよい– このプロトコルを並列実行したときに起こりうる

ケース• 他のセッションから得たデータを利用して、新

しいメッセージを構築してもよい

Page 9: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

関連研究 (2)

• L.Lamport 81– One Time Password: 事前にハッシュ値のチェー

ンを作成し、ひとつずつ使い捨てにする– 筆者らの方法では、やはりハッシュ値の

チェーンを利用するが、使い捨てにはしない• Goldreich 87, Ostrovsky 90

– Oblivious Machine:RAM へのアクセスパターンを隠蔽する

Page 10: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタック (1)

• Push, Pop, New, Delete の 4 種の操作を考える• 質の良い乱数が得られるものとする• 値 x に対して、デバイス T はサインでき

る (σ(x) を計算できる )– ハッシュ関数ないしは公開鍵によるサイン– σ(x) は Collision resistant かつ 2nd pre-image regista

nt

• スタックに積むのは単一の文字列とする

Page 11: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタックのプロトコルのイメージ

x1 σ1

x2 σ2

x 3 σ3

σ4

H T

rinit

↑Correct Digest

Page 12: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタック (2)

• new() の手続き– T は乱数 r-init を生成する– T →H “new stack” Label:σ(r-init)– H →T “Done”– T σ’ ←σ(r-init)

• 乱数にサインし、これをラベルとして ホストに記録させる

• サインした乱数を格納しておく

Page 13: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタック (3)

• Push の手続き– T→H “push stack” x,σ, label: σ(r-init)– H x と σ を格納– H→T “Done”– T σ’ ← σ( x ||σ)

• T は Push する値 x と、現在のキーを渡す• 新しいキーとして、 x と現在のキーとを接合

したものにサインした値を使用する

Page 14: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタック (4)

• Pop の手続き– T→H “pop stack” label: σ(r-init)– H→T スタックの一番上から x と σtop を返

す• アンダーフローの時は、 σ(r-init) と “ error” を返す

– T σ(x || σtop) を算出し、 σ と比較する“ error” が返ってきた場合、 σ(r-ini

t) を 比較する– T σ’ ← σtop

Page 15: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタック (5)

• Delete の手続き– T→H “delete stack”, label: σ(r-init)– H→T “Done”– T (σ, r-init ) の対を削除する

Page 16: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタックの妥当性の証明 (1)

• 定義 1– 理想的なスタックとは、標準的なスタック

の仕様に従って動作するスタックである• 定義 2

– 不正なスタックとは、いくつかの操作 Ω={o1,o2,o3,…on , pop(stackid)} の後に理想的なスタックが返すべき値を返さないスタックである

Page 17: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

スタックの妥当性の証明 (2)

• 定義 3– もし不正なスタックが不正な値を返したら

必ずそれを検知できるならば、そのスタックをチェックするプロトコルの実装は、セキュアである

• 定理 1– サインする手段が Collision resistant かつ 2n

d pre-image resistant なら、著者の提案するプロトコルはセキュアである

Page 18: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

証明の方針

• スタックの correct digest という概念を定義する

• いかなる操作のあとでも、 T は correct digest を保持しつづけることを証明する

• correct digest が保持されている限り、 H による不正な操作は必ず検出される

• 以上の事柄を、帰納法を利用して証明する

Page 19: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

Correct digest の定義

• 定義 4– s0 で始まり、 s1,s2,…sn から構成されるス

タックの correct digest を以下のように定義する

• σ0 = σ(s0)

• σi = σ( si || σi-1 ), i = 1...n

Page 20: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

命題 1

• 命題 1– 以下の条件が満たされれば、著者らのプロ

トコルは任意の操作 Ω={o1...on} の後でもT 上の理想的なスタックの correct digest を保持する

• a) T が著者らのプロトコルに則って動作する• b) サインする手段が collision resistant かつ 2n

d pre-image resistant

Page 21: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

命題 1 の証明

• 初期状態 (i=0) では明らか• σi-1 が correct digest と仮定する

– 次の操作は push か pop• push の場合

– T は σi を、 σi = σ( x || σi-1) として算出する – 定義 4 より σi は correct digest

• pop の場合– H は x と σ r を返し、 T は σi-1 = σ( x || σr) を検証– 命題 1 の条件より、 x と σr は偽造できない– 定義 4 より σr も correct digest

Page 22: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

命題 2

• 命題 2– 以下の条件の下で、 T が理想的なスタック

の correct digest を保持しているならば、任意の操作 Ω={o1...on} の後のスタックの不正な振舞いを検知できる

• サインする手段が collision resistant かつ 2nd pre-image resistant

Page 23: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

命題 2 の証明

• Pop についてのみ考察すればよい– pop によって σn = σ(x || σr) が返されるが、

σ(x) は collision resistant だから、この式を満たす偽の x と σr を返すことはできない

Page 24: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

キュー

• 基本的にはスタックと同じ• キューから出したデータのためのキー

も必要なので 二つのキーを保持する必、要がある

Page 25: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

キューのイメージ

x1 σ1

x2 σ2

x 3 σ3σq

4

H T

rinit

σr1

Page 26: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

RAM Tree

• Merkle の signature trees– 二分木を利用してセキュアな RAM を確保する手法– n bit のアドレス空間について、 2n の葉と 2n のノード

を用意する必要がある– 基本的な考え方は アドレス 、 a に対応するノードに、連

結した子ノードにサインした値を格納させる• M[a] = σ(M[a||0]||M[a||1])

– M[0] は、信用できるデバイス上で保持する– アドレス a にアクセスする場合は、 a の経路全てのキー

を一緒に渡す– アドレス a の値を更新する場合、全てのサインをやり直す

Page 27: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

RAM との比較

• キューもスタックも RAM があれば実現可能– n-bit のアドレス空間ではアクセス毎に n 回

の署名計算が必要–ページに分割 / secure virtual memory

• T 上に複雑なプログラムを置く余地はない• ページフォールト毎に O(n) の計算が必要

– 現時点では優れた secure virtual memory の実装はない

– このプロトコルは実装が簡単

Page 28: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

RAMTree のイメージ

1

00

0

110

100101

1010

Page 29: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

応用

• static analyzers, type checkers, proof checkers, compilers/instrumenters など、信頼性が求められるソフトウェアを、 trusted hardware に載せることができる– Java bytecode-verification など

• リソースが必要な作業でも実行できる– 証明コードつきのソフト

• trusted hardware が検証を行うので、コードの詳細が外部に漏れない

– mobile code の解析と証明

Page 30: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

筆者らが提案するスキーマ (P.Devanbu,et.al 97,98)

μ

Vendor

TrustedTool

Hostμ: ソフトウェア配布

π,σ(μ,π):ソフトに関する証明

ReleaseManager KeyManager

Key Certificate

Centralized Configuration Manager

Page 31: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

将来の拡張

• 秘密保持– 秘密保持のためのレイヤーを追加するのは容易だろ

う• キーの更新

– 全面更新:一旦実行を中断し スタックやキューを、空にしてから積みなおす

– 部分的更新:複数のキーの管理が必要• データ共有

– 複数のデバイスがホスト上のデータ構造を共有する

– secure quorum scheme と統合できるか?

Page 32: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

結論

• 信用できないホスト上にスタックとキューを保持するプロトコルを示した

• Trusted hardware 側は、 O(1) のメモリがあればよく、操作毎に送るデータの規模も O(1) でよい– 先行研究ではそれぞれ O(log n ) が必要– ただし、攻撃者に対する仮定が異なる

• 不正な値を返すような攻撃が行われたら、すぐにそれを発見できることを示した

Page 33: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

主な Reference(1)

• Nancy M.Amato and Michael C. Loui.– Checking linked data structures. In Proceedings

of the 24th Annual International Symposium on Fault-Tolerant Computing (FTCS), 1994

• Manuel Blum, William Evans, Peter Gemmell, Sampath Kannan, and Moni Noar.– Checking the correctness of memories. Algorith

maica, 12(2/3):225-244, 1994.

Page 34: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

主な Reference(2)

• P.Devanbu, P.W.Fong, and S.Stubblebine. – Techniques for trusted software engineering.In

Proceedings of the Twentieth International Conference on Software Engineering, 1998

• O.Goldreich.– Towards a theory of software protection and si

mulation by oblivious rams. In Proceedings of the 19th Annual Symposium on Theory of Computing. ACM, 1987

Page 35: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

主な Reference(3)

• L.Lamport– Password Identification with Insecure Commun

ications. Communications of the ACM, Nov 1981.

• R.C.Merkle– A certified digital signature. In Advances in Cr

yptology-Crypto ‘89, 1989

Page 36: Stack and Queue Integrity on Hostile Platforms Premkumar T. Devanbu Stuart G. Stubblebine

主な Reference(4)

• R.Ostrovsky– Efficient computations on oblivious rams. In Pr

oceedings of the 22th Annual Symposium on Theory of Computing.ACM, 1990


Top Related