前回の記事で高校生判定プロトコルと現金支払いプロトコルについて述べましたが、新しいプロトコルを考案したので公開します。これを読んで、何か分からないことや改良する方法を考えついた方はコメントなどで知らせていただけると幸いです。
個人情報認証プロトコル
登場人物
ここには次のような登場人物がいると仮定します。
- JK
- 自分の年齢や性別などを公開したいが、自分の意図しない情報は公開したくない
- おっさん
- ある人間について、年齢や性別といった特定の個人情報を確定させたい
高校生判定プロトコルで書いたように、例えばJKが健康保険証などを用いてしまうと、名前や住所などといったおっさんには公開したくない情報が流出してしまいます。
プロトコルの制約
JKが公開できる個人情報
このプロトコルで公開できる個人情報には次の制約があります。
- 顔写真と住所がついた公的身分証明書によって確認できる情報
例えば、（僕の知る限り）血液型などといった情報は公的身分証明証では確認できないので、このプロトコルを用いて公開することはできません。
JKが使用できる公的身分証明書
公的身分証明書には、学校などが発行する学生証や自治体が発行する住基カードなど様々なものがありますが、このプロトコルで使用できる公的身分証明書は次の条件があります。
- 顔写真と住所がついており、デビットカードの発行に用いることができる身分証明書
つまり、学校などが発行する学生証は恐らくデビットカードの発行に用いることができないので、このプロトコルでは使うことができませんし、健康保険証は顔写真がないので同じく使うことはできません。一方で、運転免許証はこの条件を満すので使うことができます。また、デビットカードの発行に用いることができる身分証明書はデビットカード会社によって異なるので、このプロトコルで使用可能なデビットカード会社を次で定義します。
なお、この記事では以降、「公的身分証明書」という言葉を用いた場合は、暗黙の内にこの条件を満す公的身分証明書であるとします。
デビットカード会社
このプロトコルでは、公平な第三者機関としてデビットカード会社を仮定します。デビットカード会社は次の能力があるものとします。
- デビットカードの暗証番号と公的身分証明書のコピーを郵送で受け取る
- 郵送されてきた公的身分証明書のコピーが本当に存在する公的身分証明書からコピーされたものかを判定する
- 公的身分証明書のコピーが実在する公的身分証明書からのコピーであった場合、郵送された書類で指定した暗証番号で口座などへアクセスできるデビットカードを公的身分証明書に記載された住所へ郵送する
ここで公平な第三者とは、JKとおっさんのどちらにも協力しないということです。JKとおっさんの両方がこの第三者を信用していると言い替えることもできます。
また、デビットカード会社によっては年齢による申し込み制限を設けているところがありますが、今回仮定するデビットカード会社はそのような制限を行っていないものとします。
プロトコル
ここでは簡単のため、JKは自分の年齢と性別を公開し、その情報をおっさんが認証すると仮定します。また、JKは公的身分証明書として住基カードを使用するものとします1。
（住基カードの見本：http://www.city.itako.lg.jp/index.php?code=87）
-
JKは公的身分証明書のコピーを作成する -
JKは公開したい情報と顔写真だけが自分と同じであり、その他は全てデタラメな本物とそっくりの偽の公的身分証明書のコピーを$n$枚作成する（この例では、誕生年と性別はJKの公的身分証明書と同じだが、その他の情報はデタラメなものとする） -
JKはデビットカードの申し込み書類と封筒をそれぞれ$n + 1$組入手する。 -
JKとおっさんは喫茶店などで会う（この時JKは（1）と（2）で作ったコピー（$n + 1$枚）と（3）で用意したデビットカードに関する書類を持参する） -
JKはおっさんに（1）と（2）で作った$n + 1$枚のコピーを渡す（この時、コピーはシャッフルされていて、おっさんはどれが本物の公的身分証明書のコピーであるのか判定できない） -
おっさんはJKに関する知りたい情報が$n + 1$枚のコピー全てにおいて一致しているかをチェックする（この例では誕生年と性別をチェックする。また、公的身分証明書のコピー全てに記載された顔写真とJKの顔が一致しているのかもチェックする。このチェックに失敗すれば、プロトコルはここで失敗となる） -
JKはおっさんにデビットカードの申し込み書類$n + 1$組を渡す -
おっさんはJKに見られないように、デビットカードの書類$n + 1$枚全てに同じ暗証番号を書き込み、公的身分証明書のコピーと共に封筒に入れて糊付けする（JKは封筒の中を見ることはできないので、おっさんが書いた暗証番号は分からない） -
JKとおっさんは$n + 1$枚の封筒を全てポストへ投函する - デビットカード会社は届いた$n + 1$組の公的身分証明書のコピーをチェックする（このうち$n$枚は
JKが（2）で作成した偽の公的身分証明書のコピーなので、これらは書類不備となるが、（1）で用意した本物の公的身分証明書のコピーのみは受理される） - デビットカード会社は
JKの公的身分証明書のコピーに記載されている住所に対して、デビットカードを送付する -
JKはデビットカードを持参しておっさんとATMへ行く -
JKはATMにデビットカードを挿入する（デビットカードの表面にはJKの名前などが打刻されているので、それをおっさんに見られないようにする） -
JKとおっさんはATMを操作して、出金など暗証番号が必要な操作を実行する -
おっさんは（8）で設定した暗証番号を入力する - 暗証番号が正しく受理されればプロトコルは成功であり、失敗すればプロトコルは失敗となる（この時、
おっさんは暗証番号の入力をやり直すことはできない）
このプロトコルでは確かにおっさんはJKの本当の公的身分証明書を見ることになりますが、$n$枚のダミーデータによって、それを隠蔽しています。ダミーにおいても本物においてもおっさんが確定させたい情報は同じなので、おっさんにとってはどれかが本物であればよいということになります。
マリシャスな振る舞い
JKやおっさんが行えるマリシャス（悪意ある）な振る舞いについて検証していきます。
おっさんが偽の公的身分証明書コピー生成システムをJKに提供する
このプロトコルでJKがネックになるのは、ダミーの生成です。これを自動化するアプリケーションを開発するのはそれほどの技術的な困難はありませんが、自動化アプリケーションの開発者はJKが信頼できる人であるか、あるいはオープンソースになっていて、ソースコードをJKが検証したのちにコンパイルしたものでなければなりません。
なぜなら、自動ダミーデータ生成アプリケーションの開発者がおっさんもしくはその協力者であった場合、一見ランダムに生成されているようで、名前の文字列や誕生日などといった情報にダミーデータであることを表す情報が埋め込まれている可能性があります。例えばダミーデータ生成アプリケーションで生成されたデータは全て「誕生年と誕生月と誕生日の和を$11$で割った余りが必ず$0$になる」といった規則を持たせておけば、おっさんはダミーデータを判別してJKの公的身分証明書を突き止めることができます。
おっさんがATMでの暗証番号認証失敗時に再試行を行う
おっさんがATMでの暗証番号認証失敗時に再試行を行うことを許可してしまうと、次の手法でJKの個人情報が流出する可能性があります2。
-
おっさんは（8）で暗証番号を設定する際に、$n + 1$枚全てに別々の暗証番号を設定し、設定した暗証番号と個人情報の対応を記録する（JKはおっさんの設定する暗証番号を見てはならないので、暗証番号が全て同じになっていることを保証できない） - （15）で暗証番号の入力を繰り返し行い、成功した暗証番号に対応する個人情報が
JKの本当の個人情報であると決定する
ただ、このようなマリシャスなおっさんを逆手に取って、JKは次のマリシャスな行為が可能になります。
-
JKは本物の公的身分証明書のコピーを用いずにこのプロトコルを実行する（おっさんに見せるコピーは全てダミーなので、JKはおっさんの設定した暗証番号を持つデビットカードを入手できない） -
JKは適当な暗証番号を持つデビットカードを入手する -
おっさんは暗証番号を最大で$n + 1$回行う（$n + 1$回の試行で、JKが適当に用意したデビットカードの暗証番号と偶然一致してしまう可能性がある）
このように、複数回の暗証番号入力を行うことになるとプロトコルが破綻することもありえるので、JKとおっさんの両方にとってマリシャスな振る舞いの意味をなくすために、複数回の暗証番号入力は認めないものとします。
JKが他人の公的身分証明書を用いる
JKが他人の公的身分証明書を入手する手段について考えてみましょう。次の二つのパターンがあります。
- 他人から同意なく奪う、もしくは偶然落ちているものを拾う
- 協力者から貸してもらう
まず、前者の場合ここのプロトコルで用いる公的身分証明書は住所の記載が前提となっており、デビットカードはその住所へ郵送されることになっています。ですので、他人から同意なく入手した公的身分証明書を用いたとしても、郵送されるデビットカードが受け取れずにプロトコルが失敗します。
また、協力者がいて公的身分証明書を貸してもらっている場合、協力者の住所へデビットカードが郵送され、協力者を経由してJKへデビットカードが渡る可能性はあります。ですが、そもそもこのプロトコルで用いる公的身分証明書は顔写真が前提となっています。協力者の公的身分証明書に記載されている顔写真がJKの顔と異なるため、JKは次のどちらかの選択をする必要があります。
- 顔写真を偽造する
- 顔写真を偽造しない
まず、顔写真を偽造した場合、もはやそれは本物の公的身分証明書ではないということになるのでデビットカード会社によって書類不備となりデビットカードが発行されません。また、顔写真を偽造せずに用いた場合、おっさんが実際のJKと公的身分証明書のコピーの写真と比較するので、顔がとても似ている場合を除きおっさんに公的身分証明書が他人の物であると分ってプロトコルが失敗します。
このような理由から、このプロトコルで使える公的身分証明書は顔写真が必須となっています。
既知の脆弱性
おっさんが総当たり的な身元調査を行う
このプロトコルで使用する公的身分証明書は$n + 1$枚であり、JKがこのプロトコルを真摯に実行していたとすれば、この中に本当の公的身分証明書があるということになります。つまり$n + 1$枚のコピー全てに書かれた情報を調査することで、いつかはJKの公的身分証明書に記載された個人情報に到達できてしまいます。さらに悪いことに、おっさんは探偵業者などを使うことで調査能力をお金で分散並列処理することができます。
このおっさんによる総当たりについては、今のところダミーの数$n$を巨大にするしかないですが、そうすることで一回のプロトコルにおけるJKの負担が増加してしまいます。この部分に関しては今後の課題です。