暗号化データベースモデルにおける関係情報推定を防ぐ索引手法

747 views

Published on

Published in: Technology
  • Be the first to comment

暗号化データベースモデルにおける関係情報推定を防ぐ索引手法

  1. 1. 暗号化データベースモデルにおける 関連情報推定を防ぐ索引手法 川本 淳平†, 吉川 正俊 (京都大学大学院情報学研究科) †日本学術振興会特別研究員
  2. 2. クラウドソースデータベース  サービスとして提供されるデータベース  巨大なデータセンターを用意することなくDBを利用できる  情報システムの管理・運用コストを削減可能  スケーラビリティを重視した設計  一組のシステム(ハードウェア)で複数の利用者に提供  従来個別に用意していたシステムの運用費を一つにまとめられる  共通機能をまとめるため低コスト低エネルギーであるサービス 2 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  3. 3. クラウドソースDBにおけるセキュリティ  サービスプロバイダが利用者データを保管・管理する  保管するデータの漏洩  悪意ある利用者だけでなくサーバ自信も攻撃者になりうる  管理者のミスによる情報漏洩, 利用者データの目的外利用  典型的な対応策  信頼できるクライアント上で予め暗号化して置くこと  サーバには暗号化したデータのみが保存される  攻撃者、サーバ共にデータを取得できない 暗号化データベースモデル† †H. Hacıgümüş, B. Iyer, C. Li, and S. Mehrotra, “Executing SQL Over Encrypted Data in the Database- service-provider model,” SIGMOD „02, pp. 216-227. 3 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  4. 4. 暗号化データベースモデルのプレイヤ サーバ上のデータを傍受 信頼できるクライアントとサーバの通信を傍受 攻撃者 •索引を用いた問合せへ変換 暗号化と索引情報の付加 •問合せ結果の復号とフィルタリング 信頼できる サーバ 信頼できる クライアント クライアント データ提供者 データ利用者 4 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  5. 5. 暗号化DBモデル:タプルの追加 利用者・クライアントに対する見かけのスキーマ: Event(name, begin, end) 信頼できるクライアントによる暗号化 (“Meeting”, “10/17 15:00”, “10/17 17:00”) 変換 (“vo3i4hlk4”, 151, 64, 221) web 元属性値から計算される索引情報: Iname, Ibegin, Iend 元属性値 name, begin, endをまとめて暗号化したもの: etuple サーバにおける実際のスキーマ: Event*(etuple, Iname, Ibegin, Iend) 5 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  6. 6. 暗号化DBモデル:タプルの検索 見かけのスキーマ上で問合せを発行 1. 暗号化された問合せ結果を復号 2. 再度問合せを実行 信頼できるクライアントが (無関係な問合せ結果の除去) 索引を用いた問合せに変換 name = “Meeting” 索引のみを用いて評価するため False Positiveを許す. 変換 “Meeting” Iname = 151 web 151 変換された問合せが届く データを復号することなく問合せを実行 6 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  7. 7. 索引の要請  索引の値から暗号前の値が分からない  索引を用いた問合せでは,  問合せ結果に漏れがあってはならない  問合せ結果に余分なデータが含まれることは許す 7 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  8. 8. バケット化を用いた索引計算方法†  計算手順  対象属性のドメインに順序を仮定  ドメインをいくつかのバケットに分割する  各バケットにラベルを振り,その値を索引の値とする 10/17 10/18 16:00 20:00 64 221 905 “10/17 15:00” → 64, “10/17 17:00” → 221  範囲問合せもサポートする “10/17 15:00” ~ “10/17 17:00” → 64 ~221  本来問合せていないタプルも取得する 221 で問い合わせると 16:00 ~ 20:00 すべてを取得する †B. Hore, S. Mehrotra, G. Tsudik, “A privacy-preserving index for range queries,” VLDB „04, pp. 720-731. 8 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  9. 9. 既存手法の問題点  ユーザ側に「関係」があることを考慮していない  コミュニティ(グループ)情報  発生するリスク  仮定 「同じ条件で問い合わせたユーザは関連が強い」  利用者の関連度推定によりLink disclosure†の可能性 社会ネットワークにおいて利用者間に関係の枝があるか否かが漏洩 アリス ? キャロル ? ? ボブ †K. Liu, E. Terzi, “Towards identity anonymization on graphs Export,” SIGMOD „08, pp. 93-106. 9 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  10. 10. Link disclosure問題 (1/2) クラウドサービスを用いたSNSの例 利用者A サイトオーナー SNS 利用者B 第三者  各種データやサイトそのものをクラウドサービスの上に構築  利用者の名前や住所といった個人情報  何を書き込んだのか・どんなコミュニティに属しているのか etc クラウドサービスのプロバイダも含め 利用者が許可した相手以外には公開すべきではない 10 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  11. 11. Link disclosure問題 (2/2)  数名の利用者だけがq1, q2, …, qmを問い合せた  数名の利用者はグループであると推定可能  グループ内の利用者が情報(趣味・思想 etc)を公開  他のユーザも共通の属性を持っていると推測される  あるデータ X を問合せた複数の利用者  共通する問合せが q のみ  X は問合せ q の索引値に対応していると分かる  索引の安全性が破られる 11 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  12. 12. 目標  同じ条件で問合せを行ったユーザu, vについて  サーバへ到達する問合せが異なる値になっている  サーバへ到達する問合せから本来の問合せが分からない  (暗号化DBモデルの上で動作する)  上記を満足する索引構築手法と問合せ処理方法を提案  索引をベクトルを用いて表現する  次元を拡張しダミーとなる値を追加  基底変換によりベクトルの各成分の値も秘匿する 12 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  13. 13. バケット索引のベクトル表記  バケット索引では対象のドメインDAをバケット化する inf DA sup DA a1 a2 ai an  属性値がラベルaiのバケットに入るタプルの問合せ { t | t ∈ R ∧ t.IA = ai } (索引値が ai に一致するタプル) t.IA = ai ai – t.IA = 0 1 (1 -t.IA) =0 ai タプルごとに定まる 問合せごとに定まる 索引 問合せ 13 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  14. 14. 問合せ表記のランダム化  乱数の追加 ai ai (1 -t.IA) =0 (1 0 -t.IA) r = 0 (r : 毎回異なる乱数) 1 1  基底の変換 ai ai (1 0 -t.IA) r = 0 (1 0 -t.IA)M M-1 r = 0 (M : 正則行列) 1 1 索引 問合せ 同じ ai に対して,毎回異なる問合せベクトルとなる 14 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  15. 15. 安全性について  問合せベクトルが一致する確率  問い合わせるバケットラベル ai と乱数 r が一致する時  乱数 r に 32bit 整数を用いると約4億通りの可能性  同じ ai を問い合わせ続けても 4 億回に1回の一致  基底の変換行列 M が漏洩する可能性  サーバには (1 0 -t.IA)M のみ保存される  サーバ上のタプルからは M を計算できない  利用者に配布される M-1 は漏洩しないと仮定すると安全  利用者ごとに異なる M-1u を用いる方法は今後の課題 15 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  16. 16. 範囲問合せの処理  属性Aの値がバケットaiからajに入るタプルを問合せる t ai+aj 2 問合せとして Q(ai, aj)= M-1 ai-aj r ai-aj を用いて 索引 I に対して-1 ≤ I •Qu(ai, aj) ≤ 1 を満足するタプルを求める  以下より属性Aの値がバケットaiからajに入るタプルのみ取得 r r 16 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  17. 17. 評価実験  実験内容  共著関係データ:Bibliography on database systems†  問合せのシミュレーション  著者を利用者とし,各論文情報をDBへ保存する  8309名の利用者と20011個の暗号化タプル  利用者(著者)は自身が執筆した論文を検索したとする Authors Title M. Abadi Temporal-Logic Theorem … … J. Abate and H. Dubner Optimizing Performance of … … … … … 見かけ上のタプル(本来は暗号化されている) † http://liinwww.ira.uka.de/bibliography/ 17 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  18. 18. 評価実験  評価指標  問合せログから利用者間の関係情報が抽出できるか  抽出にはナイーブなアルゴリズムを使用  閾値 θ 回以上,同じ問合せを行ったとき関係があると判定  問合せ処理の実行速度の比較  前処理:ベクトルを用いた問合せの計算  問合せ処理:サーバ上での評価+通信時間  後処理:復号とフィルタリング  その他  既存研究を考慮した二種類のバケット計算方法  (実験結果に有意な差が出なかったため省略する) 18 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  19. 19. 実験結果:ナイーブ抽出アルゴリズムの精度 1 悪 0.9 0.8 0.7 従来手法ではバケット数・閾値により関係情報が抽出可 Precision 0.6 0.5 提案手法では問合せが一致しないため精度は低い opt 0.4 opt+vec avg 0.3 avg+vec 0.2 0.1 良 0 Threshold (number of buckets) ドメインをいくつのバケットに分けるか(少 ←→ 多) + 閾値 19 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  20. 20. 実験結果:ナイーブ抽出アルゴリズムの再現率 1 悪 0.9 0.8 従来手法ではバケット数・閾値により関係情報が抽出可 0.7 0.6 Recall 0.5 提案手法では問合せが一致しないため再現率も低い opt 0.4 opt+vec avg 0.3 avg+vec 0.2 0.1 良 0 Threshold (number of buckets) ドメインをいくつのバケットに分けるか(少 ←→ 多) + 閾値 20 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  21. 21. 実験結果:問合せ処理速度の比較 180 前処理・後処理にかかる時間に差はほとんど無い 160 140 バケットの作り方は速度に影響しない 120 Time (msec) x2.5 x2.5 バケット数が少ないと提案手法のコスト高 100 x2 x2 80 post 60 x2 x2 server pre 40 20 0 ドメインをいくつのバケットに分けるか(少 ←→ 多) + バケットの計算方法 Method 21 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
  22. 22. まとめと今後の課題  暗号化DBモデルにおけるLink disclosureを防ぐ索引  索引をベクトルを用いて表現する  次元を拡張しダミーとなる値を追加  基底変換によりベクトルの各成分の値も秘匿する  評価結果  サーバ上での処理速度は遅い  共通の問合せか否かの判別が現実的には困難  今後の課題  問合せ結果からのLink disclosureに対応する  利用者ごとに異なる M-1u を用いる方法  サーバ上での処理速度の改善 22 2010年 暗号と情報セキュリティシンポジウム 2010/1/21

×