端末固有IDおよびそれを基にした識別子を使った機構の問題について

SE

最近スマートフォン界隈でIMEIやUDIDなど端末固有IDの扱いをしくじってプライバシー的な問題が顕在化するケースが増えている。
この問題に対して「AppleがUDIDの利用を非推奨にした」「○○というIDを使ってると炎上する」といった観点でそれらIDの利用を控える向きもあるが、端末固有ID周りの問題を認識せずに「余所様が言うから」という理由で動いても同じ失敗を繰り返すだけだ。


と、いうことでこのあたりの問題について考えていることを書いておく。
特に端末固有IDを使うことで発生する問題にはセキュリティ的なものとプライバシー的なものが存在するが、前者についてはまともな技術者ならある程度わかるはずなので、ここでは前者はさらっと流して後者に重点を置いて記す。
なお、本来プライバシーに関しては端末固有IDのみならず個人に関わる情報全般を対象として考えるべきだが、今回は冒頭で述べた端末固有ID周りの「非推奨」「炎上」あたりに目が向きがちな方々への説明を想定しているので、端末固有IDに特化した書き方になっている。


まず、セキュリティ的な問題として「なりすまし可能」ということが挙げられる。
端末にずっとついてまわるIDなので容易に調べることができるし、当該IDをつけたリクエストなどをまったく別のところで生成してサーバに送ることもできる。
古き良きフィーチャフォン（ガラケー）のサービスではリクエストに付加された端末固有IDを基に認証することもあったようだが、それは、別の方法で端末を識別したキャリアゲートウェイがリクエストに付加している（かつ、おそらく事前にリクエストに不正な方法で付加されていたものは取り除く）ために原則信頼できることになっていたものであり、「別の方法で端末を識別」することなしに端末側のアプリで直接似たようなものをくっつける機構を用意しても、それが詐称し放題なのはすぐに分かることだろう。


で、本題のプライバシー的な問題としては「追跡可能」ということが挙げられる。
端末に限らず「固有ID」を利用することで考えられるいくつかのシナリオは結城浩さんが2003年頃に記した「固有IDのシンプル・シナリオ」にある。


先ほどのセキュリティの問題について正しく理解して対応できる技術者は多いと思うが、プライバシーの問題についてはイマイチ正しく理解できてなさそうなケースがみられる。
たとえば「A：端末固有IDは暗号化（もしくはハッシュ化）して使う」「B：端末固有IDを取ってるけど、うちは正しく扱ってるから問題ない」などだ。


「A：端末固有IDは暗号化（もしくはハッシュ化）して使う」は技術的に問題点が理解できていないケースである。


暗号化（可逆）の場合、変換前後の値は1:1もしくは1:nの関係にある。1:nというのは変換時に端末固有ID以外に可変の要素を含めた場合である。
ハッシュ化（不可逆）の場合、変換後の値の衝突の可能性があるので(1+α):1となるが、頻繁に衝突するようなアルゴリズムを使うことは少なく、母数が少ない場合はほぼ1:1に近いと考えられる。ハッシュ化の場合も変換時に端末固有ID以外に可変の要素を含めると(1+α):nになる。
このとき、暗号化にせよハッシュ化にせよ、変換後の値がnになってしまっては識別子としてのIDを使う意味が無くなってしまうため、通常はあるスコープの中では1:1となるように設計されることになる。また、スコープ外でnとなることを許容するのであれば、それはもはや端末固有IDを使って算出する必要がない値（スコープ内でUUIDを使えば事足りる値）ということである。


ここでプライバシー的な問題である追跡可能性について考えてみると、端末(X)に端末固有ID(X1)があったとき、端末固有ID(X1)と1:1関係にある暗号化（またはハッシュ化）後の値(X2)に追跡可能性を低減する効果があるのかどうかというと、否だろう。
端末(X)に密に紐付いた端末固有ID(X1)が、端末(X)に密に紐付いた別の端末固有ID(X2)に変わっただけである。


「B：端末固有IDを取ってるけど、うちは正しく扱ってるから問題ない」は技術的な問題ではなくユーザ視点に立っていないことによる問題のため、技術者でもきちんとした対応がしにくいのではないかと思う。


自分は、端末固有IDおよびそれを基にした識別子（暗号化したものやハッシュ化したもの）を使った機構については以下の問題があると考えている。

  • A1．裏側でユーザの意図しない名寄せが行われる可能性がある。
  • A2．ユーザからみて名寄せの可能性有無を検知できない。
  • A3．ユーザの意思で変更することができない。
  • A4．もっと個人と疎になる方法を選択できるケースがある。


まず、A1の可能性によって個人情報として機能してしまうケースがある。
機構を提供する側としては「うちは正しく扱ってますよ」と名寄せを否定することはできるのだが、A2の通りユーザがそれを確認することは難しい。
また、ある時点で本当に白であったとしてもビジネス転換やミスによって黒になる可能性が存在する機構なので、そもそも機構自体が不完全だといえる。


ここで、名寄せの可能性がある機構だとしても、ユーザが「危うい」と思ったときにユーザの意思でIDを変更して名寄せを断ち切ることができればまだよいのだが、端末固有IDあるいはそれを基にした識別子の場合、ユーザの意思では変更できない（A3）。


そもそも何故そのようなIDを使わなければならないのかを考えたときに、単純に「あるリクエストグループと別のリクエストグループを弁別したい」というケースの場合は何もそんなに固定化されたIDを使うのではなく、アプリ初回起動時にランダムな識別子を発行してそれを使うようにして回避できるはずである（A4）。


DRMのように業界としてソリューションを持っていない状態でライブラリが端末固有IDを利用するケースも存在するため、必ずしもすっきりと端末固有IDを使った機構と決別することはできないかもしれないが、上記のことから、個人的には代替できるケースでは使うべきでないし、代替できなかったとしても手放しでOKとは言えないと考えている。


ひとまず社内で上記のような文章を送りつけてみてはいるのだけれどどうだろう。