Inhaltsverzeichnis         Kapitel 1         Kapitel 2         Kapitel 3         Kapitel 4         Kapitel 5         Kapitel 6         Literaturverzeichnis

3 Technische Konzepte zur Erfüllung der Anforderungen an ein sicheres elektronisches Zahlungssystem

Ein Kryptosystem ist formal ein Tupel (K, C, S, V_s, E_s) mit

An gute Kryptosysteme werden folgende Anforderungen gestellt:

In Kryptosystemen besteht das Geheimnis nicht in dem Verfahren, sondern in den benutzten Schlüsseln. Der Schlüsselraum S sollte möglichst groß sein, damit ein Angreifer nicht durch Ausprobieren aller Schlüssel aus dem Schlüsselraum S in akzeptabler Zeit den Klartext erhalten kann. Desweiteren sollten die Schlüssel aus zufälligen Daten erzeugt werden.

Abbildung 1: Symmetrisches Kryptosystem ([NET98])

Symmetrische Kryptosysteme haben folgende Eigenschaften (s aus S, k aus K und c aus C):

Das Problem ist der sichere Austausch des geheimen Schlüssels.

Wichtige symmetrische Kryptosysteme sind DES (data encryption standard), das im Bankwesen häufig eingesetzt wird, und IDEA (International Data Encryption Algorithm), das heute bei PGP (Pretty Good Privacy) zum sicheren Versenden von E-Mails verwendet wird. Problematisch an DES ist die geringe Schlüssellänge von 56 Bit, weshalb die einmalige Anwendung von DES heute als nicht mehr sicher gilt. Empfohlen wird die dreifache Anwendung von DES mit unterschiedlichen Schlüsseln.

Abbildung 2: Asymmetrisches Kryptosystem ([NET98])

Bei asymmetrischen Kryptosystemen erfolgen Ver- und Entschlüsselung mit zwei verschiedenen Schlüsseln. Asymmetrische Kryptosysteme haben folgende Eigenschaften( (s₁,s₂) Schlüsselpaar mit s₁, s₂ aus S und s₁<>s₂, k aus K):

Der Vorteil von asymmetrischen Kryptosystemen ist, dass ein Schlüssel öffentlich bekanntgegeben werden darf (Public Key), während der andere geheim bleiben muss (Private Key). Der Nachteil gegenüber symmetrischen Verfahren ist die erheblich geringere Ver- und Entschlüsselungsgeschwindigkeit. Außerdem ist die Zugehörigkeit des öffentlichen Schlüssels zu einer Person nicht sichergestellt (diese Problematik wird in Kapitel 3.2 aufgegriffen). Das bekannteste und am häufigsten eingesetzte asymmetrische Kryptosystem ist RSA.

Im folgenden wird ein unsicherer Kanal (z. B. ein Weg durch das Internet) betrachtet, über den der Sender A eine geheime Nachricht an den Empfänger B schicken will. Dazu benutzen beide ein asymmetrisches Kryptosystem: Zunächst sendet B seinen öffentlichen Schlüssel s₁ an A. A bildet c=V_s1(k) und sendet c an B. B erhält den Klartext k durch k=E_s2(c), also durch Entschlüsseln mit seinem privaten Schlüssel s₂. Ein Problem ist, dass die Integrität des öffentlichen Schlüssels s₁ nicht gewährleistet ist; s₁ könnte auf dem Weg durch den unsicheren Kanal gefälscht werden (sog. Man-in-the-middle-Attack). Um dies zu verhindern, benötigt man das Konzept der digitalen Signaturen (Kapitel 3.1.5).

Abbildung 3: Digitale Signatur ([NET98])

Digitale Signaturen dienen zwei Zwecken: sie ermöglichen in Kombination mit Zertifikaten (Kapitel 3.2) die Feststellung der Identität des Senders A durch den Empfänger B und decken mögliche Manipulationen einer Nachricht auf ihrem Weg durch das Netzwerk auf. A bildet aus der zu sendenden Nachricht n₁ einen sogenannten Hash-Wert h₁=H(n₁). Die Hashfunktion H muss folgende Eigenschaften besitzen:

A verschlüsselt den Hash-Wert h₁ mit seinem privaten Schlüssel s₁: c₁=V_s1(h₁); c₁ ist die sog. digitale Signatur der Nachricht n₁. A sendet die Nachricht n₁ zusammen mit der digitalen Signatur c₁ an B; B empfängt n₂ und c₂. B entschlüsselt c₂ mit dem öffentlichen Schlüssel s₂ von A (h₂=E_s2(n₂)) und bildet seinerseits den Hash-Wert h₂' der empfangenen Nachricht n₂: h₂'=H(n₂). Sind h₂ und h₂' identisch, gilt auch n₁=n₂ wegen der Eineindeutigkeit von H, d. h. die Integrität der übertragenen Nachricht ist nachgewiesen. Andernfalls ist die Nachricht nicht so angekommen, wie der Empfänger sie abgeschickt hatte, oder die Nachricht stammt nicht vom Besitzer des passenden privaten Schlüssels. A könnte auch die zu sendende Nachricht direkt mit seinem privaten Schlüssel verschlüsseln (c₁=V_s1(n₁)) und n₁ zusammen mit c₁ an B schicken. Jedoch ist die verschlüsselte Nachricht im allgemeinen viel länger als der verschlüsselte Hash-Wert, somit würde die Benutzung der verschlüsselten Nachricht als Unterschrift zu einem erheblich höheren Datenaufkommen im Netzwerk führen.

Das Konzept der blinden Signatur erlaubt das digitale Signieren von Nachrichten, ohne dass der Signierer den Inhalt der Nachricht lesen kann. Blinde Signaturen werden im elektronischen Zahlungssystem eCash (Kapitel 5.2) zur anonymen Geldausgabe eingesetzt. Angenommen Person A möchte eine Nachricht n₁ von Person B blind signieren lassen. Dazu werden folgende Schritte ausgeführt:

Ein Zertifikat ordnet einem öffentlichen Schlüssel eine Person, einen Server, ein Unternehmen oder andere Dinge der realen Welt zu. Zertifikate erfüllen die Forderungen Authentifizierung und Autorisierung; sie verhindern, dass jemand einen öffentlichen Schlüssel benutzt, der ihm gar nicht gehört. Der öffentliche Schlüssel des Zertifikats passt nur zu dem privaten Schlüssel, den der Inhaber des Zertifikats besitzt. Zertifikate werden von sogenannten CAs (Certificate Authorities) ausgestellt und von diesen mit ihrem privaten Schlüssel digital signiert. So kann der Benutzer des Zertifikats mit dem öffentlichen Schlüssel des CAs feststellen, ob das Zertifikat wirklich von diesem CA ausgestellt wurde. Um ein Zertifikat zu bekommen, muss die Identität des zu zertifizierenden Objektes nachgewiesen werden. Zum Beispiel können sich Privatpersonen in Deutschland kostenlos beim TC Trustcenter (http://www.trustcenter.de) zertifizieren lassen, wobei es hier verschiedene Zertifikatklassen gibt, die sich nach dem Grad der Identifizierung (E-Mail-Adresse, Personalausweis) richten.

Zertifikate werden z. B. in folgenden Bereichen eingesetzt:

In diesem Kapitel wird der Aufbau eines Zertifikats nach dem X.509-Standard dargestellt. Ein solches Zertifikat enthält die folgenden Datenfelder [NET98]:

Name	Erläuterung
Datensektion
Version	Versionsnummer des X.509-Standards, der von diesem Zertifikat unterstützt wird
Seriennummer	Diese Seriennummer identifiziert eindeutig das Zertifikat aus der Menge der von dem ausstellenden CA ausgestellten Zertifikate.
Informationen über den öffentlichen Schlüssel des Zertifikatinhabers	Diese Informationen enthält das benutzte Kryptosystem und den öffentlichen Schlüssel selbst.
DN des ausstellenden CAs	Die DN enthält Informationen, die den CA identifizieren.
Gültigkeitszeitraum
DN des Zertifikatinhabers	Die DN enthält Informationen, die den Zertifikatinhaber identifizieren.
Zertifikaterweiterungen
Signatursektion
Kryptosystem, mit dem der CA das Zertifikat signiert
Digitale Signatur des CA	Aus den Daten des Zertifikats wird ein Hash-Wert generiert und dieser mit dem öffentlichen Schlüssel des CA verschlüsselt.

Tabelle 1: Zertifikat nach dem X.509-Standard ([NET98])

Hier ein Beispiel für ein X.509-Zertifikat in einer für Menschen lesbaren Form [NET98]:

Abbildung 4: CA-Hierarchie ([NET98])

Jede Software, die mit Zertifikaten umgehen kann, hat eine Liste von Zertifikaten von CAs, denen sie vertraut. Sie vertraut somit auf die Korrektheit aller Zertifikate, die von diesen CAs ausgestellt wurden und werden. Nun kann es sein, dass große Organisationen, die als CA auftreten, die Ausstellung von Zertifikaten an untergeordnete CAs delegieren, z. B. weil die Anzahl der Zertifikate zu groß ist, um von einem einzigen CA verwaltet werden zu können oder weil verschiedene Länder oder Organisationseinheiten verschiedene Identifizierungsmechanismen bedingen. Auf diese Weise entsteht eine sog. CA-Hierarchie (Abbildung 4).

In dem Beispiel sieht man die Aufteilung der CAs nach Regionen und Organisationsformen. Die Zertifikate von CAs, die einem anderen CA direkt untergeordnet sind, werden durch den übergeordneten CA signiert. Zum Beispiel werden in Abbildung 4 die Zertifikate von dem Asia CA, dem Europe CA und dem USA CA von dem Root CA signiert. Das Zertifikat des an der Spitze der Hierarchie stehenden CAs (hier der Root CA) wird von dem Root CA selbst signiert. Vertraut eine Software einem bestimmten CA, so vertraut sie allen Zertifikaten, die von diesem CA ausgestellt wurden, also auch allen ihm untergeordneten CAs. Es kann z. B. sein, dass die prüfende Software nur dem Root CA vertraut, nicht aber der ausstellenden Stelle, dem Engineering CA. Damit die Software dem Zertifikat trauen kann, muss in der Hierarchie eine "Kette des Vertrauens" von dem Engineering CA zum Root CA existieren. Der Verifizierungsprozess läuft am unteren Ende der Kette beginnend in folgenden Schritten ab:

In der folgenden Abbildung ist die Kette vom Engineering CA zum Root CA dargestellt:

Abbildung 5: CA-Kette ([NET98])

Das deutsche Signaturgesetz wurde 1997 im Artikel 3 des Gesetzes zur Regelung der Rahmenbedingungen für Informations- und Kommunikationsdienste (IUKDG) formuliert. Dessen Ziel ist es, eine Sicherheitsinfrastruktur aufzubauen, die eine Zuordnung von öffentlichen Schlüsseln zu ihren Besitzern ermöglicht und damit die Grundlage für elektronische Unterschriften von Dokumenten legt. In § 2 wird eine Bestimmung des Begriffs der digitalen Signatur vorgenommen. Demnach ist eine digitale Signatur "...ein mit einem privaten Schlüssel erzeugtes Siegel zu digitalen Daten, das mit Hilfe eines zugehörigen öffentlichen Schlüssels, der mit einem Signaturschlüssel-Zertifikat einer Zertifizierungsstelle oder der Behörde nach § 3 versehen ist, den Inhaber des Signaturschlüssel und die Unverfälschbarkeit der Daten erkennen läßt ... " ([SIG97]). Das Ausstellen der Zertifikate für Nutzer (z. B. Privatpersonen oder Unternehmen) übernehmen Zertifizierungsstellen, die von der zuständigen Behörde eine entsprechende Genehmigung erhalten haben. Die Zertifikate der Zertifizierungsstellen werden von der zuständigen Behörde signiert. In § 16 wird die Bundesregierung dazu ermächtigt, Gesetze zu erlassen, die nähere Einzelheiten zu Genehmigungsverfahren, Anforderungen an die Zertifizierungsstellen, die Signierung von Dokumenten usw. regeln.

Abbildung 6: Passwortbasierte Autorisierung ([NET98])

Der Benutzer gibt seinen Namen und sein Passwort ein und sendet es über das Netzwerk an den Server. Anhand des Passworts authentifiziert der Server die Identität des Client und autorisiert den Client für den Zugriff auf die gewünschte Ressource. Der Client hat dafür Sorge zu tragen, dass er sein Passwort geheimhält. Ein häufiges Problem ist die Benutzung von sog. schwachen Passwörtern, also Passwörtern, die aus gebräuchlichen Bezeichnungen bestehen und durch geschicktes Raten oder mit Hilfe von elektronischen Wörterbüchern ermittelt werden können. Eine weitere Schwachstelle ist die Übertragung von Name und Passwort über das Netzwerk, die bei den gebräuchlichen Internetprotokollen auf der Verarbeitungsschicht (Kapitel 4.1) unverschlüsselt erfolgt. Natürlich muss auch der Webserver gegen unberechtigten Zugriff abgesichert sein.

Abbildung 7: Zertifikatbasierte Autorisierung bei einer SSL-Verbindung ([NET98])

Abbildung 7 zeigt die Schritte bei einer zertifikatbasierten Autorisierung während einer SSL-Verbindung (Kapitel 4.4):

Der potenzielle Schwachpunkt des Systems ist das Passwort des Client zum Zugriff auf seine privaten Schlüssel. Desweiteren ist der Server vor unberechtigtem Zugriff zu schützen.

Bei "Zero Knowledge"-Protokollen besitzt der Benutzer ein Geheimnis, mit dem er sich authentifizieren kann, ohne das Geheimnis dem Kontrolleur preisgeben zu müssen. Das bekannteste Zero-Knowledge-Authentifizierungsverfahren ist das von Feige, Fiat und Shamir ([SCH96]). Die zur Autorisierung und Authentifizierung benötigten Daten können auf einer Chipkarte gespeichert werden (Beispiele: Student Identity Card der Universität Leipzig, GeldKarte, CAFE (Kapitel 5.3)). Eine weitere Möglichkeit stellt die Heranziehung von charakteristischen biometrischen Merkmalen einer Person zur deren eindeutigen Identifizierung dar. Geeignete physiologische Merkmale sind z. B. das Aussehen des Gesichtes, der Hand oder der Fingerkuppen (Fingerabdruck). Daneben gibt es eindeutige Verhaltensmerkmale, z. B. die Stimme oder die Schreibbewegung.

Abbildung 8: Nachrichtenübertragung ([SET99])

Abbildung 8 zeigt eine sichere Kommunikation zwischen den beiden fiktiven Personen Alice und Bob. Alice will eine Nachricht an Bob schicken. In einer elektronischen Zahlungsumgebung übernimmt Alice die Rolle einer Kundin, die ihre Order- und Zahlungsinformationen an den Händler Bob übermitteln will. Es werden dazu die folgenden Schritte durchgeführt:

Bob empfängt die Nachricht wie folgt:

Die gezeigte Kommunikation erfüllt weitgehend die in Kapitel 2 aufgestellten Sicherheitsanforderungen:

Inhaltsverzeichnis         Kapitel 1         Kapitel 2         Kapitel 3         Kapitel 4         Kapitel 5         Kapitel 6         Literaturverzeichnis