2012年11月04日

ハッシュ化ではユーザー追跡による名寄せ=個人情報の復号を回避できない

強固なハッシュ関数を用いても、名寄せ・ユーザー追跡を回避して個人情報を秘匿する役にはたたないことは、情報を利用する側の人以外には、あまり理解されていないように思う。
そうでなければ、「パスワードや個人情報をハッシュ化して対策」などという奇妙な誤解がまかり通るはずがない。現在のインターネット上で収集されるハッシュは元のメッセージとほとんど等価だ。


ハッシュでは元メッセージが推定できる
ハッシュ関数は原像困難性をもつので、秘密のメッセージMのハッシュC=H(M)から元のMを推定することは『メッセージMが完全にランダムな場合は』出来ない。
しかし、電話番号は約9桁で30bit程度しかバリエーションがない。48bitのMACアドレスも(UserAgentなどで公開される)端末のチップベンダーから高々24bitのバリエーションしか無い。

秘匿するべきメッセージの範囲が推定できる場合、いわゆる辞書攻撃ができる。メッセージとハッシュの組み合わせの辞書(あるいはレインボーテーブル)を用意することで、ハッシュからメッセージを復元できてしまう。30bitという組み合わせの数は6文字の英数字パスワード(30〜36bit程度)より弱い。

MACでも追跡し名寄せできる
漏洩対策として、ハッシュと秘密鍵やsaltを組み合わせたメッセージ認証=MACをハッシュ化と呼んで使うことが多い。パスワード保存時にハッシュとソルトを保存することは一般的になった(と願う)。しかしこれもほとんどの状況下で悪意ある名寄せの対策にはならない。

まず秘密鍵・saltがハードコードされた固定値の場合、秘密鍵Kは定数とみなせるのでMAC関数MH(M,K) == H(M) すなわち単なるハッシュに書き直せる。この場合、ハッシュ関数を書きなおすだけなので辞書攻撃のコストはほとんど変わらない。(パスワード保存にアカウントごとにランダムなsaltが必要な理由)

秘密鍵Kがユーザー毎に違って安全なMACであっても、IPアドレスなどの公開情報や、サードパーティCookie、ローカルDBなどアプリ・サーバー間通信を用いて、MACのままユーザーを追跡し名寄せすることは出来る。MAC自体から元メッセージを復元できない"匿名の識別符号"であっても、名寄せした先に個人情報、たとえばSNSのアカウント名や購買履歴などが紐ついていれば、最終的に個人情報の復元が可能になる。


個人情報を復号できなくするためには、
  • ハッシュではなく秘密鍵(salt)を組み合わせたMACを使うこと
  • 秘密鍵はランダムに生成し端末の安全な領域に保存し、他の情報から推定できなくすること
  • 秘密鍵はユーザーが追跡されてよいと考える範囲内でのみ保持・共有し、追跡されたくないときに破棄、あるいはランダムに再生成すること(例えば、アプリをアンインストールしたら秘密鍵を破棄する)

で足りるが、ユーザー追跡・名寄せによる個人情報の取得を回避するには、
  • ユーザー追跡手法を用いても、匿名の識別符号=ハッシュ自体を名寄せできないこと

が必要になる。
追跡の手段は多数存在し全てを遮断することは困難、そして個人情報を一切出さずにインターネット上で活動することは既に不可能に近い。個人情報と紐付けられた脆弱なハッシュや、悪意ある個人情報管理者が一つでもあれば元の個人情報を復元できてしまう。
ユーザーの個々のアクセスは匿名で行えても、ユーザー追跡は容易で、追跡した先に個人情報が紐ついている可能性は十分にある。

OS以下を管理できるPCなら追跡を排除できる可能性があるが、携帯端末のようにOSレベル以下を書き換えることが困難な場合それすら難しい。
アプリ内広告などに使われる端末固有識別子はアプリ自身が管理しているので、ユーザー側で名寄せ対策するには、全てのコードをデコンパイルし、実装・通信内容に問題が無いか確認するか、アプリと外部の通信を全て遮断するしか無い。

今のところ、アプリ利用時の権限チェックと、rooted・JailBreak端末で端末情報へのアクセスや広告サーバーへの接続を禁止することが現状最善の解決方法と考えている。しかし、実用上通信が必須なアプリは多く、root化済み端末をチェックして利用を拒否するアプリ・ライブラリはau marketなど既に普通に存在する。root化での環境改変自体法的にもグレーだ。アプリに許可された権限や署名を改変する、より強力な方法も無くはないが、OS実装に関する知識や安全な署名を必要とする。

不当な名寄せや個人情報の悪用は違法となるべきだが、ユーザー追跡・名寄せによる個人情報の収集はサーバー内で秘密裏に行うことが出来、巧妙な(あるいは馬鹿げた)利用規約で法律問題を丸ごと回避することさえ可能だ。
一方、セキュリティ上警察組織などリソースの限られた第三者しか情報の扱いの健全性を検証することが出来ないので、ユーザーには識別符号が適切に利用されているか判断することは不可能で、盲目的に信用するか、自衛するしかない。

アプリ開発側は、可能な限り送信・共有が必要な情報を明示し、通信内容の可読性を高めて第三者に検証をしてもらう努力をしなければ、利用者の不信は募るばかりと思う。


posted by ko-zu at 20:28| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。