Jusletter IT

Demokratische Wahlen müssen allgemein, frei, gleich, persönlich (außer dort, wo Stellvertretung möglich ist) und geheim sein [2]. Diese rechtlichen Voraussetzungen können in konkrete technische Anforderungen umgesetzt werden, die ein eVoting-System erfüllen muss (für Beispiele solche «Übersetzungen», s. [3], [4]). Die wichtigsten davon wären:

Abb. 1 fasst diese Anforderungen in einem Raster zusammen, wobei in jeder Dimension angegeben wird, wie weit ein System den jeweiligen Punkt technisch absichert. Bei einer technischen Absicherung hängt der Schutz nicht vom Wohlverhalten der Beteiligten ab, sondern wird vom System selbst durchgesetzt; bei einer organisatorischen Sicherung hingegen hängt die Einhaltung des jeweiligen Punktes vom Wohlverhalten der Beteiligten ab.

Abbildung 1 zeigt zur Illustration ein Beispielsystem; je weiter nach außen in einer Dimension der Wert liegt, umso besser ist das System gegen den betreffenden Angriff abgesichert. So wird in diesem angenommenen Beispielsystem das Stimmgeheimnis in perfekt abgesichert, vor der Stimmabgabe ist diese Sicherung jedoch rudimentär. Analog die Beschreibung der anderen Dimensionen.

Es erhebt sich die Frage, wie die Einheiten auf den Achsen operationalisiert werden können. Eine Möglichkeit dazu wäre die Angabe, welche Koalition an Beteiligten das Ziel der betreffenden Achse kompromittieren kann: ein Einzelner, eine Gruppe unter Einschluss des Wählers, die Wahlkommission, ... Ein weiteres Kriterium könnte die Anzahl der Stimmen sein, die von der jeweiligen Koalition kompromittiert werden können: eine einzelne Stimme, die eines Sprengels oder Wahlkreises oder alle Stimmen. Selbstverständlich können auch Kombinationen dieser Kriterien für die Operationalisierung dieses Rasters verwendet werden.

Dieser Beitrag setzt sich nun mit der Rolle des Wahlclients bei der technischen (also nicht rein organisatorischen) Durchsetzung dieser Sicherheitsziele auseinander, wobei zwei Aspekte betrachtet werden: (i) Manipulationen an der Stimme durch die Serveradministration bzw. den Wahlveranstalter und (ii) Manipulation des gesamten Systems durch die selben Personen.

Hier handelt es sich um eine Designentscheidung in der Implementierung des Wahlsystems, die – unabhängig vom verwendeten kryptographischen Wahlprotokoll – entscheidend für die Einhaltung der Wahlgrundsätze ist und die insbesondere alle Sicherungen des Wahlprotokolls zur Absicherung der Wahlrechtsgrundsätze zunichte machen kann.

Im Unterschied zu anderen Schutzprofilen (vgl. z.B. [5]) geht Rec. 2004(11) nicht von einem «sicheren Server» und einem ehrlichen Wahlveranstalter aus. Einige der wesentlichen Bedrohungen in diesem Zusammenhang werden in Annex III der Empfehlung gelistet, hier eine Auswahl der wichtigsten im Zusammenhang mit der Integrität des Serversystems:

T.System_Forgery: das gesamte Wahlsystem wird gefälscht;
T.Audit_Forgery: die Aufzeichnungen und Protokollierungen werden gefälscht;
T.Hack: das Wahlsystem wird von einem externen Angreifer übernommen;
T.Ballot_Forgery: Fälschung des ausgehenden Stimmzettels bzw. der eingehenden ausgefüllten Stimmzettel;
T.Vote_Modify: Veränderung der eingegangenen Stimmen;
T.Vote_Confidentiality: Durchbrechen des Stimmgeheimnisses.

Was bedeutet dies nun im Zusammenhang mit der erwähnten Softwaredesignentscheidung?

Wie im oberen Teil von Abb. 2 gezeigt, läuft eine Webapplikation immer im Server; der Browser des Wählers dient bloß der Darstellung am Schirm. Daran ändert auch eine SSL-Verschlüsselung [6] nichts, da diese nur gegen Angriffe durch Dritte während der Übertragung im Internet schützt. Im Webserver wird diese Verschlüsselung wieder entfernt und die eingegangene Nachricht, z.B. die Stimme, liegt im Klartext vor. In diesem Augenblick besteht die Möglichkeit die Stimme zu verändern, zu unterdrücken oder einfach nur auszulesen, um zu sehen, wie jemand abgestimmt hat.

Wenn danach die Stimme an den Applikationsserver weitergereicht und verschlüsselt wird und so in der Datenbank abgelegt ist, so kann dies als reines «Placebo» angesehen werden, umso mehr als die Verschlüsselung der Stimme in erster Linie als Maßnahme gegen Betrug durch die Serveradministratoren gedacht ist. Diese haben aber bereits bei der Übergabe der Daten vom Web Server an den Applikationsserver die Möglichkeit die Manipulationen vorzunehmen – der Schaden wäre also bereits erfolgt.

Diese Verwundbarkeit ist vom verwendeten kryptographischen Wahlprotokoll vollkommen unabhängig. Vielmehr gehen die meisten Wahlprotokolle davon aus, dass der Wahlclient bestimmte Verarbeitungen durchführt, die dem Server verborgen bleiben:

Vollkommen anders stellt sich die Situation im Falle der Verwendung eines Wahlclient dar, wie sie im unteren Teil von Abb. 2 dargestellt ist. Ein Wahlclient ist im Gegensatz zu einer Browserapplikation ein am PC des Wählers ablaufendes Programm. In den 90er Jahren wurde verschiedentlich der Vorschlag gemacht, einen auf CD verschickten Wahlclient zu verwenden, der auch eine Boot CD inkludiert (s. dazu [8]). Heute wird dafür sinnvollerweise ein Java Client [7] verwendet, der zwar mit einer Webseite ausgeliefert wird, dann aber am PC in einer geschützten Umgebung (der «Sandbox») abläuft. Solange der Java Client (auch als Applet bezeichnet) nicht explizit mit dem Server Kontakt aufnimmt, merkt der Server nicht, welche Verarbeitungsschritte durchgeführt werden. Da eine solche Kontaktaufnahme entweder über Socketverbindungen [9] oder Web Service Calls [10] explizit und im Coding des Applet genau nachvollziehbar erfolgt, ist eine «versteckte» Kontaktaufnahme nur schwer vorstellbar, wenn der Client einer entsprechenden Sicherheitsüberprüfung unterzogen wird (s. dazu auch den folgenden Abschnitt 3).

Hier kann nun die Stimme im Wahlclient so verschlüsselt und an den Wahlserver abgeschickt werden, dass niemand außer der Wahlkommission diese Stimme öffnen und lesen kann; Dritte auf dem Übertragungswege oder die Serveradministration können dies nicht und sehen die Stimme nicht im Klartext.

Die einzigen Angriffsmöglichkeiten, die einem Dritten oder der Serveradministration bleiben, sind (i) das Unterdrücken der Stimme bzw. das Löschen der verschlüsselten Stimmen in der elektronischen Urne, (ii) das Einschleusen von Stimmen. Ersteres kann, da die Stimme den Manipulierenden nicht im Klartext vorliegt, nur «blind» erfolgen, so ist etwa ein statistischer Angriff denkbar, indem beispielsweise jede vierte Stimme eines bestimmten Wahlkreises unterdrückt wird, da dort eine bestimmte Partei besonders stark vertreten ist. Dies kann aber einerseits dadurch verhindert werden, dass auch die Information, die eine solche Zuordnung ermöglicht, ebenfalls im Wahlclient verschlüsselt wird (also dem Zugriff der Serveradministration entzogen wird); andererseits kann die erfolgte Stimmabgabe entsprechend nachvollzogen werden: entweder individuell durch Prüfcodes der Stimmen, die gezählt wurden oder global indem bestimmte Summen übereinstimmen müssen. Erlaubt ein Verfahren beispielsweise die unabhängige Wahlbeobachtung und muss jedes ausgestellte Wahlrecht (und damit jeder ausgestellte Stimmzettel) vom Wahlbeobachter gegengezeichnet werden (s. dazu das Verfahren von [13]), so wird das «Verschwinden» von Stimmen natürlich erkannt. Ein solches Verschwinden von Stimmen ist dabei durchaus kein hypothetischer Fall, immerhin hat das oberste finnische Verwaltungsgericht 2009 den eVoting-Einsatz bei den finnischen Kommunalwahlen 2008 aufgehoben und die Wahl musste auf Papier wiederholt werden [17, 18].

Ähnlich verhält es sich mit dem Einschleusen von Stimmen durch die Serveradministration. Gibt es eine unabhängige Wahlbeobachtung im Verfahren implementiert, so ist es kein Problem, solche Stimmen zu erkennen.

Somit sind daher die verbleibenden Angriffe im Falle der Verwendung eines Wahlclient durchaus beherrschbar, und die Diskussion verlagert sich wiederum auf das Gebiet des Wahlprotokolls. Im Falle einer Webapplikation hingegen bestehen die in Abschnitt 2.1 genannten grundsätzlichen Bedenken unabhängig vom verwendeten Wahlprotokoll.

H1: Ein eVoting-System, das auf einer Webapplikation und keinem Wahlclient basiert, kann unabhängig vom verwendeten kryptographischen Wahlprotokoll die Wahlrechtsgrundsätze nicht technisch absichern.

Es erfüllt damit in seiner technischen Absicherung nicht die Empfehlung 2004(11), Annex III.

Natürlich kann ein solches System immer noch organisatorische Sicherungen bieten. Beispielsweise können Ziviltechniker die Server zusätzlich im Betrieb überwachen, die Administratorpassworte können verteilt gehalten werden etc. Immer jedoch hängt die Sicherung hier vom Wohlverhalten der Beteiligten ab.

Sicherheitskritische Webapplikationen werden mit SSL/TLS abgesichert, das bedeutet nicht nur die Verschlüsselung der Kommunikation zwischen dem Browser des Benutzers und dem Web Server, sondern auch die Authentisierung des Servers, mit dem der Benutzer kommuniziert. Das Zertifikat des Servers wird von einem Wurzelzertifikat durch Signatur authentisiert, wobei die öffentlichen Schlüssel des Wurzelzertifikats im Browser zur Verfügung stehen. Anbieter von Wurzelzertifikaten sind Trust Center, wie etwa Verisign oder a-trust . Mit diesen kann dann das Zertifikat des Servers (bzw. dessen Signatur durch den Provider des Wurzelzertifikats) geprüft und dieser damit authentisiert werden.

Nicht authentisiert wird damit aber die am Server gerade ablaufende Software.

Damit ist ein eVoting-System auf Basis einer Webapplikation wiederum offen gegen Angriffe durch die Betreiber des Systems, beispielsweise T.System_Forgery oder T.Audit_Forgery. So kann beispielsweise eine betrügerische Serveradministration das komplette Wahlsystem am Server austauschen – aus Sicht von SSL und der Zertifikatsprüfung ist alles in Ordnung, schließlich wurde ja der Server, auf dem das Zertifikat installiert ist, nicht getauscht.

Anders stellt sich dies bei Verwendung eines Java Client dar. Dieser kann beispielsweise von der Zertifikatsstelle, die diesen prüft und zertifiziert, digital signiert werden. Diese Signatur wird mit einem Java Applet ausgeliefert und kann von jedem Benutzer geprüft werden – der Zertifikatsmechanismus ist hier ganz ähnlich wie bei SSL-Zertifikaten, allerdings betrifft er hier nicht die Quelle einer Nachricht, sondern den Inhalt , d.h. es wird prüfbar, ob der am Wahltag ausgelieferte Java Client vollkommen identisch mit dem Client ist, der geprüft und zertifiziert wurde. Wird auch nur ein Zeichen in diesem Client verändert, so stimmt die digitale Signatur nicht mehr. Damit kann Bedrohung T.System_Forgery effektiv ausgeschaltet werden, was die wählerseitige Software betrifft. T.Audit_Forgery kann soweit ausgeschaltet werden, als Nachrichten vom Wahlclient zusammengestellt und manipulationsgesichert aufbereitet werden.

Selbstverständlich kann daneben immer noch SSL zur Serverauthentisierung verwendet werden, diese wirkt aber hier nur ergänzend.

H2: Bei einem eVoting-System, das auf einer Webapplikation und keinem Wahlclient basiert, kann unabhängig vom verwendeten kryptographischen Wahlprotokoll dem Wähler nicht die Möglichkeit gegeben werden, die eingesetzte Wahlsoftware zu authentisieren.

Natürlich wird es auch bei Verwendung eines Wahlclient immer noch eine serverseitige Software geben, die die abgegebene Stimme übernimmt und in die Urne legt. Allerdings ist zum ersten die Komplexität dieser serverseitigen Software gegenüber einer reinen Webapplikation dramatisch reduziert, wie folgende in Tabelle 1 dargestellte, rein heuristische und keinen Anspruch auf Vollständigkeit ergebende Gegenüberstellung bei der eigentlichen Stimmabgabe zeigt.

Tendenziell ergibt sich hier ein klares Bild, dass die Mehrzahl der Verarbeitungsschritte im Wahlakt im Wahlclient ablaufen, dessen Authentizität entsprechend Abschnitt 3.2 geprüft werden kann.

Des weiteren muss natürlich auch bezüglich der serverseitigen Teile der Software ebenfalls sichergestellt werden, dass zu jedem Zeitpunkt zwischenInstallation des Systems und Ergebnisermittlung das authentische und geprüfte System läuft. Dies kann letztlich nur durch systemtechnische Maßnahmen sichergestellt werden, da organisatorisch/physische Maßnahmen (Zutrittsschutz, physische Bewachung) bei einem vernetzten System in Leere gehen.

Dieser Beitrag widmete sich dem Unterschied zwischen einem Wahlclient und einer reinen Webapplikation zum Zwecke des eVoting und es wurden zwei Hypothesen aufgestellt, dass nur Wahlclient-basierte Systeme die Wahlrechtsgrundsätze technisch absichern und damit die Empfehlung 2004(11) erfüllen können.

Natürlich bedeutet das nicht, dass jedes Wahlclient-basierte System diese Anforderungen auch automatisch erfüllt. Allerdings erst ein Wahlclient und damit dezentrales Design ermöglicht es grundsätzlich überhaupt Systeme zu bauen, die die Wahlrechtsgrundsätze technisch schützen.

In diesem Sinne kann die Wahlclient-Basiertheit eines Systems als notwendige, aber nicht hinreichende Bedingung für einen derartigen technischen Schutz angesehen werden.

[1] Council of Europe, Recommendation 2004(11) of the Committee of Ministers to member states on legal, operational and technical standards for e-voting; Strasbourg (2004).
[2] Walter R. & Mayer, H., Grundriß des österreichischen Bundesverfassungsrechts, 4. Auflage, Manz, Wien (1982).
[3] Prosser, A., Elektronische Demokratie und die Stimmabgabe über das Internet. In: Zechner, A. (Hrsg.), E-Austria Guide 2006, Linde, Wien (2006).
[4] Volkamer, M., Hutter, D., Das Potential von e-Voting in Prosser, A., Krimmer, R. (Hrsg.): e-Democracy, Technologie, Recht und Politik, OCG-Verlag, Wien, S. 163-174 (2003).
[5] Bundesamt für Sicherheit in der Informationstechnik, Common Criteria Protection Profile for Basic set of security requirements for Online Voting Products, PP0037.
[6] Internet Engineering Task Force: RFC 2246 (TLS 1.0), RFC 4346 (TLS 1.1), RFC 5246 (TLS 1.2).
[7] Niemayer, P., Knudsen, J., Learning Java; O’Reilly, Sebastopol (2005).
[8] Otten, D., Forschungsgruppe Internetwahlen, www.internetwahlen.de (2000).
[9] Krüger, G., Handbuch der Java-Programmierung, 4. Auflage; Addison-Wesley, München, S. 915 ff. (2006).
[10] Buczek, G., Instant ASP.NET Applications; Osborne, New York, S. 865 ff. (2001).
[11] Chaum, D., Blind Signatures for Untraceable Payments in Crypto, 199-203 (1982).
[12] Fujioka, A., Okamoto, T. & Ohta, K., A practical secret voting scheme for large-scale elections in AUSCRYPT 92 Lecture Notes in Computer Science Vol. 718, Springer, Berlin, S. 244-251.
[13] Prosser, A. & Müller-Török, R., E-Democracy: Eine neue Qualität im demokratischen Entscheidungsprozess, Wirtschaftsinformatik, 6, 545-556.
[14] ElGamal, T., A public key cryptosystem and a signature scheme based on discrete logarithms, Lecture Notes in Computer Science Vol. 196, 10-18.
[15] Schoenmakers, B., A Simple Publicly Verifiable Secret Sharing Scheme and its Application to Electronic Voting, Lecture Notes in Computer Science, Vol. 1666, S. 148-164.
[16] Maaten, E., Towards Remote E-Voting: Estonian Case in Prosser, A., Krimmer, R. (Hrsg.), Electronic Voting in Europe – Technology Law, Politics and Society; GI Verlag, S. 83-100.
[17] ORF (Redaktion), E-Voting-Wahlgang in Finnland ungültig; http://futurezone.orf.at/stories/1602230/ aufgerufen 19.4.2009 (2009).
[18] Electronic Frontier Finland (EFFI), Finnish e-voting results annulled, municipalities to hold new elections; www.effi.org/blog/2009-04-09-EVoting-Supreme-Admin-Court.html aufgerufen 19.4.2009 (2009).
 

Department für Informationsverarbeitung und Prozessmanagement, Wirtschaftsuniversität Wien
Augasse 2-6, 1090 Wien, AT, alexander.prosser@wu-wien.ac.at