トップ «前の日記(2012-06-13) 最新 次の日記(2012-06-17)» 編集

日々の破片

Subscribe with livedoor Reader
著作一覧

2012-06-16

_ 電子投票は難しい

ちょっと電子投票システムについて考えてみたが、おれの想像を超えて厄介なものだな、と気付いた。知らぬはおればかりなりということだ。

東京とかで考えるからいい加減になるので、以下の条件で考えてみた。

・田舎町の市長選挙

・プロバイダはCATV一社のみ。CATVということもあって、ほぼすべての市民はこの回線を利用している。

・携帯回線(3G)はある。

・システムは選挙管理委員管轄で、サーバールームは市役所にある。

・市長選には、現職、対立の2者が優勢で、他に共産党と無農薬エコがそれぞれ立候補している。50:46:4:0 くらいな状況。

・現職市長の一派は地元の昔ながらの経済を牛耳っているので、店子とかは大家から、現職に投票したほうがいいですよ~とかそれとなく言われているので、ちょっと他の候補者に入れると知られたくはない状況。特に地場の企業に就職している人間は毎日演説会にまで動員させられている始末。ちなみにプロバイダのCATVは現職が10年前にてこいれして引っ張って来た会社で、現職市長の弟が社長をやっていたり。

・対立候補は、地元の大手工場の労組が支えているので、工員たちは~君をよろしく、と毎日言われている状況。現職に投票したのがばれるとなんかいやんなことが起きそうな予感。工員はやたらと数がいて、市の半数弱を占めている。

・最近の地元不況で、一部の商店主とかが対立候補に傾きつつあるという噂も流れている。商店会の会長は、裏切りものが出ないか毎日のように親睦会を開いて睨みをきかせている。

・市内でシステムを構築できる技術を持つ企業は、大手工場に付属しているソフトハウスと、現職の甥が経営しているソフトハウス(基本的に市役所のシステム構築は数十年にわたってここが受託している)。

システム要件は選挙である以上は、

・選挙人は全員1票を投票する権利を受けられる

・選挙人は1票のみ投票でき、投票後は再投票はできない

・どの候補者に誰が投票したかは絶対にわからない(あたりまえだ)

・選挙人の数は1万弱程度(ちょっと多い気がするけどまあいいや)と想定する。

・投票された1票は確実に選挙人の投票行動と一致する。(現職に投票したはずが、いつのまにか対立候補にカウントされるということはあり得ない)

問題点

まず政治的な合理性に基づいて考えると、現職が勝てばCATV会社を経由している点が怪しまれる。対立候補が勝てば、市役所内のサーバーチェックだの、CATV会社でのログチェックで、犯人捜しが行われるのも想像の範囲。

というか、投票システムの入札でどこが受託するかはやる前からわかっている。仮に予想が外れても大差がなかったり。というわけで、どうすれば、そのシステムが公正なシステムと担保できるかが最初の問題。

仮にそれが解決したとしても、これまでの紙の投票だと、さすがに1万枚弱の筆跡を分析したりするのは無理だと思っていた連中が、システム化されれば、誰がこの市に住むべきではないかとか、減給対象にできるかとかが、ばっちりわかるのではないかと期待している状態を、どう解決できるかが次の問題。

つまり、選挙が匿名で行われるということ=誰が投票したかわからないのであれば、現職のほうが得票が多かったと発表すれば済むし(なぜなら誰が誰に投票したか調べられない)、逆に誰が誰に投票したかがわかるのであれば徹底的に社会的報復を食わせられるのでそれもまた良し、と期待にわくてか状態の人たちの期待をどのようにすれば、それが無理だとシステム的に理解させることが可能なシステムとできるかという問題である。

・まず、そう考えてみると、電子投票システムは、暗号のアルゴリズムと同じで、公開システムでなければならないようだ、ということが想定できる。投票箱への投票行為と開票行為は完全なホワイトボックスシステムである必要がある。(受託して開発するようなものではなく、オフザシェルフでなければならない)

・経路の安全は、内容の秘匿だけで不足で、アプリケーション層が内容を取り出した瞬間に経路情報から完全に分離する必要がある(デバッグが大変そうだ)。つまり、このIPアドレスから送られたメッセージというものと、この投票トークンというものを、後から再結合できないようにする必要がある。でも、その一方で、その投票トークンが明白にシステム内で生成されたものではなく、外部由来のものだということが明らかでなければならない。

とすると、まずシステムそのものは、第3者機関が提供、設置するものでなければならない。最初の前提と変わるなぁ。ベリサインみたいな機関が必要なのだな。ISPはそうであれば単なる通過点となるため、内容さえ秘匿できていれば良い。

誰が誰に得票したかは、本人確認が可能であれば良しとして(そうでなければ、その投票は私ではないと名乗ることに問題ない)考えると、個人と紐付けた投票トークン(これは公開)と、そのシステムを通して得られるハッシュ(これは秘密。本人は参照可能)とし、システムはハッシュと被投票人の紐付けペアを持てば良い。追記:投票時に生成する必要がある(おそらく投票時間をソルトとして付加することで、公開の投票トークンを知っていても再現できないものとしなければならない。投票トークンと投票先を送ると、ハッシュ(意味としては秘密の投票トークンだな)が返ってくるので投票人はそれをメモすることで自分の投票を後で検証可能とする、とすれば良いと思う)

そのようになっていれば、最悪の状況として、開示が必要となれば、ハッシュとその投票先のリストを公開する。ハッシュは本人のみが知っているので自分の投票結果と一致するか、あるいは自分がリストされているかを確認できるということだ。もし自分の投票結果と一致しない、あるいはリストされていない、という状況が確認できればそこで文句を言える(と思うが、最初の前提から、対立候補に投じたはずの票が、なぜか現職に投じたことになっていても、公開の場で異を唱えられないということはあり得る。というわけで、バグ以外の原因で投票行為を恣意的に操作することが考えにくい第3者機関がシステムを持つ必要があり、投票結果を左右するような有意な障害は起きないものとみなせなければならない。面倒くさいな。追記:これだと水増しされたリストが発表された場合に間違いを指摘できない。どうやって水増しされていないことを担保できるか? これも第3者機関なのでそのモチベーションが無いということで担保するしかないのかなぁ)。

ここまでを確認すると、まず投票結果の集積所は第3者機関とし、投票トークンの発行は現在と同様にどこでも良く、ただしハッシュの生成と管理は同様に第3者機関が行うとすれば済む。(通信はSSLで良い)

なんか、まだまだ電子投票が可能な民度に達していませんというように感じてしまうおれがいる。

本日のツッコミ(全1件) [ツッコミを入れる]
_ shiro (2012-06-16 16:44)

水増し検出の問題は http://www.loria.fr/~skremer/Publications/b2hd-KRS-esorics10.html で言うeligibility verifiablityでしょうか。流し読みしかしてないですが、複数回のやりとり(全員投票後になんかキーが付け加えられて、各投票者がそれを確認してまた何か付け加えるとか) を使う必要があるんですかね。ソーシャルな問題も考えると、投票システムだけで完結して作るのは難しそうですね。むしろ一般的に「匿名かつverifiableな通信」というのが実用化されてみんなそれを普通に信頼して使えるようになってからの方がいいんじゃないかという感じを私も受けます。(そんな通信、投票以外に使い道あるのかって話になりますが…)


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|

ジェズイットを見習え