Ein paar Gedanken zur SMV – ohne LQFB

By | 8. Januar 2013

Nachdem wir während unseren Aufenthalts in #bongs in der Küche der MV WG bereits zu diesem Thema ein kleines Brainstorming betrieben haben, finde ich heute doch mal die Zeit und Lust dien Entstandene Idee zur SMV niederzuschreiben.

Ich persönlich bin der Ansicht, Liquid Feedback geht gar nicht für eine SMV. Das hat mehrere Gründe:

  • Keine geeignete Dikussionsplattform
  • Delegierten-Problem (alleine wegen der Akzeptanz)
  • Wahlcomputer-Problem
  • Webapplikation

Gerade der letzte Punkt ist für mich äußerst wichtig. Web-Applikationen sind anfällig gegen diverse „Attacken“.  Sozial Engineering und andere Methoden ( Fake-Seiten, XSS, ..),  könnten die Sicherheit der Applikation aushebeln, und Angreifern ermöglichen die Kontrolle über den Maschinen-Raum der Piraten zu übernehmen. Daher fallen für mich auch andere Anwendungen die über einen Browser bedient werden aus.

Viel besser fände ich Server-Client Modell mit eigener Software. Die Sicherheit müsste über kryptographischen Mittel gewährleistet werden, und die Bedienung möglichst einfach. Die Umsetzung sollte möglichst einfach sein. Am besten man nimmt bereits vorhandene Technologien und erfindet das Rad nicht neu.

Entstanden ist in besagter Küche daraus folgendes Konzept:

Zur Diskussion von Anträgen werden die bewährten Mittel genutzt: Mailinglisten. Dort kann ein offener Diskurs geführt und Änderungsvorschläge eingebracht werden. Nach einem fest definierten Zeitraum (am besten in der GO der SMV) wird der Wahlleiter die Diskussion schließen und den Abstimmungs-Prozess starten.

Als digitales Wahllokal wird ein Mailserver eingesetzt. Auf diesem werden zunächst ein Satz Zufalls-Adressen generiert. Für jedes Mitglied eine. Außerdem wird zu jeder Adresse ein PGP-Schlüssel erzeugt und mit dem Key des Wahlleiters unterschrieben.

Diese Adressen und Schlüssel werden in die Konten der Stimmberechtigten Mitglieder übertragen.

Über den Client (erhältlich für alle Betriebssysteme, und Quelloffen 😉 ) kann dann jedes Mitglied an der Abstimmung teilnehmen. Der Client kommuniziert natürlich mit Hilfe von SSL mit dem zentralen System, welches die Metainformationen zur Abstimmung und die Zugangsdaten bereit hält. Dazu wählt es seine Antwort(en) in der Oberfläche.  Das Programm erzeugt daraufhin eine signierte E-Mail. Diese kann noch einmal kontrolliert und (inkl. Signatur-Block) weg-gesichert werden, so es denn der Abstimmende wünscht.  Ist alles O.K., wird die E-Mail mit dem öffentlichen Key des Wahlleiters verschlüsselt und abgeschickt. Durch diesen Vorgang wird unmittelbar die Zuordnung der Zufalls-Adresse und des Benutzer-Kontos gelöscht, da diese nicht länger benötigt wird.

Nach Ende der Abstimmungsfrist können zunächst durch ein Programm die E-Mails entschlüsselt und verarbeitet werden. Sollte ein GO-Antrag auf Auszählung erfolgen, ist es auch für den Wahlleiter möglich, diese vorzunehmen.

  • Auf Grund der digitalen Signaturen kann verifiziert werden ob die einzelnen Stimmen korrekt sind.
  • Durch die digitale Unterschrift der Wahlleitung an den Zertifikaten ist sichergestellt, das der Absender Wahlberechtigt war. D
  • Durch die Zufälligen Adressen lassen sich zum keine Rückschlüsse auf den Absender zu.

 

Das ist bisher nur ein grobes Konzept, ausbaufähig und braucht noch etwas Feinschliff, aber ich denke, dass dies durchaus eine Alternative zu LQFB & Co. wäre.

Was meint ihr dazu?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kommentarlinks könnten nofollow frei sein.