Antworten auf technische Fragen zu den im Schweizer Fernsehen behaupteten Schwachstellen im Genfer E-Voting System
Ein technischer Anhang zum Hauptartikel auf SocietyByte.swiss.
Wie funktioniert der demonstrierte Angriff technisch?
Das Fernsehen zeigte einen erfolgreichen DNS Cache Poisoning Angriff. Dieser in einem lokalen Setting triviale Angriff nützt eine systembedingte Schwachstelle im DNS System des Internets aus. Durch die Manipulation von DNS Antworten wird ein Client, der Browser im PC eines Stimmbürgers oder einer Stimmbürgerin, anstatt auf den E-Voting Server des Kantons Genf auf einen präparierten Web-Server des Angreifers umgeleitet, wo eine Kopie der Webseite des originalen E-Voting Servers dargestellt wird.
Normalerweise müsste der Browser des Opfers den Angriffes mit einer Sicherheitswarnung reagieren (“invalid security certificate”). Allerdings hielt sich das supponierte Opfer des Angriffes nicht an die URL in den Stimmunterlagen und gab anstatt dem abgedruckten “https://www.evote-ch.ch" nur die verkürzte Variante ein: “www.evote-ch.ch". Bei einem erstmaligen Aufruf der Genfer E-Voting URL ergänzt der Browser das zu “http://www.evote-ch.ch" und setzt die Anfrage unverschlüsselt ab. Dies hat zur Folge, dass sich der präparierte Web-Server des Angreifers nicht mit einem signierten Zertifikat ausweisen muss und der Angriff ohne Sicherheitswarnung von statten geht.
Der Aufruf des Opfers wurde in der Aufzeichnung des Fernsehen mit einer Weiterleitung auf die Adresse “https://evote-net.ch" beantwortet. Dahinter verbirgt sich erneut der Server des Angreifers. Dieses Mal ist er aber in Besitz eines Sicherheitszertifikats für diese von ihm kontrollierte Domäne, was ihm erlaubt, den Anschein zu erwecken, es handle sich um eine sauber verschlüsselte Verbindung mit einem authorisierten Server. In der Adresszeile des Browsers prangte aber auch für Laien gut sichtbar ein unterschiedlich dargestelltes Zertifikat und die präparierte URL.
Wie könnte man nun das Stimmgeheimnis brechen?
Volker Birk demonstrierte nur die Umleitung des Browsers, nicht aber den Bruch des Stimmgeheimnisses. Er hat aber recht, dass es auf dieser Basis mit mehr oder weniger Aufwand möglich wäre, das Stimmgeheimnis zu brechen.
Dafür stehen mehrere Varianten zur Verfügung. Welche Methode gewählt wird, ist aber nicht wichtig. Denn es besteht kein Zweifel, dass der Angreifer so die Stimme eines einzelnen Opfers mitlesen könnte und es ist auch völlig klar, dass es nur mittelmässige Kenntnisse braucht, um diesen Angriff beim zur Zeit in Genf verwendeten System auf ein einzelnes Opfer von A bis Z durchzuführen.
Wie könnte man die Stimme manipulieren?
Die Stimme nicht nur mitzulesen, sondern zu manipulieren, wird deutlich schwieriger. Die Schweizer E-Voting Systeme setzen auf die sogenannte individuelle Verifizierbarkeit: Nachdem man seine Stimme abgegeben hat, retourniert der Abstimmungsserver einen individuellen Zahlencode. Dieser persönliche Code ist auch in den Abstimmungsunterlagen für jede einzelne Wahlmöglichkeit abgedruckt. Stimmt man also für eine bestimmte Vorlage «Nein», dann muss der Antwort-Code der Zahl entsprechen, die bei der Nein-Stimme in den Unterlagen abgedruckt ist. Stimmt der Code nicht überein, dann ist das ein Beweis dafür, dass die Stimme nicht so gespeichert wurde, wie man sie abgegeben hat. In diesem Fall sollte man unbedingt mit den Behörden Kontakt aufnehmen.
Das Prinzip, das sich hinter den Prüfcodes verbirgt, ist simpel. Der Prüfcode wird beim Eingang der Stimme in die Wahlurne berechnet. Wenn die Stimme eines Stimmbürger oder einer Stimmbürgerin durch einen Angreifer manipuliert wurde, dann kann dieser Code nicht stimmen. Während der Stimmabgabe kann einzig die offizielle elektronische Wahlurne diesen Code für einen bestimmten Stimmrechtsausweis berechnen und der Code stimmt nur dann mit den Unterlagen überein, wenn auch die korrekte Stimme abgespeichert wurde. Ein «Ja» anstelle eines «Nein» hätte unweigerlich einen anderen Code zur Folge und der Betrug würde auffliegen: Korrekte Prüfcodes kann dank starker Kryptographie nur das echte E-Voting-System retournieren.
Dieser Mechanismus ist einer der zentralen Vorteile der elektronischen Stimmabgabe gegenüber dem brieflichen Abstimmen. Denn die individuelle Verifizierbarkeit garantiert, dass eine Stimme ohne Manipulation in die Wahlurne gelangt ist. Sie hebt das Abstimmen von zu Hause aus damit auf eine ähnliche Stufe wie das Stimmen an der Urne. Ein entsprechender Mechanismus fehlt beim Abstimmen per Brief offensichtlich.
Wie kann der Angreifer die Überprüfung der Codes verhindern? Der Angreifer könnte dank der erfolgreichen Umleitung des Opfers die Anzeige dieser Prüfcodes verhindern. Das heisst die Aufforderung zur Eingabe der Prüfcodes fällt weg und der Stimmbürger kann die Kontrolle nicht durchführen. Dieser Schabernack mag ein Einzelfällen funktionieren, aber wie mit den gefälschten Briefkasten würde es in der Breite sehr schnell auffliegen. Das heisst, irgend jemand wird die Prüfcodes vermissen und sich beim Kanton melden, worauf eine Untersuchung startet.
Das bedeutet, dass Manipulation der Stimmen skaliert noch einmal deutlich schlechter als der Bruch des Stimmgeheimnisses, da hier das elektronische System der individuellen Verifizierbarkeit einer Manipulation sehr schnell Limiten setzt.
Welche Schutzmassnahmen hat der Kanton Genf ergriffen?
Einer der beiden SRF Journalisten publizierte am 4. November einen privaten Blogpost in dem er die birksche Behauptung aufgriff, der Kanton Genf habe keinerlei Massnahmen zur Verhindung dieses seit Jahrzehnten bekannten Angriffes unternommen.
Er unterstellte dem Kanton drei wesentliche Unterlassungen:
- Fehlen von DNS SEC
- Fehlen von HSTS
- Fehlen von permanenten Weiterleitungen (HTTP Status Code 301)
Zentral ist dabei der sogenannte HTTP Strict Transport Security (HSTS) Standard. Die Behauptung lautet, das Genfer E-Voting hätte diesen Standard zu Beginn der Recherche durch das Fernsehen nicht unterstützt. Der Fernsehmitarbeiter publizierte am 5. November ein Update zu diesem Artikel. Hier erwähnt er, er sei von einem namentlich erwähnten Techniker des Kantons Genf kontaktiert worden. Der Mitarbeiter des Kantons Genf bestätige, dass das E-Voting System HSTS seit 2016 unterstütze. Im Blog Post steht nun — Stand 20. November — Aussage gegen Aussage. Überhaupt machte der Journalist hier vieles richtig. Er stand auch hinter dem Teaser, den das Fernsehen am frühen Abend des 2. Novembers publizierte. Dieser Teaser präsentierte sich denn auch viel differenzierter als die späteren Newssendungen und bemühte sich um Einordnung des gezeigten Angriffs.
HSTS kommt im Zusammenhang mit dem demonstrierten Angriff eine grosse Bedeutung zu. Der Standard wurde etabliert, um just genau diesen Angriff auf einzelne Benutzer im WWW zu verhindern. Würde der Kanton Genf HSTS nicht unterstützen, wäre das ein grosses Versäumnis.
Der Standard erlaubt es einem Webserver einem Browser mitzuteilen, dass er zukünftig nur noch verschlüsselt angesprochen werden möchte. Das hat unweigerlich zur Folge, dass der Server sich zukünftig mit einem signierten Sicherheitszertifikat ausweisen muss, was sich durch einen Angreifer nur sehr schwer umgehen liesse.
Stellen wir uns vor, der Browser des Opfers sei dank HSTS über die gewünschte Verschlüsselung der Verbindung im Bilde. Würde der Angreifer den beschriebenen Angriff nun in die Tat umsetzen, so würde der Browser des Opfers sofort mit einer sehr deutlichen Sicherheitswarnung reagieren und sich weigern die E-Voting Seite aufzurufen. Das würde sehr schnell zu einem Telefonanruf an die Betrieber des E-Voting Systems führen, da ein Abstimmen nicht mehr möglich ist.
Die Angreifer haben also die schwierige Aufgabe vor sich, nur diejenigen Opfer angreifen zu können, die noch nie elektronisch abgestimmt haben. Bei allen anderen gehen sofort die Alarmsirenen noch.
Neben diesem Standard beschreibt der Journalist auch, dass der Server des Kantons zur Zeit der Recherche sogenannte Redirects (Weiterleitungen des Browsers) mit einem sub-optimalen Status-Code durchgeführt habe. Dieses Verhalten habe sich dann plötzlich geändert. Auch hier steht die Aussage des Genfer Technikers im Weg, der das Gegenteil behauptet.
Was die Sicherheit betrifft, sind diese Status Codes eher ein Nebengeleise. Sie spielen nur dann eine Rolle, wenn HSTS nicht im Spiel ist. Darüber hinaus empfehlen die Betreiber der Schweizer E-Voting Systeme das Löschen des Browser Caches (das macht die vorteilhafte Wirkung des qualitativ besseren Status-Codes zu Nichte) und auch die Umsetzung des Redirects durch die verschiedenen Browserhersteller war zumindest früher nicht in jedem Fall korrekt, wobei sich das gebessert haben mag.
Wir könnten dieses Thema also eigentlich beiseite schieben, aber da hier erneut eine gewichtige Aussage von CCC und Fernsehen gegen die Aussage des Kantons Genf, respektive ihres Technikers steht, verdient es unsere Beachtung. Das Thema wird also weiter unten noch einmal aufgegriffen.
Weshalb funktioniert der Angriff denn überhaupt beim ersten Mal?
HSTS wartet darauf, dass der Browser sich zum ersten Mal verbindet und es antwortet dann mit dem Hinweis, dass eine Verschlüsselung unterstützt wird und dass zukünftig nur noch verschlüsselt kommuniziert werden soll.
Das heisst, beim erstmaligen Verbindung ist der Browser dann durch Cache Poisoning Angriffe verwundbar, wenn der Stimmbürger die URL verkürzt abtippt. Bei folgenden Aufrufen — in der nächsten Wahlperiode — aber nicht mehr.
Dieses Verhalten ist im RFC Standard 6797 beschrieben und wird vom Kanton Genf als Massnahme gegen Cache Poisoning Angriffe umgesetzt.
Um auch Angriffe auf erstmalige Anfragen zu vereiteln, existiert eine inoffizielle Erweiterung für den Standard, die sich HSTS-Preload nennt. Diese Erweiterung funktioniert über eine Liste, die gemeinsam mit der Browser-Software ausgeliefert und regelmässig aktualisiert wird.
Um Eingang auf die Liste zu finden, muss man die eigene HSTS Antwort nach einem bestimmten Muster abfassen, das Schlüsselwort “preload” in der Antwort einschliessen und danach die eigene Domäne auf der URL https://hstspreload.org/ für die Preload-Liste registrieren. Dies hat der Kanton Genf bis dato unterlassen.
Man kann über die Gründe hiezu nur spekulieren. Am wahrscheinlichsten sind die folgenden:
- Die Preload-Liste ist eine inoffizielle Erweiterung ausserhalb der RFC Standards. Sie besitzt deshalb nicht denselben Stellenwert, wie der Rest des Standards.
- Wer auf der Liste eingetragen ist, hat praktisch keine Möglichkeit, die Liste wieder zu verlassen. Zwar ist für ein E-Voting System kein triftiger Grund absehbar, die Liste jemals wieder zu verlassen, aber die Unumkehrbarkeit des Eintrages veranlasst viele Webseiten-Betreiber zur Zurückhaltung.
- Dass ein WWW-Service einen Security-Test ohne HSTS passieren könnte, ist 2018 kaum denkbar. Schliesslich gilt der HSTS als der wichtgste einer ganzen Reihe von HTTP Response Headern. Wer Sicherheits-Testberichte liest, stösst wiederholt auf Einträge, die das fehlende HSTS als gravierende Schwäche qualifizieren. Den fehlenden Eintrag auf der Preload-Liste übersehen die Tester aber gerne oder taxieren ihn als Nice-to-Have.
Unter dem Strich wäre es gut, wenn die Domäne evote-ch.ch auf der Liste eingetragen wäre, aber angesichts des sehr limitierten Schadenspotentials stellt das bisherige Fehlen nur eine geringe Nachlässigkeit durch die Betreiber dar.
Unterstützt das Genfer System diesen Standard wirklich?
Volker Birk und auch der Journalist des Schweizer Fernsehens behaupten beide, Genf habe zur Zeit der Recherche HSTS nicht unterstützt. Erst nach der Konfrontation mit den Vorwürfen des Fernsehsenders sei der Server umkonfiguriert worden. Das heisst, seit dem 2. November werde HSTS unterstützt, zuvor aber nicht.
Auch die Aussage des Genfer Systemtechnikers, HSTS werde auf dem Genfer E-Voting System seit 2016 unterstützt, brachte die beiden nicht von dieser Aussage ab. Dabei gilt der Techniker als absolut vertrauenswürdig. Er arbeitete mehrere Jahre im Security-Team des CERN. Er ist Absolvent der EPFL und erhielt den Kudelski Preis für seine Beiträge auf dem Gebiet der Kryptographie. Das Fernsehen diskreditiert hier also einen ausgewiesenen Experten auf dem Gebiet der Sicherheit.
Der Konflikt ist aus mehreren Gründen spannend. Da wäre einmal die Behauptung, der Kanton Genf habe keinerlei Schutzmassnahmen gegen einen jahrzehntealten Angriff ergriffen. Sollte Genf HSTS hingegen unterstützen, dann wäre diese mit Nachdruck vorgetragene Behauptung Makulatur, der Angriff könnte nur noch beim erstmaligen Abstimmen funktionieren, seine Wirkungslosigkeit in der Breite wäre damit demonstriert und die verschiedenen Berichte des Fernsehens würden ihre Basis verlieren.
Auf der anderen Seite pokert der Kanton Genf hoch. Denn eigentlich muss ja davon ausgegangen werden, dass die Anschuldigungen auch bewiesen werden können. Wenn der Genfer Systemtechniker also eine Schutzbehauptung an den Journalisten schickt, dann muss er damit rechnen, dass man ihn der Lüge überführen würde. Und in dieser Situation würde die Behauptung überhaupt keinen Sinn mehr machen. Die Nachricht des Genfer Technikers macht also nur dann Sinn, wenn sie stimmt; ansonsten wäre sie ein Eigentor.
Tatsächlich bleiben sowohl Volker Birk als auch der Journalist jeglichen Beweis schuldig. Wir haben nur ihre Aussage, die Volker Birk auch auf Twitter aufrecht erhält.
Das ist doch sehr merkwürdig. Wie ist es möglich, Vorwürfe dieser Tragweite vortragen zu können, ohne Beweise liefern zu müssen? Wie kann es sein, dass staatliche Institutionen und dekorierte Wissenschaftler der Untätigkeit bezichtigt werden, ohne den geringsten Beleg dazu zu präsentieren?
Es sprechen verschiedene Indizien dafür, das Genf HSTS tatsächlich seit längerem unterstützt. Die Schwierigkeiten einen Security-Audit ohne HSTS zu bestehen, wurde bereits besprochen. Dann antwortete die Genfer Staatskanzlei auf die Anfrage des Fernsehens mit der Aussage, dass sehr wohl Massnahmen ergriffen worden seien. Da HSTS am 2. November aktiv war, hätte Genf also während einer laufenden Abstimmung aufgrund von Vorwürfen, die Genf selbst deutlich zurück wies, den Server umkonfigurieren müssen. Das ist wenig wahrscheinlich, da die hohen Sicherheitsstandards, welche die Bundeskanzlei den Betreibern der E-Voting Systeme auferlegt, solche kurzentschlossenen Umkonfigurationen nur im äussersten Notfall und angesichts massiv drohender Angriffe erlaubt. Mit einer Umkonfiguration hätte Genf sich also nicht nur äusserst zweifelhaft verhalten, es hätte sich medial auch enorm angreifbar gemacht.
Neben dem sehr wichtigen HSTS Standard unterstützt Genf auch weitere HTTP Response Header. So etwa den deutlich schwierigeren und selten berücksichtigten Content-Security-Policy Standard, sowie die Header X-Content-Type-Options und X-Frame-Options. Allesamt seltenere und im Vergleich zu HSTS auch als weniger wichtig eingestufte Header. Ja selbst der neue und noch sehr wenig bekannte HTTP Response Header Referrer-Policy wird vom E-Voting System des Kantons Genf bereits berücksichtigt.
Warum man in Genf diese sekundären Header unterstützen sollte, aber den primären Header Strict-Transport-Security nicht, das bräuchte eine gute Erklärung, die bis dato aber nicht geliefert wurde.
Ein interessantes Indiz trat am 16. November zu Tage. Hernanî Marques, auch er ein vehementer E-Voting Kritiker und Vertreter des Zürcher Chaos Computer Clubs, wies auf Twitter auf einen GitHub Eintrag hin. Der Kanton Genf ist mit seiner E-Voting Software auf der Entwicklerplattform GitHub präsent und nimmt Hinweise zu Fehlern in der Software entgegen.
In einer solchen Notiz vom 18. September 2017 ist zu lesen:
Der User chsec0 weist Genf also darauf hin, dass es von Vorteil wäre, wenn die Domäne evote-ch.ch auf der HSTS-Preload Liste eingetragen würde.
Der User verlangt nicht, HSTS zu unterstützen. Denn HSTS wurde damals offenbar bereits unterstützt. Vielmehr verlangt er über den Standard hinaus auch noch die HSTS-Preload Liste zu unterstützen. Ohne HSTS auf evote-ch.ch macht diese Formulierung keinen Sinn.
All diese Indizien sprechen dafür, dass der Kanton Genf HSTS seit längerem unterstützt, aber sie sind noch kein Beweis. Den Beweis findet man bei Shodan. Diese sehr bekannte Seite ist bei Sicherheitsforschern und auch beim Chaos Computer Club sehr beliebt ist. Sie dient oft dazu, Schwachstellen im Internet aufzuspüren. Hier kann sie aber herangezogen werden, um zum belegen, dass eine behauptete Schwachstelle gar nicht existiert.
Der Dienst Shodan scannt den gesamten bekannten Adressraum des Internets regelmässig und speichert die Ergebnisse in einer historischen Datenbank, die für das Genfer E-Voting System bis Anfang 2018 zurück reicht.
In dieser nach einer Registrierung öffentlich zugänglichen Datenbank lässt sich nachsehen, zu welchem Zeitpunkt die Domäne evote-ch.ch den HSTS Standard unterstützt hat. Sie tat dies etwa Anfang Jahr bei den folgenden Shodan-Scans:
2018–02–08 04:23:39 Strict-Transport-Security: max-age=31536000
2018–02–19 05:38:59 Strict-Transport-Security: max-age=31536000
2018–02–21 02:10:59 Strict-Transport-Security: max-age=31536000
2018–02–21 10:26:29 Strict-Transport-Security: max-age=31536000
2018–02–22 17:15:26 Strict-Transport-Security: max-age=31536000
2018–02–22 22:50:31 Strict-Transport-Security: max-age=31536000
2018–02–24 11:13:01 Strict-Transport-Security: max-age=31536000
2018–03–02 03:14:25 Strict-Transport-Security: max-age=31536000Die Behauptung, der Kanton Genf habe keinerlei Massnahmen zur Verhinderung eines DNS Cache Poisoning Angriffes unternommen, bricht damit zusammen. Sie entbehrt damit ihrer Grundlage und sollte korrigiert werden: Der Kanton Genf, seine Techniker und sein E-Voting System gehören rehabilitiert. Nicht der Kanton Genf arbeitete schlampig, sondern die Vertreter des Zürcher Chaos Computer Clubs.
Wie sieht es mit dem Redirect-Status-Codes aus?
Auch hier steht Aussage gegen Aussage und auch hier kann Shodan weiterhelfen. Entgegen der Behauptung des Fernsehjournalisten und entgegen der auf Twitter nochmals mit einem drohenden Ton vorgetragenen Behauptung von Volker Birk, dass der Kanton Genf die Status Codes bis zum 2. November nicht korrekt benützt habe, haben sich die Genfer Server in diesem Punkt korrekt verhalten.
Auf die folgenden Shodan-Anfragen antwortete der Server mit dem korrekten Status Code 301.
2018–09–30 16:53:32 HTTP/1.1 301 Moved Permanently
2018–10–11 03:57:50 HTTP/1.1 301 Moved Permanently
2018–10–17 04:24:28 HTTP/1.1 301 Moved Permanently
2018–10–28 15:51:44 HTTP/1.1 301 Moved Permanently
2018–11–18 05:14:55 HTTP/1.1 301 Moved PermanentlyWie konnte so eine Fehlleistung auf Seiten des CCCs und auf Seiten des Fernsehens geschehen?
Auch hier kann man nur spekulieren. Allem Anschein nach, wurde unsauber gearbeitet, denn es wurde beispielsweise kein taugliches Journal geführt. Das ist bei dieser Arbeit aber ein Muss. Zudem sollten Screenshots jeden Befund dokumentieren, denn nur so ist die Transparenz der Recherche und die Nachvollziehbarkeit jederzeit gegeben. Das ist gerade in diesem Fall zu betonen, denn die Status Codes und auch der HSTS Standard verleiten rasch zu Fehlschlüssen.
Webserver haben die Eigenschaft, sich in verschiedenen Situationen subtil anders zu verhalten. Das betrifft etwa die Status Codes. Der HSTS Standard wiederum verlangt von einem Server, bei der Kommunikation im Klartext keinen HSTS Header zu schicken. Der gesuchte Antwort-Header ist bei Anfragen auf Port 80 also nicht vorhanden. Wenn man in der Konsole arbeitet, und man sieht Volker Birk am Fernsehen in der Konsole arbeiten, entscheidet ein “s” im Schema, ob der HSTS Response Header verlangt wird, oder unerwünscht ist.
Dass Volker Birk in diesem Punkt gelogen hat, ist hingegen nicht zwingend. Viel wahrscheinlicher ist es, dass den verschiedenen Vertretern des Chaos Computer Clubs ein Fehler unterlaufen ist und dass sie tatsächlich glaubten, die Server verhielten sich falsch.
Wenn wir den sicheren Grund verlassen, zu spekulieren beginnen und die Shodan Scans genauer betrachten, dann sehen wir, dass https://www.evote-ch.ch in puncto HSTS auffällige Verhaltensänderungen zeigt. Shodan scannt das Internet nicht in arbiträren Abständen. Das heisst, wie haben keine durchgehenden Datensätze zur Verfügung. Wenn wir aber die vorhandenen Datensätze mit den Terminen der eidgenössischen Abstimmungen in Einklang bringen, dann lässt sich eine interessante Beobachtung machen: Die URL https://www.evote-ch.ch retournierte immer dann, wenn es darauf ankam, den HSTS Header. Sobald die Wahlurne geschlossen wurde, verschwand der HSTS Header wieder. Es scheint so, als ob der Kanton zwei verschiedene Server betreiben würde: Einen gesicherten E-Voting Server und eine Landing Page ohne weitere Funktion, die zwischen den eidgenössischen Wahlperioden aktiviert wird und darauf verweist, dass das E-Voting System zur Zeit nicht zur Verfügung stehe. Auf der Landing Page scheint kein HSTS aktiviert zu sein. Denn hier ist es auch nicht nötig (was nun nicht heisst, dass man es aus konfigurationsästhetischen Gründen nicht nachholen sollte. Es sei dem Kanton nahegelegt, das zu korrigieren).
Für den 28. Oktober 2018 liegt ein Shodan Scan vor, der kein HSTS zeigt, da potentiell die Landing Page angesprochen wurde. Die laufende Abstimmungsperiode begann am 29. Oktober. Gemäss dem folgenden Scan am 2. November war HSTS dann aktiv, denn nun kam der E-Voting Server zum Einsatz.
Nehmen wir an, dies sei die Erklärung für die falschen Behauptungen am Fernsehen. Dann hiesse dies, dass die Chaos Computer Club Hacker ausserhalb der Abstimmungsperiode die Sicherheit der Landing Page des Kantons überprüft hätten und zu ihrer Behauptung gekommen seien. Sie gelangten dann aber erst nach dem Start der Abstimmungsperiode an das Fernsehen und die Journalisten nahmen ihre Arbeit auf. Diese zeitliche Abfolge würde dann aber die im Fernsehen präsentierte Geschichte über den Haufen werden. Denn bei SRF hiess es, der Zürcher Chaos Computer Club habe sich das Genfer E-Voting System am 31. Oktober zum ersten Mal angesehen und sei gleich danach direkt ans Fernsehen gelangt.
Aber diese Erklärung ist recht gewagt und es kann nicht zweifelsfrei belegt werden, dass es sich wirklich so abgespielt hat. Immerhin würde es eine Erklärung bieten, wie ein ausgewiesener Sicherheitsexperte wie Volker Birk dazu kommen kann, im Fernsehen falsche Behauptungen aufzustellen.
Ich komme also zum Schluss, dass hier ein Fehler passiert ist. Deshalb wäre es so wichtig gewesen, dass der Chaos Computer Club seinen Befund zunächst mit dem Kanton Genf geteilt hätte (Genf gibt die Email-Adresse security-chvote@etat.ge.ch als Kontakt an), um den Befund zu verifizieren. Oder zumindest, dass das Fernsehen den Befund in diesem zentralen Punkt in Ruhe nachvollzogen hätte. Stattdessen haben die Journalisten einfach die Anschuldigungen des CCC übernommen.
Spätestens als dann die Warnungen der angefragten Experten eintrafen und auch der Kanton und die Bundeskanzlei reagierten, hätten die Journalisten — oder die Redaktionsleitung — innehalten sollen. Dass dies unterlassen wurde, ist für alle Beteiligten sehr schmerzhaft.
Welche weiteren Schutzmassnahmen sind denkbar?
Volker Birk kommt im Lauf der Sendungen auf DNS SEC zu sprechen, räumt aber bereits ein, dass dieser Standard, der in der Schweiz ein Mauerblümchendasein fristet, keinen umfassenden Schutz bietet.
DNS SEC ist ein Standard, der es verhindern könnte, dass der Angreifer dem Opfer eine falsche DNS Antwort übermitteln kann. Damit dieser Schutzmechanismus spielt, müssten aber nicht nur Genf, sondern auch die Internet Provider den Standard unterstützen, was aber gerade die grossen Player nicht tun.
Insgesamt wird der Standard hierzulande kaum unterstützt. Konkret arbeiten weniger als 3 Prozent der wichtigsten Schweizer Domains nach diesem Standard.
Dazu kommen weitere Nachteile: Die Sicherheit von DNS SEC beruht auf der Signierung der DNS Antworten. Für einen DNS Server bedeutet dies einen marginalen Mehraufwand, aber die Antworten werden tendenziell grösser was in gewissen Situationen Nachteile mit sich bringt. Die Einführung von DNS SEC müsste deshalb unter Experten diskutiert werden.
Daneben scheint es sinnvoll, die Stimmbürger explizit auf die Überprüfung der URL hinzuweisen. Sie sollte inklusive dem Schema (“https://”) abgetippt und dann nach dem Laden nochmals kontrolliert werden. Dieser Kontrollschritt ist sogar noch einfacher als die Überprüfung des Zertifikats. Wenn man die Anleitungen der verschiedenen Kantone, die sich für das Genfer System entschieden haben, nacheinander durchsieht, dann fällt auf, dass auf den Screenshots die URL oft abgeschnitten wird. Das ist eine Schwäche dieser Anleitungen, die korrigiert werden sollte. Und auch die Formulierungen selbst sind oft zu wenig klar gehalten.
Die Sicherheitszertifikate von E-Voting Systemen werden sinnvollerweise von Stimmbürgern und Stimmbürgerinnen kontrolliert. Ein Fehler bei dieser berprüfung sollte zum Abbruch des Abstimmungsvorgangs führen. Das heisst, Stimmbürger sollten darauf hingewiesen werden, dass Ihr Stimmgeheimnis in Gefahr ist, wenn das Zertifikat nicht mit dem Zertifikat der Anleitung übereinstimmt. Kritiker werfen den Betreibern der Systeme und der Bundeskanzlei gerne vor, für einen Laien seien diese technischen Überprüfungen nicht zu schaffen. Auf der einen Seite wäre es mit der richtigen Anleitung durchaus machbar. Und auf der anderen Seite reicht es, wenn jeder 10. oder jeder 20. Stimmbürger diese Überprüfung vornimmt, denn damit werden flächendeckende Angriffe garantiert erkannt.
In dieselbe Kategorie fällt auch die Überprüfung der Checksummen der Javascript Dateien, die vom Browser beim E-Voting heruntergeladen werden. Dieser Überprüfungschritt kann von Laien nicht verlangt werden. Es wäre aber sinnvoll, den technisch interessierten Personen die Möglichkeit zu geben, diese Checksummen zu überprüfen, indem sie an einem geeigneten Ort publiziert werden.
Und zu guter Letzt noch ein Vorschlag, der noch kaum diskutiert wurde, der aber durchaus plausibel ist: Die beiden Schweizer E-Voting Systeme werden unter der “.ch” Top Level Domain angeboten. Dies erlaubte es dem Chaos Computer Club sehr leicht, eine ähnlich klingende Domain zu registrieren, da “.ch-Domänen” auf Antrag hin automatisiert vergeben werden.
Daneben existiert seit 2014 aber die “.swiss” Top Level Domain, die vom Bundesamt für Kommunikation deutlich restriktiver verwaltet wird. Hier scheint es wenig wahrscheinlich, dass ein Angreifer so einfach in den Besitz einer ähnlich klingenden Domain für seinen E-Voting Angriff gelangen könnte.
Die Stimmbürger und Stimmbürgerinnen könnten dann auf die Endung “.swiss” hingewiesen zu werden, was die Überprüfung für sie nochmals vereinfachen würde.
Tatsächlich müssen die E-Voting Systeme bestrebt sein, von den Stimmbürgern möglichst wenig Computer-Kenntnisse zu verlangen. Aber wie bei der brieflichen Stimmabgabe hängt die Wahrung des Stimmgeheimnisses zu einem guten Teil von der Mitarbeit des Stimmbürgers ab. Denn wer seinen Stimmzettel am Bahnhof ausfüllt, muss damit rechnen, dass eine Überachungskamera seine Auswahl mitfilmt. Und wer die Sicherheitshinweise in der Anleitung zum elektronischen Abstimmen nicht befolgt, muss ebenfalls damit rechnen, dass sein Stimmgeheimnis bei einem Angriff gebrochen werden könnte.
[UPDATE: 24.11.2018: Präzisierung DNS SEC und Präzisierung der Abschnitte zu HSTS]
[UPDATE: 29.11.2018: Präzisierung DNS SEC bringt kein grosses DoS Problem mit sich]