Liquid Democracy/Internetwahlen

Dieser Artikel ist keine offizielle Aussage der Piratenpartei Deutschland, sondern hier findet/fand eine offene Diskussion des Themas statt. Wenn Du meinst, diese Idee erweitern zu können, tu es, aber bitte beachte die Diskussionsregeln. Ist die Idee tragfähig und mehr als eine Einzelmeinung, so kann man das Ganze auch als Entwurf kennzeichnen.

Komplizierte Wahlsysteme sind wirtschaftlich nur Online durchführbar. Im Gegensatz zu den bisherigen Blackbox-Wahlcomputern sollte innerparteilich ein "Internetwahlsystem" etabliert werden, dass ein freies, geheimes und nachvollziehbares Abstimmungsverfahren ermöglicht.

Vorschlag

Vorgeschlagen wird der Einsatz von Wahlbeobachtungsservern zur laufenden Überprüfung der Ordnungsmäßigkeit.

Vorbereitung: Der Benutzer definiert eine PIN, die er zur Abfrage seiner Stimme verwenden kann. Dies geschieht bei der Erstinitialisierung lange vor der Wahl und evtl. am besten bei einer Tagung. Diese PIN wird auf der Festplatte des Benutzers in sicherer Art und Weise gespeichert (Key Chain, AES verschlüsselt ..). Bei der Erstinitialisierung wird auch die PKI aufgebaut.

Nach der Vorbereitung erfolgt der Wahlvorgang in sechs Schritten:

1. Der Benutzer startet die Wahlsoftware, loggt sich mit seiner ID ein und sendet einen Block von Zufallszahlen.
2. Der Berechtigungsserver ermittelt, ob der entsprechende Benutzer wahlberechtigt ist.
3. Der Zufallsblock wird vom Berechtigungsserver signiert. Der so signierte Block heißt nun Token A.
4. Die Wahlsoftware verschlüsselt nun die Stimme mit dem Schlüssel des Wahlleiters und dem eigenen Schlüssel (der die PIN als Passphrase hat). (Technisch: Mehrfache Verschlüsselung eines Schlüssels für den eigentlichen Inhalt). Token A wird nun zusammen mit der verschlüsselten Stimme und einem NEUEN Zufallsblock an den Urnenserver versendet.
5. Der Urnenserver prüft die Signatur von Token A und speichert die Stimme. Er meldet dem Berechtigungserver, dass er die Stimme des Benutzers angenommen hat.
6. Der Urnenserver signiert nun den neuen Zufallsblock. Dieser signierte Block wird nun Token B genannt.

Zu einem späteren Zeitpunkt, z.B. alle 3 Stunden oder wenn mindestens 50 Stimmen zusammengekommen sind, werden Token A und (Token B+Verschlüsselte Stimme) an die Wahlbeobachter geschickt. Es darf keine zeitliche Korrelation zwischen Token A und Token B geben, damit durch Logging beim Berechtigungsserver keine Personenkorrelation hergestellt werden kann.

Diese Wahlbeobachter erlauben dem Wähler unabhängig von den Wahlservern zu ermitteln, ob die Stimmen bearbeitet wurden. Auch ist eine spätere Kontrollzählung über die Wahlbeobachter möglich, sofern sie entweder über den Schlüssel des Wahlleiters oder über die PIN der Wähler verfügen. Wenn ein Wähler wissen möchte, ob seine Stimme korrekt angekommen ist, kann er Token B an einen Wahlbeobachtungsserver senden. Evtl. zusammen mit der PIN und seine Stimme entschlüsseln. Wird eine ungültige PIN angegeben, ist das entschlüsselte Ergebnis nicht korrekt. Allerdings wird trotzdem ein Ergebnis angezeigt, da der Wahlbeobachtungsserver nicht erkennen darf, ob die Entschlüsselung korrekt war.

Um entscheiden zu können, ob eine Stimme korrekt entschlüsselt wurde, bedarf es einer bekannten Sequenz an bytes. Diese dürfen nicht vorhanden sein in dem Teil der Stimme, die mit dem privaten Schlüssel entschlüsselt werden kann.

Zur Stimmauszählung werden alle Stimmen mit dem Wahlleiterschlüssel dekodiert und ausgewertet.

Vorteile

• Die Daten werden an mehrere Wahlbeobachter verteilt, die eine logische Überprüfung durchführen können (Stimmt die Anzahl der Registrierungen mit der Anzahl der Stimmen überein).
• Der Benutzer kann auf redundante Art und Weise prüfen, ob seine Stimme angenommen wurde.
• Er kann verifizieren, ob die Stimme korrekt abgegeben wurde.
• Er kann durch die bewußte Eingabe einer falschen PIN die tatsächlich abgegebene Stimme verschleiern.
• Die Zuteilung der PIN, die Wahl und die Verifikation der Wahl sind zeitlich voneinander abgegrenzt.
• Die Verifikation der Stimmenabgabe erfolgt idealerweise mit einem anderen Client als dem Wahlclient.
• Verschiedene Implementierungen möglich: Browser-basiert, eMail-Client, Rich-Client, Shell-Skript...

Ungelöste Probleme

• Was tun, wenn die Anzahl von Token A ungleich der Anzahl von Token B ist?
• Sollte man eine Stimme invalidieren oder ändern können?
  • Pro für invalidieren: Man konnte seine Stimme nicht frei abgeben (Partner hat zugeguckt, Mafia Rechnung nicht bezahlt etc..)
• Integration mit GPG?
• Kompromittierter Berechtigungs-Server + kompromittierter Urnen-Server => Stimmen können eindeutig zugewiesen werden
  • Das Problem ist die PKI beim Berechtigungs-Server der eine Zuordnung zu einer real existierenden Person erlaubt. Evtl. kann man eine Stimmberechtigung erkennen ohne das dieses einer Person zuordbar ist. (Nr. 124663 hat Ja gestimmt ist keine wertvolle Information solange es keine Tabelle 124663>KarstenB gibt)
• Wie ist ein bösgläubiger Wahlbeobachter zu behandeln, der die Feststellung des Ergebnisses torpediert?
  • Dadurch das es beliebig viele Wahlbeobachter geben kann, sollte feststellbar sein das einer bösgläubig ist.

Varianten

• Anstelle von Token A wird der Public Key des Wählers an die Wahlbeobachter weitergeleitet.
  • Die Kontrolle der Wahlberechtigung des Benutzers ist dadurch auch den Wahlbeobachter möglich.
• Anstelle eines zufälligen Byte-Blobs für die Stimme könnte auch Ascii benutzt werden.
  • Nachteil: Die plausible deniability geht verloren, da man bei Nicht-ASCII Dechiffrierung weiß, dass es sich nicht um eine korrekte Stimme handelt.
  • Vorteil: Bessere Kontrolle für den Wähler.