Download - 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 グループミーティング資料塩谷 沢生
概要
• 信頼できないホスト H 上でスタックやキューを保持するプロトコルの提案
• O(1) のメモリと、 Push や Pop などの操作ごとに O(1) のデータを送信するだけでよい
Introduction
• Trusted Hardware の普及– SmartCard など– ハードウェアとしては貧弱– 通常はホストマシンに装着して使用する
• Trusted Hardware 上から、ホストマシンのリソースを利用して計算を行えないか?
論文の構成
• 目標と課題および関連研究• スタックの実現方法とその評価• キューの実現方法とその評価• RAM を扱った先行研究との比較• 応用• 将来の拡張• 結論
関連研究
• 信用できないホスト上のメモリをチェックするフレームワーク– M.Blum, et al. 94– N.M.Amato, et al. 94 – 信用できないホスト P 上に n bit のメモリ
に対して デバイス、 V は log(n) のメモリがあれば妥当性をチェックできる
• Merkle Signature trees ( 後述 )
User CheckerResource/Manager
WorkSpace
– 信用できないホスト上に、キューやスタックを保持させる
trusted untrusted
攻撃者に関する仮定 (1)• ホスト H はこのプロトコルに従わなくてよい• 信用できるデバイス T と ホスト H との通信
チャネルは、認証されている• ホスト H はデバイス T に高次の命令を指示で
きる= Known Attack ・ Chosen Attack が可能– Known Attack: 攻撃者は各操作とデータを知ってい
る– Chosen Attack: 攻撃者は各操作とデータをコント
ロールできる
攻撃者に関する仮定 (2)
• 攻撃者は computationary に制約されるものとする– データ構造に対して行う操作の制約– 蓄積できる情報量の制約– データの処理や蓄積に必要な操作の制約
• 攻撃者は他のインスタンスからのデータを再現してもよい– このプロトコルを並列実行したときに起こりうる
ケース• 他のセッションから得たデータを利用して、新
しいメッセージを構築してもよい
関連研究 (2)
• L.Lamport 81– One Time Password: 事前にハッシュ値のチェー
ンを作成し、ひとつずつ使い捨てにする– 筆者らの方法では、やはりハッシュ値の
チェーンを利用するが、使い捨てにはしない• Goldreich 87, Ostrovsky 90
– Oblivious Machine:RAM へのアクセスパターンを隠蔽する
スタック (1)
• Push, Pop, New, Delete の 4 種の操作を考える• 質の良い乱数が得られるものとする• 値 x に対して、デバイス T はサインでき
る (σ(x) を計算できる )– ハッシュ関数ないしは公開鍵によるサイン– σ(x) は Collision resistant かつ 2nd pre-image regista
nt
• スタックに積むのは単一の文字列とする
スタックのプロトコルのイメージ
x1 σ1
x2 σ2
x 3 σ3
σ4
H T
rinit
↑Correct Digest
スタック (2)
• new() の手続き– T は乱数 r-init を生成する– T →H “new stack” Label:σ(r-init)– H →T “Done”– T σ’ ←σ(r-init)
• 乱数にサインし、これをラベルとして ホストに記録させる
• サインした乱数を格納しておく
スタック (3)
• Push の手続き– T→H “push stack” x,σ, label: σ(r-init)– H x と σ を格納– H→T “Done”– T σ’ ← σ( x ||σ)
• T は Push する値 x と、現在のキーを渡す• 新しいキーとして、 x と現在のキーとを接合
したものにサインした値を使用する
スタック (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
スタック (5)
• Delete の手続き– T→H “delete stack”, label: σ(r-init)– H→T “Done”– T (σ, r-init ) の対を削除する
スタックの妥当性の証明 (1)
• 定義 1– 理想的なスタックとは、標準的なスタック
の仕様に従って動作するスタックである• 定義 2
– 不正なスタックとは、いくつかの操作 Ω={o1,o2,o3,…on , pop(stackid)} の後に理想的なスタックが返すべき値を返さないスタックである
スタックの妥当性の証明 (2)
• 定義 3– もし不正なスタックが不正な値を返したら
必ずそれを検知できるならば、そのスタックをチェックするプロトコルの実装は、セキュアである
• 定理 1– サインする手段が Collision resistant かつ 2n
d pre-image resistant なら、著者の提案するプロトコルはセキュアである
証明の方針
• スタックの correct digest という概念を定義する
• いかなる操作のあとでも、 T は correct digest を保持しつづけることを証明する
• correct digest が保持されている限り、 H による不正な操作は必ず検出される
• 以上の事柄を、帰納法を利用して証明する
Correct digest の定義
• 定義 4– s0 で始まり、 s1,s2,…sn から構成されるス
タックの correct digest を以下のように定義する
• σ0 = σ(s0)
• σi = σ( si || σi-1 ), i = 1...n
命題 1
• 命題 1– 以下の条件が満たされれば、著者らのプロ
トコルは任意の操作 Ω={o1...on} の後でもT 上の理想的なスタックの correct digest を保持する
• a) T が著者らのプロトコルに則って動作する• b) サインする手段が collision resistant かつ 2n
d pre-image resistant
命題 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
命題 2
• 命題 2– 以下の条件の下で、 T が理想的なスタック
の correct digest を保持しているならば、任意の操作 Ω={o1...on} の後のスタックの不正な振舞いを検知できる
• サインする手段が collision resistant かつ 2nd pre-image resistant
命題 2 の証明
• Pop についてのみ考察すればよい– pop によって σn = σ(x || σr) が返されるが、
σ(x) は collision resistant だから、この式を満たす偽の x と σr を返すことはできない
キュー
• 基本的にはスタックと同じ• キューから出したデータのためのキー
も必要なので 二つのキーを保持する必、要がある
キューのイメージ
x1 σ1
x2 σ2
x 3 σ3σq
4
H T
rinit
σr1
RAM Tree
• Merkle の signature trees– 二分木を利用してセキュアな RAM を確保する手法– n bit のアドレス空間について、 2n の葉と 2n のノード
を用意する必要がある– 基本的な考え方は アドレス 、 a に対応するノードに、連
結した子ノードにサインした値を格納させる• M[a] = σ(M[a||0]||M[a||1])
– M[0] は、信用できるデバイス上で保持する– アドレス a にアクセスする場合は、 a の経路全てのキー
を一緒に渡す– アドレス a の値を更新する場合、全てのサインをやり直す
RAM との比較
• キューもスタックも RAM があれば実現可能– n-bit のアドレス空間ではアクセス毎に n 回
の署名計算が必要–ページに分割 / secure virtual memory
• T 上に複雑なプログラムを置く余地はない• ページフォールト毎に O(n) の計算が必要
– 現時点では優れた secure virtual memory の実装はない
– このプロトコルは実装が簡単
RAMTree のイメージ
1
00
0
110
100101
1010
応用
• static analyzers, type checkers, proof checkers, compilers/instrumenters など、信頼性が求められるソフトウェアを、 trusted hardware に載せることができる– Java bytecode-verification など
• リソースが必要な作業でも実行できる– 証明コードつきのソフト
• trusted hardware が検証を行うので、コードの詳細が外部に漏れない
– mobile code の解析と証明
筆者らが提案するスキーマ (P.Devanbu,et.al 97,98)
μ
Vendor
TrustedTool
Hostμ: ソフトウェア配布
π,σ(μ,π):ソフトに関する証明
ReleaseManager KeyManager
Key Certificate
Centralized Configuration Manager
将来の拡張
• 秘密保持– 秘密保持のためのレイヤーを追加するのは容易だろ
う• キーの更新
– 全面更新:一旦実行を中断し スタックやキューを、空にしてから積みなおす
– 部分的更新:複数のキーの管理が必要• データ共有
– 複数のデバイスがホスト上のデータ構造を共有する
– secure quorum scheme と統合できるか?
結論
• 信用できないホスト上にスタックとキューを保持するプロトコルを示した
• Trusted hardware 側は、 O(1) のメモリがあればよく、操作毎に送るデータの規模も O(1) でよい– 先行研究ではそれぞれ O(log n ) が必要– ただし、攻撃者に対する仮定が異なる
• 不正な値を返すような攻撃が行われたら、すぐにそれを発見できることを示した
主な 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.
主な 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
主な 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
主な Reference(4)
• R.Ostrovsky– Efficient computations on oblivious rams. In Pr
oceedings of the 22th Annual Symposium on Theory of Computing.ACM, 1990