\maketitle
\begin{center}\bf{Diese Seite wurde bewußt freigelassen.}\end{center}
\tableofcontents{}
\listoffigures{}
Aufgabenstellung
Ziel meiner Studienarbeit ist es eine webbasierte Authentication mittels
Zertifikaten zu ermöglichen.
Diese Formulierung ist sehr knapp gehaltene und aus eben diesem Grund
eher unpräzise. Das sorgte dafür, daß ich beim Lösen der Aufgabe Aspekte
beleuchten mußte, die für mögliche Realisierungen keine Bedeutung
haben aber zum Verstehen des Sachverhaltes dienlich sind. Andererseits
bekam ich durch diese Aufgabe einen Spielraum, der mir die Suche nach
einer praktikablen Lösung erleichterte.
Im nächsten Kapitel möchte ich die in der Aufgabenstellung verwendeten
Begriffe klären, um anschließend einen Einblick über das Zustandekommen
und die Bedeutung der Aufgabe liefern zu können. Die darauffolgenden
Kapitel befassen sich mit Grundlagen zu Bedrohungen denen Informationstechnologie
ausgesetzt ist und Präventivmaßnahmen, die ergriffen werden können,
um diese Bedrohungen abzuschwächen. Im Anschluß daran wird an ausgewählten
Beispielen der aktuelle Entwicklungsstand beschrieben.
Ab Kapitel acht wird die Umsetzung der Aufgabe auf einer von mir gewählten
Plattform erläutert. Diese Umsetzung erfolgt unter Berücksichtigung
der in den vorangegangenen Kapiteln beschriebenen theoretischen Erkenntnisse,
so daß an dieser Stelle mehr Wert auf die Nachvollziehbarkeit der
gezeigten Möglichkeiten gelegt wird.
Zum Schluß gebe ich noch einen kleinen Ausblick, welche weiteren Entwicklungsschritte
im Umfeld dieser Aufgabe möglich sind und wie dies durch neue Anwendungen
beeinflußt wird.
Begriffsklärung
2.1 Authentifikation
Eine Authentifikation ist der Nachweis eines potentiellen Kommunikationspartners,
daß er der ist für den er sich ausgibt. Seine Identität wird durch
die Überprüfung unverwechselbarer Merkmale festgestellt. Je nach Art
dieses Merkmals handelt es sich um einen bestimmten Typ der Authentifikation.
Man unterteilt hier in drei Gruppen.
Eine sehr beliebte Möglichkeit eine Maschine die Authentizität eines
Nutzers prüfen zu lassen ist die Authentifikation durch Wissen. Das
älteste mir bekannte Beispiel hierzu ist "Sesam öffne dich !" aus
Alibaba und die vierzig Räuber. Eine etwas zeitgemäßere Variante der
Authentifikation durch Wissen ist das Einloggen an einem Rechner mittels
Nutzername und Password, wobei der Nutzername öffentlicher Parameter
ist, also selbst nicht zum Geheimnis gehört und nur festlegt welcher
"Berg" geöffnet werden soll.
Die zweite Art der Authentifikation ist das Anzeigen von Besitz. Der
einfachen Handhabbarkeit wegen ist der Gegenstand mit dessen Hilfe
dies geschieht meist in seinen Abmessungen genormt. Das eigentliche
Merkmal mit dem Identifiziert wird ist zur optischen Erkennung auf
die Oberfläche aufgebracht. Heute wird diese Methode, mit rein optischer
Erkennung, gern da verwendet, wo nur ein geringes Sicherheitsbedürfnis
besteht aber sich durch den Einsatz der Service erhöht oder statistische
Auswertungen ermöglicht werden, die diesen Aufwand rechtfertigen.
Das Medium ist dann meist eine bedruckte Plastikkarte die über einen
Barcodescanner erkannt werden kann. Früher waren Siegelringe eine
Umsetzung dieser Authentifikationsform. Um die Sicherheit bei der
maschinellen Erkennung zu erhöhen wird die Merkmalspalette in vielen
Fällen, wie bei der EC-Karte, durch Magnetstreifen und Speicherchips
erweitert.
Eine dritte Art der Authentifikation ist durch Eigenschaften möglich.
Die Eigenschaft wird dabei so gewählt, daß sie nicht übertragbar ist.
Um die Authentizität eines Menschen zu prüfen müssen also biometrische
Eigenschaften wie Augenhintergrund, Fingerabdrücke oder Stimme kontrolliert
werden. Die Dresdner Bank testet seit wenigen Tagen Geldautomaten,
die den Kunden über Videotechnik an seiner Iris erkennen \cite{1}.
Das besondere daran ist, daß die biometrische Eigenschaft hier nicht
als Ergänzung zu anderen Authentifikationsmöglichkeiten verwendet
wird. Der Kunde braucht also weder Karte noch PIN. Ich persönlich
bin sehr gespannt, wann damit die "Und wie möchten sie bezahlen ?"
VISA Werbung getoppt wird.
Ein Problem, das bei der Authentifikation durch biometrische Eigenschaften
auftritt ist, daß zum Erkennen dieser Eigenschaften spezielle Technik
erforderlich ist und diese Technik lokal verfügbar sein muß. Nach
dem Scannen der Eigenschaft wird diese in Form von Bits und Bytes
vom Scanner zum auswertenden Rechner übertragen. Bei dieser Übertragung
ist die mit der Eigenschaft assoziierte Information aber am ehesten
mit Wissen vergleichbar und kann entsprechend dupliziert oder manipuliert
werden. Diese Übertragung ist also entsprechend zu Schützen. Das kann
durch den Einsatz von Zertifikaten erfolgen, was nun in einem etwas
anderen Zusammenhang das Ziel meiner Studienarbeit ist. Die Authentifikation
mittels biometrischer Eigenschaften sei daher hier nur der Vollständigkeit
wegen gennant. Sie wird im weiteren Verlauf meiner Arbeit keine Rolle
spielen.
Bei Wissen und Besitz stellt die Weitergabe kaum ein Problem dar, deshalb
werden unterschiedliche Arten der Authentifikation oft miteinander
kombiniert. Das ist zum Beispiel dann der Fall, wenn man mit dem eigenen
Schlüssel die Haustür aufschließt (Besitz), an der Wohnungstür einen
bestimmten Rhythmus klingelt (Wissen), um dann auf die Frage "Wer
da ?" mit "ich bin's" zu antworten (Stimme als Eigenschaft).
Je nach vereinbarten Sicherheitsanforderungen kann es notwendig werden,
daß sich alle Partner gegenseitig authentifizieren. Das schließt auch
Maschinen ein. Selbst wenn nicht explizit vereinbart wurde, daß sich
ein Computer identifizieren muß kann ich sein "Wissen" prüfen. Ich
kann versuchen mich mehrmals mit falschem Password anzumelden und
verwende dann das Richtige. Wenn ich daraufhin Zugriff erhalte und
alle vorherigen Fehleingaben als solche erkannt wurden scheint der
Computer der zu sein für den er sich ausgibt. Wenn der Nutzer sich
einer strengen Authentifikation unterziehen muß sollte er von der
Maschine jedoch das gleiche verlangen können ohne Gefahr zu laufen
sein Login zu sperren. Prinzipiell kann das durch alle oben genannten
Möglichkeiten geschehen.
2.2 webbasiert
In der Aufgabenstellung steht, daß diese Authentication webbasiert
sein soll. Web ist nicht gleich World Wide Web, es kann sich also
auch um ein lokales, isoliertes Netzwerk handeln. Die Prinzipien unterscheiden
sich jedoch nicht. Die Realisierungen haben nur unerschiedliche Ausmaße.
Eine webbasierte Lösung ist immer Client - Server basiert. Vom Client,
dem Webbrowser eines Nutzers, wird eine Verbindung zu einem Server,
in diesem Fall einem Webserver, aufgebaut um von dort Informationen
zu beziehen. Andere Server mit denen ein Browser in Verbindung treten
kann sind beispielsweise FTP- und Mail-Server. Mein Bericht bezieht
sich jedoch ausschließlich auf Webserver, da ihre Funktionalität die
eines FTP- Servers beinhaltet und Zertifikate zur Authentication bereits
innerhalb von Mail's eingesetzt werden können.
2.3 Zertifikate
Der dritte zu beachtende Punkt der Aufgabenstellung ist, daß die webbasierte
Authentifikation durch Zertifikate erfolgen soll. Ein solches Zertifikat
ist ein Gutachten einer vertrauenswürdigen und aus diesem Grund normalerweise
unparteiischen Instanz. Solche Instanzen heißen Certifikation Authorities.
Im weiteren Bericht werde ich Certification Authorities mit CA abkürzen.
In einem Zertifikat werden bestimmte Daten des Besitzers bestätigt.
Diese Daten müssen natürlich vor der Ausstellung eines Zertifikates
von der ausstellenden CA geprüft werden. Wenn sich nun ein Nutzer
mit Hilfe eines Zertifikates bei einem Webserver authentifizieren
möchte muß der Server die Daten des Nutzers nicht selbst prüfen, sondern
kann sich auf die Überprüfung der Daten durch die ausstellende CA
verlassen. Der Server verwaltet deshalb eine Liste mit vertrauenswürdigen
CA's. Es erfolgt also keine Prüfung von "Einzelschicksalen" sondern
die Prüfung einer Gruppenzugehörigkeit. Wenn ein Nutzer dem Server
ein für diesen gültiges Zertifikat vorweisen kann steht einer Kommunikation
nichts mehr im Wege. Um die Sicherheit zu erhöhen sind Zertifikate
zeitlich begrenzt. Der Server kann aber auch bei einem zeitlich noch
gültigen Zertifikat bei der CA nachfragen, ob das Zertifikat eventuell
zurückgezogen, für ungültig erklärt, wurde. Das kann der Fall sein,
wenn sich Daten des Besitzers geändert haben, ihm die Gruppenzugehörigkeit
entzogen wurde oder das Zertifikat gestohlen ist.
Legitimation der Aufgabe
Zur Aufgabenstellung gibt es natürlich auch eine entsprechende Hintergrundgeschichte,
welche die Bedeutung der Aufgabe und ihre Einbettung in die Chemnitzer
Informatik erklärt. Seit 1995 gibt es an der Universität Chemnitz
ein Internet-Aufbaustudium "Informations- und Kommunikationssysteme"
[11]. Die Teilnehmer, der von der Universität Chemnitz und dem VDE
angebotenen Kurse, müssen nur zur Anmeldung und zur Abschlußprüfung
persönlich erscheinen. Die eigentliche Ausbildung erfolgt ausschließlich
am PC, die Arbeitsmaterialien werden über das Internet bezogen. Da
diese Ausbildung kostenpflichtig ist muß sichergestellt werden, daß
nur "Zahlende Gäste" Zugang zu den entsprechenden Betriebsmitteln
erhalten. Deshalb wird jeder Nutzer, der sich auf die Teilnehmerseiten
von iuk.tu-chemnitz.de begibt, nach einer USER ID und dem zugehörigen
Password gefragt.
Diese Art der Authentifikation ist, da sie leicht realisert werden
kann, weit verbreitet. Das bedeutet jedoch nicht, daß sie nicht verbessert
werden kann, denn ein möglicher Angriffspunkt ist die Eingabe und
Übertragung von Passwörtern. Das Problem, daß sensible Daten über
einen unsicheren Kanal zwischen zwei Computern übertragen werden,
kann man durch Verschlüsselung lösen.
Das Nutzer versuchen können aus einer unsicheren Umgebung heraus eine
Verbindung aufzubauen ist ein weiteres Problem. Trotz aller Verschlüsselung
darf nicht vergessen werden, daß die Kommunikation vom und zum Nutzer
im Klartext verläuft und daran wird sich ohne den Einsatz von Transplantaten
auch nichts ändern. Damit muß sich jeder, der keine Steckdose hinter
dem Ohr trägt, bei der Authentifikation durch Wissen fragen, ob er
sein Wissen in der jeweiligen Umgebung preisgeben möchte. Um das zu
vermeiden bleibt einem nur die Möglichkeit ganz auf Passwörter zu
verzichten und andere Authentifikationsformen zu wählen.
Dieses Problem gilt besonders in für den Nutzer unbekannten Umgebungen.
Während er in seinem gewohnten Umfeld einen Überblick über die verwendete
Infrastruktur hat und ihm auch die in angrenzenden Büros arbeitenden
Leute vertraut sein sollten kann ein Besucher eines Internetcafes
nicht mit Sicherheit sagen, welche Aufgaben ein kleiner grauer Kasten
im Kabelgewirr hinter dem Rechner erfüllt und ob der Kasten gestern
schon da war.
Es kann aber auch versucht werden das Risiko durch einen administrativen
Eingriff zu verringern. So kann zum Beispiel festgelegt werden, daß
ein Nutzer nur von einem Bestimmten Rechner (seinem eigenen) einen
Zugriff auf die Betriebsmittel des Webservers erhält. Eine solche
Maßnahme beinhaltet aber eine starke Einschränkung der Verwendbarkeit.
Da Computer im Internet anhand ihrer IP-Adresse identifiziert werden
darf sich diese bei einer fest eingetragenen Zugangsberechtigung von
Rechner sowieso nicht verändern. Wenn sich aber jemand per Notebook
und Modem anmelden möchte wird die IP-Adresse, die sein mobiler Rechner
bekommt, dynamisch vergeben. Er erhält möglicherweise bei jeder Anmeldung
eine andere IP-Adresse. Ob das Verfahren mit dem Überprüfen der IP-
Adresse eingesetzt werden kann muß demnach von Fall zu Fall geprüft
werden. Es kann sich deshalb höchstens um eine Ergänzung zu anderen
Sicherheitsvorkehrungen handeln.
Eine andere Möglichkeit einen Verbindungsaufbau von einem potentiell
unsicheren Rechner zu erschweren ist der bereits beschriebene Einsatz
von Zertifikaten. Ein Zertifikat stellt Besitz dar und der muß transportiert
werden. Bei einem Rechnerwechsel wegen Umzug oder Aufrüstung kann
ein Zertifikat problemlos per Diskette oder ähnlichem auf den neuen
Rechner übertragen werden. Da eine solche Aktion gezielt erfolgen
muß können "Unfälle", durch die Sicherheitslücken entstehen, weitgehend
vermieden werden. Niemand geht aus versehen mit einer Diskette seines
Zertifikates in ein Internetcafe, installiert es dort und baut eine
Verbindung zum Webserver auf. Das eine solche Handlungsweise fahrlässig
ist sehen sicher auch die ein, die sich eventuell von dort per Nutzername
und Password angemeldet hätten.
Die Aufgabe eine webbasierte Authentifikation mittels Zertifikaten
zu ermöglichen ist wie ich eben gezeigt habe nicht nur theoretischer
Natur. Lösungen dieser Art können sofort überall eingesetzt werden,
um webbasiert auf sensible Daten in einem Netzwerk zuzugreifen. Die
Nutzer müssen nur die Möglichkeit haben ihr Zertifikat sicher auf
ihrem lokalen Computer zu deponieren.
\includegraphics{pics/aufgabe.eps} ([fig] Prinip webbasierte Authentifikation)
Grundbedrohungen
Alle gezeigten Bedrohungen lassen sich auf drei Grundbedrohungen zurückführen.
4.1 Verfügbarkeit
Eine Bedrohung die lange Zeit unterschätzt wurde ist der Verlust der
Verfügbarkeit. Unterschätzt deswegen, weil angenommen wurde, daß nur
Systeme mit sensiblen Daten bedroht werden können. Wenn jedoch die
Seiten eines frei zugänglichen Webservers gelöscht werden ist der
Schaden oft nicht unerheblich. Das liegt daran, daß die Informationen
bis zur Wiederherstellung eben nicht zur Verfügung stehen und die
Wiederherstellung selbst natürlich auch einen Aufwand bedeutet. Die
verursachten Kosten setzen sich überwiegend aus den vorbeugend einzusetzenden
Backupmechanismen und den Verzögerungen durch das Fehlen von Information
zusammen.
\includegraphics{pics/verfueg.eps} ([fig] Verfügbarkeitsverlust)
Als Beispiel möchte ich das Löschen oder Unbrauchbarmachen eines Bibliotheksrecherchesystemes
nennen. Selbst bei einem Ausfall von nur wenigen Stunden kann die
Summe der Wartezeiten leicht mehrere tausend Stunden betragen. Es
gibt im wesentlichen zwei Arten des Verlustes der Verfügbarkeit. Zum
einen können äußere Einflüsse oder höhere Gewalt für einen Ausfall
zuständig sein. Das sind dann meist Schwierigkeiten mit zuviel oder
zuwenig Strom, unterbrochenen Leitungen und ähnlichem. Relevant für
meine Untersuchungen ist jedoch nur die andere Art von Verfügbarkeitsverlust,
die entweder absichtlich oder fahrlässig herbeigeführt unter Zuhilfenahme
eines Computers erfolgt. Es handelt sich hier meist um das Löschen,
Überschreiben oder sonst irgendwie unbrauchbar machen von Daten.
4.2 Integrität
Eine zweite Bedrohung ist der Verlust der Integrität. Im Unterschied
zum oben beschriebenen Totalausfall ist eine Veränderung von Daten
oft schwerer zu erkennen. Solche Manipulationen können über einen
längeren Zeitraum erfolgen und verringern dadurch die Chance einer
erfolgreichen Wiederherstellung der Daten durch Backups. Je älter
die Daten für die Rekonstruktion sind desto geringer ist zwar die
Wahrscheinlichkeit einer Manipulation aber desto unvollständiger bzw.
ungenauer sind sie.
Das bekannteste Beispiel für Integritätsverlust ist die ``man in the
middle attack'', bei der ein zwischen die Kommuikationspartner geschalteter
Angreifer, der sich bei beiden Beteiligten für den jeweils anderen
Partner ausgibt.
\includegraphics{pics/integri.eps} ([fig] man in the middle attack)
4.3 Vertraulichkeit
Die wohl am häufigsten auftretende Bedrohung ist der Verlust der Vertraulichkeit.
Am häufigsten deswegen, weil die Vertraulichkeit oft genug unbeabsichtigt
verlorengeht. Denn unabhängig davon, wie Daten übertragen werden,
sind sie oft genug ohne besonderen Schutz "gelagert". Das gilt besonders
für Informationen, die zwar elektronisch erstellt und bearbeitet werden,
deren Archivierung dann aber auch auf Papier erfolgt. Jeder kennt
sicher Schreibtische, auf denen sich aufgeschlagene Schnellhefter
und Aktenordner stapeln. Da kann sich schon mal ein Zettel seinen
Weg von einem Ordner zum nächsten bahnen. Ein noch größeres Problem
sind jedoch Besucher, deren Erscheinen zwar einen legitimen Grund
hat, die jedoch kaum gezwungen werden können die ganze Zeit aus dem
Fenster zu sehen und so sicher leicht die eine oder andere Überschrift
erhaschen können. Es müssen nicht immer Passwörter sein. Die Gerüchteküche
arbeitet schnell und ohne einen Quellennachweis zu fordern.
Nun ist der Computer oft Bibliothek, Büro und Aktentasche in einem
Gerät. Grund genug etwas Sorgfalt walten zu lassen und dem Geschehen
etwas Aufmerksamkeit zu schenken. Selbst bei einem gezielten Angriff
zur Informationsbeschaffung weiß das Opfer oft nicht das es bestohlen
wurde. Wir haben es schließlich mit nichts materiellem zu tun. Das
jemand über bestimmte Informationen verfügt, läßt sich daher erst
nachweisen, wenn diese verwendet werden und manchmal nicht einmal
dann. Die Verwendung eines gestohlenen, erlauschten Passwortes kann
anhand der Protokolldateien des benutzten Computers ermittelt werden.
Viele Systeme zeigen nach erfolgreicher Anmeldung wann und von wo
die letzte Anmeldung erfolgte. Wenn aber eine gestohlene Information
verwendet wird, um das Angebot eines Konkurrenten knapp zu über- oder
unterbieten um einen Auftrag zu erhalten ist ein Nachweis des Diebstahls
anhand seiner Auswirkungen nicht möglich.
\includegraphics{pics/vertrauli.eps} ([fig] Vertraulichkeit geht verloren)
4.4 Authentizität
In der Literatur wird oft von einem Verlust der Authentizität als weiterer
Bedrohung gesprochen. Vom Erscheinungsbild her ist dieses Problem
dem Verlust der Integrität sehr ähnlich. Bei einem Verlust der Authentizität
wird versucht Zugang mittels gefälschter Identität zu erlangen. Beim
Verlust der Integrität werden Informationen verfälscht. Für den Empfänger
von manipulierten Daten spielt es dabei keine Rolle, ob die Information
als Falschmeldung erzeugt wurde oder eine reguläre Anforderung verändert
wurde. Der Punkt ist, daß veränderte Informationen unbemerkt weitergegeben
werden, was sonst weder beim Verlust der Vertraulichkeit noch beim
Verlust der Verfügbarkeit der Fall ist. Der Verlust der Authentizität
stellt damit zwar eine Bedrohung dar, ist jedoch keine Grundbedrohung.
4.5 Kombinationen
In der Praxis ist es häufig so, daß eine Bedrohung durch eine andere
entsteht oder zumindest wahrscheinlicher wird. Ein Verlust von Integrität
oder Verfügbarkeit ist oft auf einen Verlust von Vertraulichkeit zurückzuführen.
Das Erlangen vertraulicher Informationen kann also als Einstieg in
die Computerkriminalität betrachtet werden da es hier eine sehr breite
Grauzone gibt in der nicht mit Sicherheit gesagt werden kann, ob sich
ein Besitzer vertraulichen Materials, das nicht für ihn bestimmt ist,
krimineller Handlungen schuldig gemacht hat um an dieses Material
zu gelangen. Es sollten also vorbeugende Maßnahmen ergriffen werden
um entsprechende Situationen von vornherein auszuschließen. Für die
Lagerung brisanter Daten besteht eine solche Maßnahme seit der Vor
- Computer - Ära im wegschließen der Daten. Das trifft heute natürlich
noch genauso zu und deshalb sollte ein LockScreen beim kurzzeitigen
Verlassen eines Rechners im Pool genauso selbstverständlich sein wie
das verschließen des Büros beim Verlassen des selben. Das eigentliche
Sicherungsproblem besteht aber bei der Übertragung von Informationen.
Prinzipien der Verschlüsselung
5.1 Der sichere Kanal
Erste Ansätze um einem Verlust der Vertraulichkeit vorzubeugen stammen
aus dem militärischen und aus dem diplomatischen Bereich. Es wurde
versucht durch entsprechend aufwendige Chiffrierung eine Nachricht
für jeden Nichteingeweihten unverständlich zu halten.
Das setzt natürlich einige Bedingungen voraus. So müssen sich die beiden
miteinander kommunizierenden Partner vor dem Übertragen der Nachricht
auf ein Chiffriersystem und eventuell die zugehörigen Schlüssel einigen.
Die Unterhaltung um eine solche Einigung zu erzielen muß über einen
sicheren Kanal geführt werden. Mit einem solchen (Übertragungs-)Kanal
ist das Medium gemeint, über das die Nachricht Übermittelt wird. Dieser
Kanal muß abhörsicher sein, um einen Schlüsselmißbrauch zu verhindern.
Da es in der Praxis einen solchen sicheren Kanal nicht gibt, denn sonst
könnte man sich die Verschlüsselung sparen und nur sichere Kanäle
verwenden, ist es notwendig, daß sich die Partner persönlich zu einem
Schlüsselaustausch treffen. Darauf, daß dies einen erheblichen Nachteil
des Systems darstellt, muß sicher nicht näher eingegangen werden.
5.2 Realisierbare Ziele
Auf die Verfügbarkeit hat die Verschlüsselung keinen Einfluß. Verfügbar
ist entweder Alles, was zwischen zwei Computern übertragen werden
soll, oder Nichts. Das liegt daran, daß Informationen zum Verbindungsaufbau
nicht verschlüsselt werden können, da Router und Gates, über die eine
Komunikation läuft, die Adressen der Beteiligten kennen müssen. Für
den mechanischen Aspekt der Verfügbarkeit gilt diese "geht oder geht
nicht" Eigenschaft ebenfalls. Ein Computer ist verfügbar, wenn eine
physische Verbindung aufgebaut werden kann, oder ist nicht verfügbar,
weil z.B. die Leitung unterbrochen ist.
Gegen die anderen bereits beschriebenen Bedrohungen kann Verschlüsselung
eingesetzt werden. Sie wird also verwendet, um Integrität und Vertraulichkeit
zu sichern. Weil über das Anfertigen verschlüsselter Nachrichten auch
der Besitz der zugehörigen Schlüssel nachgewiesen wird, kann über
diesen Umweg auch eine Authentifikation realisiert werden, denn wer
in der Lage ist eine gültige verschlüsselte Nachricht zu erzeugen,
muß dazu im Besitz der richtigen Schlüssel sein und ist mit großer
Wahrscheinlichkeit der richtige Kommunikationspartner.
Bei all den phantastischen Sachen, die mit Verschlüsselung getan werden
können ist zu beachten, daß sie Sicherheitsbedürfnisse befriedigen
soll und das am besten unauffällig, schnell und vollautomatisch. Während
früher die Entschlüsselung einer Nachricht mühselig von Hand erfolgte
wird sie heute vom PC am Arbeitsplatz durchgeführt ohne das der Nutzer
eine Verzögerung bemerkt. Was jedoch bei vielen Verfahren negativ
auffällt ist der hohe Verwaltungsaufwand. Besonders beim Schlüsselmanagement
besteht Bedarf für eine sanftere Integration in bestehende Applikationen.
Kryptosysteme
6.1 symetrische Kryptosysteme
Verfahren, bei denen sich Sender und Empfänger einen geheimen Schlüssel
teilen bezeichnet man als symetrische Kryptosysteme, da zur Codierung
derselbe Schlüssel eingesetzt wird wie zur Decodierung und nur der
Algorithmus in umgekehrter Reihenfolge abgearbeitet wird oder bei
der Decodierung genau das Gegenteil von dem getan wird, was zur Codierung
erforderlich war. Bei vielen dieser Kryptosysteme wurde nicht nur
der Schlüssel geheimgehalten, sondern auch die Arbeitsweise des Systems
selbst um noch einmal die Sicherheit zu erhöhen.
Von allen heute anerkannten Kryptosystemen ist auch deren Arbeitsweise
bekannt, da eine Anerkennung und die damit einhergehende Überprüfung
sicherheitsrelevanter Eigenschaften nur durch Diskussion in einer
breiten Öffentlichkeit zustande kommen kann. Trotzdem ist es nicht
trivial vom Chiffrat auf das verwendete Kryptosystem zu schließen,
was in etwa der Tatsache entspricht, daß verwendete System geheimzuhalten.
Schlüssel und Kryptosystem geheimzuhalten war nötig, da es keine mathematischen
Untersuchungen zur Sicherheit dieser Kryptosysteme gab, also ein Angriff
auf das System ohne Schlüsselkenntnis nicht ausgeschlossen werden
konnte. Das änderte sich erst, als die Verbreitung von Rechentechnik
den Datenaustausch mit vielen verschiedenen Partnern ermöglichte.
\includegraphics{pics/symet.eps} ([fig] Funktionsweise symetrischer
Kryptosysteme)
6.1.1 Standardisierung
Es war nötig, eine einheitliche Plattform zu schaffen, um auf deren
Basis eine sichere Kommunikation zu ermöglichen. Eine solche Plattform
bringt eine Reihe von Vorteilen mit sich. So wird zum Beispiel verhindert,
daß viele verschiedene Algorithmen implementiert werden, mit deren
Hilfe dann jeweils nur wenige Leute Daten austauschen können. Außerdem
müßte irgendwann jeder diese Fülle von Algorithmen auf seinem Rechner
haben. Die Implementierung vieler kleiner Systeme bindet so viele
Kräfte, daß diese erfahrungsgemäß schlechter realisiert werden und
mehr Sicherheitslücken enthalten, als ein großes Kryptosystem. Das
das Verfahren, nach dem dieses Kryptosystem arbeitet bekannt gegeben
werden mußte war nötig, weil Implementationen für verschiedene Rechnerarchitekturen
realisiert werden mußten und diese Implementationen natürlich auch
käuflich sein sollten. Ein Verstecken des Algorithmus ist also nicht
möglich, denn der kann durch Analyse des Binärcodes ohnehin ermittelt
werden.
Anfang der 70er Jahre wurde eine Liste mit Bedingungen für ein solches
Kryptosystem erstellt. Bei IBM wurde zu dieser Zeit an einem System
gearbeitet, daß bereits viele dieser Anforderungen erfüllte. Sie erhielten
aus diesem Grund den Auftrag ihr System weiterzuentwickeln. Die Ergebnisse
wurden von der NSA geprüft, getestet und 1977 unter dem Namen DES
"Data Encryption Standard" von ANSI für die USA zum Standard erklärt.
Es wurden Hardwarerealisierungen gebaut, um zu Ermöglichen, daß der
Durchsatz der Codierung und Decodierung dem Datentransfer in Computernetzen
in nichts nachsteht. In vielen UNIX-Derivaten steht der Befehl "des"
noch heute zur Verfügung, sollte jedoch nur noch unter Vorbehalt verwendet
werden.
6.1.2 Verwendbarkeit
"Bis heute ist keine ernsthafte Verwundbarkeit von DES aufgedeckt worden.
Zudem hat die Hardware einen zur vollständigen Schlüsselraumsuche
notwendigen Entwicklungsstand noch nicht erreicht." schrieb Oppliger
1992 \cite{2}. Im ersten gennanten Punkt hat sich bis heute nichts
geändert. Kryptoanalytisch kann der DES heute noch als sicher betrachtet
werden. Anders sieht das allerdings beim Durchprobieren der Schlüssel
aus.
Beim letzten öffentlichen Test, an dem im Januar 1999 etwa 100000 Computer
per Internet und ein speziell zu diesem Zweck entwickelter Computer
mit dem Namen DeepCrack teilnahmen wurde der richtige Schlüssel in
einer Zeit von nur 22 Stunden und 15 Minuten gefunden \cite{3}. Nun
ist einem einzelnen Angreifer nicht dieses Potential an Hardware gegeben,
jedoch weiß auch niemand wieviele Rechner ala DeepCrack weltweit im
Einsatz sind.
Verschlüsselung mittels DES sollte also nur noch dort eingesetzt werden,
wo die Nachricht innerhalb von Stunden ihre Bedeutung verliert, oder
dann ohnehin bekannt ist. Da wo heute der DES eingesetzt wird erfolgt
meist eine Mehrfachverschlüsselung mit unterschiedlichen Schlüsseln.
Bei einem Einsatz von Triple-DES, also einer Dreifachverschlüsselung
steigt damit die Schlüssellänge 168 Bit. Die Anzahl möglicher Schlüssel
steigt somit von 2^56 auf 2^168, einer Größe die momentan jedem Angriff
standhalten sollte.
Um noch einmal auf das Beispiel mit den Angeboten zurückzukommen. Wenn
jeder sein Angebot wenige Stunden vor dem Abgabetermin zuschickt hat
ein potentieller Konkurrent keine Möglichkeit sich daran zu Orientieren,
da er die Nachricht erst zu einem Zeitpunkt aus dem Chiffrat extrahieren
kann zu dem sie ihm nichts mehr nützt. Das erhöht leider nicht die
Sicherheit des Kryptosystems selbst. Der hohe Datendurchsatz, der
einst als Vorteil vom DES gepriesen wurde ist nun sein größter Nachteil,
da dieser Vorteil mit, aus heutiger Sicht, zu kurzen Schlüsseln erkauft
wird. Außerdem sind diese Schlüssel konstant 56 Bit lang. Ein skallieren
der Schlüssellänge, wie bei anderen Systemen, ist leider nicht möglich.
6.2 Asymetrische Kryptosysteme
Revolutioniert wurden Kryptosysteme seit 1976 nach dem veröffentlichen
einer Arbeit durch Whitfield Diffie und Martin Hellman [DIF76]. Diese
beiden Wissenschaftler legten den Grundstein für eine neue Art von
Kryptosystemen, den Public-Key-Kryptosystemen. Zwar gilt heute als
ziemlich sicher, daß die Idee eines solchen Verfahrens bereits vor
Veröffentlichung der Arbeit bei einigen Institutionen bekannt gewesen
ist \cite{4}, die Forschung auf diesem Gebiet setzte jedoch erst zu
diesem Zeitpunkt ein.
Der Name Public-Key-Kryptographie rührt daher, daß es hier keinen geheimen
Schlüssel für Codierung und Decodierung gibt, den sich alle beteiligten
Kommunikationspartner teilen, sondern zur Kommunikation zwei Schlüssel
erforderlich sind. Einer dieser Schlüssel wird Private-Key genannt,
der andere Public-Key. Er gab diesem Verfahren den Namen. Public-Key-Kryptosysteme
werden heute zumeist als Asymetrische-Kryptosysteme bezeichnet um
gleich in der Namensgebung eine Unterscheidung zu Systemen mit einem
gemeinsamen Schlüssel, wie dem DES, zu erhalten.
Wenn jemand seinem Gegenüber eine verschlüsselte Nachricht zukommen
lassen möchte und dazu ein asymetrisches Verfahren einsetzt, dann
verschlüsselt er seine Nachricht mit dem öffentlichen Schlüssel (public
key) des Empfängers. Nachdem er das getan hat besteht für ihn selbst
keine Möglichkeit mehr die Nachricht aus dem Chiffrat zu extrahieren.
Alle potentiellen Angreifer, die nur über den öffentlichen Schlüssel
verfügen, können dies natürlich ebenfalls nicht.
Der einzige Weg wieder an die Nachricht zu gelangen führt über den
privaten Schlüssel (private key) und der sollte sich nur beim rechtmäßigen
Besitzer befinden. Die Verantwortung für das Schlüsselmanagement,
also die Generierung und Aufbewahrung des Schlüsselpaares unterliegt
jedem selbst. Ein Gefahrenpotential, wie es das bei symetrischen Systemen
durch die Kenntnis mehrerer Leute von einem bestimmten Schlüssel gab,
existiert nicht mehr.
Ein großer Vorteil, den es mit sich bringt, wenn ein Schlüssel zum
codieren und einer zum decodieren eingesetzt wird ist der, daß sich
die Kommunikationspartner nicht persönlich treffen müssen um sich
auf Schlüssel zu einigen. Wenn jeder seine beiden Schlüssel generiert
und den öffentlichen an geeigneter Stelle da hinterläßt, wo ihn mögliche
Kommunikationspartner finden können steht einer gesicherten Übertragung
nichts mehr im Weg. Ein Verlußt der Vertraulichkeit muß auf jeden
Fall nicht befürchtet werden, wenn die Authentizität der Schlüssel
sichergestellt ist.
Es genügt also nicht, den Schlüssel irgendwo gut erreichbar zu deponieren,
wenn es an dieser Stelle eine übergeordnete Einrichtung gibt, die
den Schlüssel austauschen könnte. Eine solche administrative Instanz
hat aber fast jeder bei seiner Homepage, einem FTP-Verzeichnis oder
ähnlichem. Eine mögliche aber umständliche Lösung ist es, seinen Schlüssel
an vielen verschiedenen Orten zu deponieren und die Liste dieser Orte
beizufügen. Wenn diese Depots in unterschiedlichen Einflußbereichen
liegen, sollte es einem Angreifer schwerfallen alle Schlüssel auszutauschen.
Ein Kommunikationspartner kann dagegen mit erträglichem Aufwand die
Gleichheit der Schlüssel prüfen.
Die praktikablere Lösung ist dagegen sich die Echtheit seines Schlüssels
von einer dritten Instanz bestätigen zu lassen. Im einfachsten Fall
kann das die Datenbank eines Trust-Centers sein, in der jeder Interessierte
nach öffentlichen Schlüsseln möglicher Kommunikationspartner suchen
kann. Wenn man diese Idee zu Ende denkt kommt man jedoch unweigerlich
zu Zertifikaten und die sind von den Certification Authorities mit
Bedacht auszustellen, können dann aber bedenkenlos gelagert werden.
Neben der Vertraulichkeit steht aber auch die Integrität ganz oben
auf dem Wunschzettel der Anwender. Nach der jetzigen Beschreibung
asymetrischer Kryptosysteme hätte ein Angreifer die Möglichkeit eine
Nachricht abzufangen, deren Zieladresse und damit den öffentlichen
Schlüssel des Empfängers zu ermitteln. Danach könnte er eine eigene
Nachricht verfassen und diese eventuell im Namen des Absenders an
den Empfänger weiterleiten. Um das zu verhindern besteht bei asymetrischen
Kryptosystemen die Möglichkeit seine Nachricht digital zu signieren.
Es ist nicht vorgeschrieben welcher der beiden Schlüssel der öffentliche
und welcher der private ist. Der Nutzer kann vor dem ersten Einsatz
wählen welchen von beiden er bekanntgibt. Was mit einem Schlüssel
codiert wurde kann immer mit dem anderen decodiert werden. Dadurch
ist es möglich eine Nachricht mit seinem eigenen privaten Schlüssel
zu codieren. In einem uncodierten Teil, der an die Nachricht angefügt
wird, wird dann beschrieben von wem die Nachricht stammt und wo der
zugehörige öffentliche Schlüssel zu finden ist. Der Empfänger erhält
so die Möglichkeit den Absender zu überprüfen und mit dessen öffentlichem
Schlüssel die Nachricht zu extrahieren.
\includegraphics{pics/asym.eps} ([fig] Asymetrisches Kryptosystem mit
Signatur)
Da asymetrische Kryptosysteme sehr rechenintensiv sind wird meist nicht
die gesammte Nachricht, sondern ein aus der Nachricht zu berechnender
Hashwert unterschrieben. Das bringt vor allem bei Informationen die
nicht vertraulich sind und öffentlich bekannt gegeben werden den Vorteil,
daß nachträgliche Veränderungen nicht dem ursprünglichen Author untergeschoben
werden können. Nach einer Änderung der Nachricht stimmen alter und
neuer Hashwert nicht mehr überein, wodurch ein erneutes Signieren
des Hashwertes mit einem geheimen Schlüssel erforderlich wird. Die
Empfänger der Nachricht, also mögliche News Leser, können dann selbst
Entscheiden wie mit einer Nachricht zu Verfahren ist, der kein gültiger
Absender zugeordnet werden kann. Eine Schwierigkeit die dann noch
besteht ist, daß nur schwer ermittelt werden kann, wer ursprünglicher
Author einer Nachricht ist, denn Zurückdatieren und neu Verpacken
kann jeder.
Die Integrität einer Nachricht kann also gewährleistet werden. Maßnahmen
zum Erhalt der der Integrität und Vertraulichkeit lassen sich auch
miteinander kombinieren. So kann eine Nachricht nach ihrer Erstellung
erst mit dem eigenen privaten Schlüssel unterschrieben werden um eine
nachträgliche Manipulation zu vermeiden. Anschließend codiert man
die Nachricht samt Unterschrift mit dem öffentlichen Schlüssel des
Empfängers um die Vertraulichkeit zu wahren.
6.2.1 NP-vollständige Probleme
Bis jetzt habe ich über die Anwendungsmöglichkeiten asymetrischer Kryptosysteme
geschrieben, im Folgenden soll der theoretische Hintergrund beleuchtet
werden. Die Idee, die allen solchen Systemen zu Grunde liegt, ist
die, daß es mathematische Einwegfunktionen gibt. Das sind Funktionen,
deren Lösung einfach zu realisieren ist, wogegen ihre Umkehrung nahezu
unmöglich ist. Einfach zu realisieren bedeutet, daß die Lösung mit
polynomialem Aufwand berechnet werden kann. Nahezu unmöglich heißt
dagegen, daß der Aufwand zur Lösung des Problems mindestens ein exponentielles
Wachstum im Vergleich zur Eingabe aufweißt. Probleme deren Lösungsaufwand
jenseits des polynomiellen liegt nennt man NP-vollständig, sie sind
mit nichtpolynomiellem Aufwand lösbar.
Eines der wohl bekanntesten Probleme dieser Art, und das am meisten
eingesetze in der Kryptographie, ist das Faktorisierungsproblem. Es
einfach zwei Zahlen miteinander zu multiplizieren, jedoch sehr schwierig
vom Produkt auf die verwendeten Faktoren zu schließen. Da das Ermitteln
der Faktoren stark erleichtert wird, wenn das Produkt aus vielen Faktoren
besteht werden zur Berechnung Primzahlen verwendet. Durch den Einsatz
von Primzahlen wird gewährleistet, daß das Produkt nur aus exakt zwei
Faktoren besteht.
Seit der Verwendung des Faktorisierungsproblems in der Kryptographie
wurden eine Reihe von Algorithmen geschrieben, um den Bedarf an großen
Primzahlen zu decken. Die Priemzahlen müssen schließlich dort berechnet
werden, wo daraus die beiden Schlüssel für das public-key Kryptosystem
entstehen sollen, und das ist normalerweise der lokale Computer des
Nutzers.
Im Gegenzug wird versucht, im Rahmen der Kryptoanalyse, Wege zur Faktorisierung
großer Zahlen zu finden. Bislang wurde keine generelle Lösung gefunden,
die gefundenen Ansätze schränken allerdings die Wahl der zu verwendenen
Primzahlen ein. Neben der Aussage, daß die verwendeten Primzahlen
möglichst groß sein sollen, um ein durchprobieren zu verhindern, sollten
sie unter anderem auch weit auseinanderliegen, da es sich sonst aus
Primzahlen handelt, die ähnlich groß wie die Wurzel der zu faktorisierenden
Zahl sind, was auch wieder eine erhebliche Eingrenzung des Suchraumes
ermöglicht.
6.2.2 RSA
Die verbreitetste Implementierung, eines Kryptosystems auf der Basis
des Faktorisierungsproblems ist das RSA Verfahren. Es wurde zwei Jahre
nach der Arbeit von Diffie und Hellmann vorgestellt und ist nach dessen
Entwicklern Rivest, Shamir und Adleman benannt. Der Tatsache, daß
es sich um eine sehr frühe Implementierung eines asymetrischen Kryptosystems
handelt, und bis heute kein erfolgreicher Angriff bekannt wurde, verdankt
dieses Kryptosystem seine große Popularität. Weil die Schlüssellänge
vom Benutzer festgelegt wird und nicht fest vorgegeben ist, konnte
in den letzten 20 Jahren mit der Verbesserung der Hardware auch immer
die Schlüssellänge erhöht werden.
Das RSA Verfahren wird heute in vielen Bereichen eingesetzt da es sowohl
zu Signaturzwecken als auch zur Verschlüsselung eingesetzt werden
kann. Ein Beispiel für die Verwendung von RSA ist sicher PGP. PGP
steht für Pretty Good Privacy und wird zum Schutz von E-Mail und Dateien
eingesetzt. In PGP kann mit dem eigenen Private-Key unterschrieben
und mit dem Public-Key des Empfängers verschlüsselt werden. Großer
Vorteil des PGP Paketes ist, daß es so in einige der gängigen Mailprogramme
integriert werden kann, das die Benutzer mit PGP fast nicht mehr in
Berührung kommen, und der Arbeitsaufwand dadurch minimiert wird. Es
lassen sich globale Einstellungen treffen, in denen festgelegt wird,
ob Mails digital zu unterschreiben und wenn möglich zu verschlüsseln
sind.
6.3 hybride Kryptosysteme
Größter Nachteil asymetrischer Kryptosysteme und damit auch Nachteil
von RSA ist die hohe Rechenleistung, die bei einem Einsatz benötigt
wird. Das wird durch die Verarbeitung auf Universalprozessoren, die
oft einen für diese Art von Kryptosystemen ungeeigneten Befehlssatz
haben, noch gesteigert. RSA wird eben zunehmend auch im privaten Bereich
eingesetzt und da spielt Bearbeitungszeit eine untergeordnete Rolle.
Um dennoch akzeptable Resultate zu erziehlen ist ein möglicher Weg
die Vorteile symetrischer und asymetrischer Kryptosysteme zu vereinigen.
Eine solche Kombination beider Systeme nennt man hybrides Kryptosystem.
Es handelt sich dabei um keine neue Art von Kryptosystem, sondern
um das zeitlich versetzte Abarbeiten eines asymetrischen und danach
eines symetrischen Verfahrens.
Bei dieser Vorgehensweise erfolgt mittels public-key Kryptosystem der
Schlüsselaustausch für den anschließenden Einsatz eines viel schnelleren
symetrischen Verfahrens. Es spielt dabei keine Rolle, ob eine stehende,
interaktive Verbindung zu einem Rechner aufgebaut werden soll oder
es sich um eine reine Datenübertragung ohne Beteiligung des Empfängers
handelt. Man kann also dem Empfänger einer Mail RSA chiffriert den
DES Schlüssel mitteilen, mit dem der eigentliche Inhalt der Mail Chiffriert
ist. Dazu ist lediglich die Kenntniss des öffentlichen Schlüssels
des Empfängers nötig.
Ein Programmpaket, bei dem dieses hybride Verfahren eingesetzt wird
um Verbindungen zu anderen Computern aufzubauen, ist SSH. Die Abkürzung
bedeutet SecureSHell und weist schon darauf hin, daß zu übertragende
Datenpakete unter einer sicheren Schale verpackt werden. Dabei können
zur Authentifizierung die unterschiedlichsten Verfahren eingesetzt
werden und nur als letzte Möglichkeit wird nach einem Password gefragt,
daß aber auch nur chiffriert übertragen wird. Auf prinzipielle Möglichkeiten
zur Authentifizierung, wurde in früheren Abschnitten bereits eingegangen.
Für die technische Realisierung bei SSH möchte ich den interessierten
Leser an die manual-pages verweisen, da hier neben der Beantwortung
syntaktischer Fragen auch auf das Umfeld beim Einsatz eingegangen
wird.
SSH wurde entwickelt, um eine Reihe weit verbreiteter aber unsicherer
Netzwerkprogramme abzulösen oder zu ergänzen. Zu einer sicheren Datenübertragung
ala FTP wird innerhalb des Paketes das Programm SCP (Secure CoPy)
bereitgestellt. Bei der Verwendung von unsicheren Programmen auf einem
entfernten Computer, bei denen lediglich die Ein- und Ausgabe vom
lokalen Computer aus erfolgt, übernimmt SSH selbst die Sicherung der
Daten. SSH bildet hier im einfachsten Fall eine sicher Alternative
zu telnet, dem Klassiker der seit den Anfängen von Computernetzen
die Möglichkeit zum Ausführen von Programmen auf entfernten Computern
liefert. SSH sichert dabei auch alle Folgeverbindungen, die im Rahmen
der bestehenden Verbindung aufgebaut werden. Das betrifft vor allem
die Ein- und Ausgaben von an den lokalen Computer weitergeleiteten
X11-Fenstern für die sonst keine anderen Sicherungsmöglichkeiten bestehen.
Programmpakete wie SSH sind dabei in der Lage unterschiedliche symetrische
Kryptosysteme einzusetzen weil die Gesetzgebung von Land zu Land verschieden
ist und nicht überall jedes Kryptosystem eingesetzt werden darf. Außerdem
liegt es im Bereich des Möglichen, daß ein Kryptosystem total gebrochen
wird, d.h. ein Weg gefunden wird mit erträglichem (polynomiellem)
Aufwand ohne Schlüsselkenntnis in den Besitz der Nachricht zu gelangen.
Um in einem solchen Fall schnell Reagieren zu können verfügt die aktuelle
Version von SSH über die Möglichkeit die Daten nach der Authentifizierung
mit IDEA, BLOWFISH, ARCFOUR, DES und 3DES zu chiffrieren.
Die Mechanismen zur Authentifizierung bei SSH sind darauf abgestimmt
zu überprüfen, ob der Nutzer auf dem Zielrechner ein login hat und
demzufolge in der Lage ist Prozesse zu starten oder auf das Dateisystem
zuzugreifen. Der Nutzer muß also auf beiden kommunizierenden Computern
über eine Reihe von Betriebsmitteln verfügen können und das unabhängig
davon, ob diese bei der Kommunikation tatsächlich verwendet werden.
Der Aufbau von sicheren Verbindungen zum Zwecke der Informationsbeschaffung
mit Unterstützung von SSH ist also nur möglich, wenn der Nutzer auf
dem Zielrechner ein login hat. Das ist aus vielerlei Gründen nicht
möglich. Man stelle sich nur vor, daß alle n Webserver weltweit jeden
der m potentiellen Nutzer kennen müßte. Bei einer webbasierten Authentifikation
müssen demnach andere Wege gegangen werden.
Um eine sichere Webverbindung zu realisieren müssen also andere Wege
beschritten werden. Die bislang beschriebenen Techniken können dabei
natürlich eingesetzt werden. Lediglich zur Authentifizierung müssen
andere Maßnahmen eingesetzt werden.
Im einfachsten Fall erfolgt die Datenbeschaffung von einem Web-Server
durch einen Verbindungsaufbau auf Port 80 des Servers gefolgt von
einer Anfrage zum Erhalt eines Dokumentes. Nach der Übertragung der
geforderten Information, oder einer Meldung, daß dies nicht möglich
war, wird die Verbindung durch den Server wieder geschlossen. Das
für die Übertragung verwendete Protokoll ist so einfach, das es unter
Umständen ohne Browser durch die Verwendung von Telnet realisiert
werden kann.
mmr@pumuckl:~ > telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /
You are connected to pumuckl.csn.tu-chemnitz.de
Connection closed by foreign host.
mmr@pumuckl:~ >
Secure Socket Layer
Um nun dem bestehenden Sicherheitsbedürfnis gerecht zu werden ist von
der Netscape Communications Corporation das SSL Protokoll entwickelt
wurden. SSL steht für Secure Socket Layer. Dieses Protokoll speziell
für den Datenaustausch im WWW entwickelt wurden. Das zeigt sich schon
beim Verbindungsaufbau, denn bei SSL authentifiziert sich der Server
gegenüber dem Clienten. Das ist etwa so, als müßte der jenige, der
angerufen wird zuerst seinen Namen nennen, ohne zu wissen wer am anderen
Ende ist. Im WWW hat diese Reihenfolge aber ihre Berechtigung, da
Information zwar an jeden weitergegeben wird, aber trotzdem die Quelle
prüfbar sein muß.
Als nächstes einigen sich beide Teilnehmer auf ein gemeinsames Kryptosystem,
mit dem Daten chiffriert werden sollen. Je nach eingestellter Sicherheitsstufe
kann der Server anschließend auch eine Authentifikation vom Clienten
verlangen. Wenn das erfolgreich verläuft müssen sich Server und Client
nur noch auf den Schlüssel zum vereinbarten Kryptosystems einigen
um mit der Kommunikation zu beginnen. Diesen Schlüssel nennt man auch
verteiltes Geheimnis, weil nur diese beiden entfernten Kommunikationspartner
Kenntnis davon haben.
Man unterscheidet innerhalb des SSL Protokolls zwischen zwei Teilen.
In dem Teil, der für den Verbindungsaufbau zuständig ist, erfolgt
die Authentifikation und werden Maßnahmen getroffen, um später die
Integrität der Daten zu gewährleisten. Der zweite Teil übernimmt dann
nach erfolgreichem Verbindungsaufbau den Datentransfer.
Da das SSL-Protokoll die die praktische Grundlage für meine Arbeit
liefert möchte ich nun detailiert auf den dabei verwendeten Verbindungsaufbau,
also dem ersten Teil des Protokolls eingehen. Die Grundlagen hierzu
lieferte Netscape selbst \cite{5}.
1. Der Client sendet dem Server seine SSL Versionsnummer, Angaben zu
möglichen Chiffren, Zufallsdaten und einige weitere Daten, die jedoch
auch ohne die Verwendung von SSL nötig wären.
2. Der Server teilt dem Clienten seine Versionsnummer mit, wählt das
stärkste symetrische Kryptosystem aus, mit dem beide arbeiten können.
Er überträgt Zufallsdaten und sein eigenes Zertifikat an den Clienten.
Wenn der Client ein Betriebsmittel anfordert, für das eine Authentifikation
erforderliche ist wird das Zertifikat des Clienten angefordert.
3. Der Client benutzt die vom Server erhaltenen Informationen um diesen
zu authentifizieren. Das geschieht erfolgreich, wenn alle der folgenden
Fragen mit "ja" beantwortet werden. - Ist das aktuelle Datum innerhalb
der Gültigkeitsperiode des Serverzertifikates ? - Kann der austellenden
CA vertraut werden ? - Kann mit Hilfe des öffentlichen Schlüssels
der CA die Unterschrift des Zertifikates bestätigt werden ? - Stimmt
der im Zertifikat eingetragene Domainname mit dem tatsächlich verwendeten
überein ? Wenn der Server nicht authentifiziert werden kann erhält
der Nutzer eine Warnung und muß selbst entscheiden, ob der Verbindungsaufbau
fortgesetzt werden soll.
4. Vom Clienten wird, in Anhängigkeit des vom Server ausgewählten Kryptosystems,
ein Geheimnis erzeugt, aus dem dann später der Sitzungsschlüssel
generiert wird. Dieses Geheimnis wird dann mit dem öffentlichen
Schlüssel des Servers, der dessen Zertifikat entnommen wurde, verschlüsselt
und dem Server zugesandt.
5. Wenn der Server die Authentifikation des Clienten fordert, dann unterschreibt
der Client einige vom Server empfangene Zufallsdaten und sendet
das Unterschriebene zusammen mit seinem Zertifikat an den Server.
6. Falls gefordert, versucht der Server nun den Clienten zu authentifizieren.
Dazu prüft er die unterschriebenen Zufallsdaten mit dem öffentlichen
Schlüssel aus dem Zertifikat des Clienten und stellt so fest, ob
das Zertifikat wirklich denem Gegenüber gehört. Alle weiteren zu
beantwortenden Fragen sind ähnlich denen der Serverauthentifikation.
- Ist das aktuelle Datum innerhalb der Gültigkeitsperiode des Clientzertifikates
? - Kann der ausstellenden CA vertraut werden ? - Kann mit Hilfe
des öffentlichen Schlüssels der CA die Unterschrift des Zertifikates
bestätigt werden ? Wenn der Client nicht authentifiziert werden
kann, dann wird die Sitzung beendet. Anderenfalls verwendet der
Server seinen privaten Schlüssel, um an das vom Clienten übertragene
Geheimnis zu gelangen.
7. Aus diesem Geheimnis wird sowohl vom Server als auch vom Clienten
der Sitzungsschlüssel des symetrischen Kryptosystems generiert,
das zur Sicherung der übertragenen Daten verwendet werden soll.
8. Der Client sendet eine Nachricht um dem Server mitzuteilen, daß ab
jetzt alle Nachrichten verschlüsselt ausgetauscht werden und eine
weitere verschlüsselte Nachricht, um dem Server mitzuteilen, daß
aus Sicht des Clienten der Verbindungsaufbau abgeschlossen ist.
9. Der Server sendet daraufhin seinerseits diese beiden Nachrichten.
Die Verbindung steht nach Abarbeitung dieser Punkte, der erste Teil
des Protokolls wurde erfolgreich beendet und es kann an dieser Stelle
begonnen werden Informationen unter Verwendung des Sitzungsschlüssel
auszutauschen.
Einrichtung des Clienten
8.1 Browser
Um bei meiner Arbeit auf das SSL-Protokoll zurückgreifen zu können
muß ich mich für einen Clienten entscheiden, der dieses Protokoll
beherscht. An dieser Stelle ist es naheliegend den Netscape Navigator
zu verwenden, da hier die zu erwartenden Probleme am geringsten sein
sollten. Im Web browsen können heute die meisten Filemanager. Die
hier gestellten Anforderungen gehen aber deutlich darüber hinaus.
8.2 Zertifikate
Neben allgemeinen Einstellungen um den Browser in Betrieb zu nehmen,
muß man ihm auch das Zertifikat des Clienten zukommen lassen, mit
dem man sich später beim Server authentifizieren möchte. Dazu gibt
es beim Netscape Navigator zwei Möglichkeiten.
8.2.1 Keygen
Die erste Möglichkeit, den Netscape Navigator mit einem Zertifikat
zu versorgen, ist ihn per HTML-Tag anzuweisen die für das Zertifikat
erforderlichen Schlüssel zu generieren \cite{6}. In diesem Fall steht
irgendwo im Quelltext des zum Erhalt eines Zertifikates auszufüllenden
Fragebogens :
Die Parameter NAME und CHALLENGE sind immer zu übergeben. Mit KEYTYPE
kann zwischen dem RSA und dem DSA Verfahren gewählt werden und der
PQG Parameter wird nur benötigt um Einstellungen für DSA vorzunehmen.
Wird kein Challenge String unterstützt, dann wird ein IA5STRING der
Länge null übergeben. Im einfachsten Fall sieht eine Anforderung also
folgendermaßen aus :
Zu beachten ist, daß in den Netscape Exportvarianten nur Schlüssel
mit einer Länge von 512 Bit generiert werden, wärend die USA-Version
die sonst übliche Länge von 1024 Bit unterstützt.
Alle weiteren Angaben sind vom Nutzer einzugeben und werden zusammen
mit dem vom Browser generierten öffentlichen Schlüssel an ein Programm
auf dem Server übergeben. Bei diesem Programm handelt es sich üblicherweise
um ein CGI- oder Perl-Script, das die Erstellung des Zertifikates
durch ausführen einer Reihe von SSL-Befehlen übernimmt.
Größtes Problem dabei ist es, sicherzustellen für wen das gerade generierte
Zertifikat bestimmt ist, denn die Kommunikation zum Erhalt des Zertifikates
läuft zwar über https aber eventuell ohne Client Authentifikation
weil dessen Zertifikat gerade erst generiert wird.
Verisign, eine amerikanische CA, bietet potentiellen Kunden ein Testzertifikat
mit einer Gültigkeitsdauer von sechs Wochen an. Die CA prüft dabei
nur, ob der Nutzer in der Lage ist die Post an eine von ihm anzugebende
E-Mail Adresse zu lesen. Es wird nach dem Antrag im WWW eine Art Password
per Mail verschickt und wenn das wieder korrekt auf der Webseite von
Verisign eingegeben wird erhält der Nutzer sein Zertifikat.
Diese Vorgehensweise ist von vielen Seiten kritisiert wurden \cite{7}.
Diese Zertifikate enthalten zwar den Vermerk, daß sich der Nutzer
lediglich mit einer E-Mail Adresse ausgewiesen hat, aber das in umlauf
Bringen unsicherer Zertifikate schadet dem Einsatz eines ansonsten
sehr nützlichen Verfahrens doch mehr als es den wenigen Nutzern innerhalb
der Testphase nützt.
Das Generieren von Zertifikaten aus dem Browser heraus sollte also
nur eingesetzt werden, wenn der Nutzer sich gegenüber der ausstellenden
Instanz so sicher authentifizieren kann, wie das später mit seinem
neuen Zertifikat möglich wird. Ein mögliches Einsatzgebiet ist das
aktualisieren von Zertifikaten kurz vor ihrem Verfallsdatum. Hier
werden zwar meist die Schlüssel beibehalten, es kann sich aber durchaus
erforderlich machen deren Länge zu erhöhen und deshalb neue zu wählen.
8.2.2 Zertifikate importieren
Eine unter dem Gesichtspunkt der Authentifikation praktikablere Lösung
für das Erstellen von Zertifikaten ist das Zertifizieren bei der CA
mit anschließendem Import einer Zertifikatsdatei in den Browser.
Da Zertifikate eine Grundlage für eine sichere Kommunikation oder Authentifikation
in Netzwerken bilden ist es nicht verwunderlich, daß bei der Authentifikation
zur Erlangung eines Zertifikates andere, konventionellere Wege gegangen
werden müssen. Viele CA's schreiben daher in ihrer Policy, dem Regelwerk
das ihrem Handeln zugrundeliegt, vor, daß die Identität eines Nutzers
durch sein persönliches Erscheinen und Vorlegen amtlicher Dokumente
zu prüfen ist. Da CA's einen großen Einzugsbereich haben können wird
teilweise auf vertrauenswürdige Registrierungsinstanzen zurückgegriffen,
die lokal die Identität und Authentizität von Nutzern prüfen können.
Als Beispiel hierfür sei die Policy des Individual Network e.V. aufgeführt
\cite{8}. Diese Policy liegt auch der CA der Firma IKS GmbH Jena zugrunde
und ermöglichte es mir mich hier in Chemnitz auszuweisen und dadurch
die Fahrt nach Jena zu vermeiden.
Eigene CA erstellen
9.1 OpenSSL
Nachdem die CA den Nutzer überprüft hat kann damit begonnen werden
das eigentliche Zertifikat zu erstellen. Dazu ist eine SSL-Implementierung
nötig, die in der Lage ist Schlüssel für ein asymetrisches Kryptosystem
zu generieren, Nutzerzertifikate zu erstellen, zu verwalten und in
spezielle Formate zu konvertieren. Erste Versuche mit SSLeay schlugen
leider fehl, da die von mir verwendete Version leider nicht das pkcs12
Format verstand, das für den Import in aktuelle Versionen (4.x) des
Netscape Navigators nötig ist. Alle anderen Schritte liefen zwar reibungslos
ab, aber was nützt das, wenn nicht der komplette benötigte Funktionsumfang
der SSL Version 3 implementiert ist. Ich mußte mich also nach einem
alternativen Programmpaket umsehen und fand is in OpenSSL, das seit
August in der Version 0.9.4 vorliegt.
Weil das Clientzertifikat von einer CA ausgestellt werden muß und hier
gezeigt werden soll wie das geschieht brauchen wir eine CA. Das OpenSSL
Paket enthält eine Reihe von Scripten um für den Administrator absehbare
Routinetätigkeiten zu vereinfachen und dadurch die Fehlerquote zu
reduzieren. Der folgende Dialog zeigt, wie mit Hilfe des Scriptes
CA.sh eine Certification Authority angelegt wird :
root@pumuckl:/usr/local/ssl/misc > /usr/local/ssl/misc/CA.sh -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Using configuration from /usr/local/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.....+++++
....+++++
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:de
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Technische
Universitaet Chemnitz
Organizational Unit Name (eg, section) []:CSN
Common Name (eg, YOUR name) []:CA pumuckl.csn.tu-chemnitz.de
Email Address []:mmr@informatik.tu-chemnitz.de
root@pumuckl:/usr/local/ssl/misc >
Die benötigten Verzeichnisse werden vom Script angelegt, es muß also
mit root Rechten gestartet werden um in /usr/local/... schreiben zu
dürfen. Schade dabei ist, daß die Zugriffsrechte für private Dateien
nicht automatisch gesetzt werden, dadurch ist erst einmal jeder mit
einem login auf dem Computer in der Lage die komplette CA zu kopieren.
Das ist einer der Gründe, warum in den meisten CA Policy's steht,
daß der Computer auf dem Zertifikate ausgestellt werden in kein Netzwerk
integriert sein darf. Das Script CA.sh stammt übrigens von Tim Hudsen,
einem der Entwickler von SSLeay.
Der Inhalt des Zertifikates, der im letzten Teil des abzuarbeiteten
Scriptes eingegeben wird, ist fest vorgeschrieben. Er dient bei Client-
und Serverzertifikaten der Authentifizierung. Da root-CA's keine übergeordnete
Instanz haben, bei der der Wortlaut geprüft werden kann und der Inhalt
mit keinem Hostnamen übereinstimmen muß kann bei einem selbstunterschriebenen
Zertifikat etwas freier bei der Namensgebung verfahren werden. Nutzer
am Clienten müssen nämlich manuell bestätigen, ob und in welchem Rahmen
sie der jeweiligen CA vertrauen und auf dem Server müssen die Zertifikate
vertrauenswürdiger CA's ohnehin in einem bestimmten Verzeichnis abgelegt
werden.
9.2 Clientzertifikat generieren
Nachdem nun eine CA existiert kann mit der Erstellung eines Zertifikates
für eines Nutzer begonnen werden. Die Nutzerdaten wurden bereits überprüft,
nun ist das RSA Schlüsselpaar zu generieren.
root@pumuckl:/usr/local/ssl/misc > openssl genrsa -out mmr.key 1024
1112 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.......+++++
....+++++
e is 65537 (0x10001)
root@pumuckl:/usr/local/ssl/misc >
Die einzelnen Schritte erfolgen direkt mit OpenSSL und sind deshalb
gut nachvollziehbar. Die eben angelegte Datei mmr.key , die das Schlüsselpaar
enthält wird im nächsten Schritt in eine Request-Datei, einen Antrag
auf Erhalt eines Zertifikates eingebaut.
root@pumuckl:/usr/local/ssl/misc > openssl req -new -out mmr.req -key
mmr.key
Using configuration from /usr/local/ssl/openssl.cnf
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:de
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Technische
Universitaet Chemnitz
Organizational Unit Name (eg, section) []:CSN
Common Name (eg, YOUR name) []:Mirko Mrowczynski
Email Address []:mmr@informatik.tu-chemnitz.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
root@pumuckl:/usr/local/ssl/misc >
Diese Request-Datei enthält exakt die Daten, die zertifiziert werden
sollen. Wird die Konfigurationsdatei /usr/local/ssl/openssl.cnf nicht
verändert, dann wird an jedes so erzeugte Zertifikat der Kommentar
"OpenSSL Generated Certificate" angehängt. Einige CA's tragen hier
Informationen zur Art des vorliegenden Zertifikates ein. Verisign
weist an dieser Stelle bei Testzertifikaten darauf hin, daß sich der
Besitzer nur durch seine E-Mail Adresse authentifiziert hat.
In einige der auszufüllenden Felder wurde lediglich ein Punkt eingetragen.
Diese Felder sind für dieses Zertifikat nicht relevant und werden
im fertigen Zertifikat nicht enthalten sein. Welche Felder unbedingt
ausgefüllt werden müssen und wo eine Eingabe optional ist wird auch
in openssl.cnf festgelegt. Eine Überprüfung findet jedoch erst im
nächsten Schritt statt, eine Fehlermeldung enthält man also auch erst
dort. Nun wird die Request-Datei der CA zur Zertifizierung vorgelegt.
root@pumuckl:/usr/local/ssl/misc > openssl ca -policy policy_anything
-out
mmr.crt -infiles mmr.req
Using configuration from /usr/local/ssl/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'de'
organizationName :PRINTABLE:'Technische Universitaet Chemnitz'
organizationalUnitName:PRINTABLE:'CSN'
commonName :PRINTABLE:'Mirko Mrowczynski'
emailAddress :IA5STRING:'mmr@informatik.tu-chemnitz.de'
Certificate is to be certified until Oct 12 18:00:42 2000 GMT (365
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
root@pumuckl:/usr/local/ssl/misc >
Dem Administrator wird der Inhalt des Antrags angezeigt, nachdem er
das Password, mit dem die Request Datei gesichert ist, eingegeben
hat. Danach wird er gefragt, ob das Zertifikat unterzeichnet werden
soll.
Die Sicherung per Password erfolgt, weil alle bis zu diesem Punkt unternommenen
Schritte auch auf einem anderen Computer als dem der CA ausgeführt
werden können. In vielen Fällen müssen sie sogar anderswo ausgeführt
werden, da die CA sonst den privaten Schlüssel, der zum Zertifikat
gehört kennt. Das Password soll also die zu übertragende Request-Datei
auf ihrem Weg zur CA schützen.
Wird bei der Zertifikatserstellung festgestellt, daß die Daten der
Request-Datei unvollständig sind bricht OpenSSL mit einem Hinweis
auf die fehlende Information ab.
root@pumuckl:/usr/local/ssl/misc > openssl pkcs12 -export -in mmr.crt
-inkey
mmr.key -certfile demoCA/cacert.pem -name "Mirko" -out mmr.p12
Enter Export Password:
Verifying password - Enter Export Password:
root@pumuckl:/usr/local/ssl/misc >
Der Antragsteller sollte sich also gut informieren, welche Informationen
benötigt werden, da durch einen Fehler oder Unvollständigkeit nochmaliges
persönliches Erscheinen notwendig werden kann.
Wenn der Administrator also seinen Segen erteilt hat legt die CA eine
.crt Datei an. In diese Datei werden die mit dem privaten Schlüssel
der CA signierten Nutzerdaten geschrieben. Diese Datei enthält also
das, was später vom Clienten zur Authentifikation an den Server übertragen
wird.
Um jedoch ein komplettes Client-Zertifikat zu bekommen, das aus einer
Datei in den Browser geladen wird muß in die .crt Datei noch der private
Schlüssel des Clienten integriert werden. Das sollte dort erfolgen,
wo das RSA Schlüsselpaar erzeugt wurde. Wenn der Nutzer mit der Zertifikatsanforderung
zur CA gegangen ist, sollte er die .crt Datei mit dem Zertifikat mit
zu seinen Computer nehmen und den letzten Schritt vor dem importieren
in den Browser dort erledigen.
root@pumuckl:/usr/local/ssl/misc > openssl pkcs12 -export -in mmr.crt
-inkey
mmr.key -certfile demoCA/cacert.pem -name "Mirko" -out mmr.p12
Enter Export Password:
Verifying password - Enter Export Password:
root@pumuckl:/usr/local/ssl/misc >
Bei den drei hierfür benötigten Dateien handelt es sich um das Clientcertifikat,
die Datei mit dem Schlüsselpaar des Clienten und um das Zertifikat
der CA, das natürlich frei zugänglich ist. Aus diesen Daten wird dann
die .p12 Datei generiert, die in den Browser geladen wird.
Im Netscape Navigator können solche Zertifikate unter dem Menüpunkt
Security, Certificates, Yours geladen werden. Wenn die Datenbank noch
keine Zertifikate enthält muß nach dem Laden ein Password zur Sicherung
eingegeben werden. Bei jeder Änderung der Datenbank und dem ersten
Zugriff nach starten des Browsers wird dieses dann geprüft. Also Vorsicht,
jeder an der Konsole kann die Zertifikate nutzen, wenn eins in dieser
Sitzung bereits verwendet wurde.
9.3 Pro und Contra eigene CA
Ich habe mich dafür entschieden eine eigene CA aufzubauen, um Server
und Client mit Zertifikaten zu versorgen. Eine andere Möglichkeit
wäre es gewesen die Zertifikate bei bestehenden, anerkannten CA's
anzufordern.
Für HTTP-Server innerhalb der TU-Chemnitz ist das kein Problem, da
das URZ eine eingene CA betreibt \cite{10}. Das hätte auch den Vorteil,
daß man über Web-Seiten des Universitätsrechenzentrums das Zertifikat
dieser CA in den Browser laden kann und der dann in der Lage ist die
Authentizität von HTTP-Servern mit einem Zertifikat dieser CA zu prüfen.
Etwas schwieriger gestaltet sich die Sache bei den Clientzertifikaten.
Es ist natürlich kein Problem für potentielle Nutzer des Servers sich
bei einer komerziellen CA (Verisign, Thawte, Easterngraphics GmbH)
ein Zertifikat zu besorgen. Der Server kann aber bei der Authentifikation
nur eine Gruppenzugehörigkeit prüfen, müßte also erst einmal jedem
Besitzer eines solchen Zertifikates den Zugang gewähren. Eine Möglichkeit
dann bestimmte Verzeichnisse freizuschalten könnte über die Auswertung
von Logfiles mit anschließender Änderung von .htaccess Files erfolgen.
Der Apache ist so vorkonfiguriert, daß er den Inhalt von Clientzertifikaten
zusammen mit Datum und Uhrzeit des Zugiffs und der IP Adresse des
Clienten in der Datei /var/log/ssl_log abspeichert. Diese Variante
bietet jedoch eine ganze Reihe von Angriffsmöglichkeiten, so das nicht
annähernd die Sicherheit bietet, die mit Zertifikaten von nur einer
CA erreicht wird.
Langfristig wird aber daran weitergearbeitet werden müssen Nutzerzertifikate
unterschiedlichster CA's zu akzeptieren da sonst jeder Nutzer eine
Reihe von Zertifikaten verwalten muß. Ähnlich wie bei Schlüsseln oder
Chipkarten kann der Besitzer einem Zertifikat dann nicht mehr die
volle Aufmerksamkeit schenken, was einen Mißbrauch erleichtert. Peinliche
Situationen können bereits entstehen, wenn aus Versehen das falsche
Zertifikat an den Server geschickt wird. Das ist dann etwa so als
fällt einem beim Bezahlen die Rabattkarte des Konkurenzunternehmens
aus der Tasche.
Server Einrichten
10.1 Installation
Beim Einrichten eines HTTP-Servers habe ich mich an das gehalten, was
mir mit der SuSE 6.0 in die Hand gegeben wurde. Der bekannteste und
wohl auch ausgereifteste HTTP-Server unter Linux, der natürlich auch
auf der SuSE Distribution nicht fehlen darf, ist der Apache. Der Apache,
bei mir in der Version 1.3 im Einsatz, zeichnet sich durch eine Reihe
von Eigenschaften aus, die ihm zu einer Vormachtstellung unter Web-Servern
verholfen hat und ihn Dank dieser Eigenschaften auch für meine Zwecke
geeignet macht.
Größter Pluspunkt bei einem komerziellen Einsatz ist sicher, daß der
Apache bei laufendem Betrieb gewartet werden kann. So ist es möglich
die Konfiguration zu ändern während Verbindungen zum Server bestehen
und dadurch eine nahezu ununterbrochene Verfügbarkeit zu gewährleisten.
Für meine Aufgabe steht jedoch der modulare Aufbau des HTTP-Servers
im Vordergrund. Diese Modularität ermöglicht es in Abhängigkeit vom
Verwendungszweck die Funktionalität des Servers zu ändern.
Eines dieser Module ist mod_ssl. Mit seiner Hilfe wird der Apache HTTP-Server
SSL fähig. Da unabhängig von den gezeigten Serverinhalten etwas gegen
mögliche Kommunikationsbedrohungen getan werden sollte ist der Einsatz
von SSL-fähigen Servern dringend zu empfehlen. Bei SuSE wird aus diesem
Grund neben dem normalen Apache, der natürlich auch durch Module ergänzt
werden kann, ein bereits vorkonfigurierter SSL-fähiger Apache angeboten.
\resizebox*{14cm}{10cm}{\rotatebox{270}{\includegraphics{pics/apassl.eps}}}
([fig] vorkonfigurierte
Apache Webserver)
Nach der Installation des apassl Paketes kann sowohl über Port 80,
den HTTP-Port als auch über Port 443, für Secure HTTP, eine Verbindung
zum Server aufgebaut werden. Das Wurzelverzeichnis für Dokumente ist
in beiden Fällen /usr/local/httpd/htdocs/ . Das kann aber für Bereiche
in denen die Verwendung von HTTPS zwingend erforderlich ist so umkonfiguriert
werden, daß ein Besucher über HTTP auf Port 80 die Meldung bekommt,
daß es sich um einen geschützten Server handelt und die Verwendung
von HTTPS mit anschließender Authentifikation per Zertifikat erforderlich
ist. Diejenigen, deren Authentizität geprüft wurde, erhalten dann
Zugriff auf das Wurzelverzeichnis von Port 443.
10.2 Konfiguration
Unter Beibehaltung der Standardeinstellungen erfolgt keine Überprüfung
des Clienten. Es wird davon ausgegangen, daß Informationen öffentlich
zur Verfügung gestellt werden. Um nun eine Authentifizierung zu erzwingen
muß die Konfiguration des Servers geändert werden. Alle damit in Zusammenhang
stehenden Dateien befinden sich in /etc/httpd/ . Der HTTP-Server lädt
beim Start oder einem Konfigurationsupdate die Dateien access.conf,
httpd.conf und srm.conf . In welcher Datei welche Informationen enthalten
sind spielt für den Server keine Rolle. Die Aufteilung erfolgt um
das Auffinden und Verändern bestimmter Einstellungen zu erleichtern.
Was als Segen gedacht war kann aber leicht zum Fluch werden. Die Möglichkeit
Ergänzungen an beliebiger Stelle vornehmen zu können sollte innerhalb
der Konfigurationsdateien mit Vorsicht behandelt werden, da durch
solche Ergänzungen eventuell vorher getroffene Einstellungen überlesen
werden oder die Ergänzungen selbst durch spätere Anweisungen ihre
Gültigkeit verlieren. Vorteilhaft bei dieser Art des Überlesens ist
jedoch, daß grundsätzlich erst einmal Alles verboten werden kann und
anschließend nur gewünschte Sachen freigeschalten werden. Dadurch
können Sicherheitslücken vermieden werden ohne das ein konkreter Verdacht
besteht.
Der Apache HTTP-Server verfügt über vier Varianten der Clientauthentifikation
per SSL. Ausgewählt wird eine der Möglichkeiten über die Variable
SSLVerifyClient in der Konfigurationsdatei httpd.conf :
# set client verification level: [RECOMMENDED]
# 0|none: no certificate is required
# 1|optional: the client may present a valid certificate
# 2|require: the client must present a valid certificate
# 3|optional_no_ca: the client may present a valid certificate
# but it is not required to have a valid CA
SSLVerifyClient 2
Voreingestellt ist das System nach der Installation auf none. Es erfolgt
keine Überprüfung des Clienten, alle Informationen sind frei zugänglich.
Für die Varianten bei denen der Client ein Zertifikat vorzeigen kann,
aber nicht muß, konnte ich keinen Nutzen feststellen. Mit der Aussage
des Servers "wenn du mir unbedingt sagen möchtest wer du bist dann
tu es, aber ich möchte es eigentlich nicht wissen" läßt sich die Sicherheit
des Systems einfach nicht verbessern. Die Möglichkeiten 1 und 3 haben
für meine Arbeit keinerlei Bedeutung. Die einzige Variante den Server
zu zwingen die Authentizität des Clienten zu prüfen ist es SSLVerifyClient
auf zwei oder require zu setzen.
Bei dieser Einstellung wird nach der Kontrolle, ob das Zertifikat zeitlich
gültig ist und der Client den zum Zertifikat gehörenden privaten Schlüssel
besitzt auch überprüft, ob der austellenden CA vertraut wird. Für
den Server gibt es an dieser Stelle nur zwei Varianten. Ihm ist das
Zertifikat der CA bekannt und er vertraut ihr, oder er kennt es nicht
und lehnt den Clienten ab. Da der Server mit Clientzertifikaten unterschiedlichster
CA's umgehen muß gibt es im Konfigurationsbereich des HTTP-Servers
ein Verzeichnis in dem die Zertifikate aller für ihn vertrauenswürdigen
CA's untergebracht sind.
Um nun den HTTP-Server zu veranlassen den Client mit dem von uns ausgestellten
Zertifikat zu akzeptieren muß das Zertifikat unserer eigenen CA in
den SSLCACertificatePath des Servers kopiert werden. Der Name, den
die auf dem Server abgelegte Date hat spielt keine Rolle. Er sollte
nur aus Gründen Der Übersichtlichkeit auf .crt enden. Der Server ermittelt
den benötigten Dateinamen über eine Hashfunktion aus den vom Clienten
übermittelten Informationen über die ausstellende CA. Um dem Server
den Zugriff zu ermöglichen wird ein Link mit dem über die Hashfunktion
ermittelten Namen angelegt, der auf die Zertifikatsdatei verweist.
Die Hashfunktion ist in OpenSSL implementiert und ihr Resultat wird
bei der Erzeugung des Links als Dateiname verwendet.
root@pumuckl:/etc/httpd/ssl.crt > ln -s demoCA.crt 'openssl x509 -noout
-hash -in demoCA.crt'.0
root@pumuckl:/etc/httpd/ssl.crt > ll
total 14
-rw-r--r-- 1 root root 887 Dec 12 1998 Makefile
-rw-r--r-- 1 root root 1385 Dec 12 1998 README.CRT
lrwxrwxrwx 1 root root 10 Oct 13 19:32 c21a8722.0 -> demoCA.crt
-rw-r--r-- 1 root root 1334 Oct 13 19:00 demoCA.crt
-rw-r--r-- 1 root root 4022 Oct 13 19:10 server.crt
-rwxr--r-- 1 root root 40 Sep 24 11:04 view
root@pumuckl:/etc/httpd/ssl.crt >
Da es bei der Anwendung von Hashfunktionen vorkommen kann, daß unterschiedliche
Zertifikate den selben Hashwert liefern, wird bei diesen Dateien die
Dateinamenserweiterung durchnummeriert. Alle Dateien bekommen aus
diesem Grund die Kennung .0 , alle doppelt vorkommenden dann .1 und
so fort.
10.3 Serverzertifikate
Jetzt wo der Server der CA vertraut und damit die Clientauthentifikation
gewährleistet ist benötigt der HTTP-Server natürlich selbst auch ein
Zertifikat. Seine Authentifikation gegenüber dem Clienten ist schließlich
sein erster Schritt beim Verbindungsaufbau. Zum erstellen des Zertifikates
wird die CA verwendet, mit der auch das Clientzertifikat generiert
wurde. Das muß natürlich nicht sein, aber wenn Server- und Clientzertifikat
von der selben CA erstellt wurden sollte es dem Nutzer am Clienten
leichter fallen auf "akzeptieren" zu klicken.
Als erstes muß wieder ein RSA Schlüsselpaar generiert werden \cite{9}.
Das kann auf einem anderen Rechner erfolgen, als dem der CA. Dann
muß jedoch auch die Zertifikatsanforderung dort erstellt werden.
root@pumuckl:/usr/local/ssl/misc > openssl genrsa -out server.key 1024
1112 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.....+++++
.+++++
e is 65537 (0x10001)
root@pumuckl:/usr/local/ssl/misc >
root@pumuckl:/usr/local/ssl/misc > openssl req -new -out server.req
-key
server.key
Using configuration from /usr/local/ssl/openssl.cnf
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:de
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Technische
Universitaet Chemnitz
Organizational Unit Name (eg, section) []:CSN
Common Name (eg, YOUR name) []:pumuckl.csn.tu-chemnitz.de
Email Address []:mmr@informatik.tu-chemnitz.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
root@pumuckl:/usr/local/ssl/misc >
root@pumuckl:/usr/local/ssl/misc > openssl genrsa -out server.key 1024
1112 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.....+++++
.+++++
e is 65537 (0x10001)
root@pumuckl:/usr/local/ssl/misc >
root@pumuckl:/usr/local/ssl/misc > openssl req -new -out server.req
-key
server.key
Using configuration from /usr/local/ssl/openssl.cnf
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:de
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Technische
Universitaet Chemnitz
Organizational Unit Name (eg, section) []:CSN
Common Name (eg, YOUR name) []:pumuckl.csn.tu-chemnitz.de
Email Address []:mmr@informatik.tu-chemnitz.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
root@pumuckl:/usr/local/ssl/misc >
Bei "Common Name" muß exakt der Name des HTTP-Servers eingegeben werden
wie er sonst in der URL steht. Wenn ich hier also pumuckl.csn.tu-chemnitz.de
schreibe, dann lautet die URL https://pumuckl.csn.tu-chemnitz.de .
Eine Fehleingabe würde letztendlich zu einem Zertifikat für einen
anderen Server führen. Der Netscape Navigator gibt eine Warnung aus,
wenn der Server sich mit einem Zertifikat authentifizieren möchte
und die Namen nicht übereinstimmen. Eine solche Warnung wird auch
ausgegeben, wenn ein Nutzer am pumuckl.csn einfach nur https://localhost
eingibt.
\resizebox*{14cm}{10cm}{\rotatebox{270}{\includegraphics{pics/certnamechk.eps}}}
([fig] Kein
Zertifikat für localhost)
Also Vorsicht mit Aliases. Der Browser kann nur den Namen prüfen, nicht
aber die IP.
Der hoffentlich richtig ausgefüllte Antrag für ein Zertifikat wird
dann der CA zum signieren vorgelegt. Der Administrator prüft dann
den Inhalt und OpenSSL mittels Konfigurationsdatei die Vollständigkeit
bevor beide ihr ok geben.
root@pumuckl:/usr/local/ssl/misc > openssl ca -policy policy_anything
-out
server.crt -infiles server.req
Using configuration from /usr/local/ssl/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'de'
organizationName :PRINTABLE:'Technische Universitaet Chemnitz'
organizationalUnitName:PRINTABLE:'CSN'
commonName :PRINTABLE:'pumuckl.csn.tu-chemnitz.de'
emailAddress :IA5STRING:'mmr@informatik.tu-chemnitz.de'
Certificate is to be certified until Oct 12 17:10:14 2000 GMT (365
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
root@pumuckl:/usr/local/ssl/misc >
root@pumuckl:/usr/local/ssl/misc > openssl ca -policy policy_anything
-out
server.crt -infiles server.req
Using configuration from /usr/local/ssl/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'de'
organizationName :PRINTABLE:'Technische Universitaet Chemnitz'
organizationalUnitName:PRINTABLE:'CSN'
commonName :PRINTABLE:'pumuckl.csn.tu-chemnitz.de'
emailAddress :IA5STRING:'mmr@informatik.tu-chemnitz.de'
Certificate is to be certified until Oct 12 17:10:14 2000 GMT (365
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
root@pumuckl:/usr/local/ssl/misc >
Dieses fertige Zertifikat muß nun zusammen mit der auf dem Server verbliebenen
Schlüsseldatei in die Serverkonfiguration integriert werden. Die Datei
server.key mit den RSA Schlüsseln wird nach /etc/httpd/ssl.key/ kopiert.
Dieses Verzeichnis ist nur für Schlüssel des Apache HTTP-Servers vorgesehen
und sollte, da dieser mit root-Rechten gestartet wird auch nur mit
diesen Rechten lesbar und ausführbar sein.
Das Zertifikat kommt zu den anderen, also nach /etc/httpd/ssl.crt/
wo bereits das Zertifikat unserer CA auf seinen Einsatz wartet. Links
müssen diesmal nicht erzeugt werden, die Dateinamen werden über Direktiven
in den drei Konfigurationsdateien festgelegt.
Jetzt muß der HTTP-Server nur noch einmal neu gestartet werden und
zwischen dem Server und dem Clienten kann eine webbasierte Authentifikation
mittels Zertifikaten erfolgen.
References
http://de.news.yahoo.com/991129/11/e54s.html
Oppliger, R. (1992): Computersicherheit : eine Einführung. Viehweg,
Braunschweig, Wiesbaden
http://www.rsa.com/rsalabs/des3/
http://www.research.att.com/~smb/nsam-160/
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
http://home.netscape.com/eng/security/comm4-keygen.html
http://archiv.tu-chemnitz.de/pub/1997/0032/certification.htm
http://archiv.tu-chemnitz.de/pub/1997/0043/vortrag/sontag/policy.html
http://www.tu-chemnitz.de/urz/ca/howto.html
http://www.tu-chemnitz.de/urz/ca/
http://iuk.tu-chemnitz.de