信頼できる認証サーバー（クライアント側の暗号化なし）を使用して、投票に関する知識ゼロの証明を作成できますか？

Question

質問：

以下で説明するすべての機能を備えた安全な投票システムを実装できますか？
- 例えば個人の投票を政府のサーバー（または第三者）に開示せずに、ZKP投票などの必要な基準をすべて保持します。
この種のシステムでは、他に考慮すべきセキュリティの問題はありますか？どのように解決しますか？

動機

安全なオンライン投票システムが欲しい

notは暗号化チップに依存します（ドイツのIDカードなど）。これは、ユーザーが単にではなく特別なチップ読み取りハードウェアを必要とするため、展開の大きな障壁となります彼らのIDカード、または同様の障壁（たとえば、ほとんどの通常の人々は自己管理PGPを使用できません）
- それは、ハッカーだけでなく、特別なクライアント側ソフトウェアを使用するだけでなく、通常の人々によってsableである必要があります。 verifyingのようなより高度な機能には、特別なソフトウェアが必要になる場合があります（公開されているよりも多くの情報がなければ、anyサードパーティが実行できる限り）。
all分散型投票の参加者は、その問題に投票することを許可された一意の人間であるという公共の証拠を維持しながら、分散化することができます（つまり、単一の当事者がすべてのZKP投票を収集して二重投票なし）
anyoneへの個人の投票を明らかに開示しない。政府の認証サーバーと、投票の入力に使用するサードパーティのサービス（またはクライアント側のソフトウェア）を含む
- ユーザーがnon-provablyを使用して、自分の設定を第三者に開示することを許可します。サードパーティが適切なプロキシの推奨を提供できるようにするため

"セキュリティ"

ここでの「安全」とは、「少なくとも現在の投票方法と同じくらい安全」を意味し、「完全にすべての可能な攻撃に対して安全」ではなく、メールによる投票を含みます。ただし、攻撃を軽減できるとよいでしょう。 TOTP IDカードが盗まれた（そしてその署名が取り消された）場合、どちらの投票かを知らなくてもその投票を無効にできるとよいでしょう。

この質問の目的のために、一般的なウェブサイトのセキュリティ、トランスポートのセキュリティ、政府がこのような認証サーバーを実行することを信頼しているか、一意のIDを持っているか、誰かがあなたのIDカードを盗んでパスワードを知ることができるかどうかなどの問題に脱線しないでください、など、この問題に固有ではありません。

ここでの私の焦点は暗号化の質問です：仲介者（など）に投票を開示せずに、認証のみを信頼するサーバーによって認証された投票のZKPを取得できますか、そしてwithout =クライアント側の暗号化が必要（暗号チップIDまたはユーザー管理のPGPキーなど）。

背景

認証サーバー

次のような政府が運営するサーバーがあるとします。

正式に登録されたすべての情報（つまり、運転免許証、有権者登録など）を知っている
埋め込まれた [〜＃〜] totp [〜＃〜] ディスプレイ付きの物理的なIDカード（例：運転免許証）を提供します
- サーバーは、TOTPにフラグを付けるだけでTOTPを取り消すことができるはずです。取り消しは、ローカルのDMVまたは同様の機関との対面のプロセスであり、カードが紛失/盗難にあったと述べ、その権限に制限時間を課します（つまり、カードの有効期限）
IDのTOTP +パスワードを使用してサーバーを認証できます。
OpenID ish APIがあり、第三者がリクエストできるようになっています。また、次の情報のサブセットを選択的に承認できます。
- 次のいずれかのサブセットなどの識別情報：
  - リクエスタ固有の人間固有のID（基本的に、あなたが一意の人間であることを第三者に証明するが、他のサイトのサイト固有のIDに関連付けることはできない、不可逆的なハッシュ）
    - ユーザーの情報を相互に関連付けたいサイトは、共通のリクエスター（「シングルサインオン」ソリューションのように）を使用するか、少なくとも共通の疑似リクエスター（たとえば、単一のアイテムへの分散投票の場合）を使用する必要があります。「リクエスター」として投票されたアイテムのハッシュ。このような状況では、サイトは、自分の永続的な使用のためのIDと、その問題で共有可能なIDの両方を要求できます）
  - 名前
  - 物理アドレス（またはそのサブセット、たとえば郡、市、または州のみ）
- 次のサブセットなどの人口統計情報：
  - 性別
  - DOB
  - 年齢
  - 髪の色
  - 目の色
  - 高さ
  - 写真
- 以下のサブセットなどの法的権限：
  - 投票の承認（例：投票するために登録されている管轄区域のリスト、登録されている政党、以前の選挙参加履歴）
  - 運転推奨（例：車、オートバイ、トラックなど）
  - 警察または政府機関の承認（例：警察官、裁判官、地方検察官、法務長官など）
そのようなすべての応答には、署名に使用されたTOTPカードの（サイト固有の）ハッシュも含まれます（盗まれたIDで行われた認証を遡及的に無効にするため）。

この場合も、この情報の任意のサブセットを承認できることに注意してください。例えば必要な場合は、サイト固有のハッシュと投票資格情報の開示のみを承認できます。これにより、サードパーティに「地区XYZでの投票が許可された一意の人間」という最小限の情報のみが提供されます。
サードパーティが政府サーバーにblob（テキストまたはバイナリ。ハッシュの場合もある）を提供し、署名を要求するためのAPIがあります。

提供されたblob（サーバーによって表示されます）に署名するときは、上記の情報のいずれかと、オプションのタイムスタンプを署名の一部として承認することができます。

署名自体は、任意の数のメソッドを使用できます。

最も簡単なIMHOは、政府が管理するPGPシステムです。政府は、所定のIDカードに関連付けられた署名キーを所有し、そのキーを取り消したり、認証した政府機関のキーを使用してそのキーに署名したりできます。

その後、サーバーは（関連付けられたキーまたは独自のキー（[IDを公開していない場合]のいずれかを使用して）に署名します（a）blobと（b）その署名に関連付けるために選択した情報（標準化されたフォーマット）。

信頼

このサーバーが信頼されていると仮定のみ誰かの法的情報（または人間の一意性）の認証、および政府関連の問題（投票権など）に対する承認を提供します。

notこのサーバーを信頼して、ユーザーに何を署名してほしいかを知ってもらう必要があります。例えば。サーバーに契約の安全なハッシュのみを与えることにより、私的な契約に署名するために使用できます。その後、ユーザーはハッシュに署名し、それによって契約を署名します。政府に契約を開示したり、第三者に必要以上の情報を開示したりする必要はありません。

ZKP投票

最後に、ゼロ知識証明ベースの投票システムが必要であるとします。

誰もが投票に参加した人を知っています（投票に参加する権限があることを知っています）
投票数が正しいこと、つまり言い換えると、各（匿名）投票が参加者の公開リストの一意のメンバーからのものであることを誰もがまとめて確認できます
- これは、期限付きの単純なはい/いいえよりも複雑な投票でも機能するはずです。例えばランク付けされた選択肢、いくつかの選択肢間の割合の割り当て、期限なし、以前にキャストされた投票の更新/取り消しなど.
特定の投票者は、自分の投票が正しく集計されたことを確認できます
有権者の協力があっても、誰もどの有権者がどの方法で投票したかを証明することはできません（たとえば、有権者が自分の投票に嘘をついている可能性があるため）
液体民主主義スタイルのプロキシに投票を与えることができ、次に別のプロキシにプロキシすることができます。（プロキシーの投票は公開されていますが、識別されていないため、これは単なる補助システムです。プロキシーの投票は、最終的な結果に対する投票まで公に追跡できます。）
分散サービスで運用可能（投票のトピックについてのみ調整し、共有する必要がある）

私はZKP自体以外のプロトコルの提案を受け入れるつもりです。私が気にしているのは、単に上記の機能セットであり、ZKP（たとえば Helios Voting によって実装されている）は、私が知っている唯一の方法で、それらを満たしています。

問題は、私が見たすべての安全な投票方法がクライアント側の暗号（クライアント管理のPGPまたは暗号チップIDのいずれか）に依存していることです。これは、通常のユーザーが使用するためにロールアウトすることはできません。誰もが使えるもので十分安全なものが欲しい。

Tom Leek · Answer

ゼロ知識証明は、ある当事者（prover）が別の当事者（verifier）を説得できる「ステートメント」の証明です。）追加の情報を開示することなく、ステートメントが真であること。 Helios投票では、プロトコルは準同型暗号を使用します。簡単な説明は次のとおりです。

各投票は0または1として表されます。
投票者encrypts「中央公開鍵」を使用した投票。
準同型暗号化の魔法によって、暗号化された投票を一緒に追加できます：与えられたE（v₁）、E（v₂）、E（v_３） ...、計算できますE（v₁ + v₂ + v_３ + ...）、つまり投票の合計の暗号化。これは秘密鍵の知識がなくても実行できます。
合計が計算されると、秘密鍵を使用して復号化されます。秘密鍵はいくつかの部分に分かれており、すべての鍵の所有者は何かを解読するために協力する必要があります。それらの少なくとも1つが正直である場合、彼は投票の合計の復号化ではない復号化への参加を拒否します。特に、彼は個人投票の解読を防ぎます。

（Helios Votingは実際には、加算ではなく乗算の準同型であるElGamalを使用しますが、この答えには関係ありません。）

ここではZKPを使用して、有権者が実際に0または1を暗号化したことを示していますnot別の整数値。実際、不正行為を行うユーザーは、「40回投票する」ために、たとえば40を暗号化しようとする可能性があります。有権者は、暗号化された投票が0または1であることを証明する必要がありますが、実際の投票は開示しません。つまり、ゼロ知識証明supportクライアント側の暗号化です。 ZKPはクライアント側の「暗号」ではありません。これは、必然的にクライアント側で発生する余分な数学であり、クライアント側の暗号化にのみ関連しています。これは、クライアント側の暗号化が不要な場合、ZKPが主な問題ではないことを意味します。 投票暗号化です。

「クライアント側の暗号化」（クライアントシステムと一部のサーバー間のSSLトンネル、つまり単なるトランスポートを除く）が不要な場合、発生する必要のある暗号化はすべてサーバーで発生する必要があります。これは、クライアントが話しているサーバーが必要に応じてユーザーの投票の価値を知ることを意味します。これはしばしば投票システムの問題と考えられています。投票システムにしばしば必要とされる特性の1つは、投票者自身以外の誰も投票者の投票を知ることができないということです。

ただし、technicallyでユーザーの投票を学習できるサーバーがある可能性があることを許容する準備ができている場合は、そうしないでください（つまりtrusted servers）。問題は解決されました。必要なのは、有権者がこれらのサーバーのいずれかで認証する方法を持っていること（TOTPはそのために便利です）であり、サーバーに必要なすべての暗号化マジックを実行させます。

信頼できるサーバーがなく、クライアント側の暗号化もない場合は、遠くまで行けません。信頼されたサーバーがないと、投票値が有権者のコンピューターに「そのまま」存在することを許容できません。ただし、クライアント側の暗号化を使用しない場合、投票値は、接続の反対側にいる誰もがすぐに読み取ることができるプレーンな値を除いて、投票者のコンピューターを終了できません。

TOTP isクライアント側の暗号化ですが、認証以外には使用できません。確かに、TOTPは秘密鍵の知識の証明（[〜＃〜] zk [〜＃〜]証明ではない）であり、[]を知っているシステムによって検証可能ですキー。ワンタイムパスワードの内容は、現在の時刻と秘密鍵に依存しますが、それ以外には依存しません。特に、投票値には依存しません。

さらにいくつかのメモ：

クライアント側の暗号化は必ずしもクライアント側の秘密鍵のストレージを意味するわけではありません。クライアント側の暗号化の場合、クライアントコンピューターで実行するためにいくつかのコードが必要ですが、これはユーザーがキーリングなどを管理する必要があることを意味しません。 Webベースのコンテキストでは、コードはサーバーからダウンロードされることがよくあります（それがJavascriptについてです...）。
実際、インターネットベースのシステムの基本的な特性は、魔法のようなものです。これにより、彼らは「コンピュータ内」で行うことを意味します。これは、ほとんどの人にとって、不透明で魔法のようなものです。アーサー・C・クラークが言うように、コンピューターは人々の「魔法の地平線を超えた」ものです。平均的な投票者しない投票の正しさについて何でも確認できる。

これが、ほとんどの投票が依然として紙と封筒を使用する理由です。人々は紙を握ります。彼らは投票手続きを観察し、封筒を数え、彼らの開会を目撃し、何が起こっているのか一般的に理解することができます。これにより、選挙は攻撃に対して堅牢になります：多数の目。

これらの状況下で、電子投票システムで実行できる最善の方法は、if詐欺が（「信頼されたサーバー」によって）試行されたことを確認することですthen少なくとも知識のある専門家が回復できる可能性のある痕跡を残します。たとえば、フランスでのインターネットベースの投票（フランスに住んでいないフランスの選挙人の場合）はsigned Java applet：そのアプレットはクライアント側の暗号化を行います）を使用します。、プロトコルは、アプレットが正しく実装している限り、投票値を有権者にリンクできず、投票全体が安全で検証可能です。しかし、これはappletです：クライアントシステム、およびブラウザキャッシュにまだ存在します。署名されています。アプレットがスパイクされている場合は、逆コンパイルできます（Javaバイトコードをリバースエンジニアリングするのは難しくありません）。署名は、これは、あらゆる大規模な詐欺が発見される可能性が高い、または少なくとも非常に危険であることを意味します（そして、大規模ではない詐欺はどこにも詐欺師を招きません）。

フランスのシステムはあなたが望むものの良い例かもしれません。クライアント側の暗号化は、実際のソフトウェアのインストールなしで行われます（アプレットメカニズムはかなり合理化されています）。概念的には、純粋なJavascriptバージョンが実現可能ですが、コードにクライアントシステムに痕跡を残してほしいwith署名を使用して、コードの変更が危険にさらされるようにします。クライアントシステムにはシークレットのストレージはありません。投票手順の最後に、有権者は、すべての将来の暗号検証を可能にするのに十分な暗号情報を含むレシート（印刷可能）を取得します。 Voter authenticationメールで取得された2つの自動生成されたパスワードを使用します（メールではなく紙のメール）。有権者がTOTP対応デバイスを持っている場合（これがシナリオです）、TOTPを使用できます。

KnightOfNi · Answer

あなたの質問を読んでいると、応用暗号法（ブルースシュナイアー）の第6章のシナリオに似た多数の投票シナリオについて読んだことを覚えているようです。私はあなたがあなたの答えをそこに見ることを勧めます。

goodguys_activate · Answer

あなたが尋ねている一つの質問のようです：

「TOTPとパスワードで知識ゼロの証明を提供するには十分ですか？」

TOTPは本質的にサーバーの「キー」を認証に使用し、そのキーのプライバシーはサーバー上で公開されます。おそらく、TOTPよりも優れたもの、およびクライアント側に必要なものを実現するためのよりスマートなハードウェアが必要です。

それはあなたが尋ねているようにも聞こえます...

「使いやすい2要素認証をデプロイし、そのテクノロジーを再利用してZKPを提供するにはどうすればよいですか？

すべての暗号は数学です。「数学」を実行するインフラストラクチャを展開していて、選択した数学がTOTPである場合、ZKPを提供するために使用できる優れた方法があると思います。