Protokollentwürfe für sicheres E-Collecting

[famoser]

Beim Hackathon wurde erstmals über sichere Protokolle für E-Collecting diskutiert (z.B. Team 6). Das ist nun schon eine Weile her, und um neue oder weiterentwickelte Ideen zu diskutieren, hier ein dediziertes Issue dazu (nach Absprache mit @dune73). Das Ziel ist es, die Grundidee von Protokollvorschlägen und deren Sicherheitseigenschaften zu diskutieren. Es würde mich freuen, wenn hier noch weitere work-in-progress Protokollvorschläge gesammelt werden könnten.

Wie in #5 dargelegt, umfassen die Sicherheitsaspekte eines E-Collecting Systems die "Verfügbarkeit des Systems", die "Sicherheit des Verfahrens" (keine Unterschriften können unterschlagen oder unrechtmässig gegeben werden) und die "Wahrung des Stimmgeheimnisses". Welche Annahmen dafür getroffen werden dürfen, analog z.B. zur VEleS für E-Voting, ist zurzeit aber noch nicht definiert von der Bundeskanzlei. Damit die Protokoll-Vorschläge miteinander verglichen werden können (siehe Kommentar in #2), bitte daher auch jeweils die Sicherheitsannahmen dokumentieren.

[famoser]

Referenz: Multi-Ballot
Status: Vollständiger Protokollentwurf, in wissenschaftlicher Aufbereitung

Die Grund-Idee ist es, die Unterschrift für eine spezifische Vorlage unter allen anderen Vorlagen zu verstecken. Konkret gibt es für jeden Wähler:in einen Mutli-ballot, der aus einem (ElGamal) Ciphertext pro Vorlage besteht. Der Ciphertext verschlüsselt jeweils 0 (nicht unterschrieben) oder 1 (unterschrieben). Möchte der Wähler:in eine Vorlage unterschreiben, wird der Ciphertext dieser Vorlage mit einer Verschlüsselung von 1 ersetzt. Alle anderen Ciphertext des Multi-ballots werden rerandomisiert. Ein zero-knowledge Beweis beweist, dass das Wahlgerät genau das gemacht hat (entweder 1 verschlüsselt oder rerandomisiert). Die Gemeinde geht bei Papier-Unterschriften genau gleich vor; 1 verschlüsseln für die Vorlage die unterschrieben wurde, und den Rest rerandomisieren. Der Multi-ballot wird dann an den Server versandt, und ersetzt das vorherige Multi-ballot. Der Wähler:in kann das Multi-ballot auf einem Zweitgerät wieder herunterladen und verifizieren, dass nur die gewollten Initiativen unterschrieben sind. Um Auszuzählen werden alle Ciphertext einer bestimmen Vorlage über alle Wähler:innen aggregiert, und diese Aggregation wird entschlüsselt, was direkt die Anzahl Unterschriften gibt.

Analyse:

• Die Verfügbarkeit des Systems ist gewährleistet indem die Wähler:innen sich wie "normal" authentifizieren (möglicherweise durch eine E-ID). Der Protokollvorschlag ist zudem kryptographisch verhältnismässig simpel und effizient.
• Dass keine Online-Unterschriften unrechtmässig abgegeben werden ist gegeben unter der Annahme, dass das Wahlgerät vertrauenswürdig ist.
• Damit keine Papier-Unterschriften unrechtmässig abgegeben werden können, werden die von der Gemeinde erstellten Multi-ballots bei der Auszählung auditiert. Zudem würde der Wähler:in auf seinem Zweitgerät dies ebenfalls bemerken.
• Bereits abgegebene Unterschriften können nicht entfernt werden, dies wird durch den zero-knowledge proof garantiert.
• Bei Papier-Unterschriften wird das Stimmgeheimnis gewahrt unter der Annahme, dass die Gemeinde vertrauenswürdig ist. Insbesondere muss dafür einem einzelnen Server nicht vertraut werden (Stichwort verifiable distributed key-generation / decryption).
• Bei Online-Unterschriften wird das Stimmgeheimnis gewahrt unter der Annahme, dass das Wahlgerät vertrauenswürdig ist. Insbesondere der Gemeinde oder einem einzelnen Server muss nicht vertraut werden.

[knr1]

Referenz: LH15

Eine Stimmabgabe wird über einen anonymen Kanal geleistet (z.B. TOR), und besteht aus drei Elementen. Das erste Element zeigt auf, dass die Person wahlberechtigt ist (mittels eines membership-proofs, der die Anonymität wahrt). Das zweite Element führt bei jeder Stimmabgabe der gleichen Person zum gleichen Wert, wodurch Doppelsignaturen herausgefiltert werden können (mittels eines commitments). Das dritte Element führt bei Stimmabgaben über Papier (=erstellt von der Gemeinde) und online (=erstellt direkt von der unterschriftsberechtigten Person) zum gleichen Wert, wodurch Doppelsignaturen über mehrere Kanäle herausgefiltert werden können (mittels eines verteilten Plaintext Equivalence Test (=PET)). Bei Stimmabgaben über Papier produziert die Gemeinde einen zusätzlichen Beweis (als Zero-Knowledge Proof (=ZKP)), dass sie die Stimmabgabe für den korrekten Wähler registriert hat.

Analyse:

• Die Verfügbarkeit des Systems ist gewährleistet da die Stimmabgabe relativ effizient validiert werden kann.
• Dass keine Online-Unterschriften unrechtmässig abgegeben werden ist gegeben unter der Annahme, dass das Wahlgerät vertrauenswürdig ist.
• Damit keine Papier-Unterschriften unrechtmässig abgegeben werden können, werden die von der Gemeinde erstellten Stimmabgaben bei der Auszählung auditiert. Zudem kann der Wähler:in auf seinem Zweitgerät seine Unterschriften auditieren.
• Bereits abgegebene Unterschriften können nicht entfernt werden.
• Bei Papier-Unterschriften wird das Stimmgeheimnis gewahrt unter der Annahme, dass die Gemeinde vertrauenswürdig ist. Insbesondere muss dafür einem einzelnen Server nicht vertraut werden (durch die PETs).
• Bei Online-Unterschriften wird das Stimmgeheimnis gewahrt unter der Annahme, dass das Wahlgerät vertrauenswürdig ist, und es einen anonymen Kanal zur Stimmplattform gibt. Insbesondere der Gemeinde oder einem einzelnen Server muss nicht vertraut werden.

[phish]

Gibt es beim Multi-ballot nicht ein Problem, wenn zu einem Zeitpunk nur eine Vorlage unterschrieben werden kann? Wenn der Server zu diesem Zeitpunkt von einer Person ein neues Multi-ballot erhält, dann weiss er was unterschrieben wurde.

[famoser]

Gibt es beim Multi-ballot nicht ein Problem, wenn zu einem Zeitpunkt nur eine Vorlage unterschrieben werden kann?

Genau, dem Ansatz liegt die Annahme zu Grunde, dass mehrere Vorlagen unterschrieben werden können. Auf Bundesebene scheint dies in den letzten 20 Jahren aber immer der Fall gewesen zu sein: Mindestens 5 (oft natürlich mehr) Initiativen waren immer gleichzeitig im Sammelmodus (gemäss einer eigenen Auswertung der Chronologie). Dazu kommen die Referenden, je nach dem wie fleissig das Parlament neue Gesetze verabschiedet hat.

[dune73]

Bedient der Multi-Ballot Server die verschiedenen föderalen Ebenen gleichzeitig mit einer einzigen elektronischen Urne?

Ohne zu tief graben zu wollen, aber es kann auf verschiedenen Ebenen ein unterschiedliches Elektorat geben. Das müsste berücksichtigt werden.

[famoser]

Bedient der Multi-Ballot Server die verschiedenen föderalen Ebenen gleichzeitig mit einer einzigen elektronischen Urne?

Ja, das wäre optimal (je grösser die Urne, desto besser für Privacy). Die Urne kann trotzdem föderal aufgebaut sein; also zum Beispiel die (Entschlüsselungs-)Schlüssel für kantonale Vorlagen nur beim Kanton platziert werden.

Ohne zu tief graben zu wollen, aber es kann auf verschiedenen Ebenen ein unterschiedliches Elektorat geben. Das müsste berücksichtigt werden.

Ja, das wird unterstützt. Auch Umziehen und andere Mutationen am individuellen Wahlrecht sind unterstützt (inkl. Verhinderung Doppelunterschriften, auch bei Kantonswechsel).

Der Multi-Ballot enthält ein Ciphertext pro Vorlage, und ist der Wähler:in zugeordnet. Durch die Zuordnung zum Wähler:in sind Mutation am Wahlrecht (z.B. Umzug) unterstützt. Durch einen dedizierten Ciphertext pro Vorlage bleibt Vorlagen-spezifische Administration gewährleistet (hinsichtlich Schlüsselverwaltung, Start/Ende der Sammlung, ...).

[famoser]

Der Unterschied von LH15 und Multi-Ballot ist vor allem bei den Annahmen zum Wahlgeheimnis:

• LH15: erwartet einen anonymen Kanal, der ausserhalb des Protokolls zu gewährleisten ist. Eine Implementation kann z.B. das TOR-Netzwerk mit einbeziehen; auch wenn dies kein perfekter anonymer Kanal ist (z.B. timing side-channels).
• Multi-Ballot: erwartet, dass stets mehrere Vorlagen gleichzeitig zur Unterschrift vorliegen. In diesem Fall kann das Protokoll selber die Anonymität gewährleisten. Dies bedingt aber auch, dass es durch das Auszählen keine zusätzlichen Privacy-leaks gibt (z.B. falls zu oft oder zu feingranuar ausgezählt wird, könnten ggf. wieder Rückschlüsse gezogen werden).

[herpaderpaldent]

Danke @famoser für das Issue. Ist dieses Issue auch da Protokollvorschläge zu verwerfen? Ich würde gerne sämtliche Post Vorschläge mit Scan-Centren früh verwerfen und keine Zeit dafür verschwenden, der Post ihr Business Modell zu retten.

Ich habe eine Frage zur folgenden Aussage

LH15: erwartet einen anonymen Kanal, der ausserhalb des Protokolls zu gewährleisten ist.

Team 6 sagt jedoch, dass ihr Proposal LH15 erweitet: This proposal extends **LH15** https://github.com/swiss/e-collecting-hackathon-team6/blob/main/README.md?plain=1#L27

Im Diagram sehe ich die Annahme und spontan leuchtet mir auch nicht ein, warum ein anonymer Kanal notwendig sein sollte. https://github.com/swiss/e-collecting-hackathon-team6/blob/main/docs/diagrams/hybridMode.mermaid

Könnte man ausführen, warum, wo und in welcher Phase das notwendig sein sollte?

[famoser]

Könnte man ausführen, warum, wo und in welcher Phase [der anonyme Kanal] notwendig sein sollte?

Der anonyme Kanal wird benötigt, wenn die Wähler:in ihre Stimme abgibt. Zu diesem Zeitpunkt muss die Wähler:in ja die Stimmabgabe zum Server senden. Der Server ordnet dann die Stimmabgabe einer Vorlage zu. Wäre die Stimmabgabe nicht über einen anonymen Kanal zum Server gekommen, wüsste der Server daher trivialerweise (ganz unabhängig von der Kryptographie) welche Vorlage unterschrieben wurde.

Vielleicht hilft der Kontrast zu Multi-Ballot bei der Intuition: Der Server bekommt hier immer einen Multi-Ballot zu sehen, der sich auf alle Vorlagen gleichzeitig bezieht. Daher kann der Server keine Rückschlüsse ziehen, welche der Vorlagen wirklich unterschrieben wurde. Von dem her ist es auch OK, dass der Server die Identität des Absenders des Multi-Ballots kennt.

Ist dieses Issue auch da Protokollvorschläge zu verwerfen?

Ich würde mich in diesem Issue darauf konzentrieren, vielversprechende Protokollvorschläge zu analysieren, aber wenig zu werten/verwerfen/hypen. Damit bleiben wir konstruktiv, und können die individuellen Vor- und Nachteile der Vorschläge besser verstehen. Das Ziel ist es, eine Intuition zu entwickeln, was technisch überhaupt machbar ist.

[dune73]

Ich würde mich in diesem Issue darauf konzentrieren, vielversprechende Protokollvorschläge zu analysieren, aber wenig zu werten/verwerfen/hypen. Damit bleiben wir konstruktiv, und können die individuellen Vor- und Nachteile der Vorschläge besser verstehen. Das Ziel ist es, eine Intuition zu entwickeln, was technisch überhaupt machbar ist.

Das ist das richtige Vorgehen. Wir können hier keine Entscheide fällen, aber wir können Argumente sammeln und Schwachpunkte identifizieren. Das trägt zu den Entscheidungsgrundlagen bei auf deren Basis dann etwas verworfen und etwas anderes bevorzugt wird. Diese Entscheide liegen aber nicht beim partizipativen Prozess.

Vielleicht noch ein Gedanke am Rande: Wir erreichen mit den öffentlichen Veranstaltungen bis dato etwa hundert Personen. Hier im schriftlichen Dialog bringt sich nur ein kleiner Teil dieser Personen aktiv ein. Eine Wertung oder Präferenz in der Diskussion hat deshalb immer nur ein beschränktes Gewicht. Durch den öffentlichen Charakter der Diskussion erhalten die Argumente trotzdem eine Sichtbarkeit. Ignorieren kann man sie in der Folge nicht mehr.

Wenn es also Vorbehalte gegen die Scan-Center-Idee gibt, dann ist es sinnvoll sie zu äussern. Verworfen ist sie damit aber noch nicht.

[herpaderpaldent]

Wäre die Stimmabgabe nicht über einen anonymen Kanal zum Server gekommen, wüsste der Server daher trivialerweise (ganz unabhängig von der Kryptographie) welche Vorlage unterschrieben wurde.

Wenn ich dich richtig verstehe gehst du davon aus, dass der POST etwa so aussieht:

POST /support/{B}
payload: B = ( c , d , e , u ^ , π 1 , π 2 , π 3 )

wobei B die Vorlage darstellt. Ich glaube da liegst du falsch, denn alles notwendige ist bereits in der Payload. ABER ich bin kein Cryptologe darum bitte korrigiere mich.

Mithilfe der E-ID und den rotierenden one-time keys. Wäre aufgrund der Authentifizierung die Rückverfolgbarkeit nicht mehr gegeben. Was bleibt ist die Verbindung, bspw. IP Adresse. Man könnte anhand der IP Adresse feststellen, welche Ballots unterstützt wurden.
Ist es das um was es geht?

[famoser]

Was bleibt ist die Verbindung, bspw. IP Adresse. Man könnte anhand der IP Adresse feststellen, welche Ballots unterstützt wurden.

Genau, das ist die Idee. Insbesondere Schadsoftware auf dem Server kann so rekonstruieren, wer sich hier verbindet.

[herpaderpaldent]

Genau, das ist die Idee. Insbesondere Schadsoftware auf dem Server kann so rekonstruieren, wer sich hier verbindet.

Ich würde im Sinne von Zero-Trust nicht nur von Schadssoftware ausgehen. Trotzdem, da wie du selber ausführst zum gleichen Zeitpunkt jeweils mehrere 'Events' stattfinden ist nicht klar welche Referenden oder Initiativen unterstützt wurden. Es könnte irgendeines gewesen sein.

Realistisch untersteht jedes Gesetz der Referendumfrist und dafür muss es jeweils ein Event geben.

Das einzige was ermittelbar wäre: dass die IP politisch partizipiert.

IMHO: Das ist verkraftbar, wir haben ja auch keine Kontrolle über die Browser und die Plugins der User.

[herpaderpaldent]

Wenn es also Vorbehalte gegen die Scan-Center-Idee gibt, dann ist es sinnvoll sie zu äussern. Verworfen ist sie damit aber noch nicht.

@dune73 Das bringt eine interessante Frage: Wie sieht der Prozess aus, dass Ideen und Protkolle verworfen werden können? Wir diskutieren gerade an einer kryptografisch sehr ausgefeilten Methodik und Privacy Themen und müssen 'Lasten' wie ein Scanning-Center ernsthaft mitdiskutieren?

[famoser]

Trotzdem, da wie du selber ausführst zum gleichen Zeitpunkt jeweils mehrere 'Events' stattfinden ist nicht klar welche Referenden oder Initiativen unterstützt wurden.

Beim LH15 Vorschlag stimmt das nicht, oder? Vielleicht stehe ich hier gerade auf dem Schlauch, aber jede Stimmabgabe ist mit einer Vorlage verbunden (insb. dem Generator h^), und dies kann vom Server auch so zugeordnet werden.