-
Notifications
You must be signed in to change notification settings - Fork 158
DE:Konzept geheime Wahlen mit OpenSlides
Das Konzept geheime, kryptografische Wahlen mit OpenSlides basiert auf drei Komponenten: OpenSlides sowie den beiden Wahlhelfern (Wahlsekretär und Wahlauditor). 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 stimmberechtigte 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 Stimmberechtigter wie gewählt hat.
Die folgende Seite stellt den Stand des Konzeptes vom 11. Januar 2025 dar.
Schaubild-CryptoVoting_20250111.pdf
Vor einer Wahl generieren die beiden Wahlhelfer jeweils ein kryptogafisches Schlüsselpaar. Die öffentlichen Schlüssel werden an die Stimmberechtigten verteilt. Diese verschlüsseln ihre Stimmzettel 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 Stimmzettel an den Wahlhelfer gesandt. Hierbei darf die Reihenfolge der versendeten verschlüsselten Stimmzettel nicht identisch mit dem Eingang der Stimmzettel bei OpenSlides sein. Wahlhelfer 1 (der Wahlsekretär) entschlüsselt die Stimmzettel und gibt sie in zufälliger Reihenfolge an den Wahlhelfer 2 (Wahlauditor) weiter. Dieser erhält ebenfalls die verschlüsselten Stimmzettel von OpenSlides und kontrolliert, dass diese richtig vom Wahlsekretär entschlüsselt wurden. Sowohl der Wahlsekretär als auch der Wahlauditor signieren die Wahlunterlagen, welches an die Stimmberechtigten zurückgegeben werden.
Die verteilten öffentlichen Schlüssel werden während der Wahl sowohl im Client (im Autopilot) als auch auf dem Projektor grafisch dargestellt. Die Stimmberechtigten und die Wahlhelfer 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 Stimmzetteln in zufälliger Reihenfolge,
- eine Liste mit kryptografischen Hash-Werten (Prüfsummen) von allen abgegebenen Stimmzetteln und
- den beiden Signaturen von Wahlsekretär und Wahlauditor.
Die Liste mit den Hash-Werten stellt sicher, dass der Wahlsekretär und der Wahlauditor die selben Stimmzettel auszählen und keine Stimmzettel hinzufügen, entfernen oder verändern können. Außerdem kann jeder Stimmberechtige am Ende der Wahl kontrollieren, dass der Hash-Wert seines Stimmzettels in den signierten Wahlunterlagen enthalten ist und somit sein Stimmzettel berücksichtigt wurde.
Der verschlüsselte Stimmzettel besteht aus der Stimme des Nutzers (zum Beispiel der Name eines Kandidaten) und der poll_id (TODO: ergänzen), daher einer für jede Wahl eindeutigen Nummer.
Den beiden Wahlhelfern wird mitgeteilt, die Stimmzettel welcher poll_id sie entschlüsseln. Enthält ein entschlüsselter Stimmzettel eine andere poll_id, so wird dieser nicht veröffentlicht. Die beiden Wahlhelfer 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 Wahlsekretär und ein Wahlauditor bestimmt. Diese können vom Wahlleiter bestimmt, durch das Gremium gewählt (z.B. Wahl- bzw. Zählkommission) 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 Stimmberechtigten verteilt.
Während der Wahl halten der Wahlsekretär und der Wahlauditor eine Verbindung zum Vote-Service offen, damit Daten gepusht werden können.
Die Clients ziehen die öffentlichen Schlüssel des Wahlsekretärs und des Wahlauditors 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 seinen Stimmzettel zusammen mit der poll_id mit den öffentlichen Schlüsseln der beiden Wahlhelfer. 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 den verschlüsselten Stimmzettel 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 Stimmzettel und pusht diese an den Wahlsekretär zusammen mit der poll_id.
Der Wahlsekretär kontrolliert, ob ihm zu der poll_id bereits Daten vorliegen. Wenn ja, werden diese zurückgegeben. Andernfalls werden die Daten berechnet.
Hierfür hasht er alle verschlüsselten Stimmzettel. Anschließend werden die Stimmzettel entschlüsselt und in eine zufällige Reihenfolge gebracht.
Enthält der entschlüsselte Stimmzettel eine poll_id, die nicht mit der vom vote-service übergebenen poll_id übereinstimmt, wird diese nicht in die Liste der entschlüsselten Stimmzettel aufgenommen. Das gleiche kann passieren, wenn der Stimmzettel technisch nicht entschlüsselt werden kann.
Die Liste der Hash-Werte und die Liste der entschlüsselten Stimmzettel 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 Wahlsekretärs an den Wahlauditor weiter. Außerdem wird die poll_id und die verschlüsselten Stimmzettel übergeben.
Der Wahlauditor führt die gleichen Schritte durch wie der Wahlsekretär. Anstatt die entschlüsselten Stimmzettel in eine zufällige Reihenfolge zu bringen, wird überprüft, dass jeder entschlüsselte Stimmzettel in dem Datenpaket des Wahlsekretärs vorhanden ist.
Wie auch der Wahlsekretär, speichert der Wahlauditor 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 Stimmzettel, die entschlüsselt werden konnten und die passende poll_id hatten, signatur_wahlsekretär: Die Signatur des Wahlsekretärs, signatur_wahlauditor: Die Signatur des Wahlauditor }
Durch die zufällige Reihenfolge der entschlüsselten Stimmuettel kann kein Zusammenhang zwischen einem Hash und dem entsprechenden entschlüsselten Stimmzettel 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 Wahlunterlagen-Datenpaket gespeichert. Bei Veröffentlichung der Wahl werden die Daten mit den Singaturen an alle Stimmberchtigten verteilt.
Das OpenSlides-Backend sendet nach dem erfolgreichen Speichern der signierten Wahlunterlagen im Datastore einen Clear-Request an den Vote-Service.
Der Vote-Service löscht hieraufhin alle Informationen zur Wahl (die verschlüsselten Stimmzettel).
Der Vote-Service informiert den Wahlsekretär und den Wahlauditor über das erfolgreiche Speichern der signierten Wahlunterlagen. Die beiden Wahlhelfer löschen daraufhin alle Daten inklusive ihrer geheimen Schlüssel.
Beim Löschen der Daten bei den Wahlhelfern muss sichergestellt werden, dass für die gleiche poll_id nicht unterschiedliche Stimmzettel 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 Wahlsekretär und der Wahlauditor für den gesamten Lebenszeitraum des Schlüssels merken, zu welchen poll_ids sie bereits Daten entschlüsselt haben.
Die Stimmberechtigten erhalten über den Autoupdate-Service die signierten Wahlunterlagen. Sie überprüfen mit den öffentlichen Schlüsseln der beiden Wahlhelfer, dass die Signaturen korrekt sind. Anschließend wird die Liste der Hash-Werte durchgegangen und überprüft, dass der Hash des eigenen verschlüsselten Stimmzettels vorhanden ist.
Optional kann der Client die signierten Wahlunterlagen durch eine externe Software überprüfen. Hierdurch wird sichergestellt, das der OpenSlides-Client nicht manipuliert wurde.
Der Code des Wahlsekretärs, des Wahlauditors und der Code zum Abgeben und Überprüfen der Stimmzettel 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 einem der beiden Wahlsekrehelfer zusammenarbeitet, insbesondere der Admin von OpenSlides keinen Zugriff auf die Computer der Wahlhelfer hat.
Der OpenSlides-Admin kennt die Zuordnung der verschlüsselten Stimmzettel zu den stimmberechtigten Personen. Die beiden Wahlhelfer kennen die entschlüsselte Stimmzettel zu der jeweiligen verschlüsselten Stimmzettel. Solange die Beteiligten nicht zusammenarbeiten, kann der entschlüsselte Stimmzettel keinem Stimmberechtigten zugeordnet werden.
Würde der OpenSlides-Admin einen Stimmzettel entfernen oder ersetzen, so würde der Wahlsekretär den Hash des Stimmzettel nicht aufnehmen. Hierdurch würde dem betroffenen Client auffallen, dass der eigene Stimmzettel nicht entschlüsselt wurde.
Würde der OpenSlides-Admin Stimmzettel hinzufügen, so würde auffallen, dass es mehr Stimmzettel wie Stimmberechtigte gibt.
Würde der Wahlsekretär Stimmzettel hinzufügen, verändern der entfernen, so würde dies dem Wahlauditor auffallen, dass das Ergebnis des Wahlsekretärs nicht mit den verschlüsselten Stimmzetteln übereinstimmt.
Der OpenSlides-Admin hat nicht die Möglichkeit jedem User unterschiedliche Daten anzuzeigen (jedem Nutzer wird sein korrekter Stimmzettel angezeigt, aber alle anderen Stimmzettel 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 Wahlsekretärs oder des Wahlauditors übernehmen. Er erzeugt öffentliche Schlüssel und verteilt diese an die Clients.
Dieser Angriff fällt auf, wenn die Clients und der richtige Wahlsekretär und Wahlauditor die grafische Darstellung der öffentlichen Schlüssel überprüfen. Da der OpenSlides-Admin nicht den gleichen geheimen Schlüssel wie der Wahlsekretär und der Wahlauditor erzeugen kann, unterscheidet sich die grafische Darstellung auf den Bildschrimen von Wahlsekretär und Wahlauditor 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 Stimmzettel (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 einen Stimmzettel zur Entschlüsselung an den Wahlsekretär. Dieser entschlüsselt den Stimmzettel. Da es nur einen Stimmzettel gibt, kann die Reihenfolge nicht geändert werden und der Admin erfährt, wie dieser eine Stimmzettel unverschlüsselt aussieht.
Allerdings kann der Admin anschließend die anderen Stimmzettel nicht mehr entschlüsseln, da der Wahlsekretär für die gleiche poll_id immer die gleichen Daten zurückliefert. Der OpenSlides-Admin kann auch keine andere poll_id verwenden, da der Wahlsekretär einen Stimmzettel nur entschlüsselt, wenn die poll_id im verschlüsselten Stimmzettel mit der angefragten poll_id identisch ist.
Der Angriff kann nicht dadurch abgewehrt werden, dass der Wahlsekretär die Stimmen nur dann entschlüsselt, wenn mindestens N Stimmzettel übergeben werden. Denn der OpenSlides-Admin kann ohne Probleme N Fake-Stimmzettel erstellen. Wenn er die Fake-Stimmzettel und den einen User-Stimmzettel übersendet und entschlüsseln lässt, dann kann er in der Rückgabeliste ohne Probleme die Fake-Stimmzettel erkennen und aussortieren. So erhält er den User-Stimmzettel.
Eine Verteidigung gegen diesen Angriff existiert noch nicht.
Der OpenSlides-Admin könnte manipulierte Daten an den Wahlauditor schicken, nachdem er die richtigen Daten vom Wahlsekretär erhalten hat. Da es aufwendig wäre dem Wahlauditor mitzuteilen, wer der echte Wahlsekretär ist, kann der Wahlauditor die Signatur des Wahlsekretärs nicht sicher überprüfen. Da jedoch der Wahlauditor für die selbe poll_id immer die selben Daten zurückgibt, können zu einer poll_id nur einmal manipulierte Daten an den Wahlauditor 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 seinen Stimmzettel abgibt.
Da jedoch die verschlüsselten Stimmzettel 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 Stimmzettel einem entschlüsselten Stimmzettel zuzuordnen.
Wenn jedoch der Netzwerk-Admin gleichzeitig der Wahlsekretär oder der Wahlauditor ist, dann könnte er durch eine Timing-Analyse herausfinden, in welcher Reihenfolge die Nutzer abgestimmt haben. Würde OpenSlides die gespeicherten Stimmzettel in genau dieser Reihenfolge an den Wahlsekretär oder den Wahlauditor schicken, so könnten diese zuordnen, welche entschlüsselten Stimmzettel zu welchem Nutzer gehört.
Aus diesem Grund ist es wichtig, dass OpenSlides die Stimmzettel nicht in der Reihenfolge an die beiden Wahlhelfer sendet, in welcher er sie erhalten hat. Es muss nicht unbedingt eine zufällige Reihenfolge sein. Möglich ist auch eine Sortierung nach User-ID. Die Reihenfolge darf nur nicht abhängig vom Eingang der Nachricht bei OpenSlides 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.
Wahlsekretär, Wahlauditor sind WebAssembly-Module. Diese exportieren die folgenden Funktionen:
Initialisiert die Daten der beiden Wahlhelfer. Insbesondere wird ein neuer geheimer Schlüssel erzeugt.
Ist die Komponente 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 Stimmzettel.
Gibt die signierten Wahlunterlagen (Hash-Liste und entschlüsselte Stimmzettel).
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 Stimmzettel sowie die signierten Wahlunterlagen des Wahlsekretärs.
Gibt die Wahlunterlagen, signiert von Wahlhelfer und Wahlauditor 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 Wahlsekretärs oder des Wahlauditors und gibt eine SVG-Grafik zurück, welche den Schlüssel darstellt.
Erwartet die öffentlichen Schlüssel des Wahlsekretärs und des Wahlauditors sowie die poll_id und die zu verschlüsselnden Stimmzettel.
Gibt die verschlüsselten Stimmzettel zurück.
Erwartet die öffentlichen Schlüssel des Wahlsekretärs und des Wahlauditors sowie die Rückgabedaten des Wahlauditors. Optional kann der (eigene) verschlüsselte Stimmzettel übergeben werden.
Gibt alle entschlüsselten Stimmzettel zurück sowie die Anzahl der abgegeben Stimmzettel. Die Anzahl der entschlüsselten Stimmzettel kann unterschiedlich sein, wenn ungültig verschlüsselte Stimmzettel abgegeben wurden oder Stimmzettel 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 Stimmzettel nicht in der Hash-Liste ist.
Folgende kryptografischen Operationen sind erforderlich:
Bei den asymmetrischen Schlüsseln von Wahlsekretär und Wahlauditor handelt es sich bei der aktuellen Implementierung 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 Wahlsekretär und Wahlauditor 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 Stimmzettel als auch die entschlüsselten Stimmzettel. Es darf ihm nicht möglich sein durch erneutes verschlüsseln der Stimmzettel den Klartext eines Stimmzettels den verschlüsselten Stimmzettel 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 Stimmzettel passiert in einem Durchgang beim Wahlsekretär und beim Wahlauditor. 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 Stimmzettel müssen sowohl für den Wahlsekretär als auch für den Wahlauditor verschlüsselt werden. Es ist möglichst auszuschließen, dass ein Stimmberechtigter unterschiedliche Daten für den Wahlsekretär und den Wahlauditor verschlüsselt. Dies würde erst bei der Aktion des Wahlauditor auffallen, der dies nicht von einen Angriff des Wahlsekretär 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 Wahlsekretär und des Wahlauditors jeweils ein "shared secred" erzeugt.
- Aus den beiden "shared secreds" werden für den Wahlsekretär und den Wahlauditor 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 Wahlsekretär und für den Wahlauditor gemeinsam verschlüsselt. Es ist dem Stimmberechtigten 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