柔軟なプライバシ保護を考慮した分散型位置情報システムの提案
8
0
0
全文
(2) 1. はじめに. 近年、インターネットと携帯端末の急速な普及によ り、移動するユーザの地理的な位置情報を利用するアプ リケーションが多く開発されている。単純なアプリケー ションとしては、NTTドコモが2000年 1月より提供して いる「どこ Navi」サービスがある。さらに、地理的位 置情報を利用するアプリケーションが様々な場面で利 用されることが期待されている [1]。しかしながら、地 理的位置情報を管理することで享受するメリットの一 方でプライバシ侵害などの新たな問題が予想される。 例えば、情報がサービス提供者以外に利用されてし まう、匿名で提供した位置情報が個人と対応づけられ てしまうなどの問題が生じる。このような問題を防ぐ ために IETFgeopriv ワーキンググループでは、位置情 報システムにおけるプライバシ保護を考慮するための 要求仕様が議論され、[2] で公開している。だが、現状 ではこ れを実装したシ ステムはない。 [4] でプライバシ保護を考慮した地理位置情報シス テム (GLI: Geographical Location Information) が提案 された。このシステムは現実世界を移動する移動体を 対象とし、その識別子と位置情報および付帯情報の登 録・検索機能を実現している。GLI では、時とともに 変化する匿名の識別子で登録することにより移動体の 特定・追跡を防止している。また、この識別子は移動 体と信頼関係にある者は移動体と対応づけることがで き、信頼関係のない者には統計情報しか公開しないこ とでプ ライバシを保護 している。 しかし、実際にプライバシを保護するためには位置 情報を公開するか・しないかだけではなく、公開する 情報を含めて、よりきめ細かく制御する必要がある。 例 え ば ユー ザは あ る時 間帯 の み、あ るエ リ ア内 での み、または目的に応じて位置情報を公開するか・しな いかを決めたい。このように様々な条件に応じて公開 する位 置情報を調整す ることが求めら れている。 この概念を考慮した例としては、[5]が知られている。 しかし、位置情報システムの応用範囲を広げる、位置か らその場にいる移動体を検索する機能がなく、サーバ の分散化も考慮されていない。そこで、GLI システム の高度な検索機能を損なうことなく、[2] で議論されて いるプライバシ保護の肝腎となる要求を適用した新た な 位 置 情 報 シ ス テ ム GLIPSE(Geographical Location Information with Privacy and Security Enhancement) を提案 する。. 2. セキュリティ上の脅威とプライ バシ保護の目標. からなる。各エンティティはインターネットを介して 通信を行う。プライバシ保護をするためには、各エン ティティが管理するデータおよびそれぞれの通信に対 する脅威 からデ ータ を守ら なけ ればな らない 。[6] で は、IETF ワーキンググループで議論された位置情報 システムにおける 脅威分析が公開 されている。 ここでは、Servers を 基本的に信用しないという前 提の上で GLIPSE システムのセキュリティ上における 脅威を抽出し、プラ イバシ保護の目 標を定める。. 2.1. プライバシ侵害. GLIシステムでは信頼関係の有無でしか情報を制御 できない。Agentと、信頼関係を結んでいるClient 全て との間で、同じ秘密を共有しているため、一度許可し た Client の ア ク セ ス を 再 度 禁 止 す る こ と が 難 し い 。 従って、許可した目的外で利用されることを防ぎにく くなり、Agent のプライバシを侵害される危険性があ る。また、あるエリア内に登録する Agent が少ない場 合においては、時と共に変化する匿名の識別子を利用 しても、Agent を特定される可能性があり、プライバ シ侵害につながる。従って、信頼関係があるかどうか でのみ制御するのではなく、様々な条件に応じて精度 を含めて位置情報を制御できるシステムを設計する。. 2.2. 通信路での盗聴、改竄. インターネットを介して通信を行うことにより、通 信データが盗聴されたり、改竄される可能性がある。 通信中のデータには送信元のIP アドレスが含まれるた め、そのデータを特定の Agent と対応付けられる可能 性がある。また、過去に盗聴したデータを利用して、 位置情報とすり替える再生攻撃も考えられる。従って、 データが盗聴されても盗聴者に解釈できない、データ が改竄されたり、古いデータを再送信された場合でも、 各エンティティがそれを検出で きるようにする 。. 2.3. なりすましの脅威. 悪意を持つ要素が Agent になりすまして偽の位置情 報を登録し、Servers になりすまして Agent が登録する デ ー タ を 奪った り、ま た あ る Client に な り す ま し て Agent がその Client に許した位置情報を得てしまうな どの危険性がある。従って、なりすまし防止ができる、 各エンティティが互いに認証し合えるメカニズムを扱 えるようにする。. GLIPSE システムは、大きく分けて、位置情報を登 録するエンティティ(以下、Agentと呼ぶ）、情報を管理 するサーバ群 (以下、Servers と呼ぶ) と、位置情報を検 索しそれを利用するエンティティ(以下、Client と呼ぶ). −26− 2.
(3) 2.4. 情報収集による特定、追跡. ネットワーク上で流れるデータをある程度監視しつ づけると、Agent の特定・追跡ができる危険性がある。 また、情報収集をすることで監視者がAgentとClient の 関係を予測できる可能性がある。これにより、Agent と Client にとって不利な目的で第三者に利用される危 険性がある。従って、各通信時の機密性を高めること によりそれらの脅威から回避できるように工夫する。. 2.5. Denial of Service 攻撃. 悪意を持つ要素が特定のエンティティを攻撃するよ りも、位置情報を管理する Serversに連続的に負荷をか け、登録または検索ができないようにする DOS 攻撃に よってシステムのサービスが停止する危険性がある。 GLIPSEシステムでは、不正な Agentや Client からの登 録、検索要求を拒否可能にし、DOS 攻撃を回避できる ように する。. 2.6. データベースの盗難・書換. プライバシ保護のための機構. 本章では、GLIPSE システムにおけるプライバシ保 護のた めの機構につい て述べる。. 3.1. 3.2. ア ク セ ス 制 御 表 と Rule Server の 利用. アクセ ス制御 表 (Access Control List, ACL) は本 シ ステムにおいて、様々な精度の位置情報が扱えるよう にするための重要な要素である。ACL では、何種類の 精度の位置情報を用意するか、どの Client に対してど の情報を渡すかなどのプライバシポリシがリストされ る。本論文では ACL について、異なる精度の情報を n 個生成する方法と、その選択ポリシをリストすること のみで 、詳細は定めない 。 このために、サーバ群の中には ACL を管理するた めの Rule Server を導入する。Client にどの情報を渡す かを決めるためにはRule Serverに問い合わせる形にす. 情報の暗号化. 通信路での機密性を高めるために、各エンティティ で送信時には位置情報と所有者情報を暗号化する。各エ ンティティでの処理が増加するが、通信路上での盗聴 対策に効果がある。また、2.4節の情報収集による情報 所有者の特定、追跡も防止できることになる。さらに、 暗号化する情報の中に時刻情報を入れることで、2.2節 の過去のデータによる再生攻撃の対策にも効果がある。 暗号処理による処理速度と暗号する鍵の事前共有の トレードオフを考慮した結果、いわゆるハイブリッド 暗号方式を採用する。すなわち、位置情報とその所有 者情報は一時共通鍵で暗号化し、その暗号で利用した 鍵を公開鍵暗号で暗号化する。また、各エンティティ の公開鍵は PKI によって入手、検証できるものとする。. 3.3. 位置情報を管理するServersはそれぞれAgentとその 位置情報を対応づけられるデータベースを持っているの で、Servers のデータベースが盗難されたら、Agent を 特定される可能性がある。従って、データベースが盗難 された場合においても、許されたエンティティ以外に は解読できないようにする、または Agent にとって最 低限の被害しか及ばないようにシステムを設計する。. 3. る 。この よ う に す る こ と に よって 情 報 取 得 権 を 持 つ Client のみが、Agentに許された情報を取得できること になり、2.1 節の脅威 に対処できる。. 電子署名と電子証明書による認証. 通信する情報を暗号化する前に、予め電子署名でサ インをしておくことによって2.2節のデータ改竄の対策 とする。受信側でそのサインを確認することでデータ が改竄されたかどうかが検出できる。また、そのサイ ンの正当性を証明するには電子証明書を利用する。こ れにより、2.3 節の脅 威から回避でき ることになる。. 3.4. DOS 攻撃対策. GLIPSE システムでは、負荷のことを考慮し、通信 プロトコルとしてUDP を採用する。UDP においては、 送信元の IP アドレスを簡単に書き換えられるので、ラ ンダムな IP アドレスで Servers に対して DOS 攻撃が可 能になる。その対策として、新たなAgentとClient によ る要求に 対して は、電子 署名の 確認の 前に Servers は cookie を要求元に送り返し、その cookie を含めた要求 の再送を要求する。正しい cookie を含む要求のみ署名 確認を行う。これにより、相互通信可能な IP アドレス の要求に対してのみ署名確認を行うことになり、ラン ダムなホストから の要求を回避可 能になる。. 3.5. Servers で管理するデータの分割. データベース盗難の対策として、各サーバで管理す るデータを分割する。特に、位置情報とその所有者情 報を対応付けられないようにこれらを別のサーバで管 理する。両方の情報が別々に管理できない場合、一人 の所有者 に対 して 一個の サー バが 管理 するよ うに す. −27− 3.
(4) る。このようにすることによって、そのサーバが乗っ 取られた場合、管理している所有者の情報のみ漏洩す ることにより、2.6 節の脅威を回避できるようになる。. 4.2. 提案システムの設計. 4 4.1. で 指 定し て (北 緯 50 度 ∼51 度 、東 経 100 度 ∼101 度）検索すると、その範囲内にいる Agent 群と、 その位 置情報のリスト が得られる。. 動作. 本章では、登録処理、正引き処理と逆引き処理のそ れぞれについて、通信手順を説明す る。. 構成. GLIPSE システムは位置情報を登録する Agent(A)、 ACL を管 理す る Rule Server(RS)、位 置 情報 を管 理す る Data Server(DS)、各地理位置情報に対応した Agent の情報 を管理する Area Server(AS) と 位置情報 を検索 するClient(C) から構成される。分散管理については[7] と同様 の手法を用いる 。 本システムの説明をする準備として、以下のものを 定義す る。 • EA (M ) メッセージ M を鍵 A で暗号化したもの (暗号文)。 • SA (M ) メッセージ M に A の署名を付加 したもの。 • CertA A の証明書 。 • L Agentが登録する位置情報。本システムで扱う位 置情報は、現実世界で移動するエンティティの地 理的な位置情報 [緯度、経度、高度] である。L は ACL で指定した異なる精度 n 種類で登録できる。 • ID Agentの元々の識別子。インターネット上のIPア ドレス、FQDN やユーザ名、現実世界での名前 などにあ たる。 • pseudoID ID を ス ク ラ ンブ ル し た 時 と共 に 変 化 する 識 別 子 。第三 者 に よ る Agent の ID との 対 応 付 け は 困 難 で あ る 。こ の 識 別 子 は Area Server 内 で の Agent の 匿名性を保っている [1]。 • ttd 位置情報の有効期限。ある程度位置情報が更新 さ れ な い と き 、各 サ ー バ の デ ー タ ベ ー ス か ら Agent の 情報を削除する までの時間であ る。. 4.2.1. 登録 処理. 登録処理の手順を図 1 に示す。さらに詳しい手順を 図 2 に示す。 Agent は自身の位置情報 L と ID 、オプションとして ACLとttdをRule Serverの公開鍵で暗号化したものに署 名 し 、そ の デ ー タ セット [SA {ERS (ID, L, ACL, ttd)}] を Rule Server に 登録要求とし て送る。 Rule Server は 自 分 の キャッシュか ら Agent の 証 明 書 を 検 索 す る 。検 索 に 失 敗 し た ら 、cookie を 生 成 し 、Agent の 証 明 書 を 要 求 す る 。成 功 し た ら 、証 明 書 の 検 証 を 行 う。認 証 で き た も の の み 自 身 の プ ラ イ ベ ー ト 鍵 で 復 号 化 し 、送 信 さ れ た 情 報 を 得 る 。 ACL に 基 づ い て 位 置 情 報 L を n 通 り 計 算 し 、各 L に 対 す る 鍵 Ki と 一 時 鍵 Dj を 生 成 す る 。デ ー タ セ ット[CertRS , SRS {EDS (Dj ), ED j (ID, i, Ek i (Li ), ttd)}] (ttd はオ プション) の リスト を Data Server に 登録要 求 として送る。このようにして、一つの Agent に対して 様々な精 度の位置情報を Data Server に 登録す る。 次に、Area Serverに登録するためのpseudoIDを計算する。デー タセット[CertAS , SRS {EAS (Dj ), EDj (pseudoID, i, Li , ttd)}]. (ttd はオプション) のリストを特定した Area Server に登. 録要求として送る。このようにして、一つのpseudoID に対し、様々な位置情報を登録することが可能である。 pseudoID で登録することによって Area Server を 信頼 する必要がなくな る。 Data Server と Area Server からの登録完了メッセー ジが届くと、Rule Server は Agent に登録完了メッセー ジを送る。. º»¼½ ¾ ©ª« ¸ · © ¶ ¸ ¡ ¹ µ ¢¤ ¸ £¦¥¨§ ´ ¸ ¬®¯1° ±³² ´
(5) . • i 位置情報 の精度を表す番 号。 • 正引き検 索 IDを鍵としてAgentの位置情報を検索する機能。 例えば、ある Agent のID を指定して検索すると、 許可され た精度の位置情 報が得られる。.
(6) u u ! ~ ~ v v y z zE}E~ w6y y z {1| }E~ y ~ | wx. • 逆引き検 索 地理的な位置情報 (ここでは緯度と経度のみ) を 鍵として、その領域に存在する Agent を 検索す る機能。例えば、検索する範囲を 2点の位置情報. −28− 4. ? F D ) ; BED $& > C %K ; B H '= > K 33< K 0 K '; A G M @ L ((*K JI 0I ,KJI 9 I 7 : - . 7 8 . 2 3 5 +6- - . /10 2 3 - 43 0 + ,. Q SU i m n T h s t NP g l OR r h k o e \ Ya dVEf g r ] ] d r [ r j r
(7) b qp [p Wrqp p ` c X Y` a YE\E] _ V X X Y Z1[ \E] X ^] [ V W. !"# 図 1: 登録手順.
(8) Agent. Rule Server REGIST_REQ SA(ERS(ID,L,ACL,ttd)). registration to RS CERT_REQ cookie. search certificate cache if not exist { generate cookie, cached } else { verify CertA }. REGIST_REQ cookie, CertA ,SA(ERS(ID,L,ACL,ttd)) verify CertA cache CertA generate shared key D, generate key Ki for every precision of L registration to DS. *,+.-/ 0 1 23 4576 8 -:9 4;=<>?. Data Server REGIST_REQ CertRS,SRS(EDS(Dj),ED (ID,i,EK (Li),ttd) j. I. verify CertRS register list of EK (i)i.
(9) b e f \ c l WY ` i Xk c g j Zd h k c g f Zb e f Z a k _ ` k ^ [ [ [ ] U V B T BDC C FH O:J LGPIK LRMQ N S J L E$F. i. REGIST_REP. Data registration completed. generate pseudoID generate shared key D registration to AS. m $ m m } ~ u n n n xyz { y|s w$p x o p qtr s u p v. Area Server REGIST_REQ SRS(CertRS,EAS(Dj),ED (pseudoID,i,Li)). ! "#$ $
(10) ! . @ A &() @ . j. verify CertRS register list of Li.
(11) . !% '&() ! . REGIST_REP. Area registration completed. 図 3: 正引き 検索の手順 (詳 細). REGIST_REP registration completed. 1 <= i <=n 1 <= j <=q. 図 2: 登録 処理 (詳細). 4.2.2. 正引き処 理. 正引き検索処理の手順を図 3 に示す。さらに詳しい 手順を 図 4 に示す。 Clientは検索したいID をRule Serverの公開鍵で暗号 化したものに署名し、そのデータセット[SC {ERS (ID)}] を Rule Server に 検索要求として 送る。 Rule Server は自分のキャッシュで Client の証明書を 検索する。検索に失敗したら、cookieを生成し、Client の証明書を要求する。成功したら、証明書の検証を行 う。認証できたもののみ自身のプライベート鍵で復号 化し、送信された情報を得る。ACL に基づいて Client に許された位置情報の精度を決定し、その精度 i に対 す る 鍵 Ki と アク セス 許可 を暗 号化 し、デ ータ セット [SRS {EC (Dj ), ED j (Ki , EDS (SRS (C, ID, i)))}]をClient に送り 返す。 Client はそのアクセス許可に自分の署名をし、検索 要求としてデータセット[SC {EDS (SRS (C, ID, i)))}] を Data Server に送る。Data Server は鍵 Ki で暗号化され たま まの 情報に 署名 し、Client に送 り返 す。Client は Data Serverから受信した鍵Ki で復号化し、Agentの位 置情報 を取得する。. 4.2.3. Client. Rule Server F_QUERY. looking for access permission of ID. SC(ERS(ID)) search certificate cache if not exist { generate cookie, cached } else { verify CertC }. CERT_REQ cookie. F_QUERY cookie, CertC,SC(ERS(ID)) verify CertC cached CertC check the ACL to find precision i for C F_REPLY generate shared key D and SRS(EC(Dj),ED (Ki,EDS(SRS(C,ID,i)))) access permission to DS j. Data Server F_QUERY looking for L of ID. SC(EDS(SRS(C,ID,i))) F_REPLY SDS(EK (Li)). search database find Li. i. get permitted L of ID. 1 <= i <=n 1 <= j <=q. 図 4: 正引き検 索処理. 逆引き検 索. 逆引き検索処理の手順を図5に示す。図6にその詳細 を示す。 Client は検索したい範囲指定に署名し、Area Server に検索要求を送る。その要求を受けたArea Serverは自. −29− 5.
(12) 分のキャッシュで Client の証明書を検索する。検索に失 敗したら、cookie を生成し、Client の証明書を要求す る。成功したら、証明書の検証を行う。認証できたも ののみ 検索処理を続け る。 Area Server で要求された範囲に m エントリを発見 すると、各エントリに対してどの位置情報を返せばい い の かを Rule Server に 問い 合わ せる 。Rule Server は ACL を確認し、各エントリに対して Agent が許可した 位置情報の番号 iをArea Serverに返す。そのClient に対 して Agent のID を明らかにしてもよい場合には、その ID を Client の公開鍵で暗号化して同時に返す。そうで なければ、pseudoID を渡す。このようにして、Agent が許可 した情報しか Client に渡さな いことになる。. 5. 本システムにおいては、暗号処理の部分に最も負荷 がかかると予想される。従って、暗号処理の性能が本 システム全体の性能を左右する。本実装に向けて、準 備実験として本システムで利用する公開鍵による暗号 と共通鍵による暗号の処理時間を測定し、システム全 体の性能の見積もりを行う。また、電子署名の生成と 認証の処理時間も 測定する。 全ての実験はAiCryptoライブラリ関数[8]を使用して 行った。測定は、Intel 社製 Pentium 4 (2.40 GHz)CPU を用いた FreeBSD 4.9R 上で行った。. 5.1.
(13) % &)( *,+-/. 021 ' 3465879 :;=< s p u v_wxKyz{_| } pr t {_| q q } {| {| u v_w~ xKyz{|
(14) V Q SU e k_j T d i j NP c h OR o d g l [#\ ]_^
(15) `Fab c f o Z o n m Y m X o n m W m
(16)
(17) ® ²_³ §©¨ ª_«¬K £ ¤ ¯ ¶ ¦ ± ¶ ¥ ° £ ¤ ¯ ¶ µ ´ ¢ ´ ¡ ·¹¸»º¼!½¿¾ÁÀ  LKM @ B I DKJ H G E C DFEG E B A > ? "#6 > ! "#$ . 評価および考察. 暗号の処理. まず、公開鍵暗号による暗号化と復号化の処理時間 を測定した。測定に用いた関数は AiCrypto ライブラリ [8] のRSAprv doCrypt()と RSAprv doCrypt()という関 数 で あ る 。使 用 し た 鍵 の 長 さ は ぞ れ ぞ れ 、modulus INTEGER n 1024 bit、publicExponent INTEGER e 17 bitとprivateExponent INTEGER d 1024 bitである。 ランダムな 128byteの入力値で暗号化と復号化を 10000 回繰り返して測定した。それぞれの平均値を表1に示す。. 表 1: RSAにおける暗号化および復号化の処理時間 処理. 図 5: 逆引 き検索の手順. Client. 平均処理時間. 暗号 化 復号 化. 1.2 msec 46.9 msec. Area Server R_QUERY. looking for entries in an area. SC(Lmax,Lmin) CERT_REQ cookie. また、共有鍵暗号により暗号化と復号化の処理時間 測定も行った。使用した関数は DES3 cbc encrypt() と DES3 cbc decrypt() である。192 bit の鍵長に、実装で 使用するデータペイロードに十分な大きさとして、 4096 byte の入力値で 10000 回繰り返し測定した。その 平均値は表 2 に 示す。. search certificate cache if not exist { generate cookie, cached } else { verify CertC }. R_QUERY cookie, CertC,SC(Lmax,Lmin) verify CertC cached CertC search database, m entry found generate shared key D ask precision for every entry to RS Rule Server R_QUERY SAS(ERS(Dj),ED (pseudoIDk,C)) j. check the ACL to find precision i for C. 表 2: 3DES CBC モードにおける暗号化および復 R_REPLY SRS(EAS(Dj),ED (pseudoIDk,i,EC(IDk)) j. 号化の処理時間 処理. get precision for every entry. get the entries in the area. 平均処理時間. 暗号 化 復号 化. R_REPLY list of SAS(pseudoIDk,Li,EC(IDk). 1.5 msec 1.4 msec. 1 <= i <=n 1 <= j <=q 1 <= k<=m. 図 6: 逆引き検索処理 (詳細). 5.2. 電子署名の処理. 認証に使用する電子署名の生成および検証するため の処理時間を測定した。利用した関数は電子署名生成の 場合は、OK do signature()、その署名の検証の場合は、 OK do digest() と OK do verify() で あ る 。128 byte の 平 文 に 128 byte の 秘 密 鍵 、SHA1withRSAEncryption アルゴリズムで 10000 回測定し、平均値を表 3 に示す。. −30− 6.
(18) 表 3: 3DES CBC モードにおける暗号化および復. 表 4: 暗号および電子署名処理の回数と処理時間. 号化の 処理時間 (msec). の見積もり。n は公開す る位置情報の精 度の数。. 処理 署名の生 成 署名の検 証. 5.3. 平均 処理時間. m は検索で 発見したエント リ数。. 47.4 msec 1.3 msec. 処理. 登録、検索の性能見積り. 5.1 節と 5.2 節の測定結果を元に、Rule Server, Data Server と Area Server へ の位 置 登 録 の性 能 見 積 もり を 行った。また、一台の Agent からの登録にかかる時間 および一つのリクエストにかかる検索時間の見積もり も行った。 Rule Serverにおいて、一人の Agentからの一台の登 録 リ ク エ ス ト を 処 理 す る の に か か る 時 間 は (48.3 + 52.8n) msec である。ここで、n は公開する位置情報の 種類である。n = 1 の場合は、1 リクエストあたり 101 msec 要するので、Rule Server への位置登録の性能は 9 リクエスト/秒である。正引き検索リクエストの性能 は、6 リクエスト/秒であり、逆引き検索リクエストの 性能は 10 リクエ スト/秒である 。 また、Data Server と Area Server への登録にかかる 時 間 は と もに 49.6n msec で ある の で 、Data Server と Area Server への位置登録の性能は、20 リクエスト/秒 である。n = 1 の場合、1 分の周期で登録リクエストを 許 可 す れ ば 600 台 の Agent の 位 置 登 録が 可 能 に な る 。 n = 2 の場合は、その半分の台数の登録が可能である。 一 台 の Agent か ら の登 録 リク エ スト 全 体の 処 理時 間は 、(96.8 + 199.4n) msec で ある。n = 1 の 場合は 、 292.2 msec を要するので、登録の性能は 3.38 リクエス ト/秒で ある。 同様に検索に関しても見積もりを行う。1 正引き検 索リクエストあたり 393.6 msec 要するので、正引き検 索の性能は、2.54リクエスト/秒である。逆引きに関し て は 、1 リク エス ト あた り (48.7 + 253.9m) msec 要 す る。m は検索で発見したエントリ数である。m = 20 の 場合、逆引きの処理時間は5126.7 msecであるので、そ のとき の性能は 0.195 リ クエスト/秒となる。 また、匿名で逆引き検索結果を返す (発見したエン トリに対する Rule Server への問い合わせを行わない) 場 合 、電 子 署 名 の 処 理 を (1 + m) 回 し か 行 わ な い た め、1 リ クエストあ たり (48.7 + m) msec を 要する。 登録と検索で行う暗号および電子署名処理の回数と 各処理 にかかる時間を 表 4 にまと める。. 5.4. 従来の位置情報システムとの比較. 本節で、プライバシの保護について従来のGLI シス テムと 比較する。 GLI で は Agent が あ る 位 置 に 長 時 間 停 止 し て い る と 、匿 名 の ID が変 化 し て も 、そ の 匿 名 の ID が ど の. 公開 鍵暗号 使用 回数 共有 鍵暗号 使用 回数 電子 署名 使用 回数 処理 時間 (msec). 登録. 正引き 検索. 逆引き検索. 1 + 2n. 3. 3m. 2n. 1. 2m. 1 + 2n. 5. 1 + 3m. 96.8 + 199.4n. 393.6. 48.7 + 253.9m. Agent の ID であるかが対応づけられてしまう。また、 GLI システムでは、匿名の ID の有効期間内には Agent の追跡ができてしまう。なぜなら、正引き検索で利用 する検索鍵は逆引き検索で取得できるためである。し かし、GLIPSE システムでは、アクセス を Client 毎に 制限することとそれぞれの検索に異なる ID を用いる ことにより、両方の 問題を回避でき る。 GLI システムでは、Agent と信頼関係にある Client は匿名の ID を生成し、偽の位置情報を登録可能であ る。それに比べ、本システムは電子署名により各エン ティティの 認 証 を 行って い る た め 、権 限 の あ る エ ン ティティ以外は 要素以外は偽の 登録ができない 。 また、本システムでは DOS 攻撃と再生攻撃につい ても考慮しているので、それぞれの攻撃による偽の登 録および検索を回避可能である。従って、プライバシ 保護の面においては、GLIPSE システムがより優れて いると言える。. 5.5. サーバの盗難・書換. GLIPSE システムで各サーバが管理する情報を表 5 にまとめた。Rule Server は最も信頼されるサーバで、 Agent と そ の Agent の 位 置 情 報 の 対 応 を 含 め て 全 て 管 理し て いる 。本 シス テ ムに お い ては 、一 つの Rule Serverは一台のAgentを管理するとする。従って、Rule Serverが乗っ取られた場合、一台のAgentの情報しか影 響されないで済む。一つの Rule Server で複数の Agent を管理することも可能だが、サーバ運用コストとプラ イバシ保護の機能 はトレードオフ の関係にある。 Data Server は Agent の ID 情報を持つが、管理する 位置情報は暗号化されたものしか持たない、またArea Server は 位 置 情 報 を 持 つ が 、本 当 の ID は 持 た な い 。 こ の た め 、一 度 に 両 方 の サ ー バ が 乗っ取 ら れ て も 、 Agent を特定・追跡され ない。. −31− 7.
(19) [6] M.Danley, D. Mulligan, J., Morris, J. Peterson, “Threat Analysis of the Geopriv Protocol”, RFC 3694, February 2004.. 表 5: 各サーバで管理 する情報 サー バ. RS DS AS. 6. 管理 する情報. A, DS, AS の IP アドレス、ACL、 ID、 pseudoID、鍵 Ki 、L RS の IP アドレ ス、ID、Ek (Li) RS の IP アドレ ス、pseudoID、 Li. [7] 栗栖俊治 : ”インターネットを利用した移動体の位 置情報管理機構の構築”, 慶應義塾大学, 理工学部情 報工学科卒業 論文, February 2003. [8] ”AiCrypto ラ イ ブ ラ http://mars.elcom.nitech.ac.jp/Research/ MM/security/aicrypto.html. おわりに. 本論文では、様々な条件に応じて位置情報の公開精 度が制御できるGLIPSEシステムの枠組みを提案した。 本 シ ス テ ム で は 、Rule Server に 登 録 す る Agent 毎 の ACL(アクセス制御表) を持たせることにより柔軟なプ ライバシ保護を実現した。また、暗号処理を利用する ことで各通信路での機密性を高め、データが盗聴され ても Agent の特定、追跡を防止できた。また、電子署 名を利用することで各要素の成りすましを防止した。 DOS 攻撃や再生攻撃の対策も考慮した。最後には、現 状の位置情報システム[4] に付加された機能の性能評価 を行い、増加するオーバーヘッドの見積もりを行った。 本システムの問題点は、暗号にかかる処理時間であ る。従って、より性能の良いシステムを設計するために は暗号処理を軽減するための工夫が必要である。今後は それについて改良と実装を行い、システム全体の性能 を評価する。また、Rule Server が管理する情報の機密 性を高める仕組みも検討する。さらに、このシステム を効果的に利用できるアプリケーションを検討する。. 参考文献 [1] 和泉順子, 竹内奏吾, 渡辺恭人, 植原啓介, 砂原秀樹, 寺岡文男, 村井純 : “位置情報システムにおけるプ ライバシ管理方法の提案”,DICOMO2000 シンポジ ウム論文集, pp.667-672, June 2000. [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, “Geopriv Requirements”, RFC 3693, January 2004. if0 [3] 渡辺恭人, 竹内奏吾, 植原啓介, 寺岡文男, 村井純 : “プライバシ保護を考慮した位置情報システム”, 情 処学論マルチメディアネットワークシステム特集 号, vol.42, no.2, February 2001. fi [4] 渡辺恭人, 竹内奏吾, 栗栖俊治, 寺岡文男, 村井純 : “プライバシ保護を考慮した位置情報システムの実 装と評価”, 電子情報通信学会論文誌 B, vol.J86-B, no.8, pp.1434-1444, August 2003. [5] 上松啓, 吉川正人, 倉島顕尚, 坂田一拓, 市村重博, 小 池雄一: “携帯Javaプログラムに向けたユーザ指向の ポリシーベースプライバシ保護方式”,DICOMO2003 シンポジウム論文 集, pp.553-556, June 2003.. −32− 8. リ”,.
(20)
図
![図 6: 逆引き検索処理 (詳細) 5 評価および考察 本システムにおいては、暗号処理の部分に最も負荷 がかかると予想される。従って、暗号処理の性能が本システム全体の性能を左右する。本実装に向けて、準備実験として本システムで利用する公開鍵による暗号と共通鍵による暗号の処理時間を測定し、システム全体の性能の見積もりを行う。また、電子署名の生成と認証の処理時間も測定する。全ての実験はAiCryptoライブラリ関数[8]を使用して行った。測定は、Intel社製Pentium 4 (2.40 GHz)CPUを用いた](https://thumb-ap.123doks.com/thumbv2/123deta/6409601.1624628/6.918.97.425.321.927/およびシステムがかかるシステムシステムシステムライブラリ.webp)
関連したドキュメント
リスク研究の分野では、 「リスク」 を検証する際にその対になる言葉と して 「ベネフ ィッ ト」
これらの実証試験等の結果を踏まえて改良を重ね、安全性評価の結果も考慮し、図 4.13 に示すプロ トタイプ タイプ B
FSIS が実施する HACCP の検証には、基本的検証と HACCP 運用に関する検証から構 成されている。基本的検証では、危害分析などの
太宰治は誰でも楽しめることを保証すると同時に、自分の文学の追求を放棄していませ
紀陽インターネット FB へのログイン時の認証方式としてご導入いただいている「電子証明書」の新規
※証明書のご利用は、証明書取得時に Windows ログオンを行っていた Windows アカウントでのみ 可能となります。それ以外の
しかし , 特性関数 を使った証明には複素解析や Fourier 解析の知識が多少必要となってくるため , ここではより初等的な道 具のみで証明を実行できる Stein の方法
すべての Web ページで HTTPS でのアクセスを提供することが必要である。サーバー証 明書を使った HTTPS
