Zurück zur Inhaltsangabe

3. Die Mittel die Browser unterstützen


3.1 Gängige Authentifizierungsverfahren


3.1.1 Basic Authentication

Basic Authentification ist eine Möglichkeit der Authentifizierung, die HTTP bietet. Der Zugriff läuft in vier Schritten ab:

  1. Der Client stellt eine normale Anfrage für das gewünschte Dokument.
  2. Der Server verweigert die Auslieferung des Dokumentes, indem es den Statuscode "401 Unauthorized" zurücksendet und gibt dabei an, um welches Authentifizierungsverfahren es sich handelt, hier: Basic Authentification. Damit ist HTTP auch für beliebig andere Authentifizierungsverfahren offen.
  3. Wenn der Client das angeforderte Authentifizierungsverfahren kennt und beherrscht, kann der Benutzer meist in einem Dialog-Box User-ID und Passwort angeben. Der Client schickt erneut eine Anfrage, diesmal mit der eingegebenen Authentifizierung
  4. Der Server überprüft Passwort und User-ID. Falls diese korrekt sind, wird das gewünschte Dokument ausgeliefert.

Das Verfahren erfüllt nur Autorisierung und Authenzität. Und da Basic Authentication keine krytographische Lösung ist, sind selbst diese Anforderungen nicht sicher gelöst.

Der Nachteil an diesem Verfahren ist, dass die User-ID und das Passwort vom Client zum Server im Header der Anfrage im Klartext verschickt werden. Hacker ist es ein leichtes durch mitschneiden des Headers das Passwort und die User-ID herauszufinden. Solange aber die "geschützten" Dokumente keine hochsensiblen Informationen enthalten, kann diese Verfahren dennoch genutzt werden.

3.1.2 Digest Access Authentication (DAA)

DAA dient ebenfalls nur zur Authentifikation. Der Zugriff läuft wiederum in vie Schritten ab:

  1. Der Client stellt eine normale Anfrage für das gewünschte Dokument.
  2. Der Server verweigert die Auslieferung des Dokumentes, indem es den Statuscode "401 Unauthorized" zurücksendet und gibt dabei an, um welches Authentifizierungsverfahren es sich handelt, hier: Digest Access Authentication. Nebenbei wird noch ein sogenannter "Nonce"-Wert (Integer-Zahl), der bei jeder Anforderung neu erstellt wird.
  3. Die User-ID und das Passwort, welche der Benutzer angegeben hat, werden mit dem Nonce-Wert zusammen durch eine MD5-Hashfunktion als 128 Bit-Zahl kodiert werden. Nun stellt der Client nochmals die Anfrage, aber mit dieser Authentifizieung.
  4. Der Server überprüft User-ID und Passwort und übermittelt bei Richtigkeit das gewünschte Dokument. Zur Überprüfung muss nicht einmal die User-ID und das Passwort auf dem Server gespeichert sein, es reicht einfach nur die 128-Bit-Zahl zu speichern

Der Vorteil gegenüber Basic Authentication liegt klar auf der Hand: Es werden das Passwort und die User-ID niemals im Klartext über das Netz verschickt.

3.1.3 Mediated Digest Authentication (MDA)

MDA ist ein Erweiterungsvorschlag zu DAA. Da bei DAA zwischen jedem Server und jedem Client ein Gemeinsamer Schlüssel vereinbart werden muss, wird dieses Verfahren bei hoher Teilnehmerzahl sehr unpraktikabel. MDA sieht hier die Zusammenarbeit mit einer vertrauenswürdigen dritten Partei vor, welche die Schlüsselverwaltung übernimmt. Somit braucht sowohl Client und Server sich nur den Zugang zu einem sogenannten Authentifizierungserver (authentification server) zu merken. Jeder braucht also nur einen einzigen Schlüssel.

Versucht also ein Client auf ein mit MDA geschütztes Dokument auf einem Web-Server zuzugreifen, so sendet der Web-Server nach diesem ersten Zugriffsversuch, neben den nach DAA nötigen Authentifizierungsangaben, auch noch eine Liste von Authentifizierungsservern, denen er vertraut. Besitzt der Client ein Passwort für den geforderten Gültigkeitsbereich, kann er sich nach dem DAA-Modell gegenüber den Server authentifizieren. Ansonsten kann nun der Client aus der übertragenen Liste ebenfalls einen Authentifizierungsserver aussuchen, dem er vertraut und von diesem einen Sitzungsschlüssel anfordern.

Zurück zur Inhaltsangabe


3.2 Sichere Übertragung von Mails


3.2.1 Privacy-Enhanced Electronic Mail (PEM)

Privacy-Enhanced Electronic Mail ist der offizielle Standard in der TCP/IP-Protokollsuite. Es werden mehrere Verschlüsselungs-, Hash- und Public-Key-Algorithmen unterstützt. Davon ist zur Zeit DES der einzige Verschlüsselungsalgorithmus für die Nachricht selbst. RSA wird benutzt um die DES-Schlüssel und der Schlüsselzertifikate zu kodieren. Um die Signatur zu erstellen, wird der MD5-Hashwert der Nachricht berechnet.

PEM lässt sich als externes Paket in einigen Browsern integrieren.

3.2.2 Riordan's Internet Privacy Enhanced Electronic Mail (RIPEM)

Riordan's Internet Privacy Enhanced Electronic Mail (RIPEM) ist im Prinzip eine Untermenge von PEM. RIPEM benutzt dieselben Verschlüsselungs-, Hash und Public-Key-Algorithmen. Der einzige Unterschied ist, dass RIPEM keine Zertifikate implementiert. Also muss jeder Benutzer von RIPEM die Gültigkeit der Schlüssel selber beurteilen.

3.2.3 Pretty Good Privacy (PGP)

Pretty Good Privacy wurde 1991 von Phil Zimmermann entwickelt. Es benutzt zur Verschlüsselung der Nachricht einen dem DES ähnlichen Algorithmus, den sogenannten IDEA (International Data Encryption Algorithm), der zur Verschlüsselung einen 128 Bit Schlüssel benutzt. Für die Signatur der Nachrichten wird wieder eine MD5-Hashfunktion benutzt. Zur Übertragung der Schlüssel und Zertifikate wird der RSA-Algorithmus benutzt

PGP lässt sich als externes Paket in einigen Browsern integrieren.

Zurück zur Inhaltsangabe


3.3 Sichere Übertragung von HTTP-Dokumenten


3.3.1 Secure Socket Layer Protocol (SSL)

SSL ist ein Protokoll, welches durch Verwendung kryptograhischer Algorithmen und Protokolle Verschlüsselung und Authentizität einer Client-Server-Kommunikation erlaubt. Es wird eine Server- und optional auch eine Klienten-Authentifikation durchgeführt.

Das Protokoll ist zwischen der Anwendungsschicht (bspw. Telnet, FTP, ...) und der Transportschicht (TCP/IP, NetBios, ...) angesiedelt und lässt sich somit leicht in bereits bestehende Infrastrukturen integrieren. Entwickelt wurde SSL ursprüglich von Netscape und so ist die gesicherte Kommunikation im WWW wohl immer noch der Hauptanwendungszweck von SSL.

SSL bietet Unterstützung für:

SSL bietet dem Client immer eine Authentifizierung des Servers. Dies spielt sich in der SSL-Ebene ab. Die Anwendung bekommt also davon nichts mit. Die Authentifizierung des Clients ist optional.

Beim Aufbau einer TCP/IP-Verbindung von einem SSL-Client zu einem SSL-Server macht SSL eine Art Verhandlung zwischen diesen beiden. Es wird sich geeinigt, welchen Grad der Sicherheit erreicht werden soll.

Nach diesem Verbindungsaufbau, kümmert sich SSL nur noch darum den Datenfluss der Applikation zu kodieren bzw. zu dekodieren.

Ein Verbindungsaufbau bei SSL läuft wie folgt ab:

  1. In der sogenannten Hello-Phase, baut der Client eine Verbindung zum Server auf und teilt diesem mit, welche Kryptographischen-Algorithmen er unterstützt. Der Server wählt von diesen ein Public-Key-Verfahren, Private-Key-Verfahren und ein Hashverfahren aus und teilt diese dem Client mit.
  2. Der Server sendet nun ein Zertifikat, das neben der Identität des Servers auch den öffentlichen Schlüssel des Servers enthält. Mit diesem Zertifikat kann der Client überprüfen, ob die Antwort wirklich vom gewünschten Server stammte.
  3. Der Client generiert nun einen Sitzungsschlüssel (Session-Key) für den Datenaustausch mit dem gewählten Private-Key-Verfahren. Diesen kodiert der Client mit dem erhaltenden öffentlichen Schlüssel des Servers und schickt diesen an den Server.
  4. Der Client authentifiziert den Server, indem der Client jetzt einige mit dem Sitzungsschlüssel kodierten Testnachrichten an den Server sendet. Der Server kann diese nur korrekt entschlüsseln, wenn es sich um den echten Server handelt. (Damit hat sich der Server also gegenüber dem Client authentifiziert)
  5. Jetzt kommt ein optionaler Schritt, wo der Client sich dem Server gegenüber authentifizieren kann. Dieser Schritt ist nur möglich, wenn der Client über ein registriertes Zertifikat verfügt
  6. Beide Seiten schließen den Verbindungsaufbau ab und kodieren alle weiteren Datenpakete mit dem Sitzungsschlüssel.


3.3.2 Secure-HTTP (S-HTTP)

Einen alternativen Ansatz zu SSL bietet Secure HTTP (S-HTTP), das von einer Kooperation zwischen RSA Data Security Inc. und EIT Enterprise Integration Technologies entwickelt worden ist.

S-HTTP ist eine Erweiterung von HTTP und ist somit im Gegensatz zu SSL in der Anwendungsschicht angesiedelt. Es ermöglicht eine Aushandlung zwischen Client und Server von verschiedenen Sicherheitsmechanismen, die unabhängig voneinander sind.

Der Vorteil von Secure-HTTP gegenüber SSL liegt in der wesentlich breiteren Vielfalt von Anwendungsmöglichkeiten. Da S-HTTP in der Anwendungsebene verankert ist, ist es dem Benutzer, also Informationsanbieter und Informationsnutzer, zugänglicher als SSL. Es ist also nicht nur möglich vertrauliche Daten untereinander auszutauschen, sondern dem Benutzer stehen auch Möglichkeiten, wie digitale Unterschriften zur Verfügung. Damit können Kommunikationspartner Verträge abschließen, verbindliche öffentliche Mitteilung machen und so weiter. Es ist also mächtiger als SSL, konnte sich aber gerade aufgrund seiner Komplexität nicht gegenüber SSL durchsetzen.


3.3.3 Private Communication Technology Protocol (PCT)

Microsofts Private Communication Technology Protocol (PCT) ähnelt sehr Netscapes SSL Protokoll und ist sogar voll kompatibel zu diesem. PCT verbessert und korrigiert jedoch einige Schwachstellen des SSL-Protokolls:


3.3.4 Transprot Layer Security (TLS)

TLS steht als potentieller Nachfolger von SSL in den Startlöchern. Das neue Protokoll verspricht noch mehr Sicherheit bei der Kommunikation im Internet. Schon die Bezeichnung "TLS" lässt erkennen, dass es sich bei dieser Technologie um ein Protokoll der Transportschicht handelt. Microsoft hat mit seinem Private-Communication-Technology-Protokoll (PCT) versucht, eine sehr ähnliche Sicherungstechnologie durchzusetzen. Heute scheint es sicher, dass beide in Zukunft von TLS abgelöst werden.

Die TLS-Spezifikation basiert weitestgehend auf Secure Socket Layer. Das vordringlichste Ziel von TLS ist es, einen Mechanismus bereitzustellen, der Privacy und Datenintegrität zwischen zwei Anwendungen erlaubt. Ein Vorteil von TLS ist die Unabhängigkeit vom Applikationsprotokoll. Höhere Anwendungsprotokolle wie HTTP können sich transparent über TLS legen. Wie SSL geht TLS immer davon aus, dass die verwendeten Verschlüsselungsverfahren sicher sind. Durch seine Flexibilität ist es aber jederzeit möglich, Verschlüsselungsverfahren gegen andere zu ersetzen. Die Entscheidung, wie die Initialisierung eines TLS-Handshakes und wie der Austausch von Authentifizierungszertifikaten interpretiert werden kann, und darüber, welche Verschlüsselungsverfahren verwendet werden, liegt beim Entwickler.


3.3.5 Secure Electronic Transaction (SET)

Ende 1995 haben die beiden Kreditkartenunternehmen Mastercard und Visa ihre eigenen Sicherheitsprotokolle veröffentlicht. Mastercard hat zusammen mit IBM, Netscape, GTE und Cybercash eine offene Spezifikation, die Secure Electronic Payment Protocol (SEPP), entworfen. Visa hat zusammen mit Microsoft ebenfalls eine offene Spezifikation, die Secure Transaction Technology (STT), entworfen. Offene Spezifikation bedeutet, dass diese Protokolle jedem zur Verfügung stehen und jeder sie implementieren kann.

SET setzt sich aus diesen beiden Protokollen , also STT und SEPP zusammen. Mastercard und Visa schafften somit einen gemeinsamen Standard für elektronisches Geld. SET ist also nicht dafür gedacht Dokumente sicher übers das Netz zu schicken, sondern um eine sichere Bezahlung mit Bankkarten im offenen Netz zu gewährleisten.

Wie Set funktioniert zeigt dieses Beispiel.

Zurück zur Inhaltsangabe