Inhaltsverzeichnis

2 Anforderungen für eine kommerzielle Nutzung

3 Das Internet und seine Sicherheitslücken

3.1 Das OSI- und TCP/IP-Referenzmodell
3.2 Die Protokollfamilie TCP/IP und ihre Schwachstellen
3.2.1 Das Internet Protokoll (IP)
3.2.2 Die Protokolle TCP und UDP
3.2.3 Protokolle auf der Verarbeitungsschicht

4 Bemerkungen zum kryptographischen Hintergrund
4.1 Symmetrische und asymmetrische Kryptosysteme
4.2 Digitale Signaturen mit asymmetrischen Kryptosystemen

5 Maßnahmen zur Erhöhung der Sicherheit
5.1 Zertifikate und die Rolle von Trust Centern
5.2 Vertrauensmodelle
5.3 Absicherungen im Internet
5.3.1 Absicherung auf der Internetschicht
5.3.2 Absicherung auf der Transportschicht
5.3.3 Absicherung auf der Verarbeitungsschicht

6 Aktuelle Lage in Deutschland
6.1 Verordnung zur digitalen Signatur
6.2 Vorschläge für Key Escrowing

7 Zusammenfassung

8 Literatur

A Verordnung zur digitalen Signatur

Um dies zu erfüllen, gibt es verschiedene Lösungsansätze, von denen einige im folgenden nach einer Beschreibung der potentiellen Schwachstellen vorgestellt werden.

Die Anforderungen an eine kommerzielle Nutzung sind in Kapitel 2 beschrieben. Kapitel 3 zeigt potentielle Schwachstellen im Internet. In Kapitel 4 werden ein paar kryptographische Grundlagen vorgestellt. Heutige Konzepte für eine sichere Datenübertragung sind Bestandteil von Kapitel 5. Im 6. Kapitel wird schließlich auf den heutigen Stand in Deutschland eingegangen.

• Authentifizierung
• Datenintegrität
• Vertraulichkeit
• Nachweisbarkeit

Datenintegrität soll die Daten vor Manipulation schützen.

Die Vertraulichkeit soll das Abhören von Nachrichten verhindern.

Schließlich fordert man noch Nachweisbarkeit. Es soll für Dritte nachweisbar sein, wer die Daten gesendet bzw. empfangen hat.

• Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird.
• Jede Schicht sollte eine genau definierte Funktion erfüllen.
• Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden.
• Die Grenzen zwischen den einzelnen Schichten sollten so gewählt sein, daß der Informationsfluß über die Schnittstellen möglichst gering ist.
• Die Anzahl der Schichten sollte so groß sein, daß keine Notwendigkeit besteht, verschiedene Funktionen auf eine Schicht zu packen, aber so klein, daß die gesamte Architektur nicht unhandlich wird.

Dabei sollen nach [SK95] die einzelnen Schichten folgende Funktionen erfüllen:

• Die Bitübertragungsschicht betrifft die Versendung von Bits in den verschiedenen Kommunikationskanälen. Hier wird dafür gesorgt, daß eine gesendete 0 oder 1 auch als 0 oder 1 ankommt. In dieser Schicht finden physikalische Normen ihren Platz.
• Die Sicherungsschicht sorgt dafür, daß die Signale zuverlässig ankommen. Diese Schicht sorgt dafür, daß bei Ausfällen die entsprechenden Daten noch einmal gesendet werden. Bei mehrfach Daten werden die überflüssigen Teile herausgefiltert. Weiterhin ist hier ein Mechanismus vorhanden, der die kommunizierenden Partner aufeinander abstimmt.
• Die Vermittlungsschicht bringt die Daten auf den richtigen Weg zum Empfänger. In diese Schicht fällt damit die Adressierung und das Routing der Daten. Hier müssen ebenfalls Datenstaus bewältigt werden. Es muß beachtet werden, daß der Empfänger die gesendeten Daten auch verarbeiten kann. Die zuverlässigen Daten aus der Sicherungsschicht finden hier ihre zuverlässigen Verbindungen.
• In der Transportschicht werden die Verbindungen zwischen Sender und Empfänger aufgebaut. Hier finden zuverlässige Punkt-zu-Punkt-Verbindungen statt. Es ist die erste Schicht, die unabhängig von der Hardware arbeitet. Sie muß auch mit dem Problem klarkommen, daß von einem Knoten mehrere verschiedene Verbindungen gleichzeitig stattfinden können.
• Die Sitzungsschicht kümmert sich um den abstrakten Datentransport in sessions, die von Benutzer initiiert werden können.
• In der Darstellungsschicht wird definiert, wie Daten aussehen müssen, die übermittelt werden sollen. Nach dem Willen der ISO sollen in dieser Schicht auch Verschlüsslungsverfahren angesiedelt sein.
• In der Verarbeitungsschicht wird definiert, wie eine Applikation auf verschiedenen Plattformen einigermaßen einheitlich präsentiert werden kann.

Im Internet wird eine etwas andere Schichteneinteilung verwendet. Hier sind nur vier Schichten vorhanden (siehe Abbildung).

Die Schichten sollen die folgenden Aufgaben erfüllen:

• Die Host-an-Netz-Schicht ist die unterste Schicht. Sie umfaßt die Schicht 1 und 2 des OSI-Modells. Im TCP/IP-Referenzmodell befindet sich hier nur der Hinweis, daß sich ein Host über ein bestimmtes Protokoll an ein Netz anschließen muß.
• Die Internet-Schicht entspricht der Schicht 3 des OSI-Modells. Ihre Aufgabe ist es, Pakete an ihr Ziel zu befördern. Das Protokoll ist dieser Schicht ist das Internet Protokol (IP).
• Die Transportschicht soll wie die OSI-Transportschicht Partnereinheiten an den Quell- und Zielpunkten die Kommunikation ermöglichen. Hier werden End-zu-End-Verbindungen definiert. Auf dieser Schicht arbeiten die Protokolle TCP (Transmission Control Protokoll) als zuverlässiges, verbindungsorientiertes und UDP (User Datagramm Protokoll) als zuverlässiges, verbindungsloses Protokoll.
• Die Schicht oberhalb der Transportschicht heißt Verarbeitungsschicht. Hier befinden sich alle höherwertigen Protokoll wie FTP (Dateitransfer), TELNET (virtuelles Terminal), SMTP (E-Mail), DNS (Domain Name Service) und viele andere mehr.

3.2 Die Protokollfamilie TCP/IP und ihre Schwachstellen

• TCP/IP ist unabhängig von physischen Übertragungsmedium, also der Host-to-Net Schicht.
• Es handelt sich um offene Standards, die unabhängig von bestimmter Hardware und Betriebssystem entwickelt wurden.
• Ein Teil von IP ist ein weltweit einheitlicher Adressiermechanismus.
• Es gibts zahlreiche Protokollstandards auf der Anwendungsebene.

3.2.1 Das Internet Protokoll (IP)

• die Gestalt der IP-Adresse,
• die Integration der Netzwerkadresse in die IP-Adresse,
• die Aufgabe von IP, Datagramme, die die maximale Rahmengröße der darunterliegenden Schicht überschreiten, zu zerlgen,
• und die verbindungslose Natur.

Die Sicherheitsprobleme bei IP-Datagrammen sind die folgenden [NU98]:

• Es ist unklar, ob und wie ein IP-Paket ankommt.
• Die verwendete Route ist nicht vorhersehbar.
• Man ist den Betreibern der Netze ausgeliefert, die das Paket durchläuft. Jeder Betreiber kann das Paket einsehen, abfangen und modifizieren.
• Ein weiteres Problem ist das sogenannte Internet Address Spoofing, das gezielte Verschicken von Datagrammen mit falscher IP-Absenderadresse.

• Der Source Routing Angriff bedient sich einer speziellen Option im Protokollfeld des IP-Datagramms. Damit ist es in bestimmtem Fällen möglich, eine bestimmte Route vorzugeben. Zusammen mit dem Internet Adress Spoofing ist es möglich, die Rolle eines anderen Rechners effektiv zu übernehmen. In die zu versendenden Pakete trägt man einfach die IP-Adresse dieses Rechner ein. Über die Routing-Option gibt man eine Route vor, die über den eigenen Rechner läuft. Dadurch stellt man sicher, daß die Anwortpakete auch wieder über den eigenen Rechner gesendet werden. Dort können sie dann einfach abgefangen werden.
• Beim RIP-Angriff bedient man sich des Routing Information Protokolls (RIP), einem Protokoll zum dynamischen Austausch von Routing Informationen durch die Router. Ein Router ordnet jeder Route, die ihm bekannt ist, Kosten nach bestimmten Gesichtspunkten (Auslastung, Paketlaufzeit, geographische Entfernung usw.) zu. Standardmässig wird immer die Route verwendet, die die niedrigsten Kosten verursacht. Um immer eine optimale Route zu finden, tauschen die Router aller ein paar Minuten Informationen über die ihnen bekannten Routen und deren Kosten aus. Bei RIP-Angriff gibt ein Rechner vor, ein Router zu sein und eine besonderes günstige Route zu einem Rechner zu kennen. Mittels dieses Angriffs ist es möglich, sich in die Standardroute zwischen zwei Rechner zu plazieren.

3.2.2 Die Protokolle TCP und UDP

Mit der Secure-Socket-Layer (SSL) ist es aber auch möglich, auf der TCP-Schicht bestimmte Sicherheitsvorkehrungen zu treffen.

3.2.3 Protokolle auf der Verarbeitungsschicht

Protokoll	Aufgabe
TELNET	Implementierung eines virtuellen Terminals
FTP	Dateiübertragung
SMTP	E-Mail Zustellung
POP3	E-Mail Abholung durch den Mailboxinhaber, Gegenteil zu SMTP
DNS	Name Service
NNTP	Austausch von Nachrichten
HTTP	Holen von Seiten aus dem WWW

Der gemeinsame Schwachpunkt dieser Protokolle ist, daß sie allesamt sogenannte Klartextprotokolle sind. Das heißt, alle Daten werden unverschlüsselt über das Netz übertragen. Da mag bei DNS, NNTP und bei früheren Versionen von HTTP nicht unbedingt kritisch sein, da es ohnehin der Sinn der Name-Informationen, News-Artikel und Web-Seiten ist, der ganzen Welt zugänglich zu sein. Schwieriger wird es da bei TELNET, FTP, POP3. Bei allen diesen Protokollen werden Passwörter im Klartext übertragen. Sie können also von jedem Host, über den der Kommunikationsweg läuft, abgefangen und verwendet werden.

Die eigentliche Schwachstelle bei DNS ist aber an einem anderen Punkt zu suchen. Die Aufgabe von DNS ist es, weltweit die Zuordnung von Rechnernamen zu IP-Adressen vorzunehmen. Bei der Vielzahl der Rechner im Netz kann aber nicht jeder alle Zuordnungen kennen, aus welchem Grund auch die Idee für DNS entstand. Deshalb ist DNS als verteilte Datenbank aufgebaut. Die Information, die ein Name-Server nicht auflösen kann, leitet er an den höchsten Server weiter. Von dort wird schrittweise an den Nameserver, der für die entsprechende Domain zuständig ist, weitergeleitet. Man muß also bei so einer Adreßanfrage allen bei der Auflösung beteiligten Servern vertrauen. Andererseits ist es möglich, etwa durch RIP-Angriffe die Funktion eines Nameservers zu übernehmen und gezielt eine falsche IP-Adresse zurückzuliefern. Zwar gibt es zur Kontrolle der Korrektheit noch die Möglichkeit der Rückwärtsauflösung der Adresse, also das Suchen des Rechnernamens zur gegebenen IP-Adresse. Allerdings basiert das auf demselben Mechanismus, so daß auch dort Angriffe möglich sind.

Um diese Unsicherheiten zu beseitigen, muß im Laufe der Zeit dazu übergegangen werden, die Daten vor der Übertragung zu verschlüsseln. Es gibt Versionen der Protokolle (S-HTTP, SSH), die vor der eigentlichen Übertragung eine gegenseitige Identifizierung und das Bilden eines Schlüssels für die jeweilige Sitzung ermöglichen. Bei DNS ist der Aufbau eines gesicherten DNS-Dienstes angestrebt, bei dem die Server ihre Antwort digital signieren, so daß der Nutzer nachvollziehen kann, ob die Antwort wirklich von dem erwarteten Rechner kommt.

Im Falle eines symmetrischen Kryptosystems erfolgen Ver- und Entschlüsslung jeweils mit demselben Schlüssel. Das heisst, für ein beliebiges k aus K, m aus M gilt:

1. d( e(m, k), k) = m
2. Im Allgemeinen gilt: e( d(m,k), k)<>m.
3. Sei k2 aus K mit k2<>k. Dann gilt im Allgemeinen: d( e(m, k), k2)<>m und d( e(m, k2), k)<>m.

Im Gegensetz zu den symmetrischen Systemen sind in den letzten zwei bis drei Jahrzehnten asymmetrische Kryptosysteme entwickelt worden. Die Idee dabei ist es, daß Ver- und Entschlüsslung mit zwei verschiedenen Schlüsseln erfolgen. Daher ist es möglich, den Schlüssel zum Verschlüsseln öffentlich bekanntzugeben. Bei den heute verfügbaren asymmetrischen Kryptosystemen werden über mathematische Verfahren zwei Schlüssel gebildet, die eine entgegengesetzte Wirkung haben, d.h. wenn einer zum Verschlüsseln verwendet wird, dann kann der andere zum Entschlüsseln verwendet werden. Das Verfahren, mit dem man aus einem Schlüssel ohne weitere Kenntnisse den anderen berechnen kann, sollte mindestens genauso komplex sein wie das knacken des Chiffretextes.

Asymmetrische Kryptosysteme haben die folgenden Eigenschaften:

Für ein Schlüsselpaar (k1, k2) mit k1, k2 aus K und alle m aus M gilt:

1. d( e(m, k1), k2) = m und auch d( e(m, k2), k1) = m
2. e( d(m, k1), k2) = m
3. Für alle k aus K, k<>k1, k<>k2 sollte gelten: d( e(m,k), k1)<>m, d( e(m,k), k2)<>m,
   d( e(m,k_1), k)<>m und d( e(m,k_2), k)<>m

Um ein RSA-Schlüsselpaar zu bilden ermittelt der Nutzer zunächst zwei große Primzahlen p und q. Er berechnet das Produkt n= p g und wählt zufällig eine zu (p-1)(q-1) teilerfremde Zahl d aus dem Bereich 1<= d<=p-1)(q-1). Anschließend berechnet er mittels des erweiterten Euklidischen Algorithmus die eindeutig bestimmte Zahl e, 1<=e<=(p-1)(q-1) mit der Eigenschaft d e = 1 mod (p-1)(q-1). Das Paar (e, n) wird als öffentlicher Schlüssel bekanntgegeben, das Paar (d, n) bildet den privaten Schlüssel. Da es ziemlich einfach möglich ist, d aus e, p, q zu berechnen, sollten p und q vernichtet werden.

Das Versenden einer verschlüsselten Nachricht M erfolgt auf die folgende Weise:

1. Man zerlegt M in Blöcke Mi und stellt jeden Block durch eine Zahl aus dem Bereich 0..(n-1) dar.
2. Die Verschlüsslung erfolgt durch die Berechnung C = (Mi)^e mod n.
3. Der Empfaenger berechnet D = C^d mod n, wobei D = M ist.

Mit diesem Mechanismus lassen sich digitale Signaturen auf folgende Art erzeugen:

1. Alice möchte an Bob eine signierte Nachricht schicken. Sie hat das Schlüsselpaar (pub, priv). Also bildet sie für ihre Nachricht m: s = d(m, priv) und schickt (m, s) an Bob.
2. Bob empfängt (m, s) und bildet v = e(s, pub), wobei pub Alices öffentlicher Schlüssel ist. Gehört die Signatur zu der Nachricht und ist sie korrekt, so gilt: m = v und Bob wird m akzeptieren. In allen anderen Fälle wurde entweder die Nachricht geändert oder die Signatur gehört nicht zur Nachricht. In diesen Fällen wird Bob m ignorieren.

1. Man kann durch die Vorschriften in einem Land dazu gezwungen werden, seinen privaten Schlüssel zur Entschlüsslung herauszugeben. So ist es nach der Herausgabe der Schlüssels trotzdem nicht möglich, Signaturen zu fälschen.
2. Unter bestimmten Umständen ist es auch möglich, Signaturen zu fälschen, wenn zum Verschlüsseln und Signieren dasselbe Schlüsselpaar verwendet wird.

Dabei sind Alice und Bob die kommunizierenden Parteien, die zu Beginn der Sitzung sich gegenseitig ihre öffentlichen Schlüssel senden. Mallot sei in der Route zwischen Alice und Bob plaziert. Alice sendet nun ihren Schlüssel. Der Weg läuft über Mallot. Mallot fängt den Schlüssel ab und sendet statt dessen ihren öffentlichen Schlüssel an Bob. Ebenso verläuft das in der Gegenrichtung. Mallot fängt auch Bobs Schlüssel ab und sendet auch Alice ihren öffentlichen Schlüssel. Alice und Bob haben keine Ahnung davon, daß sie gar nicht den Schlüssel ihres Gegenübers besitzen. Sendet nun Alice etwas an Bob, so läuft der Weg auch über Mallot. Alice verschlüsselt die Nachricht mit Mallotīs Schlüssel und sendet sie an Bob. Mallot entschlüsselt die Nachricht mit ihrem privaten Schlüssel, verschlüsselt sie mit Bobīs Schlüssel und sendet sie an Bob. Da Bob nun eine Nachricht erhält, die mit seinem öffentlichen Schlüssel verschlüsselt ist, kann er sie entschlüsseln ohne im geringsten einen Verdacht zu schöpfen. Genauso läuft die Kommunikation von Bob nach Alice. Da Alice und Bob den Schlüssel von Mallot benutzen, kann Mallot jede Nachricht zwischen Alice und Bob im Klartext lesen.

Um die Überprüfbarkeit der Schlüssel für alle zu gewähleisten, ist das Konzept von Zertifikaten eingeführt worden. Ein Zertifikat enthält Daten über den Inhaber und ist von einer Zertifizierungsstelle (Trust Center) signiert. Damit der Nutzer die Gültigkeit der Signatur auch Überprüfen kann, wird der öffentliche Schlüssel der Zertifizierungsstelle auf einem sicheren Weg (z.B. persönlich) dem Nutzer übergeben.

Der Aufbau solch eines Zertifikats ist in der Norm X.509 geregelt. In der ersten Version (X.509v1) ging es dabei vorrangig um die Zuordnung zwischen Namen und öffentlichen Schlüssel des Inhabers (s. Abbildung).

So können Alice und Bob zu Beginn der Kommunikation sich gegenseitig ihre Zertifikate schicken. Die Echtheit der Zertifikate kann mit dem öffentlichen Schlüssel der Zertifizierungsstelle überprüft werden. Dadurch ist die Verbindung zwischen Namen und öffentlichem Schlüssel hergestellt, so daß in diesem Fall Mallot keine Chance haben wird.

Für kommerzielle Nutzung ist die Kopplung zwischen Namen und öffentlichem Schlüssel oft nicht ausreichend ist. So möchte man auch noch andere Daten des Inhabers haben und manchmal auch verhindern, daß der Inhaber andere Nutzer zertifizieren kann (s. Abschnitt Vertauensmodelle). Zu diesem Zweck wurde der Aufbau erweitert. Dies geschah allerdings unter dem Gesichtspunkt, daß man kompatibel zur Version v1 bleiben möchte. Der Aufbau eines Zertifikats nach X.509v3 ist im folgenden dargestellt.

Aufbauend auf Zertifikaten ist dann auch eine zuverlässige gegenseitige Identifizierung der kommunizierenden Parteien möglich. Alice und Bob wollen zum Beispiel miteinander kommunizieren und sich dabei sicher sein, daß sie wirklich miteinander reden. Also müssen sie sich gegenseitig identifizieren. Zuerst will sich Alice davon überzeugen, daß wirklich Bob am anderen Ende sitzt. Zuerst sendet Bob ihr eine Nachricht der Art "Hallo, ich bin Bob und hier ist mein Zertifikat" senden. Alice nimmt das Zertifikat in Empfang und überprüft mit Hilfe des öffentlichen Schlüssels der Zertifizierungsstelle die Echtheit des Zertifikats. Anschliessend sendet sie Bob irgendeinen beliebigen Text. Die Aufgabe von Bob ist es, diesen Text zu signieren und den signierten Text wieder an Alice zurückzusenden. Nun kann Alice die Signatur mit Hilfe des öffentlichen Schlüssels aus dem Zertifikat überprüfen. Stimmt die Signatur, so kann sie sicher sein, daß sie mit Bob kommuniziert. Auf dieselbe Art kann sich Bob davon überzeugen, daß er wirklich mit Alice redet.

Haben sich beide Seiten identifiziert, so besteht trotzdem noch die Gefahr, daß ein Angreifer eine Nachricht als Bob an Alice schickt. Um auch dies noch zu verhindern, sollten Alice und Bob auch alle ihre Nachrichten signieren.

Es kann notwendig sein, Zertifikate vor Ablauf ihrer Gültigkeit zu sperren. Dies ist beispielsweise dann der Fall, wenn der Inhaber seinen privaten Schlüssel verliert. Um Zertifikate zu sperren, werden in regelmäßigen Abständen Sperrlisten veröffentlicht. Dort werden die Nummer der gesperrten Zertifikate veröffentlicht. Mit dem Standard X.509v3 wurde gleichzeitig ein genormter Aufbau der Sperrliste festgelegt.

Sperrlisten werden in regelmäßigen Abständen von den Zertifizierungsstellen veröffentlicht. Je nach Sicherheitsanforderung kann sich der Abstand zwischen zwei Veröffentlichungen im Zeitraum von wenigen Minuten bis zu einem Tag bewegen.

5.2 Vertrauensmodelle

Ein Vertauensmodell ist durch die folgenden Definitionen und Eigenschaften gekennzeichnet [NU98]:

• Ein Vertrauensmodell definiert Vertrauensketten zwischen Zertifizierungsstellen oder Nutzern. Die Identität jedes Nutzers ist durch mindestens eine, im Modell vorhandene Zertifizierungsstelle, garantiert.
• Den Zertifizierungsstellen wird vertraut, die Identität von Personen und anderen Zertifizierungsstellen bestätigen zu können.
• Jeder Benutzer hat mindestens eine vertrauensmaximale Zertifizierungsstelle. Das ist die Stelle, von der er über einen sicheren Kommunikationskanal deren öffentlichen Schlüssel erhalten hat.
• Ist einmal eine Vertrauenskette mit einer fremden Zertifizierungsstelle hergestellt, so können alle deren Zertifikate akzeptiert werden, ohne jedesmal die Vertrauenskette neu herstellen zu müssen.

Das flache Vertrauensmodell entspricht dem Fall einer unabhängig operierenden Zertifizierungsstelle.

Beim PGP-Vertrauensmodell stellt jeder Nutzer eine unabhängige Zertifizierungsstelle dar und entscheidet selbst durch seine digitale Unterschrift wem vertraut wird. Es bleibt auch jedem Nutzer selbst überlassen, im jedem Einzelfall eine Vertrauenskette zu finden und zu entscheiden, ob er die Unterschrift eines anderen Nutzers als ausreichend anerkennt.

Beim verteiltem Vertrauensmodell wird von mehreren, dezentral operierenden Zertifizierungsstellen ausgegangen. Für jeden Nutzer stellt seine Zertifizierungsstelle die vertrauensmaximale Instanz dar. Zusätzliche Stellen sind für Kreuzzertifizierungen vorgesehen, um für den Nutzer einer Zertifizierungsstelle die Zertifikate der anderen Stellen akzeptabel zu machen.

Das zentrale Vertauensmodell geht von einer straffen, streng hierarchischen Struktur aus. Es gibt genau eine oberste Zertifizierungsstelle, die auch für alle Nutzer die vertrauensmaximale Instanz darstellt.

5.3 Absicherungen im Internet

5.3.1 Absicherung auf der Internetschicht

Eine solche Absicherung wird im IPv6 vorgesehen, der Weiterentwicklung des heute verwendeten Internet Protokol IPv4. Momentan wird noch versucht, ein Protokoll für die Schlüsselverteilung zu standardisieren.

5.3.2 Absicherung auf der Transportschicht

Von Netscape wurde im Zuge der Entwicklung der kommerziellen Nutzung das Protokoll SSL (von Secure Sockets Layer) entwickelt. Von diesem existieren heute schon eine Reihe frei verfügbarer Implementierungen.

Unmittelbar nach dem Aufbau der TCP/IP-Verbindung findet die Initialisierungsphase von SSL, der sogenannte SSL-Handshake, statt. Dazu gehören die folgenden Vorgänge [NU98]:

1. Der Client baut eine Verbindung zum Server auf, beginnt den Initialisierungsvorgang und schlägt dabei eine Reihe der von ihm unterstützten kryptographischen Verfahren vor.
2. Der Server antwortet mit einer Auswahl der geeigneten und von beiden Seiten unterstützten Verfahren und überträgt sein X.509-Zertifikat. In diesem Schritt kann der Server auch optional ein Zertifikat von Clienten verlangen. Es wird ebenfalls der Beitrag vom Server zum Sitzungsschlüssel gesendet, abhängig von gewählten Schlüsselaustauschprotokoll.
3. Nach erfolgreicher Überprüfung des Zertifikats vom Server durch den Clienten überträgt er, falls er dazu aufgefordert wurde, sein Zertifikat an den Server und bedient sich dabei ebenso wie der Server einer digitalen Unterschrift zur Sicherstellung seiner Identität. Außerdem werden vom Clienten auch die zur Erzeugung des Sitzungsschlüssels notwendigen Informationen an den Server übertragen. Hier ist die Initialisierungsphase von der Seite des Clienten aus beendet.
4. Server und Client bilden den gemeinsamen Sizungsschlüssel aus ihrem eigenen und dem dazu empfangenen Beitrag. Gegebenenfalls überprüft der Server das Zertifikat des Benutzers und bestätigt den erfolgreichen Abschluß der Initialisierungsphase. Diese Nachricht wird mit dem ausgehandelten Verfahren symmetrisch verschlüsselt und digital signiert. Anschließend steht der Anwendung die sichere Verbindung zur Verfügung.

5.3.3 Absicherung auf der Verarbeitungsschicht

Secure-HTTP

Bei S-HTTP handeln Client und Server für jede Verbindung die Absicherung erneut aus. Dabei ist es möglich, Mindestanforderungen für die Absicherung der Verbindung zu stellen. Dabei sind drei Stufen vorgesehen [NU98]:

• Unwichtige Daten können im Klartext übertragen werden.
• Bei verbindlichen Daten kann der Client eine Signatur oder auch Verschlüsslung des Servers fordern.
• Im Gegenzug kann der Server aber auch eine Signatur der Angaben des Benutzers verlangen.

Secure-DNS

Der DNS-Dienst wird dabei in zwei Richtungen erweitert [NU98]:

• Es soll eine kryptographische Authentifizierung der an der Auflösung beteiligten DNS-Server erfolgen, um die Sicherheitsrisiken des DNS zu beseitigen.
• Weiterhin kann die DNS-Datenbank auch dazu eingesetzt werden, um nach erfolgreicher Authentifizierung nicht nur den Rechnernamen, sondern auch den dazugehörigen öffentlichen Schlüssel zurückzugeben. Weiterhin soll die Abfrage von Benutzerzertifikaten im Namensbereich möglich sein.

Die Spitzen der Zertifizierungshierarchie sind im Optimalfall einer weltweiten Umstellung auf Secure-DNS die DNS-Server der obersten Namensbereiche (z.B. de oder com). Um eine schrittweise Umstellung von DNS auf Secure-DNS zu erreichen, bedient man sich keines zentralen Vertrauensmodells, sondern verläßt sich auf Kreuzzertifizierungsmechanismen. Dadurch besteht eine Interoperabilität zwischen beide Systemen. Kann ein sicherer Server keinen Vertrauenspfad herstellen, so wird auch dieser nur eine unsichere IP-Adresse zurückliefern. Zur Inbetriebnahme von Secure-DNS ist deshalb nicht die sofortige Entstehung einer weltweiten Spitzenorganisation eine Voraussetzung [NU98].

Im Anhang A befindet sich das Inhaltsverzeichnis der Signaturverordnung.

6.2 Vorschläge für Key Escrowing

Allerdings ist die so entstehende Sicherheit nicht absolut zu betrachten. Die Sicherheit der zugrundeliegenden kryptographischen Verfahren beruht meistens darauf, daß es noch niemandem gelungen ist, eine Schwachstelle darin zu finden. Eine Auflistung heute bekannter Pannen ist beim Bundesamt für Sicherheit in der Informationstechnik zu finden.

[BK91]

Beutelspacher, A., Kertsen, A., Pfau, A.: Chipkarten als Sicherheitswerkzeuge,
Springer Verlag Berlin, Heidelberg, 1991.

[NU98]

Nusser, Stefan: Sicherheitskonzepte im WWW,
Springer Verlag Berlin, Heidelberg, 1998.

[SC98]

Schneyer, Bruce: Angewandte Kryptographie,
Addison-Wesley, Bonn, 1998.

[SK95]

Schönleber, Claus, Keck, Cornelius: Internet Handbuch,
Franzisī, Poing, 1995.

[SM97]

Smith, Richard E.: Internet Cryptographie,
Addison-Wesley, Reading, 1997.

[ST94]

Studer, Bruno: Sicherheit im Netzmanagement,
Dissertation an der Universität Zürich, 1994.

[TA98]

Tanenbaum, Andrew S.: Computernetzwerke,
Prentice Hall, 1998.

[BSI99]

Bundesamt für Sicherheit in der Informationstechnik,
http://www.bsi.bund.de

[KA99]

Aktuelle juristische Informationen zu EDV-Fragen,
http://www.kanzlei.de/edvr.htm

§ 1

Verfahren bei Erteilung, Rücknahme und Widerruf von Genehmigungen

§ 2

Kosten

§ 3

Antragsverfahren bei Vergabe von Zertifikaten

§ 4

Unterrichtung des Antragsstellers

§ 5

Erzeugung und Speicherung von Signaturschüsseln und Identifikationsdaten

§ 6

Übergabe von Signaturschlüsseln und Identifikationsdaten

§ 7

Gültigkeitsdauer von Zertifikaten

§ 8

Öffentliche Verzeichnisse von Zertifikaten

§ 9

Verfahren zur Sperrung von Zertifikaten

§ 10

Zuverlässigkeit des Personals

§ 11

Schutz der technischen Komponenten

§ 12

Sicherheitskonzept

§ 13

Dokumentation

§ 14

Einstellung der Tätigkeit

§ 15

Kontrolle der Zertifizierungsstellen

§ 16

Anforderungen an die technischen Komponenten

§ 17

Prüfung der technischen Komponenten

§ 18

Erneute digitale Signatur

§ 19

Inkrafttreten