高木浩光（@HiromitsuTakagi）さんによる『UDIDやIMEIの取得について「ハッシュ化すればOK」の考察』

Hiromitsu Takagi @HiromitsuTakagi

UDIDやIMEIの取得について「ハッシュ化すればOK」のような主張が見られるので、この点について検討。

Hiromitsu Takagi @HiromitsuTakagi

問題とされているこの種のIDを、直接ではなく（暗号学的）ハッシュ関数に通した値を取得したとしても、そのID取得で懸念される問題の何一つ解決しない。「ハッシュ関数を通せばOK」という考えは、何が問題とされているのか知らないためであろう。

Hiromitsu Takagi @HiromitsuTakagi

「この種のID」は、誰もが共通に利用できるIDである。つまり簡単に言えば公知のIDということ。それを隠すことには意味がない。

Hiromitsu Takagi @HiromitsuTakagi

公知であることと取得してはならないことが矛盾するかのように思われるかもしれないが、全員が取得しないのを厳守すれば公知でなくなるが、誰かが取得し得るからには公知である。「誰かが取得するんだったら俺が取得してもいいじゃないか」というものではない。

Hiromitsu Takagi @HiromitsuTakagi

例1：UDIDでログイン状態を維持するサービスというセキュリティ上の欠陥を問題とする場合、UDIDをハッシュ化しても解決しない。なぜなら、元のUDIDが公知なのだから、ハッシュ関数が公知であれば、元と変わらぬセキュリティ上の危険が残る。

Hiromitsu Takagi @HiromitsuTakagi

例2：UDIDに個人に関する情報を紐付けて収集・記録するサービスが複数ある場合、それらがUDIDで名寄せして結合されることを問題とする場合。あるサービスがUDIDをハッシュ化したとしても、皆が同様に同じハッシュ関数を用いるようになれば、結局元と同じこととなる。

Hiromitsu Takagi @HiromitsuTakagi

このことは、「社会保障と税の番号制度」においても議論されており、番号が「裏番号」化して脱法行為となるのを防ぐよう、番号の目的外利用等の禁止規定に、ハッシュ化した番号等も含まれるように、法案が検討されているはず。「ハッシュ化すればOK」という人らはマイナンバーにもやりかねない人達。

Hiromitsu Takagi @HiromitsuTakagi

では次に。単なるハッシュ関数ではなく、鍵付きハッシュ（HMAC等）で変換した値にすればいいのか？

Hiromitsu Takagi @HiromitsuTakagi

鍵付きハッシュにするといっても、その鍵はアプリに固有の鍵でそのアプリの利用者では共通の鍵となる。そして、その鍵は（IDをアプリの外に出さないのであれば）アプリに内蔵されることになる。よって鍵は（発見され得るものなので）公知である。先の例1のセキュリティ欠陥への解決先にはならない。

Hiromitsu Takagi @HiromitsuTakagi

では先の例2の問題に対してはどうか。まず、「鍵付きハッシュにしているのでOKです」言っても、同じ鍵でハッシュしている他の業者がいる（それを認識している）なら、詭弁である。そうではないとして、鍵は他社に使ってほしくないと考えている場合に、誰かがその鍵をあえて使う場合があるかどうか。

Hiromitsu Takagi @HiromitsuTakagi

誰かがその鍵をあえて使う場合、何が動機か。……

Hiromitsu Takagi @HiromitsuTakagi

それ以前に、例2の問題は、2つのデータを名寄せできるかである。公知であるIDの値（の候補）が手元にあって、データAのアプリ鍵とデータBのアプリ鍵も公知なのなら、ハッシュ化されたIDも計算できるので、それを用いて名寄せできる。

Hiromitsu Takagi @HiromitsuTakagi

よって、鍵付きハッシュにしても駄目。

Hiromitsu Takagi @HiromitsuTakagi

次に検討し得るのは、IDをサーバに送って、サーバ上の秘密の鍵で鍵付きハッシュに通して、それを記録する方法にした場合。データだけ流出して鍵は流出しないとの仮定で、そこに意味があるか。