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

Stack and Queue Integrity on Hostile PlatformsPremkumar 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 (後述)

trusted untrusted User Checker Resource/ Manager WorkSpace • 信用できないホスト上に、キューやスタックを保持させる

攻撃者に関する仮定(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 registant • スタックに積むのは単一の文字列とする

スタックのプロトコルのイメージ H T x３ σ3 x2 σ2 σ4 ↑Correct Digest x1 σ1 rinit

スタック(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-init)を比較する • 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 かつ 2nd 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 かつ 2nd 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を返すことはできない

キュー • 基本的にはスタックと同じ • キューから出したデータのためのキーも必要なので､二つのキーを保持する必要がある

キューのイメージ H T x３ σ3 σq4 x2 σ2 σr1 x1 σ1 rinit

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 0 0 10 1 101 100 0 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 Host μ: ソフトウェア配布 μ π,σ(μ,π)：ソフトに関する証明 TrustedTool Key Certificate Centralized Configuration Manager ReleaseManager KeyManager

将来の拡張 • 秘密保持 • 秘密保持のためのレイヤーを追加するのは容易だろう • キーの更新 • 全面更新：一旦実行を中断し､スタックやキューを空にしてから積みなおす • 部分的更新：複数のキーの管理が必要 • データ共有 • 複数のデバイスがホスト上のデータ構造を共有する • 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. Algorithmaica, 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 simulation by oblivious rams. In Proceedings of the 19th Annual Symposium on Theory of Computing. ACM, 1987

主なReference(3) • L.Lamport • Password Identification with Insecure Communications. Communications of the ACM, Nov 1981. • R.C.Merkle • A certified digital signature. In Advances in Cryptology-Crypto ‘89, 1989

主なReference(4) • R.Ostrovsky • Efficient computations on oblivious rams. In Proceedings of the 22th Annual Symposium on Theory of Computing.ACM, 1990

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