マイナンバーとzk-SNARKs


#1

まだまだzk-SNARKsの理解は浅いですが、chrisethのホワイトペーパーやherumiさんのpairing暗号の解説やmiximusのコードを読み漁って匿名送金の実装が理解できている程度のレベルで試しに考えてみる。

マイナンバーの漏洩を知るためのコントラクト

  1. マイナンバーが漏洩したか知りたい人(漏洩者)のためを想定して 本名+sha3(マイナンバー) を100ETHの供託とともにコントラクトのstateとして保存する関数を用意する

  2. そのコントラクトの別の関数として、漏洩したマイナンバーを知っている人間(攻撃者)の存在を想定した「100ETHの供託とともに 本名+sha3(マイナンバー) を入力すると、攻撃者の供託と漏洩者の供託を合わせた200ETHが戻ってくる」というものを用意する。この関数は1アドレスに一度だけ使える。外れたら供託は漏洩者に渡る。

  3. 漏洩者は、供託を奪われない限り、マイナンバーが漏洩していないと想定することができる。

  4. 漏洩者はマイナンバーを開示することなく(高額の供託を払って)攻撃者が少なくとも一人いることを確認できる。SybilAttackは攻撃者の供託負担のために緩和されている。

欠点としては漏洩者の確認コストとしての供託額が非現実的な点。しかしzk-SNARKsの応用を考える練習問題として一から考えたにしては悪くない気がしている。このようなバカバカしい設計から初めて贅肉を削ぎ落とすのが良いアイデアには効くので、これからも暇つぶしにやっていきたい。

P.S. おそらくsha3ハッシュで書いているところをpairing暗号の楕円関数ベクトルで表現して、それをzksnark_verify関数にかけてbool判定しないと意味ない


#2

マイナンバーが、日本で使われているあのマイナンバーだとすると、そもそも人に渡すものだと思っていて、そこについては一旦置いておくとすると。

まき餌っぽい感じで面白いですね。そしてマイナンバーを人に渡さずに運用する方法も同様に設計できそうですね。


#3

逆フィッシング攻撃とか取り入れると、供託金緩和できそうですね。

  1. 本名+sha3(マイナンバー)をエントロピーとして秘密鍵を生成しEOAを作成する。
  2. 1.で作ったEOAに100ETHと等価値のtokenを送金する
  3. 1.のadressのETH保持数を0にする
  4. マイナンバーを知っている攻撃者が2.のTokenを引き出すために1.のEOAにETHをデポジットする
  5. 実は裏で毎回1.のEOAからETHを引き出すtransactionが投げ続けられており、攻撃者のETHは没収される。でも攻撃してきた事はわかるので漏洩している事もわかる。

みたいな?


#4

zk-SNARKs要素が消えてしまったので誰かうまいこと復活させてあげてくださいw
秘密鍵作るところとかで使えそう?なんか無駄な事やってるかなぁ。。。。


#5

こねくり回してると何がzk-SNARKs要素なのかよくわからなくなるのわかる。とりあえずzkverify関数をRinkebyでたくさん使ってみて肌感を身に着けましょうか