Nachdem bei den öffentlichen Tests der e-Voting-Lösung von Scytl/Post im Frühjahr 2019 eklatante Sicherheitsprobleme festgestellt wurden und der Bund vorerst auf die Freigabe von e-Voting verzichtete, wurde es in der Öffentlichkeit ruhig am Thema. Hinter den Kulissen gingen die Arbeiten aber sowohl bei der Post (welche in e-Voting offenbar weiterhin ein interessantes und wirtschaftlich lohnenswertes Produkt sieht) wie auch beim Bund (welcher den rechtlichen Rahmen neu abstecken will) weiter.

Vor einigen Tagen hat der Bundesrat diesen neuen Rahmen bekanntgegeben und wird die zugehörigen Verordnungen per 1.7.2022 in Kraft setzen. Da das e-Voting-System der Post selbst noch in Entwicklung ist und anschliessend erneut einem öffentlichen Test unterzogen werden muss, werden interessierte Kantone selbst dann frühestens 2023 e-Voting anbieten können falls sie zeitlich noch dieses Jahr schaffen, ein erneutes Gesuch bei der Bundeskanzlei zu stellen. Andererseits haben in den letzten Monaten bereits externe Tests stattgefunden, es st daher ein guter Zeitpunkt für eine Momentaufnahme zum Stand der Dinge.

Eines vorneweg: wir fokussieren uns im folgenden auf die technischen Aspekte. Zur generellen Einschätzung der Sinnhaftigkeit und der grundsätzlichen Vertrauensfrage lohnt sich das Reinhören in die ersten 20 Minuten der neunten Folge des Netzpodcasts der Digitalen Gesellschaft.

Was hat sich bei der Software getan

Für den neuen Anlauf hat die Post, wie in den neuen Verordnungen gefordert, verstärkt auf Offenheit und Transparenz gesetzt. Der Sourcecode sowohl für das eVoting-System an sich wie auch für eine (technisch) unabhängige Verifikationssoftware wurden ebenso auf Gitlab veröffentlicht (allerdings ohne eigentliche Open Source-Lizenz) wie die relevante Projektdokumentation und die Beschreibung der kryptografischen Protokolle. Der Zugang zum eVoting-Sourcecode steht so allen offen, und im Vergleich zum ersten Anlauf in 2019 ist auch das Einreichen von Befunden deutlich einfacher geworden.

Zusätzlich hat die Bundeskanzlei im Sommer 2021 mehrere Expertengruppen (unter anderem die Gruppe rund um Olivier Pereira und Vanessa Teague welche bereits in 2019 kritische Schwachstellen identifiziert hatten) beauftragt, das eVoting-System gezielt zu untersuchen. Konkret untersucht wurden dabei

1. das kryptografische Protokoll des Systems
2. die zum Einsatz gelangende Software
3. die Infrastruktur und den Betrieb bei der Post
4. Intrusionstest

Für die Klassifizierung der Befunde wurden vier Schweregrade definiert:

• Kritisch: Ausnutzung der Schwachstelle gefährdet die Applikation, das System oder den Stimmabgabeprozess schwerwiegend. Die Ausnutzung ist einfach möglich.
• Hoch: Ausnutzung der Schwachstelle gefährdet möglicherweise die Applikation, das System oder den Stimmabgabeprozess. Die Ausnutzung ist schwer möglich.
• Mittel: Die Ausnutzung der Schwachstelle ermöglicht beschränkten, unkritischen Zugriff. Für die Ausnutzung der Schwachstelle benötigt der Angreifer besondere Rechte, muss Social Engineering anwenden oder sich in einem lokalen Netzwerk befinden. Die Ausnutzung ist sehr schwer möglich.
• Tief: Ausnutzung der Schwachstelle hat sehr geringe Auswirkungen auf die Applikation, das System oder den Stimmabgabeprozess. Schwachstellen, die keine direkten Auswirkungen auf die Applikation, das System oder den Stimmabgabeprozess haben, fallen ebenfalls unter diese Kategorie (z. B. Tippfehler in den GitLab Markdowns).

Der Fokus lag aufgrund des Projektstand primär auf den Themen 1 und 2, für 3 und 4 machen vollständige Prüfungen erst Sinn wenn das eVoting-Produkt eine einsatztaugliche Reife hat. Die Prüfberichte liegen seit einigen Monaten vor (ebenso die Antworten der Post), wir haben (ohne Anspruch auf Vollständigkeit) einige interessante Punkte herausgepickt.

Klassifizierte Schwachstellen

Das Positive vorneweg: Es wurden in den Untersuchungen keine als kritisch einzustufenden Schwachstellen gefunden (als kritisch werden Schwachstellen bezeichnet deren Ausnutzung die Applikation, das System oder den Stimmabgabeprozess schwerwiegend gefährdet, und deren Ausnutzung einfach möglich ist). Dies natürlich unter dem Vorbehalt, dass keine noch so umfassende Überprüfung garantieren kann, dass alle Schwachstellen gefunden werden und dass grundsätzlich jede zukünftige Software-Änderung eine kritische Schwäche bewirken kann.

Fündig wurden die Experten allerdings bezüglich nicht-kritischen Schwachstellen (also Schwachstellen, die sich an sich nicht so einfach ausnutzen lassen und/oder über die keine Manipulation des Votings möglich ist). Die Post hat vier davon als hoch eingestuft. Und die sind nicht nur als Schwachstelle an sich interessant, sondern stehen geradezu beispielhaft für die verschiedenen Problemklassen welche die Entwicklung grosser IT-Systeme im allgemeinen und sicherheitskritischen Systemen wie eVoting im besonderen so anspruchsvoll machen. Wir schauen uns diese Befunde im Folgenden an (kursiv zum Einstieg jeweils das konkret gefundene Problem) und ordnen ein.

1. Ungenügende Validierung von Inputdaten

Zur besseren Absicherung des Systems sind einige der zur Konfiguration einer Abstimmung verwendeten Rechner nicht mit dem Internet verbunden (offline), der Datenaustausch mit den am Internet angeschlossenen Rechnern erfolgt über USB-Sticks. Aufgrund einer ungenügenden Validierung der von solchen USB-Sticks geladenen Daten (konkret wurden alle auf dem USB-Stick vorhandenen Dateien auf den offline-Rechner geladen auch wenn sie für die Konfiguration gar nicht relevant waren) wäre es einem Angreifer möglich, Schadsoftware auf die Offline-Rechner zu laden und so die Konfiguration einer Abstimmung anzugreifen bzw. zu beeinflussen.

Grundsätzlich geht es hier um ungenügende/fehlende Prüfung von Input-Daten, also um einen klassischen Entwicklungsfehler, über den wohl schon jede Entwicklerin und jeder Anwender schon mal gestolpert ist. Und wenn sich nachfolgende Programm-Teile auf die Korrektheit des Inputs verlassen, dann entsteht für eine Angreiferin durch die fehlende Verifikation die Möglichkeit, diese nachfolgenden Teile anzugreifen (ein breiter bekanntes Beispiel ist eine SQL-Injection bei Texteingaben auf einem Webformular).

Relevant ist hier insbesondere, dass jeder ins System einfliessende Datensatz (egal ob er von einem Menschen, einem Datenträger oder einem anderen System stammt) verifiziert werden muss um solche Fehler zu vermeiden. Und dass eine übersehene Eingabemöglichkeit dazu führen kann, dass das System angreifbar wird.

Diese Problematik wird auch im Bericht von Aleksander Essex, einem der von der Bundeskanzlei beauftragten unabhängigen Experten, thematisiert.

Aus Sicherheitsüberlegungen heraus müsste jeder Algorithmus (bzw. jede Komponente) jeden Input selbst validieren und dürfte sich nicht darauf verlassen, dass die vorgelagerte Komponente dies bereits erledigt hat. In der vorliegenden eVoting-Implementierung verzichtet die Post teilweise auf diese Validierung, offenbar aus Effizienzgründen. Ohne konkrete Informationen über den Rechenaufwand einer konsequenten Validierung lässt sich nicht abschätzen ob diese Optimierung zweckdienlich ist (ob das Resultat am Abstimmsonntag schon um 14 oder erst um 15 Uhr vorliegt, wäre ja unerheblich). Die Einschätzung des Experten bezüglich der Fähigkeit der IT-Community wie auch der Post, auf die konsequente Validierung verzichten zu können, stimmt jedenfalls nicht optimistisch.

Zum selben Themenkomplex gehören Annahmen über die Qualität von Zufallszahlen (welche für die Verschlüsselungsprotokolle eine zentrale Rolle spielen). Mathematisch gesehen ist das Generieren von Zufallszahlen ja alles andere als trivial, und für Verschlüsselungsalgorithmen brauchbare Zufallszahlen-Algorithmen müssen eine ganze Reihe von Kriterien erfüllen um eben zu vermeiden dass ihre Ergebnisse (also die Zufallszahlen) nicht voraussehbar sind und die Verschlüsselung dadurch geschwächt wird. Um so heikler also dass das eVoting-System gleich mehrfach allzu vertrauensselig mit dem Generieren von Zufallszahlen umgeht, einmal im eVoting-Server, einmal im Browser der Stimmbürgerin.

• Server-seitig verlässt sich das eVoting-System beim Generieren von Zufallszahlen auf die entsprechende Java-Funktion, diese jedoch wird mit einem Startwert initialisiert, der von der Konfiguration des Rechners abhängig ist. Ob dieser Startwert dazu geeignet ist, den für ein sicheres eVoting notwendige Level an Zufälligkeit zu erreichen, wird nicht sichergestellt, hierzu verlässt man sich ungeprüft auf die Konfiguration des Rechners.
• Im Browser der Stimmbürgerin benötigte Zufallszahlen werden mit der entsprechenden JavaScript-Funktion erzeugt, diese ist direkt im Browser implementiert. Die JavaScript-Spezifikation lässt aber zu, dass solche Funktionen auf relativ einfache Weise durch selbstgeschriebene mit im konkreten Fall schlechten Zufallszahlen ersetzt werden können. Dies könnte unter Umständen für einen Angriff ausgenutzt werden. Gerade gegen Manipulationen auf dem unsicheren Endgerät (also dem Browser der Stimmbürgerin) sollte ein eVoting-System aber resistent sein. Sich gerade hier auf eine Funktion zu verlassen welche leicht manipulierbar ist, stellt sicher nicht die beste Designentscheidung dar…

2. Kreuzabhängigkeiten

Eine Angreiferin, welche Kontrolle sowohl über den Rechner des Abstimmenden, über den eVoting-Server wie auch eines der zur Verifikation verwendeten Systeme erlangen kann, ist in der Lage, eine individuelle Stimmabgabe (d.h. eine Einzelstimme) zu manipulieren ohne dass dies der Abstimmende merken würde.

Hinter diesem Problem liegt die Fragestellung, wie sich die für das eVoting verwendeten Systeme gegenseitig vertrauen und wie dieses Vertrauen technisch auch über mehrere Komponeten hinweg sichergestellt wird. Etwas vereinfacht gesagt erzählt Bob Charlie, dass Alice schlecht über ihn (Charlie) rede; und Charlie glaubt Bob dies ohne bei Alice nachzufragen was genau sie meine. Charlie verlässt sich also darauf, dass Bob die Wahrheit sagt ohne dies zu verifizieren. Mitbeteiligt an der Problematik war die oben bereits beschriebene unvollständige Validierung von (Input-)Daten.

Hier zeigt sich die Gesamt-Komplexität eines grossen IT-Systems. Es reicht nicht aus, dass die einzelnen Komponenten korrekt funktionieren, auch die Datenflüsse und Sicherheitsprotokolle müssen komponenten-übergreifend korrekt sein. Und wie so oft bei grössen Systemen steigt die Komplexität mit jeder weiteren Komponente überproportional an.

3. Unvollständige Spezifikationen welche kritische Aspekte der Implementierung überlassen

Falls ein Angreifer Teile der Server-Infrastruktur der Post wie auch auch die vom jeweiligen Kanton betreibene Offline-Komponente am Ende der Verifikationskette unter Kontrolle bringen kann, wäre er unter Umständen in der Lage, das Stimmgeheimnis mehrerer Stimmen zu brechen.

Diese Angriffsmöglichkeit wurde auf Basis der Dokumentation entdeckt (also nicht direkt im Code), sie ist also Teil der verwendeten Sicherheitsarchitektur. Das Interessante hier ist der Kontext. Aus der Beschreibung des Issues:

Note that privacy depends on implementation details / practical decisions, that are not specified in the specification document.

https://gitlab.com/swisspost-evoting/e-voting/e-voting-documentation/-/issues/11

Mit anderen Worten: Ob die Schwäche effektiv besteht bzw. ausgenutzt werden kann, hängt von der konkreten Implementierung ab. Die Angaben in der Spezifikation des Protokolls alleine reichen nicht aus, um sicherzustellen, dass die Implementierung korrekt sein wird. Zur Behebung muss die Spezifikation an sich so erweitert werden, dass die Implementierung klar vorgegeben wird.

Der Knackpunkt hierbei ist dann allerdings nicht nur die Umsetzung der notwendigen Anpassungen sondern auch deren Auswirkungen auf andere Komponenten (wie in der zweiten Schwachstelle oben ausgeführt). Dies wiederum bedeutet, dass die Sicherheit des Gesamtsystems anschliessend sowohl theoretisch (auf Basis der Dokumente) wie auch praktisch (im implementierten System) erneut untersucht werden muss. Die mit diesem „erneut untersuchten“ verbundenen Probleme werden wir bei der vierten als noch eingestuften Schwachstelle noch genauer betrachten.

Zur Problematik der Lücken in den Spezifikationen finden sich auch in den Expertenberichten entsprechende Punkte.

Die Verifier Specification beschreibt, wie die Ergebnisse des eVotings nachvollzogen werden können. Damit soll es dritten ermöglicht werden, die Korrektheit des eVotings quasi von aussen zu verifizieren. Naheliegenderweise ist dies nicht wirklich möglich, wenn die Spezifikation selbst unvollständig oder ungenau ist.

Die Beschreibung der Protokolle welche den sicheren Datenaustausch zwischen den eVoting-Komponenten sicherstellen, ist also unvollständig und lässt Raum für Interpretation offen. Dies deckt sich ziemlich der eingangs beschriebenen Schwachstelle wo eine „falsche“ Interpretation dann eben zu Lücken führen kann.

Die teilweise unvollständige Spezifikation wirft daher zumindest bei einzelnen Experten die Frage auf, ob das spezifizierte System überhaupt grundsätzlich als sicher bewiesen werden kann.

4. Lokale Verbesserungen können Gesamtsicherheit reduzieren

Bei der Stimmabgabe wird der Stimmbürgerin für jede Abstimmfrage ein individueller Bestätigungscode angezeigt den sie mit dem Vordruck in den individuellen Papierunterlagen vergleichen kann um sicherzugehen dass ihre Stimme korrekt übermittelt wird. Aufgrund einer unvollständigen Verschlüsselung im Datenaustausch zwischen dem Drucksystem (wo die Unterlagen erstellt werden) und dem eVoting-Server (wo der Bestätigungscode angezeigt wird) kann ein Angreifer unter Umständen die Codes erraten und so der Stimmbürgerin eine korrekte Stimmabgabe vorgaukeln (also der Stimmbürgerin bestätigen dass sie „Ja“ gestimmt hat obwohl der eVoting-Servier ihre Stimme als „Nein“ registiert hat.

Ein wenig (vereinfachter) Kontext vorneweg: Für die elektronische Stimmabgabe erhält jeder Stimmbürger individuelle Verifikationscodes für ein Ja und für ein Nein. Wenn er also ein Ja eingibt, wird ihm der Code für Ja anschliessend vom eVoting-Server zur Kontrolle angezeigt und er kann ihn mit dem auf dem Stimmunterlagen Code vergleichen. Sind beide gleich, wurde seine Stimme auf dem Weg ins eVoting-System nicht verfälscht.

Erstellt/berechnet werden diese Codes im Drucksystem beim Erstellen der Abstimmungsunterlagen, das eVoting-System erhält anschliessend eine Kopie davon um sie nach der Stimmabgabe anzeigen zu können. Entsprechend muss die Datenübermittlung zwischen Drucksystem und eVoting-Server sicher sein, um ein Auslesen der Codes durch potentielle Angreifer zu verunmöglichen. Die konkrete Lücke hätte im beschriebenen Fall zwar nicht das Ausleben erlaubt aber die Menge der möglichen Codes deutlich reduziert (und es so einfacher gemacht, sie allenfalls zu erraten).

Auslöser des ganzen ist interessanterweise eine Software-Änderung (deren Grund in den Unterlagen nicht aufgeführt ist) in der Herleitung des für die Kommunikation zwischen Drucksystem und eVoting-Servers verwendeten Schlüssels. Diese Änderung führte also dazu dass der eVoting-Server selbst (bzw. ein dort eingedrungener Angreifer) die generierten Codes unter Umständen erraten könnte.

Die Problematik wird durch den Umstand verschärft, dass das neue eVoting-System noch nicht wirklich fertig ist.

Sowohl die Sicherheitsverfahren wie auch die Implementierung selber sind noch „work in progress“, eine abschliessende Aussage können die in den letzten Monaten vorgenommenen Tests also noch gar nicht machen. Dies impliziert auch, dass vor einem effektivem Einsatz erneut Reviews notwendig sein werden.

Weitere offene Themen

In einigen der Expertenberichten werden weitere Themen angesprochen, die zwar nicht direkt mit der eigentlichen Implementierung des eVoting-Systems zu tun haben aber sehr wohl mit der generellen Einführung von eVoting.

Im Bericht der Berner Fachhochschule werden die Stimmenthaltungen angesprochen, bzw. konkreter die Frage aufgeworfen wie ein nicht vom seinem Stimmrecht Gebrauch machender Stimmbürger nach der Abstimmung verifizieren kann, dass niemand anderes in seinem Namen abgestimmt hat. Die Möglichkeit zur Verifikation an sich ist Teil der Verordnungen der Bundeskanzlei, das eVoting-System an sich bietet dazu aber apriori keine Lösung an. Die Experten schlagen vor, analog zu den Kontrol-Codes für ein Ja oder Nein auch solche für „Stimmenthaltung“ zu generieren und diese allen Stimmbürgern als Teil der Unterlagen zuzustellen. Zur einfachen Kontrolle könnten dann all (vom Prinzip her anonymen) bei der Abstimmung verwendeten Codes auf einer kantonalen Webseite veröffentlicht werden.

Auf einer völlig anderen Ebene gibt es Kritik am Software-Entwicklungs- und -Lifecycle-Prozess.

Für die Entwicklung sicherheitskritischer Software ist es elementar dass entsprechende Überlegungen zur Sicherheit in jedem Schritt der Entwicklung angewandt und nicht an den Schluss des Prozesses verlagert werden. Entsprechende Massnahmen scheinen bei der Post noch nicht vollständig umgesetzt/eingeführt zu sein, was das Risiko steigert dass rein aus Versehen sicherheitsrelevante Fehlentscheide getroffen werden die schlussendlich unentdeckt bleiben.

Versuch einer Einordnung

Wie man dem obigen leicht entnehmen kann, und was auch in verschiedenen Expertenberichten festgehalten wurde: das neue eVoting-System der Post ist noch nicht fertig.

Kurz gesagt wurde das sich in Entwicklung befindliche System einem ersten Review unterzogen, jetzt ist zuerst einmal die Post als Entwickler gefordert um die Erkenntnisse umzusetzen und das System in eine einsetzbare Form zu bringen. Basierend auf dieser werden dann erneut Reviews notwendig sein (welche natürlich erneut kritische Erkenntnisse ergeben können welche vor dem Einsatz in einem der Kantone behoben werden müssen). Oder mit anderen Worten: Ob ein erster Einsatz wie erhofft in 2023 stattfinden kann, steht momentan noch ziemlich in den Sternen.

Diese Annahme wird dadurch verstärkt, dass in verschiedenen Berichten erwähnt wird, dass in einer frühen Phase gemeldete Findings auch Monate später noch nicht addressiert waren. Dies muss nicht unbedingt heissen dass sie unter den Tisch gefallen sind sondern kann schlicht das Ergebnis einer Arbeitspriorisierung im Entwicklungsteam sein. Es ist aber ein Indikator dafür dass noch viel Arbeit ansteht bis das System einsatzreif ist.

Insgesamt ist auch der neue Anlauf der Post, ein eVoting-System für die Schweizer Kantone bereitzustellen, ein komplexes Unterfangen. An der Problematik dass wie oben beschrieben kleine Schwächen ausreichen können um das Vertrauen ins Ergebnis erschütterbar zu machen, hat sich gegenüber dem letzten Versuch in 2019 nichts geändert. Ebenso dürfte es eine kleine Gruppe von Menschen sein, welche das notwendige mathematische und technische Wissen haben um aufgrund der Sicherheitsprotokolle und Implementierung das System effektiv als vertrauenswürdig zu verstehen, die breite Bevölkerung muss sich auf deren mathematisch/wissenschaftlich gestützten Aussagen verlassen. Und wie die zwei bisherigen Corona-Jahre gezeigt haben, ist das Vertrauen in die Wissenschaft durch gezielte Desinformation recht einfach zu erschüttern. Auch der Umstand, dass sich Bund und Kantone in letzter Zeit mit Digitalisierungsprojekten eher schwer tun, ist dem Vertrauen abträglich.

Durchzogene Aussichten bezüglich Vertrauenswürdigkeit auf der einen Seite, und vermutlich hohe Kosten für Fertigstellung, Betrieb und fortlaufende Sicherheitsreviews auf der anderen: Wir sind gespannt, ob sich in den nächsten zwei Jahren Kantone finden welche sich wieder ans Thema eVoting wagen wollen.

Vielleicht wird es einfach drauf rauslaufen, dass einzelne Kantone eVoting trotz Sicherheitsbedenken einsetzen werden um schlicht davon abzulenken, dass das ganze unterdessen eine ordentliche Stange Geld gekostet hat (Betriebswirtschaftler würden von Sunken Cost sprechen).