JK・おっさんプロトコル Ⅱ
前回の記事で高校生判定プロトコルと現金支払いプロトコルについて述べましたが、新しいプロトコルを考案したので公開します。これを読んで、何か分からないことや改良する方法を考えついた方はコメントなどで知らせていただけると幸いです。
個人情報認証プロトコル
登場人物
ここには次のような登場人物がいると仮定します。
- 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
の負担が増加してしまいます。この部分に関しては今後の課題です。
Author And Source
この問題について(JK・おっさんプロトコル Ⅱ), 我々は、より多くの情報をここで見つけました https://qiita.com/yyu/items/9e0d146f2e1b0ebb645d著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .