Vorschlag zur Erweiterung des verifizierten, anonymen Online-Votings von Johannes Ponader

Bitte zuerst den Blogartikel von Johannes dazu lesen: [1]

... wie man im Kommentar und bereits im Artikel selbst sieht hat diese wunderbare Idee noch einige Verbesserungsmöglichkeiten.

Bitte nutzt für Kommentare auch zu diesem Erweiterungsvorschlag alle die Kommentarfunktion in Johannes Ponaders Blog, damit wir diese nicht zu gegebener Zeit mühsam im Web zusammensuchen müssen ;-)

Vorschlag zur Erweiterung/Verbesserung des Konzeptes zum verifizierten, anonymen Online-Voting Im Konzept von Johannes Ponader, Dunkelzahn und Lennart Dührsen gibt es noch zwei wesentliche Knackpunkte:

  (1) wie weist man im Falle eines Missbrauchs seines Schlüsselpaares nach, wem das Schlüsselpaar tatsächlich gehört bzw. welche Stimme also die gültige Stimme ist?
  (2) gibt es eine Möglichkeit das Akkreditierungsdilemma eleganter zu lösen? (siehe Kommentar: Problem bei Parteiaustritt)

Um die Probleme besser erläutern zu können, wird im Folgenden zwischen Stimmwilligen und Stimmberechtigten unterschieden. Stimmwillig kann potentiell jeder sein. Jeder Stimmwillige kann einen öffentlichen Schlüssel in die von Johannes beschriebene Datenbank geladen haben. Stimmberechtigt sind hingegen nur jene, die zum Zeitpunkt der Abstimmung wirklich noch Parteimitglieder sind.

Problem (1) lässt sich mit einer Signatur des öffentlichen Schlüssels A(o) lösen, der in die von Johannes beschriebene Datenbank aufgenommen wird. Hierfür wird ein Schlüssel B(p) verwendet. Der private Schlüssel B(p) wird idealerweise auf einem separaten und idealerweise auch "analogen" Medium aufbewahrt (z.B. Papier). Der private Schlüssel B(p) wird in der Regel nur einmal benötigt um, die Signatur von A(o) zu erstellen. Erst wenn es zu einem Missbrauchsfall kommt, kann man anhand des Schlüssels B(p) nachweisen, wer die Signatur eines bestimmten Schlüssels A(o) tatsächlich erstellt hat. Zu entscheiden, welche Stimmabgabe allerdings die gültige ist, ist dadurch noch nicht möglich. Vielleicht hat jemand anderes hierfür noch eine Idee. Im Moment bleibt mir nur auf die Lösung des Problems (2) zu verweisen, die gleichzeitig die Manipulation von Stimmabgaben erschwert, weil sie eine zwei-Wege-Authentifizierung benötigt (Passwort/Einweg-Token+korrekter privater Schlüssel).

Problem (2) entsteht dadurch, dass grundsätzliche Stimmwillige durch öffentliche Schlüssel in der von Johannes beschriebenen Datenbank als stimmberechtigt zum Zeitpunkt des Hochladens des öffentlichen Schlüssels qualifiziert werden. Zu allen anderen Zeitpunkten (insbesondere späteren Zeitpunkten) sagt dieser Schlüssel jedoch nichts über die Stimmberechtigung aus, sondern lediglich dass der Inhaber stimmwillig ist, wenn er diesen zu einem späteren Zeitpunkt wieder verwendet. Um Problem (2) zu lösen muss der öffentliche Schlüssel nicht zwingend aus der von Johannes beschriebenen Datenbank gelöscht werden. Vielmehr muss es neben dieser Datenbank eine zweite Datenbank und eine dritte Datenbank geben. In der einen Datenbank werden Mitgliedsnummer und ein Passwort hinterlegt (im Folgenden kurz MPDB). Wichtig ist, dass unmittelbar nach einem Parteiaustritt/Parteiausschluss/o.ä. die Akkreditierungsverantwortlichen den jeweiligen Mitgliedsnummer-Passwort-Datensatz aus der Datenbank löschen. Man erhält dadurch eine simple Liste mit den Mitgliedsnummern aller Stimmberechtigten, gegen die sich jedes Mitglied mit Hilfe eines Passwortes authentifizieren kann. Die dritte Datenbank ist eine Schlüssel-Tokendatenbank (im Folgenden kurz STDB). Möchte jetzt ein stimmberechtigtes Mitglied an einer Abstimmung X teilnehmen, so authentifiziert er sich gegen die MPDB und erhält einen Einweg-Token (kann nur einmal benutzt werden) vom System, welcher ohne weitere Informationen (Zeitstempel,etc.) außer der Abstimmung zu der er verwendet werden darf in der STDB hinterlegt wird. Unter der Voraussetzung, dass die MPDB stets aktuell ist, werden Stimmwillige, die nicht stimmberechtigt sind automatisch von der Abstimmung ausgeschlossen, weil die Authentifizierung gegen die MPDB für sie fehlschlägt und sie keinen Einweg-Token bekommen können. Das stimmberechtigte Mitglied gibt auf seinem Abstimmzettel jetzt sowohl den Einweg-Token als auch seinen öffentlichen,signierten Schlüssel und seine Wahl für die Abstimmung X an. Durch die Art der Erzeugung des Einweg-Tokens ist sicher gestellt, dass nur Stimmberechtigte an einer Abstimmung teilnehmen dürfen. Durch den öffentlichen, signierten Schlüssel ist sichergestellt, dass im Missbrauchsfall der Daten eines Stimmberechtigten, durch Vorlage des Schlüssels B(p) Manipulation nachgewiesen werden kann. Die Sicherheit des Verfahrens läst sich noch erhöhen, wenn der Einweg-Token auf einem zweiten/separaten Weg (z.B. Handy, Postbrief, etc.) zugestellt wird. Einweg-Token sind zeitlich durch das Ende der Abstimmung begrenzt.

Das ganze zusammengefasst in einer Grafik:

Vielleicht hat ja Lennart Lust, die Grafik in das gleiche Format zu übertragen wie die Grafik im Blog-Post?

Ein ethisches Problem, was durch das Verfahren in seiner bisherigen Form noch gelöst wird, ist die Nachvollziehbarkeit aller Abstimmungszettel eines Stimmberechtigten im Missbrauchs/Manipulationsfall, wenn dieser aufgedeckt werden soll. Die vollständige Nachvollziehbarkeit kann durch die zeitliche Begrenzung der Vorratsspeicherung gemindert, aber nicht eliminiert werden. Hat jemand eine Idee, wie man das vielleicht technisch noch besser lösen kann? Im Moment sehe ich nur die Möglichkeit, dass jeder einzelne selbst regelmäßig einen neues Schlüsselpaar A erzeugt und neu signiert, um die Reproduzierbarkeit von individuellen Wahlentscheidungen zeitlich zu begrenzen (ich persönlich würde das etwa, alle zwei bis drei Monate machen oder bei grundlegenden Änderungen meines Meinungsbildes).

Bitte nutzt für Kommentare auch zu diesem Erweiterungsvorschlag alle die Kommentarfunktion in Johannes Ponaders Blog, damit wir diese nicht zu gegebener Zeit mühsam im Web zusammensuchen müssen ;-)

Vielen Dank an Maria (Benutzer:Geirkairam), die mich auf den Blog von Johannes aufmerksam gemacht hat

--Open4elpis 14:46, 17. Jun. 2012 (CEST)