雑記

◆ PPID（Private Personal Identifier）方式のもとでRP間での名寄せを自動化する方法

このエントリは高木浩光さんの「富士通総研が研究員のコラムを削除、国民ID・共通番号制度を巡る現況」を読んで、PPID方式に対する誤解が広まるんじゃないかと勝手に心配して書いたエントリです。まず断っておくと、Webサービスで使われるPPID方式と情報連携基盤とではそもそも仕組みが全く違いますので、このエントリに書く名寄せの方法は情報連携基盤では使えません。従って、本エントリは高木さんの主張に何ら影響を与えませんし、私自身『フラットモデル』は論外という立場です。

RPの結託による名寄せの仕組み

さて、高木さんはLiberty Allienceの目的として、

*RP同士が結託してもIDによる名寄せができないようにする

と書かれていますが、PPID方式であってもRPが結託した場合、それらRP間で共通する利用者については機械的に名寄せが可能、ということを示したのが右の図になります。

図の上半分は前提となる部分で、IdP上でのID:xxxxのユーザに対して、RP1ではID:zzzzが、RP2ではID:yyyyが割り振られている様子を表しています。図の一番下にいるのが、今回の例で運悪く名寄せの対象となるID:xxxx@IdPの利用者です。この時、RP1とRP2が結託してシステムを構築し、図の下半分の流れとなるように仕組みます。

1. ユーザがRP1にログインする
2. ユーザが利用しているブラウザに対して永続的なCookieでRP1上のid:zzzzを保存させる
3. ユーザがRP2にログインする
4. 適当なタイミングでRP2のid:yyyyという情報を含むWebバグをページに埋め込んで、5.のアクセスを誘発させる
5. 2.でCookieとして仕込んだRP1上でのIDと、5.のリクエストに含まれるRP2上でのIDを紐付けする。この時点でRP1上では自サイトのzzzzと、RP2のyyyyの名寄せが完了する。
6. (おまけ)RP2にお礼として、RP1で紐付けられたIDのペアを渡す。

あとはこの仕組みを適当にカモフラージュして運用を続ければ、RP1-RP2間の名寄せは自動化できます。 したがって、PPID方式では

* RPのIDからIdPのIDを逆計算する
* RPがIdPのデータだけ{{fn 'RPにPPIDを振り出すための「種(salt)」は取られていないということ'}}を取ってきて、自分のデータとIDで名寄せする
* RPが他のRPのデータを取ってきて、自分のデータとIDで名寄せする
* 複数のRPからデータを取ってきて、それらをIDで名寄せする

といったことはできませんが、

* RPどうしが悪意を持って結託して、お互いのIDを名寄せする

というのを防ぐのは残念ながらできないということになります。

余談ながら、この方法はWeb広告やGoogle analyticsで使われているやり方のアレンジで、いってしまえば一般的に広く利用されている仕掛けの応用ですので、PPID方式自体の欠陥という訳ではありません。つまり、これを欠陥あるいはセキュリティ上の脅威として防ごうと思ったら、Web広告やGoogle analyticsも使えなくなるようにブラウザの仕様を変えるしかありません。

情報連携基盤でこの方法が使えない理由

PPID方式にこのような抜け穴があるなら、情報連携基盤にも同様の穴があるのではないかと考えるのは当然ですが、すばらしいことに情報連携基盤ではそのようなことが無いようにちゃんと設計されています。

個人情報保護ワーキンググループの個人情報保護ＷＧ（第３回）議事次第 の（資料２−２）番号制度 番号連携イメージに（ちょっとごちゃごちゃしていてわかりにくいですが）ある通り、情報連携基盤の利用において「利用者」は必ず「マイ・ポータル」および「情報連携基盤」経由で各「情報保有機関」にアクセスするような仕組みとなっています。図では「情報連携基盤」と「情報保有機関」を結ぶ専用回線を使った閉域ネットワーク内における連携でPPID方式を使うという事になっており、私が最初に示した図に当てはめられるような「情報保有機関」が直接「利用者」にサービスを提供する仕組みではありません。このため、「情報保有機関」にCookieやWebバグを仕込む余地は無く、一般的なPPID方式にある名寄せの危険性は情報連携基盤の現在の設計には無い、ということになります。

逆に言うと、「なぜマイ・ポータルなんてお仕着せのものを使う必要があるんだ、情報保有機関が直接サービスを提供すれば良いじゃないか」とか、官民問わず「情報連携基盤をWebサービスのIdPとして解放しろ」などという方向に向かうと危険ということになります。

一般的なPPID方式でのRPの結託のリスクは？

ここで情報連携基盤から離れて、一般的なPPID方式のWebサービスにおけるRP結託のリスクについてちょっと補足します。

最初に書いた通り、PPID方式でもRPどうしが結託した場合に名寄せは防げませんが、名寄せ可能な範囲はあくまで結託したRP間のデータのみで、IdPや、結託の枠外のRPのデータまで名寄せされることはありません。従って、こうした名寄せのリスクの大きさは、結託の規模によるといえます。

まあ、世の中にはすでにRPどころか、IdPも含めて結託して、名寄せ・マーケティングに利用しますと宣言しているシングルサインオンサービスもすでにありますが。楽天とか、楽天とか！、楽天とか！！、楽天とか！！！ 。

フラットモデル vs. リンクコード方式へのコメント

もうちょっとだけ続きます。うまくまとめられずに箇条書きで逃げている上に同じことを何度か書いたりしてますが、ご容赦を。

• フラットモデルでは「名寄せ」に作業不要
  • 右の図(上)で言えば、年金RP、医療RPからそれぞれ表を入手するだけで、互いのデータを紐付けできてしまう(1980.5-1981.3まで年金未納の人間が2005年の8月3日に内科で診療を受けている、とか)
  • PPID方式では、表を入手しただけでは、情報連携基盤および各情報保有機関のリンクコードどうしの紐付け(yyyy1 = zzzz3 (= xxxx2))はできない
• 「(国民)番号」ベースのフラットモデルはさらに論外
  • 右の図(上)でxxxx1,xxx2,...が「(国民)番号」状態
  • 「(国民)番号」と個人情報の紐付け情報は「情報連携基盤」外からも入手できる可能性がある。逆説的に情報漏えい時の影響範囲が「情報連携基盤」の外にまで広がってしまう。
• 漏えいしたときの影響に差が無い？
  • 「漏洩が起きたらそもそも駄目」というのは失礼ながら「安全神話」に通じる危険な思想に見える。漏えいは起きるものだと想定しての設計が今どきなのでは？というわけで以下その前提で。
  • フラットモデルでは、複数の情報保有機関から漏えいした時のIDベースの名寄せが簡単。例えば、年金RPで漏えいが起きた時、医療RPでさらに漏えいした場合のインパクトが大きくなる。そういう意味で漏えい時の影響範囲は情報連携基盤の枠組み全体に及ぶ。
  • そうした状況になってしまった場合に、フラットモデルでIDコードをリセットしようとすると、IdPや医療RPにまで影響してトータルで膨大なコスト負担が必要となる。
  • PPID方式では、年金RPで漏えいが起きた時に年金RPにおけるリンクコードだけをリセットできる。リンクコードを「見えない」コードにしておく利点はここにもある。
• フラットモデルでPPID方式と同等の安全性を確保することは不可能
  • 「リンクコード」を生成するための「種」をIdPが握っていて、RPだけでは「リンクコード」を再現できない点が重要
  • RPで「IDコード」を「種付きハッシュ」化しても、「手提げ金庫の底にセロテープで鍵」状態になってしまい、種ごと盗まれたらおしまい。
• 【余談】政治面とかパフォーマンスとか度外視するなら各情報保有機関に「個人情報」は持たせない設計がより理想的
  • 具体的には
    • 氏名・住所等の「個人情報」は情報連携基盤側で管理する。あるいは、「個人情報」専用の情報保有機関を作って情報連携基盤で中継する
    • 各情報保有機関にはリンクコードと各機関固有の情報との対応表だけを保存・管理させる
    • 情報連携基盤上で各情報保有機関のデータと「個人情報」をマージしてマイ・ポータルに渡す
  • メリット
    • 各情報保有機関が「個人情報」込みでデータを参照するときには、必ず情報連携基盤にリクエストしなければならなくなるので、「アクセスログ」を情報連携基盤で取れるようになる
    • 各情報保有機関のDBに保管されている情報だけでは完全に個人を特定出来なくなるので、PPID方式の優位性がより際立つ。

まとめ

* 一般論としてRP(IdP)に結託してWebバグやCookieを使われたら名寄せは防ぎようがない
* PPID方式では「RPどうしが結託しても名寄せできない」とは言い切れず「第三者による名寄せはできない。また、あるRPが漏えい起こした時に、IdPや他のRPに迷惑をかけない」ぐらいまで
* それでもPPID方式とフラットモデルとの間には越えられない壁がある