DBWeb 2007.

1. データ共有型WEBアプリケーションにおける
サーバ暗号化
京都大学 大学院情報学研究科
川本 淳平 吉川正俊

2. データ共有型WEBアプリケーションとは
サーバ上でユーザのデータは保管され
簡単にデータ共有が行えるアプリケーション
何時でも何所にいても
コラボレーションできる
(ユビキタス・コラボレーション)
何時でも何所にいても
コラボレーションできる
(ユビキタス・コラボレーション)
2

3. 3
WEBアプリケーションの問題
ユビキタス・コラボレーション環境構築のためにサーバは
ユーザデータは暗号化してサーバへ送信する
暗号化のまま保存しサーバ自身によるデータ閲覧を不可能にする
暗号化データに対する問合せをサポートする
という機能をサポートすべき
ユビキタス・コラボレーション環境構築のためにサーバは
ユーザデータは暗号化してサーバへ送信する
暗号化のまま保存しサーバ自身によるデータ閲覧を不可能にする
暗号化データに対する問合せをサポートする
という機能をサポートすべき
セキュリティ対策が
十分であるのか？
サーバ自身がユーザデータを
収集・利用するかもしれない
ユーザプライバシは守られているのか？ユーザプライバシは守られているのか？

4. 動機と目的
しかし，
そのような機能をサポートしているWebアプリケーションは皆無
そこで，
現在提供されているWebアプリケーションの機能のみを利用し
サーバへ特別な機能を仮定すること無く
プライバシ保護のための要件を実現するシステムを提案する
そこで，
現在提供されているWebアプリケーションの機能のみを利用し
サーバへ特別な機能を仮定すること無く
プライバシ保護のための要件を実現するシステムを提案する
4

5. WEB通信フィルタリングシステム
Webアプリケーション
サーバ
クライアント
(Webブラウザ) フィルタリング
エージェント
ローカル端末
•送信データの暗号化
•受信データの復号化
•送信データの暗号化
•受信データの復号化
他のユーザとのデータ共有が行えない
データの検索が行えない
通信暗号化による問題通信暗号化による問題
5

6. アカウント
識別子とパスワードによる認証
Webアプリケーションでの
大まかなデータ集合を構築する
本研究では、
1. Webアプリが想定している利用方法ではなく
2. アクセス制御機能を提供するために
アカウントの機能を利用する
本研究では、
1. Webアプリが想定している利用方法ではなく
2. アクセス制御機能を提供するために
アカウントの機能を利用する
識別子とパスワードはシステムが管理しユーザには通知しない
そのためユーザはシステムを介さずにアプリケーションを利用できない
note
6

7. アカウントを用いたアクセス制御
Webアプリケーションサーバ
アカウント アカウント1
アカウントN
一つのアカウントを利用する手法 複数のアカウントを利用する手法
次の2手法が考えられる次の2手法が考えられる
7

8. 一つのアカウントを利用する手法(1/2)
ユーザ
ユーザ
ユーザ
Webアプリケーションサーバ
アカウント
アクセス制御情報
エントリ毎にアクセス制御を行うエントリ毎にアクセス制御を行う
8

9. 一つのアカウントを利用する手法(2/2)
データエントリe 暗号化データ: Enc(e, ke )
共通鍵: ke
Enc(ke , pub1 )
このパックされたデータをサーバで保存このパックされたデータをサーバで保存
Step1Step1
Step2Step2
課題：この部分が膨大になってしまう課題：この部分が膨大になってしまう
Enc(e, ke ) Enc(ke , pubn )
Pubi :ユーザ i の公開鍵
ユーザ1 ～ユーザn にアクセス権限を与える場合
9

10. 一つのアカウントを利用する手法の問題
 アクセス権限情報が膨大
 エントリ毎にアクセス許可を持つユーザ分必要
 権限の無い多くのエントリを復号する可能性
 復号を行うまでアクセス権限の有無は判らない
Enc(ke , pub1 )Enc(e, ke ) Enc(ke , pubn )
順に復号を試みて，ほとんどのデータに
権限がないということもある
10

11. 複数のアカウントを利用する手法(1/3)
ユーザ1
ユーザ2
ユーザ3
アカウント毎にアクセス制御を行うアカウント毎にアクセス制御を行う
Webアプリケーションサーバ
アカウント1
User:{1,2}
アクセス制御情報
User:{2,3}
アカウントN
11

12. 複数のアカウントを利用する手法(2/3)
Step1Step1
Step2Step2
pubi :ユーザ i の公開鍵
ユーザ1～ユーザnにアカウントAiのアクセス権限を与える場合
アカウント毎に共通鍵暗号の鍵設定する
アカウント A1 A2 … An
鍵 kA1
kA2
… kAn
アカウント毎にアクセス権限を与えるユーザを設定する
Enc(kAi
, pub1)
このデータをアカウントに追加このデータをアカウントに追加
Enc(kAi
, pubn)
アカウント i
準備準備
12

13. 13
複数のアカウントを利用する手法(3/3)
アカウント i
データエントリeの追加データエントリeの追加
Step1Step1 アカウントからアクセス権限情報を取得する
Enc(kAi
, pub1) Enc(kAi
, pubn)
Step2Step2 アカウントの共通鍵kAi
を取得
Enc(kAi
, pubj) 共通鍵:kAi
ユーザjにアクセス許可がある場合kAi
を取得できる
Step3Step3 共通鍵kAi
を用いて暗号化しアカウントへ保存する
データエントリe 暗号化データ:Enc(e, kAi
)
共通鍵: kAi

14. 複数のアカウントを利用する手法の特徴
 権限の無いエントリへの復号を回避
 アカウントに権限が無い⇒中のデータにも無い
 アカウント単位でしか権限設定できない
 細かく設定すると最悪 O(2n) のアカウントが必要
14

15. ペアリングとユーザクラスタリング
 これまでの問題点
 権限を細かく設定すると情報が多くなる
 権限の有無を調べるための復号コストがかさむ
 ペアリング暗号
 アクセス権限情報を固定長で記述できる
 ユーザクラスタリング
 アクセス権限が近いユーザをクラスタリング
 復号コストの減少
15

16. ペアリング暗号の利用
16
 ペアリング暗号
 近年，研究が進んでいる新しい公開鍵暗号方式
ペアリング暗号を用いるとアクセス制限を持つユーザの人数に関わらず
固定長でデータエントリの共通鍵を暗号化することができる
Enc(ke , pub1 )Enc(e, ke ) Enc(ke , pubn )
Pairing(ke, {pub1 , … , pub2 })Enc(e, ke )
固定長固定長
アクセス権限情報を小さくすることができたが，
復号コスト問題は残ったまま．そこでユーザのクラスタリングを導入する．

17. ユーザクラスタリング(1/5)
 各ユーザに参照先アカウントを設定
 権限の有無を調べるのは参照先データのみ
 権限の有無を調べるデータ数を減少できる
 ペアリング暗号との併用
 参照先に含まれるデータに権限情報を付加
 参照先データ全てに権限を持つわけではない
細かい権限設定を可能にする
17

18. ユーザクラスタリング(2/5)
account1 account2 account3 account4
user1 user2 user3 user4
各ユーザは
始め互いに素な一つのアカウントのみを参照している
誰とも共有しないデータはこのアカウントに保存する
各ユーザは
始め互いに素な一つのアカウントのみを参照している
誰とも共有しないデータはこのアカウントに保存する
18

19. ユーザクラスタリング(3/5)
account1 account2 account3 account4
user1 user2 user3 user4
二人の共有データを追加する
どちらかのアカウント参照情報を更新するどちらかのアカウント参照情報を更新する 19

20. 20
ユーザクラスタリング(4/5)
account1 account2 account3 account4
user1 user2 user3 user4
三人の参照関係が上記の場合
三人の共有データはどこに保存すべきか
参照関係を更新するユーザが最少となるアカウントに保存する参照関係を更新するユーザが最少となるアカウントに保存する
ここに追加した場合
参照関係が更新されるユーザは2人
ここに追加した場合
参照関係が更新されるユーザは2人
ここに追加した場合
誰も参照関係を更新しなくて良い
ここに追加した場合
誰も参照関係を更新しなくて良い

21. 21
ユーザクラスタリング(5/5)
account1 account2 account3 account4
user1 user2 user3 user4
この場合はどこに保存すべきか
account2, 3どちらでも更新するユーザは1人
更新ユーザ数が等しい場合は参照ユーザ数の小さい方に保存する更新ユーザ数が等しい場合は参照ユーザ数の小さい方に保存する
ここにはuser1,2とは無関係な
user4のデータも含まれている
ここにはuser1,2とは無関係な
user4のデータも含まれている

22. ユーザクラスタリング・ルール
 ユーザ集合 S で共有するデータの追加
1. が参照しているアカウント集合∑を求める
2. アカウント について以下を求める
3. が最小となるアカウントAを求める
4. 対象アカウントが複数ある場合
A を参照するユーザが最も少ないものを選ぶ
5. A を参照していないユーザに A を参照させる
Su 
A
},|{ AuSuuNA 
AN
22

23. 実験
 権限の有無を調べるための復号コストがかさむ
 提案手法によりどの程度改善されたか
 アクセス適合率: r
 「復号してみた結果使えなかった」
が多いか少ないかを調べる
)(
)(
調べる総データ数アクセス権限の有無を
いたデータ数アクセス権限を持って
r
23

24. データ共有関係グラフ
1
2
3
4
5a
a
a,c
b
bb,c
c
この3人は共有関係にある
この2人は非共有関係
* Barabási, A.-L., and Albert, R., "Emergence of scaling in random
networks", Science 286, pp. 509-512 (1999)
一人のユーザを一つの頂点に割り当てる
同一ラベルの枝が張られたユーザ間にデータの共有関係があるとする
一人のユーザを一つの頂点に割り当てる
同一ラベルの枝が張られたユーザ間にデータの共有関係があるとする
24
BAモデル*を用いて
100, 1000, 10000 ユーザ
について作成した

25. 実験結果（100ユーザ）
ア
ク
セ
ス
権
限
適
合
率
アカウント参照数
25

26. 実験結果（1000ユーザ）
ア
ク
セ
ス
権
限
適
合
率
アカウント参照数
26

27. 実験結果（10000ユーザ）
ア
ク
セ
ス
権
限
適
合
率
アカウント参照数
27

28. 今後の課題
 アクセス権限適合率の改善
 所属アカウントは少ないが適合率も低いユーザ
 所属アカウントが多いユーザ
 これらの解消のために所属アカウントの再配置
28

29. まとめ
 データ共有型Webアプリケーションにおいて
ユビキタス・コラボレーション環境構築のために必要な
 ユーザデータは暗号化してサーバへ送信する
 暗号のまま保存しサーバ自身によるデータ閲覧を不可能にする
 暗号化データに対する問合せをサポートする
という機能を
 現在提供されているWebアプリケーションの機能のみを利用し
 サーバへ特別な機能を仮定すること無く
実現するシステムを提案した
 今後の課題
 アクセス権限適合率の改善
29