Sichere History

[lordnaikon]

@lordnaikon

Deine Kritik bleibt unberechtigt. Wenn bei der *Erstellung* der Historie nicht ein Secret einfliesst, dass vom Server bezogen wurde (dein initialer Hash ist nichts anderes als genau dass), dann ist saemtliches asymetrisches verschluesseln spaeter voellig irrelevant - denn es kann nachvollzogen werden.

Stimmt, danke! Deine Analogie meines initialen Hashes mit deinem Secret ist gut und hat mir beim Verständnis geholfen. Bei Kenntnis des initialen Hashes und des Schlüssels kann ich eine neue Historie bauen, gleiches gilt für die Kenntnis des Secrets.

Ich begreife nicht, warum du ein Secret im Speicher oder Programmcode weniger sicher bewertest als einen Public key.... Das secret wird ja nicht zur *entschluesselung* verwandt, sondern ist einfach nur Bestandteil des hashes, damit man den nicht einfach nur in Kenntnis des eigentlichen Algorithmus nachbauen kann.

Das ist wohl das klammern an die eigenen Idee, was mich, unbewusst, dazu verleitet meiner Lösung mehr zu vertrauen, Ich versuche mich zu bessern. Aber man vertraut sicherlich einer eigenen Überlegung mehr, da man sie genauer überlegt hat als eine Fremde - sie mitunter nicht genau versteht und diese eigene Ungewissheit als Unzulänglichkeit der fremden Idee bewertet.

Ich wage einen weiteren Klammerversuch. Dein Secret muss aber über die gesamte Lebensdauer der Anwendung bekannt,also im Speicher, sein. Mein initialer Hash nur am Anfang, danach darf und soll er vergessen werden. Ich halte zwar noch den aktuellen Hash vor, das ermöglicht aber nur ein Anhängen an die Historie, nicht aber ein verändern der schon vorhandenen.

[jerch]

@jerch: "Richtig - aber das ist doch immer möglich" ich meine nein. Bei meinem Ansatz, so glaube ich zu wissen ( ) ist es nicht möglich eine Historie, unter der Prämisse der validen Erstellung, im nachhinein zu verändern.

Da muss ich Dir widersprechen. Grundproblem ist doch, dass der Client alles Wissen darum hat, eine (vermeintlich) valide Historie zu erstellen. Da ist es egal, wie Du verfährst, ob Hashing oder public/private Keys etc. Ohne Prüfinstanz (Server) kann der Client zwischendrin immer die bisher aufgelaufene Historie verwerfen und eine "falsche" berechnen und später propagieren.

Grundsätzlich:
Ich sehe 2 Hauptangriffsvektoren für Dein Szenario, welches reichlich im Dunkeln bleibt
1.) Die Historie ist vom Client manipuliert, d.h. sie enthält andere Aktionen als in Wahrheit ausgeführt. Darum drehen wir uns gerade.
2.) AktionXY sieht für die Historyerstellung wie AktionXY aus, ist aber was ganz anderes (untergeschobener Schadcode)
Beide Probleme lassen sich reduzieren auf - die Prüfinstanz sieht AktionXY und gibt sie als valide im aktuellen Kontext aus, der Endzustand entspricht aber nicht der Transition aus Anfangszustand ---> AktionXY ---> Endzustand.
Problem 1 ist ohne ständiges Eingreifen der Prüfinstanz nicht lösbar (alle Aktionen sind quasi kritisch), Problem 2 ist viel schwerwiegender, da dies nur mit Auslagern der Programmlogik lösbar ist.

Ich skizziere mal kurz ein mögliches Szenario, um beiden Problemen aus dem Weg zu gehen:
- Zustandsautomat auf Server, dieser kennt x-beliebige Zustände mit verschiedenen Transitionen
- Server-API propagiert Zustand und mögliche Transitionen/Aktionen
- Client triggert AktionXY
- Server prüft AktionXY im Kontext des aktuellen Zustandes und führt diese auf dem Server aus
- Rückmeldung an den Client

Diese Model erlaubt auch einen kurzzeitigen Ausfalls des Servers, indem man dem Client die Möglichkeit gibt, den Automaten lokal nachzuvollziehen und die Aktionen in einer History ablegt. Mit dem nächsten Serverkontakt sind der lokale und der serverseitige Automat out of sync, der Server kann die Schritte dann aber einfach nachholen (und ggf. verwerfen, falls ungültig).

[lordnaikon]

...Grundproblem ist doch, dass der Client alles Wissen darum hat, eine (vermeintlich) valide Historie zu erstellen. Da ist es egal, wie Du verfährst, ob Hashing oder public/private Keys etc. Ohne Prüfinstanz (Server) kann der Client zwischendrin immer die bisher aufgelaufene Historie verwerfen und eine "falsche" berechnen und später propagieren.

Das Erstellen bzw. das initiale Anlegen einer Historie ist nur in Verbindung mit dem Servers möglich, durch den initialen Hash. Bricht die Verbindung ab und wurde der initiale Hash nicht irgendwie abgefangen/gespeichert, kann ohne diesen keine Valide Historie mehr angelegt werden. (sollte man eine Historie überhaupt ein weiteres mal anlegen können, bzw soll der Server den Hash ein zweites mal senden dürfen ... ich denke nein)

Grundsätzlich:
Ich sehe 2 Hauptangriffsvektoren für Dein Szenario, welches reichlich im Dunkeln bleibt

Ist es von nutzen das Szenario näher zu beschreiben?

Diese Model erlaubt auch einen kurzzeitigen Ausfalls des Servers, indem man dem Client die Möglichkeit gibt, den Automaten lokal nachzuvollziehen und die Aktionen in einer History ablegt. Mit dem nächsten Serverkontakt sind der lokale und der serverseitige Automat out of sync, der Server kann die Schritte dann aber einfach nachholen (und ggf. verwerfen, falls ungültig).

Danke! An eine Art Zustandsautomaten habe ich noch gar nicht gedacht, in dem ich dann die Transitionen überprüfen kann. Damit kann man dann nachprüfen ob die Schritte an sich möglich wären, aber nicht ob sie wirklich so waren. Aber das Problem hat man ja sowieso, sollte das Programm manipuliert sein.

In Meinem Szenario, so würde ich es mir wünschen, sollte es nach der FireAndForget Methode laufen. Ein Client wird initialisiert und dann darf die Verbindung abbrechen, die Daten hohle ich mir später. Ich bin mir der Manipulationsmöglichkeit des Programms während der Benutzung und Erstellung der Historie bewusst. Ich muss leider erst einmal davon ausgehen, das es für diese Zeit ca. 3h super sicher und unknackbar ist. Die Historie ist zu dieser Zeit gültig und richtig. Danach soll es nicht mehr möglich sein die Historie zu verändern auch wenn ich nun in der Lage bin die Anwendung zu manipulieren, Schlüssel, Hashfunktionen usw zu extrahieren.

Ich kann mir gut vorstellen, dass ich hier bei den meisten wirke wie ein stures Kind, dass einfach nicht hören will, und sich für jede Unzulänglichkeit was neues einfallen lässt, um seine Welt nicht zu zerstören. ich weiß nicht wie ich das ändern könnte, ich kann mich hingegen nur sehr bedanken, für die ganzen Denkanstöße, die mir diese Diskussion bisher geliefert hat.

[jerch]

Das Erstellen bzw. das initiale Anlegen einer Historie ist nur in Verbindung mit dem Servers möglich, durch den initialen Hash. Bricht die Verbindung ab und wurde der initiale Hash nicht irgendwie abgefangen/gespeichert, kann ohne diesen keine Valide Historie mehr angelegt werden. (sollte man eine Historie überhaupt ein weiteres mal anlegen können, bzw soll der Server den Hash ein zweites mal senden dürfen ... ich denke nein)

Und wie willst Du verhindern, dass der intiale Hash abgefangen wird? Der Client ist nicht sicher, und Du kannst ihn nicht zu etwas zwingen (z.B. den initialen Hash ganz schnell zu vergessen).
Wenn es Dir allerdings nur um das 3h Fenster geht, hängt es eher vom Glück ab, dass kein Hacker Deinen Client innerhalb der 3h erreicht.

Ist es von nutzen das Szenario näher zu beschreiben?

Ist es, ich kann mir beim besten Willen kein Szenario vorstellen, wo die Sicherheit dermaßen wichtig ist für nur einmal 3h

Danke! An eine Art Zustandsautomaten habe ich noch gar nicht gedacht, in dem ich dann die Transitionen überprüfen kann. Damit kann man dann nachprüfen ob die Schritte an sich möglich wären, aber nicht ob sie wirklich so waren.

Ob sie wirklich so waren, ist unerheblich, da der Server den Ton angibt (und der Client ein Rollback auf den gültigen Serverzustand machen kann).
Ich geb Dir mal ein Bsp. dazu:
Ein Spieleclient ist manipuliert und Du kannst in eine Wand reinlaufen. Der Server kriegt die Aktion LaufeZu(x,y), wobei er merkt, dass das ungültig ist, da die Bewegung nach x,y eine Wand schneidet. Der serverseitige Automat vollführt die Bewegung einfach nicht (oder bleibt am Schnittpunkt stehen wotever) während der Automat des Clients "in" der Wand steht. Für die Interaktion mit anderen Spieler ist es nun völlig unerheblich, ob der Clientautomat den Fehler korrgiert oder nicht, da diese nur die serverseitige Aktion "sehen".

[lordnaikon]

Und wie willst Du verhindern, dass der intiale Hash abgefangen wird? Der Client ist nicht sicher, und Du kannst ihn nicht zu etwas zwingen (z.B. den initialen Hash ganz schnell zu vergessen).
Wenn es Dir allerdings nur um das 3h Fenster geht, hängt es eher vom Glück ab, dass kein Hacker Deinen Client innerhalb der 3h erreicht.

Im Moment gibt es keine Methode um das Abfangen zu verhindern (Bis auf eine sichere Verbindung). Und genau darum geht es, ich bin einfach mal so arogant, zu behaupten, dass mein Programm diese 3h nicht erfolgreich angegriffen werden kann. Nach dieser Zeit ist auch der initiale Hash zu vergessen. (Warum genau sollte ich ihn nicht dazu zwingen können?)

Ist es, ich kann mir beim besten Willen kein Szenario vorstellen, wo die Sicherheit dermaßen wichtig ist für nur einmal 3h

Es geht um ein digitales Voting, wobei noch nicht klar ist, auf welcher Plattform es stattfindet. Wahrscheinlich ist es aber so, dass jeder Wahlberechtigte ein "Wahlgerät" zur Verfügung hat, und das für ca 3h. Nach einer initialen Anmeldung soll es möglich sein, sollte der Server ausfallen, die "Wahlgeräte" einzusammeln und auszuwerten. Für diesen Fall soll die Historie gut sein. Zum einen soll sie von den Wählern selber nicht nach der Wahl manipuliert werden können, genauso wenig nach dem einsammeln durch einen Dritten, der sich der eingesammelten Daten bemächtigt, sowie zum Zwecke der sicheren Archivierung.

Ob sie wirklich so waren, ist unerheblich, da der Server den Ton angibt (und der Client ein Rollback auf den gültigen Serverzustand machen kann).

Richtig, der Server kann aber nicht beurteilen, ob ich A angekreuzt habe aber B übersandt wurde. Er kann nur Testen ob es überhaubt die Möglichkeit gibt B anzukreuzen. Um das auf den Gamingserver zu übertragen der Server kann nicht prüfen wenn ich nach links laufe, der Client aber nach rechts laufen überträgt.

[BlackJack]

@lordnaikon: Ich würde mal sagen: Vergiss es. Bei digitalem Wählen kann man Manipulationen nicht sicher erkennen. Darum ist das ja auch so eine blöde Idee.

Wie willst Du denn den Client (nicht mehr Deinen, sondern den manipulierten!) dazu zwingen den initialen Hash zu vergessen?

Geh mal davon aus, dass der in einer virtuellen Umgebung läuft, bei der alles inklusive der Kommunikation mit dem Server aufgezeichnet wird, und dass man die Aufzeichnung wieder „abspielen” und ab einem beliebigen Zeitpunkt wieder auf Normalbetrieb umstellen kann. Was willst Du gegen dieses Szenario unternehmen?

[jerch]

@lordnaikon:
Eine elektronische Wahlmaschine - und auch noch programmierbar
Für sowas brauchst Du eine Sicherheitskette von Authentifizierung und Tastendruck, über Speicherung im Client, Übertragung zum Server und den Server samt Auswertung selbst. Das ist mit einer reinen Softwarelösung keinesfalls machbar, und die Hardwarelösungen sind ja schon vor Jahren in der Diskussion um die Wahlmaschinen als nicht manipulationssicher entlarvt worden und aus gutem Grund in Deutschland derzeit verboten.

Nun hat Dein Votingsystem wahrscheinlich nicht die Tragweite/juristische Konsequenz einer Bundestagswahl und genügt daher vllt. niedrigeren Sicherheitsstandards, allerdings ist doch ein Votingsystem, dass nicht ein Mindestmaß an Sicherheit bietet, keinen Pfifferling wert. Und da sehe ich große Probleme allein auf Clientseite, da dieser programmierbar und wahrscheinlich mit einem handelsüblichen OS versehen ist und nicht einmal die Funktionsweise des Eingabegerätes (also der Tastendruck) sichergestellt ist bzw. durch Viren und Rootkits im Vorfeld sehr einfach manipuliert werden kann.

Sollte das alles keine Rolle spielen (weil die Wahl zu unbedeutend ist), wirds einfach - dann kannst Du die Wahl über eine Webseite abfeuern, wo sich der potentielle Wähler vorher ausreichend authentifizieren muss und die Kommunikationswege gesichert sind. Die Daten werden nur serverseitig gespeichert, das spart die Kopfschmerzen über eine dezentrale, unsichere Datenhaltung (vorausgesetzt das Serverpersonal ist vertrauenswürdig und der Server selbst entsprechend gesichert).

[lordnaikon]

@BlackJack,jerch: Ich hatte wohl unterbewusst gute Gründe, den Einsatzzweck, das Szenario im dunklen zu lassen. Ich weiß, was das Thema Wahlcomputer in informierten Kreisen auslöst, was für Flashbacks an vergangenen Offenlegungen z.B. des CCC's das hervorbringt. Aber so ist das nun mal :K gewählt wird, komme was wolle. Die e-Wahl findet aber eher als Test, parallel zur Papierwahl statt. Es soll auch einfach mal getestet werden, ob damit überhaupt eine Arbeitsersparnis einhergeht. Eine Arbeitsersparnis/Verlagerung weg von der Auswertung hin zur Vorbereitung. Die Ergebnisverkündung ist bis jetzt immer auf den nächsten Tag angesetzt. Da müssen die Auswerter meist die ganze Nacht Wahlzettel abtippen. Diese Arbeitsleistung soll auf die Entwicklungszeit der Wahlmaschine umgesetzt werden, so das nach der Wahl elektronisch ausgewertet werden kann. Uns sind Scansysteme und der gleichen bekannt, sollen für diesen Test aber nicht eingesetzt werden.

@BlackJack: Das Problem Software und Hardware manipulationssicher zu halten ist bekannt. Wir versuchen auch gerade solche Systeme wie das BingoVoting(falls jemand sowas kennt) zu evaluieren. Ich weiß selber, dass das ne blöde Idee ist, aber so ist die Idee nun mal, demokratisch entschieden :K

Wie willst Du denn den Client (nicht mehr Deinen, sondern den manipulierten!) dazu zwingen den initialen Hash zu vergessen?

Gar nicht, wie gesagt meine Annahme geht arroganterweise davon aus, dass der Client bis dahin ungebrochen/valide ist.

Geh mal davon aus, dass der in einer virtuellen Umgebung läuft,

Danke, für den Angriffsvektor, bis jetzt gibt es noch keine Überlegungen für eine Verteidigungsstrategie in solch einem Fall. Ideen, deinerseits?

@jerch:

Nun hat Dein Votingsystem wahrscheinlich nicht die Tragweite/juristische Konsequenz einer Bundestagswahl...allerdings ist doch ein Votingsystem, dass nicht ein Mindestmaß an Sicherheit bietet, keinen Pfifferling wert.

Genau, nicht ganz Bundestagswahl ... . Und wenn es nach mir ginge, ist auch das jetzige Papierwahlprotokoll nicht so, dass man es sicher nennen könnte. Offene Türen, Auszählung im IT-Büro .. ich könnte endlos so weiter machen. Da sehe ich die Idee des e-Votings schon als Verbesserung, weil man jetzt zum manipulieren schon IT-Kenntnisse benötigt. Jetzt muss man einfach nur in das völlig überfüllte, laute, stickige Büro gehen sich nen Wahlzettel schnappen(die offen rumliegen) und das Kreuzchen neu setzen.

dann kannst Du die Wahl über eine Webseite abfeuern

Das wird leider nicht möglich sein, daran wurde gedacht, wird sich aber wohl aus logistischen Gründen nicht umsetzen lassen.

@all:
Alles in allem sieht es so aus, dass diese Testwahl zu Evaluation stattfindet. Jetzt geht es darum, mit den vorhandenen Möglichkeiten das in irgendeiner Art und Weise einigermaßen sicher zu machen. Ein wichtiger Punkt ist halt, dass man ein (so weit es eben geht) sicheres Prüfprotokoll hat, ein äquivalent zu einem Wahlzettel. Und darum dreht sich meine eingangs gestellte Frage. Dabei ist natürlich Voraussetzung, dass der Wahlzettel, das Protokoll, die Historie, "richtig" also im Sinne von nicht manipuliert, den Willen des Wählers wiederspiegelnd, ausgefüllt/erstellt wurde. Und da muss ich jetzt einfach mal davon ausgehen, dass der Client manipulationsfrei ist. So wie ich davon ausgehe, dass die Wahlzettel nicht aus Zauberpapier oder Stifte mit Zaubertinte befüllt sind - der Wähler ohne vorgehaltener Waffe abgestimmt hat.

[BlackJack]

@lordnaikon: Es sollte bei Wahlen nicht um Arbeitsersparnis gehen, sondern um eine nachprüfbare, halbwegs manipulationssichere Wahl. Wenn es um Arbeitsersparnis geht, dann lässt man die Wahl einfach weg und kungelt oder würfelt ein Ergebnis aus.

Ich weiss, dass ich das jetzt ziemlich einfach sagen kann, weil ich nicht in der Situation bin, aber ich würde mich schlicht weigern so etwas zu entwickeln. Wenn von so einer Wahl tatsächlich etwas wichtiges abhängt, dann möchte ich nicht, dass sie nicht nachprüfbar manipulierbar ist. Und IMHO sollte man Leute auch gar nicht erst daran gewöhnen, dass das so schön einfach geht, und mit „Naja, das ist schon sicher genug und es spart Arbeit” argumentieren. Das ist IMHO Augenwischerei.

Das die jetzige Papierwahl Schwachstellen hat, macht e-Voting nicht besser. Gegen die Schwachstellen bei der Papierwahl kann man nämlich etwas machen. Gegen die inhärenten Probleme beim e-Voting nicht.

Das jemand bei offen herumliegenden Wahlzetteln nachträglich unbemerkt Kreuzchen ändert, kann man verhindern, in dem man halt darauf achtet. Das die Tür offen ist, sehe ich als Vorteil gegenüber e-Voting, denn bei der offenen Tür kann jeder zuschauen und nachvollziehen wie das Ergebnis zustande gekommen ist. Beim e-Voting braucht man IT-Kenntnisse um zu manipulieren, aber auch um Schwachstellen überhaupt zu erkennen, oder um zu prüfen ob am Gerät manipuliert wurde. Das Ergebnis kann man *gar nicht* prüfen! Du kannst Bits nicht ansehen ob sie manipuliert wurden. „Zauberpapier”, radiert und neu gesetzt, usw. kann man dagegen noch hinterher überprüfen. Bei einer rein elektronischen Wahl, kann der Wähler nie sicher sein, dass seine Stimme auch so gezählt wird, wie er sie abgegeben hat. Und damit disqualifiziert sich das Verfahren für jede Wahl bei der es tatsächlich auf etwas ankommt. Und bei unwichtigen Wahlen kann man sich gleich das ganze Sicherheits-„snake oil” sparen.

[lordnaikon]

Hatte ich erwähnt, das es gar nicht um Wahlen geht? Ähh .... Äahh .. Aprilscherz, Aprilscherz! Es geht darum Schachzüge bei einem Turnier aufzuzeichnen ... Nein, ernsthaft:

Ich wollte das eigentlich nicht in eine Grundsatzdiskussion über e-Voting Enden lassen. Ich weiß selber, dass ich bei Bekanntgabe dieses Themas und bei Aufstellung für die Pro-Seite bei einer Diskussion in einem Debattierklub, sofort das Handtuch werfen würde. Ich bin selber ein großer Gegner davon, bei wichtigen Wahlen.
Wenn ich könnte, dann würde ich mich gerne mit dir, Blackjack und allen anderen hier interessierten, bei einer Tasse Tee hinsetzen und über die genauen Hintergründe reden. Bitte verzeiht mir, dass ich dazu nicht in der Lage bin - und wie euer Interesse dazu steht, sei mal dahingestellt Mir ist diese Wahl herzlich egal und würdet ihr wissen um welche es geht, euch sicherlich auch. Für die Leute selber, sieht es wohl anders aus ... die sind eh nen bissl "anders".

Ich kann ja die Missgunst über das Thema verstehen aber ihr und vor allem ich werden das stattfinden auch kaum verhindern. Lass "sie" doch wählen, "sie" haben sich dafür entschlossen das so und nicht anders zu machen, mir soll es doch egal sein.
Seid mir bitte nicht böse, wenn ich nicht weiter die Kraft aufbringen kann über ein Thema zu reden, bei dem ich völlig eurer Meinung bin - e-Voting ist scheiße. Vielleicht sollte man einen neuen Thread dazu aufmachen. Der wird zwar recht Inhaltsleer und redundant - jeder postet "e-Voting ist scheiße" mit mir an erster Stelle - und eigentlich ist auch an anderer Stelle schon ausreichend gesagt, aber bitte sprengt mein Thema nicht damit, in dem ihr mich auf die "pro e-Voting" Seite drängt und stichhaltige Argumente dafür verlangt damit ihr meine eingangs erwähnte Frage als "fragenswürding" in einem logisch widerspruchsfreien System akzeptiert, denn das kann ich nicht liefern!
Wenn die Mehrheit auf die Frage nicht antworten möchte, weil die Randbedingungen (das e-Voting) nicht in ihr akzeptiertes Weltbild passt dem man nie Unterstützung geben möchte, so muss ich das akzeptieren und würde dann bitten diesen Thread zu schließen. Ich selber habe nämlich, wie gesagt, keine Kraft Fürsprecher einer Sache zu sein, nur um meine Frage tauglich der Beantwortung erscheinen zu lassen.

@lordnaikon: Es sollte bei Wahlen nicht um Arbeitsersparnis gehen, sondern um eine nachprüfbare, halbwegs manipulationssichere Wahl. Wenn es um Arbeitsersparnis geht, dann lässt man die Wahl einfach weg und kungelt oder würfelt ein Ergebnis aus.

Ja, richtig!

Ich weiss, dass ich das jetzt ziemlich einfach sagen kann, weil ich nicht in der Situation bin, aber ich würde mich schlicht weigern so etwas zu entwickeln. Wenn von so einer Wahl tatsächlich etwas wichtiges abhängt, dann möchte ich nicht, dass sie nicht nachprüfbar manipulierbar ist. Und IMHO sollte man Leute auch gar nicht erst daran gewöhnen, dass das so schön einfach geht, und mit „Naja, das ist schon sicher genug und es spart Arbeit” argumentieren. Das ist IMHO Augenwischerei.

Ja, richtig, da habe ich nichts hinzuzufügen.

Das die jetzige Papierwahl Schwachstellen hat, macht e-Voting nicht besser. Gegen die Schwachstellen bei der Papierwahl kann man nämlich etwas machen. Gegen die inhärenten Probleme beim e-Voting nicht.

Mir ging es nicht um DAS Papiervoting, sondern wie es JETZT bei "UNS" umgesetzt ist. An einer Verbesserung dieser habe ich keinen Einfluss. Mein Einfluss einer Verbesserung würde nur darin bestehen, dieses e-Voting besser zu machen als das jetzige Papierwahlverfahren.

Das jemand bei offen herumliegenden Wahlzetteln nachträglich unbemerkt Kreuzchen ändert, kann man verhindern, in dem man halt darauf achtet. Das die Tür offen ist, sehe ich als Vorteil gegenüber e-Voting, denn bei der offenen Tür kann jeder zuschauen und nachvollziehen wie das Ergebnis zustande gekommen ist. Beim e-Voting braucht man IT-Kenntnisse um zu manipulieren, aber auch um Schwachstellen überhaupt zu erkennen, oder um zu prüfen ob am Gerät manipuliert wurde. Das Ergebnis kann man *gar nicht* prüfen! Du kannst Bits nicht ansehen ob sie manipuliert wurden. „Zauberpapier”, radiert und neu gesetzt, usw. kann man dagegen noch hinterher überprüfen. Bei einer rein elektronischen Wahl, kann der Wähler nie sicher sein, dass seine Stimme auch so gezählt wird, wie er sie abgegeben hat. Und damit disqualifiziert sich das Verfahren für jede Wahl bei der es tatsächlich auf etwas ankommt. Und bei unwichtigen Wahlen kann man sich gleich das ganze Sicherheits-„snake oil” sparen.

Absolut, anstandslos richtig.

[deets]

Whao. Spannende Einstellung. Zuerst enthaelst du uns den wahren Zweck des ganzen vor, laesst uns hier nach Loesungsansaetzen suchen - und als das ganze dann klar wird, fehlt dir die Kraft, weiter zu reden. Aber unseren Aufwand vorher dankend in kauf nehmen?!?

Wenn du gleich rausgerueckt waerest mit deinem Plan, dann haette sich die Diskussion auf ein "ich will e-voting", "geht nicht wirklich", "ok, ich muss es aber trotzdem machen" beschraenkt. Vor allem, weil du dich ja auch schon offensichtlich mit dem Thema auseinandergesetzt hast.

So aber eiern wir hier rum, ohne zu wissen worum's geht.... und alle Gedanken und Einwaende werden eh in den Wind geschlagen. Danke dafuer.

[Leonidas]

So aber eiern wir hier rum, ohne zu wissen worum's geht.... und alle Gedanken und Einwaende werden eh in den Wind geschlagen. Danke dafuer.

Hab den Thread jetzt erst durchgelesen und es ist völlig egal was ihr argumentiert, lordnaikon wird eh irgendein System aufstellen, egal wie sicher oder nicht das sein wird. Also tendentiell eher weniger sicher, wenns auf PCs laufen soll. Aber da kann man sich dann noch mehr Arbeit sparen und einfach alle Sicherheit weglassen, also nur das implementieren was unbedingt nötig ist. Public Keys, Signaturen? Bah, das steigert nur den ja eigentlich zu reduzierenden Arbeitsaufwand, würde empfehlen sich dieses Snake-Oil Voodoo auch zu sparen.

[deets]

@Leonidas

Exakt, ja.

[BlackJack]

@lordnaikon: Ich denke Du musst aufpassen technische Antworten nicht mit einer Grundsatzdokumentation zu verwechseln, wenn sie Dir nicht gefallen.

Wo kommt hier eigentlich die Historie ins Spiel?

[lordnaikon]

@deets: Wenn ihr euch missbraucht fühlt, dann tut es mir leid, ehrlich. Ich denke das der Thread genau gleich verlaufen wäre hätte er mit : ["ich will e-voting", "geht nicht wirklich", "ok, ich muss es aber trotzdem machen" ] angefangen. Ich weiß du siehst das anders. Natürlich bin ich dankbar, für euren Aufwand. Aber willst du mir unterstellen, dass ich undankbar bin, weil ich nicht das xste mal darauf eingehen will, dass e-Voting unsicher ist? Ich bin ja nicht ratsuchend hierher gekommen, damit ihr mir dieses System durchdenkt, damit ich weniger Arbeit habe. An sich ist mir dieses e-Voting auch schnuppe. Ich hatte aber ein persönliches Interesse speziell an diesem Protokoll, der Historie. Als nämlich die Frage danach aufkam hatte ich, einfach für mich, ein persönliches Interesse daran, ganz abseits dieses e-Votings. Denn so eine Historie ließe sich sicherlich auch für einiges andere anwenden. Mir ist sowas nämlich noch nicht bekannt, weder als eine art Bibliothek, vorkommen in anderen Programmen oder Papers darüber. Etwas ähnliches habe ich nun z.B. in Bitcoin gefunden, wobei es dort gänzlich anders abläuft. Das tolle daran ist nämlich, dass man das Problem, wie ich finde, ganz losgelöst von dem e-Voting betrachten kann. Ich wollte einfach wissen ob es so etwas schon gibt, wenn nein ob und wie man sowas umsetzen könnte oder ob es überhaupt vertretbar geht ohne zu viele Annahmen treffen zu müssen. Leider musste ich aber immer wieder darauf hinweisen, dass es zwar um e-Voting geht ich es aber losgelöst, mit der Prämisse des sicheren Clienten, betrachtet sehen möchte. Das hat aber leider niemanden interessiert. Meine Kritik und Kraftlosigkeit fußt eher auf diesen Umstand, und nicht das ihr, als meine Arbeiterbienchen hier nicht die Ergebnisse liefert, die ich möchte.
Entschuldige wenn ich dich und andere verärgert haben sollte. Das war weder meine Absicht, noch habe ich es bewusst dazu kommen lassen.

@Leonidas: Snake-Oil Voodoo ist aber verlangt.

Ich will in dem Thread nicht beantwortet wissen, wie man sichere e-Voting betreibt. Sondern ob und wie ich so ein Protokoll am besten erstellen kann, und welche Vorbedingungen dafür gelten müssen. Da ich im Verlauf des Threads schon einen Vorschlag gebracht habe, vielleicht noch wo Denkfehler sind und wo es unter Berücksichtigung der Vorbedingen angreifbar ist. Dass das Thema e-Voting nicht gut ankommt war mir bewusst. Sollte ich anfangs durch Verschleierung einen falschen Weg eingeschlagen haben, dann tut mir das leid. Ich schätze nämlich die Diskussionen hier im Forum nämlich sehr und finde die angenehm Erkenntnis bringend, die mich schon das ein oder andere mal zu Lösungen gebracht hat ohne die ich alleine außerstande gewesen wäre. (Ich erinnere da an das Auswahlproblem für ein Mosaik und die Routenberechnung, beide Threads haben mir sehr geholfen)

Weiter weiß ich nicht was ich sagen soll. Entweder ihr zeigt mir jetzt die kalte Schulter, weil ich mit dem Thema aus Eigenverschulden falsch umgegangen bin oder .. ja ich weiß nicht was "oder".

hochatungsvoll Lordnaikon

[lordnaikon]

@lordnaikon: Ich denke Du musst aufpassen technische Antworten nicht mit einer Grundsatzdokumentation zu verwechseln, wenn sie Dir nicht gefallen.

Ich werde mich bemühen.

Wo kommt hier eigentlich die Historie ins Spiel?

Die abgegebene Wertung/Wahl soll schrittweise auf dem Client aufgezeichnet werden. Es stehen mehrere "Wahlzettel" zur Verfügung, eine Wahl(Stimmenabgabe) ist änderbar so lange das Verfahren nicht durch den Wähler abgeschlossen oder eine Frist abgelaufen ist. Stell es dir vielleicht eher als ein Survey mit vielen Fragen und multiple-choice Antworten vor. Der gesamte Wahlprozess soll geloggt werden. Dienlich ist das ganze falls der Server nach der Anmeldung ausfällt. So sollen die Stimmenabgaben an den Wahlgeräten eingesammelt werden können um sie dann "per Hand" elektronisch auszuwerten.
//EDIT: Dabei soll dieses "Log", nachdem es eingesammelt wurde oder während dem einsammeln, nicht mehr verändert werden können. Hast du das gemeint?

[BlackJack]

@lordnaikon: Auch losgelöst von e-voting kann man die Probleme davon nicht lösen. Oder anders ausgedrückt, wenn man das könnte, dann gäbe es ja schon eine e-voting-Lösung ohne die Probleme.

So ein manipulationssicheres Protokoll kann man nicht erstellen. Jedenfalls nicht ohne dass die Anwender dem System soviel vertrauen entgegen bringen, dass Du es auch ganz einfach ohne den ganzen Hokuspokus speichern kannst.

Wir sagen dir nicht dass das nicht geht, weil wir etwas gegen e-voting haben, sondern wir haben etwas gegen e-voting, weil das eben *technisch* nicht geht. Das ist keine Meinungs- oder ideologische Frage.

[crs]

weil das eben *technisch* nicht geht.

Warum nicht?

[deets]

weil systeme, die irgendwo beim endanwender stehen, auf die selbiger zugriff hat - oder auch nur andere involvierte 3te, wie zB kommunale angestellte, welche solche dinge einlagern - nunmal manipulationen ausgesetzt sein koennen.

wenn es eine loesung fuer dieses problem gaebe - glaubst du nicht, ein multi-milliarden-konzern wie sony haette sie sich nicht schon erarbeitet, statt sich ueber einen geohot zu aergern, der ihnen den signier-schluessel mopst?

[crs]

weil systeme, die irgendwo beim endanwender stehen, auf die selbiger zugriff hat - oder auch nur andere involvierte 3te, wie zB kommunale angestellte, welche solche dinge einlagern - nunmal manipulationen ausgesetzt sein koennen.

Das waere moeglich, aber falls diese Manipulationen erkannt werden koennen?

wenn es eine loesung fuer dieses problem gaebe - glaubst du nicht, ein multi-milliarden-konzern wie sony haette sie sich nicht schon erarbeitet, statt sich ueber einen geohot zu aergern, der ihnen den signier-schluessel mopst?

Das beschreibt aber zum einen ein anderes Problem, und zum anderen ist damit auch nicht gesagt das es generell nicht geht, nur weil Firma x mit y Milliarden etwas nicht kann.

Eine History die nicht geaendert werden kann ist aber auch ein anderes Problem als Voting.