-
Notifications
You must be signed in to change notification settings - Fork 158
DE:Konzept geheime Wahlen mit OpenSlides
Das Konzept geheimer Wahlen mit OpenSlides basiert auf drei Komponenten. OpenSlides, dem Wahlhelfer und dem Wahlbeobachter. Das Konzept funktioniert, wenn diese drei Komponenten unabhängig voneinander sind und nicht in böser Absicht zusammenarbeiten.
Das Konzept wird am Beispiel von Personenwahlen erklärt. Es lässt sich jedoch auch auf andere Abstimmungen (zum Beispiel "Ja", "Nein", "Enthaltung") übertragen.
Durch das Konzept wird ermöglichst, dass nur wahlberechtigte Personen eine Stimme abgeben können, das Wahlergebnis jedoch von keiner der drei Komponenten gefälscht werden kann und keine der Komponenten herausfinden kann, welcher Wahlberechtiger wie gewählt hat.
Die folgende Seite stellt den Stand des Konzeptes vom 13. September 2024 dar.
Schaubild-CryptoVoting_20240913.pdf
Vor einer Wahl generien der Wahlhelfer und der Wahlbeobachter jeweils ein kryptogafisches Schlüsselpaar. Die öffentlichen Schlüssel werden an die Wahlberechtigten verteilt. Diese verschlüsseln ihre Stimme mit beiden Schlüsseln und senden diese an OpenSlides. OpenSlides überprüft die Wahlberechtigung und das jede Person nur einmal wählt. Am Ende der Wahl werden alle verschlüsselten Stimmen an den Wahlhelfer gesandt. Hierbei darf die Reihenfolge der versendeten verschlüsselten Stimmen nicht identisch mit dem Eingang der Stimmen bei OpenSlides sein. Der Wahlhelfer entschlüsselt die Stimmen und gibt sie in zufälliger Reihenfolge an den Wahlbeobachter weiter. Dieser erhält ebenfalls die verschlüsselten Stimmen von OpenSlides und kontrolliert, dass diese richtig vom Wahlhelfer entschlüsselt wurden. Sowohl der Wahlhelfer als auch der Wahlbeobachter signieren das Ergebnis, welches an die Wahlberechtigten zurückgegeben werden.
Die verteilten öffetlichen Schlüssel werden während der Wahl sowohl im Client als auch auf dem Projektor grafisch dargestellt. Die Wahlberechtigten, der Wahlhelfer und der Wahlbeobachter sind aufgerufen zu überprüfen, dass die Darstellung auf ihrem eigenen Bildschirm identisch mit der Darstellung auf dem Projektor ist.
Der Ergebnis einer Wahl besteht aus drei Teilen:
- Den entschlüsselten Stimmen in zufälliger Reihenfolge,
- eine Liste mit kryptografischen Hashes (Prüfsummen) von allen abgegebenen Stimmen und
- den Signaturen des Wahlhelfers und des Wahlbeobachters.
Die Liste mit den Hashes stellt sicher, dass der Wahlhelfer und der Wahlbeobachter die selben Stimmen auszählen und keine Stimmen hinzufügen, entfernen oder verändern können. Außerdem kann jeder Wahlberechtige am Ende der Wahl kontrollieren, dass der Hash seines Stimmzettels im Ergebnis ist und somit gezählt wurde.
Der verschlüsselte Wahlzettel besteht aus der Stimme des Nutzers (zum Beispiel der Name eines Kandidaten) und der poll_id, daher einer für jede Wahl eindeutigen Nummer.
Dem Wahlhelfer und dem Wahlbeobachter wird mitgeteilt, die Stimmen welcher poll_id sie entschlüsseln. Enthält ein entschlüsselter Stimmzettel eine andere poll_id, so wird dieser nicht veröffentlicht. Der Wahlhelfer und der Wahlbeobachter merken sich das Ergebnis zu einer poll_id. Werden sie mit der selben poll_id erneut aufgerufen geben sie das selbe Ergebnis zurück, selbst wenn andere Daten übergeben wurden. Hierdurch wird sichergestellt, dass OpenSlides jeden Stimmzettel nur einmal entschlüsseln lassen kann.
Vor der Wahl wird ein Wahlhelfer und ein Wahlbeobachter bestimmt. Diese können vom Wahlleiter bestimmt, durch das Gremium gewählt oder auf einen anderen Weg festgelegt werden. Diese laden den entsprechenden WebAssembly-Code und generieren darüber ihr Schlüsselpaar. Die beiden öffentlichen Schlüssel werden an das Backend gesandt und über die in OpenSlides üblichen Wege in die Datenbank gespeichert und über den Autoupdate-Service an alle Wahlberechtigten verteilt.
Während der Wahl halten der Wahlhelfer und der Wahlbeobachter eine Verbindung zum Vote-Service offen, damit Daten gepusht werden können.
Die Clients ziehen die öffentlichen Schlüssel des Wahlhelfers und des Wahlbeobachters und zeigen eine grafische Darstellung auf ihrem Bildschirm an. Gleichzeitig wird die gleiche Darstellung auf dem Projektor angezeigt. Der Client ist angehalten, die Darstellungen zu vergleichen. Anschließend verschlüsselt er seine Stimme zusammen mit der poll_id mit den öffentlichen Schlüsseln des Wahlhelfers und des Wahlbeobachters. Dieser verschlüsselte Stimmzettel wird an den Vote-Service gesendet.
Der Request-Body an den Vote-Service ist beispielsweise:
{
id: Id; // poll_id
user_id: id; // vote-user. Für Vote-Delegation.
value: base64(enc({
// pollmethod in (Y, N)
votes: {<option_id>: <amount>} | 'Y' | 'N' | 'A';
// pollmethod not in (Y, N)
votes: {<option_id>: 'Y' | 'N' | 'A'} | 'Y' | 'N' | 'A';
poll_id: id
}))
}
Der vote-service prüft wie bisher, dass der Nutzer authentifiziert ist und wählen darf.
Anschließend speichert er sowohl die verschlüsselte Stimme als auch die Information, dass der Nutzer abgestimmt hat. In der selben Datenbank-Transaktion wird sichergestellt, dass der Nutzer vorher noch nicht gewählt hat und die Wahl noch läuft.
Das OpenSlides-Backend sendet am Ende der Wahl ein Signal an den vote-service.
Der vote-service lädt alle verschlüsselten Stimmen und pusht diese an den Wahlhelfer zusammen mit der poll_id.
Der Wahlhelfer kontrolliert, ob ihm zu der poll_id bereits Daten vorliegen. Wenn ja, werden diese zurückgegeben. Anderenfalls werden die Daten berechnet.
Hierfür hasht er alle verschlüsselten Stimmen. Anschließend werden die Stimmen entschlüsselt und in eine zufällige Reihenfolge gebracht.
Enthält die entschlüsselte Stimme eine poll_id, die nicht mit der vom vote-service übergebenen poll_id übereinstimmt, wird diese nicht in die Liste der entschlüsselten Stimmen aufgenommen. Das selbe kann passieren, wenn die Stimme technisch nicht entschlüsselt werden kann.
Die Liste der Hashes und die Liste der entschlüsselten Stimmen wird zusammengefügt und gemeinsam signiert.
Zuletzt werden die Daten zusammen mit der Signatur unter der poll_id gespeichert und an den vote-service zurückgegeben.
Der vote-service gibt die Daten des Wahlhelfers an den Wahlbeobachter weiter. Außerdem wird die poll_id und die verschlüsselten Stimmen übergeben.
Der Wahlbeobachter führt die selben Schritte wie der Wahlhelfer durch. Anstatt die entschlüsselten Stimmen in eine zufällige Reihenfolge zu bringen, wird überprüft, dass jede entschlüsselte Stimme in dem Datenpaket des Wahlhelfers vorhanden ist.
Wie auch der Wahlhelfer, speichert der Wahlbeobachter das Ergebnis für eine poll_id und gibt bei einem erneuten Aufruf der selben poll_id das selbe ergebnis zurück.
Zuetzt wird eine weitere Signatur über die Daten gebildet und alles an den vote-service zurückgegeben. Dieser erhält daher die folgenden Daten:
{ hash_liste: Liste der hashes aller verschlüsselten Stimmzettel, entschlüsselte_stimmen: Liste aller entschlüsselten Stimmen, die entschlüsselt werden konnten und die passende poll_id hatten, signatur_wahlhelfer: Die Signatur des Wahlhelfers, signatur_wahlbeobachter: Die Signatur des Wahlbeobachters }
Durch die zufällige Reihenfolge der entschlüsselten Stimmen kann kein Zusammenhang zwischen einem Hash und der entsprechenden entschlüsselten Stimme gebildet werden.
Der Vote-Service leitet das Ergebnis an das Backend weiter.
Das Backend wertet das Ergebnis aus. Zusätzlich zu der Auswertung wird das zweifach signierte Datenpaket gespeichert. Bei veröffentlichung der Wahl werden die Daten mit den Singaturen an alle Wahlberchtigten verteilt.
Das OpenSlides-Backend sendet nach dem erfolgreichen Speichern der Daten im Datastore einen Clear-Request an den vote-service.
Der vote-service löscht hieraufhin alle Informationen zur Wahl (die verschlüsselten Stimmen).
Der vote-service informiert den Wahlhelfer und den Wahlbeobachter über das erfolgreiche Speichern der Daten. Diese löschen daraufhin alle Daten inklusive ihrer geheimen Schlüssel.
Beim Löschen der Daten im Wahlhelfer und Wahlbeobachter muss sichergestellt werden, dass für die gleiche poll_id nicht unterschiedliche Stimmen entschlüsselt werden können. Aktuell wird dies dadurch sichergestellt, dass beim Beenden einer Wahl das Schlüsselpaar gelöscht wird und es somit unmöglich ist, die Stimmenzettel erneut zu entschlüsseln. Es ist möglich, dass in einer zukünftigen Version das Schlüsselpaar nicht nach jeder Wahl gelöscht wird, sondern für mehrere Wahlen verwendet werden kann. In diesmem Fall müssen sich der Wahlhelfer und der Wahlbeobachter für den gesamten Lebenszeitraum des Schlüssels merken, zu welchen poll_ids sie bereits Daten entschlüsselt haben.
Die Wahlberechtigten erhalten über den Autoupdate-Service die signierten Daten. Sie überprüfen mit den öffentlichen Schlüsseln des Wahlhelfers und des Wahlbeobachters, dass die signaturen stimmen. Anschließend wird die Liste der hashes durchgegangen und überprüft, dass der eigene verschlüsselte Stimmzettel vorhanden ist.
Optional kann der Client die signierten Daten durch eine externe Software überprüfen. Hierdurch wird sichergestellt, das der OpenSlides-Client nicht manipuliert wurde.
Der Code des Wahlhelfers, des Wahlbeobachters und der Code zum abgeben und überprüfen der Stimmen wird als WebAssembly-Modul zur Verfügung gestellt. Es braucht daher abgesehen von OpenSlides keine weitere Server-Infrastruktur. Die entsprechenden Module werden bei bedarf durch den OpenSlides-Client geladen.
Optional wird eine versionierte Wahlsoftware über sichere Kanäle ausgeliefert, welche jedoch intern den selben WebAssembly-Code ausführen. Anders als beim Web-Client wird der WebAssembly-Code hier nicht nachgeladen, sondern ist Teil der Software. Hierdurch wird sichergestellt, dass die Ausgeführte Software nicht durch den OpenSlides-Admin manipuliert werden kann.
Ein besonderes Setup für das Konzept ist nicht erforderlich.
Die Sicherheit basiert auf der Annahme, dass der Admin von OpenSlides nicht mit dem Wahlhelfer oder den Wahlbeobachter zusammenarbeitet, insbesondere der Admin von OpenSlides keinen Zugriff auf die Computer des Wahlhelfers und des Wahlbeobachters hat.
Der OpenSlides-Admin kennt die zuordnung der verschlüsselten Stimmen zu den wahlberechtigten Personen. Der Wahlhelfer und der Wahlbeobachter kennen die entschlüsselte Stimme zu der jeweiligen verschlüsselten Stimme. Solange die Beteiligten nicht zusammenarbeiten, kann die entschlüsselte Stimme keinem Wahlberechtigten zugeordnet werden.
Würde der OpenSlides-Admin eine Stimme entfernen oder ersetzen, so würde der Wahlhelfer den Hash der Stimme nicht in den Briefumschlag aufnehmen. Hierdurch würde dem betroffenen Client auffallen, dass die eigene Stimme nicht entschlüsselt wurde.
Würde der OpenSlides-Admin Stimmen hinzufügen, so würde auffallen, dass es mehr Stimmen wie Stimmberechtigte gibt.
Würde der Wahlhelfer Stimmen hinzufügen, verändern der entfernen, so würde dies dem Wahlbeobachter auffallen, dass das Ergebnis des Wahlhelfers nicht mit den verschlüsselten Stimmen übereinstimmt.
Der OpenSlides-Admin hat nicht die Möglichkeit jedem User unterschiedliche Daten anzuzeigen (jeder Nutzer wird seine korrekte Stimme angezeigt, aber alle anderen Stimmen sind manipuliert), weil dann die Signaturprüfung fehlschlagen würde.
Der OpenSlides-Admin kann keinen manipulierten JS-Code, bzw. WebAssembly-Code an die Clients ausliefern, der die Signatur falsch prüft, da die Clients den Datenblob auch manuell prüfen könnten. Entweder im Terminal oder über einen externen Software.
Im folgenden werden verschiedene Angriffsmöglichkteiten besprochen:
Der OpenSlides-Admin kann selbst die Rolle des Wahlhelfers oder des Wahlbeobachters übernehmen. Er erzeugt öffentliche Schlüssel und verteilt diese an die Clients.
Dieser Angriff fällt auf, wenn die Clients und der richtige Wahlhelfer und Wahlbeobachter die grafische Darstellung der öffentlichen Schlüssel überprüfen. Da der OpenSlides-Admin nicht den gleichen geheimen Schlüssel wie der Wahlhelfer und der Wahlbeobachter erzeugen kann, unterscheidet sich die grafische Darstellung auf den Bildschrimen von Wahlhelfer und Wahlbeobachter von der Darstellung auf dem Projektor.
Der OpenSlides-Admin könnte einen gefälschten Client ausliefern. Dieser verhält sich zwar korrekt, sendet die unverschlüsselte Stimme (oder mit einem Schlüssel des OpenSlides-Admins) aber zusätzlich noch an eine andere URL.
Mit dem Angriff wird die Wahl nicht manipuliert. Der Admin erfährt jedoch, wie welcher Nutzer abgestimmt hat.
Da OpenSlides sehr viele Requests absendet, wäre es selbst für einen aufmerksmane Nutzer sehr schwer, möglich die Daten zu entdecken.
Eine Lösung wäre, dass wir für das Voting eine abgeschlossene App/Browser-Plugin/etc. anbieten, welches code-reviewed wurde und vom Admin zur Laufzeit nicht angepasst werden kann.
Bei größeren Veranstaltungen könnte der OpenSlides-Admin gegenüber den Nutzern behaupten, dass mehr Leute stimmberechtigt sind. Zum Beispiel behauptet er, dass 100 Personen stimmberechtigt sind, obwohl es tatsächlich nur 80 sind. Die 20 Differenzstimmen kann nun der Admin selbst abgeben.
Nach der oben beschriebenen Überprüfung durch die Clients fällt dies nicht auf. Der Angriff fällt nur auf, wenn ein Nutzer weiß, dass es (nach der Satzung) nur 80 Delegierte hätte geben dürfen, aber 100 Stimmen abgegeben wurden. Aus diesem Grund ist es wichtig das Wählerverzeichnis zu veröffentlichen oder zumindest einer vertrauenswürdigen Person zugriff hierauf zu geben.
Der OpenSlides-Admin könnte beim Beenden einer Wahl für alle Nicht-Wähler eine Stimme abgeben.
Dieser Angriff fällt nur auf, wenn Nutzer später beweisen könnten, dass sie nicht abgestimmt haben. Dies dürfte sehr schwierig sein.
Der Admin kann bei einer Person herausfinden, wie diese abgestimmt hat, wenn er dafür in Kauf nimmt, dass die Wahl ungültig wird. Er sendet dafür die eine Stimme zur Entschlüsselung an den Wahlhelfer. Dieser entschlüsselt die Stimme. Da es nur eine Stimme gibt, kann die Reihenfolge nicht geändert werden und der Admin erfährt, wie diese eine Stimme unverschlüsselt aussieht.
Allerdings kann der Admin anschließend die anderen Stimme nicht mehr entschlüsseln, da der Wahlhelfer für die gleiche poll_id immer die gleichen Daten zurückliefert. Der OpenSlides-Admin kann auch keine andere poll_id verwenden, da der Wahlhelfer eine Stimme nur entschlüsselt, wenn die poll_id in der verschlüsselten Stimme mit der angefragten poll_id identisch ist.
Der Angriff kann nicht dadurch abgewehrt werden, dass der Wahlhelfer die Stimmen nur dann entschlüsselt, wenn mindestens N Stimmen übergeben werden. Denn der OpenSlides-Admin kann ohne Probleme N Fake-Stimmen erstellen. Wenn er die Fake-Stimmen und die eine User-Stimme übersendet und entschlüsseln lässt, dann kann er in der Rückgabeliste ohne Probleme die Fake-Stimmen erkennen und aussortieren. So erhält er die User-Stimme.
Eine Verteidigung gegen diesen Angriff existiert noch nicht.
Der OpenSlides-Admin könnte manipulierte Daten an den Wahlbeobachter schicken, nachdem er die richtigen Daten vom Wahlhelfer erhalten hat. Da es aufwendig wäre dem Wahlbeobachter mitzuteilen, wer der echte Wahlhelfer ist, kann der Wahlbeobachter die Signatur des Wahlhelfers nicht sicher überprüfen. Da jedoch der Wahlbeobachter für die selbe poll_id immer die selben Daten zurückgibt, können zu einer poll_id nur einmal manipulierte Daten an den Wahlbeobachter gesandt werden, was zu einer ungültigen Wahl führen würde.
Ein Angreifer, der bei einer lokalen Veranstaltung das Netzwerk kontrolliert und überwachen kann, könnte versuchen mit Timing-Analysen herauszufinden, welcher Nutzer wie abgestimmt hat. Hierfür beobachtet er, wann welcher Nutzer während einer Abstimmung seine Stimme abgibt.
Da jedoch die verschlüsselten Stimmen durch OpenSlides gespeichert und erst am Ende der Abstimmung gemeinsam an den Wahlhelfer gesandt werden, hat der Netzwerk-Admin keine Möglichkeit die verschlüsselte Stimmen einer entschlüsselten Stimme zuzuordnen.
Wenn jedoch der Netzwerk-Admin gleichzeitig der Wahlhelfer oder der Wahlbeobachter ist, dann könnte er durch eine Timing-Analyse herausfinden, in welcher Reihenfolge die Nutzer abgestimmt haben. Würde OpenSlides die gespeicherten Stimmen in genau dieser Reihenfolge an den Wahlhelfer oder den Wahlbeobachter schicken, so könnten diese zuordnen, welche entschlüsselte Stimme zu welchem Nutzer gehört.
Aus diesem Grund ist es wichtig, dass OpenSlides die Stimmen nicht in der Reihenfolge an den Wahlhelfer und den Wahlbeobachter sendet, in welcher er sie erhalten hat. Es muss nicht unbedingt eine zufällige Reihenfolge sein. Möglich ist auch eine alpfabetisch sortiert nach der verschlüsselten Stimme. Die Reihenfolge darf nur nicht abhängig vom Eingang der Nachricht bei OpenSlides und die User-ID sein.
Die Performance währned einer Wahl ist identisch wie der aktuelle vote-service.
Erst am Ende einer Wahl müssen die Einzelstimmen entschlüsselt werden.
Wahlhelfer, Wahlbeobachter sind WebAssembly-Module. Diese exportieren die folgenden Funktionen:
Initialisiert die Daten des Wahlhelfers. Insbesondere wird ein neuer geheimer Schlüssel erzeugt.
Ist die Komonente bereits initialisiert, wird ein Fehler zurückgegeben.
Setzt alle Daten zurück. Anschließend kann mit Init ein neuer Schlüssel erzeugt werden.
Gibt den öffentlichen Schlüssel zurück.
Gibt einen Fehler zurück, wenn init noch nicht aufgerufen wurde.
Erhält die poll_id und die verschlüsselten Stimmen.
Gibt die entschlüsselte Wahl (Hash Liste und entschlüsselte Stimmen) sowie eine Signatur zurück.
Gibt insbesondere dann einen Fehler zurück, wenn init noch nicht aufgerufen wurde oder wenn count mit einer anderen poll_id aufgerufen wurde. In einer zukünftigen Version könnte der Wahlhelfer in der Lage sein, mehrere poll_ids zu verwalten.
Erhält die poll_id, die verschlüsselten Stimmen sowie die Daten des Wahlhelfers.
Gibt die Daten des Wahlhelfers sowie eine weitere Signatur zurück.
Gibt insbesondere dann einen Fehler zurück, wenn init noch nicht aufgerufen wurde oder wenn count mit einer anderen poll_id aufgerufen wurde. In einer zukünftigen Version könnte der Wahlhelfer in der Lage sein, mehrere poll_ids zu verwalten.
Erwartet einen öffentlichen Schlüssel des Wahlbeobachters oder des Wahlhelfers und gibt eine SVG Grafik zurück, welche den Schlüssel darstellt.
Erwartet die öffentlichen Schlüssel des Wahlbeobachters und des Wahlhelfers sowie die poll_id und die zu verschlüsselnde Stimme.
Gibt die verschlüsselte Stimme zurück.
Erwartet die öffentlichen Schlüssel des Wahlbeobachters und des Wahlhelfers sowie die Rückgabedaten des Wahlbeobachters. Optional kann die (eigene) verschlüsselte Stimme übergeben werden.
Gibt alle entschlüsselten Stimmen zurück sowie die Anzahl der Abgegeben Stimmen. Die Anzahl der entschlüsselten Stimmen kann unterschiedlich sein, wenn ungültig verschlüsselte Stimmen abgegeben wurden oder Stimmen mit einer falschen poll_id abgegeben wurden.
Gibt insbesondere einen Fehler zurück, wenn eine der Signaturen nicht passt oder wenn der hash der optional übergebenen verschlüsselten Stimmen nicht in der Hash Liste ist.
Folgende kryptografischen Operationen sind erforderlich:
Bei den asynchone Schlüsseln von Wahlhelfer und Wahlbeobachter handelt es sich bei der aktuellen Implemntierung um Schlüssel nach dem Ed25519 verfahren (rfc8032).
Mit diesen wird die Signatur der entsprechenden Komponente erzeugt sowie die Signatur überprüft.
Aus einem Ed25519 Schlüssel lässt sich ein x25519 Schlüssel berechnen, der zum Verschlüsseln der Stimmen bzw. zum entschlüsseln verwenden lässt.
Die Votes haben eine unbestimmte Größe. In den meisten Fällen sollte es unter 100 Byte sein. Das System sollte jedoch mit 1kb großen Stimmen keine Performanceprobleme bekommen.
Das Verschlüsselungsverfahren muss sicherstellen, dass die verschlüsselten Daten nicht verändert wurden, da die Daten über den (potenziell bösen) OpenSlides-Admin an den Wahlhelfer und Wahlbeobachter gesandt werden und nicht weiter signiert sind. Ein HMAC ist daher erforderlich.
Außerdem muss das Verfahren sicherstellen, dass bei der Verschlüsselung der gleichen Daten unterschiedliche verschlüsselte Daten entstehen. Der OpenSlides-Admin kennt am Ende einer Wahl sowohl die verschlüsselten Einzellstimmen als auch die entschlüsselten Einzelstimmen. Es darf ihm nicht möglich sein durch erneutes verschlüsseln der Einzelstimmen den Klartext einer Stimme der verschlüsselten Stimme zuzuordnen. Es muss daher eine probabilistic encryption verwendet werden.
Die Verschlüsselung passiert verteilt in jedem Client. Die Geschwindigkeit beim Verschlüsseln sollte daher keine Rolle spielen.
Die Entschlüsselung aller Stimmen passiert in einem Durchgang beim Wahlhelfer und beim Wahlbeobachter. Ein solcher Durchgang ist zwar nicht zeitkritisch, sollte jedoch nicht mehr als ein paar Sekunden dauern.
Die Besonderheit ist, dass nicht ein großer Datenblob entschlüsselt wird, sondern viele kleine. Bei einer hybriden Verschlüsselung müssen daher sehr viele AES-Schlüssel mit dem asymmetrischen Verfahren entschlüsselt werden. Das asymmetrische Verfahren sollte daher schnell sein.
Die Stimme muss sowohl für den Wahlhelfer als auch für den Wahlbeobachter verschlüsselt werden. Es ist möglichst auszuschließen, dass ein Wahlberechtigter unterschiedliche Daten für den Wahlhelfer und den Wahlbeobachter verschlüsselt. Dies würde erst bei der Aktion des Wahlbeobachters auffallen, der dies nicht von einen Angriff des Wahlhelfers unterscheiden könnte und daher die Signatur verweigern würde.
Für die aktuelle Implementierung wird wie folgt vorgegangen:
- Zunächst wird ein zufälliger AES128 Schlüssel erzeugt (zufällige 128bit) und die Stimme damit verschlüsselt. Als Blockmode wird GCM verwendet, wobei ein statischer (nicht zufälliger) nonce verwendet wird. Da der AES-Key nur ein einziges Mal verwendet wird, ist ein statischer Noce unkritisch.
- Anschließend wird ein zufälliger und temporärer x25519 Schlüssel erzeugt. Mit diesen wird aus den öffentlichen Schlüsseln des Wahlhelfers und des Wahlbeobachters jeweils ein "shared secred" erzeugt.
- Aus den beiden "shared secreds" werden für den Wahlhelfer und den Wahlbeobachter mit HKDF und SHA256 jeweils ein geheimer AES-Schlüssel erzeugt.
- Mit diesen beiden Schlüsseln wird mit AES256 der in Schritt 1 erzeugte Schlüssel verschlüsselt.
In Schritt 1 wird AES128 gewählt, da dieses einen 128bit Schlüssel verwendet. Für die kurzen Nachrichten (ca 100. byte bis 1.000 byte) ist dies mehr als ausreichend. Der Vorteil ist jedoch, dass jede Variante von AES immer eine blocklänge von 128 bit verwendet. Ein AES128 Schlüssel kann daher in Schritt 4 direkt verschlüsselt werden, ohne dass es einen Blockmode braucht.
Durch dieses Verfahren werden die Daten für den Wahlbeobachter und für den Wahlhelfer gemeinsam verschlüsselt. Es ist dem Wahlberechtigten nicht möglich, unterschiedliche Daten zu verwenden. Durch das GCM verfahren in Schritt 1 wird die Authentizität der Daten sichergestellt.
Die verschlüsselten Daten enthalten den zufällig erzeugten öffentlichen Schlüssel aus Schritt 2 (32 byte), die beiden in Schritt 4 verschlüsselten Schlüssel (zwei mal 32 byte) sowie die in Schritt 1 verschlüsselten Daten (länge des Klartext) nebst dem GCM-Tag (16 byte). Die Chiffre ist daher immer 112 Byte länger als der Klartext.
- DE:Konzept OpenSlides 4
- Update Workflow
- Architecture
- Introduction to functionality
- Restrictions
- Buildsystem
- Development organization
- Services
- Technical details
- Potential Optimizations
- Best practices for developers