RF-ID技術2題(自律位置取得・あいまい知人判定プロトコル)
•
0 gefällt mir•585 views
RF-IDにまつわる思いつきアイデア2題： 1.GPSとRF-IDの組み合わせで自律的に位置を取得するデバイス 2.未知のノードには個人情報を漏らさずに、知人ノードのみ発見できるあいまい知人認証プロトコル
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Andere mochten auch
Mehr von Kohei Otsuka
Mehr von Kohei Otsuka (20)
RF-ID技術2題(自律位置取得・あいまい知人判定プロトコル)
- 1. RF-IDに関連する 新技術案2題 ここギコ！ 大塚恒平 1
- 2. 目次 RF-IDとGPSと組み合わせた 1. 安価で正確・高速な位置情報インフラ 検証サーバを必要としない 2. セキュアな分散型個人検知・検証プロトコル これらの技術の存在する未来像 3. 2
- 4. 既存の位置情報インフラ （１）GPS 複数衛星（4基以上）からの信号時差により位置を � 同定 利点 � インフラは整っており、基本的にどこでも使える � 欠点 � 精度が低い（数m～十数m） � 特に都会や山間では障害物に阻まれ補足衛星数が減り、数十 m � ～100mの誤差が出ることもある 測位計算に計算機能力が必要 � センシングデバイスが高価になりがち � 測位計算に時間がかかる（数秒～十数秒） � 精度の低さともあいまって、視覚障碍者の歩行支援のような人命 � の関わる用途には使えない 4
- 5. 既存の位置情報インフラ （２）RF-ID 位置情報を埋め込んだパッシブ型のRF-IDを街角に � 埋め込み、位置を取得 利点 � その場所から情報を得るため、精度が高い（数 cm～数十 � cm） センシングデバイスが安価で測位が高速 � 欠点 � 個別の場所にRF-IDを埋め込んだ地物を設置する必要が � あり、インフラ構築が困難 埋め込む情報の管理等、管理作業が大変？ � 5
- 6. 欠点を補完しあう位置情報インフラ （１） GPS、RF-IDの利点、欠点は相互補完的 � GPS RF-ID インフラ グローバル 局地的 （構築済、利用のみならコスト無） （個別に構築するコスト大） 測位速度 遅い 速い CPUパワー 必要 あまりいらない デバイス 高価 安価 GPSとRF-IDが相互補完しあえば、測位が高速・正確で、デ � バイスも安価な位置情報インフラが、安価に構築できるので はないか 与える位置情報の管理をしなくとも、 工場出荷→街中に設置するだけ � で、自律的に正確な位置情報を取得 し、RF-IDで発信するデバイスが あればよい デバイスの位置取得 → GPS、位置発信 → RF-IDで行う � 6
- 7. 欠点を補完しあう位置情報インフラ （２） ③ 自位置を得たRF-IDユニットは、 正確な位置情報を高速に ① GPSユニットは、設置後 利用者に配信する GPSを使って自位置を測位 ② 自位置測位後、GPSユニットは RF-IDユニットに自位置を通知 RF-ID GPS 一体化チップ ※ここまでの案は 自位置測位は、設置後ゆっくりと算出すればよい ヒューマンインタフェース学会 � 2008年2月（Vol.10 No.1）に GPS GPSチップの高計算能力は不要 � 定点観測による誤差拡散 寄稿済み � 繰り返し測位による揺らぎを吸収し、正確な位置が算出できる � 自律的に位置を取得 � RF-ID RF-IDに埋め込まれた位置情報の管理労力が不要 � 7
- 8. 欠点を補完しあう位置情報インフラ （３） 給電の問題 � GPS測位計算を行うため、微弱であっても給電必要 � 給電インフラ自体は、何らかの形で構築される想定をしていた � 太陽電池と組み合わせれば、給電インフラも不要の「設置するだけ」位置情 � 報インフラデバイスにできないか 太陽電池 給電 位置 RF-ID GPS 一体化チップ 必ずしも太陽電池である必要はないが、給電システムと一体化させて完全自 � 律的なデバイスとして提案できるか 8
- 9. 課題 GPSチップの低電力化・安価化、及び給電手段の検討 � ゆっくり定点測位すればよい（ 1測位数分とかでも問題ない）ため、 � CPUパワーは全くいらない ⇒ かなりの低電力化・安価化は可能 しかしながら、 � 簡易な給電手段との組み合わせだけで動くレベルへの低電力化 � 現実的に大量生産⇒大量設置できるレベルでの低価格化 � を実現するには、まだブレークスルーが必要ではないかと予測 低電力GPSチップの研究も進んでいる � Air Semiconductor社 � http://plusd.itmedia.co.jp/mobile/articles/0809/02/news103.html 定点測位による位置精度向上の実現性検討 � 揺らぎを吸収すれば、位置情報の精度向上は可能なはず � 実証実験必要 � より正確で計算効率のよい揺らぎ吸収アルゴリズムの確立 � 9
- 10. ２．検証サーバを必要としない セキュアな分散型個人 検知・検証プロトコル 10
- 11. アクティブRF-IDタグによる 個人識別の問題点（１） 個人と一意に結びついた識別信号（個人ID） � が撒き散らされる 個人IDと個人との関連は非公開であっても、ソー � シャルハッキングと組み合わせて情報が得られ てしまう 悪意ある第三者によるストーキング等にも悪用さ � れうる 11
- 12. アクティブRF-IDタグによる 個人識別の問題点（２） ED3FGHJK… Aくんが通りかかった! 犯罪に巻き込まれないか 監視開始! 見守りシステム K GHJ F ED3 ED3FGHJK… 今あそこを通っている 富豪の息子のIDか… 見守りシステムのない ところで検知したら Aくん 誘拐してやろう 悪意の第三者 このように個人情報との紐付けが 公開されていなくとも、ID撒き散らしは 危険です（産総研 高木浩光氏） 12
- 13. アクティブRF-IDタグによる 個人識別の問題点（現状の解決案） 復号して! ＸHg?;:KJ 復号完了! ED3FGHJK ED3FGHJK…Aくんだ! 毎回異なる 中央サーバ 監視開始! 暗号化 見守りシステム J ?;:K ＸHg 富豪の息子がＸHg?;:KJ の信号を出しているが… 暗号化されていて 別のところでは違う信号 だから意味ないな… Aくん （個人ID：ED3FGHJK） 悪意の第三者 撒き散らされる信号を暗号化し、 権限がなければ複合化要請できなくします （同定不能プロトコル：U研 坂村健氏） 13
- 14. 同定不能プロトコルでは解決できない ユースケース（１） 同定不能プロトコルの前提 � 復号を中央サーバへの問い合わせに頼る � 中央サーバへのアクセスラインが確保されなければ検 � 証できない � ローカルの検知をいちいち中央に問い合わせるのは 煩雑 復号の権限管理も中央サーバが行う � 監視者と監視対象といった一方的な権限検証であれ � ば処理可能だが、不特定多数の検証者が不特定多数 の検知者を検証するような用途では、サーバ処理は 非現実的 14
- 15. 同定不能プロトコルでは解決できない ユースケース（２） あｓｄ Aさん ｆｇｆｈ ｆｈｊ ；あ Bさん ｄｊ；ｊが ｌｓ ｊｆ Jｆｊｓｄ 暇なCさんは誰かいれば飲みに ｆんｋ 行きたいなあと思っている 暇だなあ ｄんｋｄ 幸い割と近くに友人のBさんがいる か 誰かいたら ｌｊｇ 遊びたいなあ ｌｊｋ んｖｍｓ Ｈｋ Ｌｊが ｊｆｋｇｊ ｄふぁ ｊ；あ Eさん Cさん Dさん 15
- 16. 同定不能プロトコルでは解決できない ユースケース（３） ユーザ間の 知人関係情報を 中央サーバが持つ Aさん ⇒プライバシー問題 中央サーバ B,C,D,Eさんが Bさん 知人か検証して! Bさんはオフライン 不特定多数×不特定多数の ⇒中央サーバに 検証要求がサーバに殺到 知人検証依頼できない A,B,C,Eさんが A,B,C,Dさんが 知人か検証して! 知人か検証して! A,B,D,Eさんが 知人か検証して! Eさん Cさん Dさん 16
- 17. 望まれる検証プロトコル Aさん 中央サーバにアクセスせず ユーザのデバイス間だけで ローカルに検証解決 ？ すか で ⇒デバイス自体はオフライン ない Bさん ゃ 人じ よ す？ ました でもユーザ間だけで 知人は 知 ま ？ て がし よね き かし して アドホック通信が成立すれば Cさん な気 す もし です が いま そん 人な気 です 、B 思 よい 私も り に はC よう とお 知 す !私 その 人の すま すね ね 、知 ま で り です さん っぱ 、B さん A,D,Eさんは や た C かっ ど、 ほ わ 知人じゃなさ なる 徐々に情報を明らかにすることで、 そうだ 無関係の第三者に情報を出すことを防ぐ Cさん 知人はBさん 知人情報は本人のみが持つ Eさん （プライバシー懸念なし） Dさん 17
- 18. 用いられるデータ 個人ID � 各個人が一つ持つ、識別用 ID � 基本的に秘密で、知人にしか明かさない � ただし、知人であれ他人に明かす情報のため、悪意の第三者が何ら � かの方法で略取したとしても問題ない前提で設計 ※公開鍵で代用させる考え方もありうる � 公開鍵 � 各個人が一つ持つ、公開鍵暗号での暗号化用 /署名検証用鍵 � 基本的に万人に対して公開 � 秘密鍵 � 各個人が一つ持ち、公開鍵とセットで使う復号用 /署名用鍵 � 知人含め、絶対に誰にも明かさない � 知人IDリスト � 各個人が持つ、知人の個人 IDリスト � 18
- 19. 満たすべき要件 フェーズ１：知人の個人IDの検知 � 各個人は、個人IDをビット操作した発信IDを発信する � 発信者を知らない第三者には、乱数に近い情報となる � 発信者を知る知人からは、「発信者かもしれない」と検知できる � 何らかの方法で発信者の個人IDを詐取した悪意の第三者にも、「発信者か � もしれない」と検知される が、その後の検証フェーズで落とされるため確証が得られない � フェーズ２：知人の検証 � 公開鍵暗号、或いはゼロ知識証明等を利用し、本当にお互いに知人かを検 � 証する 悪意の第三者は、このフェーズで落とされる � 検証依頼側も受付側も、自分だと証明する情報を一度に出してはいけない � 悪意ある第三者に「XXさんですか？」とたずねられる場合 � 逆に、有名人のふりをして、「YYさんですか？XXです」と名乗ってくるのを待ち伏 � せる場合 飽くまで双方が、少しずつ情報を開示し、一歩一歩知人である確からしさを詰 � めていく必要 19
- 20. フェーズ1：あいまいな知人検知（１） 個人IDにランダムな反転（XOR）ビット（以下 � マスク）をかける 例：個人IDが128ビットの場合、全くランダム � な128ビット列との一致割合 ⇒ ランダムなビット列との一致ビット 数発生率が1割～2割になるような ビット数のマスク用ビット列を乱数 発生比率 発生させてやる ⇒ 以後の説明ではマスクは32ビットと この辺を狙って マスクを発生させる 仮定する 64ビット 0ビット 128ビット 一致ビット数 20
- 21. フェーズ1：あいまいな知人検知（２） 検知されたい個人（A）は、32ビットのマスクをかけた � 個人ID（以下、発信ID）をブロードキャストする 検知する側は、観測した発信IDに対し、自分の知人 � IDリストとのXORを取る Aを知らない第三者にとっては、意味のないランダムビット � 列と同じ ⇒ 個人IDを知られることはない Aの個人IDを知る知人にとっては、 XORの結果が32ビット � となり、Aである可能性が高いと判る Aの個人IDを不法に入手した悪意ある第三者にも 32ビッ � トの結果が渡るが、Aでない個人であっても 1割程度の割 合でAと判定されるため、Aであると特定はできない あいまい性により、個人プライバシーが守られる 21
- 22. フェーズ1：あいまいな知人検知（３） ※個人ID8ビット、 Aさんを知らない人 反転ビット2ビット 01110011… とした例 誰？ 個人ID： 01010111 マスク： 00100100 Aさんを知る人 発信ID： 01110011 01110011… 01010111 11 100 との誤差2ビット! 011 Aさんかも! Aさんを不法に知った人 ⇒検証フェーズで確認 Aさん 01010111 との誤差2ビットだが Aとは限らない… ⇒検証フェーズで確認できないため、あいまいなまま 22
- 23. フェーズ2：あいまいな知人検知（４） 問い合わせ側は、同様にマスクされた発信ID � を送り、検証を申し込む 双方が知人らしいと判断した場合、検証 � フェーズに移る Aさんを知るBさん 1 001 個人ID： 01010110 1 011 マスク： 00001010 01011100 発信ID： 01011100 OK GO AHEAD Aさんかな？ Aさん 検証を申し込もう BさんのIDと2ビット差… Bさんかしら? とりあえず検証はOKしよう 23
- 24. フェーズ2：あいまいな知人検証１ 公開鍵認証を使う方法（１） 次に公開鍵認証を利用し検証を進める � ただし、いきなり核心的な情報を与えては、情 � 報だけ取られて逃げられる可能性がある 11 100 011 Aさんですか？ Bです！ 01011100 OK GO AHE AD Bさんの 署名つき Aさんっぽい信号を出す 情報 悪意の第三者 ⇒ 「Bさんがそこに居た」 という情報だけ取りトンズラ 24
- 25. フェーズ2：あいまいな知人検証１ 公開鍵認証を使う方法（２） 検証要請側（B）は、短い情報（8ビット程度）を自分 � （B）の秘密鍵で暗号化し、相手（A）に送る 以下では、Bの個人IDの先頭ビットを利用する � Aは、想定する相手（B’）の公開鍵で復号する � 想定があっていた（B＝B’）場合は、復号できる � 想定が間違って（B≠B’）いても、情報が短いのでたまたま � 復号結果が一致することもある 復号結果が想定相手（ B’）の個人IDの先頭ビットと一致すれば、 � 次に進む 復号結果が想定相手（B’）の個人ID先頭ビットと一致しな � ければ、その場で手続き破棄 25
- 26. フェーズ2：あいまいな知人検証１ 公開鍵認証を使う方法（３） 続いて検証受付側（A）も、同様に短い情報（A � の個人ID先頭8ビット）をAの秘密鍵で暗号化 し、相手（B）に送る Bは、想定する相手（A’）の公開鍵で復号する � 以下同様 � 先頭8ビットの検証が互いに終われば、ビット � 数を増やして同様に検証する 最終的に納得するところまで徐々に検証し、 � 互いが知人であるとの確証を得る 26
- 27. フェーズ2：あいまいな知人検証１ 公開鍵認証を使う方法（４） 互いに実際に知人だった場合 � ※1ビットずつ検証するとした例 Ｊｄｈｓｋｌｆｊｌ；ｓｊｚｓ 1 1 Bさん秘密鍵 Bさん公開鍵 Ｊｈｄｆｋｌｈｆ；ｇｈ：あｊ 0 0 Aさん Aさんを知るBさん Aさん公開鍵 Aさん秘密鍵 個人ID： 01010111 個人ID： 10010110 Ｈｈｊｇｆｈｊｇｆｊｈｆｊｈｄｆ 10 10 Bさん秘密鍵 Bさん公開鍵 ひｄｈぎｈぎｈｄｂ 01 01 Aさん秘密鍵 Aさん公開鍵 えｒｇｌｂんｌ；ｇんｋｇ；ｄｎ 100 100 Bさん秘密鍵 Bさん公開鍵 ．．．．繰り返して検証 27
- 28. フェーズ2：あいまいな知人検証１ 公開鍵認証を使う方法（５） 知人ではなかった場合 � ※1ビットずつ検証するとした例 Ｈｋｈｇｈｆｈｇｄｆｈｇｌｋｄｆ 1 0 Cさん秘密鍵 Bさん公開鍵 Ｇｄｆｇｄｆｋｇｊｋｌｊｌｊｌｄｇ 0 1 Aさん Cさん Dさん公開鍵 Aさん秘密鍵 個人ID： 01010111 個人ID： 01000110 Ｄｆｇｄｆｇｄｆｇｄｆｇｄｆｄ 相手をBさん 01 相手をDさん 00 （10010110） （11110001） Aさん秘密鍵 Aさん公開鍵 と推定 と推定 NG BYE 28
- 29. フェーズ2：あいまいな知人検証２ ゼロ知識証明を使う方法（１） ゼロ知識証明を用いて、相手が本当に知人である可能性を � 検証 お互いは、相手の公開鍵（素数の積）を知っている � 自分は、自分の秘密鍵（公開鍵の素因数情報）を持っている � 相手によって、自分の秘密鍵の内容をゼロ知識証明で検証してもら � うことにより、知人だと検証してもらう ゼロ知識証明は、1回の情報交換でずばり情報が検証でき � る手法ではない 「そのものズバリ」の情報を外部に漏らすことなく、「その情報（例えば � 秘密鍵）を知っているという事実」だけを確率論的に証明する 試行を繰り返すことにより相手が知人本人である可能性を増していく � お互いが相手をテストする試行を交互に繰り返す ことによって、お互 � いがお互いの知人である可能性が徐々に高まっていく 29
- 30. フェーズ2：あいまいな知人検証２ ゼロ知識証明を使う方法（２） 一般的なゼロ知識証明 ① � 大きな素数の積nに対し、mod nでの平方剰余Zを与え、Z=T2 mod n � となるTを知っているかを検証する手法 （以下、 基礎プロトコル） P（証明者）とV（検証者）の間で、下の試行を k回繰り返す � Pが実際にはTを知らないにも関わらず、k回連続して試行に成功する � 可能性は2k分の1 ① 乱数Rを選び、X = R2 mod nを計算し、Xを送付 ② bとして0か1をランダムに選び、bを送付 ③ bに応じて、以下のいずれかをYとして送付 Y = R b=0の場合 TR mod n b=1の場合 V（検証者） P（証明者） ④ Vは以下が成立するかでYを検証 ⑤ 上記に成功するたび、Pが2分の1の X ≡ Y2 （mod n） b=0の場合 確率でTを知っていることが証明され、 k回繰り返すと詐称確率は2k分の1になる ZX ≡ Y2 （ mod n ） b=1の場合 30
- 31. フェーズ2：あいまいな知人検証２ ゼロ知識証明を使う方法（３） 一般的なゼロ知識証明 ② � 大きな素数の積nに対し、nの素因数を知っているかを検証 する手法 � （公開鍵に対する秘密鍵を知っているかに利用できる） ① 乱数Tを選び、Z = T2 mod nを計算し、Zを送付 ② 基礎プロトコルを用い、Zのmod nでの平方根を Vが知っていることをPに証明 k回 ③ Pは n の素因数を知っているので、 Zのmod nでの平方根Sを計算できる ④ 基礎プロトコルを用い、Zのmod nでの平方根を Pが知っていることをVに証明 V（検証者） P（証明者） k回 31
- 32. フェーズ2：あいまいな知人検証２ ゼロ知識証明を使う方法（４） ゼロ知識証明を使うと � 外部（検証者含め）に一切情報を漏らさず、秘密の情報を � 知っていることを証明できる 検証相手が知人の秘密鍵を持っていることを証明できれば、知 � 人であると検証できる 段階的に確からしさを増すことができる � １回の検証では、本当に本人である可能性は 2分の1でしかなく、 � 何回も試行することで確からしさを増す 互いの検証試行を順番にやることによって、相手に自分の正体を � 確定させず、相手の正体も確認しながら徐々に相互検証できる どちらの側も、一度でも検証が失敗すれば、相手は知人ではないと � してそこで相互検証を停止すればよい 32
- 33. フェーズ2：あいまいな知人検証２ ゼロ知識証明を使う方法（５） ゼロ知識証明によるあいまい知人検証 � 公開鍵nを持つPさんと、公開鍵mを持つVさんの間の検 � 証 ① 乱数Tを選び、Z = T mod nを計算し、Zを送付 2 ② 乱数Uを選び、Y = U2 mod mを計算し、Yを送付 ③ Zのmod nでの平方根を知っていると証明 ④ Yのmod mでの平方根を知っていると証明 ③、④を k回繰り返す ⑥ m の素因数を使い ⑤ n の素因数を使い Yのmod mでの平方根計算 Zのmod nでの平方根計算 ⑦ Zのmod nでの平方根を知っていると証明 ⑧ Yのmod mでの平方根を知っていると証明 Vさん Pさん 公開鍵m 公開鍵n ⑦、⑧をk回繰り返し、 互いに知人と検証完了 33
- 34. 課題 検知 � 固定ビット数XORによる個人ID保護は十分か？ � 長期観測されることでIDを推定されないか � IDが詐取されている場合、位置的偏在性と併せ個人特定される � 可能性も XORビット数を可変にし、知人にだけ利用するビット数を � 知らせる案 複数チャンネルを準備するような感じ � 或いは全く別のプロトコルを考える � 検証 � 検知の段階で、複数の知人候補が存在すればどうするか � 個別に検証する � 複数の知人の公開鍵を使った検証結果を同報する � 34
- 35. ３．これらの技術の 存在する未来像 35
- 36. 将来、サイバーワールドは リアルワールドに重畳する リアルワールドと同期したサイバーワールド内で、位置偏在した情報がインタラク � ションする未来 アニメ：電脳コイル � 技術コンセプト：セカイカメラ � 実現に必要な技術シーズ � 正確で高速な位置・向き・傾き等のセンシング技術 � 高速でセキュアなローカルノード間の情報インタラクション � 36
- 37. これらの技術のない世界では･･･ 困ったわ、電波状態が サーバが混雑してて遅すぎ!! 悪くて中央サーバに Bさんと出会った今頃になって 繋がらないから 「近くにBさんが居ます」だって B 周りの状況が全然判らない しかも隣の路地にいること になってる やあ、 A君！ 近くにCさんが居るようなので C こっちに来ない？と誘ってる Cさん けど全然返答がない… … Bさん Aさん 危ねっ！ 危うく轢かれそうに 使えねーじゃん Dさん この歩行者支援 37
- 38. これらの技術がある世界だと･･･ オフラインだけど近くの お！この先にBさんが 情報源から直接情報が B 取れて街の様子がよく判る いるね！なるほど暇なのか、 あ、Dさんから誘いが来た！ それじゃ楽しそうな D 娯楽施設を近くから検索！ Bさん 近くにCさん見つけた！ C 初めての街で迷ってるみたい こっちに来ないと誘ったら OK OK、すぐ行くだって Cさん Aさん 先の路地に車が来てるな…… 位置の把握が正確だし 情報交換がローカルで Dさん 高速完結するから すばやく適切に行動できる 38