Trivial-Angriff gegen Bingo Voting
Das wird immer besser. Die Autoren von Bingo-Voting behaupten, die Korrektheit der Wahl beweisen zu können auch wenn die Wahlmaschine manipuliert ist, weil jede Manipulation entdeckt würde und nachweisbar sei. Ein Trivial-Angriff:
Eigentlich hatte ich in der Analyse vom Stand Sonntag den Angriff betrachtet, daß ein Wähler den (nach Protokollspezifikation nicht fälschungssicheren) Wahlquittungszettel fälscht und einfach behauptet, die Wahl wäre manipuliert.
Dabei hatte ich auch die sich zunächst aufdrängende Erweiterung einer digitalen Signatur unter den Quittungen betrachtet und gezeigt, warum dies keine gute Idee wäre.
Nun hat mir jemand in einem Kommentar den Link auf den Quelltext gegeben, und ich habe ihn mal überflogen (ziemlicher Fall von obfuscated Spaghetti übrigens). Wenn ich die Datei Wahltag/BallotToTxt.java richtig verstehe, drucken sie auf die Quittung noch eine Signatur.
(Ich habe schon 10 Jahre kein Java mehr gemacht und bin nicht auf dem Stand der aktuellen Laufzeitbibliotheken, aber das könnte wohl eine X.509-Signatur mit Zeitstempel sein, was dann sowieso das Wahlgeheimnis hinrichtet, ich weiß nur noch nicht, ob sie die nur drucken oder auch speichern…)
Also treibe ich folgenden Angriff:
Die Aussage ist ja, daß auch bei kompromittierter Maschine Manipulationen erkannt werden. Also darf ich die Maschine kompromittieren und ändere den Code wie folgt:
Wenn der Wähler wählt, drucke ich zwar eine Wahlquittung mit dem, was er gewählt hat, in die Datenbank schreibe ich aber etwas anderes, nämlich das, was mir gefällt. Die Signatur errechne ich für meine, d.h. die angreiferischen Daten und drucke sie trotzdem auf die Quittung mit drauf.
Weil der Wähler ganz sicher keine X.509-Signaturen im Kopf prüft, merkt er das nicht.
Nachher kommt bei der Wahl etwas anderes heraus, als der Wähler erwartet. Seine Quittungszahlen tauchen nicht in der Liste auf. Der Wähler will zum Beweis seine Quittung vorlegen, aber ach: Die Signatur stimmt nicht. Sie stimmt aber für die von der kompromittierten Maschine veröffentlichten Zahlen. Kurzerhand beschuldige ich den Wähler der Urkundenfälschung und lasse ihn verhaften.
Und weil die Maschine dabei ja weiß, was der Wähler wählen wollte, beschränke ich das auf die Wähler irgendeiner radikalen Partei und dann glaubt mir auch jeder, daß sie sich abgesprochen haben und alle die Zettel gefälscht haben.
Hähä.
2 Kommentare (RSS-Feed)
Mir fällt da noch einer ein:
Sie sagen, dass auch bei kompromittierter Maschine die Korrektheit der Wahl nachweisbare wäre.
Angenommen, die Wahl verläuft korrekt, aber ich schnappe mir den Signaturschlüssel. Dann kann ich 300 falsche Quittungen erzeugen und behaupten, die Wahl ist ungültig, falls mir das Ergebnis nicht paßt.
Irgend ein Verbrecher hat die Klasse KonstantCollection aus dem Archiv genommen – die darf man sich neu stricken, um das Projekt überhaupt compilieren zu können.
Zum Glück gibt es Werkzeuge wie Eclipse, die unnötige Imports und ungenutzte Attribute aufspüren. Gerade die Wahltag/BallotToTxt.java enthält zu 2/3 ungenutzte imports.
Das heißt nicht viel – ein rascher Überblick verrät nur, daß wohl verschiedene Personen mit unterschiedlichen Einrückstilen und Sorgfaltsideen am Werk waren, und vielleicht fehlte vor allem die Zeit, es fertig zu stellen.
Dokumentation war für das Projekt auch Glückssache.