Abbildung 3.5: Beta-System-Komponenten einer lokalen Administration.
In der Vorbereitungsphase definiert BBS der LA eine Spezifikation der Entscheidung und publiziert diese gemeinsam mit seiner Signatur im öffentlichen X.500-Verzeichnis (CCITT X.500, 1994). Das X-500-Verzeichnis wird derartig organisiert, daß alle Teilnehmerdaten, Zertifikate, Schlüssel der Teilnehmer, Schlüssel der Administrationen sowie die Spezifikationen der Entscheidung durch diesen Dienst verwaltet werden können. Die Beschreibung der Funktionalität dieses Dienstes spezifiziert der Abschnitt 3.10.4. Dagegen erscheinen ergebnisorientierte Daten wie die lokale Auswertungsliste und die Resultate im BBS.
Bevor der Teilnehmer eine gültige Stimme abgeben kann, muß Client mit dem Zertifizierungs-Server ein sicheres Zertifizierungsprotokoll ausführen. Dabei weist Client gegenüber dem Zertifizierungs-Server die Identität des Benützers nach und erhält im Gegenzug ein Zertifikat, das für die Durchführung einer gültigen Stimmabgabe nötig ist. Dieses Zertifizierungsprotokoll verwendet ein blindes Signatursystem: Der Client erzeugt zunächst ein Zufallsschlüsselpaar. Bevor der öffentliche Zufallsschlüssel zum Zertifizierungs-Server übermittelt wird, camoufliert Client den öffentlichen Schlüssel in eine Form, die es dem Zertifizierungs-Server nicht erlaubt, den Inhalt des öffentlichen Schlüssels zu lesen. Außerdem unterzeichnet Client den blinden öffentlichen Schlüssel (Camouflage) mit seinem geheimen Signaturschlüssel, dessen korrespondierender öffentlicher Schlüssel durch Trust-Center zertifiziert wurde. Der Zertifizierungs-Server empfängt vom Client den blinden öffentlichen Schlüssel mit der dazugehörigen Signatur. Daraufhin verifiziert der Zertifizierungs-Server in seiner Datenbank, ob der Wähler stimmberechtigt ist, noch kein Zertifikat erhielt und die Signatur korrekt ist. Nach positiver Erfüllung aller Bedingungen signiert der Zertifizierungs-Server den blinden Schlüssel und sendet seine Signatur zurück zum Wähler. Client wartet die Antwort des Zertifizierungs-Servers ab. Nachdem der Client seine Wahldaten vom Zertifizierungs-Server zurückerhalten hat, transformiert dieser die Signatur und den blinden Schlüssel zurück. Daraus gewinnt der Client ein gültiges Zertifikat zum ursprünglichen öffentlichen Zufallsschlüssel. Der Zertifizierungs-Server verfügt nur über die Information, daß er für den Wähler ein Zertifikat ausgestellt hat - er kennt aber keinesfalls den öffentlichen Zufallsschlüssel und die Transformationsschlüssel des blinden Signatursystems. Deshalb kann dieser nachträglich keinen Zusammenhang zwischen Wähler und Zertifikat feststellen. Parallel zum blinden Signaturprotokoll lädt Client den öffentlichen Kollektivschlüssel aus dem X.500-Verzeichnis, den er benützt, um seinen Wahlschein zu chiffrieren (siehe Alpha-3-System). Auch empfängt Client die öffentlichen Schlüssel der Mix-Einheiten und die Spezifikation des Wahlscheins.
Abbildung 3.6: Zertifizierungsprotokoll (stark vereinfacht).
Im Wahlzeitpunkt führt Client das Wahlprotokoll aus. Client verschlüsselt die Benutzereingaben mit dem öffentlichen Kollektivschlüssel und signiert den codierten Wahlschein mit dem geheimen Zufallsschlüssel. Aus diesem Vorgang geht eine Pseudonym-Signatur hervor. Client chiffriert nachstehende Daten mit den öffentlichen Schlüsseln der Mix-Stationen in spezifizierter Reihenfolge:
Abbildung 3.7: Wahlvorgang.
Falls kein BBS eingesetzt wird (ohne authentifizierbare Stimmabgabe), besteht durch den Einsatz anonymer Kanäle die Sicherheitsproblematik darin, daß eine böswillige Einheit der Administration (d.h. ihr Zertifizierungs-Server) unbemerkt Stimmen für Nichtwähler abgeben kann. Unter Nichtwählern verstehen wir Personen, die (vor der Wahl) ein blindes Zertifikat anfordern, aber keine Stimme abgeben.Selbst wenn die Administration keine Möglichkeit hat, Stimmen einzelnen Wählern zuzuordnen, kann sie immer noch eigenständig eine Anzahl gültiger Stimmen abgeben. Diese Angriffsart gewinnt an Bedeutung, wenn die Anzahl der registrierten Nichtwähler groß ist (z.B. 50%). Beispielsweise sendet ein böswilliger Zertifizierungs-Server kurz vor Ende der Wahlzeit Stimmen anstelle der Nichtwähler über den anonymen Kanal.Die notwendige Anzahl (z.B. 30%) der zu übertragenden Stimmen würde der Zertifizierungs-Server vom Auswertungs-Server erhalten. Da niemand weiß, wer gewählt hat und wer nicht, kann dieser Angriff nicht entdeckt werden.
Da in unserem Ansatz die gesamte Kommunikation (für die Stimmabgabe) über BBS abgewickelt wird, ist es verifizierbar (BBS zeichnet alle Lese- und Schreibzugriffe auf), wer gewählt hat. Daher kann keine weitere Stimme einer betrügerischen Administration hinzugefügt werden. BBS schützt die Mix-Einheiten auch vor externen Netzangriffen, da ausschließlich signierte chiffrierte Mix-Daten anonymisiert werden (Zugriffskontrolle). Die Anonymisierung der codierten Wahlscheine erfolgt nur über das BBS. Die Mix-Einheiten anonymisieren einen verschlüsselten Wahlschein nur dann, wenn der Teilnehmer seine authentifizierbare Signatur zum BBS mitsendet. BBS schützt vor einer betrügerischen Administration, da zu jedem Protokollzeitpunkt eine öffentlich abrufbare Liste der Teilnehmer-Signaturen existiert. Versucht eine böswillige Administration Stimmen für einen Nichtwähler abzugeben, dann muß sie den jeweiligen geheimen Teilnehmer-Signaturschlüssel ausforschen. Dies erfordert das Brechen des Signaturschemas. Ein solcher Angriff ist aber wegen des sicheren Signaturschemas praktisch undurchführbar.
Der für die Stimmabgabe benötigte sender-anonyme Kanal wird mit Hilfe von Mix-Einheiten realisiert. Jede Mix-Einheit führt zur Anonymisierung Transformationen eines Public-Key-Kryptosystems durch. Die Übertragung der Wahlscheine erfolgt ausgehend vom BBS über mehrere hintereinander geschaltete Mix-Stationen, bevor die Wahlscheine wieder BBS erreichen.
In diesem Ansatz befinden sich alle Mix-Stationen im Gebäude der jeweiligen lokalen Administration (interne Mix-Einheiten). Jede Mix-Einheit wird von einer unabhängigen Betreiberorganisation kontrolliert. Doch die Anforderungen an diese sind hoch: Jeder Teilnehmer sollte in der ihm zugeordneten Mix-Kaskade der lokalen Administration mindestens einen Mix seines Vertrauens finden (beispielsweise Amnesty International als Betreiberorganisation). Außerdem ist nicht sichergestellt, daß der Betreiber die alleinige Macht über seinen Mix hat, da Mix-Einheiten als komplexe Systeme praktisch unauffindbare Trojanische Pferde enthalten könnten. Daher sollten Mix-Einheiten verschiedener Betreiber auch unabhängige Hersteller (und Entwerfer) haben.
Die Anonymität ist dann gewährleistet, wenn mindestens eine Betreiberorganisation ehrlich ist. Die Mix-Stationen sind nicht direkt über das Netz erreichbar, daher sind Angriffe von außen schwieriger durchzuführen.
Bei der Anonymisierung führt eine Mix-Station vier grundlegende Basisaufgaben aus:
Abbildung 3.8: Anonymisierungsprotokoll.
Ein Vorteil des Ansatzes interner Mix-Einheiten gegenüber eines externen Mix-Netzes (die Mix-Einheiten sind über das Netz verteilt) besteht in der Verhinderung einer möglichen Verkehrsanalyse. Unter der Bedingung einer niedrigen Netzbelastung (z.B. eine geringe Anzahl von Stimmen wird zum Zeitpunkt X über den externen anonymen Kanal gesendet, die an bestimme Administrationen adressiert sind) vervollständigen die Mix-Stationen in der derzeitigen Standard-Mix-Implementierung den Nachrichtenstapel durch Attrappen-Pakete (Dummy-Pakete).
Betrügerische Administrationen sind aber Borrell und Riera zufolge imstande (Borrell/Riera, 1999), zwischen Attrappe und echtem Wahlschein zu unterscheiden. Diese können durch Analyse der Verkehrsdaten und durch Zusammenschluß ihrer empfangenen Pakete Stimmen rückverfolgen (Borrell/Riera, 1999). Dieser Angriff gegen die Anonymität wird hier nicht näher ausgeführt. Auch steigern Attrappen-Pakete die Netzbelastung.
Im Beta- und im Gamma-System wird ein Dechiffrierungskreis durch die jeweiligen internen Mix-Einheiten und durch den Auswertungs-Server A gebildet. Nach dem Ende der Wahlzeit führt jede Einheit des Dechiffrierungskreises jeweils eine Teilentschlüsselung der codierten Wahlscheine mit ihrem geheimen Teilschlüssel aus. Auch beweist jede Protokolleinheit, daß ihre Dechiffrierungsoperation auch korrekt war. Schließlich ordnet der Auswertungs-Server jedem decodierten Wahlschein eine eindeutige Sequenznummer zu, veröffentlicht die Auswertungsliste und das Resultat im BBS. Jeder Wähler kann im Rahmen eines Verifikationsprotokolls prüfen, ob seine Stimme in der Auswertungsliste erscheint.
Das erste RSA-Wahlschema, bei dem die Administration blinde
Schlüssel zertifizierte, stammt von Sako (Sako, 1994). Qi He und Zhongmin
Su publizierten ein weitgehend analoges Protokoll (He/Su, 1997). Damit
das Kriterium der Nichtbeeinflußbarkeit erreicht wird, benötigen
beide Wahlprotokolle zwei Durchgänge zur Stimmabgabe. Ein weiterer
Nachteil der Verfahren liegt darin, daß alle für die Wahl registrierten
Teilnehmer auch tatsächlich wählen müssen. Diese starke
Prämisse bleibt im allgemeinen unerfüllt. Infolgedessen kann
eine böswillige Administration unbemerkt Stimmen für Nichtwähler
über den anonymen Kanal senden. Das Beta-System behebt diese Defizite
und stellt somit eine Weiterentwicklung des blinden Schlüsselzertifizierungsansatzes
dar, da die Stimmabgabe in einem Durchgang abgewickelt und die Nichtvermehrbarkeit
garantiert wird.
Abbildung 3.9: Verifikation der individuellen Stimmabgabe.
