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
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 .
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
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.
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.
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.
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.
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.
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ß .
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
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.
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)