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