Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Semelhante a 暗号化データベースモデルにおける関係情報推定を防ぐ索引手法
Semelhante a 暗号化データベースモデルにおける関係情報推定を防ぐ索引手法 (20)
Mais de Junpei Kawamoto
Mais de Junpei Kawamoto (18)
暗号化データベースモデルにおける関係情報推定を防ぐ索引手法
- 1. 暗号化データベースモデルにおける 関連情報推定を防ぐ索引手法 川本 淳平†, 吉川 正俊 (京都大学大学院情報学研究科) †日本学術振興会特別研究員
- 2. クラウドソースデータベース サービスとして提供されるデータベース 巨大なデータセンターを用意することなくDBを利用できる 情報システムの管理・運用コストを削減可能 スケーラビリティを重視した設計 一組のシステム（ハードウェア）で複数の利用者に提供 従来個別に用意していたシステムの運用費を一つにまとめられる 共通機能をまとめるため低コスト低エネルギーであるサービス 2 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 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 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 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. 暗号化DBモデル：タプルの検索 見かけのスキーマ上で問合せを発行 1. 暗号化された問合せ結果を復号 2. 再度問合せを実行 信頼できるクライアントが (無関係な問合せ結果の除去) 索引を用いた問合せに変換 name = “Meeting” 索引のみを用いて評価するため False Positiveを許す． 変換 “Meeting” Iname = 151 web 151 変換された問合せが届く データを復号することなく問合せを実行 6 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 7. 索引の要請 索引の値から暗号前の値が分からない 索引を用いた問合せでは， 問合せ結果に漏れがあってはならない 問合せ結果に余分なデータが含まれることは許す 7 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 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. 既存手法の問題点 ユーザ側に「関係」があることを考慮していない コミュニティ（グループ）情報 発生するリスク 仮定 「同じ条件で問い合わせたユーザは関連が強い」 利用者の関連度推定によりLink disclosure†の可能性 社会ネットワークにおいて利用者間に関係の枝があるか否かが漏洩 アリス ？ キャロル ？ ？ ボブ †K. Liu, E. Terzi, “Towards identity anonymization on graphs Export,” SIGMOD „08, pp. 93-106. 9 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 10. Link disclosure問題 (1/2) クラウドサービスを用いたSNSの例 利用者A サイトオーナー SNS 利用者B 第三者 各種データやサイトそのものをクラウドサービスの上に構築 利用者の名前や住所といった個人情報 何を書き込んだのか・どんなコミュニティに属しているのか etc クラウドサービスのプロバイダも含め 利用者が許可した相手以外には公開すべきではない 10 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 11. Link disclosure問題 (2/2) 数名の利用者だけがq1, q2, …, qmを問い合せた 数名の利用者はグループであると推定可能 グループ内の利用者が情報（趣味・思想 etc）を公開 他のユーザも共通の属性を持っていると推測される あるデータ X を問合せた複数の利用者 共通する問合せが q のみ X は問合せ q の索引値に対応していると分かる 索引の安全性が破られる 11 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 12. 目標 同じ条件で問合せを行ったユーザu, vについて サーバへ到達する問合せが異なる値になっている サーバへ到達する問合せから本来の問合せが分からない (暗号化DBモデルの上で動作する) 上記を満足する索引構築手法と問合せ処理方法を提案 索引をベクトルを用いて表現する 次元を拡張しダミーとなる値を追加 基底変換によりベクトルの各成分の値も秘匿する 12 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 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. 問合せ表記のランダム化 乱数の追加 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. 安全性について 問合せベクトルが一致する確率 問い合わせるバケットラベル 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. 範囲問合せの処理 属性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. 評価実験 実験内容 共著関係データ：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 2010年 暗号と情報セキュリティシンポジウム 2010/1/21
- 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. 実験結果：ナイーブ抽出アルゴリズムの再現率 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. 実験結果：問合せ処理速度の比較 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. まとめと今後の課題 暗号化DBモデルにおけるLink disclosureを防ぐ索引 索引をベクトルを用いて表現する 次元を拡張しダミーとなる値を追加 基底変換によりベクトルの各成分の値も秘匿する 評価結果 サーバ上での処理速度は遅い 共通の問合せか否かの判別が現実的には困難 今後の課題 問合せ結果からのLink disclosureに対応する 利用者ごとに異なる M-1u を用いる方法 サーバ上での処理速度の改善 22 2010年 暗号と情報セキュリティシンポジウム 2010/1/21