Certification Authority im Internet


4 SICHERUNGSMÖGLICHKEITEN IM WWW

Derzeit wird intensiv an Sicherungsmöglichkeiten für das World Wide Web (WWW) gearbeitet, wobei aber heute eigentlich nur 3 verschiedene Verfahren weit verbreitet sind.

Wie stark diese Technologie noch am Anfang ihrer Entwicklung ist, zeigt, daß es noch kaum Standards in diesem Bereich gibt.

4.1.1 Einführung
4.1.1.1 OSI - Schichtenmodell
4.1.1.2 TCP/IP - Protokolle (Internet)
4.1.2 WWW-Server : Basic Authentication Mechanismus
4.1.2.1 Zugriffsautorisierung des Benutzers
4.1.2.2 Zugriffsautorisierung auf Grund der Rechneradresse
4.1.2.3 Schwachstellen
4.1.2.3.1 Benutzerauthentifizierung
4.1.2.3.2 Datenübertragung
4.1.2.4 Rechneradresse des Benutzers
4.1.2.5 Einsatzm"glichkeiten
4.1.3 S-HTTP (Secure Hypertext Transfer Protocol),
4.1.4 Secure Socket Layer (SSL)
4.1.4.1 Verbindungsaufbau - anwendungsbezogen
4.1.4.2 Merkmale des Browser's nach dem Aufbau einer sicheren Verbindung
4.1.4.3 Verbindungsaufbau - technisch gesehen:
4.1.4.4 Zertifizierung
4.1.4.5 Schwachstellen
4.1.4.5.1 Einseitige Zertifizierung
4.1.4.5.2 Lönge des Sitzungsschlüssel
4.1.4.6 Pseudozuföllig erzeugter Sitzungsschlüssel
4.1.5 Vergleich S-HTTP und SSL
4.2 ELEKTRONISCHE POST
4.2.1 Was passiert beim Absenden einer E-Mail ?
4.2.2 L"sungen zur Sicherung elektronischer Post
4.2.3 PGP (Pretty Good Privacy)
4.2.3.1 Allgemeines
4.2.3.2 Funktionsweise
4.2.3.3 Schlüsselmanagement
4.2.3.3.1 Öffentlicher Schlüssel
4.2.3.3.1.1 PGP-Keyserver
4.2.3.3.1.2 ARGE-DATEN
4.2.3.3.2 Privater Schlüssel
4.2.3.4 Schwachstellen bei Mehrbenutzersystemen
4.2.4 PEM (Privacy Enhanced Mail)
4.2.4.1 Funktionsweise
4.2.5 Firewall
4.2.5.1 Aufbau einer Firewall :
4.2.5.2 Konfiguration einer Firewall :
4.2.5.3 Arten von Firewalls

4.1.1 Einführung

Datenkommunikation wird oft nach einem Client-Server Modell durchgeführt, d.h. ein System (z.B. Web-Server) bietet seine Daten an, und ein oder mehrere Client's können diese Daten nutzen, siehe Abbildung 15 .

Mit Hilfe eines WWW-Clients (Web-Browser) und einer URL kann auf einen Web-Server zugegriffen werden, Internetverbindung natürlich vorrausgesetzt. Als Ergebnis retourniert der Web-Server die gewünschte Web-Seite, die vom Browser angezeigt wird.

Im folgenden wird nun dieser Vorgang technisch genauer beleuchtet:

Um die einzelnen Komponenten, die an der Kommunikation beteiligt sind, sowie deren Beziehungen verstehen zu können, wird oft ein Schichtenmodell zur Darstellung verwendet.

Abbildung 15 - Client-Server Modell

4.1.1.1 OSI - Schichtenmodell

Die ISO erkannte bereits 1977 die Notwendigkeit, den Bereich der Rechnerkommunikation zu normen. Ziel dieser Standards ist die herstellerunabhängige Kooperation zwischen verschiedenen örtlich getrennten realen Systemen, z.B Rechnernetzwerke. Diese Aufgabe übernahm das _Subcommitee 16ä mit der Bezeichnung Open Systems Interconnection (OSI). Es wurde ein Basisreferenzmodell geschaffen, auch OSI-Architekturmodell (OSI Basic Reference Model ) genannt Abbildung 16 - ). OSI beschäftigt sich aber ausschließlich mit den Regeln für die Kooperation zwischen Systemen im Verbund. Das interne Verhalten der realen Systeme, z.B. die konkrete technische Realisation, ist dabei für OSI belanglos.


Abbildung 16 -
OSI Referenzmodell

Jeder der 7 Schichten sind klar abgegrenzte Aufgaben zugeordnet. Dabei bietet jede Schicht bestimmte Dienste an die darüberliegende Schicht an, bzw. nimmt sie von der darunterliegenden Schicht Dienste in Anspruch. Die Schichten untereinander kommunizieren über ein gemeinsames Protokoll (_gemeinsame Spracheä).

Die unteren 4 Schichten befassen sich mit dem Informationstransport, Schicht 5 und 6 mit dem Problemkreis des _Verstehensä und Schicht 7 mit der Verarbeitung derselben .

4.1.1.2 TCP/IP - Protokolle (Internet)

Umgelegt auf die Kommunikation im Internet bedeutet dies (siehe Abbildung 17 - ):

Erklärung TCP/IP - Protokollfamilie:

Die unterste Schicht umfaßt den Bereich Hardware, physische Verbindung und die Übertragung der Datenpakete auf Bit-Ebene.

Die IP-Schicht erfüllt Dienste, Verbindungsauf- und Verbindungsabbau auf IP-Ebene (Schicht), Paketvermittlung zwischen den einzelnen Knoten (Rechnern). Jeder Knoten muß einen eindeutigen Namen (entspricht IP-Adresse bzw. Namen) besitzen, damit das IP-Paket vom Sender zum Empfänger geleitet werden kann. Dieser Vorgang wird auch Routing genannt.

Die TCP- Schicht hat Aufgaben, wie Verbindungsauf- und Verbindungsabbau auf TCP-Ebene (Schicht), Wegoptimierung, Fluß- und Fehlerkontrolle, Aufteilung des Datenstromes in einzelne Pakete, d.h. da oft mehrere Wege vom Sender zum Empfänger existieren, soll der optimale Weg bestimmt werden (Übertragungsdauer, Auslastung, Kosten, Qualität der Verbindung). Zusätzlich muß sichergestellt werden, daß kein Paket während der Übertragung verlorengegangen ist oder dieses fehlerhaft übertragen wurde (eventuell nochmals gesendet werden muß) und die Pakete in richtiger Reihenfolge beim Empfänger wieder zusammengesetzt werden, da z.B. jedes Paket über einen anderen Weg (Route) gesendet werden könnte, und aufgrund der Übertragungsverhältnisse der einzelnen Wege (z.B. Übertragungsdauer) die Empfangsreihenfolge der Pakete nicht gleich der Sendereihenfolge sein muß.


Abbildung 17 -
Vergleich OSI Modell - TCP/IP- Protokolle Beispiel (siehe Abbildung 18 ):

Der Web-Client fordert mit einem HTTP -Request vom Web-Server die gewünschte Web-Seite an (über URL). Der Client fordert die unterliegende Schicht (TCP) auf, eine Verbindung aufzubauen, diese wiederum fordert die nächste Schicht (IP) zum Verbindungsaufbau auf, usw. Nach erfolgreichem Aufbau kann der Client einen HTTP-Request zum Web-Server übermitteln. Dazu wird dieser Request in Form eines Datenpakets zum Server gesendet, wobei jede Schicht die entsprechenden Informationen, gemäß ihrer Aufgabe (z.B. Routing, Fehlerkontrolle, usw. ), hinzufügt. Serverseitig wird beim Durchlauf der Schichten die entsprechende Information vom Datenpaket wieder getrennt und verarbeitet. Der Web-Server erhält den HTTP-Request und sendet das geforderte Dokument als HTTP-Response. Dazu übergibt er die Daten an die darunterliegende Schicht (TCP), usw. Der Client erhält die Daten und zeigt sie dem Benutzer.


Abbildung 18 -
Funktionsweise WWW-Verbindung

4.1.2 WWW-Server : Basic Authentication Mechanismus

Dieses Verfahren ermöglicht eine Sicherung der Web-Seiten auf Zugriffsebene, d.h. nur der Zugriff wird gesichert und nicht die Übertragung der Daten selbst. Da die Web-Seiten auf einem Web- Server in verschiedenen Verzeichnissen abgelegt sind, kann so z.B. das Verzeichnis, in dem sich ein Dokument befindet, das nur für bestimmte Benutzer aufrufbar sein soll, mit einem Usernamen und einem dazugehörigen Paßwort geschützt werden. Der Schutz kann auf zwei verschiedene Arten, wobei auch eine Kombination möglich ist, erreicht werden.

Zugriffsautorisierung des Benutzers (Benutzername, Paßwort) Zugriffsautorisierung auf Grund der Rechneradresse, auf dem der Web-Browser verwendet wird

4.1.2.1 Zugriffsautorisierung des Benutzers:

Beschreibung:

1. Der Benutzer greift mit seinem Web-Browser(Client) ganz normal auf die gewünschte Web-Adresse zu, da dem Benutzer noch nicht bekannt ist, ob es sich um ein geschütztes Dokument handelt oder nicht.

2. Der Server verweigert nun die Auslieferung und übermittelt dem Client auf HTTP-Ebene, daß dieses Dokument geschützt ist (Statuscode 401, äUnauthorized to access the document'). Gleichzeitig teilt er dem Client mit, durch welches Authentifizierungsverfahren dieses Dokument geschützt ist, in diesem Fall Basic Authentication. HTTP ist offen für beliebige Authentifizierungsverfahren, wobei derzeit nur das Basic Authentication Verfahren standardisiert ist.

3. Unterstützt der Client das verwendete Authentifizierungsverfahren, wobei alle HTTP-konforme Clients das Basic Authentication Verfahren unterstützen, so zeigt der Client einen Dialog an, wo ein Benutzername(User Name) und das dazugehörige Paßwort(Paßword) eingegeben werden kann. Diese Daten werden an den Server übermittelt, siehe Abbildung 19 - .


Abbildung 19 -
Basic Authentication Passwort Dialog 4. Der Server überprüft die Richtigkeit und liefert im Erfolgsfall das angeforderte Dokument. Wird die Berechtigung verweigert, so erscheint am Client die Meldung _Authorization required Your browser is not authorization capable, or authentication failedä.

4.1.2.2 Zugriffsautorisierung auf Grund der Rechneradresse

Beschreibung:

1. Der Benutzer greift, wie beim vorigen Verfahren bereits beschrieben, mit seinem Web-Browser(Client) ganz normal auf die gewünschte Web-Adresse zu.

2. Der Server überprüft, ob ein Zugriff auf das gewünschte Dokument von dem Rechner, auf dem der Web-Browser läuft, gestattet ist. Der Web-Server erhält die Absenderadresse (IP-Adresse) aus dem HTTP-Request-Paket. Ist der Zugriff gestattet, so wird die aufgerufene Seite übermittelt. Hat der Benutzer keine Berechtigung, so erscheint die Meldung:

403 Forbidden Your client does not have permission to get URL / from this server

4.1.2.3 Schwachstellen

Die oben beschriebenen Verfahren weisen jedoch einige Schwachstellen auf:

4.1.2.3.1 Benutzerauthentifizierung

Wie in Punkt 3 (Zugriffsautorisierung des Benutzers) beschrieben, werden die Benutzerdaten an den Server übermittelt. Dabei werden diese Daten zwar nicht im Klartext übertragen, jedoch ist die Verschlüsselung unzureichend, z.B. Benutzername meier mit Paßwort sierten hat folgendes Aussehen im Header des HTTP-Requests:

Authorization: Basic bWVpZXI6c2llcnRlbjEwMg== Als Verschlüsselungsverfahren wird die Base64-Kodierung verwendet. Ist ein Hacker nun im Besitz dieses HTTP-Datenpakets, so kann er bequem mittels eines Dekodierungsprogramms z.B. mmencode die Daten entschlüsseln. Unter Unix erhält man mit folgendem Befehl:

echo 'bWVpZXI6c2llcnRlbjEwMg==' | mmencode -b -u als Ergebnis die Zeichenfolge:

meier:sierten entspricht dem Benutzernamen meier mit Paßwort sierten102.

4.1.2.3.2 Datenübertragung

Hat nun der Benutzer die Zugriffsberechtigung erhalten, so werden die Dokumente nach wie vor im Klartext übertragen, somit ist die Datenübertragung selbst ungeschützt, d.h. bei Übertragung vertraulicher Daten besteht kein Schutz.

4.1.2.4 Rechneradresse des Benutzers

Man kann sich nicht darauf verlassen, daß die Rechneradresse immer korrekt ist. Versierte Hacker sind durchaus in der Lage, Absenderadressen zu fälschen, um so Zugang zu erhalten.

4.1.2.5 Einsatzmöglichkeiten

In Kapitel 3.2.1 Sicherheitsanforderungen allgemein, wurden die Maßnahmen beschrieben, um eine sichere Kommunikation zu erreichen. Von diesen fünf Punkten erfüllt Basic Authentication nur einen Punkt, die Authentifikation, teilweise, wobei selbst diese als keineswegs sicher anzusehen ist.

Da die Datenübertragen ungesichert erfolgt, ist abzuwägen, wie schützenswert oder wertvoll die Daten sind, die mit Basic Authentication geschützt werden sollen.

Der Anbieter muß nun abwägen, wie groß der Schaden bei unberechtigtem Eindringen sein kann bzw. in welchem Verhältnis ein Einbruch zu dem angestrebten Gewinn steht. So kann für einen Verlag Basic Authentication durchaus ausreichend sein, um z.B. nur registrierten Abonnenten kostenpflichtige Publikation zugänglich zu machen. Selbst wenn ein Hacker das Benutzername/Paßwort-Paar herausfindet und so kostenpflichtige Artikel abrufen sollte, hält sich der finanzielle Schaden in Grenzen.

Für personenbezogene Daten oder für strategische, interne Unternehmenspapiere ist Basic Authentication sicher nicht ausreichend.

4.1.3 S-HTTP (Secure Hypertext Transfer Protocol)

Entwickelt wird dieses System von Teresia Systems, ein Joint Venture von RSA Data Security Inc. und EIT Enterprise Integration Technologies, welches in erster Linie für das Commerce Net gedacht war und welches das sichere Abwickeln von Geschäften via Internet ermöglichen soll.

Beim Secure HTTP handelt es sich um ein neues Protokoll, das ähnlich wie das HTTP-Protokoll aufgebaut ist und als Inhalt gewöhnliche HTTP-Nachrichten kapselt. Es werden aber nicht nur Erweiterungen am Transportprotokoll vorgenommen, sondern auch zusätzliche HTML Elemente eingeführt. Zum Unterschied von HTTP können bei der Datenübertragung die Datenpakete durch eine beliebige Kombination aus 3 Mechanismen geschützt werden:

digitale Unterschrift Datenverschlüsselung Authentifizierung Zusätzlich hat der Absender die Möglichkeit, jeder der genannten Kombinationen mittels Hash-Funktion einen Message Digest mitzusenden, der die Datenintegrität gewährleistet. Enthält der Message Digest auch einen Zeitstempel, so kann die Kommunikation auch vor _Replay-Attacken ä geschützt werden. In S-HTTP werden eine ganze Reihe von verschiedenen symmetrischen und asymmetrischen Verfahren für den Verbindungsaufbau (initialer Handshake), für Chiffrierung, digitale Unterschriften, verschiedene Hashfunktionen für die Berechnung des Message Digest unterstützt. Die tatsächlich verwendeten Verfahren werden beim Verbindungsaufbau zwischen Client und Server ausgehandelt. Als Format für die gekapselten Nachrichten werden bislang PEM, PGP und PKCS#7 (PEM ähnlich von RSA DS1) unterstützt.

Im Gegensatz zu SSL sind die kryptographischen Verfahren nicht auf Verbindungs- , sondern auf der Anwendungsebene realisiert. Es gibt auch die Möglichkeit, Schlüssel für symmetrische Chiffrierung auf externem Weg (Telefon, Fax, Post, usw.) auszutauschen und für eine spätere S-HTTP-Kommunikation einzusetzen.

Die Entwickler des Protokolls modifizierten Mosaics- und NCSA- Webserver und stellen den Mitgliedern des Net-Konsortiums ein Toolskit für eigene S-HTTP-Entwicklungen zur Verfügung. Verschiedene Firmen, unter anderm Netscape Communications, haben die Integration des Protokolls in ihren Produkten angekündigt.

4.1.4 Secure Socket Layer (SSL)

Wie der Name bereits andeutet, wird bei SSL eine zusätzliche Schicht über den üblichen Socket eingeführt (siehe Abbildung 20 - ).


Abbildung 20 -
Schematische Darstellung SSL Diese Schicht ermöglicht:

Authentifizierung des Servers Aufbau einer sicheren Verbindung D.h. der Benutzer kann sicher gehen, daß der angewählte Server der wirkliche Server ist und nicht nur ein Doubel, die Datenübertragung erfolgt nach erfolgreichem Verbindungsaufbau verschlüsselt.

Für die Anwendungen erscheint diese Schicht als herkömmlicher Socket, d.h. bereits bestehende Anwendungen können ohne Veränderungen weiterbetrieben werden. Dieses Verfahren ist nicht alleine auf WWW (HTTP) beschränkt, sondern es kann für jedes auf TCP/IP basierende, höhere Protokoll verwendet werden, z.B. FTP, Telnet, NNTP (Net News Transfer Protocol) - Protokoll für Newsgroups, SMTP (Simple Mail Transfer Protokoll) - Protokoll für elektronischen Briefverkehr, usw.

Um jedoch die Vorzüge von SSL nutzen zu können, müssen die Anwendungen und Server die Funktionen von SSL unterstüzen.

Derzeit ist SSL nur für HTTP (WWW) verfügbar, entsprechende Server sind z.B. der Secure Server von der Firma Netscape oder Alibaba von der Firma CSM . Als Client eignet sich derzeit nur der Browser Navigator, Version 2.0b1 oder höher, der Firma Netscape.

4.1.4.1 Verbindungsaufbau - anwendungsbezogen

Anders als bei herkömmlichen Web-Servern beginnt die Adresse mit https://.... . Es gibt nun 2 Möglichkeiten:

1.) Der Browser anerkennt das Zertifikat des Servers, alle bereits anerkannten Zertifikate sind über Menüpunkt Options/Security Preference/Site Certificate (siehe Abbildung 21 - ) mit Auswahlmöglichkeit All Certificates im Netscape's Browser abrufbar.


Abbildung 21 -
Bekannte Zertifikate Über Edit Certificate werden die genauen Eigenschaften des Zertifikats angezeigt (siehe Abbildung 22 )
Abbildung 22 -
Zertifikat Es erscheint nur mehr ein Hinweis (einstellbar), ob in einen gesicherten Zustand gewechselt werden soll (siehe Abbildung 23 ).


Abbildung 23 -
Hinweis bei Wechsel in sicheren Zustand Wird dem zugestimmt, so wird eine sichere Verbindung aufgebaut (siehe Kapitel 4.1.4.2 Merkmale des Browser's nach dem Aufbau einer sicheren Verbindung, ) 2.) Dem Browser ist das Zertifikat unbekannt (siehe Abbildung 24)
Abbildung 24 -
Zertifikat unbekannt Die folgenden Dialoge fragen ab, ob das Zertifikat als gültig anerkannt werden soll, entweder nur für diese Session oder auch für nachfolgende Sessions. Im letzten Fall wird das Zertifikat in die Zertifikatliste aufgenommen ( Abbildung 21 ). Es erscheint noch ein Hinweis (einstellbar), ob in einen gesicherten Zustand gewechselt werden soll (siehe Abbildung 23).

4.1.4.2 Merkmale des Browser's nach dem Aufbau einer sicheren Verbindung

Abbildung 25 zeigt typische Merkmale.


Abbildung 25 -
Merkmale des Netscape-Browser bei einer sicheren Verbindung Diese sind :

1. Die angewählte Server-Adresse(URL) ist https://.... und nicht http://...., wie bei herkömmlichen Web-Servern. Durch die URL https://.... wird der Port angewählt anstatt des Standardsports 80 für http://.... . Mit Portnummer wird der einzelne Dienst eines Rechners angesprochen und kann als Untereinheit einer IP-Adresse angesehen werden, z.B. Port 21 - Dienst für FTP, Port 23 - Dienst für telnet, usw. 2. Das Schlüsselsymbol zeigt einen ganzen Schlüssel an, d.h. die Übertragung der Daten ist sicher. Ein gebrochener Schlüssel würde einer unsicheren Verbindung entsprechen. 3. Es erscheint ein Balken, der zusätzlich anzeigt, daß eine sichere Verbindung gegeben ist.

4.1.4.3 Verbindungsaufbau - technisch gesehen :

Vor der Übertragung der eigentlichen Daten wird vom Client und vom Server ein Handshake-Protokoll abgearbeitet: 1.) In einer sogenannten _Hello-Phaseä baut der Client eine Verbindung zum Server auf und übermittelt ihm: Einmalwert EC (challange) Liste der unterstützten Verschlüsselungsverfahren sofern vorhanden, eine Session-ID aus einer früheren Sitzung 2.) Der Server antwortet mit einer neuen Connection-ID. Falls sich die angegebene Session-ID noch im Cache des Servers befindet, können beide Seiten den früher vereinbarten Hauptschlüssel (Master Key) verwenden. Andernfalls sendet der Server: sein Zertifikat, das unter anderem den öffentlichen Schlüssel des Servers enthält. Mit Hilfe dieses Zertifikats kann der Client überprüfen, ob die Antwort wirklich vom gewünschten Server stammt. Liste der unterstützten Verschlüsselungsverfahren 3.) Der Client generiert einen neuen Master Key. Diesen Schlüssel chiffriert der Client mit dem öffentlichen Schlüssel des Servers und sendet diesen an den Server.

4.) Sowohl Client und Server erzeugen aus dem Hauptschlüssel und den verbindungsbezogenen Daten mittels einer Hashfunktion (MD5 87) zwei Sitzungsschlüssel (Session Keys). Für Sende- und Emfangsrichtung wird dabei ein eigener Sitzungsschlüssel benutzt.

5.) Der Client schickt die mit dem Sendeschlüssel chiffrierte Connection-ID an den Server.

6.) Der Server sendet den mit dem Sendeschlüssel verschlüsselten Einmalwert EC (der in Punkt 1 an den Server übermittelt wurde) an den Client zurück.

7.) Der Client überprüft mit Hilfe seines Empfangsschlüssels , ob der Einmalwert mit dem von ihm gesendeten übereinstimmt. Damit kann der Client sicher gehen, daß der Server als der tatsächliche Inhaber des Zertifikats authentisch ist, denn andernfalls könnte der Server den Master Key nicht korrekt dechiffrieren und folglich auch keinen Sitzungsschlüssel erzeugen.

8.) Der Server kann ebenfalls die Authentität des Clients überprüfen. Dieser Fall tritt jedoch nur dann ein, wenn der Client ein öffentliches Zertifikat besitzt. Der Server sendet einen Einmalwert ES und eine Liste der unterstützten Verschlüsselungsverfahren. Der Client antwortet mit seinem Zertifikat und einer Authentifizierungsinformation. Diese Information besteht aus einem Digest (Fingerabdruck), welches mittels MD5 aus dem Sende- und Empfangsschlüssel, den Einmalwert ES und dem Zertifikat des Servers erzeugt und mit dem privaten Schlüssel des Clients chiffriert wurde.

9.) Der Server schickt dem Client verschlüsselt die neue Session-ID.

10.) Beide Seiten schließen den initialen Verbindungsaufbau ab und chiffrieren nun alle weiteren Datenpakete mit dem Sitzungsschlüssel. Dabei wird das Verschlüsselungverfahren RC4 verwendet.

Als Zertifikat wird derzeit das X. 9-Format89 verwendet, wobei allerdings auch andere Formate und Authentifikationsmechanismen leicht hinzugefügt werden könnten.

4.1.4.4 Zertifizierung

Damit ein Server als sicher gilt, muß dessen Zertifikat von einer als zuverlässig geltenden Stelle verfiziert worden sein.

VeriSign, Inc. ist derzeit eine der bekanntesten Firma weltweit, die die Zertifizierung von Personen und Web-Servern durchführt. Die Zertifizierung von Web-Servern ist deshalb nötig, um den Einsatz von SSL bei einer Web-Verbindung zu ermöglichen.

Seit April 1996 bietet auch ARGE-DATEN (Österreichische Gesellschaft für Datenschutz) die Verwaltung und Zertifizierung von öffentlichen Schlüsseln für Personen an, siehe http://keyserver.ad.or.at/ .

4.1.4.5 Schwachstellen

4.1.4.5.1 Einseitige Zertifizierung

Derzeit ist nur eine Zertifikation eines Servers vorgesehen, nicht jedoch eine für einen Client bzw. Benutzer.

4.1.4.5.2 Länge des Sitzungsschlüssel

Als sicher kann die Übertragung der Daten nur in den USA angesehen werden. Um eine Exportlizenz zu erhalten, mußte aufgrund der strengen Exportbestimmungen, die für Verschlüsselungsalgorithmen in den USA herrschen, der Sitzungsschlüssel auf eine Länge von 40 Bit reduziert werden, womit die Verbindung dann als keineswegs sicher gilt. In den USA- Versionen hat der Sitzungsschlüssel eine Länge von 128 Bit.

So wurde z.B. am 14. Juli 1995 die Internet-Benutzer von Hal Finney dazu aufgefordert den Sitzungsmitschnitt zwischen dem Netscape-Client und dem Netscape Secure Server zu knacken. Damin Doligez aus Frankreich gab am 15. August als erster die Lösung bekannt, unabhängig von ihm knackte eine weitere Gruppe 2 Stunden zuvor die als sicher geltende Verbindung. In beiden Fällen wurde der gesamte Schlüsselraum (alle Möglichkeiten) durchsucht, wobei die Berechnung auf mehrere Computer aufgeteilt wurde, die nach 1 bis 2 Wochen das Ergebnis lieferten .

Bei der zweiten Herausforderung die Hal Finney stellte, gelang es den _Cypherpunksä den Sitzungsschlüssel in nur 32 Stunden zu knacken. Sie verwendeten ein spezielles Verfahren, das ebenfalls den ganzen Schlüsselraum absucht, wobei aber die Aufgabe auf beliebig viele Rechner im Internet verteilt werden kann und dazu lediglich die frei zur Verfügung stehende Rechnerkapazität für die Berechnung verwendet wird.

4.1.4.6 Pseudozufällig erzeugter Sitzungsschlüssel

Oft wird die Tatsache unterschätzt, daß kryptographische Verfahren in Programmen nicht korrekt implementiert sind. So erzeugte der Netscape-Navigator die Sitzungsschlüssel nicht zufällig, sondern lediglich pseudozufällig, d.h. die erzeugten Zufallszahlen sind statistisch nicht gleich verteilt, sondern gehorchen einer bestimmten Funktion. Aufgrund dieser Kenntnis läßt sich die Anzahl der möglichen Schlüssel stark einschränken, und selbst die als sicher geltende, nicht exportfähige 128 Bit Variante scheint verletzlich. Netscape hat aber inzwischen eine korrigierte Version der Softwareprodukte erstellt.

4.1.5 Vergleich S-HTTP und SSL

Im Secure Mosaic, das das S-HTTP einsetzt, werden die verschiedenen Sicherheitsstufen eines Dokuments dem Benutzer mit Icons (Symbolen) angezeigt, z.B. eine unverschlüsselte und unsignierte Nachricht erscheint als einfache Textseite. Enthält die Seite eine digitale Unterschrift, so wird ein Siegel angezeigt, ein verschlüsselter Text steckt in einem Umschlag und ist eventuell mit einem Siegel versehen. Im Gegensatz dazu wird bei SSL nur angezeigt, ob eine sichere Verbindung gegeben ist oder nicht (URL ist https://....., Balken, Schlüsselsymbol, siehe auch Abbildung 25 ).

Da bei S-HTTP kryptographischen Verfahren auf der Anwendungsebene liegen und deshalb sowohl für den Benutzer als auch für den Anbieter zugänglich sind, bietet dieses Verfahren gegenüber SSL eine wesentlich breitere Vielfalt der Anwendungsmöglichkeiten. Bei SSL ist nur der sichere Austausch von Dokumenten möglich, hingegen gibt es bei S-HTTP die zusätzliche Möglichkeit der digitalen Unterschrift, mit dessen Hilfe signierte Dokumente ausgetauscht werden können. Damit könnten Verträge via Internet abgeschlossen, verbindliche öffentliche Mitteilungen verfaßt werden, usw.

Bei S-HTTP erfolgt der Verbindungsaufbau des Clients mit dem Server bereits in verschlüsselter Form, bei SSL wird diese im Klartext durchgeführt.

4.2 Elektronische Post

E-Mail ist eines der wichtigsten elektronischen Kommuniktionsmittel, aber nur wenige Benutzer machen sich Gedanken darüber, wie E-Mails übertragen werden und welche Risiken dabei für den Absender entstehen. Spätestens jedoch wenn man selbst in die Verlegenheit kommt, persönliche oder vertrauliche Daten auf die Reise zu schicken, wird einem die Problematik bewußt, z.B. bei der Übermittlung seiner Kreditkartennummer.

4.2.1 Was passiert beim Absenden einer E-Mail ?

Mail-Systeme arbeiten nach dem Store-and-Forward Prinzip, unabhängig davon, ob als Übertragungsprotokoll SMTP oder X.400 verwendet wird, d.h. ähnlich wie beim herkömmlichen Postverkehr werden die Briefe (Nachrichten) von einem Postamt zum nächsten weitergesendet. SMTP und X.400 sind Standards für die Übertragung von elektronischer Post . Im elektronischen Datennetz übernimmt der Message Transfer Agent (MTA) die Aufgabe eines Postamts. Die MTA's reichen die Nachrichten (E-Mails) im Klartext untereinander weiter. Auf ihrem Weg werden sie so mehrfach zwischengespeichert. Für Administratoren dieser Rechner oder für Hacker, die unerlaubt in solche MTA's eindringen, ist es nun ein leichtes, die ein- und ausgehenden Mails zu lesen, zu kopieren, zu verändern oder Fälschungen durchzuführen.

Zusätzlich können Programme (Filterprogramme) eingesetzt werden, die automatisch, gezielt nach Schlüsselwörtern, Adressen, Kreditkartennummern usw. suchen. Deshalb ist also ein Mail nichts anderes als eine _elektronische Postkarteä, die schnell gesendet werden kann, aber möglicherweise nicht vertraulich am Zielort anlangt und schlimmstenfalls sogar nicht authentisch ist, d.h. Absendername oder Inhalt stimmen nicht mit dem Original überein, z.B. eine politische Partei macht eine Presseaussendung via Internet, welche vom politischen Gegner abgefangen und manipuliert wird.

Als Angriffspunkte gelten hier die gleichen Punkte, die bereits im Kapitel 3.2 Angriffspunkte in Datennetzen:, , beschrieben wurden; ebenso die Kapitel 3.2.1 Sicherheitsanforderungen, und Kapitel 3.2.2 Maßnahmen zur Erhöhung der Sicherheit, .

4.2.2 Lösungen zur Sicherung elektronischer Post

Grundsätzlich gibt es zwei verschiedene Ansätze, um die sichere Übertragung elektronischer Post zu gewährleisten :

1) Volle Integration der Dienste in das verwendete Mail- System, d.h. Anpassung aller Mail-Protokolle, MTA's und User Agents (UA's) , zum Beispiel X.400 (1988) / ISO 1002197. Dies kann erreicht werden durch: 1.1.) Verbindung zwischen den mit Transport von Nachrichten beteiligten Einrichtungen (MTA's, UA's). 1.2.) Anwenden von Sicherheitsfunktionen auf den Nachrichtentext und übertragen der relevanten Informationen in einem _Umschlagä; das ist die der eigentlichen Mitteilung vorangehende Zusatzinformation. 2) Das vorhandene System wird ohne Modifikation der Protokolle und MTA's weiterverwendet. Es wird nur der UA verändert und zwar so, daß die für die Sicherheit notwendigen Daten im Hauptteil der Nachricht transportiert werden. Dieser Ansatz wurde für PGP und PEM gewählt.

4.2.3 PGP (Pretty Good Privacy)

4.2.3.1 Allgemeines

PGP steht für äPretty Good Privacyä, zu deutsch etwa ärecht gute Privatsphäreä, wobei äPretty Goodä auch als Kurzform von äPhil's Pretty Good Softwareä angesehen werden kann. Entwickelt wurde dieses Programm von Philip Zimmermann und im Jahr 1991 zum ersten Mal vorgestellt. Es handelt sich um ein hochsicheres Ver- und Entschlüsselungsprogramm, das für sehr viele verschiedene Rechner und Betriebssysteme bereits erhältlich ist, so z.B. auf MS-DOS, Unix, Macintosh, VAX/VMS usw .

PGP ermöglicht den Austausch von Nachrichten ohne Verzicht auf Privatsphäre (Vertraulichkeit), Authentifikation und Komfort. Unter Privatsphäre versteht man, daß eine Nachricht nur von den gewünschten Adressaten gelesen werden kann. Unter Authentifikation, ob eine Nachricht überprüfbarerweise von der Person stammt, von der sie zu stammen scheint (elektronische Unterschrift), und unter Komfort, daß der Anwender sich keine unnötigen Gedanken darüber machen muß, wo er welche Schlüssel aufbewahrt und welchen Schlüssel er zum Datenaustausch mit wem benutzt.

Richtig eingesetzt, schließt es die Möglichkeit, per E-Mail oder Diskette versandte Daten ohne Berechtigung zu entschlüsseln, weitgehend aus. Es ist aber kaum dazu geeignet, Daten auf einem Computer in komfortabler und zuverlässiger Weise vor fremdem Zugriff zu schützen. Dies sollte bei der Verwendung von PGP beachtet werden.

4.2.3.2 Funktionsweise

PGP bietet folgende Funktionen und verwendet dazu folgende Verfahren :

Funktion Verfahren Beschreibung Zur Erzeugung eines Message Digest wird MD5 verwendet. Digitale Signatur RSA, MD5 Dieser Message Digest wird mittels RSA-Verfahren mit dem privaten Schlüssel des Empfängers chiffriert und an die Nachricht angehängt.

Die Nachricht wird mittels IDEA (symmetrisches Verfahren) chiffriert, als Schlüssel wird Chiffrierung der IDEA, RSA ein One-time session key Nachricht verwendet. Dieser Schlüssel wird mit dem RSA-Verfahren mittels privaten Schlüssel des Empfängers chiffriert und an die Nachricht angehängt.

Die Nachricht kann komprimiert Kompression ZIP (Kompres- werden, womit der Aufwand für sionsverfahre die Übertragung sinkt und das n) Dechiffrieren erschwert wird.

Bei der Übertragung von E-Mails E-Mail kompatible Radix 64 sind oft nur bestimmte Zeichen als Nachrichtentext zugelassen (z.B. keine Umlaute). Damit aber z.B. nach dem Komprimieren eine Übertragung möglich ist, wird dieser in ein ASCII - Format konvertiert, wobei das Radix 64 Verfahren zur Anwendung kommt.

Segmentierung Da die Länge des Nachrichtentextes bei E-Mail- Verfahren oft limitiert ist, nimmt PGP eine Segmentierung und eine Desegmentierung vor.

PGP kann auf verschiedene Arten angewendet werden, so kann z.B. nur Datenverschlüsselung oder nur eine digitale Signatur angefertigt werden, usw. Folgende Abbildung 26 zeigt einen typischen Anwendungsfall in der Praxis.


Abbildung 26 -
Funktionsweise PGP Beschreibung: Sender:

Um das Datenvolumen zu reduzieren und die Angriffe zu erschweren, wird die Nachricht komprimiert. Die Nachricht wird mit einer Signatur versehen, dazu wird ein Message Digest MD erzeugt und mit dem geheimen Schlüssel des Senders unterschrieben (verschlüsselt). MD wird an die Nachricht angehängt. Die Verschlüsselung erfolgt mittels zufällig erzeugtem Schlüssel (Session Key) durch Einsatz des IDEA- Verfahrens. Dieser Schlüssel wird mit dem öffentlichen Schlüssel des Empfängers chiffriert und an die Nachricht angefügt.

Abschließend erfolgt eine Transportcodierung, um die Nachricht in verschiedene Mailsysteme versenden zu können, z.B. SMTP für Internet.

Empfänger:

1.) Decodierung der Transportcodierung 2.) Dechiffrierung des Nachrichteninhaltes, indem PGP den privaten Schlüssel des Empfängers verwendet, um den Session Key für die Dechiffrierung zu erhalten. 3.) Überprüfung der Integrität und Authentizität, der Sender hat den MD mit seinem geheimen Schlüssel verschlüsselt. Dieser wird mit dem authentischen öffentlichen Schlüssel des Senders entschlüsselt. Das Programm des Empfängers erzeugt selbst einen MD und vergleicht diesen mit dem übermittelten. Bei Übereinstimmung wurde die Nachricht nicht verfälscht.

Authentifizierung:

Zur Authentifikation wird das RSA-Verfahren verwendet.

4.2.3.3 Schlüsselmanagement

Der Benutzer kann mit dem Programm PGP ein Schlüsselpaar erzeugen, wozu ein Paßwortnötig ist. Bei jeder Verwendung des privaten Schlüssls ist die Eingabe dieses Paßwortes notwendig.

Zusätzlich wird die Verwaltung von privaten und öffentlichen Schlüsseln unterstützt. Die Schlüssel werden in sogenannten Schlüsselbunden gespeichert (mindestens 1 Schlüsselbund für private Schlüssel und 1 Bund für öffentliche Schlüssel).

4.2.3.3.1 Öffentlicher Schlüssel

PGP gestattet es, andere öffentliche Schlüssel in einen eigenen Schlüsselbund aufzunehmen bzw. können auch öffentliche Schlüssel von anderen Personen mit einer eigenen Unterschrift bestätigt werden, womit Zertifizierungsinstanzen geschaffen werden könnten, z.B. innerhalb eines internationalen Konzerns.

Die Verwaltung von öffentlichen Schlüsseln ist das Hauptproblem bei Public-Key-Verfahren.

Beispiel:

Alice benötigt von Bob den öffentlichen Schlüssel, um eine vertrauliche Nachricht an Bob zu übermitteln. Sie kann sich diesen Schlüssel von einer öffentlichen Stelle besorgen, in der Bob seinen Schlüssel bekannt gab. Jedoch könnte Charlie eine Möglichkeit gefunden haben, Bob's öffentlichen Schlüssel durch einen selbst erzeugten Schlüssel zu ersetzen, wobei er Bob's ID verwendet. Zusätzlich kann Charlie die E-Mail's, die an Bob gesendet werden, abhören bzw. abfangen. Alice glaubt nun, Bob's richtigen Schlüssel zu besitzen, wobei sie aber einen von Charlie hat. Sie sendet nun die verschlüsselte Nachricht an Bob. Charlie fängt diese ab und entschlüsselt sie, da er den privaten Schlüssel dazu hat. Er kann die Nachricht lesen, verändern oder gar nicht weiterschicken. In den ersten beiden Fällen verschlüsselt er die Nachricht mit Bob's richtigem Schlüssel und sendet diese an Bob weiter. Bob erhielt nun ebenfalls einen falschen Schlüssel, als er Alice's öffentlichen Schlüssel holte, womit nun auch Charlie Nachrichten unterschreiben kann, und Bob dies nicht erkennen würde.

Lösungen:

Alice erhält den öffentlichen Schlüssel direkt von Bob, z.B. Diskette, praktisch, aber schwierig.

Überprüfung per Telefon, Bob könnte an Alice den ganzen öffentlichen Schlüssel übermitteln, unpraktisch. Besser ist eine Übermittlung des öffentlichen Schlüssel per E- Mail oder Alice besorgt diesen von einer öffentlichen Stelle. Sie kann nun einen Message Digest (MD5) vom öffentlichen Schlüssel erzeugen, ruft Bob an, und vergleicht den Message Digest von Bob mit ihrem (128 Bit lang, entspricht 32 Zeichen), bestätigt Bob den von ihr vorgelesenen MD. Somit ist der Schlüssel verifiziert.

Eine öffentliche Zertifizierungsstelle (CA) erzeugt ein signiertes Zertifikat. Dieses beinhaltet Bob's öffentlichen Schlüssel, Erzeugungsdatum und Ablaufdatum. Mit MD5 wird ein Message Digest von diesem Zertifikat erstellt, dieses mit dem privaten Schlüssel der CA verschlüsselt und als Signatur an das Zertifikat angehängt. Damit ist sichergestellt, daß nur diese CA das Zertifikat erstellen konnte. Die CA gibt nun ihrerseits den öffentlichen Schlüssel bekannt, womit die Signatur überprüft werden kann. Es könnte natürlich vorkommen, daß unberechtigte Personen Veränderungen in der CA vorgenommen haben. Daher muß der öffentliche Schlüssel von einer übergeodneten CA verifiziert werden, auf die gleiche Weise wie mit Bob's öffentlichem Schlüssel vorgegangen wurde. Dieser Vorgang wird solange wiederholt, bis man zur obersten CA gestoßen ist, der letztendlich vertraut werden muß .

4.2.3.3.1.1 PGP-Keyserver

Derzeit existieren für die Verwaltung von öffentlichen Schlüsseln sogenannte Keyserver.

Diese stellen jedoch keine Garantie für die Authentizität oder Validität eines Schlüssels dar, d.h. es muß die Authentizität noch zusätzlich mit anderen Mitteln überprüft werden (Signatur, usw.).

Um die Antwortzeiten bei Anfragen gering zu halten, wurden zusätzlich zum zentralen Keyserver mehrere nationale Keyserver geschaffen, wobei ein Datenabgleich zwischen den einzelnen Servern erfolgt.

Die Übermittlung des Schlüssels bzw. Abfragen kann mittels E- Mail oder WWW erreicht werden Die folgende Abbildung 27 zeigt das Abfrageergebnis des Keyservers der Universität Tromso (Norwegen), gesuchte Zeichenfolge : _Wolfgangä. Durch Anklicken der ID des gesuchten Schlüssels, wird der Schlüssel zum Benutzer übertragen.


Abbildung 27 -
Abfrage eines PGP-Keyservers

4.2.3.3.1.2 ARGE-DATEN

Seit April 1996 bietet auch ARGE-DATEN (Österreichische Gesellschaft für Datenschutz) die Verwaltung und Zertifizierung von öffentlichen Schlüsseln an, siehe http://keyserver.ad.or.at/ .

4.2.3.3.2 Privater Schlüssel

Dieser sollte möglichst sicher aufbewahrt werden, z.B. nur auf Diskette, nicht auf Festplatte, wobei auch Sicherungskopien davon existieren sollten. Wie bereits erwähnt ist bei Anwendung des privaten Schlüssels die Eingabe des Paßwortes notwendig. Falls Schlüssel oder/und Paßwort verloren gehen oder gestohlen werden, muß der Besitzer dafür sorgen, den öffentlichen Schlüssel für ungültig erklären zu lassen.

2 Fälle:

privater Schlüssel ist noch vorhanden, PGP erlaubt das Erstellen einer Rückrufurkunde, d.h. der öffentliche Schlüssel wird für ungültig erklärt. Diese muß nun an alle Personen geschickt werden, die den öffentlichen Schlüssel benutzen.

Ist der Schlüssel nicht mehr verwendbar, muß ein neues Schlüsselpaar erzeugt werden. Der öffentliche Schlüssel muß neu zertifiziert und die potentiellen Anwender verständigt werden.

4.2.3.4 Schwachstellen bei Mehrbenutzersystemen

PGP wurde nur für den Einsatz von Einzelplatzsystemen entwickelt, daher treten bei Mehrbenutzersystemen folgende Probleme auf:

Übertragung von der Eingabeeinheit (Terminal) zum Server erfolgt oft unverschlüsselt, z.B. bei Unix, d.h. das Paßwort für die Verwendung des privaten Schlüssels wird vom Terminal zum Programm PGP im Klartext übermittelt.

Dateien, in denen sich die Schlüssel befinden, könnten verändert werden.

4.2.4 PEM (Privacy Enhanced Mail)

Die Entwicklung von PEM begann 1985 und wurde erst 1993 als Internet Standard veröffentlicht .

4.2.4.1 Funktionsweise

PEM spezifiziert 2 verschiedene Nachrichtentypen:

1.) integritätsgeschützte, authentische Nachricht - Typ MIC 2.) wie 1, mit zusätzlich verschlüsseltem Nachrichteninhalt - Typ ENCRYPTED Zusätzlich kann die Nachricht vor dem Transport mittels 6 Bit Codierung umgewandelt werden (MIC-ONLY), um Nachrichten in verschiedene Mailsysteme versenden zu können. Falls der Empfänger nicht über PEM verfügt, ist auch das Abschicken ohne Codierung möglich (MIC-CLEAR), siehe Abbildung 28 .


Abbildung 28 -
Funktionsweise PEM Beschreibung:

Sender:

1.) Kanonisierung : Es wird die Nachricht in ein (je nach E-Mail-Protokoll unterschiedliches) Einheitsformat konvertiert (z.B. SMTP, X.400). Dem Empfänger der Nachricht wird dieses Format durch Angabe des Mail-Protokolls im Header der Nachricht mitgeteilt. 2.) Jede PEM-Nachricht wird mit einer Signatur versehen, dazu wird ein Message Digest (hier MIC genannt) erzeugt und mit dem geheimen Schlüssel des Senders unterschrieben (verschlüsselt). MIC, Name der Hashfunktion, öffentlicher Schlüssel und ein Zertifikat dieses Schlüssels werden ebenfalls im Header eingetragen. 3.) Die Verschlüsselung ist optional und erfolgt mittels zufällig erzeugten Schlüssels (DEK - Data Encrypten Key genannt) durch Einsatz des DES - Verfahrens (Standard), wobei auch andere Verfahren möglich sind, Angabe im Header. Der DEK wird wiederum mit dem öffentlichen Schlüssel des Empfängers (IK - Interchange Key) verschlüsselt und ebenfalls im Header mitgesendet. Um den Empfänger eindeutig zu identifizieren, wird bei Typ ENCRYPTED eine Empfänger ID im Header angegeben, bei mehreren Emfängern wird für jeden eine Empfänger ID benötigt. 4.) Abschließend erfolgt optional eine Transportcodierung, um die Nachricht in verschiedene Mailsysteme versenden zu können, z.B. SMTP für Internet Beispiel :

-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC,BFF968AA74691AC1 Originator-Certificate: MIIB..... Key-Info: RSA, I3rRI..... Issuer-Certificate: MIIB..... MIC-Info: RSA-MD5,RSA, UdFJ..... Recipient-ID-Asymmetric: MFEx..... Key-Info: RSA, O6BS.....

< -- ab hier beginnt der Nachrichteninhalt -- > qeWlj/a4LqKeq3ciFzEv/MbZhA== ... -----END PRIVACY-ENHANCED MESSAGE----- Empfänger:

1.) Optionale Decodierung der Transportcodierung 2.) Optionale Entschlüsselung des Nachrichteninhaltes, indem PEM's Key Info mit dem eigenen privaten Schlüssel dechiffriert wird, wodurch der DEK-Key gewonnen wird. Die Nachricht kann nun entschlüsselt werden. 3.) Überprüfung der Integrität und Authentizität. Der Sender hat den MIC mit seinem geheimen Schlüssel verschlüsselt. Dieser wird mit dem authentischen, öffentlichen Schlüssel des Senders entschlüsselt, zusätzlich erhält man das Zertifikat des Senders und kann die MD des Zertifikats mit dem MD des verwendeten, öffentlichen Schlüssel vergleichen. Der Empfänger erzeugt selbst einen MIC und vergleicht diesen mit dem übermittelten. Bei Übereinstimmung wurde die Nachricht nicht verfälscht.

Authentifizierung:

Zur Authentifikation wird das RSA-Verfahren verwendet.

Die Zertifizierung des öffentlichen Schlüssels wird mit dem X.509 (Internet Public-key Certification Standard) Modell erreicht (siehe Abbildung 29 ).


Abbildung 29 -
Zertifizierung bei PEM
Die Internet Registration Certification Authority (IPRA) ist Wurzel-CA in diesem Zertifizierungsmodell. IPRA arbeitet unter der Kontrolle der Internet Society (ISOC) . IPRA zertifiziert die Policy Certification Authority (PCA), diese die Certification Authority (CA), und letztere wiederum den Benutzer (User).

Somit ist eine durchgehende Zertifizierung gewährleistet.

Anwendungen:

Eine frei erhältliche PEM-Implementierung namens _SecuDEä ist bereits für einige Plattformen verfügbar, z.B. Unix, Windows, OS/2, MS-DOS.

4.2.5 Firewall

Zum Schutz von eigenen Netzwerken, die mit öffentlichen Netzen (z.B. Internet, aber auch ISDN ) verbunden sind, hat sich das Konzept von Firewalls bewährt . Ähnlich wie bei einer Burg, bei der man nur durch das Burgtor bzw. über die Zugbrücke ins Innere gelangt, werden nur bestimmte Stellen im Netzwerk definiert, über die der Datenverkehr vom und zum Netz erfolgt. Damit kann der Datenfluß genau gesteuert und kontrolliert werden, anders als wenn z.B. zahlreiche Rechner, die womöglich noch verschiedene Betriebssysteme benutzen, direkt mit dem öffentlichen Netz verbunden sind. Diese Kanalisierung des Datenflusses hat auch den Nebeneffekt, daß Einbruchversuche anhand von Log-Dateien ausführlich dokumentiert werden können, da der Eindringling auf jeden Fall die Firewall passieren muß.

Ohne Firewall :


Abbildung 30 -
Internetzugang ohne Firewall Mit Firewall :


Abbildung 31 -
Internetzugang mit Firewall Hier ist das eigene Netzwerk über einen definierten zentralen Punkt verbunden.

4.2.5.1 Aufbau einer Firewall :

Eine Firewall kann auf verschiedene Arten angeorndet werden, zum Einen kann sie aus einer einzelnen Maschine bestehen oder zum anderen mehrstufig ausgeführt werden. Mehrstufige Anordnungen werden meist dann verwendet, wenn bestimmte Dienste, die vor allem für die Öffentlichkeit bestimmt sind, z.B. ftp-Service oder WWW-Server, in einem Zwischennetz isoliert werden.

Einstufige Firewall :

Abbildung 32 - Einstufige Firewall Mehrstufige Firewall :


Abbildung 33 -
Mehrstufige Firewall

4.2.5.2 Konfiguration einer Firewall :

Für die Konfiguration einer Firewall gibt es zwei Grundstrategien :

1) Es ist alles erlaubt, was nicht verboten ist. 2) Es ist alles verboten, was nicht erlaubt ist.

ad 1) Dieser Ansatz ist einerseits benutzerfreundlich, da neue Dienste automatisch erlaubt sind, andererseits muß jedoch der Administrator ständig das Verhalten der Benutzer beobachten, damit er rechtzeitig Gegenmaßnahmen treffen kann.

ad 2) Diese Strategie ist für den Anwender eher hinderlich, da für die Verwendung von neuen Diensten diese erst beim Administrator beantragt werden müssen. Sie schützt aber auch vor Sicherheitslücken die in Anwendungsprogrammen oder im Betriebssystem vorhanden sind, indem der Zugriff auf Ports (Kommunikationsschnittstelle zwischen Programmen), von denen unbekannt ist, ob sie einen sicheren Dienst anbieten oder nicht, unterbunden wird.

4.2.5.3 Arten von Firewalls

Es gibt drei Arten von Firewalls :

1) Paketfilter 2) Circuit Level Gateways 3) Application Gateways ad 1) Diese überprüfen die Quell- und Zieladresse einer Übertragung. Diese Information ist in jedem Netzpaket (IP - Paket, IP steht für Internet Protocol) gespeichert. Es wird also entschieden, ob ein Netzpaket passieren darf oder nicht. Ein Nachteil dieser Methode besteht jedoch darin, daß nicht zwischen Nutzern und deren Rechten unterschieden werden kann, d.h. es kann festgelegt werden, von welchen Rechnern (aufgrund der Internetadresse eines jeden Rechners) auf das eigene Netz zugegriffen wird, jedoch nicht mit welcher Anwendung. Es gibt aber bereits intelligente Paketfilter, die zusätzlich den Inhalt der Pakete analysieren und somit auch die Zulässigkeit von Verbindungen, z.B. sind ftp- Verbindungen auch von Rechnern mit beliebiger Internetadresse, erlauben.

ad 2) Circuit Level Gateways arbeiten ähnlich wie Paketfilter. Die Verbindung durch solch ein Gateway erscheint für den Benutzer so, als bestünde die Verbindung mit dem Firewall-Rechner (Host) selbst. Damit ist es möglich, Informationen über das eigene Netzwerk zu verbergen.

ad 3) Ein anderes Konzept verfolgen die Application Gateways, auch Proxy (Stellvertreter) genannt. Auf jedem Firewall-Host wird dabei für jede zulässige Anwendung ein eigenes Gateway-Programm installiert. Jeder Anwender, der mittels eines Clients (Anwendungs-programm) auf eine solche Anwendung zugreift, muß sich dabei gegenüber dem Proxy-Programm authentifizieren. Der Proxy führt nun alle Aktionen stellvertretend für den Client aus. Somit ist es möglich, ein genaues benutzerspezifisches Profil zu erstellen, z.B. zu welchen Zeiten darf ein Dienst benutzt werden, welchen Dienst darf man nutzen, welche Rechner dürfen zugreifen. Zusätzlich kann die Verbindung anwendungsbezogen festgelegt werden. Es entsteht somit ein einfaches Regelwerk. Da Application Gateways typische Vertreter des Konzepts _Es ist alles verboten was nicht erlaubt istä ist, ist dieses Verfahren als eines der sichersten, aber auch aufwendigsten einzuschätzen.

Da alle Zugriffe eines Clients über den Proxy laufen, wird die Möglichkeit geschaffen, den Proxy gleichzeitig als Cache (Zwischenspeicher) zu nutzen, z.B. bei einem WWW-Server von CERN (Conseil Europeen pour la Recherche Nuclaire, The European Laboratory for Particle Physics)). Hier werden WWW-Seiten während einer WWW-Verbindung zwischengespeichert. Wenn nun ein anderer Client eine WWW-Verbindung aufbauen will, aber die gewünschten WWW-Seiten bereits im Proxy vorhanden sind, so liefert der Proxy diese Seiten, ohne extra eine neue Verbindung aufzubauen. Auf diese Weise kann der Datenverkehr zu häufig angewählten Zielen reduziert werden.



Inhalt

Naechstes Kapitel: ELEKTRONISCHER ZAHLUNGSVERKEHR (E-CASH)