Sonntag, Februar 28, 2010

Liquid Feedback anonymisieren

Liquid Feedback ist ein System, um Politische Anträge zu verfassen, Änderungsanträge einzureichen, Unterstützer für diese Anträge zu sammeln, und über sie abzustimmen.

Die Piratenpartei (Allen voran Landesverband Berlin) testet dieses System momentan.

Da die Piraten elektronischen Wahlen nun skeptisch gegenüber stehen, gibt es natuürlich Probleme mit dem System. Wahlen haben nachvollziehbar zu sein, schön wäre auch, wenn sie anonym sein könnten (Wahlgeheimnis).
Die Korrektheit der Wahlen wird in der FAQ auf der Projektwebsite als wichtiger als die Anonymität bezeichnet (Eine Wahl, die nicht überprüfbar korrekt ist, ist natürlich nicht viel wert); deshalb wird auf die Anonymität verzichtet, da die Funktionen von Liquid Feedback wohl sonst nicht technisch umsetzbar wären.

Projektwebsite: http://liquidfeedback.org

Das sehe ich anders.

Eine überprüfbare anonyme Wahl halte ich für möglich, wobei
1. Überprüfbar bedeutet, daß jeder Wähler die korrekte Zählung aller Stimmen, sowie den korrekten Eingang der eigenen Stimme überprüfen kann
2. Eine Stimme, die ein Delegierter (nach dem Prinzip der liquid democracy) für einen Wähler bereits abgegeben wurde, von diesem wieder eingezogen und durch eine echte eigene Stimme ersetzt werden kann.

Das soll so funktionieren:

Insgesamt sind für das ganze Verfahren 2 Techniken vonnöten:
1. Asymmetrische Verschlüsselung
2. Blind Signatures die zur Verschlüsselung passen

1. Wahltokens

Es gibt einen Wahlserver, der "Wahlzettel" annimmt. Nennen wir ihn "Urne". Ein Wahlzettel besteht aus einer zufälligen Bitsequenz (Wahltoken) und einer Wahl (Wahl heisst hier 'dafür', 'dagegen' oder was die Abstimmung grad hergibt.)

Ist der Wähler im Besitz dieses Tokens, ist die Verbindung Wähler<->Token aber ansonsten geheim, so kann der Wähler den korrekten Eingang seines Wahlzettels prüfen, da nach der Abstimmung einfach alle Stimmen veröffentlicht werden können. Niemand anders kann allerdings Wahlzettel und Person verknüpfen, da niemand sonst die Tokens der anderen kennt.

2. Authentisierung
Um nur zur Wahl zugelassene Menschen (zB nur Piraten) Wahlzettel an der Urne abgeben zu lassen, muß ein geeigneter Authentisierungsmechanismus her.
Folgendes halte ich für praktikabel: Es gibt einen Authentisierungsserver (Auth-Server).
1. Der Wähler generiert sich sein Wahltoken
2. Er meldet sich am Auth-Server an. Dieser prüft die Zulassung zur Wahl, und markiert den Wähler als jemanden, der gewählt hat. (oder nach abschluss des Verfahrens gewählt haben wird)
3. Der Wähler 'blindet' sein Wahltoken (siehe oben: Blind Signatures)
4. Der Wähler schickt sein geblindetes Token an den Auth-Server
5. Der Auth-Server signiert das Token und schickt es dem Wähler zurück.
6. Der Wähler kann das signierte Token entblinden, und mit einem lesbaren, signierten Token an der Wahl teilnehmen.
Die Signatur bietet der Urne die Möglichkeit, zu wissen, daß der Wähler zur Wahl berechtigt ist. Dabei erfährt die Urne nicht die Identität des Wählers, und der Auth-Server wegen der Verblindung das Token nicht. Beide (selbst bei Personalunion) können also nicht (ausser durch zeitliche Abläufe) Wähler und Token zuordnen.

3. Delegierte

Jeder Wähler soll seine Stimme an einen beliebigen anderen Wähler delegieren können. Diese nenne ich Delegenten, jene Delegierte.

Der Auth-Server weiß, wer schon gewählt hat (s.o.) und weiß auch (durch Vorgabe), wer wem seine Stimme delegiert hat bzw. wer berechtigt ist, für wen abzustimmen.

Um das jetzt anonym und funktionierend hinzukriegen, muß ich etwas ausholen:

1. Das Wahltoken-Verfahren läßt (m.E.) nicht zu, daß Stimmen, wenn sie einmal abgegeben sind, in ihrer Wertung verändert werden. Da dies aber nötig ist, bei einer nachträglichen Abgabe einer eigenen Stimme eines Delegenten (Delegent +1, Delegierter -1) muß tatsächlich für jede Stimme ein Wahlzettel abgegeben werden.

2. Der Delegent muß seine Stimme überschreiben können. Das kann er aber nur, wenn 1. die Urne das zuläßt (gut, das tut sie), und wenn er 2. sein Wahltoken kennt.
Desweiteren (und das ist wichtig) muß hier sichergestellt sein, daß es wirklich das Wahltoken der Stimme ist, die der Delegent auch überschreiben darf. (und nicht eine fremde).

Hier also das Verfahren, wie ein Delegierter E fuer einen Delegenten D abstimmt:
1. E meldet sich beim Auth-Server an, und teilt mit, er möchte für D abstimmen. Der Auth-Server ist in der Lage zu entscheiden, ob das ok ist (Hat D schon abgestimmt, oder ist E gar nicht von D delegiert, dann gehts zB nicht.)
2. E generiert eine grosse Zahl (>1 und zB n) sogenannte pre-Tokens, die ich auch Lösch-Tokens nenne.
Für jedes dieser Pre-Tokens generiert E eine verschlüsselte Version, die nur D lesen kann (Verschlüsselung per Public-Key von D), eine Version die nicht verschlüsselt ist, aber gehasht wird (zB SHA1) und dann geblindet wird, und eine Version die auch nicht gehasht, sondern nur geblindet wird.
3. Alle diese Tripel werden an den Auth-Server geschickt.
4. Der Auth-Server sucht sich ein Tripel zufällig aus, daß er _nicht_ lesen können will, und teilt dies E mit.
5. E schickt alle Verblindungsfaktoren an den Auth-Server, mit Ausnahme des ausgewählten.
6. Der Auth-Server kann nun die verblindeten Teile entblinden, verhashen, mit dem Public-Key von E verschlüsseln, und prüfen, ob die Tripel korrekt gebildet sind. Wenn ja, vertrauen wir darauf, daß auch das ausgewählte und für den Auth-Server eben nicht prüfbare (da nicht lesbare) Tripel korrekt ist.
7. Der Auth-Server sendet die verschlüsselte Version des Pre-Tokens an D. Damit ist D in der Lage, seine Stimme später zu überschreiben, da er das Pre-Token kennt. (Wie das geht, folgt gleich).

8. Der Auth-Server signiert die geblindete, gehashte Version des Pre-Tokens und sendet sie an E zurück.
9. Er führt eine Wahl durch wie in "1. Wahltokens" ausgeführt, wobei das gehashte Pre-Token das Wahltoken darstellt.

4. Überschreiben von Stimmen

D hat seine Stimme delegiert, E hat für ihn/sie gewählt, und nun möchte D aber doch seine eigene Stimme wahrnehmen. (wenn D selbst Delegierter ist, kann das Verfahren leicht aufgebohrt werden).

Dafür muß D nun 2 Dinge tun. Überschreiben der Wahl ist nicht möglich, da damit die Anonymität nach oben flöten ginge. D.h. Das Wahltoken der neu abgegeben Stimme muß ein neues sein. D.h. zerteilen wir das Überschreiben in Löschen und neu wählen. Neu Wählen muß nicht erläutert werden, aber wie kann gelöscht werden?

Die Urne kann natürlich nicht einfach Stimmen löschen, wenn man ihr (unauthentisiert, denn die Urne nimmt keine Authentisierung vor, dafür ist der Auth-Server da) befiehlt, einen Wahlzettel, gewählt durch das Wahltoken, zu löschen. Dann könnte jeder mißliebige Stimmen einfach löschen.

Aber: Wir haben ja das Pre-Token. Wie oben schon erwähnt, heisst es auch Lösch-Token. Man gibt es der Urne, und die Urne verhasht es selbst zum zu löschenden Wahltoken. Damit ist sichergestellt, daß man auf jeden Fall Zugang zum Pre-Token haben muß, etwas, daß man nicht durch Lesen der veröffentlichten Abstimmung gewinnen kann.

Es wäre schön, wenn sowas implementiert werden könnte, vielleicht sogar direkt in Liquid Feedback eingebaut werden könnte. Mal schaun.
Desweiteren wärs natürlich total toll, wenn ihr Nerds mich alle ausfragt, weil ich mich unklar ausgedrückt habe, und mir erklärt, warum mein Verfahren nicht funktioniert.

Ahoi

Kommentare:

TheConstructor hat gesagt…

Die offensichtlichste Schwachstelle ist Punkt 2.

Es kann nur der authentifizierte Mensch prüfen, ob alles korrekt abgelaufen ist.

Eine Lösung wäre der Wahlzwang und eine reine Prüfung der Zahl der abgegebenen Stimmen.

In allen anderen Fällen kann bis zur Anzahl der Nichtwähler ein (automatisiertes) Strohmann-Wahlverfahren durchgeführt werden, wenn man den Authentifizierungsserver manipulieren kann.

Eine Frage zu den "Blind Signatures": Wenn ich eine ausgegebene Signatur speichere kann ich doch nachher feststellen, wer wie gewählt hat, oder nicht?

Gespeicherte Blind Signatures sind doch nur so lange anonym, wie keiner die zugehörige Ungeblindete Nachricht signiert hat, oder die Ungeblindete Nachricht gegen die Blind Signature erfolgreich geprüft hat, oder sehe ich das falsch?

Delegation prüfbar zu machen heißt prinzipiell immer, dass Delegenten und Deligierte sich gegenseitig prüfen können müssen. Also insbesondere wissen, wie der andere gewählt hat.
Das bedeutet aber, dass diese Personen weniger anonym sind als alle anderen (und es zu Datenlecks in deren Kommunikation kommen kann).

Gerade bei Delegationen ist es vermutlich wünschenswert das genaue Ergebnis mit Zuordnung der Tokens bis zum Ende der Wahlperiode geheim zu halten, damit nicht auf Grund der Gruppengrößen z.B. Rückschlüsse auf bestimmte Personen möglich sind.

Alles in allem sehe ich bis heute nur Möglichkeiten anonyme Meinungsbilder (mit evtl. doppelten Stimmabgaben) und öffentliche Wahlen elektronisch durch zu führen.

Jedes bis jetzt erdachtes Verfahren hat mindestens eine Schwachstelle. Eine einzelne Komponente deren Kontrolle eine Manipulation der Wahl zulässt.

In dem Sinne scheint das höchste der Gefühle eine automatisierte Tendenz zu sein, die öffentlich & händisch nach gezählt wird (nicht werden kann, sondern wirklich wird).

Sicher kann in einem internen Rahmen z.B. unter Veröffentlichung der Administratorzugänge Manipulation verhindert werden. Das Problem ist, dass ein geheimes Wahlverfahren idealerweise jedem Misstrauen gewachsen seien muss und nicht darauf beruht, dass "die Verantwortlichen schon das richtige machen".

MoKrates hat gesagt…

Es koennen nur Menschen, die eine Stimme abgegeben haben, pruefen, ob ihre Stimme korrekt gewertet wurde. Desweiteren kann man die Statistik ueber alle Stimmen pruefen (wirklich 60% Zustimmung?)

Sollte der Authentisierungsserver aufgemacht werden, so kann der Angreifer beliebig viele Stimmen abgeben, weil er sich seine Stimmen selber signieren kann. Damit waer das System kaput, ja. Das gleiche ginge aber auch beim oeffnen der Urne, weil man dort einfach weitere Wahlzettel (Token und Wahl) hinterlegen koennte.

Was die Blind Signatures angeht: Nein, ich kann, wenn ich die Signatur speichere, nicht lesen, wer wie abgestimmt hat. Nur, wie ich selbst abgestimmt habe.

Das Blinden wird vorgenommen, damit der Auth-Server nicht weiss, was er unterschreibt (Da das eh zufaellige Bitstrings sind, ist es aber auch egal, und der Signaturschluessel darf _nur_ fuer diese Wahl verwendet werden). Nach dem sigfniert worden ist, entfernt man die Blindung wieder, und hat ein ungeblindetes, RSA-signiertes Token. Das kann man dann auch mit dem oeffentlichen Schluessel lesen (Und schauen, dass es nicht weiter manipuliert wurde). Und genau damit waehlt man.

Die Anonymitaet erwaechst daraus, dass keine Verbindung zwischen Wahltoken und Waehlender Person gezogen werden kann. Die Wahltokens werden nach Abschluss der Wahl sowieso alle mit den entsprechenden Stimmen veroeffentlicht.

Das mit der Delegation ist in der Tat ein echtes Problem. Ich kann meine Stimme verschenken, mit dem Zweck, die Stimme eines anderen zu lernen. Das ist nicht gut.

Abgesehen davon, dass auf der Piratenliste mir grad klargemacht wird, dass Anonymitaet bei solchen Wahlverfahren vielleicht eh nicht so gut ist, und die Komplexitaet wegen schwieriger Anwendbarkeit ein Showstopper sein koennte.

MoKrates hat gesagt…

Nur die Urne aufmachen reicht im uebrigens tatsaechlich nicht. Einfach Wahlzettel hinzufuegen geht nicht, weil das dann nicht mehr mit der Zahl der angeblich abgegebenen Stimmzettel, die der Auth-Server ja auch kennt, uebereinstimmt.
Laesst man Wahlzettel weg, faellt das dem betroffenen Waehler selbst auf.